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