If you’re looking for a literal definition of what the Lightning Network is, then the following should suffice:
The Lightning Network is just a protocol that enables the passage of bitcoins “off-chain” via the execution of smart contracts in a state channel.
However, if you’re looking for more in-depth information about what the Lightning Network is, how the protocol works, and what it entails, this brief report should serve as a helpful reference point.
What are State Channels?
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:
A complete comparison of the two scaling methods. State Channels and Sidechains are the two terms in Ethereum community that are often used interchangeably, thus causing mass confusion. But today we will get it clear. Go make a cup of coffee first, it’s going to be a long one.
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:
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 reflexivity 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.
Another major issue for the LN = 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:
Above is a breakdown for everyone on how the Lightning Network operates and what it is.
It is not entirely comprehensive, because this is a Telegram channel at the end of the day.
However, this should be enough to give folks a fairly solid understanding of what the LN is, how it functions and what people mean when they use the term ‘off-chain’.
A topology report for the Lightning Network will be conducted and submitted very soon. For now, this should suffice as a very brief overview of how the Lightning Network works!