# snarkOS Technical Roadmap - A Proposal

### Summary ###

Our goals for Aleo are: (1) finality in consensus, (2) incentive compatibility and fair distribution of tokens, and (3) prover availability and fair sequencing of transactions.

I propose separating each of these out into different layers of the stack instead of trying to fit all inside of snarkOS. This will enable us to efficiently prioritize the key blockers to mainnet while at the same time simplifying the system as a whole. It also provides a tangible application idea and clear direction for Aleo the company, distinct from the Aleo network.

### Motivation ###

Much of the work to this point has been focused on integrating these properties into a single library - snarkOS. This potentially presents an elegant solution but also introduces additional complexity and in my opinion, technical risk. Also, in trying to combine these elements, we may end up "diluting" some of them because we're trying to put too much on a single layer that "does everything" versus an integrated system of individual parts that focus on doing one thing well.

The goal of this proposal is to present an alternative path to achieve these principles while mitigating technical risk and maximizing the likelihood that we achieve our timeline for end-of-year launch. Put another way, it maximizes the time and engineering resources that can be potentially spent on other important aspects of Aleo, such as Leo, a package manager interface, etc.

### A Layered vs. Integrated Approach ###

Rather than integrate these properties into a single system, I propose we separate them into different layers:

* snarkOS - is simply vanilla DiemBFT (or other suitable PoS algorithm). The purpose of this layer is to facilitate state transitions and provide *finality* to support important use cases such as interoperability. Ideally, this algorithm can be taken and implemented "off-the-shelf", minimizing technical risk and taking advantage of a "battle-tested" system. *This is a blocker for mainnet launch, and therefore should be given highest priority in terms of resources*.

* Puzzle Lottery - is an application deployed onto Aleo mainnet, which emits tokens according to some proof-of-work submitted to the chain. The purpose of this layer is to solve the distribution problem of proof-of-stake and get a greater percentage of tokens into the hands of our most important stakeholders (aka provers) over the medium-term. There are a variety of ways we could implement this, including picking a fixed baseline difficulty (based on testnet2) and giving out lottery "tickets" based on the proportion of PoSW proofs submitted that are harder than the baseline difficulty. *Critically, this no longer becomes a blocker for mainnet launch, but can be shipped after launch.*

* Proving Pool - is a separate protocol that we implement later on top of snarkOS/VM. Users interact with this directly for submitting proof requests. Similar to the idea of meta-transactions on Ethereum, this could take the form of a "relayer" network where provers can receive signed proof requests from users, generate proofs, and submit them to the Aleo network. As far as prover availability is concerned, this could be a service that we provide. *This is not a blocker for mainnet launch*. Note that this doesn't even have to be decentralized -- this can be a service offered by Aleo; our version of Alchemy, which recently raised money at a $10B valuation. This creates a clear value proposition for the company and value for our equity.

### Advantages ###

This will greatly simplify our system, reduce technical risk, and put us on a clear path to mainnet by the end of the year. It gives us additional time to focus on the developer experience & products (such as Voyager, Aleo Studio, and Leo) before mainnet. And it gives the company (vs. the protocol) a clear value proposition.

With regard to the puzzle lottery, because the submissions will simply be Aleo transactions (and therefore private) validators cannot censor transactions from a specific prover.

Finally, it provides a clear product for the company to focus on which could help drive value to Aleo equity.

### Disadvantages ###

By moving the proving pool out of the core protocol, we may not be able to address MEV effectively. However, we are already mitigating that risk by creating a programming paradigm where some parts of a program can be executed by the provers before being submitted for execution by the validators (the `finalize` statement). Moreover, for the real-world financial use cases that we anticipate for Aleo (e.g. dark pools, shielded assets, identity), MEV won't be as much of an issue as users will likely generate their own proofs or work directly with a prover anyway.

### Conclusion ###

The principles of finality, incentive compatibility, fairness, and availability are worthwhile principles that I believe will make Aleo unique compared to existing systems. However, I believe we can achieve these same properties by layering them as opposed to integrating. This "unbundling" brings the added benefit of enabling us to prioritize only what is necessary for mainnet launch, and give us flexibility to add additional products and services that can be offered by (and therefore benefit) Aleo, the company.