Slush SDK Roadmap

Originally published at Geometry

This is an outline of our plans for building the Slush SDK as well as an overview of how this will make sense in an ecosystem consisting of app specific rollups and validiums.

We see app specific L3s as being inevitable. Since L2 will have a fixed architecture, L3s will be able to offer flexibility that L2s can’t. Apps have a wide range of needs in terms of the computational power, data availability and decentralisation. L3s will be able to satisfy any of these.

Three examples below:

Hence our goal with Slush is to build the SDK that will support easily running centralised and decentralised L3s.

Our product consists of two parts; the command line tool (and eventual website) for spinning up an L3 coupled with the backend infrastructure. In our case the backend are the contracts, Starknet and Tendermint nodes, Starkware’s SHARP Shared Prover as well as regular web2 infrastructure needed to power all of this.

The Slush SDK and deployed L3s will pair well with trustless bridging tools we developed for proof-of-concept at Slush.dev as well as with tools such as Fossil, useful for reading Ethereum L1 state. These will also be included as part of the SDK, meaning interaction will be easy between different L3s.

For our first products we are focusing on the Starknet ecosystem. This is because there is a lot of publicly available software and Starkware has SHARP the Shared Prover for proving blocks.

We are decentralising our network on the Tendermint consensus mechanism. It’s fast, battle tested and well supported meaning we only need to implement a well defined set of features to get it to work in our system (see Roadmap below).

Tendermint is great for our use case because the consensus mechanism can be paired with arbitrary programs being run on the network that implement the ABCI. This will allow us to run Go, Rust or Cairo code (though only Cairo can be proven). Furthermore Tendermint allows single slot finality, which is especially good if we want to bridge between different rollups. Finally, the relatively smaller number of nodes (~100s) is not a large security issue even when it comes to Validiums, as a single honest node can secure DA for everybody.

In order to get the first version of the Slush SDK running we have a list of challenges to solve. We will outline some of the more interesting ones here.

Since we are aiming to use Tendermint for decentralisation we will need to get this to work with a light client in Cairo. This can be split into two subtasks:

Since we want to have a decentralised L3 we can verify from L2 Starknet, we need a light client in Cairo. Luckily we can base our architecture on the Tendermint-Sol library. This was originally written for the Celo network and is in Solidity. It’s a large library, however as a first step we only need to implement core functions such as verify. This will give us the base code for verifying headers of the chain from the Tendermint network.

Even the optimised version of Tendermint-Sol is super expensive to run on-chain, hence we need to simplify serialisation in the Tendermint network to make it cheaper. 70% of the gas costs of verification in the light client are related to serialisation. We can remove serialisation by removing the arbitrary size inputs of the serialisation that tendermint usually allows, and we make them fixed length. This means the signed headers and signed votes will have an even more specific format than usually allowed in Tendermint. Of course we keep the serialisation that is used for communication between the different nodes.

We also need to make the Tendermint network compatible with Starks. This means replacing the hash function with Pedersen and the signature scheme with the Starknet curve.

Finally, Starknet signatures and hashing are slower than the original, so we have to play around the network parameters to make the nodes sync well.

Of course simply having a network running on Tendermint does not guarantee decentralisation, we could be running all the nodes. For proper decentralisation we need OSS as well as an incentive for running the network. The incentive system is something we will not yet make a binding stance on, however we will be making our code OSS.

In order to eventually prove computation on our network we need to run provable code. At the moment Cairo is the most ahead with provability. Hence we want the ability to run Cairo code on Tendermint. Since Tendermint works with any program that implements ABCI a key step will be to write an ABCI interface for a Cairo VM.

Bridging will be an important part of the Slush SDK. With Merkle proofs we can bridge between any Ethereum based rollup storing data in Merkle-Patricia trees.

More details about this in this thread.

Proving

Once we have a Cairo VM on Tendermint, and the Tendermint light client on Cairo, we can prove both of them. By putting them together we can prove that the virtual machine has executed correctly, and the decentralised nodes have accepted the state of the VM. The on-chain smart contract accepts the state transition if both of the criterions are satisfied.

The current roadmap we are following for decentralising our network:

We are moving towards on demand L3s. With the above roadmap in hand these will be possible in the next 3 months.

We would love to hear from you if you are building in the Starknet ecosystem and are thinking about having your own L3.

Do you find the above plans exciting? Get in touch with Ago or Kalman!