Overlay Services Synchronization Architecture
Ty Everett (ty@projectbabbage.com)
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:
Services Host Interconnect Protocol (SHIP)
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 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
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:
Deriving the locking key using the advertiser's identity key.
Computing the signature over the token fields.
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:
Extracting token fields.
Verifying the SHIP/SLAP identifier.
Verifying the locking key and signature.
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.
Last updated