Deposit contract checklist

[JustinDrake]

• 1. Unify repos: Move deposit contract to eth2.0-specs repo. See Move deposit contract back #1127.
• 2. Remove Eth2Genesis: Rely on a more flexible genesis trigger, external to deposit contract. (Also reduces line count from 140 to 120.) See also CHAIN_START_FULL_DEPOSIT_THRESHOLD bypass #1048.
• 3. Remove merkle_tree_index: See Simplify deposits #1122.
• 4. Cleanups: Consistent comment formatting, linting, more comments, etc.
• 5. Gas profiling: Understand where gas is spent and check there is no significant wastage. See Gas consumption of different part of the deposit function call #1150.
• 6. (post-freeze discussion) Formal verification: Opcode-level formal verification to start in June by Runtime Verification.
• 7. (post-freeze discussion) Wait for BLS standardisation: Various details (G1/G2 point serialisation ambiguity, cipher-suite bits, proof of possession standard, etc.) need to figured out before deployment.
• 8. (post-freeze discussion) Deployment address: Agree on mechanism to generate deployment address (e.g. use CREATE2 or not), and clearly communicate to public. (Want to avoid scam/fake deposit contracts.)
• 9. (post-freeze discussion) Deploy early: Deploy ahead of target Eth2 genesis, even if less than two clients are production ready. Suggested deposit contract deployment target: end of Q3 2019 (30 September). Suggested Eth2 genesis target: 3 January 2020 at 00:00 UTC (Bitcoin's 11'th anniversary).

[hwwhww]

Link the formal correctness proof of get_deposit_root by Runtime Verification (ethereum/deposit_contract#44 (comment))

Thank you @daejunpark!

[JustinDrake]

array access for bytes[] not currently supported in vyper

We could try asking the Vyper people to add this feature :)

[djrtwo]

The pressing items here have been handled. Still need to deploy and publicize

closing

[axic]

Points 8) and 9) don't seem to have been covered here. Are there new issues for tracking them?

[q9f]

I don't think we will forget deploying the contract, so tracking it here previously just lead to confusion in the community about the potential dates. Let's see how the testnets work out before considering mainnet action items.

[JustinDrake]

Are there new issues for tracking them?

Pinging @CarlBeek who is the deposit contract guru :)

[axic]

I specifically meant:

8. (post-freeze discussion) Deployment address: Agree on mechanism to generate deployment address (e.g. use CREATE2 or not), and clearly communicate to public. (Want to avoid scam/fake deposit contracts.)

Which is an important and interesting point.

[CarlBeek]

No, there currently aren't issues tracking them, but I don't necessarily think there should be.

8. I am hesitant to use CREATE2 or at very least to define the salt ahead of time because it would allow someone to launch the "official" deposit contract ahead of time. This could lead to loss of funds if users use incorrect tooling that is not pointing to the correct address, uses the incorrect BLS standard etc. I don't see the benefit of using CREATE2 and deploying later instead of just deploying the contract.

More generally, there is an argument to be made here that we should have a deployment procedure. These normally include constructer arguments for contract initialisation, compiler versions, and contract deployment order. The simplicity of the deposit contract means that aside from compiler version (b13-hotfix), these requirements are not relevant. Communicating the address with the public is the harder process and has been further complicated by the cancellation of all conferences.

9. As @q9f stated, I think it is too soon to have this discussion.