Cardano's future "mic drop" moment: being able to pay transaction fees in custom currencies will attract ERC-20 issuers to Cardano ecosystem

Concept explained, video: https://www.youtube.com/watch?v=TkiltupoocM , 9 minute video about "Babel Fees on Cardano" by Prof. Aggelos Kiayias / Whiteboard Presentation

Source: https://iohk.io/en/blog/posts/2021/02/25/babel-fees/

"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."

Exploring a new mechanism to help make fees fair, stable, and more predictable over time: stablefees and the decentralized reserve system -> IOG blog: https://iohk.io/en/blog/posts/2021/06/10/stablefees-and-the-decentralized-reserve-system/

The core idea behind Stablefees is to have a base price for transactions through pegging to a basket of commodities or currencies. Stablefees includes a native "decentralized reserve" contract that issues and manages a stablecoin pegged to the basket. A comparison in the fiat world might be the International Monetary Fund’s SDR, (established in 1969) and valued based on a basket of five currencies—the U.S. dollar, the euro, the Chinese renminbi, the Japanese yen, and the British pound sterling. The stablecoin --- let’s call it "Basket Equivalent Coin" (BEC) --- is the currency used for paying transaction fees (and all other real world pricing needs of the platform, e.g., SPO costs).

In this system, ada will play a dual role: Reserve asset of the decentralized reserve, and reward currency for staking. It will also be the fall-back currency in extreme scenarios where the reserve contract is in a liquidity crunch.

The centerpiece of this mechanism is an on-chain oracle that determines the price of the basket in ada. SPOs can implement this oracle in a decentralized manner. The reserve can offer extra rewards to all oracle contributors from the fees collected during BEC/DEC ( decentralized equity coins ) issuances.

The Stablefees mechanism can be considered a natural extension of Babel fees ---spot conversion of BECs into ada by the decentralized reserve. Both mechanisms complement (and are compatible with) each other. Babel fees can be deployed together with Stablefees with just one change: Using BECs to cover Babel fee liabilities, instead of ada. This also means that fees will always be payable in ada (via a Babel fee liability convertible in ada on the spot).

Our team is currently researching the granular details of the Stablefees mechanism. Once this research is complete, Stablefees can be integrated into Cardano to offer fair and predictable transaction pricing. Moreover, the price oracle and the global BEC (and regional variants, if included) will undoubtedly find uses beyond paying transaction fees, expanding the capabilities of decentralized applications in the Cardano ecosystem.

Source: https://arxiv.org/abs/2106.01161

Custom currencies, usually following the ERC-20 standard, are one of the most popular smart contracts deployed on the Ethereum blockchain. These currencies are however second class to the primary currency Ether. Custom tokens are not natively traded and accounted for by the Ethereum ledger; instead, part of the logic of an ERC-20 contract replicates this transfer and accounting functionality. The second class nature of custom tokens goes further,though: transaction processing and smart contract execution fee scan only be paid in Ether — even by users who have got custom tokens worth thousands of dollars in their wallets.

Cardano's approach:

• by introducing native custom tokens it is possible to allow custom tokens to reuse the transfer and accounting logic that is already part of the underlying ledger. This is achieved without the need for a global registry or similar global structure via the concept of token bundles in combination with token policy scripts that control minting and burning of custom tokens.

• requirements for babel fees are summarized as follows:

  • (1) participants that create a babel fee transaction should be able to create a normal transaction, which will be included in the ledger exactly as is (i.e., no need for meta-transactions or specially crafted smart contract infrastructure) and
  • (2) the protocol should be non-interactive in the sense that a single message from the creator of a transaction to the participant paying the fee in the primary currency should suffice. In other words, we want transaction creation and submission to be structurally the same for trans-actions with babel fees as for regular transactions.

• Our implementation of babel fees is based on a novel ledger mechanism, which we call limited liabilities. These are negative token amounts (debt if you like) of strictly limited lifetime. Due to the limited lifetime of liabilities, we prevent any form of inflation (of the primary currency and of custom tokens).

• Transactions paid for with babel fees simply pay their fees with primary currency obtained by way of a liability. This liability is combined with custom tokens offered to any party that is willing to cover the liability in exchange for receiving the custom tokens.

• modify the ledger rules in three ways:

  • (1) The original UTXOma rules are defining ledger validity by adding transactions to the ledger one by one. We extend this by including the ability to add transactions in batches; i.e.,multiple transactions at once
  • (2) We drop the unconditional per-transaction ban on negative values in transaction outputs and replace it by the weaker requirement that there remain no negative values at the fringe of a batch of transactions. In other words, liabilities are confined to occur inside a batch and are forced to be resolved internally in the batch where they are created.
  • (3) We amend the rules about the use of policy scripts such that the script of a token ???? is guaranteed to be run in every transaction that increases the supply of ????

The paper makes the following contributions:

• We introduce the concept of limited liabilities as a combination of negative values in multi-asset token bundles with batched transaction processing (Section 2)
• We introduce the concept of babel fees on the basis of limited liabilities as a means to pay transaction fees in tokens other than a ledger’s primary currency (Section 2)
• We present formal ledger rules for an UTXO multi-asset ledger with limited liabilities (Section 3)
• We present a concrete spot market scheme for block producers to match babel fees (Section 4)
• We present a solution to the knapsack problem that block producers have to solve to maximise their profit in the presence of babel fees (Section 5)

Token bundles are, in essence, finite maps that map an asset ID to a quantity — i.e., to how many tokens of that asset are present in the bundle in question. The asset ID itself is a pair of a hash of the policy script defining the asset’s monetary policy and a token name, but that level of detail has no relevance to the discussion at hand.

Other applications of limited liabilities

While our primary motivation for proposing liabilities limited by transaction batches are babel fees, the mechanism of limited liabilities is more broadly applicable:

• Swaps

  • As discussed, we use liabilities in babel fees to form transaction outputs that represent atomic swaps — we call those swap outputs. We do this by including a liability (negative token value) together with an asset (positive token value). Whoever consumes such an output effectively swaps the tokens described by the liability for those constituting the asset

• Service payments

  • Extending the concept of swaps from ex-changing assets to exchanging assets for information. In the Extended UTXO model, which facilitates complex smart contracts on a UTXO ledger, transaction outputs also include a data component. This can, for example, be used to communicate information from an off-chain oracle. Liabilities included with such an output can serve as payment for consuming such an output with the data.

• Indivisibility

  • Transaction batches are different to signed trans-action groups proposed for some ledgers, such as, for example, Algorand. To create a signed transaction group, all component transactions need to be known and the group signed as a whole. If multiple component transactions are created by different parties,these parties need to cooperate to create the group transaction. The benefit of such a signed group is that it is indivisible. The transaction batches that we propose are different.

Cardano's "Competition" (Ethereum, Algorand and Stellar and XRP Ledger built-in DEX) comparison

Ethereum

Ethereum supports fee payment in non-primary currencies via its Gas Station Network. The gas station infrastructure consists of:

• a network of nodes listening for meta-transactions (transaction-like requests to cover transaction fees), which turn these requests into complete transactions, with fees covered by the relay node, and
• an interface that contracts must implement in order for the relay nodes to use this contract’s funds to subsidize the transaction fees.

This infrastructure consists of many moving parts working together, including smart contracts, relays, relay hubs, and communication on a network separate from the main chain network. Only GSN-enabled contracts can cover transaction fees. Cardano's proposal does not require any changes to existing smart contracts, and does not require meta-transactions to be disseminated on a separate network, since they are already fully-formed and signed transactions. In addition, unlike the GSN, there is no further action required from the user after submitting a Babel-fee transaction. The design of the GSN allows for the possibility that an incorrect transaction is submitted by a relay node in response to a sender’s fee-coverage request. The onus is on the sender to monitor the chain, and reques tpunitive measures to be taken against an offending relay. There are other verifications necessary to participate in GSN. Submitting transactions with liabilities has no potential of unexpected consequences (whether they are included in the ledger or not). The GSN requires participating fee-covering contracts to pre-pay for the fee amounts they intend to cover. This approach involves additional maintenance, monitoring, and communication. The contract may specify the tokens it accepts in exchange for covering fees, but the extra step of posting and updating the contracts on-chain is less flexible and has more steps (including submitting potentially costly transactions) than our strategy. Recall that in our design, we propose to automate the process of any user getting a transaction with an exchange offer, accepting or rejecting the offer based on maximizing the value they are getting by engaging in theoffer, then submitting the batch containing the swap transactions to the chain. With Babel fees, a user may use a higher-than-minimum fee or exchange bid to increase the chances of their transaction to be accepted sooner. The exchange offers made via GSN-enable smart contracts, as well as the fee amounts the contract is willing to cover,are all fixed.

Algorand

Algorand in an account-based cryptocurrency which supports custom native tokens. It provides users with a way to perform atomic transfers. An atomic transfer requires combining unsigned transactions into a single group transaction, which must then be signed by each of the participants of each of the transactions included. This design allows users to perform, in particular, atomic swaps, which might be used to pay fees in non-primary currencies. As with our design, the transactions get included into the ledger in batches. Unlike the mechanism we propose, however, incomplete transactions cannot be sent off to be included in the ledger without any further involvement of the transaction author. This interactive protocol specification ensures that batches cannot betaken apart and completed using other transactions. This may be an advantage in certain cases over a batch that is combined in a loose, easily decomposable way, but this behaviour can also be implemented in the system we have presented. Moreover, an interactive protocol for building group transaction requires additional communication, which is, in this case, reliant on off-chain communication.

Stellar built-in DEX (XRP Ledger DEX works in a similar way)

A common blockchain solution to providing swap functionality (and therefore, custom token fee payment) is a distributed exchange (DEX). The Stellar system supports a native, ledger-implemented DEX. In the Stellar DEX, offers posted by users are stored on the ledger.A transaction may attempt an exchange of any asset for any other asset, and will fail if this exchange is not offered. This approach requires submitting transactions to manage a user’s on-chain offers, and also requires all exchanges to be exact — which means no overpaying is possible to get one’s bid selected. A transaction may attempt to exchange assets that are not explicitly listed as offers in exchange for each other on the DEX. The DEX, in this case, is searched for a multi-step path to exchanging these assets via intermediate offers. This is not easily doable using the approach we have presented. A DEX of this nature is susceptible to front-running. In our case,block issuers are given a permanent advantage in resolving liability transactions over non-block-issuing users. Among them, however,exactly one may issue the next block, including the liabilities they resolved.