-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add WalletVerify to lotus-gateway #4373
Conversation
@@ -172,6 +177,14 @@ func (a *GatewayAPI) StateWaitMsg(ctx context.Context, msg cid.Cid, confidence u | |||
return a.api.StateWaitMsgLimited(ctx, msg, confidence, stateWaitLookbackLimit) | |||
} | |||
|
|||
func (a *GatewayAPI) WalletVerify(ctx context.Context, k address.Address, msg []byte, sig *crypto.Signature) (bool, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe WalletVerify should already be working in lite-mode. Is this needed for something else?
Here's where WalletVerify is exercised in the gateway tests:
https://github.com/filecoin-project/lotus/blob/feat/gateway-wallet-verify/cmd/lotus-gateway/endtoend_test.go#L72
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. lotus-gateway is for quite a bit more than just lotus-lite.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it makes sense that it works via lotus-lite because the verification is done in the wallet code itself
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but other applications who arent able to import bls and secpk libraries will still need it as an endpoint
return sigs.Verify(sig, k, msg) == nil, nil | ||
} | ||
|
||
func (a *GatewayAPI) StateReadState(ctx context.Context, actor address.Address, tsk types.TipSetKey) (*api.ActorState, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In lite-mode, we use dependency injection to replace some of the methods in StateAPI, ChainAPI etc with methods in GatewayAPI. The way this works for StateAPI is:
- The method is added to the StateModuleAPI
- The method is moved from StateAPI to StateModule (Note that StateModule extends StateAPI)
- GatewayAPI implements a method of the same name
- In lite-mode Dependency Injection replaces StateModule with GatewayAPI
So if you add StateReadState
to GatewayAPI you'll probably also want to add it to node/impl/full/state.go StateModuleAPI and then change StateAPI.StateReadAPI to be StateModule.StateReadAPI:
- func (a *StateAPI) StateReadState(ctx context.Context, actor address.Address, tsk types.TipSetKey) (*api.ActorState, error) {
+ func (m *StateModule) StateReadState(ctx context.Context, actor address.Address, tsk types.TipSetKey) (*api.ActorState, error) {
See StateAccountKey for an example.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dirkmc To make sure we're on the same page, what youre proposing is adding support for lotus-lite to call directly to the gateway to use StateReadState. I'm not currently focused on lotus-lite, what does it do right now for calls to StateReadState?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now it will just call its local StateReadState, which probably won't return anything very interesting because lotus-lite doesn't sync the chain.
I don't believe the change in this PR will have any effect on lotus-lite
Co-authored-by: dirkmc <dirkmdev@gmail.com>
No description provided.