One of the most challenging aspects of public blockchains is allocating the limited resources of the network. In an ideal world, resources would be unlimited, and there would be no need to worry about things like spam; however, that is not the world we live in.

Every blockchain tries a different resource model that makes different tradeoffs between usability, security, socialization, privatization, and incentivization. Every model must make tradeoffs in some way; the only question is which model is best able to provide a competitive user experience?

Even centralized applications need to rate limit users. For example, Github only provides so much storage and computation time for free, and then they start charging. In this post, I am going to explore the tradeoffs of resource models of EOS, ETH, and KOINOS and then propose a new model which, while not perfect, may make a better set of tradeoffs.

Measurement Overhead

There is a cost to everything, even measuring resources and collecting payment. For example, platforms that leverage Objective CPU billing (ETH/KOINOS) must count the total number and type of instructions and then look up the cost of each type of instruction to produce a deterministic price. This is an imprecise science because no cost model accurately reflects the actual cost of operations. This means that a certain percentage of limited CPU resources is utilized to produce an approximate but certainly inaccurate measure of how much to bill someone for CPU.

Given that CPU resources are among the most scarce of all resources, the objective measurement of resources could consume a meaningful percentage of resources that could be used for other things. This ends up increasing the total cost of resources in a system due to scarcity.

The alternative approach, subjective CPU billing (EOS), relies upon trusted oracles to report the real wall-clock time each transaction takes to run. This reduces CPU overhead from measurement and has the potential to more accurately account for CPU time; however, it comes at the price of trust. Different computers will take different amounts of time, and the same computer may take a variable amount of time depending upon other background tasks that occur simultaneously. This subjective approach introduces errors in measurement due to random noise, similar to how the objective approach fails to model the noise.

In doing work on database design, you learn that CPU time is often linked more to cache hits/misses than to actual instructions. The same set of CPU instructions can take 1000x more time depending on which memory regions they attempt to access. To resolve this problem, an objective billing system would have to error on the side that every memory access is a cache miss, or an attacker could construct a transaction that intentionally takes 1000x longer than the objective model because it tries to access memory in the least cache-friendly way imaginable.

Billing Overhead

Once a network has measured the resource cost, it must still find a way to charge users. This can take the form of a direct fee (ETH), pre-paid resource budgets (EOS), and token-based rate limiting (KOINOS). Each of these approaches has some overhead both from a technical perspective (CPU/RAM) and from a cognitive perspective (micro-payments/usage estimates by users).

Minimizing the technical overhead of billing means aggregating billing and not keeping a full history of all fees paid. On Ethereum every transaction includes a gas limit and a gas price and changes the user’s ETH balance. To faithfully represent your account balance, all transactions of any nature must be listed because they impact your ETH balance.

The Ethereum user has the cognitive challenge of estimating gas usage (which may change according to other users’ transactions), estimating the maximum gas (underestimating could result in paying a fee for nothing), and estimating a price which will result in timely inclusion in a block. All of this is sufficiently error prone that people have accidentally paid millions in fees in a single transaction. User interfaces must develop complex tooling to assist the user in setting these parameters on every transaction.

KOINOS needs to track regeneration time, mana delegation, and other properties, while users need to keep track of their recharge rates, dynamic cost of resources paid in mana, and estimate usage. Mana, being distributed on the basis of holding liquid tokens, will reward exchanges who then sell their surplus Mana to be used by others. This drives up the cost of resources in Mana and increases the number of KOINS users need to hold to generate enough Mana to transact regularly. While I am unfamiliar with all of the inner workings of KOINOS; however, the ability to sell/lease/delegate Mana will likely force most users to buy/rent/pay-for-delegation Mana because of the capital costs (holding KOINS) may be too high.

Everything Comes with a Price

What we learn from the existing systems is that spam prevention requires someone to pay in some way for resources. These costs can be obfuscated in various ways, but they cannot be eliminated. In systems like EOS and KOINOS, the cost of transacting is hidden in the capital cost of holding tokens. EOS makes people stake into the future (giving up liquidity), and KOINOS gives people credit for holding in the past. Stated another way, KOINOS does just-in-time short-term staking on exactly what is needed. “Mana” then must be regenerated. Users aren’t “locked in” because they can always sell, they just don’t get resources until they have held long enough to generate “Mana”.

Because Mana and EOS staking allocates resources proportional to tokens, you require 1% of the tokens to utilize 1% of the network. You quickly discover that doing even a small number of transactions requires thousands of dollars worth of tokens. Even though no tokens are consumed, the user is taking economic risks with daily fluctuations producing capital gains and losses of hundreds of dollars, not to mention the cost of tax reporting. All told, this prices most users out of the market and forces them to lease resources from others.

Because Koinos Mana doesn’t require staking, the majority of the Mana will be generated by exchanges, which may “delegate” it to users who pay for it. The net result is that while the resources may “appear free” for people who would be holding a large number of tokens anyway, the vast majority of potential users only want to pay the incremental cost of their individual transactions. This means that instead of being “gamified” and “automatic,” Koinos users who don’t hold many tokens end up having to pay the cognitive and resource overhead of paying someone to delegate Mana to them. Worst case, the technological overhead is incurred for every transaction. Best-case the user pre-pays one time for a certain amount of delegated Mana.

One of the nice things about the KOINOS model relative to the EOS model is that users only have to manage a Mana balance, and the network will automatically interact with the CPU/NET/RAM markets to buy just what is needed. This is a significant improvement compared to EOS, where users have to think about the proper ratio of these different resources when leasing from the network.

Lessons Learned

No matter what staking system one employs, the cost of capital is far more burdensome for the vast majority of users than the incremental fees they pay to lease resources from those with capital. We also learn that users shouldn’t have to think about the separate resource types (RAM/NET/CPU) and instead should only have to concern themselves with a single number: the combined economic cost. We have also seen that forcing complex “resource-delegation” markets to emerge just adds to the technical and cognitive overhead of the larger system.

Therefore I propose that an ideal system would work similarly to modern toll roads where users attach a credit card to a pre-paid balance. As the user drives over the roads, the balance is automatically billed against their pre-paid account. This saves the technological overhead of running a credit card transaction at every toll. The toll road operator automatically adjusts the fees based on traffic conditions, and there is no way for speculators to bid up fees or speculative lockup storage for a profit.

Objective billing would charge users by the miles of road traveled regardless of how fast they drove. Subjective billing would charge users by the amount of time they actually spent on the road.

Whether you employ objective or subjective billing blockchain governance is required to adjust the fee schedule or to hold oracles accountable for host reporting of CPU time. The end result for most users is that they trust their user interface and network operators to fairly bill them and go about their day. Whether they use Amazon Web Services, the local Toll Roads, their gas station, or their utilities, people are used to the idea of trusting the services to bill them monthly and automatically.

Propose Resource Model

Users pre-fund their “gas tank” with tokens at a 1:1 ratio. When they transact the network calculates the exact amount of CPU/NET/RAM usage and buys just what is needed from the internal resource markets. No one else can buy/sell/speculate on these resources because they are only an internal accounting system to calculate how much “gas” to take from the tank for each transaction.

Like Koinos, users can simply have a small number of liquid tokens available in their account, and they don’t really have to think about fees too much. The system will automatically bill them for their resource usage. Each user can pick how big of a gas tank they want and the threshold at which it should be topped off.

Gas is always one-way pegged to the network token. Once a user fills their tank, they cannot sell their gas to get the token back. Think of it as buying a gift card that cannot be sold back to the company but can only be used to buy its services.

This makes it easy for users to buy gas for other users without having to worry about them selling the gas to buy booze. It allows smart contracts to contribute gas to users without having to track the state of delegation, revocation, etc. It means when new accounts are created and pre-funded with some gas that there is no need to worry about people cheating the Sybil attack mitigations to profit from selling the “free” resources.

Preventing Squatting

One of the challenges with storage is creating incentives to free data without simultaneously creating an incentive to squat. If the price of storage increases with use and users can get money back at the higher price by deleting data, then some users will store empty data today, push the price up, and then delete that data in the future for a profit. This transfers profit from the community commons to private hands. Therefore, I propose that the refund provided by deleting data be 50% of the cost of buying data. A speculator would only profit if the price of resources were to double between the time they started squatting and when they released it.

Furthermore, the refund from freeing storage would go into the gas tank (store credit) and could not produce economic gains. Such a speculator would have to set up a smart contract that subsidizes user transactions, and other users would have to utilize custom interfaces that integrate extra calls into every transaction. The added CPU/NET/RAM costs would further erode potential profits by attempting to resell your “gift cards refunds”.

The final result of this model is that all resources are priced based upon current demand, users never have to think about fees any more than they think about their electric meter and fluctuating electric rates, and no private interests are profiting by squatting on and reselling community commons.

Eliminating Shadow Billing

Shadow billing was introduced to EOS to mitigate spammers of failed transactions. On EOS, a failed transaction cannot be included in the blockchain, and therefore, the spammer cannot be billed. To halt this spam, every node maintains a local accounting of how much time was spent on failed transactions by a particular user, and will silently drop transactions over the limit. Frequently users will see things fail and keep trying, again and again, to only dig themselves further into a hole. After 24 hours, the shadow billing clears, and the user is typically frustrated and leaves.

Since EOS already trusts its governance process to produce trusted CPU billing times, it would be a small change to allow them to bill for failed transactions. Unlike blockchains that give fees to miners (Ethereum), the block producers have little economic interest in intentionally failing valid transactions just to collect a fee. With good governance, bonded block producers, and maximum fee limits, failed transactions could be objectively accounted for.

Furthermore, if one producer marks a transaction as failed, it doesn’t prevent a subsequent producer from including it (assuming it is indeed valid). In this case, the producer who marked it as failed would be billed a multiple of what they billed the user.

With this approach, users can get solid feedback about all of their transactions, successful and unsuccessful, without mysteriously dropped transactions.

Conclusion

Resource models are a challenge on every blockchain. I hope that this new perspective gives the EOS, KOINOS, Hive, and Ethereum communities some ideas on how to improve their model and produce a lower overhead, easier to use, and cheaper resource experience for their communities. The new blockchain by fractally will incorporate most of these ideas along with some other enhancements to be revealed in the coming weeks.