Running Rollup Node to test TORU on Jakartanet

By Felipe Cardozo

Two Layers of a Rollup

The Jakarta protocol proposal introduces Transaction Optimistic Rollups (or TORUs) as the first (and experimental) implementation of optimistic rollups on Tezos.

TORUs are a scaling solution to improve TPS on Tezos.

At Layer 1 protocol level, a TORU has its own address, that compactly represents off-chain transaction execution and state updates. Assets can be deposited to the rollup – and withdrawn – by accounts, smart contracts and other rollups.

To run a TORU, a Layer 2 operator processes the transactions and update the state to reflect the changes. This operator only posts a receipt back to the main chain, summarizing the new state of the rollup as a cryptographic hash.

We can think at this behavior as a Layer 1 rollups factory that allows Layer 2 operators develop and run their off-chain nodes. This also gives them freedom to implement their own policies regarding fees and incentives. This offers diverse alternatives: being completely altruistic, whitelisting operations for specific projects, creating an off-chain subscription service or implementing their own L2 gas model based on e.g., cTez tickets.

The reason for this post

As TORU is just a new proposal, there is no standard and supported implementation for a rollup node, which makes complicated to experiment with TORUs on Tezos.

Marigold, Nomadic Labs, TriliTech, Oxhead Alpha, Tarides, DaiLambda, Functori & Tweag have developed an experimental rollup node. This post aims to explain how to set it up to make experimentation easy… and maybe give you amazing project ideas with rollups and Tezos.

How to Deploy

Prerequisite

You must know how to setup an environment from scratch

Get unreleased Tezos binaries

First, run the below commands:

git clone git@gitlab.com:tezos/tezos.git
cd tezos
git checkout master
opam init # if this is your first time using OPAM
make build-deps
eval $(opam env)
make build-unreleased
export PATH=$(pwd):$PATH

Set Jakartanet Tezos endpoint as default. You can use Marigold testnet node with this command:

$ tezos-client --endpoint https://jakartanet.tezos.marigold.dev config update

Create your wallet

Create a new key pair, which will be named mykey:

$ tezos-client gen keys "mykey"

Create a faucet wallet and transfer Tez to your wallet

The easiest way to get some testnet Tez is through the faucet website. Download the JSON file and rename it to faucet.json, then run the following to transfer from the faucet to our wallet:

$ tezos-client activate account faucet with faucet.json
$ tezos-client transfer 100 from faucet to mykey --burn-cap 0.5

Create Rollup

Execute this command to originate a transaction rollup:

$ tezos-client originate tx rollup from mykey --burn-cap 100 

The last command will output a result similar to this (you will need the yellow information):

    
Estimated storage: no bytes added
Estimated gas: 1420.108 units (will add 100 for safety)
Estimated storage: 4000 bytes added (will add 20 for safety)
Operation successfully injected in the node.
Operation hash is 'opPs1d922NToh1Cz9Yv4BA9xUmnH66jATQcHwv7GFuGhaARg6K1'
Waiting for the operation to be included...
Operation found in block: BM1cyUa9pqcQ6HERd3pwL3ZQfBovau4RXYYTji7EXYscMHftHD2 (pass: 3, offset: 0)
This sequence of operations was run:
  Manager signed operations:
    From: tz1TVH5FbvDj7cJ5YLDGCt9gMExmDdgo3T8a
    Fee to the baker: ꜩ0.000358
    Expected counter: 10815
    Gas limit: 1000
    Storage limit: 0 bytes
    Balance updates:
      tz1TVH5FbvDj7cJ5YLDGCt9gMExmDdgo3T8a ... -ꜩ0.000358
      payload fees(the block proposer) ....... +ꜩ0.000358
    Revelation of manager public key:
      Contract: tz1TVH5FbvDj7cJ5YLDGCt9gMExmDdgo3T8a
      Key: edpkvYpC5HJqGydSmAD6TWgnbYooNMstumXckFLGa5Qd7eEbysdLQm
      This revelation was successfully applied
      Consumed gas: 1000
  Manager signed operations:
    From: tz1TVH5FbvDj7cJ5YLDGCt9gMExmDdgo3T8a
    Fee to the baker: ꜩ0.000283
    Expected counter: 10816
    Gas limit: 1521
    Storage limit: 4020 bytes
    Balance updates:
      tz1TVH5FbvDj7cJ5YLDGCt9gMExmDdgo3T8a ... -ꜩ0.000283
      payload fees(the block proposer) ....... +ꜩ0.000283
    Tx rollup origination:
      From: tz1TVH5FbvDj7cJ5YLDGCt9gMExmDdgo3T8a
      This tx rollup origination operation was successfully applied
      Balance updates:
        tz1TVH5FbvDj7cJ5YLDGCt9gMExmDdgo3T8a ... -ꜩ4
        storage fees ........................... +ꜩ4
      Consumed gas: 1420.108
      Originated tx rollup: txr1hm5soQNtN1N4j1Fu5mMSPyPVeACgzaixq

The operation has only been included 0 blocks ago.
We recommend to wait more.
Use command
  tezos-client wait for opPs1d922NToh1Cz9Yv4BA9xUmnH66jATQcHwv7GFuGhaARg6K1 to be included --confirmations 1 --branch BMByD7vQKo2RTR1ck3jmHSEbZEkawJzMsg4zZPWYNuockHXe7Wk
and/or an external block explorer.
    
  

Configure Rollup

Now that we have a operator (mykey), rollup-id (originated tx rollup), and rollup-genesis (operation found in block). We can configure the rollup node with the previous information:

$ tezos-tx-rollup-node-013-PtJakart config init on \
--data-dir "$HOME/rollups" \
--operator tz1TVH5FbvDj7cJ5YLDGCt9gMExmDdgo3T8a \
--rollup-id txr1hm5soQNtN1N4j1Fu5mMSPyPVeACgzaixq \
--rollup-genesis BM1cyUa9pqcQ6HERd3pwL3ZQfBovau4RXYYTji7EXYscMHftHD2 \
--rpc-addr 0.0.0.0:9999

Run Rollup Node

Run the rollup node with this command:

$ tezos-tx-rollup-node-013-PtJakart --endpoint https://jakartanet.tezos.marigold.dev \
run --data-dir "$HOME/rollups"

Done, now you have a rollup node running on Jakartanet testnet!

:warning: This rollup node is still experimental and must not be used as is on mainnet. We encourage you to build, test and audit your own node before releasing a rollup.

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

3 Likes

This is great, but seems incomplete. How do I send xtz to txr1hm5soQNt... on the rollup node? How do Alice and Bob send xtz back and forth on the rollup node? Do I need a special tezos-client and “point” it to the rollup node?

2 Likes

You never send xtz to a rollup address, rollups only have tickets.
How to deposit a ticket is explained in developer documentation linked in the post.

This post is ops oriented to explain how to run the experimental rollup node so that it gives an example to rollups devs about originating a rollup in the protocol. DApps developers can start to develop Tezos smart contracts that deposit tickets to a rollup to evaluate protocol proposal.

Layer2 internals are depending of each rollup implementation and are not part of the protocol.

Some examples on how to use the example node would come in later posts.

This example no longer works as written, at least on the current master branch. In particular, the tezos-tx-rollup-node-013-PtJakart daemon needs a mode option.

Is there a comprehensive, current, accurate description of how to run TX rollups in jakartanet somewhere?

Would be cool to get a similar guide for running a rollup node to test SCORU

You have the documentation on how to deploy a rollup here Smart Optimistic Rollups — Tezos (master branch, 2023/02/27 06:59) documentation

The difference between TORU & SORU is that TORU was 1 rollup only about transactions, which included a ticket ledger, so i was straight forward to transfert from L1 to L2.
SORU is a framework to build any rollup, so what & how you can transfert (ticket or token or anything) between L1 and L2 depends of each rollup kernel implementation.

Messari made a great infography about different kind of rollups

SORU is a framework for sovereign rollups.

With Mumbai comes everything you need to build your “Smart Rollup” which our naming for “App-Specific Rollup”. Each rollup will have to implement its bridge. Ticket (more ever when FA2.1 will be finalized and validated) would help but it’s not mandatory, one can implement a FA1.2 or FA2 bridge.

Later will come a EVM rollup and likely more later a Michelson rollup which are 2 kind of general rollups.

1 Like

Thanks this makes sense. So the real name abbreviation is not SCORU but SORU?