Internet protocols are the backbone of online communication, ensuring data is accurately sent and received across the web.

- IP v4 vs IP v6: These are versions of Internet Protocol (IP) addressing. IP v4 is the older, more familiar format (e.g., 182.0.2.345), while IP v6 addresses the need for more internet addresses with a longer format (e.g., 4527:0a00:1567:0200:ff00:0042:8329).

- TCP and UDP: Transmission Control Protocol (TCP) ensures data is sent and received correctly and in order, while User Datagram Protocol (UDP) is used for tasks like live streaming, where some data loss is acceptable.

- HTTP/S: The HyperText Transfer Protocol, with its secure version HTTPS, is what moves data around the internet. It involves requests and headers that dictate the nature of the data exchange.

HTTP Methods

They define the action to be performed on a given resource. Let's briefly look at four primary methods:

- GET: This method is used to retrieve information from a specified resource. When you visit a webpage, your browser is essentially making a GET request to fetch the page's content.

- POST: It's all about sending data to a server, commonly used when you submit a form on a website. The data sent via POST will be processed by the server, possibly leading to updates in the database.

- PUT: This method steps in for updating existing resources. If you're editing an existing post on a forum, for instance, the application might use a PUT request to apply your changes.

- DELETE: As straightforward as it sounds, DELETE is used to remove existing resources. If you're deleting an email or removing a post, your application is likely making a DELETE request to the server.

Absolutely! Here's a paragraph on HTTP status codes that you can integrate into your article:

STATUS CODE

Essential indicators in web communication, providing insight into the result of a request. They fall into five distinct categories:

- Informational (100-199): These codes indicate that the request initiated by the browser is being processed. For example, 100 Continue suggests that the initial part of a request has been received and the client should continue the request.

- Successful (200-299): This range signifies success. The most familiar among these is 200 OK, which confirms that a request has been successfully processed.

- Redirection (300-399): Codes in this category inform the client that additional actions are needed to complete the request. A common code is 301 Moved Permanently, indicating that the resource requested has been permanently moved to a new URL.

- Client Error (400-499): These codes denote errors made by the client. 404 Not Found is a well-known status code, indicating that the requested resource could not be found on the server.

- Server Error (500-599): This group represents errors on the server side. For instance, 500 Internal Server Error is a general code used when an unexpected condition was encountered and no specific message is suitable.

Unraveling APIs and Services

Application Programming Interfaces (APIs) are critical for enabling different software components to communicate effectively.

- Browser API: It extends the functionality of web browsers, allowing them to interact with elements like local storage and geolocation.

- REST API: This is a staple in web services, enabling efficient communication over HTTP, adhering to the principles of Representational State Transfer.

- Sensor-Based API: This tech taps into device sensors, like accelerometers, facilitating real-time responses to physical data inputs.

Web Development Triad: HTML, CSS, and JavaScript

The trinity of web development: HTML, CSS, and JavaScript, each plays a unique role.

- HTML: The framework of web pages, it references files and structures content.

- CSS: The stylist of the web, CSS dictates the layout, colors, and fonts, adding aesthetics to HTML structures.

- JavaScript: The interactivity enabler. JS brings dynamic updates and interactive features to web pages.

Web Hosting Solutions

Web hosting is pivotal in making websites accessible.

- Shared Hosting: Ideal for small websites; here, a server is shared among multiple users.

- Virtual Private Server: Offers a balance of cost and performance, with fewer sites per server.

- Dedicated Physical Server: As the name implies, it's dedicated solely to one user, offering maximum control and resources.

- Cloud Hosting: A scalable, high-end option that leverages both physical and virtual servers.

Webpages, Websites, and Web Apps

Finally, let's differentiate between webpages, websites, and web apps.

- Webpage: A single document, typically a combination of HTML, CSS, and JavaScript.

- Website: A collection of webpages under one domain name.

- Web App: More dynamic and interactive than traditional websites, often resembling desktop applications in functionality.

Let's dive into it 👇🏻

Blockchain's transparency is a strength, but when it comes to smart contracts, this feature raises a dilemma:

How can we keep sensitive smart contract details confidential?

Smart contracts on blockchains, as you probably know, are like open books - anyone can read them. This exposure risks leaking personal data, trade secrets, and strategic moves.

A real concern for businesses!

In blockchain, enhancing privacy often means sacrificing scalability. More private solutions can slow down the network, making it a tough balancing act for developers.

That's why technologies like Zero-Knowledge Proofs and Homomorphic Encryption joined the market - promising to keep smart contracts confidential without losing blockchain's essence.

Fhenix.IO Solution

Now we won't get lost on ZKPs, in fact I want to focus on so-called Fully Homorphic Encryption (FHE). The novelty brought by @FhenixIO in the first place.

FHE employes an optimistic rollup, a type of Layer 2 scaling solution for blockchains. Which means that it operates under the assumption that transactions are valid unless proven otherwise.

Avoiding significant computational penalties associated with verifiable FHE techniques. Which tends to overload the system compared to traditional plaintext computation.

Optimistic rollups are thus not just a solution but a necessity for FHE in blockchain environments​​.

What are the advantages over ZK-based rollups?

• Simplicity and Compatibility

• Lower Computational Overhead

• Developer Friendly

• Cost Efficient

Fhenix framework integrates Ethereum, enhancing his ecosystem significantly while maintaining the integrity of its base layer. How?

• Cryptoeconomic Solution → it addresses the challenge of arbitrating non-EVM native fraud proofs.

Without necessitating any modifications to Ethereum's base layer, preserving EVM's structure and functionality.

• Optimistic FHE Rollups → as I have already explained, this type of rollup is used to ensure greater efficiency and scalability for smart contracts.

• Scalability and Security → thanks to the optimistic rollup approach they can scale without congesting the Ethereum Layer 1.

They achieve this by executing transactions outside the primary chain and posting back state updates along with proofs of correct execution.

• Efficiency in Handling Confidential Data → the strongest point of Fhenix, that thanks to the L2 Rollup structure improves the efficiency of executing transactions and managing confidential data on-chain.

What makes Fhenix.io's approach unique?

Traditional methods require FHE to be replicated across all nodes in a blockchain network. So how does Fhenix do?👇🏻

Fhenix.io's structure avoids this, reducing the computational cost and making the solution more efficient and practical.

While the approach is specifically tailored for the EVM, it holds independent value as a system that enables verifiable FHE.

This focus ensures that the solution is not only efficient but also highly relevant and adaptable to the most widely used blockchain ecosystem.

The architecture of the FHE rollup system, including its various components and layers, is designed to enhance efficiency through his innovative approach, that also contributes to the development of a new wave of privacy-centric dapps.

This is made possible by enhancing user confidence, expanding potential use cases, and increasing the overall security and utility in the EVM ecosystem.

The Architecture

💻 𝐟𝐡𝐞𝐎𝐒

It acts as the core engine of the Fhenix nodes, empowering smart contracts with robust encryption capabilities. When these contracts require encrypted computations, they seamlessly integrate with the fheOS precompiles, which are tailored for Fully Homomorphic Encryption (FHE) operations.

fheOS's design ensures full compatibility with the Ethereum Virtual Machine (EVM), bridging the gap between advanced encryption technologies and existing Ethereum-based applications.

The fheOS library, therefore, stands as a testament to Fhenix.io's commitment to enhancing blockchain privacy and security, offering a comprehensive suite of encrypted operations (like arithmetic operations i.e. addition, multiplication and number comparisons) essential for the next generation of smart contracts.

👨‍💻 𝐠𝐨-𝐭𝐟𝐡𝐞

It serves as a bridge between the Rust-based core FHE mathematical operations library (tfhe-rs) and blockchain applications, especially those written in Go.

This integration is achieved through a Go-based API, designed specifically for executing complex FHE mathematical operations. Additionally, a specialized Rust wrapper adapts the TFHE.rs library for seamless use in blockchain contexts.

This strategic amalgamation significantly enhances Ethereum's go-ethereum (geth) capabilities, paving the way for more advanced and secure smart contract applications.

🌐 𝐓𝐍𝐒 (Threshold Services Network)

TSN operates as a distinct network layer, separate from the L1 blockchain or other rollup components. A vital separation for its functionality and security. It gives smart contracts running on the network the ability to utilize FHE primitives.

This means dapps using Fhenix can integrate encrypted data directly into their smart contract logic. It manages a secret-shared network key. This network key is essential for threshold decryption processes.

Central to TSN's operation is the management of a secret-shared network key. Unlike traditional systems where a single entity might hold a key, this network key is collectively entrusted to the TSN, a design choice that bolsters security.

Fhenix.io innovatively employs Shamir's secret-sharing method in this context. This method involves dividing the key into multiple parts, or 'shares.' To reconstruct the key, a predetermined number of these shares (n + 1) are required, ensuring that no single entity can unilaterally access the key.

Crucially, TSN oversees the threshold decryption and re-encryption processes. This ability is pivotal in safeguarding the confidentiality of data, while still allowing it to be effectively processed and utilized within smart contracts. Such a mechanism ensures that while data remains private and secure, its utility in smart contracts is not hindered

🦹 𝐅𝐫𝐚𝐮𝐝 𝐏𝐫𝐨𝐨𝐟𝐬 𝐦𝐞𝐜𝐡𝐚𝐧𝐢𝐬𝐦

At the heart of optimistic rollups is the fraud proofs mechanism, ensuring transaction integrity on blockchain networks.

This mechanism becomes particularly vital when dealing with encrypted data in smart contracts, such as those facilitated by Fhenix.io. Fhenix.io empowers users to independently re-run and verify transactions off-chain, ensuring their accuracy. If discrepancies are detected, what's the next step?

Users can submit a fraud-proof directly on-chain, where Ethereum serves as the ultimate arbiter, ensuring fairness and rectitude. This vigilant process is crucial for upholding the pillars of trust and security in the blockchain ecosystem.

Fraud proofs are essential for accurate state updates. The system's design ensures chain integrity, even amid malicious attempts to alter transactions.

Fhenix utilizes Arbitrum’s Nitro fraud prover, cleverly adapting FHE logic to WebAssembly. System that, surprisingly, hasn't seen any fraud proof submissions since its mainnet launch in August 2021 according to Cointelegraph (at least until Sept 11th).

This innovative move allows Fhenix.io to seamlessly integrate its cryptographic smart contracts into the Ethereum ecosystem.

Who's behind Fhenix.IO?

Guy Zyskind, the founder and a pivotal figure in the blockchain industry. Zyskind combines deep technical expertise with a visionary approach to blockchain technology. His entrepreneurial spirit is further exemplified through his role as the founder of SCRT Labs, a company dedicated to advancing decentralized technologies. Known for Secret Network, a protocol that offers scalable permissionless smart contracts. Some of the projects built on it are: Tarantino NFTs, Secret Bridge, Sienna Network and Shade Protocol.

Joining him in this venture is Guy Itzhaki, has a strong blend of technical acumen and leadership. Itzhaki's experience in software development (worked at Intel Corp. for +7 years) and management positions him as a key asset in driving Fhenix's innovative solutions.

Final Thoughts

The recent acquisition of $7 million in funding by Fhenix is a resounding affirmation of the burgeoning interest and investment in the realm of blockchain privacy solutions. This influx of capital not only underscores the faith investors place in Fhenix's innovative technology but also reflects a broader industry recognition of the critical need for enhanced privacy in blockchain applications.

In a world where privacy concerns are increasingly paramount, particularly in various industries and for individuals alike, Fhenix stands at the forefront of addressing these challenges. Their approach uniquely balances the imperatives of security and data protection with the fundamental principles of transparency and decentralization that are hallmarks of blockchain technology. This alignment ensures that blockchain's core values are not just preserved but also strengthened in the face of evolving digital landscapes.

Central to Fhenix's ethos is their dedication to democratizing access to their pioneering technology for developers. By demystifying and simplifying the intricacies of advanced cryptographic techniques, Fhenix empowers developers to harness the full potential of their platform.

This focus on accessibility and user-friendliness, as articulated by founder Guy Zyskind, ensures that developers can channel their efforts towards innovation and creativity, unencumbered by the daunting complexities of underlying cryptographic mechanisms.

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.