We’re excited to share that Paladin, a programmable privacy framework, has been promoted from a lab to a full project in Linux Foundation Decentralized Trust. This is recognition of the rapid maturity of Paladin and a reflection of growing adoption by real world institutional implementations across the global financial industry.
These industry implementations have proven the need for a full-stack approach to privacy - combining modular cryptography and programmability across both the cash and asset legs in a single, unified framework.
A core tenet of Paladin has been to harness the power of a shared ledger on EVM, rather than feeling constrained by it. One key lesson the community has learned since launch is just how important it is to unleash token level interoperability. Paladin supports using transparent tokens (ERC-20 etc.), mixing those with advanced cryptography based tokens like Zero Knowledge Proofs (ZKPs), and using the EVM for atomic settlement of end-to-end business transactions in a way that is impossible without the shared ledger layer.
Full stack programmable privacy
Paladin’s full stack approach makes it unique in the enterprise privacy technology landscape. This approach puts the focus on providing common components and interoperability between privacy technologies, rather than focusing on any one individual implementation.
You can think of Paladin first and foremost like a “Wallet” or “Vault” for privacy technologies. Given that all privacy preserving smart contracts need App-layer functions outside of the blockchain node to function, why not provide a hardened open runtime extensible to all of them? The alternative is siloed solution stacks for each privacy preserving token, which is problematic for enterprise adoption of Web3 at scale.
Tokens and Programmability
There are two primary types of privacy preserving smart contract accounted for in the design:
- Tokens - Value that can be proved as owned across the whole chain, regardless of the transaction within which it originated.
- Privacy groups - Private EVM smart contracts executed between a set of parties, where the outcome is irrefutable via proof on the chain, but the data is private.
Most privacy solutions provide one of these approaches. However, real world implementations usually require atomic composability of transactions across both.
Tokens need to be issued by separate parties, in a model that fits their technical, decentralization, and regulatory requirements and that can be chosen independently. Then transactions need to be programmable separately, using privacy preserving EVM workflows - patterns like DvP and PvP - to support a wide range of market making and dynamic composition.
Anatomy of a Privacy Token on EVM
To understand the modular approach of Paladin, it is worth spending some time thinking about the common pattern that sits behind any privacy preserving smart token in EVM (with or without Paladin).
- The transaction must be proposed by a party with the authority to do so - the token holder. Depending on the technical implementation, this might mean authorizing a debit to an on-chain account or selecting coins (UTXO models are very common in privacy preserving tokens).
- Because the token is private, the on-chain account will not have access to the data. So the app-layer must do some extra work to generate a proof of the transaction that can be verified on-chain:
a) Gathering signatures from endorsing/validating parties, such as the token issuer.
b) Building a Zero-Knowledge Proof (ZKP) in the context of the full transaction data.
c) Encrypting operations with partial data access using Fully Homomorphic Encryption (FHE). - This is where the fully programmable power of the EVM shared ledger comes into play. The on-chain smart contract can be programmed to validate the transaction built in step 2 without access to the data itself. Depending on the system this step might maintain:
a) Anonymity: Hiding which addresses are transacting (vs. pseudo-anonymity in ERC-20).
b) Confidentiality: Hiding the values/data being transacted (vs. full transparency in ERC-20).
c) History masking: Further obfuscation of the linkage between token creation and spending. - In any model when the EVM on-chain smart contract is in control, the transaction cannot be considered final until the blockchain transaction is final. This might sound obvious, but many historical approaches to privacy have been loose on this point. Paladin provides flexibility in almost every other area, but this “on-chain source of truth” approach is mandatory.
As long as a token implementation fits into this 4-step model, it can be onboarded into the Paladin runtime and ecosystem. Paladin provides a modular approach to onboard each of these components in the App-layer and couple them to the on-chain smart contract. It can support Java, Go, and WebAssembly (including compiled Rust) today via an efficient gRPC interface.
Built-in token implementations
While extensibility to any token implementation is a primary design principle of Paladin, a lot of effort from the community has gone into providing hardened out-of-the-box implementations.
They give issuers of assets the confidence of institutional grade privacy.
These token implementations are also modular and extensible, so they can be upgraded and extended with additional functionality and features.
Noto: Notarized tokens
These tokens are private to all transacting parties and can be trusted by any party who receives those tokens in the future because every transaction is pre-validated and co-signed by a trusted party or set of parties.
They allow either off-chain issuer validation or use of EVM smart contracts (see below) to code the issuer functions deterministically. This includes the ability to decentralize the notarization role across multiple trusted parties.
Zeto: Zero-knowledge Proof (ZKP) tokens
With Zeto, every token transaction is validated on-chain via a proof generated by the submitting party, with access to the full transaction data.
This provides not one, but a suite of pre-built token implementations built with the popular and hardened CIRCOM toolkit that implement different patterns including:
- Efficient anonymous and confidential tokens
- History masking via nullifiers
- Allow-lists and deny-lists for trading parties
- Off-chain data storage, with only commitments held on-chain
- Post-quantum safe use of on-chain encrypted data storage
- Contributed by researchers from UC Berkeley and UNC Chapel Hill
EVM Privacy Groups - continuing the story of Tessera
If the only thing that existed were tokens, then Web3 would not have resulted in the vibrant ecosystems and innovation that we see today in the transparent/public DeFi world.Instead you have the ability to program and trade across those tokens, create DvP and PvP transactions, form dynamic markets, and provide liquidity and settlement to the assets.
Those transactions and workflows need to be programmed, and EVM is an excellent programming model for those workflows - even with privacy.
However, the EVM world state that you program in cannot be the underlying shared ledger that everybody validates. Otherwise everyone would have access to the data and you would leak anonymity and confidentiality of those workflows.
Instead, we need lots of different EVM world states, with different sets of parties that can see the data protected inside that world. These are commonly referred to as “Privacy Groups” where “Private Smart Contracts” run.
You can think of these as “micro-chains.”
They have their own genesis, and any transactions that happen in them are independent and isolated from transactions in other EVM worlds. This private separation applies to all account states - smart contracts, and eternally owned accounts (EOAs).
Pente brings a new level of flexibility and scale to privacy groups
Paladin comes with a built-in implementation of EVM privacy groups called Pente. This represents the very latest generation of EVM privacy group technology, a significant evolution beyond what was previously available in Tessera.
Pente uses the EVM implementation from LF Decentralized Trust sister project Besu to execute the privacy groups. The Paladin runtime dynamically loads that EVM in a novel way, referred to as ephemeral EVMs. Instead of having long-lived runtimes to run these EVMs, Paladin loads in the EVM on-demand on a per-transaction basis and throws it away when it’s not used.
The world state of any micro-chain is brought into being on-demand, whenever it is needed:
To propose a transaction on the node owned by the transaction submitter.To pre-execute a transaction for endorsement before it is submitted.
To generate a receipt when the blockchain confirms the transaction.
This process requires an advanced coordination and sequencer engine, and that “brain” is at the core of the Paladin runtime. The same flexible engine coordinates all of the privacy token domains as well as the EVM privacy groups of Pente.
The engine of Paladin is already reaching a second generation adding even more resilience and scale. This includes supporting features desired for many years in EVM privacy groups - such as M of N endorsement scenarios.
Full Programmable Privacy
It is only when you bring all of these elements together that you get full programmable privacy:
- A shared EVM ledger that coordinates atomicity across privacy domains, without access to private data
- Privacy tokens, each implemented with its own privacy and trust models, meeting the needs of the token issuer and ecosystem
- Sub-transaction privacy spanning multiple dynamic privacy groups executing EVM workflow, with deterministic execution of logic between counterparties fulfilling separate roles in the transaction
Real world use cases
The benefits of this level of composability have been proven in many use cases.
Paladin has already been deployed in a number of projects including central banks, commercial banks and other financial institutions. These projects have proven programmability across tokenized cash (central bank and commercial bank money), and tokenized assets (bonds and other financial assets), for payments, PvP and DvP use cases.
These use cases simply aren’t possible without the ability to decompose an end-to-end business transaction into multiple data privacy scopes. Allowing each “leg” of the transaction to set up, exchange private data, perform validated workflow and then execute atomically.
The power of the EVM shared ledger means after settlement parties receive ownership of tokens that can be proven to anyone on the shared ledger - not just those involved in the transaction.
Get Involved
If you’re interested in getting involved with Paladin, join the Paladin channel on the LF Decentralized Trust Discord. The project maintainers will be organizing regular community calls on the first Tuesday of every month starting on December 2. If you’re interested in attending, sign up and add the calls to your calendar.