This is a joint post from Nomadic Labs, TriliTech, and Functori.
Hi everyone,
We’d like to start by thanking you for your continued support of Etherlink, especially through these last couple of months - we don’t take it for granted.
Tomorrow, on Wednesday, August 19th, we will resubmit Etherlink 7.0 (Ganesha) through Etherlink’s Fast governance upgrade mechanism. It carries the same name and almost the same core feature set as the proposal the community reviewed and supported earlier this cycle, but it is a new kernel with a new root hash. This post covers what changed, why we are taking this route, and what we commit to publishing afterwards.
Where things stand
Etherlink 7.0 received bakers’ support in the Proposal period. We then identified a security vulnerability in that kernel and asked bakers to downvote it. That kernel was never activated, so Mainnet was never exposed to it.
What changed since our first submission
We have added several improvements to the kernel codebase. Compared to the kernel we asked you to reject, this new kernel contains:
-
The patch addressing the vulnerability that led us to ask for a “nay”. For a detailed explanation of the issue and how we fixed it, you can have a look at the MR !22693.
-
Several rounds of hardening of the Michelson runtime addressing flaws caught by our continuous audit process.
-
Several quality-of-life improvements for indexers and RPC consumers, following external feedback that we received.
-
Some low-impact scope reduction for Native Atomic Composability (NAC). Specifically, we removed same-runtime NAC (EVM to EVM, Michelson to Michelson) - no builder or user would ever need it, so this changes nothing you’d actually use.
Everything else is fundamentally unchanged: this new iteration of Ganesha delivers the same set of core features as the one you reviewed: the Michelson interface, cross-runtime Native Atomic Composability, RPC compatibility, and the EVM interface fixes, exactly as described in the original announcement, minus the NAC scope reduction described above. All the changes we have made are publicly available in the etherlink-ganesha branch, the full changelog can be read here, and a summary is available on the Previewnet dashboard (v0.9 and v0.10). Previewnet has already been upgraded, so you can try it out there.
Additionally, we have found a security issue currently affecting Etherlink Mainnet. We have written a fix on top of the etherlink-ganesha branch, and we are proposing to include it in the kernel bakers will vote on Wednesday. As we’ve done before with security issues found on Etherlink Mainnet, we cannot share the technical details of the patch ahead of the vote; we will publish a detailed postmortem in due course after the upgrade is activated.
Why fast-track, and why one vote instead of two
The Etherlink 7.0 proposal has already been through a full Slow governance cycle so it has already been reviewed, and bakers have already expressed their support. Running a full second Slow cycle would mean asking you to re-litigate ground you’ve already covered, adding ten days to the process. Moreover, there is a pressing need to fix the bug currently affecting the kernel running on Etherlink Mainnet. Submitted on its own, that fix would mean asking you for a separate vote within the next few weeks - on top of this one.
Combining these two proposals into one is the most efficient path, to optimize everyone’s time and be mindful about the number of governance cycles you’d need to follow, but also to bring to life both the fixes and the features that bakers supported through the last voting round.
We’d like to stress again that because the fix affecting Etherlink Mainnet remains undisclosed, you will not be able to reproduce this kernel’s root hash from public source before voting, as you could for the first 7.0 submission. Once the upgrade is activated after reaching the quorum, and Mainnet is safe, we commit to publish the complete changelog and source of the security fixes, and the reproduction instructions for the root hash – so that anyone can check that the kernel you voted on contains exactly what we said it contains.
Voting Periods
Proposal period vote: fast governance period 609, spanning between L1 level #14,563,489 (Wednesday, August 19, 03:48 CEST) and #14,568,288 (Wednesday, August 19, 11:48 CEST).
Promotion period vote: fast governance period 610, spanning between L1 level #14,568,289 and #14,573,088 (Wednesday, August 19, 19:48 CEST).
Fast governance periods last ~8 hours, so both votes fall on the same day. The Proposal period is the tight one: it opens in the early hours of Wednesday morning and closes at ~11:48 CEST. Fast governance also requires a 5% quorum on the proposal itself to move to Promotion, where slow governance only requires 1%. If you can cast your upvote first thing on Wednesday morning, it will make a real difference. The Promotion period then leaves most of the working day, and requires a 15% quorum and an 80% “yea” supermajority.
You can upvote the Etherlink 7.0 kernel during the Proposal period using the following Octez CLI command:
octez-client call KT19oUVQPnVLuUBYXrBVd46WJnNAMpqkKSwo from <baking_key or voting_key> \
--entrypoint "upvote_proposal" \
--arg "0x008c903318dfc0016de771f981069498f7774f3c35ffcc3f2dce63f5a3b6d03df6" \\
--burn-cap 0.11
If the Proposal period is successful, you will be able to upvote the kernel proposal during the Promotion period :
octez-client call KT19oUVQPnVLuUBYXrBVd46WJnNAMpqkKSwo from <baking_key or voting_key> \
--entrypoint "vote" --arg '"yea"' \
--burn-cap 0.11
See How is Etherlink governed? | Etherlink documentation for further instructions on how to participate in Etherlink’s governance.
Once again, we thank you for consistently supporting Etherlink, particularly in helping strengthen its security posture.
