TL;DR We recently discovered three potentially critical issues in the ParisB protocol upgrade proposal. These issues have been fixed in ParisB 2, a patched protocol upgrade proposal that is included in Octez v20.0 as a user-activated protocol override, which means that nodes running Octez v20.0 (and higher) will automatically activate the ParisB 2 patch instead of ParisB on June 4th.
We have recently discovered three potentially critical issues in the
ParisB protocol upgrade
proposal. The
first issue concerns the computation of rewards when a baker is
overstaked, while the second one involves inconsistent unstake requests. These issues could be triggered once Adaptive Issuance and Staking are
enabled, Finally, the third issue affects Smart Rollups’ WASM
PVM and
significantly increases the computational cost of fraud
proofs
(though they remain feasible).
Neither of these bugs pose a direct threat to the security nor the liveness of Tezos Layer 1 and Etherlink, but they are serious enough to warrant an immediate fix.
After careful consideration, we think that the best way forward is to address these issues in a patched protocol, ParisB 2, to be deployed as a User-Activated Protocol Override (UAPO). Alternatives, like postponing fixes until the Q protocol proposal or preparing an emergency user-activated upgrade for mainnet, were potentially too disruptive. ParisB 2 ensures that the reward distribution model on mainnet complies with its advertised specification and includes a critical improvement to the performance of refutation games.
The first issue was reported by Inference on May 21 while testing the ParisB protocol proposal. It involves a corner case in reward computation for bakers and stakers when the baker is overstaked. Stakers should see their rewards diluted while bakers receive their full share of participation rewards. However, this behavior was not implemented correctly. Typically, this flaw could be exploited by a staker holding nine times more stake than the targeted baker. At a cost to themselves, they could dilute the rewards of the baker and their stakers, a so-called griefing attack.
The second issue was discovered on May 27. It arises when the staker inserts stake operations after having changed bakers. This scenario results in the economic protocol incorrectly recording the status of the stake and provokes the failure of ensuing unstake requests.
The original specification shared with bakers, infrastructure and tooling builders does not suffer from these issues, which originate from an implementation bug. ParisB 2 patches them by ensuring that the implementation on mainnet complies with the specification and will hence contribute to providing users with the best staking UX from day one.
We thank Inference for raising the first issue and for their collaboration throughout the process.
Finally, the third issue originates from a mismatch between the ticks
limit defined in Paris for Smart Rollups’ WASM PVM (11 billion ticks
per kernel_run execution) and the one used in the EVM-kernel used
recently to deploy Etherlink‘s beta (50
trillion ticks). While this discrepancy does not jeopardize rollup
security, it affects the performance of refutation games, making them
significantly more computationally demanding.
Addressing this issue in ParisB 2 will improve the performance of refutation games, reducing the barrier of entry for honest participants. This contributes to strengthening the overall security and stability of Etherlink‘s deployment.
Today, Octez v20.0 was
released. It
includes ParisB 2 and implements, as mentioned above, a UAPO for
ParisB. This means that nodes running Octez v20.0 will activate
ParisB 2, PtParisBxoLz5gzMmn3d9WBQNoPSZakgnkMC2VNuQ3KXfUtUQeZ,
instead of the original ParisB proposal before block
#5,726,209.
Tezos bakers and node operators, let’s ensure a smooth activation of ParisB 2 on June 4th!
Octez v20.0 is the minimal compatible version with the ParisB 2 protocol. Note that Octez versions prior to v20.0 do not include the ParisB 2 protocol, and bakers and node operators running incompatible versions would see themselves unable to participate in Layer 1 consensus.
We are available to answer further questions and concerns on this patch, or other Paris protocol proposal features, via all of our usual channels. We will disclose further details on these issues and their resolution after protocol activation.