The Nume protocol is a new type of rollup that provides trustless instant settlements without the computational overhead of zero-knowledge proofs. For an overview, please refer to this post. In this blog, we’ll dig deeper into the security model, the limitations of the current implementation, and the roadmap to full trustlessness.
Software verification, not transaction verification
The Nume protocol involves an off-chain system that receives crypto transactions and generates periodic settlements and a set of on-chain contracts that validate settlements submitted to them. While rollups today are secured by on-chain verification of the off-chain transactions (e.g. via zero-knowledge proofs), the Nume protocol is a fundamentally different paradigm. With Nume, the on-chain contract verifies that the new state being settled has been generated by software that has been authorized. That is, given a “correct” rollup codebase (e.g. that would capture transaction validation rules, state tree update rules, etc) that the contract trusts, we need only have a hardware enclave (and no zk proof) that runs this codebase as long as we can prove that the output — the new state root — is generated from a run of this algorithm with the correct inputs (e.g. the correct previous state). The security of the system then rests on: 1) the mechanism for code authorization, and 2) the mechanism for verifying the integrity of a state update — that it is the result of executing the authorized code off-chain.
Authorizing a source update
Nume relies on the active participation of its community to upgrade its protocol. While it is typical for on-chain code to be upgraded via decentralized governance, this is the first time such a process is being applied to off-chain code (i.e. the component that executes inside the hardware enclave). Please note that a multisig will govern the protocol at launch and will be replaced by a DAO shortly afterwards.
To update the Nume protocol’s software (whether onchain or offchain), we will make improvement proposals and collect community feedback. The goal of this step is to settle directional debates. Once the implementation is ready, it will be available for anyone to review and provide feedback. Finally, we transparently generate a commitment to this updated software which anyone can verify the provenance for and put it up for community vote. If the vote passes, the update is automatically finalized onchain.
Finalizing updates to offchain software onchain
An obvious way to authorize the updated offchain software onchain is as follows. The contract stores a reference to the “correct” code that executes inside the enclave such as its hash. In every settlement thats processed, it looks for an attestation document that referneces this hash, thereby attesting to the fact that the new state provided was generated from this code. When there is an update to this offchain code that is affirmatively voted on, the onchain execution of the vote simply changes this reference value stored by the contract to whatever the new hash of the updated source is.
The key drawback with this approach is that such attestation documents generated by enclaves like AWS Nitro or Intel SGX are 1) computationally expensive to decode on-chain (on the order of millions of gas), and 2) verifying them requires verification of the entire chain of trust, meaning multiple signature verifications over a non-blockchain-friendly curve like P384 which further drives up the gas cost by several millions. This results in astronomical gas costs that we would then be forced to pass on to the user, which is exactly antithesis to our goal.
We’ve instead designed an upgrade progress that retains the security of on-chain attestation verification but at 100–200K gas per settlement. Instead of storing a reference to the offchain code, the contract instead stores a “settlement signer” address that it expects each new state update to be signed with. During a settlement verification, all it does is an ECDSA signature verification to check if the provided state has been signed by this address (along with a few other checks). This address is generated inside the hardware enclave; only the enclave knows the private key, and only the original codebase that generated it can ever access it. When an update to the offchain source is to proposed for governance, a attestation document is provided as part of the proposal that contains: 1) an secp256k1 address, 2) a unique reference to the code that was executed to produce this address. Anyone voting on the proposal can independently verify the following things:
The source code (as of this update) yields the same reference value as seen in the attestation document
The source code generates a secp256k1 key-pair that results in the same address as provided in the attestation document, and seals the private key as a secret that is decodable only by that exact same unmodified source
In comparison with the last version, the source code contains updates to the rollup algorithm that they agree with
The attestation document has been correctly signed and the chain of trust to a trusted root CA is verifiable
The checks above can be performed by anyone and ensures that by voting on the proposal, the governance committee only admits a settlement signer address to the contract that exactly and only corresponds to the source update that they would like to vote in.
In the next few blogs, we’ll cover Nume’s data availability model and how the Nume protocol lends itself to parallelized batch processing and hence horizontal scalability.
We would love to hear from you. Please reach out with any questions or feedback here or on Twitter!
