What's Cooking for Smart Rollups in Nairobi?

TL;DR: The Nairobi protocol upgrade brings new features and improvements to Smart Rollups that will make life easier for developers.

Mumbai has only just found its way to Mainnet, and a new protocol amendment is already being proposed to the community: Nairobi.

As mentioned in the Nairobi announcement, the upgrade brings several quality of life improvements for developers of Smart Rollups. This blog post is an introduction to these new features. It is aimed at developers who are already familiar with Smart Rollups, but includes context and links to existing documentation for less versed readers.

First and foremost, it is important to understand that every new feature covered by this blogpost will benefit every Smart Rollup on Mainnet, including those deployed prior to activation of Nairobi. Hence you can already deploy your Smart Rollup today, and benefit from the new features once Nairobi reaches Mainnet (though you will need to upgrade your kernel for some of them).

This “free upgrade” in Nairobi is a good example of the advantages that come with Smart Rollups being enshrined - i.e. part of the Tezos protocol itself. It is also a first re-affirmation of Tezos core developers’ commitment to continuously maintain and improve Smart Rollups.

The Protocol_migration Internal Message #

Internal messages are a particular kind of message sent to the Smart Rollups shared inbox by the Tezos protocol itself. In Mumbai, there are four kinds of internal messages:

• Start_of_level is the very first message of the shared inbox in every Tezos level.
• Info_per_level comes just after Start_of_level and provides some information about the Layer 1 progress (namely, the block hash and timestamp of the previous Tezos block).
• Transfer messages are injected by the protocol when a Michelson smart contract performs a contract call targeting a Smart Rollup.
• End_of_level is the very last message of the shared inbox for any Tezos level.

Nairobi introduces a new kind of internal message, called Protocol_migration. This message will be injected by the protocol after Info_per_level for the very first block of a given Layer 1 protocol. This way, Smart Rollup kernels can be made aware of new protocol activations. This opens new possibilities, like a kernel taking advantage of new features as soon as they are available.

The Typed_transactions_batch Outbox Message #

In Mumbai, Smart Rollup kernels can interact with Layer 1 thanks to their outbox. More precisely, they can send operation batches which can be executed in the Layer 1 as soon as the commitment containing them is cemented, i.e. can no longer be refuted.

However, these batches have a potential flaw, in the sense that they are untyped. This is an issue, because some Micheline expressions can potentially have several valid types. Worst case scenario, a kernel could potentially be tricked into withdrawing tickets by mistake. Even if this cannot be used to forge tickets on the Layer 1 (which is well protected against tickets forgery), this could potentially allow attackers to drain a vulnerable rollup.

To prevent such a scenario, Nairobi introduces a new kind of outbox message which allows the kernel to specify the types of the batched transactions it wants to execute on Layer 1.

The First WASM PVM Upgrade #

In our communications about Smart Rollups we have continuously emphasized how the runtime of Smart Rollups, the WASM Proof-generating Virtual Machine (PVM), allows for installed kernels to be upgraded.

But that isn’t all. In Nairobi we demonstrate that the WASM PVM itself is also upgradable.

A kernel can inspect the version of the WASM PVM executing it by looking at its durable storage, more precisely under the key /readonly/wasm_version. The version name of the PVM released in Mumbai is 2.0.0.

This can be verified using an up-to-date [octez-smart-rollup-wasm-debugger], which also provides an option to choose which WASM PVM to use when debugging (with the -p option).

Nairobi introduces the first revision of the WASM PVM, version 2.0.0-r1, which is key to the new features contained in the protocol upgrade. Every Smart Rollup originated in Mumbai will see their PVM upgrade automatically at the beginning of the first block of Nairobi, should the protocol amendment be adopted by the community.

The new version is fully backwards compatible with the interactive fraud proof system introduced in Mumbai: refutation games started before the activation of Nairobi will not be affected by the presence of these new features.

Stack Size Limit #

In version 2.0.0 of the PVM, the stack of a kernel is limited to 300 stack frames. This value was inherited from the reference WASM interpreter, but early adopters of Smart Rollups quickly reported it to be fairly limited, and hard to satisfy. To this day, octez-smart-rollup-wasm-debugger is still lacking the feature to tell you how many frames at most have been created by kernel_run invocations. Besides, Wasmer (the standard execution engine used for Smart Rollups when no proof is required) does not limit its own stack in terms of frames count, but rather in terms of memory usage.

As a consequence, in version 2.0.0-r1 the stack size limit of the WASM PVM has been bumped significantly to ensure that as long as Wasmer is able to execute a kernel, the WASM PVM can execute it too. This should make the lives of kernel developers easier.

Two New Host Functions #

Finally, version 2.0.0-r1 of the WASM PVM introduces two new host functions:

• store_create lets you preallocate large values in the durable storage almost for free, ticks wise. It is analogous to calling truncate to an empty file in most file systems.
• store_delete_value is the counterpart of store_delete, restricted to the value under a given key. The durable storage allows a given key to be both a value and a directory, and store_delete deletes both.

The following figure summarizes the difference between the two. Consider a durable storage which contains three values, at /foo, /foo/bar and /foobar. Calling store_delete with /foo as its argument also removes /foo/bar, while store_delete_value will leave /foo/bar untouched.

Warning against store_get_nth_key #

Please note that the store_get_nth_key host function is now considered harmful. While it has not been removed from the WASM PVM set of host functions, we advise kernel developers to not use it, as it has been discovered that its behavior is potentially incompatible with the refutation game.

Kernels which do not use this host function are safe, and we see no indication of this issue affecting the other host functions.