CasperLabs Update 18th Feb. 2020: How Highway Protocol deters Oligopolies
Oligopolies or cartel formations are a threat to decentralization, especially in Proof-of-Stake blockchains. In a PoS blockchain, an oligopoly can lead to lesser participation in the validation of transactions on the blockchain as there is a risk of being censored by members of the oligopoly. This would result in losses on the censored party and subsequent discouragement in the validation of transactions which would in return lead to increased profits for the Cartel.
The Highway protocol is built in such a way to prevent Cartel formation by distributing staking rewards in a formation that discourages censoring messages received from other validators. To demonstrate how this works, we introduce a basic sequential game;
Validators have stakes. Example: Validator A (the majority) has staked 200 tokens, whereasB (the minority) has staked 100.
In Highway, Validators are rewarded for proposing and finalizing blocks. This involves sending a variety of messages every round. However, in this simplified setting, we assume a single round where everyone is supposed to send only one message.
Validators receive rewards proportional to their stakes. A: ⅔’rds of the reward, whereas B: ⅓’rds of the reward.
3 tokens are minted as a reward → if A sends a message, he’ll receive 2, and B will receive 1
The problem here is censorship,
A (majority) can censor B (minority), but not vice versa.
If A chooses to censor B, then B appears to the protocol as not having sent a message, and does not receive any reward.
Moreover, we have to consider the cost of validation on the network
We assume that validators incur an operational cost. In the simplified censorship game, for the sake this, we’ll assume that only B incurs an operational cost 0 < c < 1.
Where ‘c’ = cost
If B sends a message and is not censored, he ends up with 1 — c as payout.
If B sends a message and is censored, he ends up with -c as payout.
B can choose whether or not to enter in order to avoid losses in case he is
censored. In that case, A receives all 3 tokens.
This can be modeled in the form of a sequential game thus;
1. B decides whether to enter or not.
2. If B decides to enter, A can choose whether to censor B or not.
3. If B decides not to enter, the game ends and A receives the whole payout.
In naive reward distribution, if someone appears to have sent a message, they receive their allocated reward. In this case, 2 tokens for A and 1 token for B.
- If B decides to enter and sends a message which does not get censored, A gets a reward of 2 tokens while B gets a reward of 1 — c.
- If B decides to enter the validator set and sends a message which gets censored by A, A still receives their full reward while B goes home with a loss of -c.
- If B decides not to enter, the game ends and A receives the whole reward.
In this scheme, it doesn’t cost A anything to censor B. A risk-averse B would be deterred from entering because the worst case results in -c losses. Thus, using backward induction, the subgame perfect equilibrium is (Don’t enter).
Scaled reward distribution (e.g. Eth 2.0)
This is similar to naive reward distribution, but if someone appears to not have sent a message, total reward is scaled by the
percentage of participation before being distributed. However, victims still don’t
receive anything.
In the case of censorship, the total percentage reward for participation is scaled to ⅔. A receives a reward of 4/3 (2 multiplied by ⅔) while B still doesn’t receive any reward. If B decides not to enter, the game ends and A receives the whole payout.
B’s worst-case after entering is still lower than not entering, so the equilibrium hasn’t changed.
Scaled and symmetric reward distribution (Highway)
If someone appears to not have sent a message, total reward is scaled by the
percentage of participation before being distributed. Victims receive rewards too.
In this case, the dominant strategy for B is to enter the game if c < ⅔, that is to say, B receives more reward if it chooses to enter, regardless of A’s strategy., Since B enters no matter what, A is forced to reevaluate his options and would have to choose either to censor messages from B and receives 4/3 or not to censor B and receive 2. The equilibrium, in that case, is (Enter, Don’t censor). In other words, the rules discourage censorship as long as c < ⅔.
Conclusion
Rules of such games will determine validator behavior. No matter how honest a network launches, adversarial behavior would emerge if the rules don’t account for it. If forming an oligopoly to censor others earn more rewards, validators would eventually do it, if not now. Scaled and symmetric rewards ensure honest behavior. While not sacrificing any performance of the protocol.
Reading list
To learn more about reward distribution in Highway, refer to the posts below
Engineering Status
- We’ve pushed our February release, Node 0.14 (previously called Node 0.12).
- Node 0.12 was released on Feb 13, 2020. However, due to issues with Rustdoc, we had to cut the release again on Feb 14th and tag it as 0.14
- Version numbers will fluctuate more due to cargo & rust docs, we will decouple version #’s from releases henceforth.
- Team has entered the second week of Sprint 30
- Our next release would be by the middle of March and the testnet would come two weeks after that.
Current focus
- We’re building an ‘honest’ version of the Highway protocol, this assumes that all validators are honest and act in good faith. This would enable us to observe performance testing and hardening while we program out the economics and security of the protocol.
- Setting up a test environment for testnet
- Continuing research on Spam and DDOS protection
Consensus
- Eras with fixed-length rounds is mostly complete.
- Updating equivocation detection to support Eras.
- Implementing log(n) optimization for the Forkchoice and wiring it with Highway.
- The team is testing consensus locally and will use our testbeds to stress test the system under various scenarios.
Node
- Stability, Optimizations, and Performance of Node.
- Adding Add deploy state transitions to the gRPC event stream.
- Deploy Gossiping.
- Continue CLType integration with Node & Clients.
Execution Engine
- Making System Contracts native in EE. This will speed up execution engine performance.
- Logging and Metrics.
- Writing a Rust Iterator based on trie_store::operations::keys.
- Removal of PurseID and TURef.
- Supporting multiple key types for secure enclaves.
- Performance testing and hardening of the Execution Engine
Test and SRE
- Demo’ing Testbed environment next week Tuesday.
- Optimizing integration testing and CI, so it’s faster. Also preparing integration tests for Highway.
- Network Simulation for testing Node restart.
- Benchmarking EE on various AWS instances.
- Updating both Scala and Python clients.
Ecosystem
- Updating documentation for Smart Contract examples and tutorials.
- Creating a Smart Contract Developer guide.
- Building deploy interface within CLarity.
- Working on a broader vision for CLarity explorer
Economics Research
- Design of combined computation/storage/bandwidth pricing.
- Design document for Spam Protection.
- Mockup for reward distribution in Python.
- Sequoia Simulator for CasperLabs Blockchain.
Team & Company Update
- Leadership offsite being planned end March / early April after Alpha Testnet launch.
- Weekly workshops every Thursday at 8 am PT and Thursday at 4 pm PT (Friday 8/9 am in Asia
Where do developers go to learn more and get started?
At release, links to installation packages and relevant documentation are available on GitHub.
Where will bugs be filed?
Report a bug on GitHub
