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