Skip to main content

Messaging and Checkpoints

note

Please refer to Overview for an introduction.

Terminology​

There are two types of units of work that NFFL Operators must complete: Messages and Tasks.

Messages are:

  • Generated by the operators in a distributed manner, there's no centralised coordinator.
  • Stored off-chain, since it's not cost and speed-effective to store them all individually on-chain.
  • Verified on demand, messages are not always verified on-chain - they should be available for verification at all times, but it's not necessary that the attestation is submitted on-chain.

Tasks are:

  • Generated by the Task Manager on-chain, which must determine the work that should be done and expect an answer from the operators.
  • Stored on-chain, Tasks are stored directly on the AVS contracts, and a response is expected to be submitted on-chain in a certain time range.
  • Always verified on-chain, Operators response to Task are verified on-chain. Failed verification of a Task represents a protocol fault.

Rationale​

EigenLayer's implementation of a Task is really similar to the definition above. However, EigenLayer Task is not a good choice for keeping track of the work done by the NFFL nodes. The main job of the NFFL node is to agree on state root updates - i.e. block based progression of each participant network. If each of those updates was an (on-chain) Task, the NFFL would most likely not be feasible in terms of operation cost and would also suffer a great blow in terms of a faster finality.

With this problem in mind, Message was defined. It then enables high throughput and most importantly essentially off-chain operations. However, it's still necessary to formalize an on-chain unit of work - not only so the NFFL progress is available on-chain but also to allow for fair slashing and payment designs.

Checkpoint Task​

In order to allow for the implementation of slashing and payment processes, the AVS Task was defined as a Checkpoint Task.

A Checkpoint Task is, essentially, comprised of the submission of a merkle root of the attested Messages during a time range. Checkpoint Task are submitted at a regular cadence. Checkpoint Task not only provides a safe ledger to the AVS state, but also allows for establishing slashing and payment processes while keeping the NFFL cost of operation cheap.

To facilitate the Checkpoint Task, the operators must then agree on all the Messages sent in that time period e.g. daily, and aggregate them into a Sparse Merkle Tree (SMT). Anyone that has a copy of this SMT, can generate proofs of membership and non-membership for any Message. This way, any Message that should've been attested can be verified and any message that shouldn't have been attested can also be verified - leading to both punishments and also liveness tracking.

NFFL Messages​

There are two Messages in NFFL:

  • StateRootUpdateMessage: A state root update Message attests to the state root of a network at a specific block height and timestamp.
library StateRootUpdate {
    struct Message {
        uint32 rollupId;
        uint64 blockHeight;
        uint64 timestamp;
        bytes32 nearDaTransactionId;
        bytes32 nearDaCommitment;
        bytes32 stateRoot;
    }

    // ...
}
  • OperatorSetUpdateMessage: An operator set update message attests to an AVS operator set delta on Ethereum at a specific timestamp. All operator set updates in a block are aggregated and attributed an auto-incrementing ID, and include all the operators whose weights changed.
library OperatorSetUpdate {
    struct Message {
        uint64 id;
        uint64 timestamp;
        Operators.Operator[] operators;
    }

    // ...
}