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:

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.