Addressing Aggregated Public Key Updates in a Dynamic Node Network

[abramsymons]

Description

When a node in the Zellular sequencer network joins, leaves, or changes its public key, the aggregated public key (APK) of the network changes. Currently, each node fetches and periodically updates the list of network nodes at predefined intervals. This periodic synchronization introduces potential inconsistencies:

The leader node might have a different view of the aggregated public key than other nodes, leading to verification failures for the locking and finalization proofs generated by the leader on other nodes.

Problem Scope

This issue is further complicated by the following:

• Continuous Updates: Node list changes can occur continuously rather than at isolated intervals.
  Multi-State Management: Multiple state changes (e.g., node additions/removals/updates) may occur in quick succession, requiring a mechanism to manage these transitions effectively.
• Leader-Replica Synchronization: Since replicas are no longer actively fetching updates, a robust mechanism is required to ensure the leader provides consistent and up-to-date state information to the replicas.
• State Expiration and Validation: Replica nodes must be able to enforce expiration of old states to ensure the leader is not withholding updates.

Proposed Solution

To address this issue, the following approach is suggested:

1. Tagging and Timestamping States:

• Each state of the nodes list is tagged with a unique identifier and a timestamp to track its validity and version.

2. Node List Query by Tag:

• Enable nodes to query the node list using a specific tag, allowing them to retrieve the exact state associated with that tag.

3. Leader-Only Updates:

• Automatic updating of the node list should be restricted to the leader/sequencer node. Replica nodes will no longer perform periodic updates.

4. Tag-Driven Synchronization:

• Replica nodes should receive the tag corresponding to the state of the nodes list that the locking or finalization proof was generated against.
• On receiving a finalization or locking request, replica nodes will:
  • Check if the tag is new.
  • Query the updated node list using the tag to retrieve the state specified by the leader.
  • Validate the timestamp of the retrieved state and, if valid, update their local node list to the suggested state.

5. Leader’s Responsibility for Updates:

• The leader node must periodically issue a new tag with a recent timestamp, even if no changes have been applied to the node list. This ensures replicas can track the leader’s active management of the network state.

6. State Expiration and Disputes:

• Replica nodes maintain an expiration time for each state. If the leader fails to provide a new tag before the expiration time, replicas will consider the state expired and dispute against the leader. This prevents the leader from hiding updates and ensures transparency and accountability in the network.

Benefits

Implementing this solution ensures:

• Consistency: Replicas have a consistent and up-to-date view of the aggregated public key.
• Transparency: State expiration mechanisms prevent the leader from withholding updates from replicas.
• Reliability: Verification of locking and finalization proofs is robust even in dynamic network conditions.
• Fault Detection: Expiration and dispute mechanisms detect inactive or malicious leaders.

Impact

This solution addresses the core challenges of maintaining a dynamic network where nodes frequently change while ensuring trust, transparency, and synchronization between the leader and replicas.

[abramsymons]

Update: New Subgraph Version for Monitoring Zellular AVs Deployed

A new version of the subgraph for monitoring Zellular AVs has been deployed with the following configuration:

indexerHints:
  prune: never

You can access it at the following endpoint:

https://api.studio.thegraph.com/query/95922/avs-subgraph/version/latest

Querying State by Block Number (Tag)

Block numbers can now be used as tags to query the specific state of operators at a particular block. For example, to get the state at block 2074515, use the following query:

query GetOperatorsByBlock {
  operators(block: { number: 2074515 }) {
    id
    socket
    stake
    blockNumber
    blockTimestamp
  }
}

```Querying the Latest State

To fetch the latest state of operators along with their block number (tag) and timestamp, use this query:

query GetLatestOperatorsState {
  operators {
    id
    socket
    stake
    blockNumber
    blockTimestamp
  }
}

Feel free to explore and use this subgraph for monitoring and debugging purposes. Let me know if there are any questions or issues!