This is my quick look of recent “Brest” amendment proposal to Tezos blockchain, which was injected and proposed by OCamlPro.
- “TzScan Baker”
tz1LWub69XbTxdatJnBkm7caDQoybSgW4T3sran 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
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.
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.
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
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
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
At block level 458751, just before the last block by
$ ./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 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
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?
Protocol upgrade reward ꜩ8000
Brest claims ꜩ8000 for the reward, which is about USD 10000 in the price of 2019-06-17.