What’s the problem, and what about the solution?

I’d love to start by looking at what Namada is trying to solve and why the problem exists, this is probably the best way to deeply understand the real value behind this project.

The Problem: The Paradox of Transparency and Privacy in Blockchain

Let’s start from the fundamental principle: Blockchains and DLTs, were designed to offer a decentralised, *transparent *and immutable ledger system.

While ***transparency ***is highly valued for its role in ensuring the verifiability of every transaction and preventing fraudulent activities, it also has a drawback: the erosion of financial privacy.

Transparency, which does create a ‘trust-free’ environment, can at the sametime raise concerns about the protection of personal financial information.

The World Economic Forum (WEF) scrupulously underscores, in the *Privacy and Confidentiality Options for Central Bank Digital Currency *paper, the paramount importance of privacy in the digital currency space, elucidating the complexities and nuances of implementing cryptographic techniques, such as Zero-knowledge proofs, to safeguard transactional privacy and confidentiality.

Namada, in its quest to harmonize transparency and privacy, could potentially leverage advanced cryptographic methodologies, akin to those discussed by the WEF, to architect a blockchain protocol that not only adheres to global privacy norms and regulatory frameworks but also robustly safeguards user data and financial transactions.

We can sum up all these points as follows:

• Transparency Paradox: While blockchains offer unparalleled transparency ensuring verifiable and fraud-resistant transactions, this very feature endangers financial privacy.

• Privacy Dilemma: The WEF emphasizes the criticality of privacy in digital currencies, highlighting the intricate balance needed between absolute transparency and complete anonymity in the blockchain space.

• Cryptographic Techniques: Implementing advanced cryptographic techniques, like Zero-knowledge proofs, can safeguard transactional privacy and confidentiality amidst the transparency of the blockchain.

• Namada’s Quest: Namada seeks to harmonize transparency and privacy, potentially utilizing advanced cryptographic methodologies to construct a blockchain protocol that adheres to global privacy norms and safeguards user data and transactions robustly.

• Global Privacy Perspective: The global viewpoint on privacy, navigating through the spectrum from anonymity to transparency, profoundly aligns with the challenges and solutions being carved out in the blockchain sector, presenting a complex yet vital puzzle to solve in the digital currency landscape.

Some articles regarding privacy issues

The solution

This is where Heliax comes in, seated in Zug, Switzerland. A company of visionaries, researchers, and innovators, that stands at the forefront of open-source protocol development.

Heliax’s Logo

Their mission?

To tackle humanity’s most pressing challenges through technology, with the aim of improving individual sovereignty and privacy.

Heliax’s philosophy rests on four foundational pillars:

• Groundbreaking Research: Heliax’s team delves deep, pioneering privacy-centric systems through rigorous research.

• Cutting-edge Design: A holistic approach ensures systems that are not only functional but also user-centric.

• End-to-End Integration: Overseeing the entire lifecycle, from ideation to deployment, ensures consistent feedback and refinement.

• Open-Source Deployment: Transparency is key. Continuous refinement in response to community feedback ensures protocols that resonate with the masses.

Heliax’s Vanguard — The projects

To understand Heliax’s impact, let’s explore some of their flagship projects:

1. Anoma

• Anoma is both a blockchain and an architectural framework for blockchains. Any chain can implement the Anoma architecture, creating what’s known as a “fractal instance” of Anoma, Namada is one them. The main innovation that Anoma brings is an infrastructure

• Link: Anoma

2. MASP (Multi Asset Shielded Pool)

• It’s a set of Rust crates designed for the Multi Asset Shielded Pool extensions of the Sapling circuits from Zcash. It allows for shielded asset types, enabling multiple assets to share the same shielded pool. The MASP retains most of the security, feature, and performance properties of the original Sapling circuits. It introduces the use of asset identifiers to distinguish different asset types and includes a Convert circuit for shielded conversions between distinct asset types.

• Link: MASP on GitHub

3. Vamp-IR

• It’s a language for arithmetic circuits. The Vamp-IR compiler can transform an arithmetic circuit into a form compatible with any proving system backend.

• Link: Vamp-IR on GitHub

4. Taiga

• It’s a framework for generalized shielded state transitions. It allows applications built on top of it to enjoy fully shielded multi-party state transitions.

• Link: Taiga on GitHub

5. Ferveo

• It’s a synchronous Distributed Key Generation protocol designed for front-running protection on public blockchains.

• Link: Ferveo on GitHub

6. PLONK

• It’s a cryptographic method used to verify complex computations efficiently and securely. Think of it as a way to confirm that a digital process was done correctly without revealing the specifics of the process itself.

• Link: PLONK on GitHub

7. Juvix

• It’s a high-level, functional smart contract language and framework that is designed to address the shortcomings of existing smart contract development platforms.

• Link: Juvix Documentation

8. Typhon

• It’s an ordering and execution engine for blockchains that Heliax is building as a CometBFT replacement for Anoma. It has four sub-components: Mempool, Consensus, Execution, and P2P Layer.

• Link: Typhon

Heliax’s Luminaries — The Team

Behind every great project is an even greater team. Let’s meet some of the visionaries at Heliax, the first three are the board members and founders of Namada:

Adrian Brink:

• Former core developer and head of partnerships at Tendermint/Cosmos.

• Technologist at Web3 Foundation.

• Co-founded Cryptium Labs and Metastate with Awa and Christopher.

Awa Sun Yin:

• First female data scientist and software engineer at Chainalysis.

• Researcher at Tendermint/Cosmos.

• Co-founded ventures with Adrian and Christopher, including Cryptium Labs.

Christopher Goes:

• Began his decentralization journey by creating Zchain, a popular explorer for ZCash, and the Wyvern DEX protocol that powers NFT marketplaces like OpenSea.

• Joined Tendermint/Cosmos in 2018 as a core developer and became the author and lead developer of the IBC protocol.

• While contributing to Cosmos until its mainnet launch and the release of IBC, Christopher co-founded Cryptium Labs and Metastate with Adrian and Awa.

Although the above-mentioned members are just a taste of Heliax’s wide range of talents, the team is much broader. As you can imagine, it takes way more than 3 people to build such an ecosystem. As a matter of fact, the team also includes: cryptographers, mathematicians, computer scientists, researchers, engineers, and many more.

Each member, whether named here or not, plays a pivotal role in the company’s success and innovation. I’d like to clarify that the omission of any name is in no way an offence. For a comprehensive view of the entire team and their remarkable backgrounds, please refer to the full link.

ANOMA — The Architectural Marvel

I don’t want to get too far off track with Anoma, but since Namada is a fractal instance of it, a few words must be said.

Anoma isn’t just another chain, it’s an entire architectural structure that reshapes the way we interact with decentralised systems.

Rather than merely processing transactions, *Anoma focuses on building an *intent-based infrastructure. A much-debated narrative at the moment (see here 2 useful posts from @Anoma and @Apriori).

Anoma does not merely execute commands, but tries to understand the underlying intention behind the commands, thus making application development more intuitive and user-centered.

I will soon write a more in-depth article on it. In the meantime, you can read this article by Jon Charbonneau.

NAMADA — A Deep but Smooth Dive into Next-Gen Blockchain Privacy

Now let us finally proceed to Namada. Since it is a relatively broad ‘protocol’, it’s good to start by breaking things down. The key innovations brought by Namada are:

• Privacy as a Public Good

• MASP & CC

• Interoperability

They can be further divided into:

• Proof-of-Stake L1: As a Layer 1 blockchain, Namada operates on a Cubic Proof-of-Stake (CPoS) consensus mechanism.

• Interchain Privacy: Namada’s design prioritizes privacy across multiple blockchains, a feature often sought but rarely achieved.

• Asset-Agnostic: From Nakamigos (NFTs) to $ETH and $DAI, every transaction is shielded, ensuring top-tier privacy.

• Native Interoperability: With the integration of IBC (Inter-Blockchain Communication), Namada seamlessly interacts with fast-finality chains.

• Ethereum Bridge: A trustless two-way bridge to Ethereum amplifies Namada’s reach, facilitating smooth transactions between the platforms.

• MASP Circuit: At its heart, Namada employs an upgraded multi-asset shielded pool (MASP) circuit, allowing a diverse range of assets to coexist within a shared shielded environment.

• Shielded Set Rewards: The recent enhancement to the MASP circuit introduces shielded set rewards, promoting privacy as not just a feature, but a “public good”.

• Public Goods Funding: This one’s a tricky and debated one. I’ll try to explain it better later on, but basically it means that Namada supports “public goods” with a two-pronged approach: continuous and retroactive funding.

Don’t worry if something seems odd, we’re going to look at each one of those in a more detailed but clear way.

The Basics

This section will cover the basics, if you already know what a Layer 1 and a consensus mechanism is, you can just skip ahead to “The Evolution and Significance of Asset-agnostic Shielded Transfers”.

To sum up what *layers *are, you can just imagine a multi-tiered cake, where each layer represents a different level of the blockchain network, each with its own functionalities and purposes, working harmoniously together to deliver a seamless, efficient, and scalable system. Well, in this case Namada it’s the flour at the bottom of the cake.

The Evolution and Significance of Asset-agnostic Shielded Transfers

From the dawn of crypto up to today, transactions were transparent and exposing metadata such as sender/receiver addresses and transaction sizes. This transparency, while ensuring verifiability, inadvertently damaged users’ financial privacy.

🔑 Zero-Knowledge Proofs are cryptographic methods that allow one party to prove to another that a statement is true without revealing any specific information about the statement itself. Imagine proving you know a password without actually revealing the password.

Protocols such as Zerocash, which later evolved into Zcash, introduced the concept of shielded transactions using zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge).

🖲️ ZK-SNARKs differ from standard ZKPs because they provide more efficient, shorter and faster proofs. Whereas standard proofs often involve multiple interactions between prover and verifier, ZK-SNARKs require only one. For security, ZK-SNARKs rely on a common reference string generated by several parties. But newer iterations like ZK-STARKs remove the need for a trusted setup.

Drawing inspiration from Zcash’s Sapling circuit — a cryptographic construction designed to facilitate private transactions — Namada introduced the Multi-Asset Shielded Pool (MASP) circuit. This upgraded circuit leverages homomorphic Pedersen commitments, a type of cryptographic commitment that allows for certain algebraic operations to be performed on the commitment values without revealing the committed data. This ensures that multiple assets can coexist in a shared shielded environment. Whether they are NFTs, an $ATOM, or a $NAM transfer, transactions are indistinguishable from one another.

Central to this is the Jubjub curve, a specific type of elliptic curve optimized for zk-SNARKs. The ctEdwards curve point is a representation on this Jubjub curve, ensuring efficient and secure cryptographic operations. The asset generator, a crucial component in Namada’s system, is a valid ctEdwards curve point on the Jubjub curve. Its uniqueness is derived from the BLAKE2s hash of the asset identifier, ensuring that each asset type has a distinct and secure representation in the system.

Edwards curves of equation x² + y² = 1 − d ·x²·y²​

But how does it work? At its core, the MASP distinguishes between two sets of assets:

• the shielded set, where transactions are completely private, and

• the transparent set, where transactions are public.

In the shielded set, privacy is achieved through Pedersen hashes — a cryptographic hash function that operates over elliptic curves. These hashes ensure transactional privacy by producing a fixed-size output, making it computationally infeasible to deduce any information about the input.

Namada’s innovation also incorporates the Pseudo Random Function (PRF), instantiated with BLAKE2s — a cryptographic hash function faster than MD5, SHA-1, and SHA-2. This PRF ensures that each asset type has a unique representation, preventing potential collisions or overlaps.

Comparison of Hash Functions: BLAKE2s, MD5, SHA-1 and SHA-2

The RFC hash-to-curve method is another crucial component, ensuring that asset identifiers are securely and uniquely mapped to points on an elliptic curve, further bolstering the system’s security.

Namada’s vertical integration is a testament to its commitment to user-centricity. Users can interact with the mainnet seamlessly, generating zk-SNARKs swiftly on edge devices via browser applications. This integration ensures that any asset can be privately and securely transferred from any device, leveraging the power of the MASP circuit and zk-SNARKs.

In essence, Namada’s advancements in asset-agnostic shielded transfers represent a significant leap in ensuring privacy and interoperability across diverse asset types and blockchains. It’s not just about transacting secretly; it’s about doing so without boundaries.

Shielded transfers with ETH, ERC20, NFTs and ATOM on Namada

Namada’s Consensus Mechanism

Namada’s Adoption of CometBFT

Namada, leveraging the CometBFT-rs bindings, offers a trifecta: peer-to-peer transaction gossip, unyielding BFT consensus, and state machine replication tailored for its unique state machine.

Why CometBFT for Namada?

1. Unwavering Finality: Once a block finds its place in the blockchain, it’s there to stay. An indispensable feature for applications that bank on irreversible transactions.

2. Inter-Blockchain Communication: With the Inter-blockchain communication system (IBC) in its arsenal, Namada promises compatibility with all CometBFT-backed blockchains, including stalwarts in the Cosmos ecosystem.

3. Proven Reliability: The Cosmos ecosystem’s longstanding trust in CometBFT stands testament to its reliability.

4. Customizability: Tailor-made solutions are the need of the hour. CometBFT doesn’t disappoint, offering flexibility in parameter adjustments, even accommodating custom proof-of-stake algorithms.

CometBFT

Its essence lies in its ability to function even when up to a third of its machines encounter arbitrary failures. Every non-faulty machine within the system is guaranteed to witness the same transaction log and compute an identical state.

This level of secure and consistent replication is pivotal in distributed systems, serving as the bedrock for applications ranging from digital currencies to infrastructure orchestration.

CometBFT’s design philosophy prioritizes user-friendliness, clarity, performance, and versatility for a broad array of distributed applications. It distinguishes itself from distributed key-value stores like Zookeeper (developed by Apache as a centralized service for maintaining configuration information, naming, providing distributed synchronization, and group services), etcd (an open-source key-value store that provides a reliable way to store data across a cluster of machines), and consul (developed by HashiCorp, is a distributed service discovery and configuration system) by its Byzantine Fault Tolerance.

While these systems can tolerate crash failures in less than half of their machines, even a single Byzantine fault can compromise their entire system. CometBFT, on the other hand, is equipped to handle arbitrary failures, including malicious attacks. Furthermore, it doesn’t confine developers to a specific application, allowing them to craft the logic that aligns with their objectives, be it a key-value store, cryptocurrency, or an e-voting platform.

CometBFT is composed of two primary technical components:

1. Tendermint Consensus Mechanism

2. Application Blockchain Interface (ABCI)

The Tendermint Consensus Engine

This engine, a modern iteration of protocols for event ordering in distributed networks, stands resilient against adversarial challenges. Its primary role? Guaranteeing consensus on transaction ordering among reliable machines through a democratic voting process. Validators, in structured rounds, propose and subsequently vote on blocks, ensuring a uniform transaction sequence.

Visual representation of the Tendermint (CometBFT) consensus mechanism

The Bridge: Application Blockchain Interface (ABCI)

The ABCI, a pivotal component of the CometBFT ecosystem, serves as the communication layer between the consensus process and user-defined applications. Its decoupled design is not just about flexibility; it’s about empowering developers. With ABCI, they can craft deterministic applications across any programming language, without being confined to the consensus algorithm’s inherent limitations.

Core Concepts of ABCI:

• Modularity: ABCI is designed with modularity at its core. It separates the networking and consensus from the application logic, allowing developers to focus solely on the latter without the intricacies of the former.

• Transactions Lifecycle: Every transaction undergoes a lifecycle: from being checked for validity (CheckTx) to being delivered (DeliverTx). ABCI ensures that each step is processed, guaranteeing the transaction's eventual inclusion in the blockchain.

• Blocks and Results: ABCI applications return results for the transactions they process. These results, combined with other transactions, form blocks. The Commit method ensures that all state transitions are atomic, providing a snapshot of the application's state after processing the transactions in a block.

• Querying: ABCI isn’t just about processing; it’s about retrieval too. The Query method allows users to retrieve information about the application's state, ensuring transparency and accessibility.

• ABCI++: An evolution of the ABCI, ABCI++ offers enhanced features, including the ability to manipulate the block before it’s finalized. This provides applications with greater control over block formation, ensuring optimal performance and efficiency.

Visualization of the flow of messages via ABCI

In essence, the ABCI acts as a bridge, but it’s a bridge with intelligence, flexibility, and adaptability, ensuring that applications not only communicate with the consensus but do so efficiently and effectively.

Inter-blockchain Communication System (IBC)

The IBC protocol, built by Cosmos, allows for secure, asynchronous communication between separate blockchains. Through IBC, chains like Namada can:

• Transfer assets and execute Smart Contracts across blockchains

• Maintain light clients without running full nodes

• Coordinate transactions and achieve atomic transfers

• Establish trust and interoperability between diverse ledgers

The IBC, influenced by TCP/IP, is the backbone of cross-chain messaging, enabling true composability and extensibility between any IBC-enabled blockchain. It starts with a handshake for mutual verification between chains. After that, data packets containing various information are exchanged and verified for authenticity. While the IBC guarantees the trustworthiness of the data, its interpretation and execution takes place at the application level. This interoperability, with flexible routing options, is crucial for an interconnected ecosystem of decentralised applications.

Namada’s Cubic Proof-of-Stake (CPoS)

Namada’s PoS mechanism, known as Cubic Proof-of-Stake (CPoS), introduces several innovations that are pertinent to both validators and delegators:

1. Upgraded F1 Fee Distribution Mechanism:

• CPoS employs an enhanced version of the F1 fee distribution mechanism. This system ensures that staking rewards compound automatically, eliminating the necessity for transactions to claim and re-stake these rewards.

• The F1 scheme is designed to split rewards and inflation between validators each block with minimal iteration. The only approximations arise due to finite decimal precision. Notably, this mechanism requires no iteration to delegate or withdraw, making it efficient and scalable.

• The F1 algorithm is agnostic to how fees are divided among validators, offering flexibility in reward distribution. For instance, it’s possible to reward only validators who signed a particular block.

• This mechanism is inspired by the initial F1 Fee Distribution research paper, which emphasizes the importance of a fair reward distribution system in a proof-of-stake blockchain. The paper presents F1 as an approximation-free, slash-tolerant fee distribution algorithm that can handle varying validator commission rates, inflation rates, and fee proportions efficiently.

2. Cubic Slashing:

• Namada’s cubic slashing algorithm ensures that penalties for safety faults are calculated in a manner where the amount slashed increases exponentially if more validators or a larger single validator commit faults simultaneously.

• The slashing rate for a specific infraction is proportional to the cube of the sum of the voting powers of all validators that committed infractions within a (-1,+1) epoch range of the infraction in question. This approach encourages validators operating multiple consensus nodes to deploy diverse and uncorrelated setups, enhancing the security of the network.

This is the Cubic Slashing Formula:

Let’s break it down:

• The multiplier, 9×: This factor further amplifies the penalty, making sure that even small infractions don’t go unnoticed, while larger ones are heavily penalized.

• This part inside the brackets sums up the voting powers of all validators who committed an infraction. Each validator’s voting power, vpi, is divided by the total voting power, vptotal, at the time of their misstep. This gives us a relative measure of how influential the erring validators were in the network.

• The squared term, ² : After obtaining the combined relative influence of the erring validators, we square this value. Squaring emphasizes the impact of larger infractions, ensuring that as the combined fault value grows, the penalty grows at an even faster rate.

This formula ensures that the penalty is not just a mere slap on the wrist. Rather, it grows exponentially based on the combined influence of the erring validators. The result is a network in which validators are motivated to act in the interest of the system.

3. Improved PoS Guarantees:

• Namada’s CPoS ensures that the cost of launching an attack on the network is quantifiable in all scenarios. This is due to the automatic detection mechanism that identifies which accounts (validators, delegators, etc.) contributed to a fault.

4. Transaction Fees in Multiple Assets:

• Namada allows transaction fees to be paid in a variety of tokens. The set of accepted tokens can be updated through a governance vote, providing flexibility and adaptability to the network’s economic model.

Ethereum Bridge

Namada-Ethereum Interoperabilty

Imagine you’ve built a brand-new city (Namada) next to an existing metropolis (Ethereum). Before you can build a bridge connecting the two, there’s a process to ensure it’s safe, efficient, and agreed upon by the city’s council. This is what bootstrapping the bridge is all about. Now, for those interested in the nitty-gritty:

1. Governance’s Role: A proposal is set in motion to decide on the magic block height, h, to activate the bridge. This isn't just a software update; it's a hard fork.

2. The Pause Before the Storm: Once h-1 block is finalized, the Namada chain takes a breather. It's halted.

3. Ethereum’s Side of Things: Smart contracts for the bridge are deployed on the Ethereum side. The validators at h block height are the gatekeepers, ensuring the bridge's integrity.

4. Transparency is Key: Details about these contracts are made public. Anyone can verify them.

5. The Rebirth: If the validators give a thumbs up, Namada chain is reborn with a fresh genesis file, now pointing to the Ethereum proxy contract.

6. Bridge in Action: Once the bridge is live, validators’ ledger nodes get to work, coordinating the first validator set update.

A Practical Example: Imagine epochs being 100 blocks long with a consistent validator set. A proposal emerges to activate the bridge at h = 3400. This proposal sails through, and by block 3399, the chain halts. Ethereum bridge contracts are then deployed, verified, and by block 3400, Namada chain is back, now with the bridge active. Within a few blocks, the first validator set update is in motion.

Security

Main points and details related to the security of the Namada-Ethereum bridge.

1. Namada Validators

• Role as full nodes of Ethereum.

• Stake’s significance in bridge security.

2. Consequences of Malicious Actions

• Forking attack consequences.

• Slashing of stake on Namada for stealing Ethereum tokens.

3. Ethereum-side Precautions

• Asset lock limit to mitigate forking attack damages.

4. Redemption Limitations

• Introduction of speed limits for redeeming wrapped Ethereum assets on Namada.

5. Purpose of Redemption Limitations

• Not primarily for security enhancement.

• Making potential attacks more cumbersome and inconvenient.

Potential Attack on the Namada-Ethereum Bridge: A Brief Scenario

1. The Setup: John the Ripper and his group become validators on Namada, aiming to exploit its connection to Ethereum.

2. The Attack: They initiate a forking attack on Namada, creating a false record of locked Ethereum tokens they never deposited.

3. Redemption Attempt: They try to redeem these fictitious tokens for wrapped Ethereum assets on the real Ethereum network.

4. Namada’s Defense:

• The forking attack is detected; John the Ripper’s group loses their staked assets on Namada.

• Ethereum’s side limits the amount of redeemable assets, capping their potential theft.

• A redemption speed limit slows down their extraction, increasing risk of detection.

Transfers — to Namada

Namada uses two main “accounts” to manage transfers. One is designed to handle the storage and tracking of Ethereum-based assets, and the other is specifically for holding Namada tokens that are set to be sent to Ethereum.

When someone sends an Ethereum-based token, like an ERC20, to Namada, the system either creates a corresponding amount in Namada or releases tokens that were previously held in a special account.

Here’s a more technical explanation:

1. Asset Transfer Mechanism:

• Namada employs two pivotal internal accounts: #EthBridge and #EthBridgeEscrow. The former governs the /eth_msgs/ storage and manages the ledgers for wrapped Ethereum assets, while the latter holds Namada tokens in escrow, which are destined for Ethereum.

2. Wrapped ERC20 Tokens:

• When an ERC20 token voyages to Namada, the TransferToNamada Ethereum event triggers. Validators then mint the requisite amount to the corresponding multitoken balance key for the receiver or liberate the escrowed native Namada token. The Rust struct TransferToNamada encapsulates the transfer details, including the amount, asset type, and receiver.

3. Namada Token Dynamics:

• Wrapped Namada tokens destined for Ethereum must have an equivalent native token held in escrow by #EthBridgeEscrow. Upon the inclusion of the associated TransferToNamada Ethereum event into Namada, validators effectuate a transfer from #EthBridgeEscrow to the receiver.

Transfers — to Ethereum

Moving assets from Namada to Ethereum is a bit more involved. Users initiate a transfer on Namada, which then produces a “proof” on the Namada side. This proof is essential, as users need to take it and submit it to Ethereum to finalize the transfer.

Due to Ethereum’s gas fees, it’s often cheaper to group several transfers together, creating what’s known as a “batch". Namada maintains a special pool where these individual transfers are collected and wait to be batched together.

This pool operates using a tree-like structure (Merkle Tree), and for added security, it requires approval from multiple validators, or trusted entities, within the system. Additionally, there are mechanisms in place to ensure the same transfer isn’t counted multiple times and to manage transfers that might take longer than expected.

Here’s a more technical explanation:

1. Transfer Initiation:

• Transferring assets from Namada to Ethereum isn’t an automatic affair. Users must dispatch a specific transaction to Namada to instigate a bridge transfer. Once greenlit, a cryptographic “proof” is generated and posted on Namada.

2. Proof Retrieval and Ethereum Submission:

• Users are tasked with obtaining the proof of the transaction. This proof, once submitted to the pertinent Ethereum smart contract, facilitates the redemption of Ethereum assets or the minting of wrapped assets. All Ethereum gas expenditures fall under the user’s purview.

3. Batching and Bridge Pool:

• Given Ethereum’s gas fees, it’s economically prudent to batch multiple transaction proofs. The Bridge Pool, akin to a mempool, accumulates these transactions. Users pay an additional NAM fee, held in a Bridge Pool Escrow, to cover Ethereum gas costs. Validators then disburse these fees in NAM to users who relay these transactions to Ethereum.

4. Merkle Tree Organization:

• The Bridge Pool adopts a Merkle tree structure. Every update mandates a signature from a quorum of validators on the tree root. Users aiming to relay transactions to Ethereum must ensure that the Merkle tree root, inclusive of their transactions, is duly signed.

5. Bridge Pool Validity Predicate:

• The Bridge Pool’s storage is governed by a native validity predicate. The storage layout is meticulously structured to ensure seamless transaction processing. The TransferToEthereum Rust struct encapsulates the transfer details, while the PendingTransfer struct includes the gas fee details.

6. Replay Protection and Timeouts:

• Nonces, cryptographic numbers used once, are pivotal in thwarting transaction replays. Given the unordered nature of transactions, some might time out. Such transactions necessitate a state reversion on Namada, including the refund of associated fees.

Namada Governance

Namada’s governance system is intricate, ensuring a robust and transparent decision-making process. It’s divided into on-chain and off-chain governance:

1. On-Chain Governance: This involves decisions made directly within the blockchain. It’s a structured process where proposals are submitted, discussed, and voted upon by validators and delegators. The outcome is determined by predefined rules and protocols.

2. Off-Chain Governance: This is more flexible and involves discussions and decisions made outside the blockchain. It’s a collaborative approach, often involving community consensus.

Proposals

They are structured suggestions for changes or decisions. Each proposal has specific attributes, such as content, author, type, and associated epochs (time periods). Namada supports various proposal types, each with its unique properties and requirements. For instance, a Default proposal allows both validators and delegators to vote and requires a specific voting power threshold to pass.

Storage

Each proposal and its associated data are stored under specific keys, ensuring organized and efficient data retrieval. Governance parameters, such as the minimum proposal fund, maximum proposal code size, and voting time windows, are stored under the GovernanceAddress. Votes, an essential part of the governance process, also have dedicated storage keys. This structured storage ensures that data related to governance is easily accessible and verifiable.

In essence, Namada’s governance system is a blend of structured on-chain processes and collaborative off-chain discussions, ensuring a transparent, fair, and efficient decision-making process.

Economics

Non-Technical Explanation:

Namada’s economic model revolves around its native token, $NAM. Users utilize $NAM to pay for transactions, and as the platform's popularity grows, so does the demand for $NAM. This is because everyone needs it to interact with the system.

On the other hand, Namada doesn’t just have a fixed amount of $NAM. The system creates new $NAM tokens every year, but there’s a limit to how many can be made. These new tokens are used to reward those who help secure the system, incentivize certain activities, and fund projects that benefit everyone. If there are extra tokens beyond what’s needed, they get destroyed to maintain balance.

Technical Deep Dive:

Namada’s economic dynamics are primarily influenced by its transaction fees and inflation model. Users are required to pay transaction fees in $NAM, and potentially other tokens, aligning the demand for $NAM with the demand for transaction space within the network. Refer to the fee system, following this paragraph, for a comprehensive breakdown.

On the supply front, Namada employs a deterministic inflation model. The protocol is designed to mint $NAM tokens at a predetermined maximum rate annually. This rate is a fraction of the existing supply, as detailed in the inflation system. The minted NAM is then channeled into three primary protocol subsidies:

1. Proof-of-Stake (PoS): The reward mechanism for validators who stake their $NAM to secure the network.

2. Shielded Pool Incentives: These are incentives provided to promote certain activities within the network, ensuring privacy and security. More about this can be found in the shielded pool incentives section.

3. Public-Goods Funding: A portion of the minted $NAM is allocated to fund projects and initiatives that are deemed beneficial for the entire Namada community.

Fee System

To ensure the efficient functioning of the Namada network, every transaction must pay a fee to be accepted into the ledger. These fees serve dual purposes:

1. They help in the efficient allocation of block space and gas, both of which are limited resources. Given the open nature of transaction submissions and fluctuating demand, fees help manage these resources effectively.

2. Fees provide an ***incentive ***for block producers to include transactions in the blocks they create.

Namada’s fee system is flexible, allowing transaction fees to be paid in any fungible token that’s part of a whitelist controlled by Namada governance. The governance also sets the minimum fee rates, which can be updated periodically. Transactions can opt to pay more than the minimum to get prioritized by the block proposer. Additionally, when using the shielded pool, transactions can unshield tokens to cover the required fees.

The whitelist consists of pairs, where one part is a token identifier and the other is the minimum price per unit gas for transactions using that token. This list can be updated through standard governance proposals. All collected fees are directly paid to the block proposer, ensuring that there’s no more profitable alternative like side payments.

Inflation System

The Namada protocol utilizes its native staking token, $NAM, to programmatically mint rewards. These rewards cater to:

1. Algorithmically measurable public goods:

• Proof-of-stake security

• Shielded pool usage

2. Out-of-band public goods.

1. Proof-of-Stake Rewards

• Purpose: To ensure the security of the proof-of-stake voting power allocation mechanism, tokens are bonded to validators. These tokens can be slashed if validators act maliciously. The bonded tokens can only be withdrawn after an unbonding period.

• Reward Mechanism: To incentivize validators and delegators for bonding their tokens and participating in consensus, Namada offers inflationary rewards. The inflation rate is adjusted using a PD-controller to aim for a 2/3 bonding ratio. The maximum inflation rate for proof-of-stake rewards is 10% annually. More details can be found in the reward distribution mechanism section.

2. Shielded Pool Rewards

• Purpose: The privacy offered by the MASP is contingent on the number of users and assets in the shielded pool. To promote a larger privacy set, Namada provides inflationary rewards.

• Reward Mechanism: A variable portion of inflation, capped at 10% annually, is allocated for shielded pool incentives. These incentives are distributed based on each asset’s presence in the shielded pool, controlled by a PD-controller. Further insights are available in the shielded pool incentives section.

3. Public Goods Funding

• Purpose: To support non-algorithmically-measurable public goods.

• Reward Mechanism: Namada allocates 10% annual inflation for this purpose. More information is available in the public goods funding section.

Detailed Inflation Calculation Model

Inflation is determined and disbursed every epoch. The calculation involves:

• Fixed Parameters: These include values like the cap of proof-of-stake reward rate, the cap of shielded pool reward rate for each asset, the public goods funding reward rate, and various other parameters related to the PD-controller.

• State Values: These are dynamic values that change over time, such as the current supply of $NAM, the current amount of $NAM locked in proof-of-stake, and other values related to the shielded pool and previous epochs.

• Public Goods Funding Calculation: This is a straightforward calculation based on the public goods funding reward rate and the current supply of $NAM.

• PD-Controllers: These are used for both proof-of-stake and shielded pool rewards. The controllers first compute some intermediate values, then determine the rewards for proof-of-stake and each asset in the shielded pool.

The tokens minted as rewards are then distributed to their respective validity predicates, and the latest inflation and locked token ratio values are stored for the next epoch.

This is the first part of the series of articles on Namada. Thank you for reading so far.

To keep up to date with future articles, in which we’ll look at concepts such as “Public Good Funding” in depth, follow me on Medium or on X.