Security of the Milkomeda Algorand Rollup

With the fresh arrival of rollups in the Algorand ecosystem with the launch of Milkomeda, it’s a good idea to take a step back and gain some perspective on rollups as a technology overall. Rollups were first proposed in 2018 by an anonymous user on Github. Rollups are known as a scaling solution in the Ethereum universe, with many people using them, but they’re quite un-familiar to those outside of the Ethereum world.

So what is a rollup? How does the Milkomeda Algorand Rollup specifically work? And how does Algorand secure transactions, and therefore secure the data of the rollup, on-chain?

What is a Rollup?

A rollup is described as a “layer 2” chain. Layer 2 means that it lives on top of an existing blockchain, which is called the layer 1 or main chain, and thus is able to take advantage of the layer 1’s native, built-in properties.

The key idea behind a rollup is to submit L2 transaction data on-chain, while L2 transaction computation is shifted off-chain to enable efficiency and interoperability gains. Unlike sidechains, rollups inherit the security of the underlying blockchain by using it for sequencing and potentially data availability. This is achieved by periodically posting condensed batches of transaction data to the main chain, allowing anyone following the chain to reconstruct the state of the rollup and verify the transactions therein.

Transactions for the rollup are collected, executed, and bundled by a batcher (aka. roller, thus rollups). The batcher then posts the bundle to the main chain as a “rollup batch”. Users running observer nodes (which anyone will be able to do themselves) can then read, and thus “unroll”, this batch of transactions and use it to reconstruct the rollup state. Storing these transactions on the Layer 1 is how a rollup inherits the security of the layer 1 it is built on.

It is this batching-posting-reading process which enables a rollup to inherit the security of the layer 1 while also removing the computational pressure from it. The ability to store arbitrary data on L1 enables us to use an alternative virtual machine to interpret it, in our case the well-known EVM.

Rollups, in more layman terms, can be described as “chains on top of chains”. But, as mentioned before, not all Layer 1s are the same and, therefore, not all rollups are the same either. In fact, to build and deploy the Milkomeda A1 rollup on top of Algorand we had to develop a novel data availability protocol from scratch.

How the Milkomeda Algorand Rollup Works and is Secured

To implement the A1 rollup on top of the Algorand blockchain we had to find a way to use Algorand for sequenced data availability. In other words, we need to be able to post the desired rollup transaction data to Algorand in the correct sequential order while ensuring the batch fits. We chose an approach which allows us to start simple and later to scale up to multiple batchers (some of whom may even be adversarial).

Each Algorand transaction allows inclusion of up to 1 kb of arbitrary data in a transaction note field. These will be our carriers of the rollup related data. Further, on Algorand, up to 16 transactions can be posted in an atomic group. That means all the transactions get included in the same block in the given order, or all of them fail. We can use these rules to ensure correct sequencing of posted data — up to 16 kb of data. However, we want to be able to post larger amounts of correctly sequenced data, thus we needed to take a step further to ensure that this is the case.

To post larger amounts of data, we’ve devised a two step process where we separate the sequencing of the batch from making the batch data available. These are called the “Batch Proposal Phase” and the “Batch Availability Phase”.

Batch Proposal Phase

After the batcher has collected enough rollup transactions from the users and decided on which ones to put into the next batch, it will encode them and split the resulting data into 15 kb chunks (i.e. ones that fit comfortably into one atomic Algorand tx group). A merkle tree is built using these chunks, and its root becomes the batch proposal for the given batch.

Once the root is included in a block the batch has officially been proposed and we move on to the Batch Availability Phase.

Batch Availability Phase

During this phase no new batch proposals are accepted and the batcher now has a set time frame within which to post all of their batched data to the chain. With each posted chunk of data, a merkle proof linking it to the batch proposal is posted. If the batcher fails to post the batch in time, then the batch is considered invalid and is discarded (if this happens we move back to the Batch Proposal Phase).

The Rollup observer, available to be run by anyone, then reads the layer 1 chain for batches being posted. On finding each batch, it orders its chunks based on the included merkle proofs, thereby successfully restoring the encoded rollup batches. By applying all of these transactions from the batches onto an EVM node, it reconstructs a view of the rollup state, thereby making it available to be queried for customary things like token balances, smart contract states, etc.

The Future

The initial setup of our rollup operates with a single batcher (as is customary with all current rollups projects). Over time we will be upgrading the Batch Proposal Phase to allow for an open set of batchers. Of important note, observers do not rely on the batcher for rollup state validation even in the single batcher scenario. Anyone observing the rollup can easily detect invalid transactions on their own and ignore them when restoring the rollup locally.

Rollups inherit the security of the chain they’re built on top of, with the A1 rollup thus inheriting security from Algorand. So how does Algorand secure transactions, and help to secure data availability for the A1 rollup?

How is Algorand Secured?

Algorand uses a Pure Proof-of-Stake (PPoS) protocol built on Byzantine consensus to secure the network and reach instant finality, resulting in the confirmation of transactions in under 5 seconds with a transaction throughput of about 1,000 transactions per second (TPS) (with support for 6,000 tps soon). So long as a supermajority of the stake supporting the network is in honest hands then the protocol can tolerate malicious actors.

Every single user who holds ALGOs can participate in the consensus protocol. To do so, a user’s account must be online. To reduce exposure, online users do not use their spending keys (i.e., the keys they use to sign transactions and spend their stake) to participate in consensus. Instead, a user must generate and register a secret participation key before going online. With this key, an online account can participate in proposing and confirming blocks.

The more stake a user has the more likely they are to be selected to participate in the consensus protocol. Selecting users to participate in the consensus protocol is done through the use of Verifiable Random Functions (VRFs). As a result, a malicious party cannot identify any of the participants of the block verification process and can, therefore, not target specific users and corrupt them and the consensus mechanism. The participants are changed for every round of block selection in order to further prevent these attacks.

As a result of Algorand’s instant finality, done through a three step process that includes two votes by committee, forking the network is impossible. A malicious actor cannot convince two separate honest actors to accept separate blocks from the same round of block production, and only one block can be certified at a time. This helps to secure the network and bring instant finality to the network.

Learn more about Algorand:

Algorand Inc: Website

Algorand Foundation: Website

Algorand Research: White Papers

Twitter: @Algorand

Medium: @Algorand

Try Out The Milkomeda Algorand A1 Rollup

Building a rollup on top of a blockchain like Algorand, which has had its security both battle and time-tested, gives developers and users the confidence to take advantage of both scaling and interoperability that the A1 rollup brings to the Algorand ecosystem. With Algorand’s instant finality of transactions, users will experience a greatly improved experience while interacting with A1’s EVM ecosystem thanks to inheriting this same property.

Now that you’ve gotten enough background to understand what the Milkomeda A1 rollup is bringing to the Algorand ecosystem, you can try it out for yourself on testnet by bridging over via the Milkomeda Algorand Rollup bridge dApp. If you want to know how to use the A1 rollup then head over to this post where we explain how to wrap and unwrap test ALGOs to use them on the testnet.

The Milkomeda A1 rollup is one of the first deployments of a rollup outside of the Ethereum ecosystem, and is an extremely exciting release for both us here at Milkomeda and the blockchain space as a whole. Keep up with Milkomeda’s and A1’s progress by following our socials and blog using the links below!

Milkomeda: Website

Documentation: GitBook

Twitter: @Milkomeda_com

Medium: @milkomedafoundation