Slashing

The approach we propose for this paper is to have the slashing condition verified and executed on the Ethereum blockchain. This introduces the following constraints into the system:

• Active participants in the protocol such as node operators must stake on the Ethereum blockchain. This allows the fraud-proof validation logic to slash offending nodes without dependence on an external system. Note that BTC liquidity providers will not need to interact with the Ethereum Blockchain for deposits and claiming yield unless the majority is censoring their requests.

• The Ethereum contract must have a source of truth for the transactions performed on the Bitcoin blockchain in a trust-minimised fashion. We assume the existence of a service posting Bitcoin block headers to an on-chain light-client contract on Ethereum and design the fraud-proof mechanism such that it includes the Merkle proof for offending transactions verifiable against corresponding block headers.

• The fraud proofs must be submitted to the Ethereum blockchain by the prover.

Proof of Solvency

Broadly speaking, the network is responsible for the following operations:

• Deployment of funds from the Free Liquidity pool (henceforth referred to as FL pool) into a lightning channel.

• Settling and Closing an existing Lightning Channel on the Bitcoin chain as determined by the global algorithm. The network’s share of the closed Lightning Channel must return to the FL pool.

• Processing deposits and withdrawals of User funds from the FL pool.

As long as an honest majority exists and the protocol is being followed, the lightning network routing protocol will guarantee the solvency of the network. Whenever a payment of amount A is routed through a network-owned lightning channel, it receives an amount A + f from an incoming channel and forwards A through an outbound channel, generating f as the revenue. It therefore follows that if the network at any point in time becomes insolvent, the majority has acted dishonestly and must be slashed.

In the following sections, we describe an interactive protocol for a single honest party to prove such a protocol violation to the Ethereum blockchain and have a dishonest majority be slashed.

Observing the Current State of the Lightning Channels

For a given lightning channel in which the protocol is one of the participants, its state at any point in time can be observed by looking at its latest Lightning Channel Commitment Transaction, a Transaction as defined by the Lightning Network Protocol describing the fund distribution of each party in the channel at that point of time and executable instructions for realizing the mentioned distribution by settling the channel on-chain.

Let the number of Lightning Channels in which a network is a participant at time t be N(t). For the ith channel, let A_N(i,t) and A_C(i,t) represent the balances owned by the network and the counterparty respectively. Then, LC(i,t), the latest signed Lightning Channel Commitment Transaction for the $i$the channel owned by the network at the time $t$ be defined as:

$$LC_i^t=(A_N(i,t),A_C(i,t),Sig_N(i,t),Sig_C(i,t))$$

where Sig_k represent the signature by party k.

A snapshot S_t of all lightning network channels owned by the network at a given time can be defined as:

S_t=\{LC_i^t | i\lt N(t)\} $$

The total share of the liquidity owned by the protocol across all channels the network is a counterparty in can be defined as:

$$R_t=\sum_{LC(i,t)\in S_t} A_N(i,t)$$

The solvency criterion for the protocol can then be defined as

$$\sum_{d\in D_t}^{} d \leq R_t$$

where D_t is the set of all user deposits that have not been withdrawn at the time t.

Preventing a dishonest majority from censoring a malicious commitment

If we assume an honest majority, the rules of the consensus will prevent the network from being dishonest since all operations including opening and settling lightning channels must go through network consensus.

However, this does not prevent the network itself from colluding and stealing the user’s deposits by using the user’s deposits to create a lightning channel and send the funds to an arbitrary address. If this channel commitment were to be reported to the protocol and be recorded in the ledger, the protocol would become provably insolvent and be liable to be slashed. Instead, it would be in the interest of the colluding majority to censor this commitment and prevent it from being included in the internal ledger.

To prevent this situation, we empower a single honest node to prove the non-inclusion of a commitment transaction on Ethereum and have the colluding majority slashed in the process

This is achieved as follows:

• The network is required to publish a state commitment (”state root”) to the state of the internal ledger on the Ethereum blockchain, periodically. This acts as the “source of truth” to the ledger’s state on Ethereum and can be used to build and verify proof that asserts the existence or absence of certain keys in it. A liveness failure for posting the state root is also a slashable offence.

• Given that all actions in the network must go through consensus, it can be reasonably assumed that a majority of the honest nodes must have at some point access to every message signed by the network.

• If LC(i, ti) is signed by the network but not included in the ledger, a single honest node can submit proof to the Ethereum blockchain asserting the non-inclusion of LC(i, ti) in all prior state-commitments published to Ethereum after t ≥ ti+delay. Such a proof can be constructed as a Zero Knowledge Proof to reduce the cost of verification, and for shielding the commitment for reasons described in a later section.

With this construction, it becomes possible for a single honest party to provably slash a dishonest majority, a key condition for quadratic scaling of safely manageable TVL with the total protocol stake.

The Need for Shielding Lightning Commitments

A Lightning Channel commitment is a signed Bitcoin Transaction with the current state of the channel, that can be broadcast to settle the channel on-chain and claim the funds. Lightning channels are not settled frequently transactions are typically just a message exchange between the transacting parties. Due to this, there is a possibility of a malicious counterparty settling the channel with an older commitment.

The Lightning Channel protocol has a mechanism to deal with this scenario. I’ll not go into detail about the actual mechanism, but what is relevant to the protocol is that if either party attempts to settle the balances with a penultimate or older commitment, the other party can claim all the funds in the channel including the offending party’s initial balance.

This is relevant to the network slashing protocol because submitting a commitment to the Ethereum blockchain broadcasts it to the whole world, giving the ability to a malicious un-staked third party to broadcast the commitment to the Bitcoin blockchain. If this is not the latest commitment of the channel, the counterparty will initiate the recovery protocol and claim all the funds in the channel, causing the protocol to lose capital and become insolvent.

A solution to this problem is to instead wrap the commitment in a zero-knowledge proof so that the prover can prove to Ethereum that it has the knowledge of a commitment which was signed by a majority of the network but was not included in the ledger whose state commitments were posted to Ethereum without revealing the actual lightning commitment.

Guaranteed Withdrawals

Another challenge is to ensure that the network does not censor valid withdrawal requests from liquidity providers. When a user raises a withdrawal request, if their withdrawal is being censored they must submit the request directly to the Ethereum Blockchain, along with proof of the deposit being performed on the Bitcoin chain. The contract on Ethereum verifies the deposit against the block headers received from the Bitcoin block header relay to the on-chain BTC Light-Client Contract.

Once the withdrawal request has been verified on Ethereum, the Network must process the withdrawal and produce proof of the withdrawal being processed within some pre-defined time Twd of submitting the withdrawal request, otherwise, the network is liable to be slashed. This proof is again verified against the Bitcoin block headers received from the relay.