By Pierre-Louis Dubois

If you started developing some kernels as explain in the previous blog post, you may reach the size limit of 24kB and have been facing a wall: your Tezos operation is too big to be executed. In this blog post, we will demonstrate how to deploy a kernel that is bigger than 24kB.

There are four steps to achieve it:
- reducing the size of your kernel,
- splitting your kernel into chunks of 4kB,
- setting up the kernel installer developed by the Tezos core developer,
- deploying the installer and your kernel

Prerequisites 📄

In this tutorial, I will assume you have read the previous tutorial and have all the prerequisites of it.

To sum up, you must know how to:

Let’s reduce the size of your kernel!

This step is not required, but highly recommended. There is a tool named wasm-strip that can drastically reduce the size of your kernel.

In this kernel.wasm example, assume its size is 2MB and store in the current directory.

$ wasm-strip kernel.wasm
Be careful, the wasm-strip command does not create a new file but replaces the original one.

Just after this command, your kernel should be smaller (32kB). You can verify the size of your kernel with ls:

ls -lh

If your kernel is smaller than 24kB, you are ready to go and you can originate your kernel as a normal operation. Otherwise, you should continue reading this post.

Let’s split your kernel

In the previous post, we have learned about the durable storage and what it is. Interestingly some files of the durable storage are also used for the correct execution of the kernel. One file that is important in our case /kernel/boot.wasm, this file contains the Wasm file of your kernel. If you update this file, your kernel will be updated.

That’s exactly what the kernel installer does. It’s a kernel that will read some data from the data reveal directory and update the /kernel/boot.wasm file.

To put data in the reveal data directory, the data must have a maximum size of 4kB, so that the refutation game can still work.

In this section, we will see how to split your kernel into many 4kB chunks. To split your kernel, we will use the Data Availability Comitee (DAC) with the legacy execution mode. The purpose of the DAC is to store data that is bigger than 4kB and make them available to the kernel into chunks of 4kB. To store them, the DAC will split the data into chunks of 4kB and then the kernel will have to merge these chunks to get back its data.

The legacy mode of the DAC is a HTTP server which accept data, split them into chunks, save them to a directory, and gives you a reveal hash.

If you have the Tezos source compiled, you will find the octez-dac-node binary in the Tezos root directory.

Let’s configure the DAC before using it:

$ mkdir dac
$ octez-dac-node configure as legacy with threshold 0 and data availability committee members --reveal-data-dir dac # The directory where your splitted kernel will be

Run the DAC node by running this command:

$ octez-dac-node run

The DAC will expose an endpoint http://localhost:10832/store_preimage to split bytes and store them as files under the reveal data directory.

When we have the DAC started, next step is to submit some bytes to it. The DAC only accepts bytes as hexadecimal, but currently, our kernel.wasm is not a hexadecimal value. We can use the command xxd to convert its format:

$ KERNEL=$(xxd -ps -c 0 kernel.wasm | tr -d '\n')

If you display this variable you should see a hexadecimal expression.

echo "{\"payload\": \"$KERNEL\", \"pagination_scheme\":\"Merkle_tree_V0\"}" | curl --silent --header "Content-Type: application/json" -X POST -d @- http://localhost:10832/store_preimage
> { "root_hash": "000389b989126c02e8c87fa101c4ccfd476a01896e43aa5206c94da9c7776d834d", "external_message": "..."}

With the command above, the DAC will return a root_hash. This root_hash will be used later, please save it. We have used the DAC to split our data into many 4kB chunks, converted it into a Merkle tree, and have the root_hash. You can stop the DAC execution and move to the next step.

Using the kernel installer

The kernel installer will read the reveal data directory of the smart rollup and update the /kernel/boot.wasm file.
To have a working installer, we will need to change its code to specify the correct root_hash (the root_hash of our kernel generated by the DAC).

First, let’s clone the kernel git repository.

$ git clone git@gitlab.com:tezos/kernel.git
$ cd kernel

To make sure everything is working, let’s try to compile it.

$ cargo make wasm-preimage-installer 

Then in the file installer_kernel/src/lib.rs, at the parameter ROOT_PREIMAGE_HASH replace its value with the root_hash generated by the DAC in the previous step.

// installer_kernel/src/lib.rs

Now we can compile the installer with the root_hash value.

$ cargo make wasm-preimage-installer 

The purpose of kernel installer is to help you to install a big kernel, but its size is still too big (690 kB) compared to a normal Tezos operation, so to originate it, we can use the wasm-strip to reduce its size (12kB). When stripped, the kernel installer will always be less than 24kB, it was designed to be a smaller kernel.

$ wasm-strip target/wasm32-unknown-unknown/release/tezos_rollup_installer_kernel.wasm
$ KERNEL_INSTALLER=$(xxd -ps -c 0 target/wasm32-unknown-unknown/release/tezos_rollup_installer_kernel.wasm | tr -d '\n')
$ cd ../

Deploying your kernel 🚀

At this step, you should have:

  • the files generated by the DAC (your split kernel)
  • the kernel installer compiled with your root_hash generated by the DAC

Before starting your smart rollup node, you will need to configure it.
Let’s create a data directory for your smart rollup rollup-data where the smart rollup node stores its data.

$ mkdir rollup-data

Then you will need to populate the reveal data directory named wasm_2_0_0 with the different files generated by the DAC.

$ mkdir rollup-data/wasm_2_0_0
$ mv dac/* ./rollup-data/wasm_2_0_0/

There is a file with the same name as your root_hash.

These steps below will be similar to deploy a normal kernel.

First, we need to originate the smart rollup in Tezos:

$ octez-client originate smart rollup from "bob" \
  of kind wasm_2_0_0 \
  of type bytes \
  with kernel "${KERNEL_INSTALLER}" \
  --burn-cap 999
Replace "bob" with your account alias.
Bob should have enough tez to deploy the smart rollup.

If everything went well, the origination will return the smart rollup address (as “SOR_ADDRESS …”), this address will be used later as a variable to start a smart rollup up node in the next step:

SOR_ADDR=sr1732roAk1iHKDsdp5jmyJpbyAAngvufAEp # please update with your smart rollup address

Let’s configure the smart rollup node by specifying the data directory of the smart rollup, and who is the operator. The operator has to have 10,000 tez to be able to send the operation from smart rollup to Tezos chain.

octez-smart-rollup-node-alpha \
  init operator config for "${SOR_ADDR}" \
  with operators "bob" \
  --data-dir "rollup-data"

Let’s run this smart rollup node:

$ octez-smart-rollup-node-alpha run --data-dir "rollup-data"

You will have to wait for the first execution of your kernel to be installed. You may need to wait for one Tezos block.

Now we have a smart rollup node that is running the kernel written in Rust (in the previous post), we can choose to either submit new operations to the inbox, restart, or stop this node.

Voilà 🎉

In this blog post, you learned how to originate a kernel bigger than 24kB on Tezos. To do so, you learned how to:

  • reduce the size of your kernel,
  • split with the DAC,
  • use the kernel installer.

In the next blog post, we will demonstrate how to send operation(s) from the smart rollup to a Tezos smart contract.

Bonus 👀

This week, the Tezos core team has released a tool to create a kernel installer. Which means you won’t need to start the DAC nor edit code, the only things you will have to do is one command. This command line interface aims to make it much simpler to originate your kernel.

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

Scroll to top