Starlight: A Layer 2 Payment Channel Protocol for Stellar

CAP-21 adds a suite of new preconditions that can be added to transactions. Preconditions are conditions that must be satisfied for a transaction to be valid. An example of a well-known precondition is transaction time bounds: a transaction needs to be submitted during its time bounds. CAP-21 adds ledger bounds, minimum sequence number, extra signers, as well as the ability to create relative time locks.

Starlight uses the minimum sequence number precondition so that groups of transactions can skip sequence numbers on accounts. This means Starlight clients only need to hold on to the last agreement. There’s no need to store or revoke old agreements as they are implicitly invalidated by new agreements.

Starlight uses the relative time lock (adding relative time and ledger delays between transactions) so that when a payment channel is closing, a delay can be inserted between the start of the close process and its finish. This delay gives the other participant an opportunity to update the close to the latest state if the participant accidentally or intentionally started the close process using an old agreement.

The extra signers precondition can be used as a way to attach a stateless hash component of an HTLC (hashed timelock contract) to a transaction off-network. We expect Starlight could use this in the future to facilitate payments that span across multiple payment channels.

CAP-40 extends CAP-21 and adds a new type of signer to the Stellar network – the signature of another transaction. Starlight uses this to atomically authorize multiple transactions by disclosing the signature for one transaction inside another.

This makes it safe for a multi-participant multi-transaction contract protocol (like Starlight) to pass multiple transactions in a single message rather than needing to use a multi-part handshake protocol. This reduces the number of messages payment channel users need to pass back and forth, reduces the number of potential channel states, and increases the number of agreements that Starlight can process per second.

The prototype we’ve been experimenting with builds on the Starlight protocol and implements buffering. Buffering is not defined in the Starlight protocol, but is one pattern that is well-suited to be used a-top of the protocol. Serial payment channels, such as Starlight, are usually limited by the latency of the network they operate. For example, if the network latency is 20 milliseconds, the maximum possible throughput would be 50 transactions per second. Buffering makes use of available network bandwidth by collecting payments during those 20 milliseconds and sending them over the wire together in a single agreement. The limit is transformed into 50 agreements per second, and each agreement can hold many payments. Instead of getting confirmation of one payment every 20 milliseconds, the channel can deliver confirmation of many payments in a single agreement in milliseconds.

Buffering is similar to batch processing in slow traditional payments systems, except that because Starlight is fast, buffers are small and transmit quickly, so it maintains fast finality.

We’ve measured Starlight producing 38 payments per second unbuffered and 1.19 million payments per second buffered in 12 agreements per second. This was observed between two participants connected over the internet using consumer hardware and residential internet services, when those payments are flowing consistently in one direction.

This measurement well exceeds the needs of enterprises building on blockchain and enterprises transitioning existing high throughput loads to blockchain. These findings are interesting to Stellar users who frequently transact with each other, where payment channels are applicable.

There’s still more work to be done and more to explore in making Starlight ready for use. Starlight today specifies the mechanisms that two users can use to construct and make payments for a single asset inside a bi-directional half-duplex payment channel between just those two participants. Many of the layers around those mechanisms still need to be well defined, such as how participants coordinate who can make the next payment, messaging formats, connection handshakes, etc.

We recognize the exciting possibilities that a Layer 2 protocol like Starlight can bring to Stellar, and we want to collaborate with the broader ecosystem to ensure that this technology will provide utility for users down the road. If you have any ideas on what use cases Starlight could apply to or feedback overall, please reach out here.

To find out more about how Starlight works:

• Watch a demo of Starlight and buffered payments in this talk at Meridian where we go into detail about how CAP-21, and CAP-40, and buffered payments work.
• Read the Starlight mechanism specification.
  

You can experiment with Starlight today with the prototype Starlight Go SDK on devnet. The SDK provides a state machine that implements the mechanisms as well as rudimentary messaging, connection management, and state persistence that are suitable for experimentation and testing. Our GitHub repository has all the details and tracks problems to solve and future developments. If you’re a developer, star the repo and get involved!