Announcing Protocol 19

Protocol 19 implements two Core Advancement Proposals.

CAP-21 introduces a new suite of transaction preconditions, which are optional requirements you can add to control transaction validity. Time bounds, which have long been a Stellar transaction precondition, allow you to craft transactions that are only valid in a specific time-based window. The new Protocol 19 preconditions allow you to craft transactions that skip sequence numbers, set ledger bounds, enforce relative time and ledger delays (aka "relative timelocks"), and require extra signers (e.g. hash locks).

CAP-40 adds a new signer type that allows multiple parties to build a set of transactions for signing that guarantee if one transaction is signed, authorized, and submitted, information is revealed that allows all other transactions in the set to be authorized as well.

The Protocol 19 changes were designed to facilitate the creation of payment channels, which are Layer 2 protocols that support high-throughput use cases. Payment channels allow two parties who frequently transact with one another to move the bulk of their activity off chain, while still recording opening balances and final settlement on chain.

Generally, payment channels rely on a structured sequence of transactions. Two parties open a channel with an on-chain transaction that gives both parties control over the settlement accounts. They then pass transactions back and forth, validate them, and sign them off chain. When one party is ready to settle, they declare their intention to close the channel, and there's a window of time for the other party to object. That way, the notified party has recourse if there's a dispute, or the declaration of closure is premature, malicious, or erroneous. If all is well, the settlement transaction is submitted to the network, and the final transfer of funds happens on chain.

Creating an account both parties control has always been easy using Stellar's built-in multi-sig capabilities, but prior to Protocol 19, it was difficult to handle the rest of that process. A transaction could only be valid if the source account's sequence number was exactly 1 greater than the sequence number used for the previous transaction, which meant that two parties exchanging transactions couldn't increment the sequence number in an off-chain channel. You also couldn't add a relative time delay to transactions, which meant that there was no way to ensure there was a window to object to or invalidate a settlement transaction. Finally, combining signatures to authorize a transaction required a multi-part handshake that required extra messaging and slowed things down. By adding new preconditions and a new type of signer, Protocol 19 solves all of those problems.

I realize that explanation is a bit abstract. Luckily, there's a concrete prototype of a Protocol 19 payment channel you can dig into to see how everything fits together.

Prior to implementing the Protocol 19 changes in production, SDF engineers used a sandbox devnet to build a working payment channel prototype called Starlight. By applying the minimum sequence number precondition to skip sequence numbers, adding relative time and ledger delays to create a relative timelock, and using the new signature type to atomically authorize multiple transactions, Starlight tested out all the Protocol 19 changes, and the results were pretty amazing…

In tests using consumer hardware and residential internet connections, Starlight was able to handle 1.19 million payments per second between two users.‍ Which is a lot!

Starlight is well documented, open source, and available for anyone who wants to roll up their sleeves and experiment. For more info, see:

• The Starlight blog post, which summarizes how the Protocol 19 changes allowed SDF engineers to build the prototype
• The Starlight Meridian tech talk, which includes a live demo of bi-directional payment channels
• The Starlight mechanism specification, which provides technical details about how Starlight works
• The Starlight Github Repo, which allows anyone interested to dig into the code and experiment with payment channels

Starlight is still a prototype, and there's a lot of work to do before it's ready for use in production. With the advent of Protocol 19, we're hoping to see some more ecosystem experimentation and engagement, and to hear more suggestions about how to improve and make use of Starlight. Have an idea you'd like to share? Add it to the list of use cases.

While Protocol 19 was designed to support Starlight-like payment channels, that's not the only thing the new preconditions enable you to build.

Kaladin, for instance, is building a hub-and-spoke system that connects blockchains to allow cheap, transparent swapping of assets without reliance on a trusted intermediary. Their solution relies on state channels, which are a superset of payment channels, and their Stellar integration takes advantage of the Protocol 19 preconditions to add a delay between initiating and finalizing the closing of a channel, and to create hash time lock agreements, which their protocol uses to synchronize swaps.

The Design Rationale section of CAP-21 also describes several other use cases, so if you're interested in exploring new possibilities, and you want some inspiration complete with technical details, it's a great place to start. In addition to two-way payment channels, it outlines how to create:

• One-way payment channels
• Hash Time Locked Contracts (HTLCs)
• New key recovery solutions
• Parallel transaction submission mechanisms
• Mechanisms for deterministic account sequence numbers at creation

Interested in finding out more? Check out the #protocol-19 channel on the Stellar Dev Discord. There's an active and ongoing discussion there as we work to coordinate the development and adoption of Protocol 19.