Execution model


The Namada ledger execution system is based on an initial version of the Anoma execution model. The system implements a generic computational substrate with WASM-based transactions and validity predicate verification. It is on top of this system which specific features of Namada such as IBC, proof-of-stake, and the MASP are built.

Validity predicates

Conceptually, a validity predicate (VP) is a boolean function which takes four inputs:

  1. The transaction itself (certain parts of the transaction are sometimes analyzed in the VP logic, such as MASP proofs)
  2. The addresses that are involved with that specific VP
  3. The storage state prior to the transaction execution
  4. The storage state after the transaction execution

A transaction may modify any data in storage, which is partitioned into different areas ("accounts"), each associated with a VP. Upon transaction execution, the VPs associated with the accounts whose storage has been modified are invoked to verify the transaction. If any of them reject the transaction, all of its storage modifications are discarded; if all accept, the storage modifications are written.

Namada ledger

The Namada ledger is built on top of CometBFT v0.37 (opens in a new tab)'s ABCI (opens in a new tab) interface with a slight deviation from the ABCI convention: in Namada, the transactions are currently not being executed in ABCI's DeliverTx method (opens in a new tab), but rather in the EndBlock method (opens in a new tab). The reason for this is to prepare for future DKG and threshold decryption integration.

The ledger features an account-based system (in which UTXO-based systems such as the MASP can be internally implemented as specific accounts), where each account has a unique address and a dynamic key-value storage sub-space. Every account in Namada is associated with exactly one validity predicate. Fungible tokens, for example, are accounts, whose rules are governed by their validity predicates. Many of the base ledger subsystems specified here are themselves just special Namada accounts too (e.g. PoS, IBC and MASP). This model is broadly similar to that of Ethereum (opens in a new tab), where each account is associated with contract code, but differs in the execution model.

Interactions with the Namada ledger are made possible via transactions. In Namada, transactions are allowed to perform arbitrary modifications to the storage of any account, but the transaction will be accepted and state changes applied only if all the validity predicates that were triggered by the transaction accept it. That is, the accounts whose storage sub-spaces were touched by the transaction will all have their validity predicates verifying the transaction. A transaction may also explicitly elect an account as the verifier of that transaction, which will result in that validity predicate being invoked as well. A transaction can add any number of additional verifiers, but cannot remove the ones determined by the protocol. For example, a transparent fungible token transfer would typically trigger 3 validity predicates - those of the token, source and target addresses.

The ledger knows what addresses are involved in a WASM transaction because of how the storage is constructed. Each variable in storage is inherently tied to a substorage owned by some account, and thus that VP is invoked.

Supported validity predicates

While the execution model is fully programmable, for Namada only a selected subset of provided validity predicates and transactions will be permitted through pre-defined whitelists configured at network launch.

There are some native VPs for internal transparent addresses that are built into the ledger. All the other VPs are implemented as WASM programs. One can build a custom VP using the VP template (opens in a new tab) or use one of the pre-defined VPs.

Supported validity predicates for Namada:

  • Native
    • Proof-of-stake (see spec)
    • Ethereum bridge (see spec)
    • IBC & IbcToken (see spec)
    • Governance (see spec)
    • Protocol parameters (part of governance)
    • Multitoken (see spec)
  • WASM
    • MASP (see spec)
    • k-of-n multisignature (see spec)