FEE-LESS Blockchains & Smart Contracts: Introducing Koinos' MANA

At Koinos Group, our mission is to accelerate the transition to a truly decentralized future by maximizing blockchain accessibility.

We believe that building a truly fee-less blockchain capable of powering free-to-use decentralized applications is key to accomplishing this mission because fees are an obvious barrier to entry that is limiting the adoption of blockchain technology.

Mana is our core innovation designed to achieve that objective by implementing a fee-less solution to the problem of blockchain spam (the halting problem).

What we propose is a generalized solution for allowing fee-less transactions (and therefore smart contracts) on a blockchain but what we also hope to convey is why we believe that mana is more than just a fee-less solution to the halting problem, it is a superior solution for blockchain resource management that is key to achieving the mass adoption of blockchain technology.

Introduction

The purpose of the mana system is to allow liquid token holders to perform fee-less transactions in an economically sustainable manner while minimizing cognitive load. It is a dynamic system for incentivizing consistent network usage while mitigating spam thereby minimizing long term state growth. Mana also provides the system with an objective method for determining whether, and to what extent, an account can be deemed a “user” which can be useful in decentralized governance.

Previous Work

Vitalik Buterin’s main objective was to allow users to add code (instructions) to their blockchain transactions for the purpose of having them executed by a decentralized network of computers (a “world computer”), thereby enabling “smart contracts.”

Buterin’s key insight was that by allowing developers to write these smart contracts using a Turing complete programming language he could maximize the creative space available to blockchain-based application developers. But this creates the risk that a user could run a program that consumes all of the resources on the network; i.e. the halting problem.

To solve this problem Buterin invoked the widely known concept of “gas” which is distinct from the currency of the platform, Ether (ETH). His solution to the halting problem as described in the Yellowpaper was to assign gas costs to each instruction based on its computational cost. Adding two numbers would cost 3 gas, multiplying them would cost 5 gas, storing 1KB of data costs 64000 gas, etc.

Decentralized Exchange for Resources

When a smart contract is executed, the gas costs for each instruction called by the smart contract are summed. The user must then add some amount of ETH to their transaction which must be accepted by a miner/validator at which point the total amount of gas required to execute the smart contract is “consumed” from the total amount of gas allocated to the Ethereum block to which it will be added.

Gas is not a token, it’s a powerful concept that allows miners and users to negotiate the price of computational resources thereby facilitating a decentralized exchange. Miners can look at how much it costs them to execute these same instructions in whatever currency they use to pay their bills (like US dollars) and then convert that cost into ETH to effectively charge the unknown user.

Every block is conceived as having a limited amount of gas which is set by the miners. Once a transaction is processed, the gas specified in the transaction is “consumed” from the “block gas limit.” For example, if the miners specify a block gas limit of 10,000,000 gas, and a transaction consumes 1,000,000 gas, then there is only 9,000,000 gas “left” within the block for use in transactions. If all of the gas in a block gets consumed, then all remaining transactions must wait for another block to get processed.

Ethereum's London Upgrade: An Overview

In the London Upgrade, Ethereum introduced variable-sized blocks which allows the platform to better adapt to periods of high network demand. Instead of a fixed gas limit, there is a target size of 15 million gas per block and a high gas limit of 30 million gas. Every time a block size exceeds the target (15m gas) the base fee associated with transactions increases 12.5% to gradually disincentivize usage without creating the poor user experience of simply rejecting transactions from a block.

Such a system had already been implemented on Steem (now Hive) and works well with the fee-less systems on those chains which are effectively precursors to the mana system. It would therefore be our recommendation for the Koinos mainnet to feature a similar implementation. That being said, the modular upgradeability of the Koinos Blockchain Framework means that this change could be made without necessitating a hard fork as it did on Ethereum.

The Concept of Mana

Vitalik invoked the concept of gas because it quickly conveyed the type of user experience one could expect to have on Ethereum. If you’ve owned a car then you understand that you need to buy gas which you will then consume down as you drive.

In order to deliver a mass-market user experience on a blockchain we need to make the experience more than tolerable, it must be fun. To accomplish this we seek to mimic the user experience of a video game which is why we invoke the widely known concept of mana (though “health” and “stamina” could just as accurately be used within user interfaces). It is also for this reason that we suggest people only use the term mana to describe a resource system as described herein both because it is the most accurate and efficient implementation of this mental model and to avoid user confusion.

The Mental Model

In a video game, mana is something you get simply for playing the game, but that is consumed down as you perform certain actions and regenerates over time. Users can then acquire more mana either by purchasing more of the “in-game currency” or by simply waiting.

In order to mimic this user experience and deliver a frictionless blockchain user experience, we conceive of every KOIN token as being “born” with a certain amount of mana (e.g. 1 mana is “full mana”) which can be consumed when a user consumes network resources. In this way, fee-less transactional capabilities are able to accrue to liquid token holders, thereby minimizing friction and cognitive load. In other words, the user implicitly possesses mana by simply holding liquid KOIN, but this mana only materializes after the transaction takes place.

Without the introduction of any additional systems or complexity, this design creates an ever-increasing opportunity cost associated with performing fee-less transactions because choosing to keep one’s tokens liquid inherently precludes them from participating in any yield-generating activities (e.g. block production, staking, yield-farming, DeFi, etc.). This makes the mana fee-mechanism far more dynamic and scalable than an explicit fee. As the platform grows (acquires a larger number and wider variety of dApps and users) the opportunity cost associated with performing fee-less transactions will naturally increase, motivating users to be more judicious with their fee-less transaction capacity.

For our blockchain implementation, we imagine mana as something similar to gas in that every block has a certain amount of mana in it that maps to the number of network resources we want consumed.

But whereas Ethereum requires that the user purchase gas from miners which then gets consumed by the transaction, we propose a system that interprets the liquid holdings of a cryptocurrency (KOIN in the case of Koinos) as simply containing a set amount of mana (e.g. 1 KOIN contains 1 mana).

Now when the user submits a transaction, they already have mana that can be consumed down. Of course, the user must still incur some cost based on the cost of the network resources being consumed which is why once any of the mana in a given token is consumed that token should be locked for a period of time. This creates an opportunity cost in lieu of a real-time monetary cost that serves to disincentivize the submission of value-less transactions.

Token Locking & Regen

Once any of the mana in a given token is consumed, the blockchain should interpret that entire token as being “locked” (non-transferable) for a fixed period of time that will be specified within the mana smart contract. In addition to creating the opportunity cost that ensures the economic sustainability of the system, this fixed period of time functions as a “regen time” which creates the user experience of mana “regenerating over time” and helping to deliver a game-like user experience.

Regen time should be chosen by balancing user experience and state growth concerns. A very long regen period will act as a disincentive to use the blockchain, thereby minimizing state growth and maximizing the affordability of the blockchain. A very short regen period will incentivize high usage which will maximize state growth thereby reducing the affordability of the blockchain.

The regen time should be satoshi-based, meaning that it is based on how long it takes for one satoshi of mana to regenerate, with regeneration happening on all tokens at the same time. Despite being a fixed period, because this mechanism is distributive, the regen time appears dynamic to the user.

Example

You have 1 KOIN and use 0.5 mana. Your 1 KOIN is constantly regenerating over 5 days. You have 1 KOIN’s worth of mana regenerating a 0.5 mana deficit. Therefore it will only take 2.5 days to regenerate back to full mana. Furthermore, mana regenerates continuously. So, after 12 hours, you would have regenerated 0.1 mana and would have 0.6 mana available.

This once again highlights the benefit of implementing the system as an upgradeable system contract. A fixed lockup period is computationally efficient and delivers a more predictable user experience while still appearing dynamic to the end-user, but what if the “wrong” period is chosen? Implementing the system as an upgradeable smart contract means that governance can make that change without disrupting network performance or creating additional operational overhead for node operators.

Tx Ordering & Failing

Transactions should be processed based on the order in which they are submitted (“first in first out”). If the transaction requires more mana than the max mana, the transaction should be cut off at the max mana and a transaction reversion should occur. In this case, the mana would be consumed but the transaction will fail.

Opcode Pricing

An ideal implementation of mana would be similar to gas in that every instruction would have a specific cost in mana. Koinos is designed to be VM-agnostic so that it can be rapidly upgraded to the best available WASM VM. Therefore, how opcode pricing is implemented will depend on the VM being used. At the moment, (Fizzy) appears to meet our needs and there is an open issue detailing a method for benchmarking individual opcodes. If there is no opcode metering built in, opcode pricing can be determined through benchmarking on target hardware.

Separate Resource Pools

One of the advantages to this implementation is that individual resources can be tracked independently, allowing developers to optimize their contracts for underutilized resources. To take advantage of this capability mana should not be implemented with a target consumption level like gas, but with resource pools. Resources should be pooled every block and there should be a limit to how many of those resources can be consumed per block. A market maker can then be used to set a price for the resources in a given block.

Ethereum’s gas calculations are one-dimensional, pricing very different resources (e.g. storage and compute) as if they are the same. This means a block that consumes a large amount of compute might cost the same gas as another block that consumes almost no compute but a large amount of storage. This is a big problem because it means that there is no way for the system to disincentivize the consumption of scarce network resources (and incentivize the consumption of underutilized resources). Mana solves this problem leading to a network that makes far more efficient use of resources.

With the mana resource model, the resources are tracked separately but the user is still only charged in mana. This is a subtle but important distinction because the consequence is a more efficient network. Not only can developers now optimize their contracts to target underutilized network resources, but end-users will prefer those dApps which perform such optimizations because they will get more “bang for their mana,” creating a positive feedback loop of self-regulation.

The mana they are charged can be simply the linear combination of each resource and cost (e.g. `bandwidth_cost * bandwidth_used + storage_cost * storage_used + compute_cost * compute_used`).

Max Mana

Because there are no fees, the user needs to only submit their transaction with the maximum amount of mana which they are willing to get consumed (“max mana”) and which represents how much of their tokens (e.g. KOIN) they are willing to get locked up temporarily. It is through the temporary locking of tokens that users will incur an opportunity cost as a disincentive to submit value-less transactions. To minimize cognitive load for users, the client library could specify a default max mana.

Whatever amount of mana remains between the max mana and the mana price is not consumed and so that capacity (i.e. mana) should remain within the block and within the user’s account.

Automated Resource Markets

Fees are how human actors (miners/validators) set the cost of using the network which can lead to inefficiencies and perverse incentives. Eliminating the fees incidentally eliminates the need for a human actor and creates the opportunity for managing network resources via an optimized algorithm. When a transaction is accepted, the appropriate amount of mana should be consumed from both the target mana amount for the block and the user’s mana balance based on the price set by the algorithm. For simplicity’s sake, we will assume that 1 token contains 1 mana.

Example:

Assume that the target mana amount on Koinos is 15 mana and a transaction is submitted with a manaLimit of 1. Further assume that the algorithm determines that the price of the transaction is .5 mana, that the user has 1 KOIN, and 1 KOIN always contains 1 mana. 0.5 mana is consumed from both sides. There is now 14.5 mana left to be consumed from the block (without going into burst mode) and the user still has .5 mana left to be consumed by performing an additional transaction.

Dynamic v. Active Staking

This approach to staking for fee-less transaction capacity can be thought of as “dynamic staking” because the system automatically stakes the minimum necessary and then returns liquidity as quickly as possible, with no active participation from the user required. The user never has to make a decision, but the outcome is always optimal and frictionless for them.

This is a marked improvement over prior platforms that force the user to actively stake tokens before they are allowed to transact (e.g. Steem, EOS). On those platforms, the user has to consciously decide ahead of time to exchange liquidity, and a certain amount of liquidity, for an unknown amount of transaction capacity. Because they can’t know how much they will ultimately need, they will naturally stake well in excess of how much they think they will actually need. Furthermore, once the user has staked tokens, it requires a conscious action to un-stake them. The friction on both sides is working against the user.

This guarantees that the user won’t use all of their transaction capacity, meaning that they are overpaying to use the blockchain. This has led to mining contracts on EOS which exchange this transaction capacity dust for some user-defined token in an attempt to maximally monetize resources.

Why XYK?

The mana pricing algorithm, like all business logic on Koinos-based chains, should be implemented as an in-band upgradeable system contract which would mean it could ultimately be replaced without requiring a hard fork if a better solution emerges.

However, we believe this to be extremely unlikely for several reasons which also highlight why the xyk algorithm is the ideal solution to this problem.

There are a certain amount of system resources contained within blocks that the community will want consumed by users based on a balance of considerations like throughput and state size (e.g. 1MB target block size). This can be accurately conceptualized as a supply of resources that increase linearly over time as new blocks are created.

It is only on the demand side that we have human actors demanding network resources for the purpose of having their transactions (and the smart contracts they contain) added to the blockchain. What we therefore want is the most efficient algorithm for (1) determining a price for those network resources such that (2) the price is as low as possible but (3) it increases based on demand so that (4) the network is protected.

Put another way, we have a supply on one side of the market that is increasing at a constant rate (x) and demand on the other side created by human actors (y) and we want to use an efficient algorithm to determine a price (in mana) for the purpose of targeting a constant amount of resources (k) over time while ensuring that if demand consistently outpaces supply price should approach infinity, thereby protecting network resources.

Conversely, if there is underconsumption of network resources (below-average demand over time) the supply will max out making the price very low and allowing it to stay low.

Individual Resource Markets

This perfectly describes an xyk market maker which also enables Koinos to have a market for each individual resource. Resource-specific mana prices can then be summed to a total that is charged to the user (1). This system would gradually and continuously charge users more mana as they consume more contentious resources and less mana for consuming underutilized resources (3). The end result is a simple, efficient, and dynamic system for determining resource costs based on user behavior that guarantees the lowest possible cost (2), while ensuring that the network is protected (4).

The London Hard Fork bolsters this argument because it demonstrates the value in automating the process of resource management on a blockchain. Leaving users to bid on network resources is a highly efficient method for determining price, but it also results in the bidding up of prices.

Introducing a market maker effectively forces market participants to collude with one another to set the price at the lowest viable price.

The London Hard Fork appears to employ a market maker that leverages the same difficulty algorithm used in their consensus system (linear scaling of difficulty).

This is likely due to their familiarity with the algorithm and the nature of their opcode pricing mechanism. Ethereum tracks gas prices per VM opcodes which are combined into one gas price. This means that network resources are effectively intermingled such that it is not possible to optimize smart contracts based on network resource consumption.

XYK v. Linear Scaling

We believe that pure use of an xyk market maker algorithm is a superior implementation for several reasons. This allows the system designers to split resources into multiple markets, solving the one dimensionality problem while allowing the price action to respond to the particular use of a smart contract and the specific resources it uses.

This approach to staking for fee-less transaction capacity can be thought of as “dynamic staking” because the system automatically stakes the minimum necessary and then returns liquidity as quickly as possible, with no active participation from the user required. The user never has to make a decision, but the outcome is always optimal and frictionless for them.

This is a marked improvement over prior platforms that force the user to actively stake tokens before they are allowed to transact (e.g. Steem, EOS).

On those platforms the user has to consciously decide ahead of time to exchange liquidity, and a certain amount of liquidity, for an unknown amount of transaction capacity. Because they can’t know how much they will ultimately need, they will naturally stake well in excess of how much they think they will actually need. Furthermore, once the user has staked tokens, it requires a conscious action to unstake them. The friction on both sides is working against the user.

This guarantees that they won’t use all of their transaction capacity, meaning that they are overpaying to use the blockchain. This has led to mining contracts on EOS which exchange this transaction capacity dust for some user-defined token in an attempt to maximally monetize resources.

Receiver Pays Mana

The design of Koinos effectively has a kind of mana delegation built-in without requiring additional system logic. Koinos smart contracts give a high degree of freedom to the smart contract developer. One of the ways a developer could leverage this freedom is by including “receiver pays” logic in their smart contract.

This would mean specifying within their smart contract that they (the developer) will provide the mana when their user runs that smart contract.

Example

The developer of a trading card game wants to enable User A to sell their NFT to User B in exchange for APP tokens. They provide a DEX smart contract that specifies they (the developer) will pay the mana cost of the transaction. The user submits their transaction to the DEX smart contract, the developer’s mana gets consumed, and the transaction is completed.

If a user runs a smart contract that consumes 1 mana that is paid by the developer, then from the user’s perspective it is as if they had been delegated 1 mana. Best of all, this “delegation” can only be used within the developers' app, meaning that the user can’t use a game developer’s mana to trade DeFi.

The developer can lean into this effect by placing limits on how much mana they will allow to be consumed by a given user. The developer in the above example could decide to limit a given user to consuming 10 mana.

They could then inform the user that they have been delegated 10 mana, but only for use in the DEX. From the user’s perspective they will then be able to use the DEX for free until they have consumed down 10 mana.

They have effectively received a 10 mana delegation despite the fact that no smart contract has been executed (lowering computational costs) and the developer remains in complete control of their KOIN and mana!

Mana Delegation

Mana delegation should be implemented as its own smart contract module. Delegation would give the recipient of the delegation full control over the specified amount of mana which effectively gives them control over the liquidity of the requisite amount of the delegator’s tokens.

This would be useful for those scenarios where someone wants to delegate mana to another person outside of the context of any specific application. As such, the function of the mana delegation contract would allow a user to specify an account that would be the recipient of a delegation and the size of the delegation.

Conclusion

We believe that this is not just a viable alternative to fee-based blockchain designs, but it is a superior implementation for blockchain resource management. It allows for more efficient use of network resources, provides more dynamic and scalable pricing through opportunity costs, all while providing a user experience that is more than tolerable, it’s engaging and fun like a game.

Furthermore, by removing friction from the user experience of Koinos, mana allows for frictionless markets for digital assets. The less friction in a market, the more efficient that market functions. By removing friction entirely, mana opens the door to the creation of markets with unmatched efficiency.

Interoperability

This implementation also has implications with respect to interoperability. The problem that interoperability is trying to solve is allowing users to move frictionlessly between blockchains. The primary source of that friction is obvious: fees.

Reasoning from first principles, the most effective means of massively increasing interoperability between chains is by eliminating fees! The mana system solves this.

Imagine being able to move seamlessly between Bitcoin, Ethereum, Koinos, and any other software solution while maintaining a smooth and pleasurable user experience because you aren’t forced to pay fees the moment you want to do anything useful. That is real interoperability and we believe the mana system is central to realizing that vision.

Scaling

Meanwhile, the same interoperability solutions (inter-blockchain communication; e.g. Cosmos IBC), scaling solutions (sharding, e.g. Near, Ethereum 2.0), throughput solutions (transaction pipelining, e.g. Solana), will work just as well on a fee-less platform as they do on a fee-based platform. In fact, as demonstrated by the London Upgrade, fee-based-bIockchains are inherently less scalable because they must sacrifice long-term cost for short-term user experience. This forces them to pursue scaling solutions sooner than mana-based systems. Of course, those same scaling solutions can then be rapidly integrated into mana-based blockchains with modular upgradeability!

For these reasons, we believe that mana is more than just a fee-less solution to the halting problem, it is key to achieving the mass adoption of blockchain technology through integration into the free-to-use internet-based applications that the public has become accustomed to using.

To learn more about Koinos, go to koinos.io

If you're interested in exploring blockchain integration, go to koinos.group