# Account coordinator scope ## Prover Gadget description The Prover Gadget will assist on ETH1 -> ETH2 chain communication in the process of Ethereum staking for ETH2 validation and will execute the following functions: 1) Create a withdrawal smart contract for the user (ETH1). The creation could be done by using CREATE2 function and contract Proxies. 2) User then will use the account + withdrawal credentials generated by the Prover Gadget in the process of staking 32ETH. 3) Generate the proof to confirm the account was generated by the Prover Gadget and ETH was deposited with the appropriate credentials. 4) Use the proof to mint 24 dETH and 8 SLOT tokens (Verify deposit data by ZK proof and make sure the withdrawal credential of submitted validator credential match the secret of deposit address) The bigger picture of the Prover Gadget use case can be seen here: ![](https://i.ibb.co/Sr1NyJT/swimlanes-6747994293c23b65c180b8843192d68d.png) [open pic here](https://i.ibb.co/Sr1NyJT/swimlanes-6747994293c23b65c180b8843192d68d.png) **Disclaimer**: Alice can only get withdrawal credential ownership only when she registered herself as a knot (I.e. Only when she has dETH and SLOT tokens), otherwise fraud is unpreventable. The Deposit/Withdrawal is managed by ETH1 hence all data structures neccesary for proofs are available on ETH1 chain, hence temporary (Before the ETH2 merge happens in 1-2 months) solution for the Prover Gadget is possible without using Inter-Blockchain communication. ## Secret information reveal requirement In order to complete the flow of ETH2 deposit to Stakehouse, the private key of the signer needs to be revealed to the specified group without revealing it in the Ethereum ledger. Hence, the requirement for storing encrypted N bytes (Ethereum datatype `bytes`) in the smart contract arises. The permissioned group should be able to decrypt these N bytes. The group is known on-chain and can change at any time (both by adding and removing members). The decryption of data should only be possible through the member contract. https://eips.ethereum.org/EIPS/eip-1186 - it is possible to get any piece of data from an ETH1 smart contract with proof and therefore we can easily establish if someone is a member of a smart contract. The data does not have to be fully on-chain. Decentralized storage solutions (Ex: arweave) are also possible. The important feature here is that ***only*** specified users could access data. We are open to various cryptographic schemes, including but not limited to Distributed Key Generation: https://eprint.iacr.org/2019/985.pdf Github:[(https://github.com/PhilippSchindler/ethdkg/)](https://github.com/PhilippSchindler/ethdkg/) One real-world alternative would be TV broadcasts: - Alice pays for TV subscription => Gets a session key to decrypt TV signal => Can watch TV. - Bob does not pay for TV subscription => Does not have a session key to decrypt TV signal => Can't watch TV ## How ETH2 deposits work The ETH2 chain is currently running only with the purpose to collect the staker deposits from ETH1 chain and is unavailable for any other actions or entities (Including smart contracts, transactions or withdrawals). The withdrawals of funds will only be available in the foreseeable future, when the mainnet will begin using Beacon Chain for consensus. All of the deposits to the ETH2 chain are handled through ETH1 smart contract. The flow is represented in the diagram below: ![](https://i.imgur.com/Bwgb2G8.png) The scheme for key generation is depicted below: ![](https://i.imgur.com/mFA4ki3.png) The code example on deposit execution and validation can be found here: https://github.com/JustinZal/eth2-deposit-simulation ## Input description #### ETH2 account details: - Public Key (BLS) - Withdraw Credentials (hash of withdrawal scheme + private key) - Amount (Amount deposited to the contract) - Custodian (ETH1 address) - Signature (The data above signed by ETH2 account) *Public key example*: `0x88b057a5fa85bef17f324a5c778af4f90ced165e289915ca9c9ea9d8acb84b536967be860dd82fde2a86aa3199161b39` *ETH1 address example*: `0xdac17f958d2ee523a2206206994597c13d831ec7` ## Further system information The preference for the ZK library is `arkworks`, because it is actively maintained and widely used. (https://github.com/arkworks-rs/snark) **Cross-Chain communication parameters:** `Domains:` ETH2 & ETH1 `Channel:` Prover Gadget ( zk-snark validator) `Public recovery:` snark verifier ref: ETH2 deposit data : https://hackmd.io/@blockswap/BJBKa9ORv ![](https://i.imgur.com/Ub6WqiA.png)