Attacking an Ethereum L2 with Unbridled Optimism

This turned out to be longer than I intended. Apologies.

I view Ethereum as a value network, connecting disparate sets of transactional use cases around a set of core services (like Address, asset records, and transaction functions)

To believe that blockchain makes sense for assets which do not require absolute integrity, you'd need to first accept that there are valuable use cases which having an asset management & transaction layer (L1) serves.

If we establish that there are valuable use cases that attract asset management to L1, at a certain point network effects begin to take hold, and the system becomes "top of wallet".

There are parallels in how you manage traditional finances today - Even if you have multiple bank accounts and digital wallets for USD (e.g., a Chase account, Cash App, Venmo, etc.) you're likely to mentally consider one of those your "primary" account. The important one. The main difference in the value network of Ethereum is that the primary account can aggregate the assets that are managed/transacted through L2 solutions. The L2 solutions leverage the core "identity/asset mgmt layer" of L1, but serve use cases that don't justify the cost of development/operation/transaction on the main layer.

To connect this analogy to the original question, let's imagine that your Bank Account offered direct integration with each of the other accounts you manage - Capturing every asset you held, including the 124 gold you still have on your World of Warcraft account from a decade ago. If the 124 gold were to somehow disappear due to a bug/hack/other integrity issue, your bank account would reflect that. But the important stuff would be there.

TL;DR - If commerce generally moves to blockchain systems at significant scale, there will be an acceptable level of failure on L2 systems to support the convenience of aggregating up asset mgmt alongside the important stuff.

The Nov 11 upgrade radically changed how Optimism's backend worked. Transactions after 11/11 are executed in a VM that's much closer to the EVM than before. It's still possible to run nodes that access these pre-11/11 transactions, but because of the way Etherscan and geth are designed, it's unfortunately not as simple as just serving the same data again.

Etherscan CSV exports are the best solution we had that didn't require significant modifications to Etherscan's backend. You should be able to use the CSV feature to export all of your relevant pre-11/11 transaction data (transactions and ERC20/ERC721 transfers).

While we did our best to communicate this months in advance on our twitter, blog, discord, and documentation, it's hard to reach everyone and we totally agree that this is not ideal. At the time, we had to prioritize progress, but we've since made a firm commitment to not to update the chain in this way going forward. So, this shouldn't be something people will need to worry about in the future.

This is a fantastic question for pretty much every scaling solution out there — as the initial engineering work on rollups finish, many of the fundamental scaling problems re-emerge on L2. Right now, our system's hardware requirements are very similar to L1 mainnet, but the state is growing.

There are two solutions in the future: statelessness, and block-producer/verifier asymmetry. Statelessness (and related concepts like state expiry) has been under active research in Ethereum for years, and we've recently started our own contributions with a new stateless Ethereum client [1]

The other part of the solution is to leverage asymmetries between the hardware requirements of block producers and verifiers. TLDR: this lets you have high HW requirements for sequencers, but still secure the network with laptops. Vitalik recently wrote about this; you can read that here [2]

[1] https://twitter.com/ben_chain/status/1488275978983915523?s=2... [2] https://vitalik.ca/general/2021/12/06/endgame.html

>1) Creating limited editions of generative art.

I personally think that it's not really an interesting feature. Creating scarcity out of something that ought not to be scarce is just a way to infiltrate capitalism in every aspect of our lives. Hacker culture historically went completely against that (phreaking, breaking DRM etc...) but I concede that it's more of a philosophical/political argument than a technical one. I still find it utterly depressing.

I would also argue that there's usually a significant difference between ownership of a token on the blockchain and what the local IP laws says. IP law is messy and sometimes subjective, putting things on a blockchain can make things messier rather than simpler.

>2) "Forever" art like on-chain pixel and ASCII art.

So that one is interesting, but I would argue that it's only true if you consider that the blockchain is "forever". In order for that to be true it means that you have to believe that your blockchain of choice will be considered significant enough by a number of people across... well eternity really. This could be true for the "big" ones like Bitcoin and Ethereum, although I'd say the scene is way too young to be sure of that. It's as good a bet as any I suppose.

But here's the thing. We already have "forever" digital "art": the source code of the Linux kernel. There are countless copies of it across the globe, and it'll remain archived for the foreseeable future.

My point here is that if something is significant enough it won't be difficult to convince a bunch of people across time and space to archive it. People do that for old videogames, music albums, usenet posts etc... And unlike the blockchain you can actually curate it, you don't have to archive the neighbor's sandwich picture collection. I'd argue that this curation power is a feature, and the fact that the blockchain just stores everything forever is a bug. It actually means that the bigger the blockchain grows, the less likely it is that people will want to store personal backups of it.

So I don't think the blockchain does anything novel here, and I don't think it does it better. Forcing arbitrary people to store arbitrary data forever regardless of value or interest is just wasteful.

>3) Frankenstein-like adaptations of traditional fintech constructs into a decentralized implementation, such as AMMs.

I think the oracle problem is really going to make "DeFi" a tough sell. There is, in fact, a lot of trust in our financial system, and being able to use a central authority (the justice system) to settle issues makes things a whole lot simpler and efficient.

In general I firmly believe that trust is usually a good thing that makes systems more efficient and this obstination of cryptopeople to get rid of it is more based on political ideology than pragmatism. Trust, but verify. But trust.