From c4d8c5266610deda3d43d626191be8c766c9835f Mon Sep 17 00:00:00 2001 From: Roman Brodetski Date: Thu, 1 Aug 2024 10:54:53 +0300 Subject: [PATCH] docs(consensus): describe the attestor committee (#2550) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ## What ❔ Concise description of l1 batch signing and the attestor committee. ## Why ❔ We want to encourage the partners that run the EN to also participate in this committee. --- docs/announcements/README.md | 8 +++++ docs/announcements/attester_commitee.md | 44 +++++++++++++++++++++++++ 2 files changed, 52 insertions(+) create mode 100644 docs/announcements/README.md create mode 100644 docs/announcements/attester_commitee.md diff --git a/docs/announcements/README.md b/docs/announcements/README.md new file mode 100644 index 000000000000..2e793fba7d38 --- /dev/null +++ b/docs/announcements/README.md @@ -0,0 +1,8 @@ +# ZKsync development announcement + +This directory will contain announcements that don't necessarily serve as documentation, but still provide valuable +information to be stored long-term. + +Current announcements: + +- 01.08.2024 - [Attester committee invitation](./attester_commitee.md) diff --git a/docs/announcements/attester_commitee.md b/docs/announcements/attester_commitee.md new file mode 100644 index 000000000000..84ff8aa5be6d --- /dev/null +++ b/docs/announcements/attester_commitee.md @@ -0,0 +1,44 @@ +# Attester Committee + +## Overview + +The Attester committee is a subset of ZKSync nodes. After each l1 batch execution, participating nodes sign its +execution result and send back to the network. + +The ultimate goal is to make L1 commit operation contingent on such signatures. This will improve the security and +finality guarantees: having these signatures on L1 shows that additional actors executed the corresponding blocks - and +ended up with the same state root hash. + +## Current State + +Before starting the L1 integration, we want to ensure that we can to consistently reach the quorum and collect the +signatures in a timely manner. Currently the main node just stores the signatures in the local DB +(`l1_batches_consensus` table). + +We run a (temporary) PoA network of attesters where the Main Node administrator defines the committee for every L1 +batch. There is currently no tangible incentive or any kind of actual or implied reward for the participants - we'll be +developing these and potential tokenomics later on. + +We are looking for participants to this network. + +## Participating in the Attester Committee + +Joining the attester committee imposes no additional computational, operational, security, or business overhead for EN +operators. + +The only difference in behavior is that the node would asynchronously sign batches and send those signatures to the main +node. Node checks if its public key is part of the committee for the current l1 batch - if it is, this logic kicks in. +We expect the participating nodes to have very high uptime, but there are no penalties for not submitting votes (and we +wouldn't have any way to impose this). + +Participants can leave the committee at any time. + +The only action that is required to participate is to share your attester public key with the Main Node operator (by +opening an issue in this repo or using any other communication channel). You can find it in the comment in the +`consensus_secrets.yaml` file (that was - in most cases - generated by the tool described +[here](https://github.com/matter-labs/zksync-era/blob/main/docs/guides/external-node/09_decentralization.md#generating-secrets)) + +> [!WARNING] +> +> Never share your **private** keys. Make sure you are only sharing the **public** key. It looks like this: +> `# attester:public:secp256k1:02e7b1f24fb58b770cb722bf08e9512c7d8667ec0befa37611eddafd0109656132`