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

fix all broken links in README #32

Merged
merged 5 commits into from
Oct 30, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 12 additions & 12 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -25,7 +25,7 @@ These two points have been addressed through the Registry Coordinator/Registry A

#### Quorums

Quorums are the different divisions of the operator set for an AVS. One can think of a quorum being defined by the token staked for that quorum, although [it is slightly more complicated than that](./StakeRegistry.md#definitions). One often wants to make trust assumptions on quorums, but wants many quorums for the same AVS.
Quorums are the different divisions of the operator set for an AVS. One can think of a quorum being defined by the token staked for that quorum, although [it is slightly more complicated than that](./docs/StakeRegistry.md#definitions). One often wants to make trust assumptions on quorums, but wants many quorums for the same AVS.

One example of the quorum concept is in EigenDA, where we have a single ETH quorum for which LSTs and native beacon chain ETH are accepted as stake and another quorum for each rollup that wants to stake their own token for security.

Expand All @@ -36,15 +36,15 @@ The Registry Coordinator is a contract that is deployed by each AVS. It handles
- Keeping track of what quorums operators are a part of
- Handling operator churn (registration/deregistration)
- Communicating to registries
The current implementation of this contract is the [BLSRegistryCoordinatorWithIndices](./BLSRegistryCoordinatorWithIndices.md).
The current implementation of this contract is the [BLSRegistryCoordinatorWithIndices](./docs/BLSRegistryCoordinatorWithIndices.md).

### Registries

The registries are contracts that keep track of the attributes of individual operators. For example, we have initially built the

- [StakeRegistry](./StakeRegistry.md) which keeps track of the stakes of different operators for different quorums at different times
- [BLSPubkeyRegistry](./BLSPubkeyRegistry.md) which keeps track of the aggregate public key of different quorums at different times. Note that the AVS contracts use [BLS aggregate signatures](#bls-signature-checker) due to their favorable scalability to large operator sets.
- [IndexRegistry](./IndexRegistry.md) which keeps track of an ordered list of the operators in each quorum at different times. (note that this behavior is likely only needed for EigenDA)
- [StakeRegistry](./docs/StakeRegistry.md) which keeps track of the stakes of different operators for different quorums at different times
- [BLSPubkeyRegistry](./docs/BLSPubkeyRegistry.md) which keeps track of the aggregate public key of different quorums at different times. Note that the AVS contracts use [BLS aggregate signatures](#bls-signature-checker) due to their favorable scalability to large operator sets.
- [IndexRegistry](./docs/IndexRegistry.md) which keeps track of an ordered list of the operators in each quorum at different times. (note that this behavior is likely only needed for EigenDA)
Registries are meant to be read from and indexed by offchain AVS actors (operators and AVS coordinators).

A registry coordinator has 1 or more registries connected to it and all of them are called when an operator registers or deregisters. They are a plug and play system that are meant to be added to the RegistryCoordinator as needed. AVSs should create registries they need for their purpose.
Expand Down Expand Up @@ -78,15 +78,15 @@ These structs, consecutively, are a history of the `Value` over certain ranges o

At the core of many AVSs on EigenLayer (almost all except those that affect Ethereum block production) is the verification of a quorum signature of an AVS's operator set on a certain message and slashing if some quality of that message and other state is true. The registry architecture is optimized for making this signature as cheap as possible to verify (it is still relatively expensive).

The current implementation of this contract is the [BLSSignatureChecker](./BLSSignatureChecker.md).
The current implementation of this contract is the [BLSSignatureChecker](./docs/BLSSignatureChecker.md).

## Further reading

More detailed functional docs have been written on the AVS architecture implemented in the middleware contracts. The recommended order for reading the other docs in this folder is

1. [BLSRegistryCoordinatorWithIndices](./BLSRegistryCoordinatorWithIndices.md)
2. [BLSPublicKeyCompendium](./BLSPublicKeyCompendium.md) and [BLSPublicKeyRegistry](./BLSPubkeyRegistry.md)
3. [StakeRegistry](./StakeRegistry.md)
4. [IndexRegistry](./IndexRegistry.md)
5. [BLSOperatorStateRetriever](./BLSOperatorStateRetriever.md)
6. [BLSSignatureChecker](./BLSSignatureChecker.md)
1. [BLSRegistryCoordinatorWithIndices](./docs/BLSRegistryCoordinatorWithIndices.md)
2. [BLSPublicKeyCompendium](./docs/BLSPublicKeyCompendium.md) and [BLSPublicKeyRegistry](./docs/BLSPubkeyRegistry.md)
3. [StakeRegistry](./docs/StakeRegistry.md)
4. [IndexRegistry](./docs/IndexRegistry.md)
5. [BLSOperatorStateRetriever](./docs/BLSOperatorStateRetriever.md)
6. [BLSSignatureChecker](./docs/BLSSignatureChecker.md)
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
86 changes: 0 additions & 86 deletions docs/middleware/README.md

This file was deleted.