# Draft Abstracts for Protocol L Preview post

## SCORU + WASM PVM enabled

<span style="color:red">**Status of the feature flag? OFF**
</span>

Smart-Contract Optimistic Rollups (SCORU) have been released under a disabled feature flag as part of the Kathmandu protocol. SCORU generalizes Transactional Optimistic Rollups (TORU) to allow for arbitrary computations running in Proof-generating Virtual Machines (PVMs).

Even though the SCORU architecture is generic with respect to the actual definitions of the PVM, a specific PVM implementation, supporting the WebAssembly (WASM) language, is included in Protocol Lima: as a consequence, a user can originate a rollup by providing a WASM program -- called a kernel -- to interpret any L2 operations targetting the rollup. These L2 operations may contain tickets to transfer assets from L1 accounts to rollups. A kernel may also produce asynchronous transfers of tickets from the rollup to L1 contracts. A mechanism of data revelation is introduced in Lima: it allows data from sources external to the L1 to be imported in a rollup.

Anyone can write a WASM kernel. An example of kernel is available [online](http://www.gitlab.com/trili/kernel). This kernel reimplements the functionality of TORUs, that is, transactions between accounts inside the kernel.

Because the WASM PVM is still in a *Beta* state, please note that the SCORU subsystem is still *disabled* on MainNet. However, SCORU is *enabled* on MondayNet: we encourage the ecosystem to start building WASM kernels and to give us feedback about its usability.

## Pipelining 2

<span style="color:red">**TODO: GAD/VB update wrt to merged changes**
</span>

Pipelining (part 2) continues to dissociate the validity from the applicability of operations and blocks in order to speed up their processing; i.e. verifying that a block or an operation is valid, which is a light operation, means that it cannot go wrong anymore and does not require a further application to proceed. This goes further as the baker daemon will not need to apply blocks anymore to produce blocks: it will now simply retrieve a commutable set of *valid* operations from the node and order those as it chooses to instantly produce a valid block that has the guarantee to be applicable. Effectively, this will half the time of block production as only the node will apply the block. However, the node will only check that the block is valid before advertising it, which is significantly faster than waiting for it to be applied. Thus, blocks will only take up to a few milliseconds to be produced and broadcast rather than a few seconds and the validation of blocks will be pipelined next. This will enable us to reduce block times furthermore in the near future. We also introduce concurrent bricks in the protocol that will allow us to move from an incremental mempool to a parallel one while ensuring the previously mentioned guarantees.

## Consensus Key

<span style="color:red">**Status?**
</span>

We allow bakers to designate a key to sign baking, endorsement and preendorsement operations, together known as consensus operations, instead of using their default key. This allows for better separation of concerns and periodic rotation of the consensus key without the need for re-delegation.

- Resources:
- Post by Nicolas Ochem: https://midl-dev.medium.com/a-consensus-key-for-tezos-bakers-16a3ac8178cf

## Improvements to Tickets

<span style="color:red">**Status?** NB: this para summs up three different _small_ projects:
</span>

We are deprecating creation, storage and transfer of zero-valued tickets, that is tickets which hold 0 tokens. In doing so, we introduced a breaking change in the `TICKET` instruction. Now this instruction pushes a ticket wrapped in `option` so that a `Some` value indicates a ticket constructed successfully, and a `None` indicates that ticket creation failed, and having zero amount is a plausible cause.

In addition, we now enable the transfer of tickets to implicit accounts via the existing transaction facility. By following a format when specifying the ticket type and content in the transaction parameters, contracts and implicit accounts may send one type of ticket to other implicit accounts.

Furthermore, we added ticket ownership updates to the transaction receipts. This enables indexers to maintain a table that tracks which accounts own what types of tickets by traversing the receipts. For L, we will only include this information for ticket minting/removal within a single contract and transfers between originated contracts. In upcoming upgrades, we will cover all combinations of transactions between implicit accounts, originated accounts, and rollups -- TORU and SCORUs. You can find the design document [here](https://hackmd.io/@marigold-dev/SyLXJQcJs).

<span style="color:red">**TODO**: links to documentation or design documents might help!
</span>

- Resources:
- Marigold blog post on Tickets w/ zero amounts: https://www.marigold.dev/post/remove-support-for-tickets-with-zero-amount
## LB sunset removed
<span style="color:red">**Status**?
</span>

The liquidity baking sunset will be removed since the subsidy can now be shut off with the moving-average toggle introduced with Jakarta.

<span style="color:red">**Status**?
</span>

## Timelock Temporary Deprecation

<span style="color:red">**TODO: Frej/MS/GAD**
</span>

## Improved gas accounting for metadata

<span style="color:red">**TODO: BC/FS/GAD**
</span>

## SNARK Rollups technology preview on testnets

A technology preview of Tezos' enshrined SNARK Rollup, is available on testnets.
This preview exposes in the Tezos' economic protocol an API which can host a large class of SNARK
Rollups and the first instance to be originated on testnets will be a simple transactional rollup for tickets that we estimate can reach ~2000 tps.

This form of rollup allows for instant finality thanks to their SNARK proof-of-validity, as opposed to the proof-of-fraud of Optimistic Rollups.
Furthermore data-availability becomes optional allowing for application to keep their state and transactions private with respect to the L1.

Our proving system is still evolving its proof aggregation capability and promises large scaling improvements for the next version that will be included in M.
New rollups are also in the works to provide even faster transactions and more complex applications.

## Bigmap and tree optimisation
The local context introduced for protocol storage allows relative access. The performance of the process of deleting implicit contracts is improved.
Gas consumed remain the same.

## New Michelson operations for bytes

We are planning to extend Michelson opcodes `AND`, `OR`, `XOR`, `NOT`, `LSL` and `LSR` to support logial operations on `bytes`. Their semantics are pretty similar to those on `nat`.

## Fixing up Ghostnet
<span style="color:red">**TODO: PirBo/GAD**
</span>
On Ghostnet test network, 2 problems arose during the migration from Jakarta to Kathmandu that we fix:
- the VDF feature activated itself with the same difficulty as on Mainnet but cycles are 4 time shorter! So there is no possibility to find a solution to the challenge within the allocated time window. For this reason the difficulty of the VDF challenge on Ghostnet is changed to become mainnet_difficulty/4.
- The duration of a voting period changed from being 2 cycles long to be 1 cycle long but the changed occured at a critical moment: the end of a odd cycle aka a point in time which was not a voting period end with the Jakarta parameters but is with the Kathmandu one! Given the order in which the economic protocol updates things, that led to not changing the voting period but underflowing the "number of remaining blocks in the period". Now that we reached a "negative number of remaining block until the end of the voting period". Ghostnet will not switch to a new period by itself. That's why a "manual/force reset of the voting period" is sheduled for the migration on Ghostnet From Kathmandu.

## Assorted Breaking changes

- Protocol constant `tokens_per_roll` has been renamed to `minimal_stake`: the concept of rolls has been removed with Ithaca (for consensus rights) and Jakarta (for governance stake).
- `TICKET` instructions now have a different typing, returning an `option ticket cty` instead of simply `ticket cty`. Contracts already originated continue to work as their old `TICKET` instructions are migrated to `TICKET_DEPRECATED`. `TICKET_DEPRECATED` cannot be used in newly originated contracts.

<span style="color:red">**Please list others!**
</span>