This is my quick look of recent “Brest” amendment proposal to Tezos blockchain, which was injected and proposed by OCamlPro.

Data

Proposer
“TzScan Baker” tz1LWub69XbTxdatJnBkm7caDQoybSgW4T3s ran by OCamlPro
The social announcement
https://www.reddit.com/r/tezos/comments/by5xy8/proposal_for_amendment_brest_a/ It calls the proposal “Brest A”.
The code with the same announcement
https://gitlab.com/tzscan/brest-amendment

As of 2019-06-17T04:35:34Z, this is the only one proposed in this Tezos voting period.

At a glance

As stated by the above announcements, I see 3 modifications between 004_Athens (or just Athens) and 005_Brest (or just Brest):

• A security fix to make some DoS attack to the storage layer of Tezos nodes more difficult.
• A fix of the proposal rewards trackability issue.
• The reward is ꜩ8000 to TzScan Baker, which is equivalent to 1 roll (i.e. 1 voting power) in Athens.

I did not find any other undocumented changes. Let’s see their details.

Security fix

Contract index database

Blockchain implementations often have Git style ledger databases. In Tezos it is called “context”. Tezos’ context is a huge file, where its storage subsystem builds its own directory structure using Irmin and LMDB.

The context carries account and contract related data stored in key-value mappings where keys are accounts and contracts. This KVS is encoded using the storage subsystem’s internal file-directory structure.

There is a vulnerability around this KVS in the storage subsystem, and up to 003_PsddFKi3 (the previous protocol of Athens) it was possible to perform DoS attacks to the Tezos nodes. It can slow down the network, but attackers cannot steal tokens just with this vulnerability as far as I understand.

I am not going to disclose the full details for now. The full detailed report is unlocked when the issue will be really fixed. Meantime, you can see the BLAKE2 hash of my draft:

$b2sum draft.md 245c031ebf72745c1d6550aa15623d29565f6ec7cece5221162bcca607e485c238bd834782f3ed8a25dc1180dca1c31927064e039618ebdd0b1e651aefd4cecd draft.md  Contract reindexing of Athens A mitigation for this DoS vulnerability was introduced by Athens, but quietly. Let’s see the explanation of “Context reindexation” in Nomadic Lab’s announcement of Athens: It is a preliminary to future improvements of the account system, such as making key handling more flexible for bakers. The announcement never mentioned it as a security mitigation because Tezos’ protocol amendment is a slow process takes 3 months. Nomadic labs carefully chose words not to send a signal to hackers who otherwise would have attacked the previous protocol running with the issue at that time. I guess it also aimed to prepare the possible emergency situation: if someone would have found the vulnerability and attacked the network, Tezos could have asked its community an emergency security hard fork, by showing the fix available in the Athens’ proposal. Luckily such events did not happen. This mitigation did not solve the vulnerability entirely but just made the attack very difficult adding more calculation for it. The real definitive solution is to fix the storage subsystem itself. Then, why Athens did not fix the storage subsystem once and for all? Since storage is not in the protocol, but in the shell, and shell fix and upgrade are not targets of protocol amendment. Famous "el Pulpo" of Tezos. The green brain of the octopus is the protocol, which requires amendment voting to upgrade (except emergency security hard forks). The rest of the octopus is called shell, where the storage subsystem lies. The purpose of this reindexation in Athens was to protect Tezos until the storage subsystem is properly fixed. I believe now people are working hard on the fix of the storage. What Brest is going to do, and what it has done already Now let’s see the explanation of the security fix of Brest: A security issue. The rehashing performed during Athens protocol change was not enough to prevent some kinds of attacks. This amendment performs a new rehashing that makes these attacks ineffective. The path length of addresses is increased from 7 to 9, making the attack 65536 times more difficult. The modification is trivial: it changes a parameter Athens has introduced from 7 to 9, to make the attack 65536 times more difficult. Questions remain to me. As of today (2019-06-17), we have not observed any attack attempt using this vulnerability. The problem itself remains in the storage subsystem even after Brest. Nothing is explained why 7 are not enough but 9 are. (Since this is a security issue, the reason might be explained privately to Tezos Foundation.) Unfortunately Brest has announced the existence of the vulnerability to public. It could have been done in a more silent manner as Athens did; the proposer should have known what they are doing because they have the perfect understanding of the vulnerability and how Athens has introduced the mitigation with careful wording. Protocol upgrade reward in a block What happened between 003_PsddFKi3 and Athens Athens has charged ꜩ100 to the proposer’s account tz1iSQEcaGpUn6EW5uAy3XhPiNg7BHMnRSXi for the upgrade reward. As you can see in block explorers, this reward was minted from nothing. There is no transaction or anything about it: neither the last block of 003_PsddFKi3 nor the first block of Athens tells you about the reward. But you can check the reward is indeed added to the account after the last block of protocol 003_PsddFKi3: At block level 458751, just before the last block by 003_PsddFKi3: $ ./tezos-client -b BMXd3qGXLKjJjdUjqCFG4HA78od8dL7JvC284gunZ55An6eWR1N-1 get balance for tz1iSQEcaGpUn6EW5uAy3XhPiNg7BHMnRSXi
0 ꜩ


After the next block at level 458752, when Athens starts working:

\$ ./tezos-client -b BMXd3qGXLKjJjdUjqCFG4HA78od8dL7JvC284gunZ55An6eWR1N get balance for tz1iSQEcaGpUn6EW5uAy3XhPiNg7BHMnRSXi
100 ꜩ


Brest claims this current behaviour makes block explorers difficult to track the protocol update rewards and they need ad-hoc fixes for each protocol update. It is true, but it only happens once three months at most, and the explorers themselves often have to be upgraded at protocol changes in any way.

Brest’s approach

Brest makes this reward payment recorded in a block explicitly.

For this, it cannot invoice the reward to its proposer just after the last block of the previous protocol, as Athens did. This is since the new protocol cannot write the balance update to the last block of the previous protocol.

Therefore, the balance update of the reward must be recorded in the first block of the new protocol. For this purpose, Brest introduces an integer state Storage.Pending_protocol_init and set it to 1 (or true) at the end of Athens. This integer is used as a flag to trigger the reward payment and its balance update injection to the first block of Brest. The flag is reset to 0 (or false) after the reward payment of course.

I am not sure whether this implementation with a new flag state is the best here. Is it hard to give the reward simply when the new protocol handles its first block?