Direct RC delegation tentative spec
direct rc delegations would act as a way for users to delegate max rc directly from one user to another.
implementation:
would be implemented via as custom_json op signed using posting auth that would be picked up by the rc plugin.
auth
Even though it makes more sense from a security standpoint to use active auth, I suggest using posting authority to allow people to run services to allow to "trail" delegations and thus simulate the effect of pools where multiple people can contribute to the same delegation.
see the limitations section on how we can enable RC delegations via posting auth without it being a risk for people to be locked out.
New objects and operation definition
proposed op: delegate_rc_operation
(open to suggestions to integrate the idea of "direct" in the name)
account_name_type from;
account_name_type to;
uint64_t max_rc = 0;
extensions_type extensions;
proposed new object to represent a delegation: direct_rc_delegation
or rc_direct_delegation
account_id_type from_id;
account_id_type to_id;
uint64_t delegated_rc = 0;
proposed changes to rc_account_object
:
Add a new field to track how much RC was delegated
uint64_t delegated_rc = 0;
And a new field to track how much RC the user is delegated to
uint64_t received_delegated_rc
or received_rc
I'm on the fence on using asset here for both of these fields, I think it makes little sense but would be more consistent with max_rc_creation_adjustment
(the rc you get from burning hive/an account creation token) it makes sense for this one to be an asset because it's directly linked to the ratio from hive to RC (since the fee is an asset). But here we directly delegate RC. I'm open to both.
this field would be used in get_maximum_rc
to substract it from the maximum RC
limitations:
You can't delegate max_rc if you don't have current_rc to match it
We only allow to delegate current rc. This means that if you have 100 max_rc but only 50 current rc, then you should only be able to delegate 50 RC, We definitely could enable delegating max_rc easily (the delegatee gets 100 extra max rc and 50 extra current rc). But I feel like we want to take an MVP approach to this where it's the simplest solution possible and I'm not sure if this feature will be needed all that much considering the usual use cases being account creation and helping a user that is out of RC. And worst case it would be pretty easy to add the feature later on.
You can't delegate your max_rc_creation_adjustment
A user should not be able to delegate max_rc_creation_adjustment
, this is his base RC that acts as a security to always let people undelegate in case they made a mistake an delegated too much RC or if they delegate almost all of their RC minus the cost of a custom_json in order to undelegate one day and then the cost of custom_json goes up, effectively locking their accounts unless they power up or get RC delegated to them.
When undelegating/updating a delegationg, you don't get the current RC back
first reason is that it simplifies the implementation and also protects us from a possible edge case exploit where you can get free RC (that was the case on RC pool until I fixed it).
There is also the case where it kind of force us to track individual delegations, otherwise you run into some cases where there is unfairness upon undelegation:
eve delegates 50 rc to bob
bob uses the 50 rc
==if eve were to undelegate now, she would get 0 current_rc back.==
alice delegates 50 rc to bob
eve undelegates and gets 50 current_rc even though it's not technically hers because those are the current rc delegated from alice.
And now if alice made a mistake and wants to undelegate, she lost her RC.
Ultimately I think it's a pretty minor issue I don't mind refunding the current_rc or not doing it.
You can't delegate delegated RC
It would make a lot of things complicated very quickly and we don't want to deal with the extra complexity to the chain and deal with cases where one person undelegates and 5000 accounts have to get updated.
three paths:
create: max_rc > 0 and no delegation to this user exists
(I skip basic checks like does the user exist etc for clarity's sake)
- check that the delegator has enough current RC to delegate.
- create a
direct_rc_delegation
object - update the delegator
rc_account_object
to increasedelegated_rc
with the amount delegated, update manabar to reduce the current_rc and max_rc - update the delegatee
rc_account_object
to increasereceived_delegated_rc
, update manabar to increase current_rc and max_rc
update: max_rc > 0 and a delegation to this user exists
We allow users to increase of decrease a delegation
if the delegation increases:
check that the delegator has enough current RC to delegate the delta (new_delegated_rc - currently_delegated_rc)
- update the
direct_rc_delegation
object - update the delegator
rc_account_object
to increasedelegated_rc
with the amount delegated, update manabar to reduce the current_rc and max_rc with the delta - update the delegatee
rc_account_object
to increasereceived_delegated_rc
, update manabar to increase current_rc and max_rc with the delta
if the delegation decreases
- update the
direct_rc_delegation
object - update the delegator
rc_account_object
to decreasedelegated_rc
with the amount delegated, update manabar to increase ONLY the max_rc with the delta - update the delegatee
rc_account_object
to increasereceived_delegated_rc
, update manabar to decrease current_rc and max_rc with the delta
delete: max_rc is 0 and a delegation to this user exists
- update the delegator
rc_account_object
to decreasedelegated_rc
with the amount delegated, update manabar to increase ONLY the max_rc with the amount of thedirect_rc_delegation
object - update the delegatee
rc_account_object
to increasereceived_delegated_rc
, update manabar to decrease current_rc and max_rc with the amount of thedirect_rc_delegation
object - delete the
direct_rc_delegation
object