Optimistic rollup enabled with Tezos VM running on top of Tezos L1.
IMPORTANT: NOT STABLE YET, DO NOT RUN THIS CODE IN PRODUCTION
The goal of this project is to create permissioned application-specific Tezos-compatible rollup that has:
- Reduced operational costs (contract automation, oracles)
- Custom MEV-resistant solution
- Chain-native tokenomics
- Feeless experience
- Contract wallets as first-class citizens (account abstraction)
Rollupnet
is a public deployment of the smart rollup operator + Tezos-compatible facade node, it is used mostly for testing and demonstrating purposes.
Public endpoint:
You need to add custom network to your wallet, if you want to interact with the rollupnet
. Check out this tutorial on how to add custom RPC provider to Temple wallet: https://www.youtube.com/watch?v=VzeSFdna8Vk
Import one of the following bootstrap keys:
edsk3gUfUPyBSfrS9CCgmCiQsTCHGkviBDusMxDJstFtojtc1zcpsh
edsk39qAm1fiMjgmPkw1EgQYkMzkJezLNewd7PLNHTkr6w9XA2zdfo
edsk4ArLQgBTLWG5FJmnGnT689VKoqhXwmDPBuGx3z4cvwU9MmrPZZ
edsk2uqQB9AY4FvioK2YMdfmyMrer5R8mGFyuaLLFfSRo8EoyNdht3
edsk4QLrcijEffxV31gGdN2HU7UpyJjA8drFoNcmnB28n89YjPNRFm
We have a dedicated instance of Better Call Dev explorer for periodic test networks including rollupnet
:
You can use it to deploy and interact with smart contracts using web interface.
- With the current limit (4096 bytes) for inbox messages you won't be able to deploy large smart contracts
- Some Michelson features are not yet supported, so you might not able to deploy contracts containing particular opcodes
Your feedback is extremely valuable, and we also expect lots of bugs at early stage, so please contact us if anything works not as expected:
Install Rust toolchain:
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
Add Wasm32 target:
rustup target add wasm32-unknown-unknown
Install build dependencies:
make install
Create wasm file for the payload kernel:
make build-kernel PACKAGE=tezos_kernel
Convert payload kernel into 4kb pages and create a boot wasm file:
make build-installer PACKAGE=tezos_kernel
Create a binary for the facade node:
make build-facade
Creates local images out of the pre-built artifacts.
Requires installer kernel and generated pages.
Note the environment file included in the Makefile, that exposes OCTEZ_TAG
, OCTEZ_PROTO
.
make image-operator PACKAGE=tezos_kernel
make image-facade
Note the environment file included in the Makefile, that exposes target NETWORK
.
Depending on the target package run:
make run-tezos-operator
You will end up inside the docker container shell.
Every time you call this target, kernel and docker image will be rebuilt.
For convenience, your local .tezos-client folder is mapped into the container in order to preserve the keys. Upon the first launch you need to create new keypair, in order to do that inside the operator shell:
$ operator generate_key
If you already have a key, check it's balance: it should be at least 10k tez to operate a rollup, otherwise top up the balance from the faucet. To get your account address:
$ operator account_info
$ operator deploy_rollup
Rollup data is persisted meaning that you can restart the container without data loss. If you try to call this command again it will tell you that there's an existing rollup configuration. Use --force
flag to remove all data and originate a new one.
$ operator run_node
Runs rollup node in synchronous mode, with logs being printed to stdout.
Also RPC is available at 127.0.0.1:8932
on your host machine.
Run tezos node binary with debug logs enabled:
$ make run-facade
Every time you call this target tezos node binary will be rebuilt.
Once you have both operator and facade images built, you can run them together with compose.
First, create a .env
file with four environment variables:
TAG=<operator image tag>
NETWORK=<destination network name>
ROLLUP_ADDRESS=<sr rollup address from node logs>
OPERATOR_KEY=unencrypted:<edsk private key from .tezos-client folder>
Then run docker-compose:
docker-compose up -d
Make sure you have nextest installed:
cargo install cargo-nextest --locked
Run all tests:
make nextest
Prepare inputs using notebooks (make sure you have Python installed):
jupyter notebook
# navigate to scripts folder
Build kernel in debug mode, create docker image, and run REPL:
make debug-kernel PACKAGE=tezos_kernel
Populate rollup inbox:
> load inputs
Run kernel:
> step inbox
Make sure kernel state is updated:
> show key /head
Known issues:
getrandom
(does not compile since version 0.2.10) => use patched version[patch.crates-io] getrandom = { git = "https://github.com/baking-bad/getrandom", branch = "patch/0.2" }
SCORU host does not support operations with floating point thus one need to make sure none of the dependencies introduces them.
Don't forget to use wasm-strip
to eliminate dead code.
Known issues with common crates:
serde_json
=> useserde-json-wasm
insteadnum-bigint
(floats used into_radix_str
andfrom_radix_str
) => useibig
instead
In order to trace back float usage, first build kernel with debug info and generate .wat
file:
make wat
Search for f64
and f32
substrings and unwind calls up to the crate level.
Some of your dependencies use wasm-bindgen
and mistakenly treat wasm32-unknown-unknown
target as browser env.
Make sure you have disabled features that do so, or replace such dependencies.
Known issues with common crates:
chrono
=> disableclock
feature
- Tezos SCORU & Kernel SDK — Nomadic Labs and TriliTech teams
- Tezos Rust SDK — Papers team
- Thanks to @emturner and @romarq for accepting my PRs :)