Experiment with Payment Channels on Stellar

It’s been a minute since we talked about CAP-21 and CAP-40, so let’s do a little recap (reCAP, get it?).

CAP-0021 introduced new optional preconditions that affect a transaction’s validity and are integral to a payment channel’s functionality. Among the preconditions are:

• Minimum sequence number - typically on Stellar, accounts must submit transactions to the network with sequence numbers incrementing by one. This can be problematic when submitting multiple transactions quickly as they may validate out of order, resulting in errors.
  
  With this precondition set, you can skip sequence numbers, allowing you to successfully submit a transaction as long as its sequence number is larger than the minSeqNum.
• Minimum sequence age - allows you to enforce relative timelocks on a transaction, meaning a transaction is only valid when a set duration elapses since the account’s sequence number age.
  
  This precondition can enforce a time separation between the declaration of the payment channel’s close and the actual close, which lets each party contest the channel’s final state.

CAP-0040 introduces a new signer type that can simplify the signing process. In payment channels, participants must exchange signatures across multiple transactions on-chain (open, declaration, and close). CAP-40’s introduction of a new signer type makes it possible for parties to exchange all signatures for a set of transactions in a single message, reducing complexity without sacrificing security.

With Protocol 19 in place, Stellar users and builders are free to explore the wondrous world of payment channels! And even experiment with Starlight — SDF’s very own Layer 2 payment channel protocol, which you can read about in our earlier blog here.

Payment channels are great for doing heaps of transactions inexpensively and in a short amount of time. You’re probably thinking: “But Stellar is already cheap and fast, why do I need payment channels?” Good question. Stellar does have low fees and fast TPS. However, while Stellar’s Layer 1 network typically processes around 200 transactions per second, Starlight recorded 1.19 million (that’s right, million) payments per second between two users. If you have a use case for doing loads of micropayments in a short period of time, payment channels might be worth looking into.

Another great thing about payment channels is that no matter how many transactions are performed in the channel, only three are recorded on-chain (opening the channel, declaration of the close, and the close). This gives you what you want out of high TPS without actually increasing the TPS on the network, freeing up the network for more exciting things, like issuing your own HAMSTER token.

So, most of a payment channel’s transactions take place off-chain. Does that mean we’re sacrificing security? It most certainly does not! Payment channels on Stellar are cryptographically secure. You still need to sign and agree on every transaction when transacting off-chain.

Let’s break down how this works.

Note here that Starlight is only one flavor of payment channel, something you can use, modify, and expand on. It exhibits a two-party, two-sided relationship- but payment channels aren’t limited to this scenario. You can experiment with multiple-party payment channels if you’d like, and we encourage that experimentation!

Let’s put together a little scenario. Walker and Daniel want to open a payment channel together. Walker has been blatantly stealing Daniel’s WiFi, and Daniel has decided it’s time for Walker to start paying (hopefully not with HAMSTER tokens).

1. Daniel proposes to open a payment channel with Walker.
2. Walker accepts, which opens the payment channel.
3. With the payment channel open, two new multi-sig accounts are created: one for Daniel (DM) and one for Walker (WM).
   a. Since Daniel is the initiator, his multi-sig account (DM) is the source account for the transactions within the payment channel and is used to track the state of the channel.
   b. DM holds the assets that Daniel contributes to the payment channel; WM holds the assets that Walker contributes to the payment channel.
   c. DM and WM are controlled by both Daniel and Walker’s accounts when the payment channel is open.
4. DM and WM transact in the payment channel.
   a. These transactions happen off-chain, with each payment dictating a new final balance that Daniel and Walker will receive or pay at the channel’s close.
5. Daniel expresses his desire to close the payment channel with the declaration transaction.
6. Because of CAP-21’s relative timelock precondition, Walker has time to assess the final state of the payment channel and dispute it if necessary.
7. Once the declaration transaction is signed by both parties and submitted, the closing transaction is also submitted on-chain, finalizing the close of the payment channel.
   a. Depending on the final state of the channel, assets are distributed from DM to WM or vice versa.
   b. Control of WM is returned to Walker, and DM is returned to Daniel.

This is a very basic rundown of how payment channels work. If you’re interested in seeing the process in 1080p detail, check out this SDF video: Starlight Meridian Video and the detailed documentation for Starlight.

No, I did not spell ‘Starlight’ incorrectly. Starlite is a web-based payment channel prototype, proof of concept, demo, if you will, brought to you by SDF Ecosystem Engineer Tyler van der Hoeven to help you see payment channels in action. It’s not pretty, but there’s something to be said for simplicity, yes?

Check it out to see how fast payments can be made off-chain and how quickly it reaches final state on-chain.

There are many possibilities that Protocol 19 brings to the Stellar network. Whether you’re working with bridges, payment channels, or anything in between, feel free to engage and ask questions in our Stellar Developer Discord (check out the #starlight channel specifically).