Florence, BA (PsFLorBAr)

Improvements to contract operation size, gas optimizations, Baking Accounts, execution order for inter-contract calls, and the elimination of the test chain activation. Full changelog here.

Features

The Florence proposal, a joint effort from Nomadic Labs, Marigold, DaiLambda, and Tarides is a protocol upgrade proposal focused on implementing new bug fixes and small improvements such as increasing maximum operation size, gas optimizations, baking accounts, depth first execution order, and the elimination of the test chain activation.

With regards to operation size, the previous maximum size 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.

In addition, we have again reduced gas consumption in smart contract execution by increasing the efficiency of gas computation inside the Michelson interpreter, allowing for smart contracts with more complicated functionality to operate economically.

Florence also changes intercontract calls to a depth first ordering, as opposed to breadth first.

Finally, the Florence proposal offers two versions, one including Baking Accounts, and one without it.

Previously, token holders would delegate to a baker by specifying that baker’s public key hash, which meant that bakers could never change their public keys. The new Baking Accounts feature alleviates this issue by adding a new account type to represent accounts managed by bakers.

However, ongoing testing and review of Baking Accounts has uncovered some important and previously undocumented breaking changes in the Baking Account proposal. We believe Baking Accounts should be postponed until a thorough audit of functionality is complete, or an alternative implementation produced. The version of Florence without baking accounts is a safer choice.

Amendment Process Updates

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.

This 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.

Explanation Posts

Source Code

Invoice

This proposal doesn’t contain an invoice.

2 Likes