-
Notifications
You must be signed in to change notification settings - Fork 25
Update EVM account mapping, add contract account handling #788
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
Conversation
0050f5e
to
c803f5b
Compare
1adea71
to
4ab495b
Compare
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.
The AccountState
thing looks a bit like a state machine to me (not mapped, mapped, contract account, ...), maybe we make it more explicit?
jor_to_evm: Hamt<DefaultHasher, JorAddress, EvmAddress>, | ||
} | ||
|
||
fn transfrom_evm_to_jor(evm_id: &EvmAddress) -> JorAddress { |
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 should be well documented
|
||
// should update and move account evm account state | ||
let old_jor_id = transfrom_evm_to_jor(&evm_id); | ||
accounts = accounts.evm_move_state(jor_id, &old_jor_id)?; |
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.
Do we allow to map contract accounts to an arbitrary Jormungandr account?
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.
Generally no, we only allow to map to that jormungandr account which user owns, signature validation comes in the another place.
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, but that is currently allowed. I would have expected the implementation to progress in the opposite order not to leave exploitable gaps, but that's not too important in the end, just do not forget to add a ticket for that if it does not exist yet
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.
Sure, we have already tickets for that :)
Yes, good point, but need to think how it is better to do it. |
/// This allows to map any `EvmAddress` to the `JorAddress` before explicit execution of the `EvmMapping` transaction. | ||
/// Intention - is to have possibility to map EVM Contarct accounts with the Jormungandr accounts. |
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 is confusing though, contract accounts should never be part of a EvmMapping
transaction AFAIK, right?
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, contract account should not be a part of the EvmMapping
certificate, will try to paraphrase it. I meant that with the usage of this function we can link contract account with the jormungandr.
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.
contract account should be a part of the EvmMapping certificate
How can this happen?
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.
Sorry, mistaken 😓
contract account should NOT be a part of the EvmMapping certificate
2d6f3d2
to
e0c0075
Compare
/// This allows to map any `EvmAddress` to the `JorAddress` before explicit execution of the `EvmMapping` transaction. | ||
/// Intention - is to have possibility to link an EVM Contarct account with a Jormungandr account. |
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.
those are two slightly different use cases.
- standard account not yet mapped, but that could be mapped in the future
- contract account that can't possibly be mapped
/// | ||
/// Algorithm description: | ||
/// 1. Get `evm_address` bytes representation -> evm_address_bytes | ||
/// 2. Append b"evm" bytes prefix to the evm_address_bytes -> bytes_data |
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.
nit: append a prefix = prepend
/// Algorithm description: | ||
/// 1. Get `evm_address` bytes representation -> evm_address_bytes | ||
/// 2. Append b"evm" bytes prefix to the evm_address_bytes -> bytes_data | ||
/// 3. Calculate hash (pub struct Hash(crypto::Blake2b256) hash) from the bytes_data -> hash_bytes |
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.
nit: don't need a reference to the specific Rust impl here, just mentioning blake2b256 is enough
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 do not master all of the details here, but let's proceed with what we have agreed on
No description provided.