RC delegations: Current development status and request for feedback

in #rc4 years ago (edited)

social_hive_revolution_dark.jpg

Hello,

First of all if you haven't already, please check out my proposal for blockchain development on hivedao: https://hivedao.com/proposals/97

This the kind of posts that I want to do now and then on chain to gather some feedback and ideas about features and ongoing hive core work.

So here's some history on RC delegations, it's a feature that was worked on over a few years by the steemit team, and was supposed to ship with the smt hard fork, I figured this was a very important feature to have asap and we shouldn't wait on smts to have it. The problem is that the code is quite different between the SMT branch (where smts are done) and the main branch (the one that powers the chain right now).

When the steemit team said "SMT development change almost every element of the chain" they weren't kidding. So the challenge was to extract the code and then adapt it to work without the rest of the SMT code. Which can be quite tricky as I had to dig up some changes that were made back in 2018.

Then I realized that there was some bugs, so I set out to fix them and finally I got a working proof of concept.

FYI: it won't go live for hf24 because we don't want such a big change in hf24 and also there's some discussions to be had and potentially modifications to be done depending on your feedback.

Here's currently how RC delegations work:

Pools

Each account got an RC pool in his account, anyone can delegate to any account pool, that RC won't be usable by the account, it's just a pool he can delegate RC from. (he can delegate to himself if he wishes).

RC slots

There is a notion of delegation slots, each account got 3 slots from which they can receive delegations. meaning they can receive rc from at most from 3 pools, also, each slot can only receive from a specific pool. If you are not "whitelisted" you can't delegate to an user.

By default:
Slot 1 is set to the account creator of the account, and only the account creator can change that slot
Slot 2 is set to the recovery account, and only the recovery account or a top witness can change that slot
Slot 3 is set to null, and the account can change that slot.

it may seem a bit odd how the user don't "own" 2/3 of his slots, but it's designed in order to offload the complexity (setting up slots etc) to power users (witnesses/account creators/recovery partners) instead of putting that burden on the user.

Most of the use cases for rc delegations are linked to account creation anyways, and that use case is handled by default, then there's games or other operation intensive applications and those could have a button to "ask for rc delegation" that would make the user set his personal slot to the game and then the app would delegate to it.

It's worth noting that if you change your slot, you lose your previous delegation on that slot.

Oversubscription

Pool work on an oversubscription model: (thanks @vandeberg for the explainer)

Let's say Alice delegates 100 RC to an RC Pool.
That pool can then delegates 30 RC to Bob, Carol, Dave, and Eugene.
There is a total of 120 RC delegated, but only 100 RC in the pool.

Is that a problem? No.The implementation allows each of the out delegations to use up to the delegation's worth of RC, but that is charged to the pool.

If Bob uses all 30 RC and no one else does, Bob will no longer have access to RC from the pool until his regenerates, even though to pool still has 70 RC available. However, if Bob, Carol, and Dave all use 30 RC, then Eugene will only be able to use 10 RC before he cannot access any more.

Although he has RC still available from the delegation, because the pool ran out of RC, Eugene does not have any to use.

This is useful for this use case: Large stake holder making many small delegations, such as Steemit delegating to new users via the faucet (back when that was a thing). Users will consume their RC, but because not all users are retained, this can be significantly over subscribed.

Another real life example:

  • Alice delegates 50 rc to her pool
  • Bob changes it slot 3 to Alice
  • Alice delegates 30 RC from it's pool to Bob (Bob can now use the RC)
  • Alice tries to delegate to Eve, but since she didn't set a slot to Alice, Alice cannot delegate RC to it

FAQ:

Will this affect the current hive power delegations ?

No it will stay the same

If I delegate hive power to someone then RC, which one is used ?

The RC used is in priority the account's own rc (hive power + delegated hive power), then if that's not enough, delegated RC is used.

It it possible to have to have multiple users contribute to the same pool ?

Yes.

How many pools can one account contribute to ?

40

To be clear an account can contribute to 40 pools, which will then be used to delegate RC to as many accounts as they want (way more than 40).

Let's say the same thing but with a soup analogy:
A user can contribute to 40 different pots, but each one of those pots can be used to feed as many people as he wants.

Does delegated RC regenerate like normal RC ?

Yes

Is it possible to Delegate from one pool to another ?

No

Feedback wanted

Now, question is, what do you think of that implementation ? Are there things you would change ? I am open to coding any changes. But keep in mind there are performance and complexity considerations to take into account (for instance that's why we don't have like 50 slots per account).

Some early feedback include allowing users to change all their slots if they want to, because a lot of slot 1 (account creator slot) would be blocked and never used since they are linked to the @steem account (including mine).

Questions ? Ask them below !

And again, please consider voting on my core development proposal here https://hivedao.com/proposals/97

Sort:  

It's overall a step in the right direction, but when I'd first heard of RC Pools I guess I was envisioning something a bit more automated and elegant. I'd imagine RC Pools tied to certain transaction types as opposed to individual user accounts, if such a thing is even possible.

I know that most (all?) posts contain some form of metadata that defines where the activity originated, as far as application, front end, tool, etc. I don't know if that's also true of voting activities. I feel that RC Pools should be tied to that information, instead of linked between each individual user account, which seems to still be a nightmare when scaling to tens and hundreds of thousands of users or more.

As an example, if Bob is posting his daily Actifit update, the system first draws from his own personal RC as is the case in what you describe above, if his balance is insufficient, it then draws from the Actifit RC Pool instead. Then Bob swings over to PeakD and makes a comment on a piece of art he really likes in the OnChain Art community. This RC cost is then auto picked up by either PeakD or OnChain Art. As a new user, Bob's experience is seamless, no requests need to be made for RC delegations, and the RC costs are being levied on the applications he's actually using. Otherwise, Bob may sign up through eSteem, get an RC delegation, discover SplinterLands, and spend his allotment of eSteem's RC on playing SplinterLands.

In the sort of system I describe, the three pools would essentially be relegated to different hierarchies of user, application, and community... quite possibly in that order of fallback. Applications and communities would ideally be able to set their own "rate limiting," blacklist certain users, etc. to control spamming and abuse of their RC. Applications could feasibly set a limit on both individual users and communities. In the example given above, PeakD may allow only 1% of their RC pool to be used toward any one community, ensuring a single popular community can't drain all their resources and harm the user experience. Then it's the responsibility of the community to power up HIVE and backstop with their own RC Pool to keep their members active and happy.

Communities are already tied to a singular account at creation that could serve as the RC Pool, Applications would have to have an account designated as their RC resource.

Whew. Hope that made some sort of logical sense.

Summation: Users should individually delegate into RC Pools of communities and applications that they want to support, but expenditure of RC Pools should be tied to transactions, not users, thereby removing the need to manage individual delegations across potentially millions of accounts. The minimal RC amount that all accounts are credited with at creation should be enough to ensure any new account can still make limited needed wallet transactions and other behaviors, while the heavy lifting of content creation and interactivity is automated on the backend and charged to the services being utilized.

That actually made a lot of sense, but there are a few issues with the system you are describing not taking into account the fact that it would require to rework the rc system to its core.

First there are currently no way of tracking some transactions and linking them to an app, there is actually a task for it somewhere. But it would be something like the "app" tag that we sometimes put in the post metadata, it's something that's useful for some UI changes here and there but shouldn't be used for important things like RC, because anyone can say "oh I am doing this post via actifit" even though it's not, and then steal RC from that pool, that could be solved by letting apps do some kind of signing on the transactions, but it complicates quite a bit the process.

And I disagree that it should be linked to transactions, because then nothing stops one spammer from using up all the RC and leaving the pool dry.

Without a doubt the biggest problem is that a system like I'm describing is ground up different than what's already in the works!

As long as pools can set automated rules on how their resources are allocated, I don't see the spam factor being problematic. Limiting accounts to (x) transactions or (x) RC per day would be sensible. It's a shame that transaction tracking isn't more robust, but it would certainly take a power user to tag their posts in such a way as to just siphon some RCs off an unrelated application. If you do consider that a serious concern, then that just speaks to the issue that primary front end applications are going to bear the brunt of RC costs, even when not used directly on their platform.

My main concerns are that it be pretty much seamless for new users to acquire an RC delegation, they shouldn't have to hunt for a frontend, application or user to provide it, request it, and wait for approval, and that applications can effectively manage their RC delegations. The pool as a "slush fund" of sorts with an attached ruleset is simpler than direct management of potentially millions of outgoing delegations, even if employing scripts and bots to help manage the task.

Side question:

Another real life example:
Alice delegates 50 rc to her pool
Bob changes it slot 3 to Alice
Alice delegates 30 RC from it's pool to Bob (Bob can now use the RC)
Alice tries to delegate to Eve, but since she didn't set a slot to Alice, Alice cannot delegate RC to it

In this example, are you able to differentiate in advance whether you're delegating to a user directly or their pool?

Each account got an RC pool in his account, anyone can delegate to any account pool, that RC won't be usable by the account, it's just a pool he can delegate RC from. (he can delegate to himself if he wishes).

For instance, even without Eve setting a slot for Alice to delegate RC to, can't Alice delegate to Eve's pool without Eve's consent, and then Eve can simply route it to herself?

What's the purpose of the extra "whitelisting" step? I'm not seeing the benefit for the added complexity. We don't force people to accept a Hive Power delegation which is more impactful as it conveys RC and voting power in tandem, so why the extra limitation on RC alone?

If I'm understanding the system correctly, my suggestion for the current slot allocations would be to change #2 to the user account directly, and have their personal RC pool potentially feed into that with no approval or as seamlessly as possible, such that when Alice tries to delegate to Eve, Eve will see the benefits immediately without the complexity of needing to reassign a slot.

This is litterally the first time Delegation Pools have been attemtped to be explained to most of us so bear with us/me as we ask some questions.


It appears one account can contribute to 40 pools.
But one application can make as many accounts as they want so the number of pools to manage can be pretty infinite and hopefully automated.

So how many users can share from a pool?

Also it appears from the 120RC delegated example with 4 users sharing from the pool that it seems like the limit is proportional? Because you said 30rc per user.

Does the pool limit per user have to be proportional? That sounds like RC was being set up to directly benefit the steemit system of allocating 15sp to each new user.

A non-proportional may lend to the apps (RC delegators) to be more attentive to RC abuse. Just not entirely sure of the reason for proportionality because so many users won't use their proportion allowing for lots more users to have RC but with proportional you kind of have to plan for the worst case user.

This is litterally the first time Delegation Pools have been attemtped to be explained to most of us so bear with us/me as we ask some questions.

Please feel free to ask anything, I made this post for that exact reason.


On the 40 account limit : the pool is not the end goal, I was confused by this too, basically :

may users can delegate to one pool, and each user can delegate to 40 pools max. The rc in the pool can then be used to be delegated to users, and then you can delegate to infinite accounts if you want.

Here's another example:

A,B,C delegate 30, 40, 60 rc to A's pool. A's pool contain 130 RC, but A can't use that rc to transact, A must delegate RC from that pool to users and then that RC will be usable.

Basically, the act of delegating RC doesn't happen when you contribute to a pool (40 per user), but when you delegate out of that pool (infinite).


Delegated RC out of a pool is not proportional, you can freely delegate 500 RC to one user and 3 to another. It's up to the pool owner to delegate whatever amount he sees fit.

OK putting RC into a pool may be complicated but really that's only a few people doing that. What we want to know is how to get the RC into the hands of users who do not have much RC>

We will see apps like ourselves and splinterlands putting a ton of RC into a pool for our users to use. Which will number into the thousands ... hopefully eventually tens of thousands (or more) users.

So i'm rereading what you wrote and it's not really clicking yet.
How does that part work. PeakD uses 100k SP worth of RCs. How does it go from there? Let's say there are 1000 users that need RC.

You delegate from the pool to each user let's say 100 hp worth of rc . And that's it assuming they have a slot set to steempeak.

In the coming days I'll post an example script, it'll make more sense for everyone if it's a more concrete example :)

I am glad you are working on this. Thanks! It is critical for mass onboarding without creating thousands of spam accounts.

It makes sense to me that all three slots should be able to be changed, but if it is going to add a bunch of work and delay things maybe that should be saved as a future update. Something now is better than nothing at this point in my opinion.

Since you mentioned this would not be in the next hardfork ... what is planned to be included in the next hardfork? I assume we don’t want to include RC delegations because there is a higher likelihood of it causing fork issues and we want our first Hive hardfork to go smooth for PR purposes?

As another note .... If the community had issues explaining HBD, Hive, and HP to newcomers, just wait until we get to explain RC delegations to them!! 🤯

Thanks for your feedback !

I wouldn't add too much work to let all three slots be changeable so that's fine.

In the next hard fork we'll likely have :

  • Chain id change (to truly set us appart from the steem chain)
  • Delayed voting (to avoid having exchanges powering up everything at once and then voting like they did before)
  • Some fixes on apis here and there
  • Changes on the sps to make it go from steem.dao to another account (@hive.fund)

On the complexity, the whole point of the way RC delegations are implemented where other people can set their slots, is to make it in order to offload the complexity to power users (aka the account creator / top witnesses)

Oh that's right! I forgot some of those changes, like the vote delay, have not gone into affect yet. It has seemed like Hive has been around for a long time, but it really hasn't. The quarantine has made me lose track of time and my mind.

Haha been there.

Can authors have their ten percent back now that the dev fund has ~90m hive?

button to "ask for rc delegation" that would make the user set his personal slot to the game and then the app would delegate to it.

Does this mean that RC pool can not delegate RC to any account they wish to? First the user would have to set the right slot, yes?

I think this is worth clarifying.

As I understand it, due to the slots arrangement, it wouldn't be possible to delegate RC's to accounts without them confirming this was OK for a slot to be used?

Think I need to read a few more times :)

That's exactly it.

Right. Sounds like it's best to get the RC's delegated from the off then with the new account creation, likely as you say in the post with button.

Will be interesting to see how it's worded by the dapps, I don't think we want 'agree to resource credit allocation' - 'allow to power your account'? :)

As a dapp owner myself, I would probably just tell them "want more rc ? click here" and everything would be done under the hood. Even better I could just delegate a lot to each users knowing some will use more rc than others and overrall the use will be okay.

Fair enough. I'm just not sure resource allocation or RC's are what new users need to hear/read. So the terms to say, 'let us kick-start your account with the ability to post, comment, vote' etc, would make more sense.

I've recently on-boarded a technical new user, and they are still blown away by the terms we pass around like everyone should know what they mean.

I tried to look for your proposal on peakd but couldn't see it? Would like to support, cheers.

Oh I think the actual flow for an account getting created would be

create account -> delegate rc to it -> if everything goes well user never feels restricted by rc.

And yeah complexity is a big problem, Before steempress with @fredrikaa we were thinking of building an onboarding tool that basically explains everything to you step by step and then creates an account for you and help you make your first introduceyourself post.

Thanks ! You can find links to vote here: https://hivedao.com/proposal/97 and on peakd I can't give you a direct link, but I am near the 12m mark

yep an rc pool cannot delegate to any account they want.

I know I'm a little late to the party, but I'm wondering why this very complex system is necessary. I think a much simpler system would suffice for the majority of use-cases.

I can see why the current system doesn't suffice. If you delegate HP, you delegate RC and voting power. This is a way of saying that you approve the actions of the user you delegated to. A large account creator can't check all actions of all their created accounts, so they can't trust them with their voting power. They do want to give the users enough ability to interact with the blockchain so they can start earning their power. That's where RC delegation comes in.

A probably much simpler way of implementing RC delegation would be to make it similar to HP delegations. You delegate a portion of your max RC to a single user. That user can use that RC to interact with the blockchain. Most required code can probably be reused from the HP delegation codebase. 1

This simplistic version indeed doesn't cover all use-cases that RC pools cover. As a dapp who provides accounts, you can't use community delegations to proxy to your new users. There's also no 'oversubscription', so the max RC delegated to the dapp users will be a lot lower, possibly low enough to run out. 2

On the other hand, this simpler system would allow every user to support any other user they want to support, without them spending an 'RC slot'. I have a mere 78 HP at the time of writing. That's not much voting power, but I never get below 80% RC. If I encounter a new user who brings great value to the blockchain, I am not in the position to delegate HP, but I would be willing to delegate some RC to them.

I believe that if we make it easy enough to delegate RC to others, there will be much less pressure on the account creator to provide the required kickstart RC. Instead, the community will be able to take care of most of it. The only problem that remains is blockchain games. Those systems usually don't promote new players to write posts and earn rewards before playing. That would require too much effort, so a dapp delegation is required. But I highly doubt that this single use-case justifies the complexity of this system.

Conclusion: I think this system is implemented to ease the life of large, singular entities, onboarding massive amounts of users while being irrelevant for small-medium accounts with sufficient RC. I believe that if we build a system that empowers everyone, small to large, to help out brand new users who make quality content, we can solve most problems those singular entities have while increasing decentralization, and decreasing complexity.

1 I can't say with certainty that this is a simpler system to implement. I only assume it is because of its similarities to HP delegation. Please tell me if I'm wrong here.
2 It is likely that I miss some use-cases. Some of them are not covered by the simpler system.

Direct peer to peer delegations have been thought of, and while it does bring a lot of simplicity, it also lacks a lot of the flexibility that pools bring (oversubscription), and when you think about it how often do you find yourself in a position where you want to delegate rc to people ? That happens very rarely for me as an user, as a dapp owner though that happens quite often when I create accounts (which is handled by design).

I think rc delegations will be something very few users will actually do. And if you want to contribute yourself to someone else, I bet there will be front ends to do it to hide some of the complexity.

And finally I envision that pools will be smart and always overdelegate because nobody uses all of their rc. So if you want to contribute to an user, you could just delegate that pool. Because in the long run, pretty much everyone will either have hp or be fed RC by a pool until they have hp.

My point is, I think there is a use case for direct delegations but it's a very niche one, and I don't think it's worth the added complexity of supporting both at the same time, or the time spent to undo the current system and make it a direct peer to peer one.

I think that one slot is enough anyway, why would you need delegations on two different slots? If you're a business that needs a lot of RC, then yeah, you might use the three slots but in this case, a business can easily deal with the complexity of that system. There is no need, to change the code too much if it is sound.

I just give an opinion because it was asked but I really think that you would have a better idea regarding what to do (along with other devs).

Thank you for your opinion :)

Well you might want multiple slots to recieve delegations from multiple actors, say 500 rc from the service that created your account and 1000 from that game that you love to play.

Aren't RCs usable across all Dapps? For instance if you delegate to me 1000 RC then I can use them anywhere, whether for PeakD, Splinterlands, or transferring to an exchange.

In that case, one delegation should always cover all needs unless the consumer of RCs is a big Dapp which needs 3 RC delegations from 3 big delegators.

Aren't RCs usable across all Dapps?

Yep

In that case, one delegation should always cover all needs

Well depends, let's say steempress has to create a lot of accounts, we probably won't delegate enough for you to post/comment 20 times per day, probably enough for 5-10 posts to get you started. And if you don't get hive power, you may end up needing more RC, and then you could ask another dapp for an rc delegation, because steempress won't have enough rc to give you more.

I see, thanks.

Is there a particular reason for the quantity parameter to be 40? What not 50, what not 25? (Kinda seems like an odd number to me)

I don't know why they picked that specific number, but I know the number of delegations is limited because of performance issues, so I assume they did their math and that number came out.

It's because I'm wondering if a max count is the best solution or a min size is a better solution.

A big account (1 million HP) might want to lend to 100 accounts. This account would have its HP into three accounts to do so. A small account could also do 40 delegations (let's say a 400 HP account) each 10 HP and tax the system too.

Ah I must have confused people with my explainer, see my reply to jarvie above, delegating to a pool is different from delegating rc to a user.

I'll add something to the post itself.

Sorry, my terminology was equally confusing. I meant delegating to pools not accounts. Like to a bunch of different communities for example.

Yeah I realize that now haha. Well I think 40 is a lot already, I don't think there will be that many dapps/account creation services. And even if there are, and the whale insists on delegating to all of them, the whale can make another account delegate hive power to it and then delegate rc to 40 more pools

Here is a direct link for @howo's proposal.

https://hivedao.com/proposal/97

What is the benefit to the account delegating the RC's ? Will it be just to support projects out of Goodwill or is there a Return on Investment? I's be happy to delegate either way, I'm just curious what the motivations would be.

This is a good proposal to say the fact but the issue I have here is that of the account creator that is still linked to Steem Blockchain that would be affected at the long run. I thought Hive is hard fork of Steem, why can't we create code to deal with that, although I know this would be tedious. But it's a good idea, because any idea to make Hive Blockchain a better chain is a welcoming idea to me.👍

hey bro you share a good info i will support you

Congratulations @howo! You have completed the following achievement on the Hive blockchain and have been rewarded with new badge(s) :

You made more than 1500 comments. Your next target is to reach 2000 comments.

You can view your badges on your board and compare to others on the Ranking
If you no longer want to receive notifications, reply to this comment with the word STOP

Do not miss the last post from @hivebuzz:

HiveBuzz - Hive Gamification Experience
Vote for us as a witness to get one more badge and upvotes from us with more power!