# Tezos

# Email

> In this regard, may I ask you to work out a plan of what work needs to be done, within what time frame, taking into account the circumstances mentioned, so that the agreed milestones and the purpose of the grant can still be fulfilled?

> I will gladly take this summary with me to discuss it with my team.

Hi Nicolas,
Thanks for coming back to us and as requested, here are the requirements:

For completion by 31 October 2022 by Istvan and Matej:
• 3 existing use cases require content written which is to be added to the website.
• 4 additional use cases need to be developed and content written for the website as follows:
1) DeFi primitives: distribute incentives to staked token balances custodied in a smart contract. [for Devs + UI]
2) Smart contract architecture for upgradability and cross contract interaction. (insights and learnings from wXTZ running in production over 1 year)
3) Token interfaces, FA1.2., FA2 tzip - simple UI to check for active allowances. [beginner Devs & UI]
4) Tickets and all of the latest additions in jakarata (that is the validation layer): [advanced devs]

In addition to the above, we have discussed within our expanded team some really great things we could provide to enhance the ecosystem - including new devs who are RUST, UI and testing specialists - who could focus on Optimistic Rollups for example, but that’s just a small part of what we have in mind.
We’ve booked a meeting with you for Tuesday – because it’d at least be great to meet you properly!
Have a great weekend Nicolas, and we look forward to chatting with you!

## Status-quo

9 use-cases needed

Have submitted 4 use-cases, but built only content for notary.

Need for 4 additional use cases.

## PoC idea bucket

Concepts:
* farming
* time-lock
* tickets
* on-chain views with parameter
* global constants
* sapling
* contract events
* Verifiable Delay Functions VDF (randomness)

Easy dApp (could be marketing):
* check for all FA1.2 and FA2 token allowances

Advanced for future project:
* RUST/WASM for SCORUs - writing custom kernel for Tezos (transaction engine)
* PoC could be for sending assets using the kernel
* need to know about tickets
* could be also its own exchange AMM in L2, which needs to be in WASM/RUST

### Use-case #1: Active allowance checker
Users should learn about FA1.2, FA2, TZIP and interfaces. We build a website that enables to user to check for active FA1.2. and FA2 token allowances.

### Use-case #2: Farm launcher
Launching your farm with a website.
We provide code + content how the farm works. We build a farm launcher. Free of charge to use it. FA1.2 compatible

### Use-case #3: Ticket
FA1.2 to ticket exchanger

## Concepts

### Tickets
Simplest explanation of what it is:
In ERC20/FA1.2 you do not hold the token, but the ledger in the smart contract does. Thus each token has a smart contract. With tickets this is different, because they are recognized on a protocol level and can be moved independently of a smart contract.

[Marigold Ticket Intro](https://www.marigold.dev/post/tickets-for-dummies)

new validations for tickets
* [ticket accounting feature](https://hackmd.io/lutm_5JNRVW-nNFSFkCXLQ?view) (balance table) and the [PR](https://gitlab.com/tezos/tezos/-/merge_requests/3495)
* [ticket scanner API](https://gitlab.com/tezos/tezos/-/merge_requests/3591) to scan for ticket value and type

### Timelock
Block miners can "front-run" certain transactions. Real name is not front-running, but "Miner Extractable Value" (MEV in ETH community) or "Block Producer Extractable Value". Solution is a time-lock encryption / time-lock puzzle.

New types:
* `chest`, which represents time-locked arbitrary bytes with the necessary public parameters to open it.
* `chest_key`, which represents the decryption key, alongside with a proof that the key is correct.

New Opcode
`open_chest :: chest_key → chest → time → or (bytes, bool)`

> open_chest takes a chest and chest_key, and produces either the underlying plaintext or indicates that the chest or the chest_key is malicious.

[Proof of conept in .ml](https://gist.github.com/murbard/23a29454a107d03d8a98393b0b98466d)
[Docs](https://tezos.gitlab.io/alpha/timelock.html)
[nomadic labs article](https://research-development.nomadic-labs.com/timelock-a-solution-to-minerblock-producer-extractable-value.html)

### On-chain Michelson views
[TZIP](https://gitlab.com/tezos/tzip/-/blob/master/drafts/current/draft_views.md)

### Global constants
`Tezos-client` is used to save a Micheline expression in a global table of constants. Multiple smart contracts can reference by the index to that code.

Advantage:
* originate large(r) contracts
* share code between contracts

### Transaction Optimistic Rollups (TORUs)
Needed for decentralized L2. Tezos ecosystem wants to encourage developers to build rollup infrastructure (opportunity?!). Still at experimental stage for Tezos, therefore it is introduced with a "sunset" of 1 year.

To understand TORUs, we need to have good knowledge of Michelson tickets, because deposited assests in rollups are represented as such.

[Nomadic Labs intro](https://research-development.nomadic-labs.com/toru-introduction.html)
[Using a TORU](https://research-development.nomadic-labs.com/toru-introduction.html#using-a-toru)

### A note on zero-knowledge, TORUs, zk-rollups and zk-proofs
Problem:
> Sending assets to a rollup and transacting inside it has the same finality as the main chain. But to withdraw assets back to the main chain, you must wait for the dispute period to pass. On Arbitrum, a popular rollup system on Ethereum, the period is currently seven days.

Solution:

> In parallel to the work of implementing optimistic rollups, we are therefore also exploring zero-knowledge rollups, or zk-rollups.

> The principle of moving transactions off-chain and posting commitments to the main chain is the same as with optimistic rollups, but zk-rollups attach a cryptographic proof of correctness with the commitment. No need for a waiting period for withdrawals.

Drawback:

> The downside is that zk-proofs are currently highly time consuming to generate. It requires a disproportionate amount of computing power, especially when dealing with smart contracts. The zero-knowledge team at Nomadic Labs is however working on improving this.

(Opportunity for RUST/WASM in Client/UI?)

[Nomadic source](https://research-development.nomadic-labs.com/tezos-is-scaling.html)

### TODO: Sapling Protocol
Used for privacy preserving transactions. A user can send tez to a shielded pool (shielding). Within the shielded pool transactions are private. When a user wants to access the tez, he/she needs to withdraw from the shielded pool (unshielding).

### Call for builders TODO: Understand long term opportunity WASM/RUST Tezos Kernel

https://research-development.nomadic-labs.com/next-generation-rollups.html#calling-all-builders

### TODO: Verifiable Delay Function (VDF)
Improved randomness.
TODO: Find out if accessible by smart contracts.
Use cases:
* NFT minting
* gambling

### Contract Events
On-chain events.

[GitLab](https://tezos.gitlab.io/alpha/event.html)

## Overview on protocol upgrades

### Note on EDO2 (not exhaustive)
* Sapling protocol

### Granada 7th upgrade (Aug 2021)
* Blocktime 30 sec instead of 60 sec
* Liquidity baking (tez<->tzBTC)
* Gas cheaper

### Hangzhou 8th upgrade (Dec 2021)

* on-chain Michelson views
* global constants
* gas cheaper thanks to cache (new [RPCs](https://tezos.gitlab.io/protocols/011_hangzhou.html#cache))

### Ithaca 9th upgrade
> A new `SUB_MUTEZ instruction has been added, it is similar to the mutez case of the SUB instruction but its return type is option mutez instead of mutez.

* ditching roll-based model for bakers
* instead rewards based on current stake
* min stake reduction: XTZ 8k -> 6k required to be a validator
* stake not frozen for 5 cycles, but credited instantly

### Jakarta 10th upgrade (28th June 2022)
* Transaction Optimistic Rollups (TORUs)
* decentralized Layer 2 solution
* smart contract TORUs comes later (SCORUs)
* [opens up Tezos](https://research-development.nomadic-labs.com/next-generation-rollups.html#opening-up-tezos) to RUST developers
* more work to harden tickets (big_map, map, token validation layer etc)
* changes to voting procedure (rolls are no more)

### Kathmandu 11th upgrade
* SCORUs
* Event logging
* Verifiable Delay Functions