docs(consensus): describe the attestor committee (#2550)

## 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

@@ -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)

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`