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 tiny grammar error #10

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
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
2 changes: 1 addition & 1 deletion validity_rollups_on_bitcoin.md
Original file line number Diff line number Diff line change
Expand Up @@ -97,7 +97,7 @@ Plasma solved the data availability problem by enabling users to exit with their

In 2019 Ethereum developers began thinking about how to solve both the data availability problem and the EVM compatibility problem in ways that also solved the other problems that Plasma and state channels had, such as the online/interactivity requirement. This led developers to revisit older proposals that required users to post a minimal amount of data on L1 for each L2 transaction.[^37] This category of protocols that put minimal data onchain while keeping transaction execution offchain came to be known as a "rollup" (which got its name from the first implementation of a validity rollup by Barry Whitehat).[^38]

Rollups are categorized into two main variants based on the way state transitions were determined to be valid: optimistic rollups, which use fault proofs to enforce correct state transitions, and validity rollups, which use validity proofs to enforce correct state transitions. (Validity rollups are also often called "zk-rollups", but this can be a misnomer since not all validity rollups use zk proofs.)[^39] Due to their reliance on cryptographic validity proofs, which automatically prevent invalid state transitions and withdrawals, validity rollups are considered "trustless" i.e. no additional trust assumptions on top of the normal L1 trust assumptions. In contrast, if someone attempts to make an invalid withdrawal from an optimistic rollup, then to block the invalid withdrawal, at least one honest party must be online, notice the invalid withdrawal attempt, construct and submit a fault proof transaction, and be able to get the fault proof transaction confirmed within a challenge period defined by the optimistic rollup protocol. Effectively, optimistic rollup users trust the block producers not to steal from optimistic rollup smart contracts, while validity rollup users do not have trust block producers not to steal because they can't. See ["Majority-vulnerable contracts"](#majority-vulnerable-contracts) in Section 6.4.
Rollups are categorized into two main variants based on the way state transitions were determined to be valid: optimistic rollups, which use fault proofs to enforce correct state transitions, and validity rollups, which use validity proofs to enforce correct state transitions. (Validity rollups are also often called "zk-rollups", but this can be a misnomer since not all validity rollups use zk proofs.)[^39] Due to their reliance on cryptographic validity proofs, which automatically prevent invalid state transitions and withdrawals, validity rollups are considered "trustless" i.e. no additional trust assumptions on top of the normal L1 trust assumptions. In contrast, if someone attempts to make an invalid withdrawal from an optimistic rollup, then to block the invalid withdrawal, at least one honest party must be online, notice the invalid withdrawal attempt, construct and submit a fault proof transaction, and be able to get the fault proof transaction confirmed within a challenge period defined by the optimistic rollup protocol. Effectively, optimistic rollup users trust the block producers not to steal from optimistic rollup smart contracts, while validity rollup users do not have to trust block producers not to steal because they can't. See ["Majority-vulnerable contracts"](#majority-vulnerable-contracts) in Section 6.4.

With solutions to the most important shortcomings of previous scalability proposals in hand, Ethereum developers began pushing the limits of rollup capabilities. For example, the Fuel and Loopring teams built optimistic and validity rollups, respectively, for p2p payments and atomic swaps, and the Aztec team built a validity rollup for Zerocash-style "shielded" transactions.[^40][^41][^42] Eventually Ethereum developers even figured out how to build fully EVM-compatible rollups, first using optimistic rollups and later using validity rollups.[^43][^44] (It should be noted that as of the time of writing, all live rollups on Ethereum except Fuel rely on multisigs to secure their bridge contract, which is a different security model than "true" rollups that rely entirely on the consensus of their parent chain for security — Edan Yago has jokingly called these "very optimistic" rollups.[^45][^46] The expectation is that as these protocols mature, they will transition to a "true" rollup security model.)

Expand Down