lightning MEV

enter extraction

This post discusses ‘MEV’ or “miner (maximal?) extractable value”. For an in-depth introduction to MEV (and how it relates to reorgs) check out this great FBC post.

@bertcmiller posed the question to me recently – what is lightning MEV? In thinking about this question, there is a strong requirement to understand first the principles and incentives of MEV, then the structure of lightning as a system. Finally we can see what sort of answers this question “lightning MEV?” gives us.

MEV is an environmental product. That is, it relies on two aspects of transaction environment that have blossomed in the ethereum ecosystem.

First, it relies on access to information. Most commonly, this is information about desired monetary exchanges, or trades. The information must be accessible prior to the monetary exchange is effectuated. In otherwords, information about a desired trade has to be made available before it is recorded in a block.

Access to information about a desired trade before execution provides an opportunity for an intermediary to insert or reorder other monetary exchanges (trades) around the desired one. The addition of these other actions captures some of the desired exchange’s value to the re-orderers account. This intermediary is the one capturing MEV, or the extractable value that’s discoverable by access to information about a desired trade.

In turn, the intermediary relies on sharing the monetary value of this information with the actor effecutating, or recording, the desired monetary exchange. By sharing value that the information access gives to the intermediary, the intermediary improves their own economic position as well as the position of the effectuator of the exchanges. In other words, the intermediary shares the gains that they’ve discovered with the party making the exchanges happen. This is the block maker for blockchain protocols.

Note that sometimes the intermediary identifying the extractable value and the block producer are the same party – in fact it’s the very fact that a block producer is sent desired transactions that gives them access to the actionable information.

MEV Recap

We have identified two steps and three parties as the pre-requisites for MEV.

The two steps are: information about desired trades is accessible before the trade is effectuated or recorded. This information gives rise to the second step, which is the discovery of other, sequential trades which, when paired or batched with the original trade, results in a gain for the actor originating the other trades, otherwise known as the intermediary.

The three actors are: a party making a trade, an intermediary taking other actions around that trade which result in a net-positive balance change for the intermediary, and a party effectuating the trade(s) who has discretion over the order that trades are executed in.

Stated in other words, state updates are available and accessible such that other state updates can be ordered around them. These other orderings create value for the party organizing the state updates.

Where is lightning MEV?

So where does MEV exist on lightning?

First, let’s consider how trades, or monetary exchanges, happen in a lightning channel.

For those of you unfamiliar with lightning channels, the general idea is that two parties commit funds to a shared account. Each party maintains a balance of the funds in the account. Money is moved between various lightning participants by adjusting the balances in accounts on a route between the payor and the recipient.

At the individual channel level, an exchange in lightning works by two parties agreeing to change the balance of funds in their shared account.

An lightning balance update has two steps: first the parties agree to move the balance of the trade into an escrow account. This is a committed proposal to transfer funds. Then, the parties settle the trade, either by moving the escrowed money into the counterparty’s balance (completing the trade) or by moving the escrowed money back into the original party’s balance (canceling the trade).

Channel balances are recorded in unbroadcast transactions (monetary exchanges). As such, the only parties who know the present balance of a lightning channel are the two peers to the shared account, or channel.

Information about pending trades is not available to parties outside of the channel. Let’s see why this is.

MEV and Executing Trades on Lightning

In our discussion of MEV above, we talked about access to information about desired trades. Let’s see how information about trades is propagated in lightning.

Lightning trades, or payments, are typically routed through a series of channels, or shared accounts. The route the payment will take is calculated by the node attempting to make the payment.

The node constructing the payment route knows which channel balances will be updated. It does not know the current channel balance of those channels*, nor does it know the resulting channel balance, after the trade has been made.

*Ignoring probing, for now.

Each node along the path of the payment knows the amount of balance it is being asked to route. It does not know the entirety of the route of the payment. This is because the route path is blinded via an onion packet. Insted, they know which peer of theirs passed the payment in and which peer they are forwarding the payment onto (assuming that they aren’t the final recipient of the trade).

To recap, the information of a desired trade in lightning is only communicated to the actors that are directly responsible for effectuating the trade. These actors are only compensated upon successful execution the desired trade.

In the context of routing payments, there is value to be extracted by the successful completion of trades; there may be an ordering of trades by a single node which enables it to more successfully execute more trades than it would otherwise.

Note that often multiple channels are involved in completing a ‘trade’ on lightning; if any one of the proposed channels along a route is unable to complete the trade (due to a lack of adequate funds, for example), then the trade will fail for all parties on the payment route. It’s impossible to know which other channels a trade’s success depends on, given that lightning routes are blinded. The only party who knows the complete payment route is the party that constructed the route.

MEV and Lightning Onchain

We’ve covered some aspects to which MEV might apply to payments routed on lightning. These are off-chain considerations.

Let’s now consider how MEV may impact on-chain transactions for lightning channels.

Lightning channels only interact with block producers in two contexts: when a channel is being opened or closed.

Channel Opens

Channel opens are typically a slow, multi-block process. As written today, the lightning protocol prescribes a waiting time of a few blocks before commencing trades between two peers. This is so that the on-chain funds are securely committed before any off-chain updates to the balances are negotiated.

A channel open adds an output to the blockchain called the “funding output”. This output is the total of funds in the channel.

Let’s now consider closes. There are two types of channel closures: mutual closes and non-mutual, or unilateral, closes.

Mutual Closes

If both parties agree on the closing balance and are online, they sign a transaction which pays each party its current, respective balance. The closing transaction is then broadcast, or made public.

From a MEV perspective, the information about the desired channel closure is now public. The close transaction depends on no other transaction spending the opening output; the only parties which have the ability to spend the opening output are the channel peers. Once peers have agreed to close a channel, no further payments will be routed over it.

A channel closure is effective once the close transaction has been included in a block.

Non-Mutual Closes

There are also unilateral (non-mutual) closes in lightning. A unilateral close is when the funding output is spent by one of the channel peers.

A unilateral closing transaction locks up the funds of the peer who broadcasts it for a period of time. (On the lightning implementation I work on, the default lock is for 144 blocks). This lock-up period gives the other channel party an opportunity to ‘dispute’ close transaction.

The only thing that is disputable about a close transaction is whether the published balance is the current balance. If a peer publishes a non-current balance to the chain, the other peer may dispute this.

In the current lightning protocol, a dispute about current channel state is resolved by complete loss of funds from the party that published an incorrect, or not presently up to date state.

In other words, publishing an old-balance state to the blockchain gives your peer the opportunity to claim all of the funds from the channel for themselves, minus the fees to process the claim (paid as fees to the miner).

If a peer is successful at publishing an old state, i.e. the old state is not disputed, what is this action worth? Or what is the possible value of publishing an old state?

At most, an old state is worth the difference between their highest historical balance and their present balance. At most, the highest would be 100% of the channel balance, the lowest minimum balance is 1% (due to reserve requirements) of the channel balance.

The highest theoretical gain from an old state broadcast is 99% of the channel balance.

The loss risk of publishing an old channel balance is the total of your current balance, which has a minimum of 1%.

Note that resolving a dispute may be expensive for your channel peer; depending on the magnitude discrepancy between the proposed and actual channel balance it maybe more economical for them to allow the old channel state to stand as the closing balance of record.

Ok, so the only actor that can extract value from a channel close is your channel partner. Their attempt at doing this may be costly to them, depending on their present channel balance and your ability to successfully dispute their close action.

Large channels should be more susceptible to griefing and cheat attempts, as there’s more value at stake.

Finally, the only ordering opportunity granted by a unilateral close is all or none. The transactions for a channel close are already strongly ordered – there is no insertion or re-ordering that isn’t a wholesale replacement of the channel peer’s transaction.

Hm there is a window of time during which a unilateral transaction has been broadcast but not yet mined in which the peer may not know that the channel is in the process of being closed during which more channel state updates could be negotiated to improve the projected gain for the cheating peer.

Closes and Miner Access

Direct access to a miner and a guarantee of effectuation of a transaction before the transaction of your peer is valuable only insofar as you’re able to delay or block your peer from issuing a “correcting” transaction, which ameliorates your attempted cheat (in this case, lightning MEV is a capture of some or all of the balance of your peer and as such is zero-sum).

MEV on lightning is only “capturable” by your channel peer (and a colluding miner) and is limited to a fixed amount, at max the “channel diff”.

(Note that I’ve failed to discuss a class of griefing attacks that will pay out your peer’s balance to a miner as fees – the griefing party gains nothing except what they negotiate to clawback from the miner.)

To recap, onchain lightning MEV is extractable only by one of the two parties in the channel, and constitutes a “cheat” attempt. There are a few cases where unilateral closes can result in large payments to the miner (and none to the peer effectuating the close). The public information that is published is only ever actionable by the channel peer (or a delegates on their behalf).

---

Some other lightning thoughts. Open market MEV seems to rely on bots, which can react to information faster than than others. It’s an interesting thought exercise to consider what actions might be possible on lightning given fast execution.

The two “MEV” opportunities on lightning that I’ve identified so far are onchain (griefing/cheating your channel peer) and payment routing (successfully routing payments).

If you could know of a payment attempt, before the payment was attempted (and the funds were committed to escrow), what actions would you want to take, as a value/return maximizing node?

• You’d want to have a channel balance available to be used by that payment

• You’d want the router to select your balance for use. Typically this is chosen as the cheapest route (considering the escrow lock that you’ve placed on the funds, as well as the amount you’ve advertised as being charged for use of those funds)

The ideal case would for there not to be any other routes available for completing the payment. i.e. you’d want the payer to have to use your available funds; and that your rates for use of the available funds is set high to reflect this limited availability.

To make this work, you’d need to know:

• The other candidate routes from the destination to source.

• The balance of those channels (can they route the payment, or am I a “must use” hop for the payment?)

• The cost of using any competing route (so you know your relative position in a cost-weighted route finding algorithm)

By design this is hard to determine, as the route is blinded using onion packets and channel balances are not publicly available. You’d have to do a lot of active probing of the network to determine this information, but it’s possible to do. Historically, it’s been difficult to reconfigure your channels and balances in real time, as it takes a few blocks for a channel to become operable, which makes it difficult to take advantage of information of desired payments even when you receive them.

It’s possible the zero-conf channel proposal (sending payments over channels before the funding tx is mined) and splicing (dynamic reconfiguring of channel balances via an on-chain tx) may make this more feasible in the future.