Skip to content

Latest commit

 

History

History
96 lines (60 loc) · 4.85 KB

0088.md

File metadata and controls

96 lines (60 loc) · 4.85 KB
Raw

BRC-88: Overlay Services Synchronization Architecture

Ty Everett ([email protected])

Abstract

This document outlines the Overlay Services Synchronization Architecture, detailing the Services Host Interconnect Protocol (SHIP) and Services Lookup Availability Protocol (SLAP). These protocols enable efficient peer discovery and data synchronization across UTXO-based overlay networks. This BRC defines the components, interactions, and responsibilities of nodes running these protocols to maintain reliable and up-to-date overlay services.

Motivation

The proliferation of UTXO-based overlay networks necessitates robust mechanisms for peer discovery and data synchronization. While BRC-22 defines transaction submission and processing, SHIP and SLAP extend this by providing standardized methods for discovering the overlay hosts that run particular services. This architecture ensures seamless interaction between network participants, improving the efficiency and reliability of data propagation. It can also enable the users of services to find hosts that are interested in their transactions.

Background

Readers of this document should be familiar with BRCs 45, 59, 22, 24, 23, and 25.

Specification

Overview

The Overlay Services Synchronization Architecture comprises two fundamental protocols:

  1. Services Host Interconnect Protocol (SHIP)
  2. Services Lookup Availability Protocol (SLAP)

Each node running overlay services will implement topic managers and lookup services for both SHIP and SLAP, ensuring alignment between advertised services and their actual configuration.

Components

  • SHIP/SLAP Topic Managers: Manage topic-specific transaction admittance.
  • SHIP/SLAP Lookup Services: Provide mechanisms for querying UTXO states within topics.
  • Advertiser: Handles the creation and revocation of SHIP and SLAP advertisements.
  • Overlay Services Engine: Coordinates the processing of transactions, alignment of advertisements, and synchronization of data across various services.

Key Responsibilities

1. Ensuring Alignment

Each node must ensure alignment between the SHIP and SLAP advertisements it has sent out and the current set of topic managers and lookup services it is configured with.

2. Hosting SHIP/SLAP Overlay Networks

Nodes host copies of the SHIP and SLAP overlay networks, ensuring they are updated with new advertisements or revocations.

  • Submission: Any node can submit SHIP/SLAP advertisements to another node if it knows its domain name, updating the overlay network.
  • Internal Updates: Nodes submit their own advertisement transactions to themselves to update the overlay networks about new advertisements or revocations, thereby ensuring their hosted copies are always current and propagating them to other nodes.

3. Transaction Propagation

As part of the transaction submission process, nodes notify each other about transactions on topics they host and care about.

When new transactions are submitted to a node, the Engine:

  • Ensures transactions are propagated to relevant nodes based on SHIP/SLAP advertisements made by them.
  • Updates lookup services with new or spent UTXOs.
  • Delegates transaction submission, verification, and output admittance to the SHIP/SLAP topic managers.

SHIP and SLAP Token Formats

SHIP Token Format

Field Meaning
Field 1 The string SHIP, denoting a SHIP advertisement.
Field 2 The BRC-31 identity key of the advertiser.
Field 3 The domain name of the HTTPS server hosting the network node.
Field 4 The topic name hosted by the advertiser.

SLAP Token Format

Field Meaning
Field 1 The string SLAP, denoting a SLAP advertisement.
Field 2 The BRC-31 identity key of the advertiser.
Field 3 The domain name of the HTTPS server hosting the network node.
Field 4 The service name, represented by a BRC-24 provider ID.

Token Creation and Submission

The advertiser creates a transaction output containing the token and submits it to known nodes, including their own. The process involves:

  1. Deriving the locking key using the advertiser's identity key.
  2. Computing the signature over the token fields.
  3. Creating and submitting the transaction output containing the token.

Token Validation and Admission

Nodes validate the identity key's link to the signature-producing key before admitting the output. The steps include:

  1. Extracting token fields.
  2. Verifying the SHIP/SLAP identifier.
  3. Verifying the locking key and signature.
  4. Admitting the token if valid.

Implementation

Developers should implement an HTTPS server that hosts the SHIP and SLAP topic managers and lookup services. The server should be responsible for notifying other nodes of relevant transactions and maintaining synchronization.