Thread by @RyanTheGentry

So now that we all agree that globally available blockspace is not scalable for actual computation, but is best used for verification of off-chain computation instead, here are some thoughts on Ethereum's approach to scaling vs. Bitcoin's.

~👇~Thread~👇~

First, definitions:
1) broadcast txs: all-to-all gossip comms that succumbs to the scalability trilemma (all L1s)
2) unicast txs: 1-to-1 direct comms that occurs between two peers only (LN)
3) multicast txs: 1-to-many comms between a subset of peers (rollups, sidechains)

Both Bitcoin and Ethereum's L1 use broadcast txs. But because of (IMO) Bitcoin's use of UTXOs vs. Ethereum's use of accounts, Bitcoin has prioritized unicast txs via LN first, whereas Ethereum's initial unicast txs projects have been discarded in favor of multicast txs.

Ethereum first. Rollups are cool! Multicast structures like this are obviously much more capitally efficient than unicast ones. If properly designed, they're also much more user-friendly since they're non-interactive: users don't need to run a node or manage channels or anything.

In order to earn that trust, validators post tx data + execution proofs on-chain. This is because when Alice deposits into a rollup, she is effectively giving up control of her L1 funds to the contract account governing the rollup validators.

If those validators turn malicious/disappear, Alice can only get her funds back from the contract account by proving to miners that her keys have a claim on funds still owned by that contract account. And that requires replaying the rollup history from genesis using on-chain data

So: data availability + fraud proofs are requirements for Ethereum multicast txs to be safe, because the contract account actually has full custody of funds. This has benefits, but puts immense pressure on two single points of failure: smart contract code, and the dapp interface.

Unicast txs make their way back into Ethereum's scaling story as a way to connect these multicast rollup zones. At scale rollup-to-rollup transfers that need to route on-chain will be slow & expensive, unless Bob the OVM validator has a channel with Carol the zk-sync validator!

IMO, all global blockchains will need to pair their base layer broadcast txs with such a mix of unicast and multicast txs. Ethereum has pushed the complexity of their off-chain systems onto validators in order to make things user-friendly... hopefully their SPOF don't fail!

(intermission question: @jadler0 @ercwl @gakonst @paddypisa are any rollups operating with multiple validators yet? Or is it still just a single node maintaining the off-chain db + creating broadcast txs + proofs?)

In general, Bitcoin protocol devs value self-custody and self-validation much more than Ethereum devs do. IMVHO, it's for that reason that multicast txs (i.e. sidechains) have not seen much traction and have been deprioritized in favor of unicast txs (i.e. Lightning).

Just like with rollups, when Alice the Bitcoin hodler deposits her UXTO into a multicast txs environment like RSK or Liquid, she gives up custody of her coins entirely. The difference is, she really needs to trust these off-chain validators not to be malicious or disappear!

This is because Bitcoin Script cannot validate fraud proofs like the EVM can, and because Bitcoin has made it expensive to paste data on-chain since that cost is borne by all full node runners. So Alice can't prove to the miners that she still owns coins off-chain, sad!

Instead, Bitcoiners have focused on Lightning, where users remain in control of their funds at all times at the cost of running their own node and managing a set of unicast comms channels. This makes the user themselves the single point of failure, trustlessness!

Another way this tradeoff can be framed is by prioritizing resiliency and decentralization over capital efficiency and user friendliness, which is Bitcoin vs. crypto in a nutshell.

Unlike rollups, Lightning is a very interactive protocol, which requires peers to be online.

I think this is a very good thing, because the sexy new multisig features in Taproot are incredibly interactive as well! They only really work if all the nodes involved have secure, private and persistent communication channels... which sounds like LN!
bitcoin.stackexchange.com/questions/9153…

Remember what I said about multicast txs earlier re: data availability and fraud proofs? Those requirements stem from giving up custody of your funds entirely, and needing to prove to miners that they're still your funds. But what if you could join a sidechain without that?

What if you could maintain 50% control of your UTXO, and share the other 50% with an off-chain validator (or a threshold signature of off-chain validators)? As long as you had unicast channels for interactivity, there would be no need for on-chain data availability + fraud proofs

How interesting would that be? All of a sudden, Bitcoin could have broadcast, unicast, and multicast txs without a new Proof of Stake checkpoint chain, without data availability shards, without adding crypto assumptions, and without compromising on values!

Soon (tm) ⚡️⚡️⚡️

I believe that OP_CTV is required to make these type of multicast txs (basically multiple owners sharing a single UTXO) non-interactive, right @JeremyRubin?

@mhluongo @zmanian @_prestwich @Ethan_Heilman @mappum please lmk where I'm being stupid.