Specifications: Fresh account deployment

[yogh333]

    > [Deploy Fresh Account](https://lucid.app/lucidchart/28c9816f-92a9-451f-a919-87c7db925932/edit?invitationId=inv_8d097081-4256-43d1-994b-810fbfa5aadb)

Regarding this sequence, I have already several questions:

1. What kind of WebAuthn authenticators do we plan to support?
2. I have made the assumption that Parsing and Validating the Registration Data will be performed by the Deployer backend. Is it correct?
3. When the Deployer backend shall deploy an account contract, does it rely on UDC?
4. How is the first plugin (WebAuthn) deployed? I have made the assumption that it is the Deployer but how the Deployer, who has its own account contract, can add a plugin to an other account? On the other side, when an account is first deplyed without any plugin (i.e without any public key), how can we interact with it ?
5. Account address shall be recoverable as when the end user will reconnect later using the same WebAuthn authenticator, an new account shall not be deployed. How do we plan to store the account address (deterministic address?) ?

Related to questions 3 and 4, it is yet not clear for me how the initial deployment is performed onchain. Below is a seq diagram describing on-chain operation, but I am not sure I have properly understood (DECLARE vs INVOKE tx, Deployer account vs Fresh account):

Would be happy to get your feedback !

Originally posted by @yogh333 in https://github.com/LedgerHQ/ledger-fresh-management/issues/21#issuecomment-1354557714

[CremaFR]

2. I guess Yes
3. Yes

The account is deployed through a proxy, this imply you deploy the proxy class hash, not the fresh account clash. The proxy has a constructor, this contrustor takes the fresh account clash and params to call a function on the implementation, here initialize. And initialize adds the first plugin

An example can be found here, in the tests

ps: I would split the declare and deploy phases. Declare is done only once per contract and it is just a requirement for a deployment.

[yogh333]

@CremaFR Thanks for the clarification. I agree about declare phase, put them in the diagram just as a prerequisite. I have updated the on-chain operation sequence diagram as following:

[yogh333]

Here are the updated sequence diagrams:

[yogh333]

Authentication step:

[yogh333]

Linked with #7

[yogh333]

⚠️ (in french sorry): Il existe en fait depuis la 0.10.1 un nouveau type de Tx DeployAccount qui permet de déployer un compte et de lui faire payer les frais. Suite à la disparition de la Tx Deploy il existe donc 2 manières de déployer un compte:

1. Un account a déjà été déployé et possède un fonction qui permet de déployer des contrats (via un appel au syscall deploy): dans ce cas, pour déployer un nouveau compte, il suffit d’un transaction Invoke sur l’account lui-même qui appelle cette fonction de déploiement de contrat. Les fees seront payés par l’account qui déploie (deployer).
2. On n’a pas d’account qui permet de déployer un contrat. Dans ce cas, on utilise une Tx DeployAccount qui permet d’auto-deployer un compte et de payer les fees associés. Il faut au préalable que l’adresse du compte (prédéterminée) soit approvisionnée en ETH.

L’utilisation de l’Universal Deployer Contract rejoint le cas 1 mais permet de centraliser le code de déploiement de contrat dans un seul contrat plutôt que dans chaque account contract. Ansi, pour déployer un contrat, il suffit de faire une Invoke Tx vers l’UDC et sa fonction deploy_contract (plus besoin d’une fonction de déploiement de contrat dans un account contract).