-
Notifications
You must be signed in to change notification settings - Fork 359
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 EthAccount #853
Add EthAccount #853
Conversation
…eat/migrate-eth-account-#573
…eat/migrate-eth-account-#573
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.
Great start, Eric! I left some feedback.
I also have some doubts on the EthAccount
dual dispatcher. The v0 eth account pubkey used the felt252 eth address; whereas, this implementation uses the secp256k1point eth pubkey. Backward compatibility will be an issue. Do you agree?
Also, this review is just for the code. I didn't want to wait any longer, so I haven't looked at the docs yet
Co-authored-by: Andrew Fleming <[email protected]>
…o/cairo-contracts into feat/migrate-eth-account-#573
I don't think we need to be BC with the cairo 0 version, but I'm wondering if we should add the camelCase interfaces for this module at all. A reason to keep it is that some contracts and modules can still be using isValidSignature, and this could be compatible by just passing a different signature (secp256k1 compatible). cc @martriay |
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 work on the docs! I know this is still a WIP, but I left a few comments and questions
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.
Great progress! Left some partial comments, still missing a few modules.
@@ -3,6 +3,7 @@ | |||
|
|||
// Class Hashes | |||
:account-class-hash: 0x016c6081eb34ad1e0c5513234ed0c025b3c7f305902d291bad534cd6474c85bc | |||
:eth-account-upgradeable-class-hash: TBD |
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.
comment to remind us to complete this once we have it
#[derive(Drop, starknet::Event)] | ||
struct OwnerAdded { | ||
#[key] | ||
new_owner_guid: felt252 | ||
} | ||
|
||
#[derive(Drop, starknet::Event)] | ||
struct OwnerRemoved { | ||
#[key] | ||
removed_owner_guid: felt252 | ||
} | ||
|
||
mod Errors { | ||
const INVALID_CALLER: felt252 = 'EthAccount: invalid caller'; | ||
const INVALID_SIGNATURE: felt252 = 'EthAccount: invalid signature'; | ||
const INVALID_TX_VERSION: felt252 = 'EthAccount: invalid tx version'; | ||
const UNAUTHORIZED: felt252 = 'EthAccount: unauthorized'; | ||
} |
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 wonder if this can be abstracted out so it's easily reused in both modules somehow
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.
Since we are prefixing messages with the module name, I don't think so. Do you have something in mind? We could implement traits with different implementations in scope, but that would be overkilling the issue imo.
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 was thinking more about normalizing the errors as Account: ...
because I still feel like treating Account and EthAccount as roughly the same component, the separation wasn't ideal but a workaround. No strong opinions, we can leave it like this.
/// | ||
/// Requirements: | ||
/// | ||
/// - The transaction version must be `TRANSACTION_VERSION` for actual transactions. |
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 updated after #858
@andrew-fleming I've pushed the updates regarding error messages, after we confirm we are ok with it, I will update the rest in the other PR. The rules I'm following:
Let me know what you think. |
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 just left a small comment and a question on the same minor thing. Overall, the error messages look good though. Nice work!
...after we confirm we are ok with it, I will update the rest in the other PR
Good call 👍
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.
Really great job! It looks very good to me. I think we're ready to test this onchain.
Co-authored-by: Martín Triay <[email protected]>
…o/cairo-contracts into feat/migrate-eth-account-#573
…eat/migrate-eth-account-#573
We can fix the conflicts and merge. |
…eat/migrate-eth-account-#573
…eat/migrate-eth-account-#573
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.
fix conflicts and good to merge!
…eat/migrate-eth-account-#573
Fixes #573
PR Checklist