Could we make L2s RC-powered on HIVE ?

in HiveDevs3 months ago

As some of you might know, I'm (slowly) working on a collection of four semi-interrelated open source projects, two of them exclusively for HIVE and the third aimed eventually at the wider Web 3.0 and utility chain space (basicly any chain where long-usage keys are part of the core design), and I'm carefully contempating adding a fourth project. Carefully, because all of my projects are virtually unfunded and I need to use most of my time on activities that do help pay my bills, that for relationship status reasons, lets just say have been a bit higher than they should be.

Now my potential 4th project wouldn't be anything too complete, just complete enough to have some utility and to be a proof of concept post-quantum-ready L2 usefull enough for some of you guys to want to run a node, that demonstrates that two of my other projects are good enough to scale to actually build such a thing.

One thing I ran in however when thinking about this potential L2 that currently only exists in my mind (a small-storage redundant least-authority file-system on top of the main HIVE chain with a possible minimal side-chain that maybe I can avoid if I think it through better).

In my previous post I was sloppy with the terms L2 and side-chain and used them interchangably, thanks for pointing that out guys (m/f/...) I'll try to be more carefull in my wordings from now on. It's an important distinction because what I hope to discuss might make it much more viable to build an L2 without the intrincic need for a side-chain.

This post however isn't about any of my project, it's about incentive. That is, if I or any other software engineer builds and open sources an L2 for HIVE or any other chain for that matter, the 'because it's cool' incentive isn't likely to get many people tu run a node. L2's and side-chains tend to come with their own incentive model that in a way kind of clashes with the core philosophy of the main chain that since the introduction of Resource Credits has basicly been about the user experience that is stake driven, and under the hood has basicly been something of an RC driven economy when it comes to user interaction with the chain.

It thus feels to me there might be something missing. A built in pluggable RC link between L1 and L2.

image.png

I hope this post can incept some discussion and thought by some of the devs on here, if this post manages to reach any of them, because it feels kind of important. If we can manage to make such a link, it might help make HIVE a much richer ecosystem where L2s are much easier to build because without the need to create a node running incentive, an L2 might be much more likely not to need to implement a side-chain, and at the same time the interaction of the user with the L2 would remain much more in sync to that of L1. Hope I'm still making sense.

A custom_json with L2 tax.

Mutating operations that the user does on the chain all come at a price to the user. Users with very little stake will be limited when doing even the most basic of tasks, users with a signigicant amount of stake are able to do expensive operations like claiming account creation rights that smaller stake accounts can't gain access to. This is because operations are funded with resource credits and stake level determines how much RC a user can gather and how fast it automatically replanishes.

Right now, operations like custom_json and custom_binary are used by L2s, but L2 nodes d aren't in any way involved in the whole RC economy right now.

But imagine they could be. Imagine a group of L2 node owners can come together and claim a unique L2 identity and bind that ID to their node-associated HIVE accounts. This part will need some considerations because node operators arent a static set, so there will need to be some serious design done for that part, I'm not claiming it is easy. But when that part is sorted, imagine that HIVE introduces two new broadcast opps:

  • custom_json_with_l2_tax
  • custom_binary_with_l2_tax

Now imagine this operation takes one exta parameter: The L2-ID we just mentioned. Now if the cost of this operation, as the name suggest would have a second part to it's RC cost, namely an L2 tax, the L1 could distribute these resource credits to the node associated accounts.

This redistribution of RC could help the nodes themselves in funding their L1 broadcasts, and if not capped to a value determined by the stake of the node accounts, could be used to fund goveted expensive operations like claiming account creation tokens, that could come in handy when running an L2.

Can we have a debate?

I know the whole idea is kind of rough right now, and I know my reach with my posts is relatively low, but I think the core idea could really have massive value for HIVE. I'm hesitant to tag in people because its a bit spammy and likely the idea is a bit rough, but still I think it would be worth debating.

But if any of you reading this agrees with me and feels it is a subject worth debating and exploring, please tag in who you think are those that should be debating this, and let's see if it is a concept that should be further developed and maybe proposed to the top witnesses and core devs, whatever procedures for that are.

Sort:  

I feel called on to the board.

I find the idea of using RC as a form of incentive weird considering RC "value", both current and historical. There is no "RC economy", operations on chain are basically free. It only serves as a safety mechanism, to prevent individual users from attacking the network. In practice most users never run out of RC, even rank 0 (free) accounts drop their RC level dangerously low in less than 5% of cases. For rank 3 accounts (minnows, like me) that are dominant in on chain activity, it is not even half of basis point.

curl --request POST --url https://api.hive.blog/ --header 'Content-Type: application/json' --data '{"jsonrpc":"2.0","method":"rc_api.get_rc_stats","params":{},"id":1}' | jq ".result.rc_stats.payers"

It is not to say that everyone can do everything. Some operations, even posting lengthy article, can be too much for free accounts, to create new account you need to be at least rank 1 (but many people graduate to rank 1 after claiming rewards from their introductory post), to think about claiming free account tokens you need to be rank 4 (dolphin).

Free account tokens are pretty much the only thing that has some monetary value and could serve as form of incentive. The problem is, it would be unsustainable if actually used. Even now the account token resource pool is kept between 5 and 10% of the equilibrium level.

curl --request POST --url https://api.hive.blog/ --header 'Content-Type: application/json' --data '{"jsonrpc":"2.0","method":"rc_api.get_resource_pool","params":{},"id":1}' | jq ".result.resource_pool.resource_new_accounts"

When one is claimed, it takes 13 blocks to fill it back to the same level. Such low fill level makes the price very volatile. Especially considering that it is cheaper for whales to claim them in bulk (because the price only changes at the end of block, so if you claim 100 at a time, all 100 will have the same, lower price). So you might occassionally see it for 10T RC (cheap), but next block the price can shoot up to 3 times that. Also if you consider that RC is a manabar - "use it or lose it" - if you don't have max RC large enough to hunt for reasonable price, you might be forced to claim tokens when they are (relatively) expensive or "waste RC regeneration". If more people started to claim the tokens, their price and volatility would only increase. All that makes free account tokens pretty lousy incentive.

From technical standpoint channeling part of RC cost from transaction payer to some other account should not be very hard to do, however in my opinion it would make more sense (if ever) after introduction of RC pools because a pool is designed to be constantly drained, so it has higher chance to have "free space" to add external RC. There is also a blocker - RC is not (yet) part of consensus, so adding changes to consensus protocol for RC is a no (like adding new operations).