# Rock n rollup "roadmap"

This document represent a rough roadmap of the `rock-n-rollup` project.

Quick remember: the goal of this project is to ease the development of kernels.

So this project is mainly about tooling and developper ux.

Because it's opiniated we can integrate in the sdk some features some developpers may want to develop theirself.

## A real high level sdk

`rock-n-rollup` is using its own binding to the hosts function, it has to use the `tezos-smart-rollup` sdk.

## Token Bridge

It would be nice to implement a way to bridge tokens.
So that if the developper want to use a L1 token it can use it without wondering too much how to do it.

At first, we can implement a cTez bridge.

Then inside the kernel it would be nice to have an interface like this:

let () = ctez.transfer(bob, alice, 5); // Transfer ctez from bob to alice
let amount = ctez.amount(bob); // Retrieves the amount of token of bob
let () = ctez.withdraw(alice, 2); // Withdraw ctez to the L1.

## Ledger for L2 tokens

It would be nice to give a way to manage l2 tokens with the following interface:

#[derive(Serialize, Deserialize)]
struct Token {
    some_metadata: String
}

let () = ledger.mint::<Token>(bob, 5); 
let () = ledger.transfer::<Token>(bob, alice, 2); 
let () = ledger.burn::<Token>(bob, 2);
let amount =  ledger.balance::<Token>(bob);

Then developper could use a ledger to what they want, like managing the inventory of a player in a game.

## Random

`rock-n-rollup` should implement a way to allow Random with a `commit-and-reveal` algorithm. So that using random in an application will be very easy.

If a bound have to be made, ctez can be used

## Framing Protocol

Today the tezos core dev team has implemented a routing protocol.

Basically it allows a message to be rooted to a precise rollup.

That's nice. But we need more.

We need a protocol to avoid replay attacks and to know who is sending the external messages. Which means signature and nonce management

We can also add a name for the entrypoint instead of a tag like in smart contract.

A framing protocol could look like this:

[<external-message-tag>, <framing-version>, <rollup-address>, <entrypoint-name>, <public-key>, <nonce>, <signature>, <payload>]

## Receipts

On each message the rollup can generate a receipt, and store it under `/receipts`:

## Ticket Upgrade strategy

The rollup can accept a byte ticket, if the ticket comes from a known smart contract and the bytes can be deserialized to a reveal preimage hash, the rollup can read the data reveal channel and proceed to the upgrade

## External Message Upgrade strategy

When receiving a partical external message from a given address, if the payload is a reveal preimage hash, the the rollup can read the data reveal channel and proceed to the upgrade

## External Message Multi Sig Upgrade strategy

Same but with BLS to support multi-sig

## Custom Upgrade Strategy

Same but should allow people to develop their own strategy
This generic solution should be the base of the others

## Be compatible with the sequencer

`rock-n-rollup` should implement a function kernel_entry with the right signature (see the requirement of the sequencer).

## Serde

Is it possible to implement Serialize and Deserialize for Nom? It would be awesome.

## Tests

`rock-n-rollup` is poorly tested, the sdk has to be tested

## Test Framework

Testing rust is easy, using the octez-wasm-debugger is not. It would be nice to provide a way to measure tick consumptions in tests.

fn test() {
    assert_ticks(runtime, my_transition, 50_000_000); // Will check if the transition consume a maximum of 50M ticks
}

The `octez-wasm-debugger` can be used under the hood

## Reboot strategy

`rock-n-rollup` should find a way to automatically reboot the kernel when the limit of ticks is near to be reached.

## Cli

It would be nice to have a cli to ease the start of development of rollups:

rock-n-rollup init <project>

## Dry-run node

It would be nice to have a way to run a rollup node without a tezos network.

When developping an application, having a fast feedback is really appreciated.

Today the feedback loop is very slow:
1. Develop
2. Deploy
1. Split the kernel
2. Set up the rollup (30s)
3. Start the rollup
3. Feedback!

## Cors

The octez-smart-rollup-node does not support CORS. It means it's impossible to develop a front-end application without setting up a reverse proxy, IMO people will give up without CORS.

## Typescript client

It would be nice to implement a typescript client to send operations to the rollup and to get the state.

## Smart Rollup Node Streams

To get the state of the rollup, the client has to fetch the rollup for each entry of the durable storage.

The client can't know what have been changed/updated in the durable storage. So the client has to make a lot of http request to the rollup.

The number of request is not exponnential, but many clients imply many requests.

A way to reduce the requests would be to stream the merkle-tree, so that the client knows what have changed (by comparing the merkle tree), then the client can make the appropriate request to retrieve the value.

However this feature can be implemented with a proxy node.

## Better durable storage

Maybe only michelson should be stored in the durable storage.
Or at least, we need a way for indexer to index the storage of a rollup.

Some tzip has to be written, at least for:
- receipts
- accounts
- ledger
- token bridges
- etc?

Maybe these tzip have to be think when developping the corresponding feature.

## Cleaning the code and audit

The code have to be clean, and it would be nice to have feedback on the code after the cleaning phase.

The goal is not to have feedback about opinions of the lib, but more about the architecture of the lib.