비탈릭 "롤업에 대한 불완전한 가이드, An Incomplete Guid to Rollups"

#이더리움롤업 #비탈릭블로그 #롤업가이드 #아비트롬 #ZK싱크

 

이더리움 롤업이 화두가 되는 2023년

비탈릭의 이더리움의 미래는 무엇인지

 

비탈릭의 블로그

https://vitalik.ca/categories/blockchains.html

Blockchains

2023 Mar 31 How will Ethereum's multi-client philosophy interact with ZK-EVMs? 2023 Feb 28 Some personal user experiences 2023 Jan 20 An incomplete guide to stealth addresses 2022 Dec 06 Updating my blog: a quick GPT chatbot coding experiment 2022 Dec 05 What in the Ethereum application ecosystem ex...

 

 

비탁릭이 2년 올린 롤업에 대한 가이드

https://vitalik.ca/general/2021/01/05/rollup.html

An Incomplete Guide to Rollups

Rollups are all the rage in the Ethereum community, and are poised to be the key scalability solution for Ethereum for the foreseeable future. But what exactly is this technology, what can you expect from it and how will you be able to use it? This post will attempt to answer some of those key quest...

 

Rollups are all the rage in the Ethereum community, and are poised to be the key scalability solution for Ethereum for the foreseeable future. But what exactly is this technology, what can you expect from it and how will you be able to use it? This post will attempt to answer some of those key questions.

 

롤업은 이더리움 커뮤니티의 모든 분노(?)이며 가까운 미래에 이더리움의 핵심 확장성 솔루션이 될 준비가 되어 있습니다. 하지만 이 기술은 정확히 무엇이며, 무엇을 기대할 수 있으며 어떻게 사용할 수 있습니까? 이 게시물은 이러한 주요 질문 중 일부에 대한 답변을 시도합니다.

 

Rage is strong anger that is difficult to contorl. (컨트롤하기 어려운 강한 분노)

 

Background: what is layer-1 and layer-2 scaling?

There are two ways to scale a blockchain ecosystem. First, you can make the blockchain itself have a higher transaction capacity. The main challenge with this technique is that blockchains with "bigger blocks" are inherently more difficult to verify and likely to become more centralized. To avoid such risks, developers can either increase the efficiency of client software or, more sustainably, use techniques such as sharding to allow the work of building and verifying the chain to be split up across many nodes; the effort known as "eth2" is currently building this upgrade to Ethereum.

Second, you can change the way that you use the blockchain. Instead of putting all activity on the blockchain directly, users perform the bulk of their activity off-chain in a "layer 2" protocol. There is a smart contract on-chain, which only has two tasks: processing deposits and withdrawals, and verifying proofs that everything happening off-chain is following the rules. There are multiple ways to do these proofs, but they all share the property that verifying the proofs on-chain is much cheaper than doing the original computation off-chain.

 

배경: 레이어 1 및 레이어 2 스케일링이란 무엇입니까?

블록체인 생태계를 확장하는 방법에는 두 가지가 있습니다.

첫째, 블록체인 자체의 트랜잭션 용량을 높일 수 있습니다 . 이 기술의 주요 문제는 "더 큰 블록"이 있는 블록체인이 본질적으로 확인하기 더 어렵고 더 중앙 집중화될 가능성이 있다는 것입니다. 이러한 위험을 피하기 위해 개발자는 클라이언트 소프트웨어의 효율성을 높이거나 보다 지속 가능하게 샤딩과 같은 기술을 사용하여 체인을 구축하고 확인하는 작업을 여러 노드에 걸쳐 분할할 수 있습니다. "eth2"로 알려진 노력은 현재 이더리움으로의 업그레이드를 구축하고 있습니다.

둘째, 블록체인을 사용하는 방식을 변경할 수 있습니다 . 모든 활동을 블록체인에 직접 넣는 대신 사용자는 "레이어 2" 프로토콜에서 오프체인 활동의 대부분을 수행합니다. 온체인에는 두 가지 작업만 있는 스마트 계약이 있습니다. 입금 및 출금 처리와 오프체인에서 일어나는 모든 일이 규칙을 따르고 있다는 증거를 확인하는 것입니다. 이러한 증명을 수행하는 방법에는 여러 가지가 있지만, 모두 온체인에서 증명을 검증하는 것이 원래 계산을 오프체인에서 수행하는 것보다 훨씬 저렴하다는 속성을 공유합니다.

 

State channels vs plasma vs rollups

The three major types of layer-2 scaling are state channels, Plasma and rollups. They are three different paradigms, with different strengths and weaknesses, and at this point we are fairly confident that all layer-2 scaling falls into roughly these three categories (though naming controversies exist at the edges, eg. see "validium").

 

상태 채널 vs 플라즈마 vs 롤업

레이어 2 스케일링의 세 가지 주요 유형은 상태 채널 , 플라즈마 및 롤업입니다. 그것들은 서로 다른 강점과 약점을 가진 세 가지 다른 패러다임이며, 이 시점에서 우리는 모든 레이어2스케일링이 대략 이 세 가지 범주에 속한다는 것을 상당히 확신합니다(가장자리에 명명 논쟁이 존재하지만, 예를 들어 "validium" 참조 ) .

 

How do channels work?

See also: https://www.jeffcoleman.ca/state-channels and statechannels.org

Imagine that Alice is offering an internet connection to Bob, in exchange for Bob paying her $0.001 per megabyte. Instead of making a transaction for each payment, Alice and Bob use the following layer-2 scheme.

First, Bob puts $1 (or some ETH or stablecoin equivalent) into a smart contract. To make his first payment to Alice, Bob signs a "ticket" (an off-chain message), that simply says "$0.001", and sends it to Alice. To make his second payment, Bob would sign another ticket that says "$0.002", and send it to Alice. And so on and so forth for as many payments as needed. When Alice and Bob are done transacting, Alice can publish the highest-value ticket to chain, wrapped in another signature from herself. The smart contract verifies Alice and Bob's signatures, pays Alice the amount on Bob's ticket and returns the rest to Bob. If Alice is unwilling to close the channel (due to malice or technical failure), Bob can initiate a withdrawal period (eg. 7 days); if Alice does not provide a ticket within that time, then Bob gets all his money back.

This technique is powerful: it can be adjusted to handle bidirectional payments, smart contract relationships (eg. Alice and Bob making a financial contract inside the channel), and composition (if Alice and Bob have an open channel and so do Bob and Charlie, Alice can trustlessly interact with Charlie). But there are limits to what channels can do. Channels cannot be used to send funds off-chain to people who are not yet participants. Channels cannot be used to represent objects that do not have a clear logical owner (eg. Uniswap). And channels, especially if used to do things more complex than simple recurring payments, require a large amount of capital to be locked up.

 

채널은 어떻게 작동합니까?

참조: https://www.jeffcoleman.ca/state-channels 및 statechannels.org

Bob이 메가바이트당 $0.001를 지불하는 대가로 Alice가 Bob에게 인터넷 연결을 제공한다고 상상해 보십시오. 지불할 때마다 거래를 하는 대신 Alice와 Bob은 다음과 같은 레이어 2 체계를 사용합니다.

먼저 Bob은 스마트 계약에 1달러(또는 일부 ETH 또는 스테이블 코인 등가물)를 넣습니다. Alice에게 첫 번째 지불을 하기 위해 Bob은 단순히 "$0.001"라고 적힌 "티켓"(오프체인 메시지)에 서명하고 이를 Alice에게 보냅니다. 두 번째 지불을 위해 Bob은 "$0.002"라고 적힌 다른 티켓에 서명하고 Alice에게 보냅니다. 그리고 필요한 만큼의 지불에 대해 등등. Alice와 Bob이 거래를 완료하면 Alice는 자신의 다른 서명으로 래핑된 가장 가치 있는 티켓을 체인에 게시할 수 있습니다. 스마트 계약은 Alice와 Bob의 서명을 확인하고 Alice에게 Bob의 티켓 금액을 지불하고 나머지는 Bob에게 반환합니다. Alice가 채널을 닫고 싶지 않은 경우(악의 또는 기술적 오류로 인해) Bob은 철회 기간(예: 7일)을 시작할 수 있습니다. Alice가 해당 시간 내에 티켓을 제공하지 않으면

이 기술은 강력합니다. 양방향 결제, 스마트 계약 관계(예: Alice와 Bob이 채널 내에서 금융 계약을 체결하는 경우) 및 구성(Alice와 Bob이 공개 채널을 가지고 있고 Bob과 Charlie도 마찬가지인 경우)을 처리하도록 조정할 수 있습니다. Alice는 Charlie와 신뢰 없이 상호 작용할 수 있습니다. 하지만 채널이 할 수 있는 일에는 한계가 있습니다. 아직 참가자가 아닌 사람들에게 오프체인 자금을 보내는 데 채널을 사용할 수 없습니다. 명확한 논리적 소유자(예: Uniswap)가 없는 개체를 나타내는 데 채널을 사용할 수 없습니다. 그리고 채널, 특히 단순한 반복 지불보다 더 복잡한 작업을 수행하는 데 사용되는 경우 많은 자본을 잠가야 합니다.

 

How does plasma work?

See also: the original Plasma paper, and Plasma Cash.

To deposit an asset, a user sends it to the smart contract managing the Plasma chain. The Plasma chain assigns that asset a new unique ID (eg. 537). Each Plasma chain has an operator (this could be a centralized actor, or a multisig, or something more complex like PoS or DPoS). Every interval (this could be 15 seconds, or an hour, or anything in between), the operator generates a "batch" consisting of all of the Plasma transactions they have received off-chain. They generate a Merkle tree, where at each index X in the tree, there is a transaction transferring asset ID X if such a transaction exists, and otherwise that leaf is zero. They publish the Merkle root of this tree to chain. They also send the Merkle branch of each index X to the current owner of that asset. To withdraw an asset, a user publishes the Merkle branch of the most recent transaction sending the asset to them. The contract starts a challenge period, during which anyone can try to use other Merkle branches to invalidate the exit by proving that either (i) the sender did not own the asset at the time they sent it, or (ii) they sent the asset to someone else at some later point in time. If no one proves that the exit is fraudulent for (eg.) 7 days, the user can withdraw the asset.

 

플라즈마는 어떻게 작동합니까?

참조: 원본 플라즈마 용지 , 플라즈마 캐시 .

자산을 예치하기 위해 사용자는 플라즈마 체인을 관리하는 스마트 계약으로 자산을 보냅니다. 플라즈마 체인은 해당 자산에 새로운 고유 ID(예: 537)를 할당합니다. 각 플라즈마 체인에는 운영자가 있습니다 (중앙화된 행위자, 다중 서명 또는 PoS 또는 DPoS와 같은 더 복잡한 것일 수 있음). 매 간격(15초, 1시간 또는 그 사이의 모든 것일 수 있음)마다 운영자는 오프체인에서 받은 모든 플라즈마 트랜잭션으로 구성된 "배치"를 생성합니다. 그들은 Merkle 트리를 생성합니다. 여기서 트리의 각 인덱스에는 그러한 트랜잭션이 존재하는 경우 X자산 ID를 전송하는 트랜잭션이 있고 그렇지 않은 경우 해당 리프는 0입니다. X그들은 이 트리의 Merkle 루트를 체인에 게시합니다. 또한 각 인덱스의 Merkle 분기를 보냅니다.X해당 자산의 현재 소유자에게. 자산을 인출하기 위해 사용자는 자산을 보낸 가장 최근 트랜잭션의 Merkle 분기를 게시합니다. 계약은 챌린지 기간을 시작하며, 이 기간 동안 누구나 (i) 보낸 사람이 자산을 보낸 시점에 자산을 소유하지 않았거나 (ii) 자산을 보냈음을 증명하여 종료를 무효화하기 위해 다른 Merkle 분기를 사용하려고 시도할 수 있습니다. 나중에 다른 사람에게. (예를들면 7일) 동안 아무도 퇴출이 사기임을 증명하지 못하면 사용자는 자산을 인출할 수 있습니다.

 

Plasma provides stronger properties than channels: you can send assets to participants who were never part of the system, and the capital requirements are much lower. But it comes at a cost: channels require no data whatsoever to go on chain during "normal operation", but Plasma requires each chain to publish one hash at regular intervals. Additionally, Plasma transfers are not instant: you have to wait for the interval to end and for the block to be published.

 

플라즈마는 채널보다 강력한 속성을 제공합니다. 시스템에 전혀 참여하지 않은 참가자에게 자산을 보낼 수 있으며 자본 요구 사항이 훨씬 낮습니다. 그러나 비용이 발생합니다. 채널은 "정상 작동" 중에 체인에 데이터가 전혀 필요하지 않지만 Plasma는 각 체인이 일정한 간격으로 하나의 해시를 게시해야 합니다. 또한 플라즈마 전송은 즉각적이지 않습니다. 간격이 끝나고 블록이 게시될 때까지 기다려야 합니다.

 

Additionally, Plasma and channels share a key weakness in common: the game theory behind why they are secure relies on the idea that each object controlled by both systems has some logical "owner". If that owner does not care about their asset, then an "invalid" outcome involving that asset may result. This is okay for many applications, but it is a deal breaker for many others (eg. Uniswap). Even systems where the state of an object can be changed without the owner's consent (eg. account-based systems, where you can increase someone's balance without their consent) do not work well with Plasma. This all means that a large amount of "application-specific reasoning" is required in any realistic plasma or channels deployment, and it is not possible to make a plasma or channel system that just simulates the full ethereum environment (or "the EVM"). To get around this problem, we get to... rollups.

 

또한 Plasma와 채널은 공통적으로 중요한 약점을 공유합니다. 두 시스템이 안전한 이유에 대한 게임 이론은 두 시스템에서 제어하는 ​​각 개체에 논리적 "소유자"가 있다는 생각에 의존합니다. 해당 소유자가 자신의 자산을 관리하지 않으면 해당 자산과 관련된 "잘못된" 결과가 발생할 수 있습니다. 이것은 많은 응용 프로그램에 적합하지만 다른 많은 응용 프로그램(예: Uniswap)에 대해서는 거래 차단이 될 수 있습니다. 소유자의 동의 없이 개체의 상태를 변경할 수 있는 시스템(예: 계정 기반 시스템 ,동의 없이 누군가의 잔액) 플라즈마와 잘 작동하지 않습니다. 이는 실제 플라즈마 또는 채널 배치에 많은 양의 "응용 프로그램별 추론"이 필요하며 전체 이더리움 환경(또는 "EVM")을 시뮬레이션하는 플라즈마 또는 채널 시스템을 만드는 것은 불가능함을 의미합니다. . 이 문제를 해결하기 위해 롤업을 수행합니다.

 

Rollups

See also: EthHub on optimistic rollups and ZK rollups.

Plasma and channels are "full" layer 2 schemes, in that they try to move both data and computation off-chain. However, fundamental game theory issues around data availability means that it is impossible to safely do this for all applications. Plasma and channels get around this by relying on an explicit notion of owners, but this prevents them from being fully general. Rollups, on the other hand, are a "hybrid" layer 2 scheme. Rollups move computation (and state storage) off-chain, but keep some data per transaction on-chain. To improve efficiency, they use a whole host of fancy compression tricks to replace data with computation wherever possible. The result is a system where scalability is still limited by the data bandwidth of the underlying blockchain, but at a very favorable ratio: whereas an Ethereum base-layer ERC20 token transfer costs ~45000 gas, an ERC20 token transfer in a rollup takes up 16 bytes of on-chain space and costs under 300 gas.

 

롤 업

참조: 낙관적 롤업 및 ZK 롤업 에 대한 EthHub .

플라즈마와 채널은 데이터 와 계산을 모두 오프체인으로 이동하려고 한다는 점에서 "완전한" 레이어 2 방식입니다 . 그러나 데이터 가용성에 대한 근본적인 게임 이론 문제는 모든 애플리케이션에 대해 이를 안전하게 수행하는 것이 불가능하다는 것을 의미합니다. 플라즈마와 채널은 소유자에 대한 명시적인 개념에 의존하여 이 문제를 해결하지만 이것이 완전히 일반화되는 것을 방지합니다. 반면에 롤업은 "하이브리드" 레이어 2 방식입니다. 롤업은 계산(및 상태 저장)을 오프체인으로 이동하지만 트랜잭션당 일부 데이터는 온체인에 유지합니다 . 효율성을 향상시키기 위해 그들은 데이터를 계산으로 대체하기 위해 멋진 압축 트릭을 사용합니다.가능한 한. 그 결과 확장성은 여전히 ​​기본 블록체인의 데이터 대역폭에 의해 제한되지만 매우 유리한 비율로 시스템이 생성됩니다. Ethereum 기본 계층 ERC20 토큰 전송 비용은 ~45000 가스인 반면, 롤업에서 ERC20 토큰 전송은 16개의 온체인 공간을 차지하고 300가스 미만의 비용이 소요됨

 

The fact that data is on-chain is key (note: putting data "on IPFS" does not work, because IPFS does not provide consensus on whether or not any given piece of data is available; the data must go on a blockchain). Putting data on-chain and having consensus on that fact allows anyone to locally process all the operations in the rollup if they wish to, allowing them to detect fraud, initiate withdrawals, or personally start producing transaction batches. The lack of data availability issues means that a malicious or offline operator can do even less harm (eg. they cannot cause a 1 week delay), opening up a much larger design space for who has the right to publish batches and making rollups vastly easier to reason about. And most importantly, the lack of data availability issues means that there is no longer any need to map assets to owners, leading to the key reason why the Ethereum community is so much more excited about rollups than previous forms of layer 2 scaling: rollups are fully general-purpose, and one can even run an EVM inside a rollup, allowing existing Ethereum applications to migrate to rollups with almost no need to write any new code.

 

데이터 가 온 체인이라는 사실 이 핵심 입니다 . 데이터를 온체인에 놓고 그 사실에 대한 합의를 얻으면 누구나 원할 경우 롤업의 모든 작업을 로컬에서 처리할 수 있으므로 사기를 감지하고 인출을 시작하거나 개인적으로 트랜잭션 배치를 생성할 수 있습니다. 데이터 가용성 문제가 없다는 것은 악의적이거나 오프라인인 운영자가 할 수 있는 일이 훨씬 적다는 것을 의미합니다.피해(예: 1주일 지연을 일으킬 수 없음), 배치를 게시할 권리가 있는 사람에게 훨씬 더 큰 디자인 공간을 열어주고 롤업을 훨씬 쉽게 추론할 수 있도록 합니다. 그리고 가장 중요한 것은 데이터 가용성 문제가 없다는 것은 더 이상 자산을 소유자에게 매핑할 필요가 없다는 것을 의미하며, 이는 Ethereum 커뮤니티가 이전 형태의 레이어 2 스케일링보다 롤업에 대해 훨씬 더 흥분하는 주요 이유입니다 . 완전히 범용이며 롤업 내에서 EVM을 실행할 수도 있으므로 기존 이더리움 애플리케이션이 새 코드를 거의 작성할 필요 없이 롤업으로 마이그레이션할 수 있습니다 .

 

OK, so how exactly does a rollup work?

There is a smart contract on-chain which maintains a state root: the Merkle root of the state of the rollup (meaning, the account balances, contract code, etc, that are "inside" the rollup).

 

그렇다면 롤업은 정확히 어떻게 작동합니까?

상태 루트를 유지하는 온체인 스마트 계약이 있습니다 : 롤업 상태의 Merkle 루트(즉, 롤업 "내부"에 있는 계정 잔액, 계약 코드 등).

 

대표사진 삭제

사진 설명을 입력하세요.

Anyone can publish a batch, a collection of transactions in a highly compressed form together with the previous state root and the new state root (the Merkle root after processing the transactions). The contract checks that the previous state root in the batch matches its current state root; if it does, it switches the state root to the new state root.

 

누구나 이전 상태 루트 및 새 상태 루트( 트랜잭션 처리 후 Merkle 루트)와 함께 고도로 압축된 트랜잭션 모음인 배치를 게시 할 수 있습니다 . 계약은 배치의 이전 상태 루트가 현재 상태 루트와 일치하는지 확인합니다. 그렇다면 상태 루트를 새 상태 루트로 전환합니다.

대표사진 삭제

사진 설명을 입력하세요.

 

To support depositing and withdrawing, we add the ability to have transactions whose input or output is "outside" the rollup state. If a batch has inputs from the outside, the transaction submitting the batch needs to also transfer these assets to the rollup contract. If a batch has outputs to the outside, then upon processing the batch the smart contract initiates those withdrawals.

And that's it! Except for one major detail: how to do know that the post-state roots in the batches are correct? If someone can submit a batch with any post-state root with no consequences, they could just transfer all the coins inside the rollup to themselves. This question is key because there are two very different families of solutions to the problem, and these two families of solutions lead to the two flavors of rollups.

 

입금 및 출금을 지원하기 위해 입력 또는 출력이 롤업 상태 "외부"인 트랜잭션을 가질 수 있는 기능을 추가합니다. 배치에 외부 입력이 있는 경우 배치를 제출하는 트랜잭션은 이러한 자산도 롤업 계약으로 전송해야 합니다. 배치에 외부로의 출력이 있는 경우 배치를 처리할 때 스마트 계약이 해당 인출을 시작합니다.

 

그리고 그게 다야! 한 가지 주요 세부 사항을 제외하고:  배치의 사후 상태 루트가 올바른지 어떻게 알 수 있는지? 누군가 결과 없이 사후 상태 루트가 있는 배치를 제출할 수 있는 경우 롤업 내부의 모든 코인을 자신에게 전송할 수 있습니다. 이 질문은 문제에 대한 솔루션의 두 가지 매우 다른 제품군이 있고 이 두 가지 솔루션 제품군이 두 가지 유형의 롤업으로 이어지기 때문에 핵심입니다.

 

Optimistic rollups vs ZK rollups

The two types of rollups are:

1. Optimistic rollups, which use fraud proofs: the rollup contract keeps track of its entire history of state roots and the hash of each batch. If anyone discovers that one batch had an incorrect post-state root, they can publish a proof to chain, proving that the batch was computed incorrectly. The contract verifies the proof, and reverts that batch and all batches after it.
2. ZK rollups, which use validity proofs: every batch includes a cryptographic proof called a ZK-SNARK (eg. using the PLONK protocol), which proves that the post-state root is the correct result of executing the batch. No matter how large the computation, the proof can be very quickly verified on-chain.

There are complex tradeoffs between the two flavors of rollups:

 

옵티미즘 롤업 VS ZK 롤업

롤업의 두 가지 유형은 다음과 같습니다.

1. 사기 증명을 사용하는 옵티미즘 롤업 : 롤업 계약은 상태 루트의 전체 기록과 각 배치의 해시를 추적합니다. 누군가 하나의 배치에 잘못된 사후 상태 루트가 있음을 발견하면 체인에 대한 증명을 게시하여 배치가 잘못 계산되었음을 증명할 수 있습니다. 계약은 증거를 확인하고 해당 배치와 그 이후의 모든 배치를 되돌립니다.
2. 유효성 증명을 사용하는 ZK 롤업 : 모든 배치 에는 사후 상태 루트가 배치 실행의 올바른 결과임을 증명하는 ZK-SNARK(예: PLONK 프로토콜 사용)라는 암호화 증명이 포함됩니다. 연산량이 아무리 크더라도 증명은 온체인에서 매우 빠르게 검증될 수 있습니다.

롤업의 두 가지 특징 사이에는 복잡한 장단점이 있습니다.

 

Property 항목	Optimistic rollups 옵티미스틱 롤업	ZK rollups ZK 롤업
Fixed gas cost per batch 배치당 고정된 가스비	~40,000 (a lightweight transaction that mainly just changes the value of the state root) 주요하게 상태루트 값만 변경하는 가벼운 트랜잭션 (~4만)	~500,000 (verification of a ZK-SNARK is quite computationally intensive) 계산 직약적인 ZK-스나크 검증 (~50만)
Withdrawal period 철회기간	~1 week (withdrawals need to be delayed to give time for someone to publish a fraud proof and cancel the withdrawal if it is fraudulent) ~1주일 (누군가 사기 증거를 게시하고 사기인 경우 철회를 취소할 시간을 주기위해 지연)	Very fast (just wait for the next batch) 매우빠름 (다음배치 동안 기다림)
Complexity of technology 기술의 복잡성	Low 낮음	High (ZK-SNARKs are very new and mathematically complex technology) 높음(ZK-스타크는 매우 새롭고 수학적으로 복잡한 기술)
Generalizability 일반화 가능성	Easier (general-purpose EVM rollups are already close to mainnet) 더 쉬움(범용목적의 EVM 롤업은 이미 메인넷에 가까움)	Harder (ZK-SNARK proving general-purpose EVM execution is much harder than proving simple computations, though there are efforts (eg. Cairo) working to improve on this) 더 어려움(범용 목적의 EVM실행을 ZK-스나크가 증명하는 것은 이를 개선하려는 노력들이 있지만 단순한 계산을 증명하는 것보다 훨씬 어려움
Per-transaction on-chain gas costs 트랜잭션당 온체인가스비용	Higher 더 높음	Lower (if data in a transaction is only used to verify, and not to cause state changes, then this data can be left out, whereas in an optimistic rollup it would need to be published in case it needs to be checked in a fraud proof) 낮음(트랜잭션의 데이터가 상태 변경을 유발하지 않고 확인에만 사용되는 경우 이 데이터를 생략 사능, 반면에 옵티미스틱 롤업에서 사기증거로 확인해야 하는 경우 게시필요
Off-chain computation costs 오프체인 계산 비용	Lower (though there is more need for many full nodes to redo the computation) 더 낮음(비록 계산을 다시 실행하려면 많은 전체 노드가 필요)	Higher (ZK-SNARK proving especially for general-purpose computation can be expensive, potentially many thousands of times more expensive than running the computation directly) 더 높음(ZK-스나크증명은 비용이 많이 들 수 있으며 계산을 직접 실행하는보다 수천배 더 비쌀 수 있음)

 

In general, my own view is that in the short term, optimistic rollups are likely to win out for general-purpose EVM computation and ZK rollups are likely to win out for simple payments, exchange and other application-specific use cases, but in the medium to long term ZK rollups will win out in all use cases as ZK-SNARK technology improves.

 

일반적으로 내 견해로는 단기적으로 낙관적 롤업이 범용 EVM 계산에 유리할 가능성이 높고 ZK 롤업이 단순 결제, 교환 및 기타 애플리케이션별 사용 사례에 유리할 가능성이 높지만 중장기 ZK 롤업은 ZK-SNARK 기술이 향상됨에 따라 모든 사용 사례에서 승리할 것입니다.

 

Anatomy of a fraud proof

The security of an optimistic rollup depends on the idea that if someone publishes an invalid batch into the rollup, anyone else who was keeping up with the chain and detected the fraud can publish a fraud proof, proving to the contract that that batch is invalid and should be reverted.

 

사기 증거 분석

낙관적 롤업의 보안은 누군가가 유효하지 않은 배치를 롤업에 게시 하는 경우 체인을 유지하고 사기를 감지한 다른 사람이 사기 증거를 게시하여 계약에 해당 배치가 유효하지 않음을 증명할 수 있다는 생각에 달려 있습니다. 유효하지 않은 배치는 되돌려져야 합니다.

 

 

A fraud proof claiming that a batch was invalid would contain the data in green: the batch itself (which could be checked against a hash stored on chain) and the parts of the Merkle tree needed to prove just the specific accounts that were read and/or modified by the batch. The nodes in the tree in yellow can be reconstructed from the nodes in green and so do not need to be provided. This data is sufficient to execute the batch and compute the post-state root (note that this is exactly the same as how stateless clients verify individual blocks). If the computed post-state root and the provided post-state root in the batch are not the same, then the batch is fraudulent.

 

배치가 유효하지 않다고 주장하는 사기 증거에는 녹색 데이터가 포함됩니다. 배치 자체(체인에 저장된 해시와 비교하여 확인할 수 있음) 및 읽은 특정 계정을 증명하는 데 필요한 Merkle 트리의 일부 및/또는 또는 배치에 의해 수정됩니다. 노란색 트리의 노드는 녹색 노드에서 재구성할 수 있으므로 제공할 필요가 없습니다. 이 데이터는 배치를 실행하고 사후 상태 루트를 계산하는 데 충분합니다(이는 비상태 클라이언트가 개별 블록을 확인하는 방법과 정확히 동일함 ). 일괄 처리에서 계산된 사후 상태 루트와 제공된 사후 상태 루트가 동일하지 않으면 일괄 처리가 사기입니다.

 

It is guaranteed that if a batch was constructed incorrectly, and all previous batches were constructed correctly, then it is possible to create a fraud proof showing the the batch was constructed incorrectly. Note the claim about previous batches: if there was more than one invalid batch published to the rollup, then it is best to try to prove the earliest one invalid. It is also, of course, guaranteed that if a batch was constructed correctly, then it is never possible to create a fraud proof showing that the batch is invalid.

 

배치가 잘못 구성되었고 이전의 모든 배치가 올바르게 구성되었다면 배치가 잘못 구성되었음을 보여주는 사기 증거를 생성할 수 있습니다. 이전 배치에 대한 클레임에 유의해야한다. 롤업에 게시된 유효하지 않은 배치가 둘 이상인 경우 가장 오래된 배치가 유효하지 않음을 증명하는 것이 가장 좋습니다. 물론 배치가 올바르게 구성된 경우 배치가 유효하지 않음을 보여주는 사기 증거를 생성하는 것이 절대 불가능하다는 것도 보장됩니다.

 

How does compression work?

A simple Ethereum transaction (to send ETH) takes ~110 bytes. An ETH transfer on a rollup, however, takes only ~12 bytes:

 

압축은 어떻게 작동합니까?

(ETH를 보내기 위한) 간단한 이더리움 트랜잭션은 ~110바이트를 사용합니다. 그러나 롤업에서 ETH 전송은 ~12바이트만 사용합니다.

행 높이 조절

Parameter	Ethereum	Rollup
Nonce	~3	0
Gasprice	~8	0-0.5
Gas	3	0-0.5
To	21	4
Value	~9	~3
Signature	~68 (2 + 33 + 33)	~0.5
From	0 (recovered from sig)	4
Total	~112	~12

 

Part of this is simply superior encoding: Ethereum's RLP wastes 1 byte per value on the length of each value. But there are also some very clever compression tricks that are going on:

 

이것의 일부는 단순히 뛰어난 인코딩입니다. Ethereum의 RLP는 각 값의 길이에서 값당 1바이트를 낭비합니다. 그러나 다음과 같은 매우 영리한 압축 트릭도 있습니다.

 

• Nonce: the purpose of this parameter is to prevent replays. If the current nonce of an account is 5, the next transaction from that account must have nonce 5, but once the transaction is processed the nonce in the account will be incremented to 6 so the transaction cannot be processed again. In the rollup, we can omit the nonce entirely, because we just recover the nonce from the pre-state; if someone tries replaying a transaction with an earlier nonce, the signature would fail to verify, as the signature would be checked against data that contains the new higher nonce.

 

• Nonce : 이 매개변수의 목적은 재생을 방지하는 것입니다. 계정의 현재 nonce가 5인 경우 해당 계정의 다음 트랜잭션은 nonce 5를 가져야 하지만 트랜잭션이 처리되면 계정의 nonce는 6으로 증가하므로 트랜잭션을 다시 처리할 수 없습니다. 롤업에서 nonce를 완전히 생략할 수 있습니다. 이전 상태에서 nonce를 복구하기 때문입니다. 누군가가 더 이른 nonce로 트랜잭션을 재생하려고 하면 더 높은 nonce가 포함된 데이터에 대해 서명을 확인하기 때문에 서명이 확인되지 않습니다.

 

• Gasprice: we can allow users to pay with a fixed range of gasprices, eg. a choice of 16 consecutive powers of two. Alternatively, we could just have a fixed fee level in each batch, or even move gas payment outside the rollup protocol entirely and have transactors pay batch creators for inclusion through a channel.

 

• Gasprice : 우리는 사용자가 가스 프라이스의 고정된 범위로 지불하도록 허용할 수 있습니다. 2의 16 연속 거듭제곱 중에서 선택합니다. 또는 각 배치에서 고정 수수료 수준을 유지하거나 가스 지불을 롤업 프로토콜 외부로 완전히 이동하고 거래자가 채널을 통해 포함된 배치 생성자에게 비용을 지불하도록 할 수 있습니다.

 

• Gas: we could similarly restrict the total gas to a choice of consecutive powers of two. Alternatively, we could just have a gas limit only at the batch level.

 

• 가스 : 유사하게 전체 가스를 2의 연속 거듭제곱 중에서 선택하도록 제한할 수 있습니다. 또는 배치 수준에서만 가스 한도를 설정할 수 있습니다.

 

• To: we can replace the 20-byte address with an index (eg. if an address is the 4527th address added to the tree, we just use the index 4527 to refer to it. We would add a subtree to the state to store the mapping of indices to addresses).

 

• To : 20바이트 주소를 인덱스로 대체할 수 있습니다 ( 예: 주소가 트리에 추가된 4527번째 주소인 경우 인덱스 4527을 사용하여 참조합니다. 상태에 하위 트리를 추가하여 상태를 저장합니다. 인덱스를 주소에 매핑).

 

• Value: we can store value in scientific notation. In most cases, transfers only need 1-3 significant digits.

 

• 값 : 과학적 표기법으로 값을 저장할 수 있습니다. 대부분의 경우 전송에는 1-3개의 유효 숫자만 필요합니다.

 

• Signature: we can use BLS aggregate signatures, which allows many signatures to be aggregated into a single ~32-96 byte (depending on protocol) signature. This signature can then be checked against the entire set of messages and senders in a batch all at once. The ~0.5 in the table represents the fact that there is a limit on how many signatures can be combined in an aggregate that can be verified in a single block, and so large batches would need one signature per ~100 transactions.

 

• 서명 : BLS 집계 서명을 사용할 수 있습니다 . 이를 통해 많은 서명을 단일 ~32-96바이트(프로토콜에 따라 다름) 서명으로 집계할 수 있습니다. 그런 다음 이 서명을 한 번에 일괄적으로 전체 메시지 세트 및 발신자에 대해 확인할 수 있습니다. 표의 ~0.5는 단일 블록에서 검증할 수 있는 집계에서 결합할 수 있는 서명 수에 제한이 있다는 사실을 나타내며, 따라서 대규모 배치에는 ~100개 트랜잭션당 하나의 서명이 필요합니다.

 

 

One important compression trick that is specific to ZK rollups is that if a part of a transaction is only used for verification, and is not relevant to computing the state update, then that part can be left off-chain. This cannot be done in an optimistic rollup because that data would still need to be included on-chain in case it needs to be later checked in a fraud proof, whereas in a ZK rollup the SNARK proving correctness of the batch already proves that any data needed for verification was provided. An important example of this is privacy-preserving rollups: in an optimistic rollup the ~500 byte ZK-SNARK used for privacy in each transaction needs to go on chain, whereas in a ZK rollup the ZK-SNARK covering the entire batch already leaves no doubt that the "inner" ZK-SNARKs are valid.

 

ZK 롤업과 관련된 한 가지 중요한 압축 트릭은 트랜잭션의 일부가 확인에만 사용되고 상태 업데이트 컴퓨팅과 관련이 없는 경우 해당 부분을 오프체인으로 둘 수 있다는 것입니다. 옵티미스틱 롤업에서는 나중에 사기 증명을 확인해야 하는 경우 데이터를 온체인에 포함해야 하기 때문에 이는 수행할 수 없습니다. 반면 ZK 롤업에서는 배치의 정확성을 증명하는 SNARK가 이미 모든 데이터가 확인에 필요한 정보를 제공했습니다. 이에 대한 중요한 예는 개인 정보 보호 롤업입니다. 옵티미스틱 롤업에서 각 트랜잭션의 개인 정보 보호에 사용되는 ~500바이트 ZK-SNARK는 체인에 연결되어야 하는 반면 ZK 롤업에서는 전체 배치를 다루는 ZK-SNARK가 "내부" ZK-SNARK가 유효한지 의심의 여지가 없습니다.

 

These compression tricks are key to the scalability of rollups; without them, rollups would be perhaps only a ~10x improvement on the scalability of the base chain (though there are some specific computation-heavy applications where even simple rollups are powerful), whereas with

compression tricks the scaling factor can go over 100x for almost all applications.

 

이러한 압축 트릭은 롤업 확장성의 핵심입니다. 그것들이 없다면, 롤업은 기본 체인의 확장성에서 ~10배 정도 개선되었을 것입니다(간단한 롤업도 강력한 특정 연산 집약적 애플리케이션이 있기는 하지만). 압축 트릭을 사용하면 스케일링 계수가 거의 모든 응용 프로그램.

 

Who can submit a batch?

There are a number of schools of thought for who can submit a batch in an optimistic or ZK rollup. Generally, everyone agrees that in order to be able to submit a batch, a user must put down a large deposit; if that user ever submits a fraudulent batch (eg. with an invalid state root), that deposit would be part burned and part given as a reward to the fraud prover. But beyond that, there are many possibilities:

 

누가 배치를 제출할 수 있습니까?

옵티미스틱 롤업 또는 ZK 롤업에서 배치를 제출할 수 있는 사람에 대한 여러 학파가 있습니다. 일반적으로 배치를 제출하려면 사용자가 많은 보증금을 넣어야 한다는 데 모든 사람이 동의합니다. 해당 사용자가 사기성 배치(예: 유효하지 않은 상태 루트 포함)를 제출하는 경우 해당 예치금은 일부 소각되고 일부는 사기 증명자에게 보상으로 제공됩니다. 그러나 그 외에도 많은 가능성이 있습니다.

 

• Total anarchy: anyone can submit a batch at any time. This is the simplest approach, but it has some important drawbacks. Particularly, there is a risk that multiple participants will generate and attempt to submit batches in parallel, and only one of those batches can be successfully included. This leads to a large amount of wasted effort in generating proofs and/or wasted gas in publishing batches to chain.

 

• Total anarchy : 누구나 언제든지 배치를 제출할 수 있습니다. 이것은 가장 간단한 방법이지만 몇 가지 중요한 단점이 있습니다. 특히 여러 참가자가 일괄 처리를 생성하고 동시에 제출하려고 시도할 위험이 있으며 이러한 일괄 처리 중 하나만 성공적으로 포함될 수 있습니다. 이로 인해 증명을 생성하는 데 많은 노력이 낭비되거나 배치를 체인에 게시할 때 가스가 낭비됩니다.

 

• Centralized sequencer: there is a single actor, the sequencer, who can submit batches (with an exception for withdrawals: the usual technique is that a user can first submit a withdrawal request, and then if the sequencer does not process that withdrawal in the next batch, then the user can submit a single-operation batch themselves). This is the most "efficient", but it is reliant on a central actor for liveness.

 

• 중앙 집중식 시퀀서 : 배치를 제출할 수 있는 단일 액터인 시퀀서 가 있습니다 (인출 제외: 일반적인 기술은 사용자가 먼저 인출 요청을 제출한 다음 시퀀서가 다음 인출을 처리하지 않는 경우입니다. 그런 다음 사용자는 단일 작업 배치를 자체적으로 제출할 수 있습니다. 이것이 가장 "효율적"이지만, 생동감을 위한 중앙 액터에 의존합니다.

 

• Sequencer auction: an auction is held (eg. every day) to determine who has the right to be the sequencer for the next day. This technique has the advantage that it raises funds which could be distributed by eg. a DAO controlled by the rollup (see: MEV auctions)

 

• 시퀀서 경매 : 다음 날 시퀀서가 될 권리를 가진 사람을 결정하기 위해 경매가 열립니다(예: 매일). 이 기술은 예를 들어 분배할 수 있는 자금을 모으는 이점이 있습니다. 롤업에 의해 제어되는 DAO( MEV 경매 참조 )

 

• Random selection from PoS set: anyone can deposit ETH (or perhaps the rollup's own protocol token) into the rollup contract, and the sequencer of each batch is randomly selected from one of the depositors, with the probability of being selected being proportional to the amount deposited. The main drawback of this technique is that it leads to large amounts of needless capital lockup.

 

• PoS 세트에서 임의 선택 : 누구나 ETH(또는 롤업 자체 프로토콜 토큰)를 롤업 계약에 예치할 수 있으며 각 배치의 시퀀서는 예치자 중 한 명에서 무작위로 선택되며 선택 확률은 금액에 비례합니다. 입금. 이 기술의 주요 단점은 불필요한 자본 잠금이 대량으로 발생한다는 것입니다.

 

• DPoS voting: there is a single sequencer selected with an auction but if they perform poorly token holders can vote to kick them out and hold a new auction to replace them.

 

• DPoS 투표 : 경매를 통해 선택된 단일 시퀀서가 있지만 성능이 좋지 않은 경우 토큰 보유자는 투표를 통해 그들을 쫓아내고 새로운 경매를 개최하여 대체할 수 있습니다.

 

Split batching and state root provision

Some of the rollups being currently developed are using a "split batch" paradigm, where the action of submitting a batch of layer-2 transactions and the action of submitting a state root are done separately. This has some key advantages:

1. You can allow many sequencers in parallel to publish batches in order to improve censorship resistance, without worrying that some batches will be invalid because some other batch got included first.
2. If a state root is fraudulent, you don't need to revert the entire batch; you can revert just the state root, and wait for someone to provide a new state root for the same batch. This gives transaction senders a better guarantee that their transactions will not be reverted.

So all in all, there is a fairly complex zoo of techniques that are trying to balance between complicated tradeoffs involving efficiency, simplicity, censorship resistance and other goals. It's still too early to say which combination of these ideas works best; time will tell.

 

분할 일괄 처리 및 상태 루트 프로비저닝

현재 개발 중인 롤업 중 일부는 레이어2 트랜잭션 배치 제출 작업과 상태 루트 제출 작업이 별도로 수행되는 "분할 배치" 패러다임을 사용하고 있습니다. 여기에는 몇 가지 주요 이점이 있습니다.

1. 일부 다른 배치가 먼저 포함되어 일부 배치가 유효하지 않을 것이라는 걱정 없이 검열 저항을 개선하기 위해 많은 시퀀서가 배치를 게시하도록 병렬로 허용할 수 있습니다.
2. 상태 루트가 사기인 경우 전체 배치를 되돌릴 필요가 없습니다. 상태 루트만 되돌리고 누군가가 동일한 배치에 대해 새 상태 루트를 제공할 때까지 기다릴 수 있습니다. 이것은 거래 발신자에게 그들의 거래가 되돌려지지 않을 것이라는 더 나은 보증을 제공합니다.

따라서 대체로 효율성, 단순성, 검열 저항 및 기타 목표와 관련된 복잡한 트레이드 오프 사이에서 균형을 맞추려는 상당히 복잡한 기술 동물원이 있습니다. 이러한 아이디어의 어떤 조합이 가장 잘 작동하는지 말하기에는 아직 너무 이릅니다. 시간이 말해 줄 것이다.

 

How much scaling do rollups give you?

On the existing Ethereum chain, the gas limit is 12.5 million, and each byte of data in a transaction costs 16 gas. This means that if a block contains nothing but a single batch (we'll say a ZK rollup is used, spending 500k gas on proof verification), that batch can have (12 million / 16) = 750,000 bytes of data. As shown above, a rollup for ETH transfers requires only 12 bytes per user operation, meaning that the batch can contain up to 62,500 transactions. At an average block time of 13 seconds, this translates to ~4807 TPS (compared to 12.5 million / 21000 / 13 ~= 45 TPS for ETH transfers directly on Ethereum itself).

Here's a chart for some other example use cases:

 

롤업은 얼마나 많은 스케일링을 제공합니까?

기존 이더리움 체인에서 가스 한도는 1,250만 개이며 트랜잭션의 각 데이터 바이트 비용은 16개 가스입니다. 즉, 블록에 단일 배치만 포함된 경우(증명 검증에 50만 가스를 소비하는 ZK 롤업이 사용된다고 가정함) 해당 배치는 (1200만 / 16) = 750,000바이트의 데이터를 가질 수 있습니다. 위에 표시된 것처럼 ETH 전송을 위한 롤업에는 사용자 작업당 12바이트만 필요하므로 배치에 최대 62,500개의 트랜잭션이 포함될 수 있습니다. 13초의 평균 블록 시간에서 이것은 ~4807 TPS로 변환됩니다(이더리움 자체에서 직접 ETH 전송의 경우 1,250만/21000/13 ~= 45 TPS와 비교).

다음은 몇 가지 다른 사용 사례에 대한 차트입니다.

 

Application	Bytes in rollup	Gas cost on layer 1	Max scalability gain
ETH transfer	12	21,000	105x
ERC20 transfer	16 (4 more bytes to specify which token)	~50,000	187x
Uniswap trade	~14 (4 bytes sender + 4 bytes recipient + 3 bytes value + 1 byte max price + 1 byte misc)	~100,000	428x
Privacy-preserving withdrawal (Optimistic rollup)	296 (4 bytes index of root + 32 bytes nullifier + 4 bytes recipient + 256 bytes ZK-SNARK proof)	~380,000	77x
Privacy-preserving withdrawal (ZK rollup)	40 (4 bytes index of root + 32 bytes nullifier + 4 bytes recipient)	~380,000	570x

 

Max scalability gain is calculated as (L1 gas cost) / (bytes in rollup * 16) * 12 million / 12.5 million.

 

애플리케이션	롤업의 바이트	레이어 1의 가스 비용	최대 확장성 이득
ETH 전송	12	21,000	105배
ERC20 전송	16 (어떤 토큰을 지정하기 위한 추가 4바이트)	~50,000	187배
유니스왑 거래	~14 (발신자 4바이트 + 수신자 4바이트 + 값 3바이트 + 최대 가격 1바이트 + 기타 1바이트)	~100,000	428배
개인 정보 보호 철회(낙관적 롤업)	296 (루트의 4바이트 인덱스 + 32바이트 nullifier + 4바이트 수신자 + 256바이트 ZK-SNARK 증명)	~380,000	77배
개인 정보 보호 철회(ZK 롤업)	40 (루트의 4바이트 인덱스 + 32바이트 nullifier + 4바이트 수신자)	~380,000	570x

 

최대 확장성 이득은 (L1 가스 비용) / (롤업 바이트 * 16) * 1,200만 / 1,250만으로 계산됩니다.

 

 

Now, it is worth keeping in mind that these figures are overly optimistic for a few reasons. Most importantly, a block would almost never just contain one batch, at the very least because there are and will be multiple rollups. Second, deposits and withdrawals will continue to exist. Third, in the short term usage will be low, and so fixed costs will dominate. But even with these factors taken into account, scalability gains of over 100x are expected to be the norm.

 

이제 이러한 수치는 몇 가지 이유로 지나치게 낙관적이라는 점을 명심할 가치가 있습니다. 가장 중요한 것은 블록에 하나의 배치만 포함되는 경우가 거의 없다는 것입니다. 최소한 여러 롤업이 있고 앞으로도 있을 것이기 때문입니다. 둘째, 입출금은 계속해서 존재할 것입니다. 셋째, 단기적으로는 사용량이 적어 고정 비용이 지배적일 것입니다. 그러나 이러한 요소를 고려하더라도 100배 이상의 확장성 향상이 일반적일 것으로 예상됩니다.

 

Now what if we want to go above ~1000-4000 TPS (depending on the specific use case)? Here is where eth2 data sharding comes in. The sharding proposal opens up a space of 16 MB every 12 seconds that can be filled with any data, and the system guarantees consensus on the availability of that data. This data space can be used by rollups. This ~1398k bytes per sec is a 23x improvement on the ~60 kB/sec of the existing Ethereum chain, and in the longer term the data capacity is expected to grow even further. Hence, rollups that use eth2 sharded data can collectively process as much as ~100k TPS, and even more in the future.

 

이제 ~1000-4000 TPS 이상으로 가고 싶다면(특정 사용 사례에 따라 다름) 어떻게 해야 합니까? 여기에서 eth2 데이터 샤딩이 등장합니다. 샤딩 제안은 모든 데이터로 채워질 수 있는 12초마다 16MB의 공간을 열고 시스템은 해당 데이터의 가용성에 대한 합의를 보장합니다. 이 데이터 공간은 롤업에서 사용할 수 있습니다. 이 초당 ~1398k 바이트는 기존 이더리움 체인의 ~60kB/초에서 23배 개선된 것이며 장기적으로 데이터 용량은 더욱 증가할 것으로 예상됩니다. 따라서 eth2 샤드 데이터를 사용하는 롤업은 최대 100,000 TPS까지 집합적으로 처리할 수 있으며 향후에는 더 많이 처리할 수 있습니다.

 

What are some not-yet-fully-solved challenges in rollups?

While the basic concept of a rollup is now well-understood, we are quite certain that they are fundamentally feasible and secure, and multiple rollups have already been deployed to mainnet, there are still many areas of rollup design that have not been well explored, and quite a few challenges in fully bringing large parts of the Ethereum ecosystem onto rollups to take advantage of their scalability. Some key challenges include:

 

롤업에서 아직 완전히 해결되지 않은 문제는 무엇입니까?

롤업의 기본 개념은 이제 잘 이해되었지만 근본적으로 실현 가능하고 안전하며 여러 롤업이 이미 메인넷에 배포되었지만 여전히 잘 탐색되지 않은 롤업 디자인 영역이 많이 있습니다. 확장성을 활용하기 위해 이더리움 생태계의 많은 부분을 롤업으로 완전히 가져오는 데 있어 몇 가지 과제가 있습니다. 몇 가지 주요 과제는 다음과 같습니다.

 

• User and ecosystem onboarding - not many applications use rollups, rollups are unfamiliar to users, and few wallets have started integrating rollups. Merchants and charities do not yet accept them for payments.
• Cross-rollup transactions - efficiently moving assets and data (eg. oracle outputs) from one rollup into another without incurring the expense of going through the base layer.
• Auditing incentives - how to maximize the chance that at least one honest node actually will be fully verifying an optimistic rollup so they can publish a fraud proof if something goes wrong? For small-scale rollups (up to a few hundred TPS) this is not a significant issue and one can simply rely on altruism, but for larger-scale rollups more explicit reasoning about this is needed.
• Exploring the design space in between plasma and rollups - are there techniques that put some state-update-relevant data on chain but not all of it, and is there anything useful that could come out of that?
• Maximizing security of pre-confirmations - many rollups provide a notion of "pre-confirmation" for faster UX, where the sequencer immediately provides a promise that a transaction will be included in the next batch, and the sequencer's deposit is destroyed if they break their word. But the economy security of this scheme is limited, because of the possibility of making many promises to very many actors at the same time. Can this mechanism be improved?
• Improving speed of response to absent sequencers - if the sequencer of a rollup suddenly goes offline, it would be valuable to recover from that situation maximally quickly and cheaply, either quickly and cheaply mass-exiting to a different rollup or replacing the sequencer.
• Efficient ZK-VM - generating a ZK-SNARK proof that general-purpose EVM code (or some different VM that existing smart contracts can be compiled to) has been executed correctly and has a given result.

 

• 사용자 및 생태계 온보딩 - 롤업을 사용하는 애플리케이션이 많지 않고 롤업이 사용자에게 익숙하지 않으며 롤업 통합을 시작한 지갑이 거의 없습니다. 상인과 자선 단체는 아직 결제를 허용하지 않습니다.
• 교차 롤업 트랜잭션 - 기본 계층을 통과하는 비용을 발생시키지 않고 한 롤업에서 다른 롤업으로 자산 및 데이터(예: 오라클 출력)를 효율적으로 이동합니다.
• 감사 인센티브 - 적어도 하나의 정직한 노드가 실제로 낙관적 롤업을 완전히 검증하여 문제가 발생할 경우 사기 증거를 게시할 수 있는 기회를 최대화하는 방법은 무엇입니까? 소규모 롤업(최대 수백 TPS)의 경우 이는 중요한 문제가 아니며 단순히 이타주의에 의존할 수 있지만 대규모 롤업의 경우 이에 대한 더 명확한 추론이 필요합니다.
• 플라즈마와 롤업 사이의 설계 공간 탐색 - 일부 상태 업데이트 관련 데이터를 체인에 배치하지만 전부 는 아닌 기술이 있으며 , 그로부터 나올 수 있는 유용한 것이 있습니까?
• 사전 확인의 보안 극대화 - 많은 롤업은 더 빠른 UX를 위해 "사전 확인"이라는 개념을 제공합니다. 여기서 시퀀서는 트랜잭션이 다음 배치에 포함될 것이라는 약속을 즉시 제공하고 시퀀서의 예치금은 단어. 그러나 이 계획의 경제 안보는 제한적입니다. 왜냐하면 동시에 매우 많은 행위자에게 많은 약속을 할 수 있기 때문입니다. 이 메커니즘을 개선할 수 있습니까?
• 부재 시퀀서에 대한 응답 속도 향상 - 롤업의 시퀀서가 갑자기 오프라인 상태가 되면 다른 롤업으로 빠르고 저렴하게 대량 종료하거나 시퀀서를 교체하여 해당 상황에서 최대한 빠르고 저렴하게 복구하는 것이 중요합니다.
• 효율적인 ZK-VM - 범용 EVM 코드(또는 기존 스마트 계약을 컴파일할 수 있는 일부 다른 VM)가 올바르게 실행되었고 주어진 결과가 있다는 ZK-SNARK 증명을 생성합니다.

 

 

 

Conclusions

Rollups are a powerful new layer-2 scaling paradigm, and are expected to be a cornerstone of Ethereum scaling in the short and medium-term future (and possibly long-term as well). They have seen a large amount of excitement from the Ethereum community because unlike previous attempts at layer-2 scaling, they can support general-purpose EVM code, allowing existing applications to easily migrate over. They do this by making a key compromise: not trying to go fully off-chain, but instead leaving a small amount of data per transaction on-chain.

There are many kinds of rollups, and many choices in the design space: one can have an optimistic rollup using fraud proofs, or a ZK rollup using validity proofs (aka. ZK-SNARKs). The sequencer (the user that can publish transaction batches to chain) can be either a centralized actor, or a free-for-all, or many other choices in between. Rollups are still an early-stage technology, and development is continuing rapidly, but they work and some (notably Loopring, ZKSync and DeversiFi) have already been running for months. Expect much more exciting work to come out of the rollup space in the years to come.

 

결론

롤업은 강력한 새로운 레이어2 확장 패러다임이며 단기 및 중기 미래(및 장기적으로도 가능)에서 이더리움 확장의 초석이 될 것으로 예상됩니다. 이전의 레이어 2 확장 시도와 달리 범용 EVM 코드를 지원하여 기존 애플리케이션을 쉽게 마이그레이션할 수 있기 때문에 Ethereum 커뮤니티에서 많은 관심을 보였습니다. 그들은 키 타협을 통해 이를 수행합니다. 즉, 완전히 오프체인으로 전환하려고 시도하지 않고 트랜잭션당 소량의 데이터를 온체인에 남겨둡니다.

설계 공간에는 많은 종류의 롤업과 다양한 선택이 있습니다. 하나는 사기 증명을 사용하는 옵티미스틱 롤업 또는 유효성 증명(일명 ZK-SNARK)을 사용하는 ZK 롤업을 가질 수 있습니다. 시퀀서(트랜잭션 일괄 처리를 체인에 게시할 수 있는 사용자)는 중앙 집중식 액터이거나 모두 무료이거나 그 사이에 있는 다른 많은 선택이 될 수 있습니다. 롤업은 아직 초기 단계 기술이며 개발이 빠르게 계속되고 있지만 작동하며 일부(특히 Loopring , ZKSync 및 DeversiFi )는 이미 몇 달 동안 실행되었습니다. 앞으로 몇 년 동안 롤업 공간에서 나올 훨씬 더 흥미로운 작업을 기대하십시오.