7

Context: I'm experimenting with an H160-address based substrate and I'm doing it from scratch (it's not a moon* or frontier template fork).

It's reasonably trivial to make changes to the substrate backend to make it work with the ethereum-style addresses (it's really two lines changed sans extra uses). However, no client is actually able to perform transactions against such a blockchain.

It boils down to SCALE not having enough information in its metadata. For polkadot.js one could add extra types in the web ui, but for something like the python client you're basically stuck, as it vendors in the type extensions for various networks.

Why is this an issue at all? Why can't moonbase return the 'address' type in its metadata to say that it's an EthereumAddress and EthereumAddress is H160 (which is a base type and clients are supposed to know it)?

Unless I'm missing something, that means that if I want to roll out my own substrate chain (be it H160 address based or, say, 16 bytes based UUID), it means that I will have to update every single substrate client for it to know that on the 'uuidchain' it needs to use this weird type.

Isn't the whole point of the chain metadata to tell these details to the clients? What am I missing?

1
  • The metadata already includes the AccountId type. Does it work for you?
    – AurevoirXavier
    Commented May 7 at 3:59

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.