| Internet-Draft | ChainSync | December 2025 |
| Douglas Dohmeyer | Expires 5 June 2026 | [Page] |
ChainSync is a lightweight application-layer protocol that runs over reliable TCP connections to synchronize a fixed linear chain of distributed processes (labeled A, B, C, ..., N) such that they execute their local tasks in strict sequential order (A -> B -> C -> ... -> N) and only after every process in the chain has confirmed it is ready.¶
The protocol uses three distinct phases:¶
Forward "readiness" wave (SYNC -> READY propagation from head to tail)¶
Backward "start" wave with deferred execution and watching (START propagation from tail to head)¶
Forward "completion" wave that triggers execution in the required order and provides clean backward-propagating exit¶
The design guarantees strict ordering even when nodes become ready at very different times and requires only point-to-point TCP connections along the chain -- no central coordinator is needed.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 5 June 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Many distributed workflows (pipeline parallelism in machine-learning training, staged data processing, multi-organization business processes, ordered multi-phase computation, etc.) require that tasks execute in a fixed order across different machines, yet must not begin until every participant is ready.¶
Standard barriers do not enforce execution order. Token-passing or leader-based schemes introduce complexity and single points of failure.¶
ChainSync solves this with a simple, fully decentralized three-wave algorithm on a line topology that guarantees:¶
No process starts until the entire chain is ready.¶
Execution order is strictly A -> B -> ... -> N.¶
Clean backward-propagating exit after N finishes.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The processes form a static logical chain:¶
(Head) A <-> B <-> C <-> ... <-> N (Tail)¶
Each process knows:¶
IP address and port of its predecessor (Head has none)¶
IP address and port of its successor (Tail has none)¶
Whether it is head, tail, or intermediate (inferable from presence/absence of predecessor/successor)¶
Each adjacent pair maintains a single persistent bidirectional TCP connection.¶
| State | Meaning |
|---|---|
| SYNC | Initial state; waiting for READY from predecessor (Head starts here but moves to READY when locally ready) |
| READY | Chain segment to the left is ready; has sent READY to successor |
| WATCH | Has propagated START leftward; waiting for COMPLETE from predecessor |
| START | Currently executing its local task |
| COMPLETE | Local task finished; has sent COMPLETE to both directions as required |
Messages are simple ASCII text lines terminated by LF. Recommended format:¶
<COMMAND>[:<ROUND-ID>]\n¶
Defined commands:¶
<ROUND-ID> is optional but RECOMMENDED (e.g., UUID) to support multiple concurrent rounds on the same connection. Implementations running only one round at a time MAY omit it.¶
Tail, upon entering READY, sends START to predecessor and moves to WATCH.¶
Intermediate node, upon receiving START from successor:¶
Head, upon receiving START, has no predecessor and therefore moves directly to START and begins execution.¶
This phase completes in O(n) messages and guarantees every node knows the entire chain is ready before any node starts.¶
A node in WATCH that receives COMPLETE from its predecessor moves to START and begins its local task.¶
When a node finishes its task, it moves START -> COMPLETE and:¶
A node in COMPLETE that receives COMPLETE from its successor MAY terminate.¶
Execution order is therefore strictly A -> B -> C -> ... -> N.¶
The RECOMMENDED approach is push-based: the node simply blocks on read() from the predecessor's TCP socket. When the predecessor finishes, it pushes COMPLETE. An alternative approach is to poll the predecessor's TCP socket.¶
Both approaches are compliant.¶
RD: READY
ST: START
CM: COMPLETE¶
A.....B.....C.....D
|-RD->|.....|.....| Phase 1
|.....|-RD->|.....|
|.....|.....|-RD->|
|.....|.....|<-ST-| Phase 2
|.....|<-ST-|.....|
|<-ST-|.....|.....| Phase 3
|.....|.....|.....| A starts immediately
|-CM->|.....|.....| A finishes and B starts
|.....|-CM->|.....| B finishes and C starts
|.....|.....|-CM->| C finishes and D starts
|.....|.....|<-CM-| D finishes
|.....|<-CM-|.....X D exits
|<-CM-|.....X...... C exits
|.....X............ B exits
X.................. A exits¶
This memo includes no request to IANA.¶
Connections SHOULD use TLS 1.3. Production deployments SHOULD use mutual TLS with certificate pinning or pre-shared keys to prevent node impersonation.¶