Technical challenges of BTC core based proof of stake implementation
This article reviews some of the issues encountered during the initial technical development of the proof of stake system for Dynamo Coin and how they are being overcome.
Batching of staking payouts
Initial simulations of staking reward payouts demonstrated a potential DOS attack vector which needed to be addressed. Specifically an attacker could stake millions of (presumably small) balances resulting in a transaction flood at the end of each staking epoch. This could effectively halt all transaction processing by creating blocks larger than the current allowable size (10mb).
The initial design called for full nodes to calculate and automatically pay out staking rewards within certain block times after the staking epoch. This was changed to requiring stakers to claim payouts and then having full nodes validate the staking claim. Instead of batching all payouts in a single block, payouts will be spread out based on mempool processing capacity, which is automatically moderated as part of normal BTC core operations. This change addresses both the transaction batching and block size issues using already built core mechanisms.
Finality of staking rewards for consensus
A consensus design issue was identified in the staking ticket processing logic. A race condition could exist where different honest nodes could determine that some staking tickets were invalid, resulting in an improper hard fork and eventually pruning from the network. This was particularly acute during fullnode restart intervals. The original design called for storage of pending rewards in a local database during the staking epoch and calculation of rewards based on that local database after a cooldown at the end of the epoch.
The revised design eliminates the local database for pending rewards and instead uses the historical blocks stored in the fullnode for the best chain tip, after a cooldown at the end of the epoch. Although this puts additional processing demands on fullnodes it is the safest and most secure method to calculate epoch staking rewards in a manner which will never break consensus.
Handling intermittently offline staking nodes
An issue was identified regarding the processing of incoming blocks and the storage of staked amounts and pending rewards during initial block download after the restart of a fullnode. The original design called for processing all incoming blocks as they arrived from other nodes and then building the pending payout database and staked balance database. As noted above the pending payout database design as abandoned. Additionally the staked balance database was re-designed to recalculate all staked balances after initial block download was complete, including during a restart of an existing partially in sync node.
By re-calculating all staked balances after IDB, the staked balances are guaranteed to be correct at the time of staking payout calculation, eliminating issues of possibly incorrect balances and thus inaccurate payout calculations leading to consensus breakage.
Revised development timeline
Based on the technical issues encountered, development is approximately 3 weeks behind the initially published timeline. Proof of stake implementation on mainnet is now estimated to occur in early to mid September 2022.