-
Notifications
You must be signed in to change notification settings - Fork 1
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
I126 secp ext #138
I126 secp ext #138
Conversation
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.
Nice
I just realized that hashing the evm address is not a good idea because it's a one-way operation. However, the oracle needs to query the evm addresses for evm token checks which it cannot do if we store the addresses as hashes. Therefore, I think we should just pad the addresses with zeros to get 32 byte account ids. Then, the oracle will be able to query addresses from the chain and just strip the padding zeros to recover the 20 byte evm addresses. |
Runtime upgrade v104 tested and successfully rolled out into prod today 2:10 pm CEST at commit 5e03a8c, ready to merge. |
Description
Aims to close #126 and #134
Bit rough around the edges, but id gets the job done. What job? Well, we wanted end users to be able to interact with the network using just their metamask wallet. For this to work, we cloned the
Multisignature
implementation fromsp-runtime
and modified theECDSA
part to verify EVM-specific ECDSA instead of a generic one that usedblake2
for hashing the message.blake2_256
with a prefixevm:
PS. polkadot.js does the same