Block Propagation
Protocols for valid block production continually evolve in the PoR forum. Initially they will include the following:
Random selection of block producers according to availability stakes. Each PoR expert who wishes to be included in the random selection of the next block producer will submit availability stakes. Availability stakes are sem tokens an expert chooses to encumber in a standardized smart contract which is sent to the Semada platform to signal their availability to produce blocks. The Semada platform has a list of all potential producers with their availability stakes, and uses the list to randomly select the next producer, weighted according to stakes. When an expert is selected, part of their availability stakes are used to pay for the opening of the validation pool for the block they produce, as described below.
Regular production schedule. Time slots for producing a block will occur every T = 10 seconds. When a block producer is chosen according to the protocol in 1) they
will be assigned a window N = 100 blocks later.
If block number x is not produced during its scheduled time slot then it is empty, but its scheduled producer’s availability stakes are still sent to the validation pool by the availability stakes smart contract, to be judged by the PoR bench. The bench may or may not punish the errant producer for failing to produce a block by downvoting the empty block, depending on the how the protocol established in the forum deals with the particular circumstance. Initially there will be no penalty for missing a block, except the lost opportunity to collect fees.
Block production. The expert selected in step 1) will produce a block and submit it to the network in accordance with the protocols listed in the forum. This will include a Merkle tree of all the network transactions the producer chooses to include in the block and a pointer to a previous block. The producer’s final action is to send the block’s address to her original availability stake smart contract, which will send the block’s address, the producer’s address, and the availability stake to the Semada platform in order to initiate a validation pool, which places the availability stakes as an upvote in the producer’s name.
Validation. Each block will be reviewed by a validation pool, which will form part of the consensus protocol (detailed in step 6, below). Along with the producer’s availability stakes, the total fees included with all transactions contained in the block will be sent in the block producer’s pseudonymous name to Semada with the block address posted to the forum. This triggers a validation pool where the PoR experts will verify the block production correctly, following the protocols agreed upon in the forum. In other words, expert PoR validators will download the most recent validation algorithm upvoted in the forum. Faithfully running this algorithm on the block will automatically choose the correct vote to win the validation pool, rewarding honest validators, assuming users with 51% of sem token power act honestly. Honesty is defined as faithfully running the algorithm, unedited.
Specifically, calling the Semada platform to validate a block returns the following:
Sem tokens in proportion to the fees contained in the block are minted and staked half in the block producers’ name as an upvote (this is the producer’s reward for their work) and half as a downvote.
The block producer’s availability stakes are staked as an additional upvote for the producer.
PoR experts may stake their sem tokens as up- or downvotes on the validity of the producer’s block.
The voting window closes according to the parameter set by the bench in the forum. Semada calculates the result of the vote.
If the bench voted against the block, the producer loses her availability stakes (slashing) to those who voted against her. If the bench voted for the block, the producer receives the reward of half the newly minted sem tokens. Similarly any expert who staked tokens for or against the validity of the block wins or loses tokens in proportion to their stakes.
In the event the block is validated, the fees sent with the block are distributed in a reputation-weighted salary to the entire bench. If the block is not validated, the fees naturally remain with the transactions and will be picked up later when they are validated in a successful block.
There are two obvious perverse incentives to discuss:
There is an incentive to validate a block to gain the fees sooner. This incentive is not particularly strong, since these small fees will be picked up a few seconds later in the rare occasion that a block is produced contrary to the automated protocols. So the incentive to validate a flawed block is outweighed by the incentive to maintain the integrity and value of the sem token by honestly following the protocols.
There is an incentive to invalidate a block in order to gain a share of the producer’s availability stakes. This is simply not the correct perspective. Presumably, if the availability stakes were not automatically encumbered the producer would have used them to upvote the validation of the block anyway. So the little extra knowledge about the amount of availability stakes given as upvotes should not affect the votes of the rest of the bench.
If the validation pool is given enough time ( t → ∞ ) after a block is proposed, the block enjoys complete finality since the community has enough time to come to perfect consensus in evaluating whether the block was created according to stipulated protocols in the forum. However, in practice, a long validation time will conflict with the practical need for swift resolution. Since every step of validation is automated, validation pools will end within seconds. By forcing validation pools to end in finite time, we open the possibility of network partition and lack of genuine consensus which opens the possibility of forks, which we discuss further below.
If a complete network outage precludes the possibility of a validation pool for block x (because the voting period expires before network connectivity is restored) then the producer will win their availability stakes back, since ties go to the upvote, and the randomly chosen producer will not be punished. However, if this happens the validators’ symmetric keys for the seed for the random selection of the producer of block x + N will be missing. In this case the producer of block x + N will be randomly chosen using the seed from the last block previous to x whose validation pool did conclude, salted with the block number. This ensures any network outage shorter than the history of the blockchain will not eternally disrupt chain production. This addresses the availability/regeneracy problem: even if the network loses all but one node, block production will continue (which is also one definition of a decentralized system).
5. Pointers. Each valid block contains one pointer to an earlier, validated block.
Pointing to a block earlier than the block in the previous time slot creates a fork, which, if continued, will invalidate the skipped blocks, leaving all unused transactions contained in the skipped blocks available for inclusion in future blocks. The fees that were previously distributed to the bench from the skipped blocks will no longer have valid histories in those skipped blocks, and so the fees’ ownership will automatically revert to the authors of the transactions contained in the skipped blocks. This creates a disincentive for validating such forks. Naturally, the protocol will automatically punish producers for skipping valid blocks by pointing to blocks too many time slots earlier (again, the specific protocol will be stipulated in the forum and will depend on current network performance).
However, sometimes forking can be healthy, as for instance when correcting a Byzantine fault as discussed in the next step.
6. Chain consensus, also known as the fork-choice rule, is determined by the chain with the largest weight of valid blocks. Weight is measured by summing the upvotes minus the downvotes. Valid blocks have satisfied 1) through 5) above, i.e., they have valid producers, valid timestamps, valid successful validation pool, and valid pointers. (In order for this protocol to be consistent, it is assumed the contemporary validation algorithm in the forum properly verifies the transactions have the proper history through their hashes).
Besides forking by pointing to a block earlier than the previous time slot, a second type of fork is possible when a producer creates two or more blocks in their time slot--a Byzantine fault called equivocation. If such an event is detected, both blocks will very likely be rejected in both validation pools and the malicious producer will lose their availability stakes to the validators who downvote the blocks. However, when the network is partitioned it is possible a malicious producer might be capable of publishing blocks in the appropriate subnets of the partition and winning each validation pool. In such an unlikely scenario, the producer would be blacklisted soon after network connectivity is restored. The next honest producer would point to a previous block and all Byzantine forks would be invalidated. If there are 51% honest producers the Byzantine fork would eventually be orphaned, since honest producers will outproduce the Byzantine producers and blacklist all who reveal themselves with dishonest application of the agreed upon protocols.
Another protocol for preventing dishonest block production during network partition may be developed in the forum: a 67% active validator requirement. This number addresses the 33% BFT threshold and is used in the Tendermint protocol. The idea is that the consensus protocol would only recognize blocks which have been validated by at least 67% of the active validators. An active validator is defined as a sem token holder who has participated in any of the past 100 blocks. This prevents any BFT block from being created during network partition, and greatly improves block finality.
However, choosing this 67% active validator requirement as part of the protocol has a downside. It arbitrarily punishes random producers with loss of their sem token rewards when the network is partitioned. More importantly, due to the CAP theorem, it limits the availability of the system, which is why it is not included in the initial implementation. The Semada platform naturally gives the bench the power to choose any parameter 0 ≤ p ≤ 1 in place of the p = .67 active validator requirement, depending on network performance, by adjusting the protocol in the forum.
7. Self-referential architecture. The Semada platform can be run on one blockchain and validate another. However, it is also possible to run the Semada platform’s DApp, including its bench, forum, and validation pool, on the very blockchain that is validated through Semada. But this self-referential architecture destabilizes the system as it increases the likelihood of forks. Once a validation pool concludes, the Semada platform will send a transaction to the blockchain which will be picked up in a future block, which itself needs to be validated by a future validation pool, ad infinitum. With this wrinkle, how is consensus reached?
If the first block that included the validation pool’s transaction is not itself validated, that transaction is not deleted, it will eventually be picked up by some other block, which itself will eventually be validated, ad infinitum. So the ouroboros architecture destabilizes the system, but not catastrophically for most imagined uses.
8. Forum contribution rewards. The entire bench shares all fees sent to the platform with PoR experts in reputation weighted salaries. Sem is earned through 4 avenues: 1) joining the bench by sending a fee, 2) performing the work of block creation, 3) policing block creation through the validation pools, and 4) contributions to the forum. The first 3 rewards were discussed above. The fourth deserves some comments here.
Protocols for block creation and evaluation, and protocol development and evaluation will continually evolve in the forum through contributions from experts in the PoR tag. Whenever a contribution is added as a post to the forum, the bench stakes sem tokens to vote on it, and the winners are rewarded with the losers’ stakes. Each time a future post references it, the author is further rewarded according to the algorithm described in the Semada core.
Last updated