We're super greatful to saurik for writing up such a great analysis of what he found. If you want to hear some of our key takeaways as the maintainers of the network, you can check out our disclosure post here [1].
If you're wondering WTF Optimism is... we are building an optimistic rollup on top of ethereum. The basic idea is to de-couple blockchain computation from data availability and allow a new operator to exist called a sequencer which can accept transaction requests and submit the calldata to Ethereum Mainnet, but do the computation on Optimism Mainnet. There is an idea of a fault proof which means you can verify that the computation done on Optimism Mainnet followed the exact rules of the EVM, and you can prove this on Ethereum Mainnet. Our fault proof codebase, cannon, was built by another jailbreak legend (geohot) precisely with the goal of running Ethereum's battle-tested code and minimize the chances of bugs like this. It's some really cool stuff. If you're into compilers, VMs, and blockchains alike, check it out! [2]
The protocol is still in active development, it is not done yet, and that's exactly why we set up this bug bounty program. We think bug bounties matter, a lot, and we're proud to now become the record holders of the largest bug bounty payout in history, however we hope to very quickly be beaten by someone else. Developers like saurik, who we've gotten to know recently, are super important for this ecosystem to thrive. Building this stuff is hard, and we want the best hackers in the world to get rich breaking these protocols because if we succeed in this industry, this technology will be the backbone of the world's financial infrastructure — it needs to be secure. Everything we write is also MIT licensed and developed completely in the open.
Very happy to answer any questions, I'll check this thread for the rest of the day — AMA :)
I've been wondering what the hardware requirements for running Optimism's infrastructure are relative to just running a Mainnet node. If Optimism can process more transactions than the main chain, does that mean state growth is also much higher? How is Optimism thinking about this problem as it moves to decentralize the sequencer 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]
I have a question: why did you make transaction data from before the Nov 11 upgrade unavailable? How hard would this have been? It's just serving the same immutable transactions that were there before, right? People were expecting these to be available for planning and tax reporting.
Even finding out about them after the fact was difficult because the cause of missing transactions wasn't made public on the user-facing site. For months the maintainers fielded questions from people on the discord that could have been satisfied by an announcement on the website. And even the announcements on discord came slowly.
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.
>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
That doesn't look like your best. Here's the blog you refer to[1]:
The only pinned tweet is a cute meme about the whitelist change, nothing to head off frustrated users wondering where transaction history went. (I don't know how to link a historical post in context but I can assure it was not evident on the Twitter feed why I was missing transaction history, and there are no such warnings before.)
The only reason I even got on the Optimism Discord is because none of these places had any information! And then, even when I went to the Discord, and go to #announcements, and look at what was being announced in the runup and release, the loss of transactions still isn't mentioned! [2]
Maintainers talk about the upgrade, to be sure, but not this implication of it.
So no, I don't know how can justify the claim that you made a serious effort to alert users.
You're right that we could have been better communicators about this. We prioritized our concerns with applications that could break during the upgrade, and we biased our public communications towards developers as a result.
For example, you're right that a notification on our homepage, in addition to our docs, would have been a good reminder to users. We'll work on getting a blog post and better documentation up that explains exactly how to access data from before 11/11. We really appreciate the candid feedback here.
We're a very fast growing startup tackling a herculean task, so we're bound to make mistakes and this is one of them — I hope you can understand. We want to be much better communicators going forward.
>For example, you're right that a notification on our homepage, in addition to our docs
I don't remember it being in the docs either, as that would have also saved me from signing up on the Discord.
And this isn't an issue of prioritization. Remember, your overworked volunteers and maintainers on the Discord are still spending hours every day fielding questions in #user-support that could have been answered by a link in prominent places. You're wasting more person-hours than you would have with effective communication and trivial updates in prominent places.
You didn't even benefit your own goals by leaving those out!
So no, I guess I don't understand what the huge barrier is to putting out these important notices.
But he said "sorry" (somewhat) politely and pulled the "we are fast growing startup"-card .. so you are obligated to forgive him?
It seems quite clear to me (as a third party to this) that the lack of communication w.r.t. this behavior was intentional. Trying to fix a mistake without having to admit having made it in the first place...
Civil discussion is going to collapse even further if bad actors don't stop with the dark patterns.
We're super greatful to saurik for writing up such a great analysis of what he found. If you want to hear some of our key takeaways as the maintainers of the network, you can check out our disclosure post here [1].
If you're wondering WTF Optimism is... we are building an optimistic rollup on top of ethereum. The basic idea is to de-couple blockchain computation from data availability and allow a new operator to exist called a sequencer which can accept transaction requests and submit the calldata to Ethereum Mainnet, but do the computation on Optimism Mainnet. There is an idea of a fault proof which means you can verify that the computation done on Optimism Mainnet followed the exact rules of the EVM, and you can prove this on Ethereum Mainnet. Our fault proof codebase, cannon, was built by another jailbreak legend (geohot) precisely with the goal of running Ethereum's battle-tested code and minimize the chances of bugs like this. It's some really cool stuff. If you're into compilers, VMs, and blockchains alike, check it out! [2]
The protocol is still in active development, it is not done yet, and that's exactly why we set up this bug bounty program. We think bug bounties matter, a lot, and we're proud to now become the record holders of the largest bug bounty payout in history, however we hope to very quickly be beaten by someone else. Developers like saurik, who we've gotten to know recently, are super important for this ecosystem to thrive. Building this stuff is hard, and we want the best hackers in the world to get rich breaking these protocols because if we succeed in this industry, this technology will be the backbone of the world's financial infrastructure — it needs to be secure. Everything we write is also MIT licensed and developed completely in the open.
Very happy to answer any questions, I'll check this thread for the rest of the day — AMA :)
Also, we are hiring! [3]
[1] https://optimismpbc.medium.com/disclosure-fixing-a-critical-... [2] https://github.com/ethereum-optimism/cannon/ [3] https://boards.greenhouse.io/optimism