Skip to content

Instantly share code, notes, and snippets.

@smondet

smondet/dev-team-edo-changes.md Secret

Last active November 19, 2020 15:00
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save smondet/ddfe73d0c0d13129174c3b71879ec41d to your computer and use it in GitHub Desktop.
Save smondet/ddfe73d0c0d13129174c3b71879ec41d to your computer and use it in GitHub Desktop.
Download ZIP
Raw
dev-team-edo-changes.md

Changes in Edo

It is (Supposed To Be) Whatever Is Ready “Now” ✉

Agora-post: Regular Scheduling For Our Tezos Proposals

Meta 🔎

This will very likely change for 009 (protocol development will be in tezos/tezos on the master branch like everything else).

How to find this all out:

  • Go to branch metastatedev/tezos:proto-proposal
  • find the common ancestor with master
  • this time, like often, looks like it is around
    • Revert "Protocol: add vanity nonce" (this time by Tomáš Zemanovič from Metastate who is often the one rebasing everything apparently …).

There is a lot more information in the issues and merge-requests but since git-rebase has rewritten the commits (many times) that link is severed hence very hard to trace back.

The 🔒proto-proposal tezos-dev channel and its many HackMD files is also very useful.

Environment V1 ♲

Up to now all protocols use V0.

Environment:

  • = assumptions about the world that the protocol makes
  • = “standard” library
  • = API it is programmed against (gigantic multi-type type-class?)

Nodes will need to have V1 available to run Edo ⇒ so required update (or reimplementation ☺).

Kinda looks like a hard fork from afar, we don't want to do those too often.

  • Various “software updates” and clean-ups (no more Lwt*_p functions, remove mBytes)
  • Hex library from Mirage (why?)
  • Expose much more of ZArith
  • Hashes keccak256, sha3_256, sha3_512
  • Library BLS12_381 with FIELD, CURVE, and PAIRING
  • Expose lib_sapling
  • Expose PVSS (“public-verifiable secret sharing” — not used for far, it's for the baking accounts, maybe in 009)

Minor Changes 🔬

  • Coq-of-OCaml → Some of the diff is fitting the protocol into a subset of OCaml.
  • Big-maps → Lazy-storage → Abstraction of the concept, I don't know if there is any user visible consequence this time.
  • Contract_services: big_map_get now returns None if there are 2+ big maps → That's the legacy “1 big-map” pre-Babylon thing → it becomes more strict.
  • Protocol/Michelson: do not use comparable_ty_of_ty for set update → simplification of the VM.

Michelson Combs 💇

  • Comparable types: allow non-comb pairs
  • Proto/Michelson: optimized notation for right comb data
  • Proto/Michelson: add a sequence notation for right combs
  • Proto/Michelson: optimized notation for right comb types

To build tuples of length greater than 2, right combs have specific optimized operations. The compact notation Pair x{0} x{1} ... x{n-2} x{n-1} is provided for the right-comb value Pair x{0} (Pair x{1} ... (Pair x{n-2} x{n-1}) ...).

Right-comb values can also be written using sequences; Pair x{0} x{1} ... x{n-2} x{n-1} can be written {x{0}; x{1}; ...; x{n-2}; x{n-1}}.

pair (t{1}) ... (t{n}) with n > 2: A shorthand for pair (t{1}) (pair (t{2}) ... (pair (t{n-1}) (t{n})) ...).

-   (Pair (Pair 1 (Pair 2 (Pair (Pair (Pair 3 0) 4) 5))) 6)
+   (Pair (Pair 1 2 (Pair (Pair 3 0) 4) 5) 6)

Protocol/Michelson: add instructions for manipulating right combs

  • PAIR n: Fold n values on the top of the stack in a right comb. PAIR 0 and PAIR 1 are rejected. PAIR 2 is equivalent to PAIR.
  • UNPAIR n: Unfold n values from a right comb on the top of the stack. UNPAIR 0 and UNPAIR 1 are rejected. UNPAIR 2 is equivalent to UNPAIR.
  • GET k: Access an element or a sub comb in a right comb.
  • UPDATE k: Update an element or a sub comb in a right comb.
  • CAR k: Access the k -th part of a right comb of size n > k + 1.
  • CDR k: Access the rightmost element of a right comb of size k.

Michelson Misc 🛍

  • Instruction LEVEL → Put the level (nat) of the current block on the top of the stack
  • Comparable types
    • Add Unit, Union, and Option as comparable types
    • Make key, chain_id and signature comparable
  • SELF_ADDRESS is equivalent to SELF; ADDRESS but it is also allowed in lambdas.
  • Empty type named never + NEVER instruction
    • it is impossible to construct a value of type never.
    • NEVER: Closes an absurd branch.
  • UNPAIR instruction that behaves as the current UNPAIR macro.
  • VOTING_POWER: Return the voting power of a given contract. This voting power coincides with the weight of the contract in the voting listings (i.e., the rolls count) which is calculated at the beginning of every voting period.
  • TOTAL_VOTING_POWER: Return the total voting power of all contracts. The total voting power coincides with the sum of the rolls count of every contract in the voting listings. The voting listings is calculated at the beginning of every voting period.
  • KECCAK: Compute a cryptographic hash of the value contents using the Keccak-256 cryptographic hash function.
  • SHA3: Compute a cryptographic hash of the value contents using the SHA3-256 cryptographic hash function.
  • DUP n: Duplicate the N-th element of the stack. DUP 1 is equivalent to DUP. DUP 0 is rejected. (used to be a macro)
  • restrict FAILWITH to packable types
  • Big-map literals → now three possible representations.
    • A map literal is always a valid representation for a big map.
    • Big maps can also be represented by integers called big-map identifiers.
    • Finally, big maps can be represented as pairs of a big-map identifier (an integer) and a big-map diff (written in the same syntax as a map whose values are options).
    • ⇒ Example: { Elt "bar" True ; Elt "foo" False }, 42, and Pair 42 { Elt "foo" (Some False) } are all valid representations of type big_map string bool.

Not yet merged as of Wed, 18 Nov 2020 18:29:47 -0500:

MR metastatedev/tezos!303: Linear operators on maps and big map

  • GET_AND_UPDATE: A combination of the GET and UPDATE instructions.

This instruction is similar to UPDATE but it also returns the value that was previously stored in the map at the same key as GET would.

Michelson Bye 👋

The deprecated instructions STEPS_TO_QUOTA, CREATE_ACCOUNT, and the deprecated variant of CREATE_CONTRACT have not been used before their deprecation so it is now safe to remove them.

RPC run_code 🏃

Proto/RPC: add a mandatory balance field to the run_code RPC

This new field allows to control the result of the BALANCE instruction when simulating a contract.

  • useful for off-chain-views
  • right now TZComet/tezos-client have to modify the view: PUSH mutez <actual-balance>

Propagate blocks before fully validated / pipelining 🤷

Shell/RPC: add endpoints for operations metadata hashes of a block

The context commits to the root hash of predecessor's operation metadata to prepare to change blocks committing to the context as of the end of previous block, which will allow to bake blocks without having to execute transactions.

MR metastatedev/tezos!225 depends on environment V1 but does not change the protocol!

Tomáš:

because it ensures that the previous protocols (in V0) wouldn't be affected by this change. Bakers need to commit context to a predecessor block's metadata hash and operation metadata hash, otherwise they would end-up with a inconsistent context hash.

Initially in the protocol but, Benjamin said:

Since this is something that the shell should be aware of, I'd prefer a solution that implements this in the shell.

Governance Changes ☑

Issue metastatedev/tezos#26, from July 2019:

screenshot-20201118-184230

Cf. also @metastatedev's tweet → Article & Agora-Topic. Governance Improvements

type kind = Proposal | Testing_vote | Testing | Promotion_vote | Adoption

The procedure consists of five periods, each of 20480 blocks (or ~two weeks), for a total of approximately 2 months and a half.

  • Proto/RPC: Add endpoint for the current voting period → (index, kind, starting position)
  • Proto: Add RPC endpoint for the voting period of the next block → /.../successor_period

Sapling 🕵

Whole lib_client_sapling in there.

Types:

  • sapling_transaction ms: A :ref:Sapling<sapling_dev> transaction
  • sapling_state ms: A :ref:Sapling<sapling_dev> state

Instructions:

  • SAPLING_VERIFY_UPDATE: verify and apply a transaction on a Sapling state.
  • SAPLING_EMPTY_STATE ms: Pushes an empty state on the stack.

See docs: sapling.rst

(Linear) Tickets 👮

Not yet merged as of Wed, 18 Nov 2020 17:02:11 -0500:

screenshot-20201118-185113

MR metastatedev/tezos!328:

The following operations deal with tickets. Tickets are a way for smart-contracts to authenticate data with respect to a Tezos address. This authentication can then be used to build composable permission systems.

A contract can create a ticket from a value and an amount. The ticket, when inspected reveals the value, the amount, and the address of the ticketer (the contract that created the ticket). It is impossible for a contract to “forge” a ticket that appears to have been created by another ticketer.

The amount is a meta-data that can be used to implement UTXOs.

Tickets cannot be duplicated using the DUP instruction.

For example, a ticket could represent a Non Fungible Token (NFT) or a Unspent Transaction Output (UTXO) which can then be passed around and behave like a value. This process can happen without the need to interact with a centralized NFT contract, simplifying the code.

  • ticket (t): A ticket used to authenticate information of type (t) on-chain.
  • TICKET: Create a ticket with the given content and amount. The ticketer is the address of SELF.
  • READ_TICKET: Retrieve the information stored in a ticket. Also return the ticket.
  • SPLIT_TICKET: Delete the given ticket and create two tickets with the same content and ticketer as the original, but with the new provided amounts. (This can be used to easily implement UTXOs.) Return None iff the ticket's original amount is not equal to the sum of the provided amounts.
  • JOIN_TICKETS: The inverse of SPLIT_TICKET. Delete the given tickets and create a ticket with an amount equal to the sum of the amounts of the input tickets. (This can be used to consolidate UTXOs.) Return None iff the input tickets have a different ticketer or content.

BLS Instructions 📈

BLS12-381

  • bls12_381_g1, bls12_381_g2 : Points on the BLS12-381 curves G₁ and G₂ , respectively.
  • bls12_381_fr : An element of the scalar field F_r, used for scalar multiplication on the BLS12-381 curves G₁ and G₂.
  • NEG: Negate a curve point or field element.
  • ADD: Add two curve points or field elements.
  • MUL: Multiply a curve point or field element by a scalar field element.
  • PAIRING_CHECK:
    • Verify that the product of pairings of the given list of points is equal to 1 in Fq12. Returns true if the list is empty.
    • Can be used to verify if two pairings P1 and P2 are equal by verifying P1 * P2^(-1) = 1.
  • bls12_381_g1 and bls12_381_g2 [literals] are written as their raw bytes, using a big-endian point encoding, as specified here
  • bls12_381_fr are written as their raw bytes, using a little-endian encoding.

Also,

Unmerged as of Wed, 18 Nov 2020 17:04:50 -0500:

MR metastatedev/tezos!367: Add typing rule for MUL to allow building Fr elements from naturals

@smondet
Copy link
Author

smondet commented Nov 18, 2020

screenshot-20201118-184230
screenshot-20201118-185113

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment