-
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
✨ Account Factory #1
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
qd-qd
force-pushed
the
develop/factory
branch
from
November 24, 2023 20:03
5b14e12
to
ac5958a
Compare
qd-qd
force-pushed
the
develop/factory
branch
2 times, most recently
from
November 24, 2023 20:14
3559b3e
to
2906ce1
Compare
LCOV of commit
|
qd-qd
commented
Nov 24, 2023
qd-qd
commented
Nov 24, 2023
This commit implements the constructor of the account factory contract. It also includes a script to deploy the factory contract and the related unit test. This commit installs a new dependency: eth-infinitism. This dependency is used as foundation for the development of our accounts and our account factory.
This function is used to determine the future address of an account given its login hash. It implement the formula used by the CREATE2 opcode. This commit installs a new dependency: OpenZeppelin Contracts. Some of the utilitary smart-contracts developed by the openzeppelin team will be used for the development of our smart-contracts. As OZ's team forces us to use the version 0.8.20 of the compiler, I had to bump our version of the compiler to this version.
This function is used to check if an account already exists for a given login hash. It either returns the address(0) if the account does not exist, or the address of the account if it does. For testing purposes, I created a wrapper contract that exposes the internal functions of the factory contract as a public function.
This function is used to check if the name service signature is signed by the authorized entity. The function reconstructs EIP-191 message hash based on the provided message (the login hash) then recovers the signer's address from the signature. The function returns a boolean. As it is an internal function, it has been added to the test wrapper.
This commit implements the function to create an account without initializing it. This function can be used in a multi-steps flow where the account is created first and then initialized later. In addition to the unit tests, a new integration test has been added to garantee the deterministic deployment of the account matches the formulas defined in the getAddress function. It's important to note this function deploy a ERC1967Proxy for the user using the provided login hash. Also, a script has been written to call the function from the CLI.
This commit implements the function to create and initializing an account. This function can be used in a one-step flow where the account is created and directly initialized with a signer. In addition to the unit tests, a new integration test has been added to garantee the deterministic deployment of the account matches the formulas defined in the getAddress function and both flow works the same. It's important to note this function also deploy a ERC1967Proxy for the user using the provided login hash. The additionnal arguments are used to initialize the proxy with the provided signer. A script has been written to call the function from the CLI. Last but not least, it is important to mention this function can revert either by the recovery library with use or by the factory itself when the signature provided is valid but the signer is not the one expected. Some notes have been added at the end of the file to give some details about the factory contract and the natspec documentation of the contract has been written.
qd-qd
force-pushed
the
develop/factory
branch
from
November 30, 2023 13:18
9efa1b2
to
b73d19b
Compare
All comments have been taken into account and squashed in the respective commits. Once the CI is clear, I'll merge the PR. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This repository implements the account factory to deploy users' accounts.
The contract exposes three different methods:
getAddress
that can be used freely by anyone who wants to predict the address of the contract that a specific login hash will deploy. This method is also used internally by the two other methods described below.createAccount
is expected to be used during a 4337-compliant flow when the userOp who triggers the flow has some initCode. This method is in charge of deploying an account for the user who requesting it.createAndInitAccount
does the same thing as the method above then init the account by adding a signer to the account. That way the account is directly usable.The accounts deployed by the factory are 1967-proxy that redirect all their call to an account contract deployed by the factory on construction time. Both the implementation of the proxy and the account contracts are hardcoded in the code of the factory.
The code implemented in this pull request has been fully tested, providing maximum coverage.
This is not yet documented in the README but the pull request introduces the Branching Tree Technique (BTT) we gonna use to structure the tests. The BTT was introduced by @PaulRBerg earlier this year and has been presented during EthCC and ETHIstanbul. Even if it is not mandatory to contribute to the project, I recommend using Bulloak to automatically generate the structure of the test files based on the .tree files. All tests are expected to respect the associated .tree files. The CI will be updated in the coming days to enforce this behavior.
You can learn more about BTT by following these links:
The implementation of the account contract is out-of-scope of this pull request and will follow.