proposal: Dynamic Withess Participation

[tomasbrod]

Dynamic Withess Participation proposal (TomasBrod)

The main questions are:

• how to determine the subset of nodes
• secure voting on NN data
• who is allowed to stake the superblock

I propose a new superblock voting and staking mechanism. It works in three periods: registration, consensus and staking. The whole process including the stats block production is separate for each project. This is to prevent one misbehaving project to delay consensus.

Note that I intentionally don't talk about the actual contents of the stats data. It may be magnitude or credit delta, total credits, rac or something else.

Registration

Nodes that wish to participate must stake a standard PoS block before data gathering begins for a project. A public key (beacon key can be reused) is included in the registration stake. The ProofHash is hashed again with a constant and the registration is only valid, if this hash is less than a registration difficulty target, thus further limiting the number of registered nodes.
Invalid registration is still a valid block with valid rewards. Registration that is late for one period, automatically applies for the next one.

PH2 := H(C2 + ProofHash)
if PH2 < RegTarget then ValidRegistration

Some may see this as attempt to centralize magnitude calculation, but that is not the intention. Anyone has a fair chance to get selected for voting and production of superblock data if he manages to stake with the right proofhash. It is expected that the registration difficulty will be low so almost all coin stakes will be valid registrations.

Data gathering initiation

Data gathering and Voting for a project is started by a standard PoS block called initiation block. This block is only special if 14.5 or more hours (600) passed since the previous initiation block and a second
proofhash (PH3) is less than target. This PH3 is calculated like PH2 in the previous section, but with different constant (C3). Difficulty target for PH3 is set constant to 1/500. Probability of initiation block being already staked after specific amount of blocks is in the table below. This luck-factor is included to make data-gathering less regular.

Set of user beacons and registered nodes is frozen with the initiation block. After 6 more blocks, registered nodes start downloading the stats data network-wide at the same time. This may seem wrong, to initiate at the same time, but it is the only way to ensure the stats don't change much.

blocks since	probability
600	0%
800	33%
1000	55%
1400	80%
2000	94%

It is expected the moment of processing stats data will drift over time and allow nodes that are not 24/7 to participate. The values presented above are only suggestions. It can be changed to less-random or more random if necessary.

Consensus Voting

Consensus voting is enabled at the same time as data gathering. As soon as node has finished extracting and processing the data into a sharable form, it sends a vote transaction.

Normal transaction to a burn address was chosen as it is fast and multiple can fit in one block. The burn can be set higher for additional peace of mind.

The vote transaction should contain hash of the superblock and must be signed with the key used in registration. To prevent nodes from capturing other votes and just sending the trending hash without actually processing the stats, the vote is composed as follows:

 Vote1 := H(C1 + H(data)) + RegBlk + H(RegBlk + RegMerkle + H(data))
 Vote := Vote1 + Sign(Vote1,RegSecret)

where plus is concatenation, H is sha256, C1 is constant, RegBlk is hash of the registration block, RegMerkle is merkle root of the registration block, data is the serialized superblock data, Sig(data,key) is signature function and RegSecret is the secret key used in registration.

I thought about using the same coins as in registration stake to save few bytes on the signature but realized that staked coins must mature first.

Stats block Staking

When 70 blocks pass after initiation block, staking of stats block for the project is enabled and further voting is disabled. Aftr that block is staked, the period ends preventing double superblock.

The stats data contents must match the most popular vote and the block must be signed with the registration key.

Number of total registered nodes, wining votes and all other votes is also recorded alongside the superblock (not hashed, but still signed and checked). From the numbers a new registration difficulty target is calculated.

To decrease the delay, superblock staking is performed with registration block hash instead of coin UTXO and at a difficulty calculated from the number of winning votes (kernel below). This paragraph may evoke some mistrust, but it becomes clear after reading about research beacon staking.

ProofHash = H( RegBlk + StakeModifier + nTimeTx );
Target = f(NumOfWinnigVotes)
if ProofHash < Target then ValidSuperblockStake

It is not important who stakes the superblock: it is only one block so the network won't be disturbed as much by adversary node not including transactions and hash of the data is already predetermined by votes.

There is a possibility of never staking the superblock, caused by network not reaching vote consensus
or all nodes with the popular vote going offline. Missing superblock is bad for the network, but it is not expected to happen often. But in that case, a new attempt will be made next day.

The node that staked a superblock receives a block reward. Other nodes that placed a winning vote (voted for sb that was then staked) also receive a reward, but later, in a coinstake transaction. The amount of both rewards should be wisely chosen or even can be made calculated from difficulty etc.