# NAMADA

What’s the `problem`, and how does the `solution` look like?

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 (ZKPs), 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:
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.


## What's the `problem`, and what about the `solution`?

### The problem

As mentioned earlier, Namada is mainly trying to solve the **privacy** issue. It’s well-known that *data breaches* and *privacy violations* are the daily routine.

Particularly in the *blockchain* and *crypto industry*, where most transactions are transparent and traceable on public ledgers.


## The solution

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.

### 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**
- **Description**: Anoma is not just a blockchain; it's an architecture or framework for blockchains. Any chain can implement the Anoma architecture, creating what's known as a "fractal instance" of Anoma. Namada is one such fractal instance, currently in development, designed to operate as an interchain asset-agnostic proof-of-stake blockchain protocol within the Anoma framework.
- **Link**: [Anoma](https://anoma.net/)
2. **MASP (Multi Asset Shielded Pool)**
- **Description**: MASP is 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](https://github.com/anoma/masp)
3. **Vamp-IR**
- **Description**: Vamp-IR is 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](https://github.com/anoma/vamp-ir)
4. **Taiga**
- **Description**: Taiga is 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](https://github.com/anoma/taiga)
5. **Ferveo**
- **Description**: Ferveo is a synchronous Distributed Key Generation protocol designed for front-running protection on public blockchains.
- **Link**: [Ferveo on GitHub](https://github.com/anoma/ferveo)
6. **PLONK**
- **Description**: A pure Rust implementation of the PLONK proving system over BLS12-381. This library contains a modularized implementation of KZG10 as the default polynomial commitment scheme.
- **Link**: [PLONK on GitHub](https://github.com/heliaxdev/plonk)
7. **Juvix**
- **Description**: Juvix is 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](https://docs.juvix.org/latest/)
8. **Typhon**
- **Description**: Typhon is 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](https://isaacsheff.com/project/typhon)
9. **Namada**
- **Description**: I'll reserve the discussion about Namada for later in this article. Otherwise, what am I writing for?
- **Link**: [Namada](https://namada.net/)

---

### **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.
- **Alberto Centelles**:
- Mathematician specializing in **cryptography**, **distributed systems**, and **programming language theory**.
- Advocates for widespread use of **zero-knowledge proofs** outside academia.
- **Aleksandr Karbyshev**:
- Trained mathematician with a focus on **software verification**.
- Envisions **formal methods** as the future standard in cryptography and DLTs.
- Aims to enhance protocol security at **Heliax** using advanced verification techniques.
- **Artem Gureev**:
- Mathematician with expertise in **dependent type theories** and **homotopy theory**.
- Passionate about **interactive theorem proving** and **category theory**.
- **Bengt Lofgren**:
- Software engineer with a background in **machine learning** and **economics**.
- Enthusiast of **zero-knowledge applications** and **public goods**.

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 six 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](https://heliax.dev/team).

---

## **ANOMA**—**The Architectural Marvel**

Anoma constitutes a revolutionary approach in the blockchain landscape. It is not just another blockchain platform; as mentioned earlier in 'The Projects' section, it is 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](https://twitter.com/anoma/status/1702054640853172642) and [@Apriori](https://twitter.com/apriori0x/status/1702055292631236804)). In essence, it does not merely execute commands, but understands the underlying purpose of these commands, thus making application development more intuitive and user-centered.

Why is this revolutionary approach significant? In traditional systems, there can be a gap in understanding the myriad shades of user intentions, which can lead to less effective or even erroneous results. Anoma's emphasis on intentions ensures that applications built on this framework are not only more efficient, but also inherently more secure.

But Anoma goes beyond simple transaction execution. It provides a complete solution for decentralised applications, encompassing tasks such as finding the right counterparties, ensuring that terms are met and settling transactions seamlessly.

This is made possible by the introduction of innovative features such as **enhanced privacy** and **cross-chain settlements**, which open the way for applications once considered unobtainable.

These foundations help us understand how Namada, built on the Anoma architecture, is poised to redefine the privacy-centric blockchain landscape. Namada, as a fractal instance of Anoma, benefits from Anoma's focus on user-defined intent and its holistic approach to application development and settlement processes.

This integration not only improves privacy, but also simplifies interactions between multiple blockchains and lays the foundation for a new era and narrative in the blockchain industry.

By integrating the concept of intent and considering the role of Anoma's architectural framework, Namada is set to offer a unique, user-centric blockchain experience, morphing the way we perceive and interact with decentralised systems.

**[Jon Charbonneau](https://www.notion.so/research-328fa9c082264b5c82f4763c406fd8a3?pvs=21)** wrote a thoroughly insightful article on architecture and the concepts of Anoma, which you can read [here](https://dba.mirror.xyz/NTg5FSq1o_YiL_KJrKBOsOkyeiNUPobvZUrLBGceagg).

---

## **NAMADA**—**A Deep 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 proof-of-stake 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 cloaked in obscurity, 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.
- **Advanced 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](https://namada.net/blog/pgf-on-namada-public-goods-capital-efficiency-cool-graphs-pick-three)”.
- **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](https://www.techtarget.com/searchsecurity/definition/elliptical-curve-cryptography) 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^2 + y^2 = 1 − d ·x^2·y^2$

But how does this 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 M*echanism**
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](https://ibcprotocol.org/faq/), 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: $9 \times \left( \sum_{i \in \text{infractions}} \frac{vp_i}{vp_{\text{total}}} \right)^2$

Let's break it down:

- $\sum_{i \in \text{infractions}} \frac{vp_i}{vp_{\text{total}}}$: This part of the formula 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, $^2$: 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.
- 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 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](https://specs.namada.net/economics/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](https://specs.namada.net/economics/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.

---

## **Public Goods Funding**

Public goods are items that are non-excludable and non-rivalrous, providing benefits to their users. They range from languages, open-source software, research, and designs to Earth's atmosphere and art. Namada's software stack, research, ecosystem tooling, and many other foundational elements are public goods. Their sustenance is vital for Namada's existence and continued operation. Traditional economic systems often misrepresent public goods due to their non-excludable and non-rivalrous nature, leading to underfunding or funding through artificial scarcity. Namada aims to contribute to the funding of these public goods without introducing artificial scarcity.

### Previous Design

Public goods funding is a well-researched area. Most funding mechanisms can be categorized as:

- **Need-based**: Allocates funds based on the cost of resources.
- **Results-based**: Allocates funds based on expected or assessed benefits, often retroactively.

There are various constraints to consider, such as governance time costs, the need for predictable funding, potential for public debate issues, and implementation engineering costs.

### **Funding Focuses**

Namada's funding interests cover a broad spectrum, allowing flexibility:

1. **Technical Research**: Funding for topics related to Namada, including cryptography, distributed systems, programming language theory, and more. Funding forms might include PhD sponsorships, grants, institutional funding, prizes, etc.
2. **Engineering**: Funding for Namada-related engineering projects, such as libraries, tooling, integrations, etc. This could involve developer grants, bug bounties, performance optimization prizes, etc.
3. **Social Research, Art, and Philosophy**: Funding for exploring the relationship between humans and technology. This includes artistic expression, philosophical investigation, and social research.
4. **Education**: Funding for open and freely accessible knowledge in various formats, from books to podcasts.
5. **Meta Public Goods**: Funding for goods that enhance the production or existence of other public goods, like forums, libraries, quadratic funding protocols, etc.
6. **External Public Goods**: Funding for goods outside the Namada ecosystem, such as carbon sequestration, journalism, legal advocacy, etc.

### **The Public Goods Stewards**

Public goods funding in Namada is managed by "public goods stewards". Each steward is elected by governance and is responsible for a specific area of public goods. While they can propose funding for various public goods, governance retains veto power over any proposal.

**What is a Steward?**

Technically, all valid PGF stewards are established multisignature account addresses. These can represent one or more individuals.

**Becoming a Steward**

To become a Steward:

1. Create a multisignature account.
2. Propose candidacy through a custom governance proposal, accompanied by a motivational statement and a commitment to a category of public goods funding.
3. Get elected by a governance proposal for a term of `StewardTerm` epochs. Re-election is required after the term ends.
4.

**Electing the Stewards**

After a `StewardProposal` is submitted, the steward address undergoes a voting process by governance participants. In the event of a tie, the proposal is rejected. Once elected, the steward's address is added to the PGF internal address.

**Example**

This example provided illustrates the mechanism:

- The governance set consists of Alice, Bob, Charlie, Dave, and Elsa.
- Current PGF stewards are Dave and Elsa.
- Bob and Charlie propose their joint candidacy as a PGF Steward.
- Voting ensues, with Alice, Bob, and Elsa voting "Yay" and Dave voting "Nay".
- With 80% participation and 75% "Yay" votes, Bob and Charlie are added to the Steward set.
- By epoch 57, Bob and Charlie can propose Public Goods Funding transactions.

---

### **Public Goods Funding - Partnership with Osmosis**

In the spirit of fostering collaboration and strengthening the interchain ecosystem, Namada has taken a significant step forward. Osmosis played a pivotal role in the "go-to-market" strategy for IBC. When IBC was launched in early 2021, it was seen as a technical novelty without a clear use-case. The interchain required an application that would treat IBC as a primary feature, integrating it seamlessly into the product, thereby showcasing the potential of the Cosmos model. Osmosis filled this gap, and without their contributions, the interchain ecosystem wouldn't have reached its current stature.

Namada, recognizing the importance of such collaborations, is proud to contribute to this growing ecosystem. In a gesture of gratitude, both spiritually and materially, to the Osmosis community, Namada is laying the foundation for future collaborations. A proposal and request-for-comment (RFC) has been presented for a partnership between Namada and Osmosis, encompassing their assets, chains, and communities.

The proposed partnership is structured in three parts:

1. An airdrop of $NAM tokens to $OSMO holders, stakers, and LPers who have been supportive of the chain.
2. An allocation of continuous public goods funding to a grants pool, managed by the Osmosis Grants Program. This pool aims to fund projects that would benefit both the Osmosis and Namada ecosystems.
3. The introduction of shielded actions, a feature designed to allow $OSMO holders and Osmosis users to effortlessly benefit from the privacy features offered by Namada and the trading capabilities provided by Osmosis.

For a deeper dive into the specifics of this partnership, you can explore the details in the [Osmosis Governance forums post](https://namada.net/blog/proposal-for-a-partnership-between-namada-and-osmosis).

---

### **Credits & Acknowledgements:**

**Research Papers & Articles:**

- [Introduction to CometBFT](https://docs.cometbft.com/v0.38/introduction/)
- [Arxiv Research Paper](https://arxiv.org/abs/1807.04938)
- [Jon Charbonneau Article](https://dba.mirror.xyz/NTg5FSq1o_YiL_KJrKBOsOkyeiNUPobvZUrLBGceagg)
- [Intents Aren't Real - Anoma Blog](https://anoma.net/blog/intents-arent-real)
- [F1 Fee Distribution's Research Paper](https://drops.dagstuhl.de/opus/volltexte/2020/11974/pdf/OASIcs-Tokenomics-2019-10.pdf)
- [What is IBC?](https://ibcprotocol.org/faq/)
- [RFC: Proposal for a public goods partnership between Namada and Osmosis](https://namada.net/blog/proposal-for-a-partnership-between-namada-and-osmosis)
- [PGF on Namada: public goods, capital efficiency, cool graphs - pick three](https://namada.net/blog/pgf-on-namada-public-goods-capital-efficiency-cool-graphs-pick-three)

**Namada Resources:**

- [Namada Specifications](https://specs.namada.net/)
- [Namada Documentation](https://docs.namada.net/)
- [Namada Official Website](https://namada.net/)
- [Introducing Namada: Interchain Asset-Agnostic Privacy](https://namada.net/blog/introducing-namada-interchain-asset-agnostic-privacy)
- [Understanding the MASP and CC Circuits](https://namada.net/blog/understanding-the-masp-and-cc-circuits)

**Privacy & Zero-Knowledge Proofs:**

- [How Zerocash Works](http://zerocash-project.org/how_zerocash_works)
- [Non-Interactive Zero-Knowledge Proof - Wikipedia](https://en.wikipedia.org/wiki/Non-interactive_zero-knowledge_proof)
- [Using ZEC Privately](https://wiki.zechub.xyz/using-zec-privately)
- [Shielded Address Contexts - Electric Coin Co.](https://electriccoin.co/blog/shielded-address-contexts/)

**Other Relevant Links:**

- [Heliax](https://heliax.dev/)
- [Anoma](https://anoma.net/)
- [Hashing to Elliptic Curves](https://datatracker.ietf.org/doc/rfc9380/)

*Some resources were discovered with the help of ChatGPT from OpenAi and Claude from Anthropic.*

---