Yesterday we offered an overview of the Extended UTXO model employed by Cardano, explaining how it differs from the approaches taken by Bitcoin and Ethereum. Now let’s dive a little deeper into inputs and outputs, the component parts of a transaction.

We need to talk about transactions: Outputs and Inputs

The term transaction usually evokes financial echoes. While such meaning would apply to Bitcoin (since the Bitcoin blockchain is used to move funds between peers), many other blockchains (including Cardano) are far more versatile. In these cases, the term ‘transaction’ is much more nuanced. One can think of transactions as transfers of value.

In a blockchain environment, each transaction can have one or multiple inputs, and one or multiple outputs. The concepts of Inputs and Outputs must be understood, if one wants to understand how a transaction works, and how it relates to UTXO. In abstract terms, think of a transaction as the action that unlocks previous outputs, and creates new ones.

Transaction output

A transaction output includes an address (that you can think of as a lock) and a value. In keeping with this analogy, the signature that belongs to the address is the key to unlock the output. Once unlocked, an output can be used as input. New transactions spend outputs of previous transactions, and produce new outputs that can be consumed by future transactions. Each UTXO can only be consumed once, and as a whole. Each output can be spent by exactly one input, and one input only.

Transaction input

A transaction input is the output of a previous transaction. Transaction inputs include a pointer and a cryptographic signature that acts as the unlocking key. The pointer points back to a previous transaction output, and the key unlocks this output. When an output is unlocked by an input, the blockchain marks the unlocked output as “spent”. New outputs created by a given transaction can then be pointed to by new inputs, and so the chain continues. These new outputs (which have not yet been unlocked, i.e., spent) are the UTXOs. Unspent outputs are simply that, outputs that have not yet been spent.

How UTXO works, in a nutshell

In a UTXO accounting model, transactions consume unspent outputs from previous transactions, and produce new outputs that can be used as inputs for future transactions.

The users' wallets manage these UTXOs and initiate transactions involving the UTXOs owned by the user. Every blockchain node maintains a record of the subset of all UTXOs at all times. This is called the UTXO set. In technical terms, this is the chainstate, which is stored in the data directory of every node. When a new block is added to the chain, the chainstate is updated accordingly. This new block contains the list of latest transactions (including of course a record of spent UTXOs, and new ones created since the chainstate was last updated). Every node maintains an exact copy of the chainstate.

EUTXO: The rationale behind Cardano's choice

Bitcoin’s ‘vanilla’ UTXO accounting model would not suit Cardano, as Cardano is designed to do more than handle payments. Particularly, the need for more programming expressiveness for the upcoming smart contracts functionality in the Alonzo era required a novel (‘Extended’) solution.

The 'basic' UTXO model has a limited expressiveness of programmability. Ethereum's Account/Balance accounting model addressed this specific problem with the development of an account-based ledger and associated contract accounts. But by doing so, the semantics of the contract code became far more complex, which had the unwanted effect of forcing contract authors to fully grasp the nuances of the semantics to avoid the introduction of potentially very costly vulnerabilities in the code.

An ‘extended’ UTXO solution would require two pieces of additional functionality that the existing UTXO model could not provide:

1 - To be able to maintain the contract state

2 - To be able to enforce that the same contract code is used along the entire sequence of transactions. We call this continuity.

A powerful feature of the EUTXO model is that the fees required for a valid transaction can be predicted precisely prior to posting it. This is a unique feature not found in account-based models.

How does the EUTXO model extend UTXO?

By adding custom data to outputs (in addition to value), and by allowing for more "locks" and "keys" deciding under which condition an output can be unlocked for consumption by a transaction. In other words, instead of just having public keys (hashes) for locks and corresponding signatures serving as "keys", EUTXO enables arbitrary logic in the form of scripts. This arbitrary logic inspects the transaction and the data to decide whether the transaction is allowed to use an input or not.

Conclusion: What makes the EUTXO model innovative and relevant

Cardano's ledger model extends the UTXO model to support multi-assets and smart contracts without compromising the core advantages of a UTXO model. Our innovative research enables functionality beyond what is supported in any other UTXO ledger, making Cardano a unique competitor in the next-generation blockchain space.

Blockchain networks are complex data structures. Transactions continuously crisscross the chain, creating digital footprints that require careful tracking and management to maintain the integrity and reliability of the underlying ledger.

Two major accounting ledgers exist in the blockchain space: UTXO-based blockchains (Bitcoin, for instance), and Account/Balance chains (Ethereum, and others).

Each of these crypto heavyweights differs in many fundamental ways, but this article focuses on their accounting models. Bitcoin uses an Unspent Transaction Output (UTXO) model, whereas Ethereum deploys an Account/Balance one.

Cardano sought to combine Bitcoin’s UTXO model with Ethereum’s ability to handle smart contracts into an Extended UTXO (EUTXO) accounting model. The adoption of EUTXO facilitates the implementation of smart contracts into the Cardano chain.

What is a blockchain accounting model?

Every company, firm, or commercial entity requires a balance sheet to keep an accurate record of profit, loss, cash flow, and other parameters. By maintaining careful accounting of all this data, companies can, at a glance, visualize their financial status at any given point in time. A company's accounting ledger offers another advantage: The ability to trace the provenance and ownership of funds.

Blockchain networks also require an accounting model to determine who owns what coins (and how many of them), track where those coins go, which ones are used up, and which ones remain available to be spent.

UTXO model v Account/Balance model: A brief overview

Decades ago, accountants used physical ledger books with handwritten entries to keep records about the movement of funds. Nowadays, companies use electronic versions of the same thing. Blockchains use transactions as records (much like entries on a ledger book) to track provenance and ownership. These transactions contain a lot of information (where the coins come from, where they're going, and whatever change is leftover from these transactions).

Here’s a brief overview of the UTXO and Account/Balance models:

UTXO

In a UTXO model, the movement of assets is recorded in the form of a directed acyclic graph where the nodes are transactions and the edges are transaction outputs, where each additional transaction consumes some of the UTXOs and adds new ones. The users' wallets keep track of a list of unspent outputs associated with all addresses owned by the user, and calculate the users’ balance.

UTXO is, in many ways, similar to cash. A good analogy is this: Imagine you have $50 in your wallet. This amount could be made up with several combinations: two $20 bills and one $10, four $10 bills and two $5 bills, and many others. But regardless of the permutations, the amount ($50) remains equal. UTXOs work in the same way. Whatever balance you have in your blockchain wallet (say, 150 coins) could be made up with many different UTXO combinations, based on previous transactions, but the balance amount remains the same. In other words, the balance held in a given wallet address is the sum of all unspent UTXOs from previous transactions.

The concept of 'change' in UTXO models

Much like cash transactions in any store, UTXOs introduce ‘change.’ When you take out say a $50 bill from your wallet, you cannot tear that bill into smaller pieces to pay for something that costs $15, for example. You have to hand over the entire $50 bill and receive your change from the cashier. UTXOs work in the same way. You cannot ‘split’ a UTXO into smaller bits. UTXOs are used whole, and change given back to your wallet’s address in the form of a smaller UTXO.

The advantages of UTXO models

By checking and tracking the size, age, and amount of UTXOs being transferred around, one can extract accurate metrics about the blockchain’s usage and financial activity of the chain.

UTXO models offer other advantages. Better scalability and privacy, for example. Also, the transaction logic is simplified, as each UTXO can only be consumed once and as a whole, which makes transaction verification much simpler.

To sum UTXO up:

• A UTXO is the output of a previous transaction, which can be spent in the future
• UTXO chains have no accounts. Instead, coins are stored as a list of UTXOs, and transactions are created by consuming existing UTXOs and producing new ones in their place
• Balance is the sum of UTXOs controlled by a given address
• UTXOs resemble cash in that they use ‘change’, and are indivisible (UTXOs are used whole)

The Account/Balance model

As the name indicates, blockchain models that deploy an Account/Balance accounting model use an account (which can be controlled by a private key or a smart contract) to hold a coin balance. In this model, assets are represented as balances within users’ accounts, and the balances are stored as a global state of accounts, kept by each node, and updated with every transaction.

In many respects, Account/Balance chains (such as Ethereum) operate in a similar fashion to traditional bank accounts. The wallet's balance increases when coins are deposited, and decreases when coins are transferred elsewhere. The crucial difference here is that, unlike UTXOs, you can use your balance partially. So for example, if you have 100 ETH in your account, you can send a portion of that (say, 30 ETH) to someone else. The resulting balance will be 70 ETH remaining in your account, and the address where you sent the coins to will increase by 30 ETH. The concept of change does not apply in Account/Balance accounting models as it does in UTXO ones.

To sum up the Account/Balance model:

• This accounting model resembles how a bank operates
• Users have accounts that hold their coin balance
• It is possible to spent partial balances
• The concept of change does not apply

Tomorrow, in the second part of this analysis, we'll discuss how each model deals with transactions, explain the rationale for developing the EUTXO model for Cardano, and provide an in-depth explanation of what EUTXO is and how it works.

At the end of March, we’ll reach another milestone for Cardano when we’ll see d, the parameter that governs what percentage of transactions are processed by the genesis nodes, get to zero. At this point, responsibility for block generation will be fully decentralized. In other words, Cardano’s network of 1,800+ community pools will be solely responsible for producing blocks.

D=0 day will be a landmark moment in Cardano's continuing journey. When we deployed the Shelley update back in July 2020, d was set to an initial 1.0, meaning that every block was produced by IOHK’s network of federated nodes. Of course, this was the antithesis of decentralization but a wise (ie, secure) approach for the near term while the stake pool operator (SPO) network got up and running.

Preparing for d=0 day

Over time, we have gradually reduced d at a rate of 0.02 per epoch (in other words, an increase of two percentage points in community block production every five days). On the day this blog is published, we are at d=0.12 with 88% of blocks being produced by community pools and just 12% by federated nodes.

Simply put, as d decreases, more blocks are created by the community, and more stake pools can produce blocks. As d ticks down, the network's diversity and geographic distribution expands.

On March 31, at the boundary of epoch 257, d will reach zero. That day will be special because while d may be small, its significance is huge. In this context, that zero heralds the most important outward indicator of decentralization, a parameterized symbol supporting a core tenet of our philosophy – d=0 pushes power to the edges.

As we continue transitioning to full decentralization, it is also a good time to reference the other parameters governing the Cardano network’s evolution, and review some of the changes we have seen.

The d number is just one of more than 20 parameters that govern network operation and health. This set of parameters are ‘levers’ to manage and steer the effective and natural operation of a decentralized proof-of-stake system. The community will ultimately drive Cardano's evolution via Voltaire governance rules, but until then, it's our job to manage this set of parameters. Our guardianship requires that we make adjustments as required to build and sustain the health of the network.

Why the k parameter is special

Aside from more technical considerations, we remain committed to supporting smaller stake pools, because we believe this approach aligns with our long-term goal of creating the most decentralized and economically sustainable ecosystem of stake pools. This is further reflected in our delegation approach, which throughout 2021 will aim to support stake pool diversity.

Last year, we made the first significant adjustment to network parameters when we moved k from 150 (meaning a system optimized at launch for 150 block-producing pools, even though other pools could produce blocks) to k=500. This came about after extensive debate, both within IOHK and the Cardano Foundation and with the SPO community.

The move to k=500 was a balanced decision based on the need to create opportunity for more pools to produce blocks (by encouraging the flow of stake from saturated pools into new pools), while supporting the pools already creating blocks, and minimizing disruption for their delegators. Overall, it has proven successful – let's dive a little deeper.

The change to k=500

Prior to the announcement that k was changing, 54.6% of all delegated ada was represented by the 10 largest stake pools and 45.4% of ada represented by smaller pools. Following the change to k=500, those numbers have reversed: 55.9% of ada is now represented by pools other than the 10 largest.

This was a dramatic change directly linked to the change in k.

It is a great start, but our goal is to continue to optimize the network. So we observed what happened, gathered feedback, and incorporated everything we learned into making the next round of changes.

Pools will split when it makes economic sense to do so. For those pools with a greater proportion of pledge, the more pledge they have, the more valuable it is and the more reason SPOs have to keep their pledge together. Conversely, if a pool has a low level of pledge, there is very little reason not to split it further to start additional pools.

While there is a cost associated with running a small pool, and given the current appreciation in the value of ada, we believe that the financial incentive for splitting pledge is even stronger now. Increasing k – for example to 1,000 – without addressing this first, would not lead to a more distributed and diverse ecosystem which, to be clear, is the objective. We will simply see many of the same operators just running twice as many pools.

Changing pledge

The a0 parameter rewards SPOs for concentrating their pledge into a small number of pools. This has been effective in encouraging pools with high levels of ada pledge to consolidate that into large private pools (as we at IOHK do) and therefore give smaller pools greater opportunity to attract delegation.

However, we believe the current system can be improved, so for some time now, we have been discussing and modeling options to make pledge more effective at addressing pool splitting for lower pledge levels.

The current structure of the rewards formula does not give us the flexibility to tweak the impact by a simple parameter change; we will need to modify the rewards formula, which is something our research team has been working on for some time.

Several promising candidates have come out of that evaluation process. We’d like at this point to acknowledge the valuable work from community contributor Shawn McMurdo in his Curve Pledge Benefit improvement proposal for helping to develop the thinking in this area.

Our research team is in the late stages of finalizing an approach. They will soon present their findings, and we will update the community then. However, the team has now concluded that a0 should change. We believe this change will greatly benefit the network, making the system more sustainable, widely distributed, and globally diverse. It will also increase the earnings of all public pools (ie, those that are not already fully 'saturated' with pledge).

While it has been a matter of considerable internal discussion, we have also concluded that any change in k should come after changing the formula for a0 to deliver the desired results (especially encouraging stake to flow to smaller single pools rather than split pools). Since this is a full formula modification, and no longer a simple epoch boundary change, it needs to be released as part of a hard fork. Given our product pipelines and the team’s current focus on continuing the Goguen rollout and available dates, we will be looking to making this change in the third quarter of the year.

Other considerations

Other factors need to be considered. Chief among these is the availability of multi-pool delegation, to allow ada holders to spread their stake across a number of pools from a single wallet. This requires significant backend work from the core development team, along with a new interface and business rules adjustments. We would also like – if possible – to offer better pledging options for SPOs from Daedalus in a similar timeframe (currently only available via CLI or AdaLite), which means additional development work not only for internal teams but also for the Ledger and Trezor wallet companies.

We will also continue researching other parameters such as the minimum fees (implemented to prevent a ‘race to the bottom’ yet skewed against smaller pools) while continuing benchmarking and optimizing node performance as smart contract functionality rolls out. Our responsibility and commitment remains to achieve a delicate balance between the stability, scalability and overall health of the network with a flourishing ecosystem of pool operators and delegators.

Evolving into the future

As we promote the health of the network and stake pool ecosystem, we continue to monitor and research other important parameters and values. This work considers both the tactical and strategic approaches we may take.

With the increase in the price of ada, implementation of native tokens, and anticipating smart contracts, we also continue to assess and review the Cardano fee structure. For example, based on community feedback, we are considering the tactical approach of immediately lowering some fees. The minimum fixed fee of 340 ada for stake pools is one strong candidate for change; network transaction fees and deposits for smart contracts are also under discussion.

Our researchers and analysts are also working with an external economic consulting group to formalize an optimization approach that ensures fees will remain stable and predictable over the longer term. The results of this review will include a governance model with a clear mandate about when and how fees should be determined in the future as we develop, optimize and scale the network. We’ll be sure to keep the community informed and involved as our thinking develops.

I’d like to thank and acknowledge Francisco Landino, Lars Brünjes, Aikaterini-Panagiota Stouka, Aggelos Kiayias, and Tim Harrison for additional input to this article and feedback throughout this evaluation period.

At the end of 2020, we announced our devnets plan to support the longer-term strategic goal of opening up Cardano to multiple development languages – as outlined in the ‘‘Island, Ocean, Pond’ video. This week, building on the Ethereum Virtual Machine, we’re rolling out a new development environment to support the Glow language.

François-René Rideau of Mutual Knowledge Systems is the creator of Glow, a DSL that will allow anyone to write verifiable DApps from a single spec and deploy it on our EVM network. We caught up with Rideau (also known as Fare) to hear more about his vision for Glow and the Cardano journey so far. The following is a distillation of his thoughts from our previous interviews.

We first introduced the community to GLOW and MuKn at the end of last year when we announced our devnets approach –  but maybe you can remind us how you began working with IOHK?

I started as a researcher in formal methods for programming languages and distributed systems. But I wanted to build systems actually used by many, so I moved into the industry where I notably worked on proving the correctness of a centralized payment protocol and creating an airline reservation system. After a few years at Google and Bridgewater, I decided life wasn’t worth working under dysfunctional hierarchies, so I started my own cryptocurrency companies. Charles invited me to speak at the IOHK Summit 2019, and I realized how much I like the Cardano community: we have a similar focus on building robust software for the long term. That is why I wanted to port my domain specific language Glow to Cardano.

Tell us a bit why you started your company Mutual Knowledge Systems, or as you call it MuKn (Moon)?

Over three years ago, I was reviewing whitepapers. Most papers (about ¾) had interesting techniques but made no economic sense. Most of the rest (about ⅕) made economic sense but had no technical content. Only the top few (about 5%) actually made sense both technically and economically. At some point, I realized I could do better, so I designed a scaling solution using lessons learned from working on Tezos. Arthur Breitman challenged me to use smart contracts instead of trying to modify his protocol.

While trying to prove his challenge absurd, I instead found that he was right and I was wrong—and I finally understood why and how to use smart contracts. I started a company around the resulting scaling solution, raised money, pivoted into building the scaling solution after the language capable of generating it from specification, fought with and fired my then-partner, became my own CEO, started a new company, and, after much struggle, finally found the right founding team. Together, we built Mutual Knowledge Systems around this new programming language, Glow—designed to be much better than existing languages to write decentralized applications.

When you say ‘better’, what do you really mean?

Writing a DApp is the single hardest thing to do in the world. This is because you can’t afford a mistake, or your users may lose significant funds. Furthermore, you are not confronting random situations, but active adversaries bent on attacking your code, who will contrive the very worst case scenarios to exploit for their profit. Yet, unlike the military, you can’t hide your code or protect access to your networks: all the critical pieces are necessarily public. On top of that, extant programming tools are not designed for these constraints and even traditional formal methods lack essential concepts to express the issues at stake.

Thus, we decided to make new tools fit for the challenge. Our domain-specific language (DSL) drastically simplifies DApp development, by abstracting away all the common blockchain infrastructure, so you can focus on your problem domain (trading, derivatives, insurance, supply chain, etc.). Your DApps can be thousands of lines of code that your users can afford to audit, instead of millions of lines of code that require leaps of blind faith. And the programming model will enable developers, auditors and automated verification tools to reason at the level of abstraction of participants exchanging assets, rather than at that of packets of bytes shipped around the Internet.

What is it about Cardano and its community that appeals?

I started like everyone else, on Ethereum, because its ecosystem is already mature. However, the Ethereum community has this attitude of building as fast as possible experiments that are good enough for now, but lack conceptual integrity and won’t last; I see a lot of value in that approach and have tremendous respect for those who can thrive this way—for I cannot. When I met the Cardano community, I felt much more at home because we share a common attitude. We want to do things that are correct by construction and will keep working in the long term. We build concrete towers on the bedrock, not stick shacks on the sand. At times, this can be frustrating because things go slow, but I am happy with the attention to detail and quality in the development of Cardano. Is it perfect? No, it’s not. But it’s got great fundamentals.

Can you talk about how you hope Glow will change the DApp developer experience?

Glow is portable. Today it works on Cardano and Ethereum but in the future it will work with any blockchain that is sufficiently advanced to support smart contracts. That means that you can write your DApp once and it will run on whichever platform has the users and the liquidity you seek. You don’t have to make a guess about where liquidity will be in the future then sink heavy investments to develop on a single chain that you bet your house on.

With Glow, developers can run their DApps on all blockchains. Glow will commoditize blockchains. Blockchains will then compete on technical and economic merits, not on user lock-in and inertia. And the value brought to users will increase.

What can the community expect from Glow?

We have launched this early version of Glow on the Cardano EVM Devnet with a command-line interface. In many ways, it is not yet ready for use by end-users, but it can already demonstrate simple applications. Users can also see how they may write a 6 line application in Glow that would require hundreds of lines in a combination of Solidity and JavaScript. We have a roadmap over the next few months to add a lot of features: from ERC20 tokens (and, on Cardano, native tokens), to generalized state channels, to a web interface, to a more robust runtime, etc. Eventually, we want to become the development environment for all blockchain projects. And Glow is of course an open source software open to the community.

We’re rolling out the integration with Glow with our EVM and devnet program, so what are some of the benefits of this?

The Cardano EVM side-chain will enable arbitrary contracts to run on Cardano that use the mature EVM platform, without waiting for Plutus to deliver its promise, to achieve feature-parity, to be considered stable, etc. And Glow can run on this EVM side-chain and provide the simplicity, safety and portability in DApp development that were not available before.

What is the rollout process like and how can our community get involved if they want to?

Glow is still in development. There are some things that it can do already and some it can’t do yet. We invite DApp developers to join the Glow community and use the language for what it can already do, and otherwise help us build the blockchain development environment of the future. You can build the missing features you need yourself, or contract MuKn to build them for you. Even if you can’t code and have no budget, you can help write the documentation, or even just tell us where it isn’t clear yet, or what features you need most so we know what to prioritize. Together, we can build great DApps that you just couldn’t have achieved safely and within budget with previous tools.

If you’re a developer, we encourage you to get involved with Mutual Knowledge Systems and Glow. See our full conversation with François-René Rideau and a demonstration of Glow during Cardano360.

In Douglas Adams' classic The Hitchhiker's Guide to the Galaxy, a Babel fish is a creature that allows you to hear any language translated into your own. This fantasy of universal translation ensures meaningful interaction despite the myriad different languages in the galaxy. 

In the cryptocurrency space, smart contract platforms enable the development of a myriad custom tokens. Is it possible to interact with the platform using your preferred token? If only there was a “Babel fees” mechanism to translate the token you use to the one that the platform requires for posting a transaction. 

Common wisdom in blockchain systems suggests that posting a valid transaction must incur a cost to the sender. The argument is that, without such constraint, there is nothing to stop anyone from overloading the system with trivial transactions saturating its capacity and rendering it unusable. Given the above tenet, a frequently made corollary is that in any blockchain system where user-defined tokens are supported, it should be prohibited to pay transaction fees in such tokens. Instead, transactions should carry a fee in the native token of the platform that is accepted by all participants as being valuable.  Arguably such a restriction is undesirable. But how is it possible to circumvent the ensuing – and seemingly inevitable – vulnerability? 

The art of the possible

Cryptography and game theory have been known to make possible what seemed impossible. Celebrated examples include key exchange over a public channel, Merkle's puzzles, and auctions where being truthful is the rational thing to do, like Vickrey's auctions. And so it also turns out in this case. 

First, let us recall how native assets work in Cardano: Tokens can be created according to a minting policy and they are treated natively in the ledger along with ada. Cardano's ledger adopts the Extended UTXO (EUTXO) model, and issuing a valid transaction requires consuming one or more UTXOs. A UTXO in Cardano may carry not just ada but in fact a token bundle that can contain multiple different tokens, both fungible and non-fungible. In this way it is possible to write transactions that transfer multiple different tokens with a single UTXO. 

Transaction fees in the ledger are denominated in ada according to a function fixed as a ledger parameter. A powerful feature of Cardano's EUTXO model is that the fees required for a valid transaction can be predicted precisely prior to posting it. This is a unique feature that is not enjoyed by other ledger arrangements (such as the account-based model used in Ethereum). Indeed, in this latter case the fees needed for a transaction may change during the time it takes for the transaction to settle, since other transactions may affect the ledger's state in between and influence the required cost for processing the transaction. 

A thought experiment

Let's consider the following thought experiment to help us move closer towards our objective of Babel fees. Imagine that it is possible to issue a transaction that declares a liability denominated in ada equal to the amount of fees that the transaction issuer is supposed to pay. Such a transaction would not be admissible to the ledger. However it can be perceived as an open offer that asks for the liability to be covered. Why would anyone respond to such an offer? To entice a response, assuming the token bundle concept already present in Cardano,  the transaction can offer some amount of token(s) to whoever covers the liability. This suggests a spot trade between ada and the offered token(s) at a certain exchange rate. Consider now a block producer that sees such a transaction. The block producer can create a matching transaction absorbing the liability covering it with ada as well as claiming the tokens that are on offer. 

By suitably extending the ledger rules, the transaction with the liability as well as its matching transaction become admissible to the ledger as a group. Due to the absorption of the liability, the set of two transactions becomes properly priced in ada as a whole and hence it does not break the ledgers' bookkeeping rules in terms of ada fees. As a result, the transaction with the liability settles, and we have achieved our objective. Users can submit transactions priced in any token(s) they possess and, providing a block producer is willing to take them up on the spot trade, have them settle in the ledger as regular transactions!

A concrete example

The mechanism is of course conditioned on the presence of liquidity providers that possess ada and are willing to issue matching transactions. In fact the mechanism creates a market for such liquidity providers. For instance, a stake pool operator (SPO), can publish exchange rates for specific tokens they consider acceptable. For instance an SPO can declare that they will accept tokenX for an exchange rate 3:1 over ada. It follows that if a transaction costs, say ₳0.16, the transaction can declare a liability of ₳0.16 as well as offer 0.48 of tokenX. In the native asset model of Cardano this can be implemented as a single UTXO carrying a token bundle with the following specification (Ada→ -0.16, tokenX→0.48). Note the negative sign signifying the liability. 

Suppose now that the SPO is about to produce a block. She recovers the liability transaction from the mempool and issues a matching transaction consuming the UTXO with the liability. The matching transaction transfers 0.48 of tokenX to a new output which is owned by the SPO. The resulting block contains the two transactions in sequence. The matching transaction provides the missing ₳0.16 in addition to the fees that are needed for itself. In fact multiple transactions can be batched together and have their fees covered by a single matching transaction. 

Figure. Alice sends a quantity of 9 tokens of type X to Bob with the assistance of Stacy, an SPO, who covers Alice's transaction liability and receives tokens of type X in exchange. The implied exchange rate between X and Ada is 3:1. 

New measures of value

The above process is entirely opt-in for SPOs. Each one can determine their own policy and exchange rate as well as decide to change the exchange rate for the various tokens they accept on the spot. Moreover, there is no need for agreement between SPOs about the value of a specific token. In fact, different SPOs may provide different exchange rates for the same token and a user issuing a liability transaction can offer an amount of tokens corresponding to the minimum, average or even maximum of the posted exchange rates in the network. In this way, a natural trade off arises between settlement time of liability transactions and the market value of tokens they offer. 

This illustrates how native assets, the EUTXO model, and the simple but powerful tweak of introducing liabilities in the form of negative values in token bundles can accommodate Babel fees empowering users to price transactions in any token supported natively by the system. It also shows the unique advantage of being an SPO in such a system. It should be noted that SPOs need not be the only entities in the network offering to cover liabilities. In fact, an SPO can readily partner -if they wish- with an external liquidity provider who will be issuing the matching transactions. In addition, third party providers can also act on the network independently and issue matching transactions. Nevertheless, the benefit will remain with the block producers; SPOs can always front-run matching transactions and substitute them for their own if they wish so. This is a case that front-running transactions is a feature: it makes it feasible for SPOs to be paid in the tokens they prefer for their transaction processing services.

The mechanism of negative quantities in token bundles can be implemented in the basic ledger rules of Cardano at some point following the introduction of native assets with the Mary Hard Fork. Beyond Babel fees, the mechanism allows a variety of other interesting applications, such as atomic swaps for spot trades, that we will cover in a future blog post. It is yet another illustration of the power of Cardano's approach and its ability to support a diverse and entrepreneurial community of users and stake pool operators. 

I am grateful to Manuel Chakravarty, Michael Peyton Jones, Nikos Karagiannidis, Chad Nester and Polina Vinogradova for helpful discussions, suggestions and comments related to the concept of Babel fees and its implementation in the Cardano ledger. We also have a video whiteboard walkthrough covering this topic.