espressosystems/espresso-sequencer

espresso-sequencer's Issues

`Transaction`: Implement `commit`

Needed to satisfy Committable trait for Transaction

Implement REST API to submit transactions

Dependencies

• #16

Implement HotShot-Hermez Adapter

Note: we haven't decided yet if this adapter should be a stand-alone service or if it should be integrated into the zkEVM application. Task details may change slightly based on that decision.

• #33
• #22
• #34

Implement HotShot traits for State type

• Add field for ChainVariables: at least a chain ID.
• Add field for block height (or block number).
• Add field for view number.
• Add field for previous state commitment.
• #50
• #51
• #52
• #53
• #63

HotShot-Hermez Adapter: receive QCs, order commit and block/batch from zkEVM app events

Add crate for zkEVM application

Integrate rollup contract: Post block commitments + QCs to rollup contract

Dependencies

• #4
• #28

Implement HotShot trait for opaque transaction type

Skeleton: define types required for zkevm application

Design rollup contract

Dependencies

• Decide if we first use a dummy contract, or if we modify the zkevm-node contracts (currently they are source available, but not licensed).

Tasks

• #24
• #25
• #26

`State`: Implement `commit`

Needed to satisfy Committable trait for State

Define transaction type (Hermez-compatible)

Run sequencer locally with modified zkevm-node in end-to-end test

`State`: Implement `next_block`

Needed to satisfy HotShotState trait for State

Create smart contract with interface that accepts QCs

Decide on frequency of transactions sent to rollup contract

Integrate rollup contract: Subscribe to block commitment updates from the framework

`Block`: Implement `commit`

Needed to satisfy Committable trait for Block

`State`: Implement `append`

Needed to satisfy HotShotState trait for State

Test infrastructure for contract development

We can borrow from CAPE. If we do write our own rollup contract it may be worth it to invest a bit of extra time to use foundry-rs.

Note that the zkevm-node test infrastructure already runs a local geth client for testing. The testing infrastructure mentioned here is only used for contract development, not for testing the integration with the zkevm-node (for which we will use the zkevm-node test infrastructure).

Tasks

• #27
• #28

Add crate for transaction ordering application

No dependencies.

Create main entrypoint with CLI/env etc.

• Add clap argument parser.
• Set reasonable, working defaults for arguments, where possible.
• Initialize the zkEVM app.

`Block`: Implement `add_transaction_raw`

Needed to satisfy HotShotBlock trait for Block

Initialize the VM agnostic framework with the Hermez application

Transaction ordering application

• Depends on EspressoSystems/HotShot#705

Tasks

• #6
• #7
• #8
• #9
• #10
• #11
• #12
• #13

Initialize HotShot

Interface to subscribe for events (finalized block commitments and then full blocks) for a particular VM

HotShot-Hermez Adapter: write finalized batch to zkevm-node DB (for Aggregator to pick up)

Dependencies

• #37

Adapt zkevm-node Etherman to work with modified rollup contract (if changes necessary).

Dependencies

• #37
• #4

Diagram plugin architecture (VM-agnostic framework interacting with a specific zkEVM application layer, including RPC, prover, and rollup contract)

`State`: Implement `validate_block`

Needed to satisfy HotShotState trait for State

• validate_block needs to check that the parent state commitment of the block matches the current state commitment of the state.
• check that view number is greater than current view number
• check that the first block only contains a genesis transaction.
• check that no genesis transaction (except for in the first block).

Execute committed blocks

Interface to register a VM

As long as it's possible to integrate an app with the sequencer we can consider this done. We currently don't plan on having multiple VMs.

Experiment: zkevm-node Sequencer bypass

1. Run the zkevm-node locally
2. Insert a batch with one EVM transaction into the corresponding zkevm-node database
3. Check if the Aggregator can compute the proof
4. Document what happens

Define opaque transaction with application tag

This type should be an enum with 2 variants, one being a special type of genesis transaction the other one being the regular transaction type the sequencer processes.

• Add Genesis transaction variant containing ChainVariables.
• Add regular transaction variant, name suggestion: Wrapped
• #48

Script to run espresso sequencer with zkevm-node

Skeleton: define types required for sequencer application

See description of types here.

• NodeTypes
  • ConsensusTime
  • Block
  • SignatureKey
  • VoteToken
  • Transaction
  • ElectionConfig
  • State
• Block
• Transaction
• State
• Committable
  • for State
  • for Transaction
  • for Block
• TestableState
• TestableBlock

Estimate gas cost of verifying a QC

Dependencies

• Exact definition of QC
• #5

zkEVM Application

• Depends on #1

Tasks

• #14
• #15
• #16
• #17
• #18
• #19
• #21
• #22
• #23

Sequencer integration with Polygon Hermez

• #37
• #30
• #31
• #32
• #35
• #36

Interface to take an application-specific transaction, wrap it in the opaque transaction type, and submit it to the HotShot layer

More granular tests for `State` validation

Could be worthwhile to make sure we can trip each failure case.

`Block`: Implement `contained_transactions`

Needed to satisfy HotShotBlock trait for Block

Rust test code to deploy the mock HotShot contract

Dependencies

• #4

A rust function to deploy the HotShot contract. We can extent deploy to also deploy the HotShot contract.

Pass execution results to JSON-RPC

Implement HotShot traits for block type

• The block needs to contain transactions: e. g. Vec<Transaction>
• The block needs to contain the parent block's state commitment.
• #45
• #46
• #47

Implement RPC dispatch to forward EVM transactions and queries

No dependencies.

• The RPC dispatch needs to inspect the method of the Ethereum JsonRPC request.
• If the method is eth_sendRawTransaction the request needs to be send to the zkEVM apps Submit API.
• Requests with other methods need to be sent to the zkevm-node RPC.

Subscribe to block updates from the framework

`State`: Implement `on_commit`

Needed to satisfy HotShotState trait for State

Disable unused services/components of Polygon Hermez (Sequencer, mempool)

No dependencies.

This is not a high priority task because as long as we don't make any requests with method eth_sendRawTransaction to the zkevm-node JsonRPC they shouldn't really do anything. I still think it would be nicer for testing locally if we can do so without running the zkevm-node Sequencer.