1 Florence

This time there is proper change-log written on-time: tezos.gitlab.io/protocols/009_florence.html

• PsFLorenaUUuikDWvMDr6fGBRG8kt3e3D3fHoXK1j1BFRxeSH4i
• https://florencenobanet.smartpy.io/chains/main/blocks/head/metadata

1.1 Double Operation Length Maximum

Tiny change 3ff6bc8da9f8941b65fb9be4e51d3de1e93bfaed with nice TZIP draft-increase_operation_size_limit.md By Keefer.

• Bigger smart-contracts at origination.
• More items in FA2-style batch contract calls.
• More items in generic operation batches (baking rewards redistribution).
• Total size of all operations in a block does not change.
• Keefer is not paid by TF for protocol development so he gets the (only) invoice of 100 ꜩ.

1.2 PtEdo2Zk

The PtEdoTez → PtEdo2Zk fix (e879b1a7) is in the Florence changelog (by mistake):

Fixed a discrepancy between CONTRACT and PACK in addresses without entrypoints

(cf. tezos/tezos#643).

1.3 BFS → DFS

A.k.a. Depth-First Execution Order

• TZIP: tzip/tzip!111
• Code: tezos/tezos!2420

Many discussions + competing designs ⇒ ended up with Simple/YOLO change.

• https://forum.tezosagora.org/t/concurrency-bfs-vs-dfs-and-a-proposal/1994
• forum.tezosagora.org/t/florence-our-next-protocol-upgrade-proposal/2816/9
• forum.tezosagora.org/t/tezos-calling-convention-migrating-from-breadth-first-to-depth-first-order-bfs-to-dfs/2846

Cf. @Rafoo’s answer and,

Note that, unless you explicitly built a contract to depend on the BFS calling convention, it probably doesn’t.

1.4 Normalization RPCs

Two new normalization RPCs, normalize_data and normalize_script […] can be used to convert Michelson comb pairs into the format they had before the introduction of the compact notations in Edo.

MR tezos/tezos!2354: Proto/Michelson: Add a normalize RPC and client command

comes after the one that adds the same functionality to Edo through plugins:

tezos/tezos!2446: Introduce RPC protocol plugins

• Harmonization: the plugin-version has some “double” RPCs, the one from the protocol and the one <path>/normalized.
• In the future: all the …/helpers/… RPCs may be moved outside the protocol using plugins (effectively kinda undoing this MR, but all together with the rest, and it has not been decided yet).

1.5 New failing_noop Operation

new operation has been added to the protocol that is guaranteed to fail

For signing arbitrary messages, long awaited feature (I even took a stab at it with a different approach ca. Aug 2019).

→ tezos/tezos!2361 with client commands:

tezos-client sign message "hello world" for <account>
tezos-client check that message "hello world" \
              was signed by <account> to produce <signature>

One can also play with the binary format tezos-codec describe 009-PsFLorBA.operation.unsigned binary schema (don’t forget the the 0x03 signing-watermark for operations). It uses “genesis” as the branch by default (not obvious …).

I submitted: tezos/tezos#1166.

1.6 Endorsements Now Checked in Linear Time

Pure performance improvement → tezos/tezos!2471.

• Idea: pack the “endorsement slot” with the signed endorsement.
• Will become even more relevant with future versions of the consensus: Emmy* and Tenderbake ⇒ be able to increase the number of endorsements.

1.7 Staking balance RPC Performance Improvements

→ the /chains/[...]/blocks/[...]/context/delegates/[...] RPC endpoint.

tezos/tezos!2547: retrieves less useless data from the context.

1.8 Gas (Accounting) Optimizations

All by Yann Regis-Gianas:

• tezos/tezos!2328
• tezos/tezos!2327
• tezos/tezos!2329

Cf. concept of Saturation arithmetic (wikipedia).

1.9 Deactivation of the Test Chain in the Economic Protocol

Nobody was using it.

1. Proposal → Proposal
2. Testing_vote → Exploration
3. Testing → Cooldown
4. Promotion_vote → Promotion
5. Adoption → Adoption

TZIP, MR.

1.10 Migrations may now Produce Balance Receipts

tezos/tezos!2437:

• Also a long awaited feature request from indexers.
• A fix was for this was also in the “Brest A” proposal by OCamlPro ca. June 2019 ☺ (cf. Jun’s commentary blog-post).

1.11 Clean-Up Protocol API

Abstract protocol types can now be used consistently outside the protocol.

tezos/tezos!2497: hides “internal types” that were mixed-up with already abstracted/high-level ones.

2 Baking Accounts

A.k.a. PsFLorBArSaXjuy9oP76Qv1v2FRYnUs7TFtteK5GkRBC24JvbdE → the official changelog:

⚠️ Note this feature includes several breaking changes. Please

⁂

Cf. Nicolas’ blog post: midl-dev.medium.com: Tezos: in favor of Baking Accounts

UPDATE: based on further analysis by Nomadic Labs, it is no longer recommended to vote for Baking Accounts as proposed during phase 42. See below.
We still believe Baking Accounts is a needed Tezos feature for the reasons explained below. We hope that Nomadic Labs will propose a newer version at a later date that addresses the issues they found.

2.1 This Version

The TZIP is still in an MR tzip/tzip!133.

⁂

• Work in progress for more than a year (Metastate).
• Initial drafts raised a lot of concerns:
  • Non-spendable baking key.
  • Too complex smart-contracts.
• Proposal was already “dumbed down”:
  • Only a predefined generic multi-sig.

⁂

Baking account: SG1fpFaowYY8G7PfkYdKkGmsMziHKUfrHRHW

• First-class multisig contract.
• State:
  • Consensus key: one PK + potentially one “pending” PK.
    • Needs to be empty/non-allocated.
    • One can still delegate to the consensus key.
  • How to vote, transfer, etc.
• Special contract:
  • Mostly the generic-multisig + baker-operations.
  • (lambda %operation unit pair (list operation) (list baker_operation)))
  • New Michelson instructions (just for bakers):
    • Usual baking stuff (vote, activate)
    • Manage consensus key.
    • Stop accepting delegations.
    • Set PVSS key (not in use in that protocol).

2.2 The Problems

forum.tezosagora.org: Baking Accounts proposal contains unexpected breaking changes

We believe Baking Accounts should be postponed until a thorough audit of functionality is complete, or an alternative implementation produced.

• Bakers’ FA1.2/FA2 Tokens + manager.tz accounts → potentially locked.
• Other SOURCE Vs SENDER assumptions broken.

2.3 For Granada or Haarlem

Arthur’s alternate TZIP → HackMD draft:

• Keep using a tz1 address for the baker.
• Break the link: address = hash(public-key).