Florence: Our Next Protocol Upgrade Proposal

UPDATE: We believe that the baking accounts implementation is significantly flawed. See: Baking Accounts proposal contains unexpected breaking changes

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


Great work & thanks for making it simple for independent devs like Keefer Taylor to get involved and execute some enhancements! We need to keep this going and make sure core dev never becomes an island.


Where can we find more technical details about the Baking Accounts in Florencenet?


Some insights: Tezos: in favor of Baking Accounts | by MIDL.dev | Mar, 2021 | Medium


@fredcy, you can find relevant links for all changes in the changelog: Protocol 009_PsFLorBA Florence — Tezos (master branch, 2021/03/04 17:28) documentation. In this case there’s the TZIP, as well as the MR and another MR for the docs.


Does everyone realize that changing the execution order of internal operations may break existing smart contracts? Or, even worse, make them vulnerable.


That is why we need developers of current smart contracts to participate in the discussion.


Isn’t the depth-first execution order a breaking change to many smart contracts? Seems like it’ll introduce a bunch of reentrancy vulnerabilities, as currently deployed contracts have (hopefully) already been written with breadth-first type reentrancy in mind.

This has been discussed in the DFS TZIP where some attempts at keeping backward compatibility have been proposed. Unfortunately they lead to complex hybrid models that are very hard to reason about. There are two distinctions to make regarding this question. The first distinction is between contracts already on the chain versus the contracts that are not yet originated but will be if and when Florence activates. The second distinction is the one you make between “break” and “make vulnerable”.

  • Breaking existing contracts: to detect possible contract breakage, we have compared for all the Delphi blocks the context hash when the block is applied using BFS and DFS. For all but one (BLHP5v9BVscaM4mocunVN6C3jALi56JiWXHpZhBQKPmKnxZctk7) block, the hash was the same. The problematic operation is at the very end of the block; it is a call to Dexter where wXTZ tokens are sold and the tez received in exchange for them are immediately locked in a wXTZ oven. So moving from BFS to DFS seems to break Dexter but no other existing contract. During the recent reboot of Dexter, the script was changed to make it more independent of the execution order (by forbidding complex interaction patterns like this one).
  • Making existing contracts vulnerable: BFS and DFS offer different atomicity guarentees so in theory it is possible that some smart contracts rely on the BFS order of execution for their security. This seems rather unlikely in practice because reasoning in the BFS model is not very intuitive (see this thread in particular). Unfortunately, this is also very hard to test. If you have examples of applications that may depend on the BFS order for their security please share!
  • Breaking or making new contracts vulnerable. We have no cristal ball so even if we assume that Florence is accepted by the community we cannot tell what contracts will be on chain in two months when it activates. The best we can do regarding the contracts of the near future is to warn the community of smart contract developers that a change in the order of application of internal operations has been proposed so we strongly recommend to either originate contracts that work and are safe in both DFS and BFS contexts or to wait for the decision of the community regarding this point. So thank you very much for having started this discussion!

@NomadicLabs please update this post to reflect people should NOT vote for the BA proposal but instead for the other one.


This blog post states that already existing contracts have been checked and patched so they are florence-compliant


I will start my opinion by saying that since bakers are risking everything, so is in our best interest to make rational decisions (delegators can always sell but our XTZ is locked in bonds).

Please let ask ourselves what would happen when a proposal is introducing features that will benefit bakers, giving us more control over the network, but it might break smart contracts? This has to objectively put in balance. We as bakers have to take care of smart contracts even if this means renouncing to more control or benefits, we need some sort of stability assurance to smart contract developers. It is imperative that these chain SC analysis are made extensively, If there is only 1 SC breaking (specially if this smart contract is being actively used) the developer could be easily contacted to perform the respective patch to their SC to be compliant with the new update, then it would be objective to go ahead with the proposal and vote yay, but when a proposal in breaking multiple SC and is impossible to coordinate with all the SC devs, then we should leave aside baker benefits even if they sound awesome and favor SC stability.

Now for the “SC in the limbo” which are the smart contracts that are not yet deployed and can’t be analyzed during the transition. This is the REAL issue. I’m still deciding what to think here. Breaking their non yet deployed SC could mean for them starting over and that is hours of developing time lost for them. I’m not an SC coder, but I assume this could be fatal for them. Now I don’t want to be conservative, I’m always open to change (otherwise it would be dogmatic), but we should consider relative stable chain conditions for them, specially in the future that the network will be heavily used.


See also Tezos calling convention migrating from Breadth-First to Depth-First Order (BFS to DFS).

1 Like

Sounds like maybe we need a smart contract address type that can redirect to other smart contracts that way contracts can go through seemless upgrades in these kind of breaking situations. Kind of like what was being done for Baking Accounts but instead Smart Contract Accounts that redirect. That new address type (FA3) could have governance standards for token holders to vote to allow upgrades (redirects) to specific other contacts or not… Similar to current on chain governance voting model but instead for smart contracts as an FA standard for redirection/upgrades.