Stake directly from wallet via staking pool contract and participating nodes

[polymorpher]

Since #9 might take a few more weeks to implement at https://github.com/harmony-one/harmony, my thoughts on a poor man's version of staking support are summarized as below.

1. (Upon the press of a button on the UI) ONE Wallet users will transfer ONEs to a staking contract which acts as a staking pool. The contract will record contributions from each wallet
2. The staking contract will also record a list of participating nodes who are required to put down a deposit to participate.
3. The nodes may set their own fees for participation. The fees will be rewarded to the node and are a percentage of the payout of the staking/delegation reward from the node.
4. Once in a while (exact time period is to be determined), if the accumulated user contributions reach a minimum threshold, the ONEs will be distributed and loaned to participating nodes based on their credit limits. The credit limits are defined below.
5. The credit limits of a participating node are maintained on the staking contracts. The limit for each node is the amount of deposit by the node, plus the sum of historical fees payout via staking participation. As a result, this limit will grow over time and incentivize good behavior and long term participation from participating nodes. The limit also ensures bad behavior from new participating node would not incur damage. The limit also makes it potentially more rewarding for the nodes to put down the deposit and participate, compared to just use the deposit and stake/delegate on their own.
6. The nodes are required to stake or delegate the distribution loaned to them and report back to the contract.
7. The participating nodes may vote to remove and ban a node if the node fails to fulfill its duty to stake/delegate, and report. The removed nodes' deposit is forfeited, and is paid back to wallets (not participating nodes).
8. A node may withdraw from participation, and it must return all payout via staking and delegation to the contract minus its fees, before it can get back its deposit.
9. A wallet user may withdraw its stake, and the contract will pay a variable-rate staking reward set periodically by consensus from the participating nodes.
10. The contract may require the participating nodes to furnish additional deposit to replenish the decreased balance due to a user's withdrawal. Nodes failing to comply may be removed from the pool and have its deposit returned.

As a simplified version, we may start with only one participating node and leave all the voting mechanisms for later implementation. This simplification will also make the staking contract very easily to implement. The node essentially will be a trusted node holding all staked funds from wallet users. It may be sufficient until total wallet balance becomes high, and the usage of this feature becomes significant enough.

[ivan-homoliak-sutd]

It is not clear how will be nodes added to the list. Can anybody make an entry and act as a delegated staking node?

• If yes, then one entity might get multiple entries and dominate the voting process.
• If not, assuming that some voting is required, then why would existing nodes opt to decrease their relative staking share by adding a new node to the contract?

7. • it would require service on each node that would continuously check other nodes and their correct staking while reacting in the case of misbehavior (sending some slash vote tx).
8. • it seems that most of the conditions you mention cannot be validated by contract, and it would need to use the voting and approval by a majority (possibly weighted by their deposit).

Minor comment: the whole design should be denoted as a delegated staking.

[polymorpher]

I think we shouldn't just allow everyone to automatically become a node at the beginning. There should be a quick approval process by voting. Existing nodes are incentivized to add new nodes because that increase the total capacity of the nodes. Note that a note cannot get more shares from the pool than their credit limit, and their credit limits are determined by the deposit they put in and the reward they accumulated so far. If there is too few nodes (and too little deposit) there would be too much left-over in the contract's pool, left un-staked.

Yes, most conditions cannot be validated by the contracts. There is simply no opcodes that allow us to query the state of the blockchain with respect to staking, and/or any historical transaction. That's also why I highly disfavor this design (hence calling it a poorman's version) and would rather wait until #9 is implemented. But I was told it is going to take at least 2+ more months.

It is not clear how will be nodes added to the list. Can anybody make an entry and act as a delegated staking node?

• If yes, then one entity might get multiple entries and dominate the voting process.
• If not, assuming that some voting is required, then why would existing nodes opt to decrease their relative staking share by adding a new node to the contract?

1. • it would require service on each node that would continuously check other nodes and their correct staking while reacting in the case of misbehavior (sending some slash vote tx).
2. • it seems that most of the conditions you mention cannot be validated by contract, and it would need to use the voting and approval by a majority (possibly weighted by their deposit).

Minor comment: the whole design should be denoted as a delegated staking.

[ivan-homoliak-sutd]

So, to me, it means that there is no fixed total reward per block that validators "compete" on. (If there would be, the nodes would not decrease their relative chance of earning it by adding new nodes.) Instead, the total block reward is given by some linear function dependent on the total state => the more total stake, the higher block reward, and vice versa.

Because Harmony has capped total supply, it should not impact inflation long term; it might impact it only short term since the speed of mining is increased.

Is it correct?

[polymorpher]

This is superseded by new smart-contract staking mechanisms described in #9 (comment)