Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs(consensus): describe the attestor committee #2550

Merged
merged 11 commits into from
Aug 1, 2024
41 changes: 41 additions & 0 deletions docs/guides/external-node/10_attestator_committee.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
# Attester Committee

## Overview

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.
RomanBrodetski marked this conversation as resolved.
Show resolved Hide resolved

## Current State

Before we start the L1 integration,
we want to make sure we are able 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 them 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 behaviour 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).

One can leave the committee any time.

The only action that is required to participate is to share your attester public key with the Main Node operator.
RomanBrodetski marked this conversation as resolved.
Show resolved Hide resolved
You can find it in the comment in `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
`
Loading