Scaling Tezos with Layer 2 solutions

By DEKU team

How to scale a blockchain is a huge topic and Tezos core devs teams are exploring several designs. At Marigold, we want to share our R&D work with Tezos builders as soon as possible to get their feedback and improve our proposal. Since scaling blockchains is still an experimental field we’re developing different solutions with different benefits.

This post aims to give a global overview of different scaling solutions for Tezos, introduce Marigold’s work in this landscape and how they relate to each other.

Why scaling matters?

When people refers to scaling they may have some objectives in mind:

  • Increasing the throughput of the chain, like having faster TPS;
  • Reducing the finality delay for a block;
  • Having deterministic finality rather than a probabilistic one;
  • Reducing gas consumption for processing operations.

In the meanwhile, they want to preserve the intrinsic properties of the blockchain like safety, censorship resistance or decentralization

Optimistic rollups

Rollups are specialized to process large batch of operations while this chain may use more powerful hardware. It’s a way to scale both horizontally and vertically.

As Layer 2 solutions, rollups have two main building blocks:

  1. a protocol in Tezos which manages communication and security between layers
  2. a daemon node which processes rollup transactions

Optimistic Rollups, or ORUs, are called optimistic, because they work on the assumption that blocks are correct until explicitly proven otherwise.

Enshrined Rollups

Jakarta2 introduced the first ORU solution into the Tezos ecosystem, so called TORU for Transactional Optimistic Rollup. While they are limited exclusively to transactions, TORUs are the very first solution that Tezos application builders can use to familiarize with ORUs.

TORU is an exploratory design exercise preparatory to the development of SCORU which will come along with a WASM VM to process smart contracts witin the rollup.

Both can be thought of as a rollup factory, meaning any rollup node builder may use their respective rollup protocol.

TORU & SCORU are called enshrined rollups because their rollup protocol is enshrined to the Tezos protocol.

This is a very innovative approach in blockchain which aims to give better warranties and faster throughput to rollups users.

Smart contract Rollups

At Marigold, we are very hyped by enshrined rollups, and some of our teammates are contributing to them. But being tied to the Tezos protocol comes with a tradeoff: you are tied to the election period, this means you can’t iterate faster than every 3 month and a proposal may be rejected by the governance. This is the why we also decided to explore a more conventional design where the rollup protocol lives inside a Tezos smart contract written in CameLIGO.

This is CHUSAI!

CHUSAI Alphanet will be released in July, we will communicate soon on how to join. This will be a very exciting journey and we will be able to iterate fast thanks to your feedback.

How Rollups scale

Rollups are designed to increase throughput. And with TORU already reaching 200 TPS, we can expect 1,000 TPS from more mature solutions.

Since Rollups use Tezos’ Tenderbake consensus, their finality is deterministic.

The gas model is not yet decided for CHUSAI. A TORU/SCORU node builder may choose their own, but for sure the fees will be lower than in Tezos.

Finality is the tradeoff of ORUs. So while it may not be a concern for an application living only in the rollups, when one needs to withdraw to Tezos, they have to wait until the end of the refutation period. The refutation period for TORU is 14 days. Though this is a very conservative estimate because TORU is still experimental. But it will remain in days.

Sidechain

A sidechain is a secondary blockchain paired to, and communicating with, a parent blockchain. A sidechain works like any blockchain and has the same core properties, with the added feature that its consensus is witnessed by the main chain.

As a scaling solution, a sidechain may accept some decentralization tradeoffs to explore new designs and to improve the throughput.

The DEKU Chain

DEKU-C is a public, proof of authority blockchain that runs a Tendermint like consensus and a WebAssembly Virtual Machine. The authority for running this chain is the Tezos Core Teams.

Like rollups, the core assets bridged between Tezos and DEKU are Michelson Tickets.

DEKU Alphanet is starting this week and open to any application builder who want to explore it.

Stay alert, lot of info will be communicated this week

DEKU Parametric

DEKU-P is the core system behind DEKU-C. We’ve open source it as a framework to build your own permissioned or private chain.

Current private blockchain solutions require deep knowledge: they are SDK either to build a full blockchain or a virtual machine. Those require a deep knowledge of blockchain internals to not be at security risk, meaning projects have more work on infrastructure than on their own business. This is very bad for time to market also.

Parametric aims to ease this by only requiring you to code your chain’s state machine.
Business would be defined only with a state machine: this is exactly what DEKU-P do.

DEKU-P comes with TypeScript, Go & OCaml SDKs and more can be added.

To know more about DEKU-P, you can attend the talk “Introduction to DEKU, a parametric sidechain on Tezos”, Friday 22th of July during the TezDev 2022 at Paris.

How Sidechains scale

Proof of authority sidechains combined with top of the line hardware may rocket the throughput. DEKU-C Alphanet currently hits 5,000 TPS, we’re working on reaching 10,000 TPS soon, and our actual objective is much higher.

Using Tendermint’s consensus, finality is deterministic and only requires 2 blocks on DEKU.

DEKU has neither a minimum nor fixed block time: blocks are produced as fast as they can.

This comes at the price of less decentralization, which is why we want to build a trustable authority. We think that a consortium of core developers, excited to work in open source and accountable to the community, would be far more trustable than a VC funded opaque corporation, but we may be wrong!

If you want to know more about Marigold, please follow us on social media (Twitter, Reddit, Linkedin)!

1 Like

The link to the CHUSAI repo (https://github.com/marigold-dev/chusai) does not work, giving me a 404/not-found

Is source code for the Deku bridge contract available in Ligo or similar? I would like to study the contract code in detail to understand how it works with tickets in particular.

Oh, perhaps this consensus.mligo is the source?

It is now public

Yes it’s consensus.mligo
This PR would it easier to read Refactor and change the place of consensus.mligo by kienle371999 · Pull Request #735 · marigold-dev/deku · GitHub

@Marigold what is the native token of Deku?

@noodlestomatojuice, you can deposit any kind of Tezos ticket to Deku. We have an application called TzPortal which provides a GUI for wrapping, e.g., FA1.2 into tickets.

Thanks for the response @d4hines. Let me ask my question a bit differently - if users bake on DEKU, what are they rewarded with?

@noodlestomatojuice, that’s not quite how Deku works.

Short version: to deposit tickets to Deku, users lock them in a single vault contract on Tezos. Users are therefore encouraged to use Ctez wrapped in tickets to handle the problem of “who gets the baking rewards”.

Long version: Deku is a framework for making sidechains. Currently it uses a Proof-of-Authority consensus heavily inspired by Tendermint, so there’s no staking, etc. part of the consensus mechanism. The alphanet includes a WASM virtual machine implementation allowing anyone to publish smart contracts written in languages that compile to WASM. There is currently no charge to originate these contracts or to run them, as it’s a proof-of-concept. The validators pay for the cost of running Deku themselves (currently that’s Marigold for the alphanet, but anyone can deploy their own instance of Deku).

But the idea of Deku as a framework is that you can swap the protocol being run with a protocol/application specific to your use case, written in the language of your choice. For example, one use case I’m excited for is game designers running the core logic of their game as a Deku protocol. Deku implementors could create all kinds of incentives for using their sidechain: that could be staking, or automatically charging a fee for e.g. in-game transactions, or probably lots of stuff I haven’t though of. Others might use Deku primarily for regulatory purposes - perhaps multiple corporations operate a sidechain together to create audit histories for shipments or something, and they might not charge any fees on-chain as the costs are handled off-chain.

1 Like