EigenLayer introduces the possibility of re-using ethereum consensus, and IMO the most interesting usecase for that would be building a decentralized two-way and security-optimal bridge between Bitcoin and Ethereum.
All bridges rely on the security of the two chains they connect and the security of the custodian^[1] used for bridging, since if the security of any of those 3 were to fail, it would be possible to drain the bridge (eg: if its possible to double-spend on any of the two chains an attacker can redeem the same coin multiple times).
However, if a significant amount of the total ETH staked were to be restaked securing this bridge, the custodian would be piggybacking on ethereum security, so those two become the same and thus you'd remove the custodian from your list of dependencies and you're left with only having to depend on the security of the two chains, which is the theoretical ceiling of security. In other words, you'd achieve the best possible security.
But not just that, you'd also get:
- A scalable bridge that can bridge any amount
- A decentralized bridge
- A long term solution to Bitcoin's security budget that doesn't rely on sustained shitcoining activity
- Real Bitcoin L2s
Assuming the same size as WBTC, it'd be very hard to build a bridge with similar properties in any other way besides enshrining it into ETH consensus. This is because the lack of advanced smart contracts on BTC make it impossible to verify ETH state from BTC consensus, and if you try to back a custodian with cryptoeconomics you'd need an amount staked that's higher than the mcap of WBTC, and right now there's very few assets in crypto that fit that bill.
BTC will be held in a FROST multisig of AVS restakers, so when a user wants to bridge BTC in they'll send BTC to the multisig and then prove that they've sent it through a Bitcoin light client in Ethereum smart contracts.
Then when they want to withdraw, users will burn their erc20 BTC and request a redeem, if the restaker multisig doesn't honor this redeem then ETH restakers will be slashed.
There's two ways to implement slashing checks:
- The easiest one is to have an optimistic verification game where a bounty is posted which can be fulfilled by proving that a BTC tx was sent to the user before a deadline. For this you only need to implement a solidity BTC light client, which has already been implemented. The problem with this is that you need to slash all restakers, regardless of whether they caused issues or not.
- A more complex solution would be to run a process on-chain which would allow contracts to pinpoint onchain who is causing the signing process to fail, and then you can punish only the restakers that are causing issues. This is better but increases complexity.
Then you'd periodically rotate all the money in the multisig to a new address in order to include new restakers and remove restakers that dropped. This rotation will happen at fixed intervals as, due to the unstaking queue, we can be sure that there will be no sharp drops.
If we used this protocol as is, an issue would be maintaining the BTC light node in ETH contracts, as that bears a significant cost. However, it's possible to optimize this away by either using ZKPs for the light node proofs or using optimistic games with large bounties. This will also heavily reduce gas costs of bridging operations.
Finally, a final optimization is to use a taproot tree for custodian address that has the following spend conditions (period is the time between address rotations):
- signed by 99% of restakers
- timelock for period+1 day && signed by 98% restakers
- timelock for period+2 days && signed by 97% restakers
- ...
- timelock for period+30 days && signed by 69% restakers
This allows us to minimize issues that could be caused by a subset of restakers withholding redeems while also keeping the threshold for stealing as high as possible.
Let's assume we achieve resounding success and our bridge grows to the same size of WBTC and takes it's throne. If the bridge has the same revenue as WBTC (which earns by charging a fee on bridge volume) that would mean 1.58M earned over the last year^[2].
However for the bridge to be secure we'd need at least 10.3bn restaked^[3], this means that if we pay all fees to restakers, they'd be earning an APR of 0.015%.
That APR is extremely tiny, especially considering that it requires putting all their value at risk, so it's unclear whether there would be enough restaking demand for it. You could structure the protocol so that if restakers do everything right they can never be slashed, but there would still be risks for restakers due to possibility of key compromise, dropping offline...
Currently all Bitcoin L2s that are either live or being worked on aren't real L2s, instead their bridges always rely on some parties which don't inherit Bitcoin's security.
The idea proposed here could be combined with an L2 on ethereum in order to achieve a real Bitcoin L2 that only adds a dependency on the security of Ethereum, which is really high. Ethereum would be only used for fraud proofs settlement and the bridge could be modified to allow deposits directly from Bitcoin to the L2.
A tempting idea that I've seen floated a few times is to use Bitcoin as the DA layer and post calldata there. However doing so would lead to high transaction costs easily surpassing >5$/tx for a uniswap tx.
Here's a simulation of historical DA costs of a swap on uniswap, assuming:
- L2 would achieve the same compression rate as Optimism
- Sequencer would fit all the data in segwit space (otherwise need to pay a higher rate)
- Uniswap trade is very simple, with one hop and no permits used
- Blockspace demand would stay the same
- How do you handle it if restakers start dropping and an AVS that used to be validated by >66% of all ETH staked ends up being validated by a fraction of that, putting the bridged funds at risk of being stolen?
[1] It's possible to not have a custodian and instead have some other mechanism, but for ethereum<>bitcoin you'll always need a custodian unless there are significant changes to bitcoin or ethereum.
[2] https://defillama.com/fees/wbtc
[3] For the bridge to be secure, we either need more value restaked than what the custodian holds or value restaked to be a significant % of all value staked on Ethereum. In the case discussed the former would be the first we'd achieve so we can reduce security to that.