Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: update withdraw security model #415

Merged
merged 1 commit into from
Jun 2, 2022
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
192 changes: 10 additions & 182 deletions src/docs/how-optimism-works/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -128,9 +128,17 @@ Benefits of this include a snappy, instant user experience, with things like nea
Alternatively, users can skip the sequencer entirely and submit their transactions directly to the `CanonicalTransactionChain` via an Ethereum transaction.
This is typically more expensive because the fixed cost of submitting this transaction is paid entirely by the user and is not amortized over many different transactions.
However, this alternative submission method has the advantage of being resistant to censorship by the sequencer.
Even if the sequencer is actively censoring a user, the user can always continue to use Optimism and recover any funds through this mechanism.
Even if the sequencer is actively censoring a user, the user can always continue to send transactions on Optimism.

For the moment, [Optimism PBC](https://www.optimism.io/) runs the only block producer. Refer to [Protocol specs](../protocol/README.md) section for more information about how we plan to decentralize the Sequencer role in the future.
For the moment, [OP Labs PBC](https://www.optimism.io/) runs the only block producer on the Optimism network.
Refer to [Protocol specs](../protocol/README.md) section for more information about how we plan to decentralize the Sequencer role in the future.

::: tip NOTE
For users to be able to execute *withdrawals* in a censorship-resistant manner, a rollup must allow participants to trustlessly publish transaction *results* to Ethereum.
Currently, [OP Labs PBC](https://www.optimism.io/) is the only entity able to publish transaction results while we work to decentralize the "result proposal" role.
Although not unique to Optimism, it's worth understanding these security properties when using the system.
Permissionless result publication should be introduced alongside the production release of our [Cannon](https://github.com/ethereum-optimism/cannon/) fault proving system.
:::

### Block execution

Expand Down Expand Up @@ -226,183 +234,3 @@ You can also try hopping in [the Optimism discord](https://discord.optimism.io)

*How Optimism Works* is a high-level overview of how Optimism really works.
If you're interested in diving even deeper, you should check out the [protocol specs](../protocol) section of this website.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure why I left all of this draft content here...

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lol.

<!-- ## Why Optimistic Rollups?

Before any code was written, Optimism was just a goal: *make Ethereum mainstream*.

We just needed to figure out exactly how to turn that lofty goal into a reality.
Constructing a new L1 system was out of the question.
Optimism was designed to scale Ethereum, not create a new chain that competes with it.
This left only two serious options: Optimistic Rollups or ZK Rollups.

### Simple

ZK Rollups are extremely cool.
They're also extremely complicated.
The most advanced ZK Rollups are built on top of fields of mathematics still being established at this very moment.
In the pursuit of simplicity and sustainability, Optimistic Rollups really can't be beat.
Perhaps most the most critical advantage is that an Optimistic Rollup can be audited without a PhD.

### Flexible

Optimistic Rollups are also more flexible than their ZK counterparts.
For Optimistic Rollups, EVM compatibility is the expectation rather than a theoretical future outcome.
Existing Ethereum applications can easily be ported to most Optimistic Rollups, a requirement that we felt absolutely necessary for a system designed to scale *Ethereum*.

### Mature
Furthermore, we know from experience that an initial protocol release is just the beginning.
Optimistic Rollup infrastructure is far more mature than the equivalent ZK Rollup infrastructure.
This is mostly a result of the minimal additional code required to transform an Ethereum node into an Optimistic Rollup node.
The relative simplicity of building and maintaining Optimistic Rollups will only serve to widen this maturity gap as time goes on.

At the end of the day, we feel that there are a number of clear advantages to the Optimistic Rollup design for the particular needs and goals of Optimism.
We hope you'll find these advantages to be just as clear once you start using Optimism! -->

<!-- ## System overview

Now that we've covered the philosophy behind Optimism, let's take a look at how it currently works at a high level.

### Fault proofs

Since Ethereum doesn't execute the L2 transactions, transaction results published to Ethereum could be incorrect.
This doesn't impact the validity of the chain itself, just what smart contracts on Ethereum think the state of Optimism is.
The worst case scenario here would be that a contract for example allows a user to withdraw funds when the user didn't actuaLly have the right to withdraw funds.
Optimism is designed to prevent this with cryptoeconomic security.

(insert diagram)

In the Optimism system, users publish results for a given block.
Then other users can challenge that result and say they think the result is wrong.
There's always only one correct answer, and it's an answer that any honest node knows.
So if there's something wrong with the result, all honest nodes will immediately know and be able to challenge the block.
One honest node then needs to start the challenge, which begins a back-and-forth process between the challenger and the publisher to determine who was correct.
The process is designed so that it will always find the correct party programmatically.

We have a one-honest node assumption for security on Optimism, that is to say that there only needs to be one node willing to participate in the security process for the system to be secure.
Because of the way the security system is set up, this one node can keep the system secure by doing the challenge process and they get paid for the cost of the challenge, so it's mostly costless.
The party with the correct answer (which will be the honest node) will always win, so you can see why you only need that one party.
The process is relatively cheap and you only need one of them, and the one party can do this sustainably.


- Transaction results
(NOTE: Currently trusted)
- Transaction results are published to Ethereum, with one result per transaction currently
- Transactions can be published by any node that puts up a bond
- Transaction results are unchecked, they could be correct or they could be bogus (this is "optimistic")
- Transaction results can be challenged by any other party
- Can be detected immediately by any honest node because we have
- This kicks off a challenge process
- Challenge process TL;DR
(NOTE: Currently disabled until further notice)
- Multi-round process a lot like TrueBit
- We compile Geth down into MIPS and turn the transaction execution into a series of states
- We go over each state and find the first place where users agree on the input but disagree on the output
- Then we execute that one step and figure out who's correct
- If the result is challenged, then we delete that result and all results that were published after it
- this does NOT mean that transactions are reverted, transactions are never reverted, it's just that a bad result may be removed.
- Important to drive home

### Deposits and withdrawals

## Start building on Optimism
- Where to learn more?
- Contact form if you want to deploy and you want assistance in getting there
- Docs, help center, discord, github
- Or just bring your existing Etheruem expertise
- To Optimism! -->




<!-- ## Design goals

Before we explore the inner workings of Optimism, it's important to understand the goals that the Optimism system sets out to achieve.
These goals deeply impact the way in which Optimism is built and define how Optimism tackles new problems.
You'll see the effects of these goals in various places throughout the Optimism protocol.
By familiarizing yourself with these goals, you'll have a more intuitive understanding of exactly *why* Optimism is built the way that it is.

### Make Ethereum mainstream

Everything about the Optimism project comes down to one core goal: to make Ethereum mainstream.

We believe that Ethereum (and its ecosystem) has the potential to revolutionize the relationship that the average person has with the institutions that govern their lives.
Ethereum is the only platform with the reach and vision to make this potential future a reality.
We could talk for ages about why we love Ethereum.
At the end of the day, Optimism is built by Ethereans, for Ethereans.
We want the Ethereum vision to succeed.
And, of course, for Ethereum to succeed it has to break into the mainstream.

This commitment to Ethereum and its future has concrete and visible effects on the way Optimism is designed.
Almost every decision that Optimism makes is informed by the way that decision can help the future of Ethereum.
For example, as you'll see later in this page, Optimism is built almost entirely as a minimal wrapper around existing Ethereum code and infrastructure.
This design decision deliberately ties Optimism to Ethereum's roadmap and means concretely that Optimism's engineers can shift towards working on core Ethereum infrastructure once the protocol is fully stable.

### Cut transaction costs

For Ethereum to break into the mainstream it has to become significantly more accessible to the average person.
The most obvious barrier to this accessibility is Ethereum's sky-high transaction fees.
It's exceedingly clear that Ethereum is simply too expensive for most people to use on a daily basis.
It's Optimism's goal to reduce Ethereum's transaction fees without compromising on the security properties that make Ethereum so attractive in the first place.

Optimism is the currently least expensive general-purpose L2 system on average and we intend to keep it that way.
It accomplishes this with various techniques that minimize the most expensive part of any Layer 2 system, the publication of transaction data to Ethereum.
However, there's always room to keep reducing costs on multiple fronts.
The impact that a design decision can have on end-user cost always has to be considered when creating new features for Optimism.

### Improve user experience

Accessibility isn't just about cheaper transactions, it's also about creating a great user experience.
Unfortunately, web2 apps usually outperform web3 apps on this front as a side-effect of centralization.
Optimism has already made significant improvements to the status quo of web3 user experience and each feature we add is carefully designed to always improve the user experience that we have in the face of our constraints.

For example, Optimism was the first L2 system to introduce instant "Sequencer confirmations", a technique where transactions sent on L2 can have strong guarantees about finality in a very short period of time.
As a result, apps deployed natively to Optimism can finally start to compete with the user experience of existing web2 apps.

### Improve developer experience

Alongside an improved user experience comes an improved developer experience.
At the end of the day we need to make it as easy and as safe as possible to build applications for Optimism.

Optimism also pioneered EVM equivalence, a Layer 2 design pattern where the client software is an almost completely vanilla version of an existing Ethereum node.
This means more than just API-level compatibility.
Tools that expect the underlying blockchain to work a certain way or tools that are designed to hook directly into an Ethereum node will "just work", no fiddling required.

All this sounds fancy, but it ultimately just means that Optimism is the easiest L2 to deploy to by a longshot.
We think you'll have a lot of fun working on Optimism.
And because of Optimism's tight compatibility with Ethereum, you're never locked into the ecosystem.
You can always take your code and deploy it to other Ethereum-based chains with little effort.

We never think we're finished, we always have more work to do.
We also believe in compatibility with other L2s and actively work to integrate the design patters that they use.
In the spirit of pragmatism and collaboration, we try to maintain compatiblity with other L2s to minimize lockin as much as possible, we think blockchain apps should be portable.

### Security through simplicity

Optimism is designed to be as simple as possible at its core.
It's aimed to be composed of the minimum number of pieces required to make a secure L2 system possible.
This simplicity and minimalism is important for a number of significant reasons to Optimism.
First, a minimal protocol will come with the least amount of overhead.
We've designed our protocol to have the smallest possible diff from existing software.
This way we don't need an entire team of people to maintain a highly custom codebase.

Simplicity also means that we're writing fewer lines of code, which means there's less room to make mistakes.
Simplicity is security.
Particularly when it comes to complex things like a Layer 2 rollup system, it should be as simple as possible so there's little room for error and so that it's as easy as possible for outside people to audit the codebase.
If a codebase can't be easily audited, it can't be trusted.

Finally, simplicity is also important for our vision.
By limiting the amount of code that we write on top of existing Ethereum tooling, we're able to position ourselves to dedicate most of the Optimism engineering effort to improving that existing tooling.
Since it will mostly be the same codebase, it will literally be a direct improvement to Optimism to be working on code like Geth.
Once the core Optimism code is done, there won't be a lot else for the Optimism team to work on!

### Build for the long-term

- Building a project is a serious endeavour. We're not here to leave. We're here to create an ecosystem that'll be around in 20 years. We're more serious about it than anyone else.
- Building a long-term ecosystem is about building sustainably. We spend a lot of time building software, but we also spend a lot of time thinking about how we can create a blockchain ecosystem where projects are supported during every stage of the development process.
- We're not in it to create an entirely separate ecosystem. You're not leaving the Ethereum ecosystem. Everything we do goes back into the Ethereum ecosystem.
- Building with the Ethereum codebase wasn't just a practical decision, it was a philosophical one. We want to work on Ethereum, we want to scale Ethereum. Optimism is jsut a part of scaling Etheruem.

- Why Optimism?
- First reiterate the previous points of cost and security, of the general-purpose rollups our tech is far ahead and we've got an excellent team pushing the protocol and client software even further. "You can expect to save a sigificant amount of money"
- We're thinking about the future of blockchains in a way that nobody else is. We want to create a sustainable ecosystem where you'll get rewarded for your contribution to the system. Retroactive public goods funding is a part of this, with Optimism you can expect to get top notch support in getting your application running, funded by protocol revenue. Optimism helps you win, it's not just another platform for you to deploy to. -->