Owner: @Marcin Pawlowski

Reviewers: 🟢@Mehmet 🟢@Daniel Sanchez Quiros 🟢@Álvaro Castro-Castilla 🟢@Thomas Lavaur 🟢@Gusto Bacvinka 🟢@David Rusu

Introduction

This document defines a mechanism enabling validators to declare their participation in specific protocols that require a known and agreed-upon list of participants. Some examples of this are Data Availability and the Blend Network. We create a single repository of identifiers which is then used to establish secure communication between validators and provide services. Before being admitted to the repository, the validator proves that it locked at least a minimum stake.

Requirements

The requirements for the protocol are defined as follows:

• A declaration must be backed by a confirmation that the sender of the declaration owns a certain value of the stake.
• A declaration is valid until it is withdrawn or is not used for a service-specific amount of time.

Overview

The SDP enables nodes to declare their eligibility to serve a specific service in the system, and withdraw their declarations.

Protocol

The protocol defines the following actions:

• Declare: A node sends a declaration that confirms its willingness to provide a specific service, which is confirmed by locking a threshold of stake.
• Active: A node marks that its participation in the protocol is active according to the service-specific activity logic. This action enables the protocol to monitor the node’s activity. We utilize this as a non-intrusive differentiator of node activity. It is crucial to exclude inactive nodes from the set of active nodes, as it enhances the stability of services.
• Withdraw: A node withdraws its declaration and stops providing a service.

The logic of the protocol is straightforward.

1. A node sends a declaration message for a specific service and proves it has a minimum stake.
2. The declaration is registered on the ledger, and the node can commence its service according to the service-specific service logic.
3. After a service-specific service-providing time, the node confirms its activity.
4. The node must confirm its activity with a service-specific minimum frequency; otherwise, its declaration is inactive.