Saito Implementation Proposal #1 – Simplified Staking
Today we are happy to share our first “Saito Implementation Proposal“. This specific proposal concerns our staking mechanism. It does not introduce changes to Saito Consensus (which simply requires that mining fees from unpaid blocks be issued to stakers) but offers an interesting suggestion on how to simplify payouts. We are sharing it for three reasons:
1. it is the first “Saito Implementation Proposal” worthy of public discussion
2. it has fascinating implications for core blockchain properties
3. it shows why community engagement matters so much for Saito
The full proposal in is a new Github repository we have created. In the interest of sharing some technical background that might help explain this proposal, let us start this blog post with some background information on how our current codebase handles staking. Essentially, our staking mechanism has the Blockchain (class) create an in-memory data-structure which contains all the UTXO slips that users have deposited for staking. Nodes keep this data-structure in sync and select which participants get paid based on the randomness contained in the golden tickets. Users deposit tokens into this data-structure by sending specially-formatted transactions into the network. They withdraw their tokens using a second type of special transaction.
In this approach, most of the work involved in developing the staking mechanism is writing the code that manages this separate data-structure and inserts and removes UTXO from it. There are many unknowns in this approach largely around performance at scale: what data structures are ideal, how many slips it reasonably includes, what are the performance implications on the speed of block processing when we need to update this staking table when we add a block to the blockchain. These questions are difficult to answer without a large public deployment, which is one reason we have been moving forward with a rollout model that will start with large deposits and gradually reduce the barrier to staking over time.
Over the last three weeks we have been considering an interesting proposal — a suggestion on re-using the existing ATR mechanism to replace these secondary data-structures. We are sharing this proposal first and foremost because we believe it is important and potentially a significant improvement to our existing approach. We also value discussion of Saito Consensus and believe this is worth sharing publicly as it delivers some fascinating properties to Saito almost as an afterthought. Among the benefits:
1. perpetual storage is (suddenly) possible, if an ATR transaction contains a UTXO holding enough SAITO that its staking payout is larger than the rebroadcasting fee, that transaction will never fall off the chain. Since 25% of the average transaction fee is redistributed to the staking table on average, in equilibrium, this would suggest that transactions willing to lock-up 400% of the long-term equilibrium transaction fee can offset their rebroadcast costs with staking income in perpetuity.
2. the technical implementation is simpler, as this technique re-uses existing data structures (the UTXO hashmap) and existing algorithms (ATR rebroadcast), thus avoiding the need for the codebase to create and optimize and synchronize separate in-memory data structures. This also speeds up validating transactions by eliminating several edge-case checks needed to prevent the double-spending of staked transactions.
3. there is no need for users to take any kind of special action to “stake” their tokens: all transactions on the network are “auto-staked” immediately on their inclusion in the blockchain, with their payout issued in a predictable amount of time. Spending any UTXO slip automatically “un-stakes” and then “re-stakes’ it, and insertion and withdrawal attacks on the staking table become impossible under this approach. As another benefit, the staking table is suddenly backed by 100% of the active token supply, further increasing the cost of attacks on the chain.
For more details we encourage everyone to read the full implementation proposal. At the moment, our core team is leaning positive on this proposal and is evaluating it (read: mulling it over). We obviously expect to think about this more before committing any changes to code, but want to share these ideas publicly so that everyone in the community can help digest the ideas. Our experience is that when developers are tasked with implementing features, the default approach tends to embracing complexity. It is usually harder to conceptualize a simple idea than add complexity, but simple ideas often require the most thought.
On a closing note, we are specifically indebted to @brickblockcube for digging into the fundamentals of Saito and — when challenged with a difficult problem as part of a private discussion — thinking through the matter and coming back and provoking us with what is in retrospect a somewhat obvious question, “if we are able to take payments from the ATR transactions looping around the chain, why can’t we issue payments to them as well?” We’re not sure @brickblockcube had this exact mechanism in mind when he asked the question, but we wouldn’t be considering this approach if not for his active engagement.