-
Notifications
You must be signed in to change notification settings - Fork 179
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 support for MultiAddress #128
Conversation
@@ -25,7 +25,7 @@ type ExtrinsicSignatureV3 struct { | |||
} | |||
|
|||
type ExtrinsicSignatureV4 struct { |
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.
For consistency with polkadot-js/types
, I've not added a ExtrinsicSignatureV5
and have just updated the V4 struct.
@@ -25,7 +25,7 @@ type ExtrinsicSignatureV3 struct { | |||
} | |||
|
|||
type ExtrinsicSignatureV4 struct { | |||
Signer Address |
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.
this will break for all the chains without the multiaddress.
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.
Good point, there are a couple of chains also using substrate master who for reasons of simplicity prefer not to use MultiAddress.
We could this solve this by making ExtrinsicSignatureV4.Signer
an interface type:
type ExtrinsicSignatureV4 {
Signer interface{}
...
}
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 think we could abstract out the Signerwith Address and MultiAddress as default implementations. This wouldn't break the compatibility
Guys, we are working on ChainBridge, and this PR needs to be merged since this issue a blocker for us. Can you please merge the PR if it is ready? |
Hey @Gauthamastro we're kinda using our own fork of GSRPC now as MultiAddress support is only one of about a half-dozen changes required to support Substrate 3.0 fully (at least for our specific needs): https://github.com/Snowfork/go-substrate-rpc-client We don't have an ETA for merging this work upstream, as it is lower priority for us right now, given our schedule. |
Ohh okay thanks for the fork. We will use that |
@vedhavyas cool cool. There's a bunch of other V3 changes in our fork if you want to pick up those too: https://github.com/Snowfork/go-substrate-rpc-client. They also include RPC APIs for offchain storage. |
MultiAddress is the new default address type in Substrate master (See paritytech/substrate#7380).
Tested against the latest
node-template
from Substrate master using the following:go test -v -timeout 30s -run ^TestChain_SubmitExtrinsic$ github.com/centrifuge/go-substrate-rpc-client/v2/teste2e
Leaving this PR in draft mode as a bunch of tests still need to be updated 🙂