In June of this year, the Stellar network was upgraded to Protocol 19, which implemented CAP-0021 (Generalized Transaction Preconditions) and CAP-0040 (Ed25519 Signed Payload Signer for Transaction Signature Disclosure). These two new CAPs open up many opportunities to users, including bridges to other blockchains, key recovery solutions, and payment channels, which is our main topic for today.
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:
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).
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).