This issue is an RFC for defining requirements for the Local Network. Why now? Because the local network flow is disrupted by block-building changes like pipelining and multiple-blocks-per-slot, so we need to define what flows need to be preserved in the local network and which ones can be dropped.
Devs use the Local Network, as in aztec start local, formerly known as Sandbox, when they want to test an app they are developing. They have already written unit tests for their contracts using the TXE, and have written e2e tests using aztecjs. They care for a fast and easy-to-use network, so they can iterate fast before moving to testnet.
As such, we propose:
- Local Network connects to an Anvil instance with automine enabled (ie every time an L1 tx is sent, a new block is mined). The Local Network can run cheat codes as needed over the Anvil instance, such as force-mining blocks or altering timestamps. The Local Network or Anvil timestamps may not match system time.
- Local Network behaves similarly to Anvil in automine mode, in that whenever an Aztec tx is sent, it gets included in a block and mined immediately. The local network node does not wait for more txs to arrive before closing and publishing a block. Likewise, blocks are checkpointed to L1 immediately, the local network produces strictly one block per slot.
- Local Network does not require real Chonk proofs, nor does generate real rollup proofs. It does submit a fake rollup proof to L1, to enable exits to L1 (ie outbox messages), every time a new block is mined. As such, blocks in the Local Network transition automatically and near-immediately from proposed to checkpointed to proven.
- Devs have access to cheat codes for force-mining an empty block immediately, or for warping time to the future by setting the time of the next block to be mined. Note that mining empty blocks is needed for consuming inbound messages (ie inbox messages).
Local network will not support:
- Forming a network with other L2 nodes.
- Connecting to a real Ethereum execution client (instead of Anvil)
Local network may eventually support:
- Real proofs.
- Mining blocks at a specific cadence (ie mining one block every N seconds)
- Mining multiple blocks per slot.
- Connecting to an Anvil instance with interval mining (instead of automine).
- Cheat codes for triggering reorgs or other behaviour.
- Testing migrations from older protocol versions.
This issue is an RFC for defining requirements for the Local Network. Why now? Because the local network flow is disrupted by block-building changes like pipelining and multiple-blocks-per-slot, so we need to define what flows need to be preserved in the local network and which ones can be dropped.
Devs use the Local Network, as in
aztec start local, formerly known as Sandbox, when they want to test an app they are developing. They have already written unit tests for their contracts using the TXE, and have written e2e tests using aztecjs. They care for a fast and easy-to-use network, so they can iterate fast before moving to testnet.As such, we propose:
Local network will not support:
Local network may eventually support: