Why is Stellar Implementing the Lightning Network?

Many have long since anticipated the full implementation of Lightning Network compatibility with the Stellar Network by the end of 2018 (Q4).

For those that do not know, the Lightning Network is supposed to be a separate protocol (that word protocol is contingent upon who you ask), that was originally manifested circa 2015 as a potential remedy to the perceived ‘scalability dilemma’ for Bitcoin.

The Lightning Network is supposed to facilitate off-chain transactions in order to take some of the ‘load’ off of the ‘main chain’.

Thus, many in the crypto community have seen the implementation of the Lightning Network on Stellar’s protocol to be a largely positive thing.

The technical roadmap for the Stellar Lightning Network was published on Stellar’s website back in March:

Lightning on Stellar: Technical Spec and Roadmap

We want Stellar to become the world’s digital payment rail. We’re already the most deployment-ready of the major platforms (see the below chart), but given the scale of the future we see for Stellar, we know we need to keep pushing our technology forward.

Let’s take a brief second to review.

The article, written by ‘Christian’, one of the technical leads for Stellar Network asserts the team’s commitment to implementing the protocol in this statement below,

“ As we said in our 2018 Roadmap it’s now clear that Lightning is the right way forward for Stellar.”

The article goes on to list the following alleged benefits of Lightning Network implementation:

Source: https://www.stellar.org/blog/lightning-on-stellar-roadmap/#future_work


The article then goes on to note that:

If you’re a bit confused on what ‘state channels’ are, then the article below, which was originally posted in Hackernoon, should help catch you up to speed:


In a nutshell, state channels refer to what the Lightning Network seeks to implement on various chains.

It is explained (in its most primitive form), as the creation of an ‘off-chain’ transaction where two parties can interact with one another limitlessly without incurring any protocol-specific trading fees or having to wait until the transaction is confirmed.

When the two parties are done transacting with one another, they simply ‘publish’ the ‘state’ of the channel (i.e., the final balance) and then that final transaction balance is what is finalized on the blockchain.

Literal Translation of What is Happening in a State Channel:

The underpinning of most ‘state channels’ (particularly Lightning Network) are multi-signature wallets.

What is a multi-signature wallet?

So, you know how every transaction that you make on the Bitcoin protocol requires you to provide your private key as a ‘signature’ that proves that you’re the rightful owner of your bitcoins, correct? We no longer really see this in modern wallet interfaces, because it’s been dumbed down to let ‘non-tech’ people transact with one another — but this is literally how the protocol works.

Generally speaking, there is only one signature per public address on the protocol (we say public address and not wallet because wallets are not public keys but that’s a whole ‘nother story we’ll get to later one day).

So, a multi-signature wallet, on the other hand, is one where more than one private key is necessary to complete a transaction on the protocol.

This Medium article provides another thorough explanation of what these wallets are and how they work in relation to the Lightning Network protocol:


How ‘State Channels’ Like Lightning Network Work

It’s important to remember that you are technical not ‘off-chain’ in a literal sense — that would be impossible because blockchains are simply designed to account for the native asset in a tracked manner. Thus, there’s never a point in time when this is not happening.

So, when you enter into a ‘state channel’, the protocol perceives that as you moving your funds into another [multi-signature] wallet. It’s important to remember that the blockchain does not think about funds in terms of human-recognizable ownership. The only thing that matters in terms of ownership is who possesses the requisite private key(s) necessary to provide a signature for a transaction to be accepted and considered valid.

It is important to remember that moving one’s transactions ‘off-chain’ counts as a transaction on the protocol.

This is Where the Lightning Network protocol comes in:

Once in the ‘state channel’, the coins in that wallet are apportioned to the necessary wallets by the protocol (in this case, the Lightning Network).

To help explain this easier, let’s go with the classic Amy and Bob example:

Now let’s say Amy brought 5 bitcoins to the channel and Bob brought 3 bitcoins to the channel.

Let’s say Bob is selling some pizza and that pizza costs 1 Bitcoin (it’s the best pizza ever made in mankind).

Amy says, great Bob — this sounds like a deal.

Amy’s balance (in our heads) would be 4 $btc and Bob’s balance should reflect 4 $btc as well.

However, one must remember, the blockchain only sees this as one multi-signature channel — So, the semantic adjustment in balance for Amy and Bob has not been taken into account by the blockchain at this point.

In the blockchain’s eyes, this is still just a wallet that contains 8 bitcoins in it.

Below, is a more sophisticated diagram detailing the functionality of state channels:

Related image
Source: https://medium.com/statechannels/state-channel-applications-1f170e7d542e


Clearing Up a Misconception About State Channels; Pointing Out Some Limitations

Since there is no literal change in the balance, it is up to the users and the protocol itself (i.e., Lightning Network) to ensure that the balances are updated in the necessary manner via whatever ledger or balance of transfer that is being used in this case.

Since the state of the channel on the blockchain remains stagnant until a final status is ‘published’, and there are no miners on the secondary protocol (Lightning Network), it is up to the protocol to verify that the balances of the individuals within the protocol are legitimate.

For example, if for instance Amy tried to initiate another ‘transaction’ with Bob and claimed that she had her original 5 bitcoins at her disposal, rather than 4, it is up to the protocol or Bob / another 3rd party to ensure that the integrity of the channel’s state is maintained.

Inherent Shortcomings in the ‘Watchtower’ Proposal

In addition, Bob or Amy must remain online if they want to ensure that the channel is not published to the blockchain without their consent.

This has led some to propose a remedy where individuals can relegate the ‘monitoring’ of their blockchain to a 3rd party that will ensure that only the latest channel state is published to the blockchain.

But, what happens if the latest ‘state’ of the channel (again, not recognized by the blockchain but by the Lightning Network), is actually not accurate? Perhaps a vendor or a customer, under the pretense that the mutability of state channels guarantees that refunds will be honored, is counting on a former state of the channel to be published.

If they rely on the ‘watchtower’ system (as some have named it), then they will be in some serious trouble, because there is no way to verify such an agreement.

Also, it’s worth noting that ‘watchtowers’ must be trusted entities. It is proposed that a smart contract could be enacted in order to ensure that the ‘watchtowers’ or this third-party are compelled to ensure that the latest state of the state channel is published to the chain — but again, this would not only undermine the purpose of using a watchtower, it would also involve rigid coding language that would not allow for the reflexiveness that the Lightning Network advertises itself as having.

It’s worth mentioning that these ‘watchtower’ entities will more than likely also mandate a fee for their services. Thus, the entire experience of creating a multi-sig wallet to act as a state channel, using an intermediary, and then publishing the final state of the channel itself will require at least 3 transactions on the main chain. Thus, if the usage of the state channels does become widely used on a protocol that is already near the limit of its maximum throughput dictated by network conditions, then this could essentially stagnate the protocol in a further quagmire of immobility (in terms of transactions), or create an ever-increasing tailspin of fee hiking by those wishing to have their channels’ state published.

Watchtower Proposals by the Community to Alleviate Some Concerns

There are some proposals that users in the community have designed to ensure the anonymity of the watchtowers, but if this anonymity is not preserved in an efficient manner, then watchtowers could easily be corrupted by bribery attempts by the supposed ‘bad acting’ node on the network that would attempt to publish a former ‘state’ of the channel.

Lack of Robust Denial of Service Protections Conventionally Afforded by Blockchain for State Channels

Others have also noted the Lightning Network’s potential susceptibility to being pummeled with Sybil attacks.

Unlike the Bitcoin network or several other protocols (mainly ones that operate via Proof of Work), there is no inherent fee model to prevent nodes from attempting to connect with other individuals on the network.

Without an inherent disincentive to limit one from attempting to connect to as many peers as possible plus a method for restricting the name servers on the protocol (Lightning Network; i.e., one can register 10 different nodes under the name ‘Stellar’), the noted vulnerabilities on the protocol will continue to persist.

A recent research report that looks into the potential vulnerabilities that side channels possess to Sybil attacks can be found below:

We won’t get into dissecting and extrapolating too much from this report in this article for the sake of conciseness — but it is well worth the read.

Looking Back at Stellar Network’s Implementation of Lightning Network

So, now that we’ve received a thorough overview of the Stellar Network protocol, we can now look at everything through the scope of how the Stellar Network is looking to implement the Lightning Network protocol itself.

In order to do so, let’s go ahead and pan back to the Lightning Network technical roadmap written by a Stellar Network developer, Christian:

Lightning on Stellar: Technical Spec and Roadmap

We want Stellar to become the world’s digital payment rail. We’re already the most deployment-ready of the major platforms (see the below chart), but given the scale of the future we see for Stellar, we know we need to keep pushing our technology forward.

Given all of the information ascertained above, the following should make (slightly) more sense (sorry non-techies!; we’ll try to break this down a bit more):

The Use Case for Lightning Network on the Stellar Protocol Still Appears Hazy

If we understand correctly, then it appears that the above theoretical structure for these state channels (Lightning Network) means that Stellar is proposing implementing a system by which the state channel automatically updates itself so that the former channel states (tracked by the LN) cannot be published to the chain.

If this is the case, then it begs the question of why the Stellar Network feels that implementation of the Lightning Network is necessary.

As we all know, the Stellar Network operates via the federated consensus algorithm, so there’s already a very efficient (albeit somewhat centralized) consensus mechanism that allows for vast scalability on the main protocol.

Thus, it begs the question of why the Stellar Network would be allocating resources to forming compatibility with the Lightning Network. From the current information (at the time of writing) that we can gleam from the Lightning Network protocol, it is hard to imagine that there would be a net positive impact on the protocol from the implementation of the Stellar Network.

{Bump_Sequence} ; Stellar’s Plans to Implement the Lightning Network

As we can see later in the same article write up on the Lightning Network road map for the Stellar Network, the implementation of a new development to the protocol called ‘Bump Sequence’ is proposed.

See below for more information about how this proposal is meant to work:

The GitHub Issues and Resolutions for the proposal can be found here:

New operation proposal: Bump Sequence · Issue #53 · stellar/stellar-protocol

Description Bump sequence allows to bump forward the sequence number of the source account of the operation. If the specified bumpTo sequence number is greater than the source account’s sequence number, the account’s sequence number is u…

While the main proposal text is located here:


Developer discussion about possible changes to the protocol. – stellar/stellar-protocol

Below is an excerpt of the code written for the Bump_Sequence:

In analyzing the code as well as the answers posted in locations such as the Stellar stackexchange:

What is “Bump Sequence”?

There is currently a new operation proposal on stellar’s github to add a bump sequence. What does this mean, why is it being implemented, and how does it impact stellar developers? Bump sequence

It appears that the primary motivation behind this code development was to grant the Stellar Network smart contract compatibility, and if that is the case, then that makes sense.

The need for this flexibility in the protocol appears to be reflected in this Medium post here where a user exclaims that the language which Stellar was written in (C++, to our knowledge) is not designed to facilitate the Turing completeness property that a blockchain (like Ethereum) would be required to possess in order to allow users to manifest contracts that contain conditions (i.e., if Amy does X, Bob receives Y).



We have reached out to the Stellar team to gain confirmation that they are indeed using the Lightning Network to create smart contracts on their protocol.

Until then, this is just a speculative theory.

If this is the case, then this is something that could potentially raise the value of Stellar substantially — assuming that they can implement the Lightning Network in an efficient manner.

It would be hard to imagine that the individuals at Stellar have not come to the same conclusion.

We will provide updates as we receive them.



Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.