Closed
Milestone Jul 17, 2023–Sep 30, 2023

An upgradable EVM-compatible community rollup is used on Mainnet

Goal

The primary goal of this project is to be able to deploy the EVM rollup on mainnet, with a safe and sound implementation.

Required for MVP

L1/L2 Communication

Target: September 25th

  • Implement the withdrawal in the EVM rollup.
    • Introduce precompiled contract to produce the withdrawals in the L2 ( #6193 (closed))
    • Implement the withdrawal entrypoint in the bridge contract ( #6192 (closed))
    • Add an E2E integration test to deposit and withdraw assets
  • Implement the bridge contract for dailynet.
  • Move from ctez to tez in the bridge
  • Add an entrypoint to the bridge to upgrades, instead of dictator in the L2.
  • Support migration of bridges.
  • Add user documentation on how to deposit and withdraw on the rollup (for dailynet and ghostnet).

Release process

Target: Nothing to be done blocking the MVP

  • Add versioning in the kernel, and runs migration after an upgrade.
  • Changelog are produced for every version.
  • Documentation on how to use the EVM rollup is written.

Gasometer #6091 (closed)

Target: October 2nd

  • Relationship between gas and tick is defined.
  • We have an idea on what should approximately be a good gas limit per block, to cap the number of transactions per block.
  • Additional ticks of kernel’s computations are benchmarked and predictable.

Transaction UX is complete

Target: October 9th

  • Invalid nonces are not pending forever #5959 (closed)
  • Transaction hash is replaced by the proper implementation #5962 (closed)
  • Logs are supported by the EVM node #5740 (closed)
  • Support all kinds of transactions (not necessarily the specific semantics).
  • The EVM proxy needs to have a pool of operations:
    • The EVM proxy accept transactions with higher nonces.
    • The batcher has an economic incentive to post the transactions on the L1, i.e. is reimbursed.
    • Transactions can be canceled or speed-up (potentially future work)

Reboot scheduling is safe and sound

Target: October 6th

The following list is more about testing and auditing. Reboot is important, deciding when to reboot and the persistence across reboots is critical.

  • The kernel never goes above the tick limit.
  • The kernel produces the same state when it reboots or not, i.e. rebooting has no impact on transactions.
  • The inbox is persistent across levels, a transaction cannot be lost (in particular deposits).
  • The reboot is stress tested against very high numbers of transactions.

High confidence in EVM compatibility

Target: Unknown

  • The EVM compatibility is tested against reference tests.

Gas model and EVM gasometer

Target: October 15th

These problems needs solution for security/safety:

  • Contract storage cost (when creating new contracts)
  • Refund limit on transactions
  • Upper limit on gas for nested transaction calls (63/64 of current gas)

Backlog (not required for MVP):

  • Refund support for the outcome of run_transaction
  • Refund of cost of durable storage
  • Refund contract storage cost on SELFFDESTRUCT
  • Hot/cold addresses for contract lookup instructions (decides price of lookup)
  • Access list for transactions (what contracts start out as "hot")
  • Price for transaction access list
  • Upgrade SputnikVM version (and primitive_types)
  • Accounting for burned L2XTZ. Count the amount of money spent on transactions
  • Empty address check for contract creation. To make sure we cannot create a contract for an address in use (especially important for CREATE2 instruction)
  • EIP1559 is supported - Fees market
  • Robust EVM node
  • Low-latency sequencer
  • Relationship between gas, tick and time computed on a reference machine to set the gas limit. Also used to pick the reference machine for Etherlink (and users).
  • Benchmarks are run in a CI to keep track of ticks' consumption
  • The EVM rollup infrastructure can be launched with a docker-compose.

Members