Table of Contents
SPEECH TITLE: Could lightning burn down the DeFi dark forest?
SPEAKER: Jed Grant
CONFERENCE: Mallorca Blockchain days 2022
The Ethereum Dark Forest
Could multichain lightning burn down the DeFi dark forest? Ethereum is a dark forest, and if you’ve heard of Maximum Extractable Value (MEV), this is what’s happening in Ethereum: frontrunning, sandwiches.
So, frontrunning is when you put a transaction in the mempool and the bots recognize it, and they’ll put another transaction in with a higher gas cost so they can take your profit. Sandwiching is when they’ll put transactions before and after your transaction so they can orb that, and there are sandwiches of sandwiches and other things happening, and it’s all because of the crappy design of Ethereum. You have this because of the public mempool where all your data is public and all the contracts are public, and anybody can copy anything
DeFi is not really Decentralized
…And it’s not really DeFi. We call it DeFi, but it’s centralized. There are governance structures and people working on this, and everything is actually centralized, which leads to bad actors and rug pull magic carpet coin, you know, that kind of thing. Even proof of stake is going to make this worse. I just don’t see a positive future for DeFi there. But there probably is a better way, and we can do that probably with Lightning.
Simple Anatomy of a Lightning Node
If you think about Lightning, it truly is decentralized. We have this infrastructure here where we can do some true decentralized financial things. If you look at the basic architecture of a Lightning node, you’ve got a full Bitcoin node running there, and then you’ve got the Lightning node running all the Lightning protocol, and you can extend that. If you just imagine that you would take that out and extend it to other blockchains.
Multichain lightning
There’s no reason a Lightning node can’t run Lightning on Ethereum or whatever chain you want to run, and you have the full service, and each one has its own peer-to-peer network for communicating the protocol of the chain or of Lightning, so we can make use of all that to build some interesting DeFi architecture, and actually, it’s being done.
If you look at all of these chains, LiteCoin, Zcash, Raiden is on Ethereum, they all are building Lightning capability, but nobody’s put it all in one node. So you basically can run a Lightning node that’s a Litecoin node, but then it won’t talk Bitcoin; it’ll only do Litecoin channels. And the trick is to have one that can do a Litecoin channel and a Bitcoin channel, and then you have an FX capability, so you can then change by receiving Litecoin on one, and you could send out Bitcoin on the other. So then you need a couple of things in this Lightning daemon. You would need rate setting where you can configure the FX rates or have them configured for you. You would need a discovery mechanism so you can figure out which nodes are offering to FX which coins and at which rates so you could figure out how to route through that, and you would need an FX fee mechanism in addition to the routing fees. So this is what your node becomes [displaying an exchange photo]; this is your Lightning node. Now it’s not just taking money in and sending money out; it’s a little exchange shop.
FX Payments – cross chain value movement
And if you look at how that works, let’s say Alice wants to pay Bob. Bob wants ETH; Alice is a Bitcoiner. She can send this through Charlie, who runs a Bitcoin Raiden node, and he converts the Bitcoin to ETH, which then gets routed to Dan, who has an inbound channel to Bob, so he can get his ETH. So it’s your basic FX, but done in a decentralized transaction.
FX Routing – a real DEX
You can do some other cool things. If Alice just wants to get ETH for her bitcoin, she can just route that through a transaction that loops back to herself. So she can send out bitcoin, goes to Bob, who turns it to ETH, and then Charlie has inbound liquidity to her and ETH underneath channel so she can get that back as ETH if she wants.
FX Mixing – using a privacy hop to hide transactions
You can also, with Zcash, route it through a privacy hop, so you could actually send, and it becomes a mixer. You can send your coins out, route them through a Zcash hop, and then get them back, and you’ve broken that connection because it’s gone through Zcash. Zcash uses Bolt, which is an offline transaction. They’re blinded offline transactions in their Lightning implementation. So there’s lots of things that you can do in this Lightning configuration that people do in DeFi, but this is truly decentralized.
LN – 3 of 3 MultiSig Channels
Then there are other things happening; there’s three of three MultiSig channels, and this is like building on the idea of dual funded channels. But this was done for IoT, so some researchers (the PDF is a reference down bottom there – it’s an academic paper if you want to read it) have figured out a three of three MultiSig so that an IoT device that’s not capable of running lightning can actually have a channel with two nodes that manage it and a three of three signatures so it can spend its money making micro payments using Lightning. But, you could also take this a step further and say, “Okay, I want to just provide liquidity to Lightning, but I don’t want to run a node.” Three of three allows me to do that. I can be the liquidity provider and the two nodes can manage the channel, and this will split the burden of running a node and providing liquidity into two different jobs. And with what I just described on bringing in other chains, Lightning can then suck up liquidity from all the shitcoins and take all that liquidity and put it in the Lightning Network.
Liquidity Provisioning, i.e. staking
So, if you look at that, it’s pretty straightforward. Say Alice and Bob have channels, Charlie wants to provide liquidity so he provides a channel between Alice and Bob where he funds the channel. The transactions then go through Alice and Bob normally and they can handle that, but using Charlie’s money and he has a signature on it, so they can’t take his money. When the channel’s closed, Charlie gets his funds back. Pretty straightforward.
Opportunistic Provisioning – network optimization
If you look at how this works, there are other things you can do. Suppose that there’s a transaction that frequently goes through Bob to get to Charlie (Alice to Bob to Charlie), and you identify that as a liquidity provider. You can then drop a channel directly and take advantage of that because you’re optimizing the network and providing liquidity where it’s needed. So, you drop a channel between Alice and Charlie directly, and those transactions that you were observing would be routed directly to Charlie. Okay, Dan can do that.
Joint Provisioning, i.e. collective investment
And then you have joint provisioning, so this is like a dual funded channel, but you could actually group a number of liquidity providers together, fund the channel, and you can get some really big channels that way if you did that. So, there are all kinds of things that we could do here that would make DeFi really interesting on Lightning.
Joint Provisioning, Credit Risk Management
If you look at it, when you drill down, there’s a lot of game theory that’s going to have to be done here, and it’s quite complicated. When you start looking at the details, obviously, as everything is, it’s interesting and simple at first, but the details make it complicated. If you look at this case where Charlie is providing 20 million sats, for example, to a channel, and then Alice and Bob are transacting with that channel, you need to be aware. And, doing this requires that the node operators become credit risk managers, so they have to understand what their counterparty node on the other side of that channel has in terms of on-chain and on-lightning balances so that they can manage the risk when that channel is closed and the transactions in it. And this all has to be done in scripts.
So, if they transact for a while and after that you have 13 million and 7 million instead of 10 and 10 because money has gone out and in on the ends, you can see that the balances are going to change. And in this case, when you close this channel, Bob actually owes Alice if we take the presumption that Charlie gets his funds back because he provided the liquidity. You have a situation where Bob has to pay Alice 3 million sats to make up for the difference in the funds that transacted there. Because the balance on-chain is available that can be done in the channel closing transaction and can be settled out normally. It could also be settled with a circular rebalance. So, if you didn’t want to close a channel, you could just rebalance the channel and make sure you’re keeping the liquidity in the right place.
If you have a multi-situation, it actually is better. It seems more complicated and intuitively might be worse. But if you have a multiple provider situation where actually the nodes participate and the liquidity provider participates in putting liquidity in the channel, it reduces the credit risk. So, if you have this situation where, for example, you have 10 million put in by Charlie and company and you have 5 million each from Alice and Bob, then you transact.
In this case, because that two million is needed to move over, you can settle that within the channel liquidity already. So, you don’t need to take it from an on-chain balance when you close the channel. The credit can be managed within the funds that are provided by the node operators. Basically, in this case, you’re using the liquidity provider to lever up. It’s just leveraged.
Enabling DeFi on LN
Building on this, if you look at it, there’s obviously a lot of new features that we would need to build on Taproot, DLCs in order to do DeFi type arrangements. And everything is private though. When you look at how Bitcoin is architected and how it would be built, you’re not doing on-chain transactions like Ethereum with public smart contracts. You’re doing this with MAST and with DLC, and you’re able to do complex DeFi things without having to show the world what you’re doing. You’re not getting frontrun because you’re not dealing with a mempool, and you can also have private channels and private services that would be invisible to the general public. So, this is where things like the mixing and whatnot can be very, very interesting. And with Schnorr signatures, you end up in a situation where opening and closing channels look like normal Bitcoin transfers. So, people don’t see, “Wow, this is a complex DeFi thing that’s being opened up and they’re going to mix and exchange, etc.” It’s just a normal transaction. That’s all you see. So, it’s pretty interesting, but there is a lot of game theory that’s going to have to go in because there are edge cases where abuse can happen. And the credit risk management, for example, becomes like an extension of the watchtower type functionality that you use in Lightning. So you’d be watching the other node, looking at what’s the balance in the channel, what’s the balance on-chain, what’s available when it closes, and if those parameters start to get out of whack, you either rebalance or close the channel right away.
A LN based AMM
If you want to do an algorithmic market maker, for example, you could do that with this setup with two nodes here. One is the BTC buyer and one is the ETH buyer, the BTC buyer you load with ETH on his end of the channel on a Raiden channel, and the ETH buyer you load with BTC on his end of the channel, and then you make the outbound liquidity channels appropriate to do that, and then these two nodes would have to communicate with each other, so they share information obviously. Here, your market-making algorithm needs to be communicated between the two nodes so that each one sees what the other one’s doing, but they can observe those channels and see what the balance is, and then change the FX rate based on the balance, which is what an AMM does. So you don’t need Uniswap, you can just do it here with two lightning nodes.
Considerations
The cons are you need to share information through the peer-to-peer protocol, so there is some information exchanged, and that protocol is latent. It’s not as fast as one would like. You need the routing calculations to find the best route. If I wanted to send funds through several hops, I want to find the best FX rate if I’m going to FX those funds in that, so that’s tricky to do. The open and close needs new scripts, so a lot of new scripts need to be developed and tested and been gamed there. But the pros are the bots on this network that would observe that … people will build bots, it’s inevitable, but they can bring in liquidity and keep the spreads tight. So you can actually get an interesting decentralized FX market, truly decentralized. That’s really important, and private transactions with no mempool.
Conclusions
This is a presentation of some ideas that I’ve been toying with for a bit of time now and thinking through. It’s not built yet, and I’m actually not building it, but I want someone to build it because I want to use it.
Watch the original content: Click here
Also read: Bitcoin and AI: A match made is cyberspace
Disclaimer: Transcripts provided on bitlyrics.co represents solely the opinion of the speaker and is not by any means financial/legal advice or an opinion of the website. The content has been transcribed with maximum accuracy. Repetitions and fill words have been amended in order to enhance the reading experience. The full text may not be confirmed by the speaker. Please, refer back to the above-provided source of content for more certainty. If you are a speaker and wish to confirm/amend your speech please contact us.
