I read up on some of the upcoming ETH scalability solutions on how they work, namely rollups. As a former LN contributor I may give some insights for all you hardcore Bitcoin nerds. :)

Obviously, everything is very different on the Ethereum chain. Transaction costs are computed around complexity and not just size. In Bitcoin the rules around valid and standard transactions are pretty strict, so big transactions usually involve a lot of complexity.

ETH transactions on the other hand operate against existing contracts and even a tiny input can trigger very complex computations. As such, raw byte size is usually not considered at all. *This* is what ETH L2 solutions use to piggy back on in the near future.

You see, as of writing, you could in theory push ~750kB of raw data into an ETH block. In practise they are ~30kB big. That is because the network has a different model of complexity. Raw data that is passed around without any computation isn't very complex after all.

If you take away one thing from this thread - it's this

ETH L2 rollup solutions use the *remaining* 700kB to squeeze in extra transactions that are *verified off chain*, but are still *passed around* on chain. Imagine huge data blobs in Bitcoin OP_RETURN outputs.

There are different variants wrt how to handle correctness of transactions. Currently the project with most traction uses bonds and incentives to keep producers in line. Since *all* data is on chain, everyone can verify the resulting state root. https://cryptobriefing.com/optimistic-rollups-finally-make-ethereum-synthetix-offers-rewards-participate/

So how would this actually work with a consumer wallet?

Looks not too bad, as it turns out. Inside that nested state you have a parallel universe in which you can do anything you want.

You can send ETH/tokens to a deposit contract to move into this parallel universe.

You don't have the toxic waste issue of LN, nor do you need to be super careful around backups. Everyone watching the contract is your watchkeeper.

But there are no privacy gains here, nor fundamental scalability gains. It's similar to SegWit as a throughput increase.

You can withdraw by requesting it through some special transaction off-chain, and after some delay, the contract will spit out those tokens again. The main contract serves as a pool for all assets within the parallel universe.

Users can be onboarded into this system by simply sending them funds within that universe. This is a key difference to Lightning, where new users still need to interact with the base layer unfortunately.

BUT REMEMBER - the transaction to onboard a user *does* require a transaction *on chain*. It isn't fully validated on chain, so it's cheaper, but every transaction incurs a cost, since the state transition *is* recorded on chain!

So what is my final take?

Sounds like it could improve the status quo of congestion on ETH quite a bit. As demonstrated by the great folks working on LN, the next very important step is standardisation. The RFCs were a corner stone of making progress. https://github.com/lightningnetwork/lightning-rfc

At the end of the day I can't shake the feeling that this is not the kind of bleeding edge technology you came here to read about.
> Just push all the data on chain in some unrelated field

But you have to work around existing constraints, an issue Bitcoiners should know best...