Fractally's Better Blockchain Resource Billing System

in #fractally2 years ago

BetterResourceBilling.png

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.

Sort:  

Thank for highlighting the issues we face concerning the critical infrastructure, namely, the building in of an equitable cost and fee system, to allow the consumers and providers to maintain efficient computer networks, with fundamental transparency to the consumers. Way to go Dan.

Unfortunately you missed HIVE RC methodology while comparing with other chains. Looking forward to read your review of that & your upcoming project (a new chain) as well.
$WINE

Cheers~


Congratulations, @theguruasia You Successfully Shared 0.100 WINEX With @dan.
You Earned 0.100 WINEX As Curation Reward.
You Utilized 1/3 Successful Calls.

wine_logo


Contact Us : WINEX Token Discord Channel
WINEX Current Market Price : 0.168


Swap Your Hive <=> Swap.Hive With Industry Lowest Fee (0.1%) : Click This Link
Read Latest Updates Or Contact Us

Was wondering too about HIVE resource allocation: why HIVE does not seem to have these problems that EOS had regarding resource allocation. It is based on similar principles as EOS after all (resource ownership instead of leasing). I think it is simply because Hive does not have smart contracts - no need to measure CPU time. CPU is probably the resource that's the most problematic for EOS.

That image looks like i dunno, US Mexico tijuana border, with project odion, face recognition

FROM RAYTHEON INTELLIGENCE AND SPACE< the OPTICAL DETECTION INTELLIGENT NETWORK lol

image.png

image.png

FACE ID FOR THE HOMELESS! EDENOS!

toll management!
https://www.vice.com/en/article/wxdp7x/tech-firm-facial-recognition-homeless-people-odin

image.png

Very interesting read!
My impression is that you have found some interesting ideas to borrow from Koinos, which is good!
I agree with you that in the future, depending on the congestion of the network, you probably will require hundreds of mana in Koinos in order to make some transactions, and in this case people will have to buy mana delegations from others, so like paying a fee for the tx.
I think this is normal. Nothing wrong with that, if the network is really congested you will need something to prioritize your tx over the others, like paying for it.

The community can also decide through governance to increase the hardware requirements in the resources contract (no hardfork required) in order to reduce congestion and then reduce the mana requirements for users. However, this comes with the cost of lower decentralization because less miners will be able to reach this hardware requirements.

There is one topic that you didn't explore and I think is very important when designing economic incentives for spam mitigation:
It's true that eventually in koinos the exchanges will drive the mana market. However, on EOS this is driven by stakers. So the stakers have profits for mining (pay per vote) and for using the network resources (pay for use). This could end up in a wrong economic model like the famous Eidos contract on EOS, where there is no incentive to reduce spam. On Koinos is different, you have to select between profits for network resources (mana delegation) or profits for mining (burn your koins to get virtual hash power). So here you have an incentive to not spam: which is take profits by mining.

I like your article. Looking forward how you will design the economic model of Fractally.

A lot of good ideas.
Yes simplifying the UX for the user and internal accounting is good.

How will the token price affect the resource costs? I feel the cost of blockspace in many crypto networks could get too high in bull markets (eg. ETH) and resource cost volatility is a major problem. The closer the total resource cost is to the actual costs of BPs & node infra the better. Thanks.

Costs are based on the % utilization and all else being equal a rise in token value is a rise in price of resources, but if that results in a fall of demand for transactions then resource prices will fall. In other words the real cost of fees is independent of the token price and entirely dependent on demand.

High demand and high token prices are correlated but not linked.

Great! Thank you Dan for sharing your vision. The billing problem is vital for mass adoption and we have learned important lessons from EOS/Hive blockchains.

The new vision/model makes me even more confident that the coming Fractally blockchain will be the best platform to build new generation of dapps.

перевод статьи на русский язык - https://hive.blog/fractally/@shakhruz/uluchshennaya-sistema-billinga-stoimosti-resursov-v-blokcheine-fraktalli

а также другие новости по Фракталли на телеграм канале - https://t.me/ashirov_public

@dan dont mention koinos lol thats not a thing

Mention telos and its governance its like super eos ...its the most impressive steemit like eosio chain .... and mention wax .... edenos should be wax nft hypernerf selfie gif login then eos smart contract then hive social media posts then telos governed dstor hosting

Love the idea of not getting users think/worry about amount of resource they need. It was quite challenging with EOS. Proton chain (an EOSIO chain) have manage to solve this issue by offering a smooth UX when using any Dapp.

I think there's some improvements here, but it seems like you're focusing on

1. Spam transactions

Sure, they can be bad. If they are phishing. But most users don't mind getting airdropped tokens they don't pay ram for.. REX was a problem, but the original resource model was the real problem. Why would 1% of tokens = 1% of resources? Why not charge for the the resources actually used per block, and make a percentage of available resources be available to a percentage of the people actually using the resources?
The truth is, SPAM makes blockchains look good, as it flexes the TPS and the TX per day. No interested stake holder goes back and checks the actual TX log before investing or as a part of their onboarding experience. Try focusing on what you WANT TO HAPPEN, not false evidence appearing real.

2. Preventing RAM hoarding

Again, this isn't a real issue. Speculation on any market is to be encouraged, or at least understood and molded into a beneficial practice.

There's another approach where you allow a user to allocate any amount of RAM to be reserved for them, and then automatically sell that ram (or 50%) if the price goes up 2x. This is perhaps not a good idea, but FOCUS ON THE SOLUTION, what you WANT TO HAPPEN. What we want to happen is affordable RAM prices. Deeper, what we want to happen is people have the RAM to do what they need to do. Focus on that. I can provide suggestions.

Also, ask for some help.

You are destroying all your systemic designs by focusing on small negatives instead of further developing the goodness.

Charging TX fees is about the biggest step back I can imagine. The little gas tank is better that wasting time and money with Power Up, but it's a huge step away from the right direction.

You find the right direction by figuring out what's working and accentuating it.

Please ask for community help. I'm not the only one jumping up and down waving my arms trying to help you. You aren't the best. I'm not the best. Together we are the best, only if we recognize and HONOR eachother's value and ideas.

Speculation can be supported by contract for difference without artificially locking up real resources.

 2 years ago  Reveal Comment

Soon youll get to login to hive with eos

Also dont act like this is a gang or cult

It doesn't matter tho, if we wanna see the adoption happening we'll build bridges between different communities. That's the only way