State Evaluation (Rollup)
A Verifiable Computation Layer for Meter Data
The M3tering Protocol introduces a specialized, high-throughput system for aggregating vast amounts of time-series data from smart meters and making it verifiably available to on-chain applications. At its core, the system functions as an Application-Specific Rollup, leveraging the power of zero-knowledge proofs to execute complex computations off-chain while inheriting the full security and data availability guarantees of the Ethereum mainnet.
The primary challenge this system addresses is the impracticality of processing high-frequency Internet of Things (IoT) data directly on a Layer 1 blockchain. A smart meter might report energy consumption every minute, and a network of thousands of such meters would generate an overwhelming volume of transactions, leading to prohibitive gas costs and network congestion. Our solution is to aggregate this data off-chain and then periodically commit a succinct, cryptographically secured proof of the new global state to Ethereum. This allows smart contracts—for applications like prepaid energy billing, tokenized carbon credits, or renewable energy certificates—to access trustworthy, up-to-date energy consumption data without bearing the cost of processing every individual data point.
Aggregation and Proving (off-chain)
An integral part of our rollup’s trust model is a formally verified cryptographic pipeline built using SP1 (Succinct Prover 1), a high-performance zero-knowledge virtual machine (ZKVM) developed by Succinct Labs. SP1 enables arbitrary Rust programs to be executed in a provable environment and verified succinctly on-chain using a zk-SNARK proof system. This approach allows the M3tering Protocol to compress high-volume smart meter computations into compact proofs that can be validated on Ethereum at low cost. The meter aggregation logic is written in such a Rust program and compiled down to SP1 bytecode that targets SP1 Groth16 proofs. Provers are stateless and ephemeral: they reconstruct all necessary state from Ethereum (via state blobs and MPT proofs) and does not need to maintain any historical data. This architecture makes proving accessible to any participant without requiring persistent infrastructure or privileged roles.
A prover begins its work by gathering a set of inputs. These inputs are the foundation upon which the new state will be verifiably built. They include the last known state bobs for both nonces and energy, a recent Ethereum blockhash to act as a trust anchor, a collection of unprocessed meter data transactions, and cryptographic proofs of the meters' public keys.
The prover fetches the bytecode of the latest nonce and energy SSTORE2 contracts directly from Ethereum. These blobs represent the starting point for the new computation. The prover then selects a recent block from the Ethereum chain, typically one within the last 256 blocks, and retrieves its blockhash. This blockhash is critical, as it corresponds to a specific, immutable state of the Ethereum world computer. It is against this state that all public key validations will be performed.
With the state anchor established, the prover uses the eth_getProof JSON-RPC method. This powerful function allows the prover to request a Merkle-Patricia Trie (MPT) proof for a specific piece of data within Ethereum's state. For each meter with pending transaction it intends to process, the prover fetches an MPT proof that demonstrates the value of the meter's public key as stored in the m3ter NFT contract at the checkpoint block. This mechanism ensures the prover is using the authentic, on-chain registered public keys for signature verification.
eth_getProof provides a verifiable link from a known blockhash down to a specific storage slot containing a meter's public keyOnce all inputs are gathered, the SP1 program executes its core logic. It iterates through the list of unseen data transactions. For each transaction, it performs two critical checks. First, it verifies the ED25519 signature of the transaction using the public key whose authenticity was just confirmed via the MPT proof. Second, it checks the transaction's nonce, ensuring it is exactly one greater than the last known nonce for that meter from the input blob. This sequential nonce prevents replay attacks and guarantees that each transaction is processed exactly once.
If a transaction passes both validations, its energy consumption value is added to the meter's cumulative total, and its nonce is incremented. After processing all valid transactions in the batch, the prover constructs the new_nonce_blob and new_energy_blob. These are formed by concatenating the updated 6-byte values for each meter, indexed by their tokenId.
Finally, the SP1 program generates a Groth16 zk-SNARK proof of this entire computation. The proof cryptographically attests that the new state blobs were correctly derived from the initial state blobs according to the rules of the protocol. The program's output consists of the proof itself and a set of public outputs that the proof commits to. These public outputs are the keccak256 hashes of the initial and new state blobs, along with the checkpoint blockhash, which are essential for on-chain verification.
Verification and State Update (on-chain)
With the proof and new state blobs in hand, the prover submits a transaction to the M3tering rollup contract on Ethereum. This transaction includes the proof, committed state blobs, and the anchor block number. The rollup contract first uses the BLOCKHASH opcode to retrieve the blockhash for the specified anchor block number. It then passes this retrieved blockhash, along with the other public outputs and the proof, to the SP1 Groth16 verifier. If the verifier confirms the proof's validity, the rollup contract proceeds to deploy the new nonce and energy blobs.
These blobs are simple, contiguous blocks of data. Each meter is allocated a 6-byte slice within the blob, indexed by its tokenId. For a meter with tokenId = i, its nonce can be read from bytes 6*i to 6*(i+1)-1 of the nonce blob. The aggregated state of all meters is stored on-chain using the SSTORE2 pattern. This technique stores data in the bytecode of a deployed contract, offering significant gas savings for writing and reading large, static data blobs compared to traditional SSTORE operations. This structure is highly efficient for on-chain parsing but imposes a hard limit on the system's capacity. Due to the Ethereum contract code size limit of 24kb (EIP-170), the maximum indexable byte is 0x6000. This translates to a maximum tokenId of 0x1000, limiting the system to 4096 meters per rollup instance. Two separate contracts are maintained for each state update: one for meter nonces (to prevent replay attacks) and one for their cumulative energy sums.
The deployment uses CREATE2 for deterministic addressing. The unique salt for the deployment is the chain length—the sequential number of this state update since the genesis. This elegant mechanism ensures that the address of each historical state blob can be easily recomputed, allowing applications to "time-travel" and query the system's state at any point in its history simply by knowing the update number.
The raw transaction data processed in the batch is also posted to Ethereum's Proto-Danksharding blob sidecar for cost-effective, short-term data availability, and simultaneously archived to long-term storage solutions like Arweave or Filecoin for permanent verifiability.
Other Components
M3ter NFTs (ERC721): Introduced on page M3ter NFTs, The M3ter contract serves as both a digital registry of asset ownership and a keystore for smart meter identities. Specifically, each token maintains a 32-byte Ed25519 public key, mapped in contract storage to it's tokenId, which is used to verify the authenticity of data transmissions sent by the corresponding physical meter. Beyond identity binding, the NFT's metadata can also link to external attributes describing the physical asset—such as location, capacity, certification, or grid integration—via attestations published using the Ethereum Attestation Service (EAS). These attestations provide a decentralized way to associate rich contextual data with the M3ter NFT while maintaining compatibility with Ethereum's trust mode
Peer-to-Peer Network: Nodes running the off-chain client software form a p2p network using protocols like Waku or Streamr. This network is used to gossip and share pending meter data transactions before they are aggregated into a proof.
Last updated
Was this helpful?