Nomadic Labs
Nomadic Labs
Florence: Our Next Protocol Upgrade Proposal

Announcing Florence Proposal

This is a joint announcement from Nomadic Labs, Marigold, DaiLambda, and Tarides.

As we described in this post, several development organizations in the Tezos ecosystem are now collaborating to submit protocol upgrade proposals every few months, which is the interval permitted by the Tezos on-chain governance process. When the Edo upgrade went live on February 13, we mentioned that a new protocol proposal, codenamed “Florence”, would soon be ready. We are pleased to announce that, as expected, “Florence” is now complete.

We are offering the community two versions of the Florence proposal to choose between, one with Baking Accounts (as described below) and one without; we’ll explain the rationale for this decision later in this blog post.

  • The hash of the proposal with baking accounts is: PsFLorBArSaXjuy9oP76Qv1v2FRYnUs7TFtteK5GkRBC24JvbdE
  • The hash of the proposal without baking accounts is: PsFLorenaUUuikDWvMDr6fGBRG8kt3e3D3fHoXK1j1BFRxeSH4i

Florence has a number of bug fixes and small improvements; we encourage you to look at the change log. Below we will discuss some of the more interesting and important changes:

Increased Maximum Operation Size: Previously, the maximum size of an operation was 16kB. In Florence, we propose to increase it to 32kB. Among other things, this has the effect of slightly more than doubling the maximum size of a smart contract, which should be of interest to some developers with particularly complicated applications.

Gas Optimizations: We have again reduced gas consumption in smart contract execution by increasing the efficiency of gas computation inside the Michelson interpreter. This allows for smart contracts with more complicated functionality to operate economically on the chain. We will continue to work on further efficiency improvements in coming versions of the protocol.

Baking Accounts: Previously, token holders delegated to a baker by specifying that baker’s public key hash. This meant that bakers could never change their public keys, which was exceptionally inconvenient. The new “Baking Accounts” feature alleviates this issue. In Florence, a new account type has been added to represent accounts managed by bakers. These accounts are Michelson smart contracts running a fixed multisig script. This feature lets bakers renew and split their consensus keys without moving to a new address and asking their delegators to follow. In addition to the usual internal operations, baking accounts can also emit baking operations such as proposing and voting for protocol amendments.

(The rights granted to the baking key (baking, endorsing, voting, and spending the funds) remain unchanged. However, the system also allows a baker to vote and access their funds using multisig authentication. Not using the baking key for such tasks reduces the risk of it being exposed, and the baking key can also be rotated in a worst case scenario.)

Although we strongly believe that Baking Accounts are an important new addition to the Tezos protocol, and although we have made considerable effort to make them backwards compatible with existing code, we recognize that client libraries, wallets, indexers, and other software will require some work to fully support Baking Accounts. We are thus providing the community with the opportunity to decide for itself during the Proposal Period whether or not to include this feature in the Florence update.

Depth First Execution Order: Previously, intercontract calls were executed in a so-called “breadth first” ordering. This was believed to be the correct choice when the Tezos protocol was initially designed, but it has turned out to significantly complicate the lives of smart contract developers. If Florence is adopted, the calling convention will change to a “depth first” execution order. This will make it far easier to reason about intercontract calls.

No More Test Chain: Previously, during the voting process, a test chain would be spun up during the “testing period” which took place between the exploration and promotion voting periods. The intent was that this test chain be used to assure that the new proposal worked correctly, but in practice, the test chain has never been used in this manner, and has caused significant operational problems to node operators. The new proposal eliminates the test chain activation; the testing period has been retained but is now named the “cooldown period”. Instead, we will continue to test the protocol using test chains that operate outside of the mainnet voting process.

This protocol amendment and the related updates to the Tezos shell were developed by programmers from Nomadic Labs, Metastate, DaiLambda, Marigold, Tarides, and an external contributor, Keefer Taylor, to whom the proposals grant an invoice of ꜩ100 to thank him for his merge request that increased the maximum operation size.

Now that Florence is code complete, we encourage you to test your own Tezos related applications to check for compatibility problems. Docker images with both proposals are now available and two testnets, one with and one without Baking Accounts, will soon be available as well.

Supplementary Information:

Gitlab Repository with Baking Accounts

Gitlab Repository without Baking Accounts

A docker image containing both proposals and the necessary code to run them may be obtained by running:

docker pull tezos/tezos:master
  • The test network for Florence will be called Florencenet. This will running the proposal with new baking accounts feature, whose protocol hash is: PsFLorBArSaXjuy9oP76Qv1v2FRYnUs7TFtteK5GkRBC24JvbdE

  • The test network for Florence without baking accounts will be called FlorenceNoBAnet. The hash of that protocol proposal is: PsFLorenaUUuikDWvMDr6fGBRG8kt3e3D3fHoXK1j1BFRxeSH4i


A technical description of the Dexter flaw

In this technical blog post, we detail the flaw found in the Dexter contract and the exploit used to “white-knight” the funds in those contracts. Background The Dexter contract contains several entrypoints allowing users to perform various operations, such as adding and removing liquidity, or converting tokens to tez back and forth. The exact interface is given by the type of the contract’s parameter: parameter (or...

Read More
Dexter Flaw Discovered; Funds are Safe

TL;DR: A flaw was found in the camlCase’s Dexter contract. The funds have been removed from the contract and returned to their original holders. A high level explanation follows; technical details of the Dexter flaw will be described in a separate post to come. As many of you know, we have been working on a new Tezos upgrade proposal. This proposal, if accepted, will change the calling convention from breadth first ordering to depth first ordering. In...

Read More
Edo, the latest Tezos upgrade, is LIVE

This is a joint announcement from Nomadic Labs, Marigold, and DaiLambda. On 13 February 2021, the Tezos blockchain successfully upgraded by adopting Edo at block 1,343,489. Jointly developed by Nomadic Labs, Marigold, DaiLambda, and Metastate, Edo is the fifth Tezos upgrade in the span of two years, and follows the Delphi upgrade of three months ago. The Tezos blockchain currently allows protocol upgrades every several months, and we intend for the foreseeable future to take advantage of...

Read More
IMPORTANT: Critical Patch to Tickets in Edo

We have discovered a critical bug within the new Tickets functionality in Edo. Several mechanisms were considered to mitigate this problem; none were ultimately found to be satisfactory. We have therefore taken the step of producing and releasing version 8.2 of the Tezos node that includes a patched version of the Edo protocol that differs by only a few lines of code. Nodes running 8.2 will automatically adopt the patched version rather than the original version of Edo when it activates on February 13th, 2021, around...

Read More
A look ahead to Tenderbake

We’re working on changing the Tezos consensus algorithm from the current Emmy+ algorithm, to a new algorithm called Tenderbake. We’d like to discuss this development, and explain why we’re considering it, and what advantages it will bring. Tenderbake and Emmy+ belong to different algorithm families: Emmy+ is a Nakamoto style algorithm, whereas Tenderbake is a BFT-style algorithm. So moving to Tenderbake would be a significant development on the Tezos network. We made every effort to keep this blog post self-contained, but just in...

Read More
POPL 2021 retrospective

A short summary of our experience at POPL, CPP and CoqPL this year.

About POPL (Symposium on Principles of Programming Languages) POPL 2021 — the 48th ACM SIGPLAN Symposium on Principles of Programming Languages — is a premier annual conference event of the Programming Languages research community. POPL consists of a main conference, and many colocated events, which together present the latest and greatest research in (amongst other topics): programming languages theory, formal verification, type systems, and functional programming — all subjects which are dear to...

Read More
A review of Nomadic Labs in 2020

Nomadic Labs’ activities in 2020

2020 is over and in spite of the difficulties which the year presented, we at Nomadic Labs got a lot done. So here’s who we are, and what we accomplished in 2020: Nomadic Labs in a nutshell Nomadic Labs is an international technical company dedicated to evolving the Tezos ecosystem. Tezos is a community-driven proof-of-stake self-evolving blockchain platform that adapts and adopts new features and enables borderless global cooperation. Let’s unpack that: Community-driven: The Tezos community is a...

Read More
Introducing mockup mode for tezos-client

Presenting tezos-client’s new mockup mode feature

We are pleased to announce that the tezos-client binary has a new feature aimed at contract and tool developers alike: the mockup mode. Mockup mode allows easy prototyping of Tezos applications and smart contracts locally. By local we mean: The relevant data files sit in a directory on your computer’s local filesystem. These files are a lightweight emulation of the internal state of a Tezos single-node network. Thus, networking communications infrastructure that a node would be wrapped...

Read More
Announcing the Edo Release!

This is a joint announcement from Nomadic Labs, Marigold, and Metastate. A couple of weeks ago, we were proud to see the “Delphi” upgrade to the Tezos protocol go live. This week, we are proud to announce our latest protocol upgrade proposal, “Edo”. As usual, Edo’s true name is its hash, which is PtEdoTezd3RHSC31mpxxo1npxFjoWWcFgQtxapi51Z8TLu6v6Uq. Why is Edo being proposed when Delphi has only been in place for a short while? Although Delphi went live on November 12th,...

Read More
  • 1
  • 2