| Config | Value |
|---|---|
| Meta | https://ssz-devnet-0.ethpandaops.io |
| Faucet | https://faucet.ssz-devnet-0.ethpandaops.io |
| CL RPC | https://bn.bootnode-1.ssz-devnet-0.ethpandaops.io |
| EL RPC | https://rpc.bootnode-1.ssz-devnet-0.ethpandaops.io |
| config.yaml | https://config.ssz-devnet-0.ethpandaops.io/cl/config.yaml |
| genesis.ssz | https://config.ssz-devnet-0.ethpandaops.io/cl/genesis.ssz |
| genesis.json | https://config.ssz-devnet-0.ethpandaops.io/el/genesis.json |
The purified web3 devnet builds on top of Prague/Electra. All features are enabled with ELECTRA_FORK_EPOCH / at the prague timestamp. This is the scope of initial devnet:
This is a new SSZ type of which Merkleization must be supported to verify proofs on purified web3.
StableContainer[16] always is hashed as if there were 16 leaves, even if there are only 4 fields.StableContainer all fields are optional. There is an additional mix-in for a Bitvector[N] that indicates which of the fields are actually in use.Profile describes a specific configuration of required / excluded fields within StableContainer. It is only relevant for type safety and for serialization, but does not affect Merkleization. Can be ignored for the initial devnet.StableContainer.This adopts StableContainer for CL data structures and affects the proofs for light client data. Proofs are a bit longer, using a scheme similar to the one used for Electra, as generalized indices change.
Transactions now use SSZ as their on-chain representation. To verify them, initialize a Transaction SSZ StableContainer from the JSON-RPC, and then hash_tree_root it to obtain transactionRoot.
The following JSON-RPC API methods are extended with an inclusionProof object in their response:
inclusionProof contains:
transactionsRoot: The transactionsRoot from the execution block header corresponding to blockHash. Verifying client implementations MUST check that this value matches the block header data.transactionRoot: The hash_tree_root of the transaction object. Verifying client implementations MUST check that JSON-RPC response data matches this root when converted to the Transaction SSZ representation.merkleBranch: An SSZ Merkle proof that proofs transactionRoot to be located at transactionIndex within transactionsRoot. Verifying client implementations MUST check correctness of this proof. The proof can be verified using is_valid_merkle_branch.https://eth-light.xyz offers a viewer to inspect the SSZ representation of any Ethereum mainnet transaction.
✅ Milestone reached: Verifiable transactions
A couple extras that are pending: https://github.com/ethereum/EIPs/pull/8939/files
Similar to the transactions, but for receipts.
authorities in the JSON-RPC response that reflects the list of EIP-7702 SetCode authorities. For the successful ones, it will be the authority signer address. For the failed / skipped ones, it will be the zero address. The key is only there for SetCode transactions.cumulative_gas_used is dropped from the on-chain data; instead, gas_used of the individual transaction is there.logs_bloom is dropped without replacementProofs are on eth_getTransactionReceipt JSON-RPC, follow the same inclusionProof format as for transactions, but use receiptRoot / receiptsRoot / merkleBranch.
Helios needs to construct the SSZ Receipt StableContainer from JSON data, hash_tree_root it then compare with receiptRoot. Check that receiptRoot is at transactionIndex within receiptsRoot. And that receiptsRoot matches the blockHash.
https://eth-light.xyz offers a viewer to inspect the SSZ representation of any Ethereum mainnet receipt.
✅ Milestone reached: Verifiable receipts
Withdrawals are changed to SSZ, this may affect block header validation if withdrawals are checked against withdrawals_root.
Bloom filters for logs are removed as they are not practically useable with their high false positivity rate.
The block hash is now computed as SSZ hash_tree_root. Logs Bloom and PoW fields are gone. Fees are now tracked as a multidimensional fee vector. This affects block header validation.
✅ Milestone reached: Verifiable block headers (beyond what is implicitly trusted from LC protocol)
There are new logs for plain ETH transfers, fee burns, priority fee payments, block rewards, withdrawals and 0-ETH calls. For basic transfers, the new logs take a similar amount of disk space as the Bloom filter used to fill. Further improvements could consolidate the fee burn + priority fee payment to improve parallel transaction execution.
This is a partial implementation of Vitalik’s idea. Instead of adding the external zk infrastructure, we put everything into EL state.
There is a system contract that stores all incremental log accumulator states in mappings. Mappings exist for lookups by address, by topic, and by address+topic. These are the same filters supported by eth_getLogs.
To verify, Helios needs to obtain the state of the accumulator state of the past, it can also cache this whenever it syncs logs. Or have the client application pass the old cached state, if historical state is difficult to query. This is done with eth_getProof and verified against a trusted old block’s parent state.
Then, run eth_getLogs and locally update the accumulators with the processed logs. If the result matches against the on-chain accumulator state (once more, eth_getProof), the logs can be trusted to be correct without extras or missing ones.
✅ Milestone reached: Verifiable logs