전 아비트럼 기술 홍보대사가 아비트럼의 구성 요소 구조를 설명합니다(위).

저자: 베니 루오, 전 아비트럼 기술 홍보대사 및 긱 웹3 기여자

이 글은 전 아비트럼 기술 홍보대사이자 스마트 컨트랙트 자동 감사 회사인 Goplus Security의 공동 창업자인 베니 루오가 아비트럼 원에 대한 기술적 설명을 작성한 글입니다.

중국 커뮤니티에는 레이어 2에 대한 전문적인 이해를 돕는 기사나 정보가 부족하기 때문에, 이 글에서는 아비트럼의 작동 메커니즘을 설명함으로써 이 분야의 공백을 메우고자 합니다. 아비트럼의 구조가 복잡하기 때문에 전체글은 최대한 단순화했지만, 여전히 1만 단어가 넘는 분량이므로 두 부분으로 나누어 전달 참고 자료로 활용하시길 권장합니다!

롤업 소터 요약

롤업 확장의 원리는 다음과 같이 요약할 수 있습니다.

비용 최적화 :계산 및 저장 작업의 대부분을 L1 체인, 즉 L2로 이전합니다. L2는 대부분 단일 서버인 시퀀서/운영자에서 실행되는 체인입니다.

시퀀서는 외형상 중앙화된 서버에 가깝기 때문에 "트리플 코어"가 아닌 블록체인의 TPS와 비용 이점을 위해 "탈중앙화"를 포기합니다.

; 사용자는 이더 대신 L2를 사용하여 이더로 거래하는 것보다 훨씬 저렴한 비용으로 거래 주문을 처리할 수 있습니다.

(출처: BNB. Chain)

보안: L2에서 트랜잭션의 내용과 트랜잭션 후 상태는 이더 L1에 동기화되며, 상태 전환의 유효성은 컨트랙트에 의해 검증됩니다. 동시에 L2의 기록은 이더에 보관되므로 시퀀서가 영구적으로 다운되더라도 이더의 기록을 통해 전체 L2 상태를 복원할 수 있습니다.

기본적으로 롤업의 보안은 이더를 기반으로 합니다. 시퀀서는 계정의 개인 키를 알지 못하면 해당 계정 명의로 트랜잭션을 시작할 수 없으며, 해당 계정의 자산 잔액을 조작할 수도 없습니다(설령 조작하더라도 금방 발견될 것입니다).

시스템의 허브로서 시퀀서는 심장의 역할을 하지만, 보다 성숙한 롤업 시나리오에서는 중앙화된 시퀀서가 거래 검열이나 악의적인 다운타임과 같은 가벼운 악행만 저지를 수 있지만, 이상적인 롤업 시나리오에서는 이를 억제하는 적절한 매뉴얼(예: 강제 인출 또는 시퀀스 증명과 같은 검열 방지 메커니즘)이 있습니다.

(L1의 로드마크 프로토콜) ">(사용자가 호출할 수 있도록 L1의 컨트랙트 소스 코드에 로드마크 프로토콜이 설정한 강제 출금 기능)

그리고 롤업 시퀀서의 악의적 행위를 방지하기 위한 상태 검증 방식은 Fraud Proof와 Validity Proof로 구분할 수 있습니다. 부정 증명 방식을 사용하는 롤업 방식을 OP 롤업(Optimistic Rollup, OPR)이라고 하며, 유효성 증명 방식을 사용하는 롤업은 몇 가지 역사적 부담으로 인해 유효성 증명 롤업이 아닌 ZK 롤업(Zero-knowledge Proof Rollup, ZKR)이라고 부르기도 합니다. 롤업.

아비트럼 원은 L1에 콘트랙트를 배포하고 제출된 데이터를 적극적으로 검증하지 않으며, 낙관적으로 정상이라고 가정하는 전형적인 OPR입니다. 제출된 데이터에 오류가 있는 경우 L2의 검증자 노드가 적극적으로 이의를 제기합니다.

따라서 OPR에는 암묵적인 신뢰 가정이 존재합니다. 주어진 순간에 적어도 하나의 정직한 L2 검증자 노드가 존재한다는 것입니다. 대신, ZKR의 컨트랙트는 암호화 계산을 통해 시퀀서가 제출한 데이터를 적극적이면서도 저렴하게 검증합니다.

(낙관적) 롤업 모드)

(ZK 롤업 동작)

이 글에서는 옵티미스틱 롤업의 대표 아이템인 아비트럼 원에 대해 전체 시스템의 모든 측면에 대해 자세히 소개합니다. 옵티미스틱 롤업/OPR.

아비트럼의 핵심 구성 요소와 워크플로우

핵심 컨트랙트:

아비트럼의 가장 중요한 컨트랙트에는 < strong>SequencerInbox, DelayedInbox, L1 게이트웨이, L2 게이트웨이, 아웃박스, 롤업코어, 브리지 등이 있습니다. 자세한 내용은 다음에 설명합니다.

Sequencer:

사용자 트랜잭션을 수신하여 정렬하고 결과를 계산하여 사용자에게 빠르게 반환합니다(보통 <1초). 사용자는 종종 몇 초 내에 L2에서 업링크된 트랜잭션을 볼 수 있으며, 그 경험은 웹2 플랫폼과 매우 유사합니다.

또한 시퀀서는 최신 생성된 L2 블록을 이더 체인 아래로 즉시 브로드캐스트하며, 모든 레이어2 노드는 이를 비동기적으로 수신할 수 있습니다. 그러나 이 시점에서 이러한 L2 블록은 최종성을 가지지 않으며 시퀀서에 의해 롤백될 수 있습니다.

몇 분마다 시퀀서는 데이터 가용성과 롤업 프로토콜의 작동을 보장하기 위해 정렬된 L2 트랜잭션 데이터를 일괄적으로 압축하여 집계한 후 Layer1의 컨트랙트인 SequencerInbox에 제출합니다. 롤업 프로토콜의 작동을 보장합니다. 일반적으로 Layer1에 제출된 L2 데이터는 롤백할 수 없으며 최종성을 가질 수 있습니다.

위 과정을 요약하면, Layer2는 자체 노드 네트워크를 가지고 있지만, 노드 수가 적고 퍼블릭 체인에서 일반적으로 사용하는 합의 프로토콜을 가지고 있지 않아 보안이 취약합니다. Layer2는 자체 노드 네트워크를 가지고 있지만, 노드 수가 적고 일반적으로 퍼블릭 체인에서 사용하는 합의 프로토콜이 없기 때문에 보안이 매우 취약하며, 데이터 릴리스의 신뢰성과 상태 전환의 효율성을 보장하기 위해 이더에 의존해야 합니다.

아비트럼 롤업 프로토콜:

롤업 체인의 RB블록 구조, 체인 지속, RB블록 해제, 챌린지 모드 프로세스를 정의하는 일련의 컨트랙트입니다. 계약. 이 맥락에서 롤업 체인은 레이어2 원장이 아니라 Arbitrum One이 사기 증명 메커니즘을 구현하기 위해 독립적으로 설정한 추상화된 "체인 데이터 구조"임을 유의하십시오.

RBlock은 매우 다른 데이터를 가진 여러 레이어2 블록의 결과를 포함할 수 있으며, 그 데이터 엔티티인 RBlock은 일련의 롤업코어 컨트랙트에 저장됩니다. RBlock에 문제가 있는 경우 검증자는 RBlock을 제출한 사람에게 이의를 제기합니다.

검증자:

아비트럼의 검증자 노드는 사실 현재 화이트리스트에 있는 레이어2 전체 노드의 특수한 하위 집합입니다.

검증자는 시퀀서가 시퀀서인박스 컨트랙트에 제출한 트랜잭션의 일괄 배치를 기반으로 새로운 RBlock을 생성합니다( 롤업 블록, ⾔어설션이라고도 함)을 생성하고, 롤업 체인의 현재 상태를 모니터링하여 시퀀서가 제출한 오류 데이터에 이의를 제기합니다.

스테이크어라고도 하는 활성 검증자는 사전에 이더리움 체인에 자산을 위임해야 하며, 위임하지 않은 레이어 2 노드는 롤업의 작동을 모니터링하고 사용자에게 경고를 보낼 수 있지만, 시퀀서가 제출한 오류 데이터에 직접 개입할 수는 없습니다. 그러나 시퀀서가 제출한 오류 데이터에 대한 응답으로 이더 체인에 직접 개입할 수는 없습니다.

문제:

기본 단계는 다중 라운드, 대화형, 단일 단계 증명으로 요약할 수 있습니다. 세분화 및 단일 단계 증명. 세분화 세션에서 챌린지 파트너는 먼저 문제가 있는 트랜잭션 데이터에 대해 여러 차례의 턴 기반 세분화를 수행하여 연산자 명령의 문제가 있는 단계를 분석하고 검증합니다. 이러한 "다중 라운드 세그멘테이션 - 단일 단계 증명" 패러다임은 아비트럼 개발자들이 가스 효율이 가장 높은 사기 증명 구현으로 간주하는 방식입니다. 모든 세그먼트는 계약상 통제 하에 있으며, 어떤 당사자도 속일 수 없습니다.

도전 기간:

OP 롤업의 낙관적인 특성으로 인해 컨트랙트는 각 R블록이 체인에 제출된 후 적극적으로 확인하지 않기 때문에 검증자에게 위조할 수 있는 시간을 남겨둡니다. 이 기간을 챌린지 기간이라고 하며, Arbitrum One 그리드에서 챌린지 기간은 1주일입니다. 챌린지 기간이 끝나면 RBlock이 최종적으로 검증되고, L2에서 L1으로 전달된 블록의 해당 메시지(예: 공식 브리지를 통해 수행된 출금)가 해제됩니다.

ArbOS, Geth, WAVM:

아비트럼은 Geth와 ArbOS로 구성된 AVM이라는 가상 머신을 사용합니다. Geth는 이더리움에서 가장 일반적으로 사용되는 클라이언트 소프트웨어이며, Arbitrum은 이를 가볍게 수정했습니다. ArbOS는 네트워크 리소스 관리, L2 블록 생성, EVM 작업과 같은 모든 L2 관련 기능을 담당합니다. 이 두 가지의 조합을 Arbitrum에서 사용하는 가상 머신인 네이티브 AVM과 AVM 코드를 Wasm으로 컴파일한 결과물인 WAVM으로 간주합니다. WAVM은 AVM 코드를 Wasm으로 컴파일한 결과물입니다. 아비트럼 챌린지 프로세스의 최종 "단일 단계 증명"은 WAVM 명령어를 검증합니다.

위 구성 요소와 워크플로우 간의 관계를 다음 다이어그램으로 나타낼 수 있습니다:

L2. 트랜잭션 수명 주기

L2 트랜잭션은 다음과 같이 처리됩니다.

1. 사용자가 트랜잭션 명령을 시퀀서에 보냅니다.

2. 시퀀서는 먼저 보류 중인 트랜잭션을 디지털 서명 및 기타 데이터로 검증하고, 유효하지 않은 트랜잭션을 제거하며, 정렬 및 연산을 수행합니다.

3. 시퀀서는 사용자에게 트랜잭션 승인을 전송합니다(일반적으로 매우 빠름). 그러나 이는 시퀀서에 의한 이더리움 체인의 "사전 처리"일 뿐이며, 이는 소프트 파이널리티 상태에 있으며 신뢰할 수 없습니다. 이는 소프트 파이널리티 상태에 있으며 신뢰할 수 없습니다. 그러나 시퀀서를 신뢰하는 사용자(대부분의 사용자)는 트랜잭션이 완료되었으며 롤백되지 않을 것이라고 낙관할 수 있습니다.

4. 시퀀서는 사전 처리된 트랜잭션에서 원시 데이터를 가져와서 고도로 압축한 다음 일괄 처리로 캡슐화합니다.

5.일주일에 한 번씩(데이터 양, 이더리움 혼잡도 등에 따라) 시퀀서는 트랜잭션 배치를 L1의 시퀀서 받은 편지함 컨트랙트에 릴리스합니다. 이 시점에서 트랜잭션은 하드 파이널리티를 가진 것으로 간주됩니다. 하드 파이널리티.

시퀀서 받은 편지함 컨트랙트

컨트랙트는 시퀀서가 제출한 트랜잭션 일괄 처리를 수신하여 데이터 가용성을 보장합니다. 좀 더 자세히 살펴보면, 시퀀서인박스의 배치 데이터는 Layer2의 트랜잭션 입력에 대한 완전한 기록을 유지하며, 시퀀서가 영구적으로 다운되더라도 누구나 배치 기록을 기반으로 Layer2의 현재 상태를 복원하고 장애/가동 중단된 시퀀서를 인수할 수 있습니다.

물리적으로 보면 우리가 Layer2로 보는 것은 SequencerInbox에 있는 배치의 투영일 뿐이며 광원은 STF입니다. 광원인 STF는 쉽게 변하지 않으므로 그림자의 모양은 오브젝트 역할을 하는 배치에 의해서만 결정됩니다.

시퀀서 받은 편지함 컨트랙트는 패스트박스라고 하며, 이미 전처리된 트랜잭션을 시퀀서가 독점적으로 제출하고 시퀀서만 데이터를 제출할 수 있습니다. 패스트 박스에 대응하는 느린 박스는 지연받은 편지함이며, 그 기능은 다음 흐름에서 설명합니다.

검증자는 항상 시퀀서인박스 컨트랙트를 수신 대기하며, 시퀀서가 해당 컨트랙트에 배치를 게시할 때마다 온체인 이벤트가 발생하고, 검증자는 이 이벤트 발생을 수신 대기하면 배치 데이터를 다운로드하여 로컬에서 실행한 후 이더 체인으로 전송합니다.

아비트럼의 브리지 컨트랙트에는 누산기라는 매개변수가 있는데, 이는 제출된 새로운 L2 배치와 느린 Inbox에 대한 매개변수입니다. 배치뿐만 아니라 느린 받은 편지함에서 수신된 새로운 트랜잭션과 메시지의 수를 나타냅니다.

(시퀀서가 시퀀서인박스에 배치를 계속 제출함)

(배치 관련 정보, 데이터 필드는 배치 데이터에 해당, 이 부분은 데이터 크기가 매우 커서 스크린샷에 모두 표시되지 않음)

SequencerInbox 컨트랙트에는 두 가지 주요 함수가 있습니다.

추가 시퀀서 L2Batch From Origin(), 이 함수는 시퀀서가 매번 호출하여 배치 데이터를 시퀀서 이녹스 컨트랙트에 제출합니다.

force Inclusion(), 이 함수는 검열 저항 트랜잭션을 구현하기 위해 누구나 호출할 수 있습니다. 이 함수가 작동하는 방식은 나중에 지연된 받은 편지함 컨트랙트에 대해 설명할 때 자세히 설명하겠습니다.

이 두 함수는 브리지 컨트랙트 내에서 누산기 매개변수 accumulator를 업데이트하기 위해 bridge.enqueueSequencerMessage()를 호출합니다.

가스 프라이싱

이러한 L2 트랜잭션은 DoS 공격을 받을 수 있고, 시퀀서 L2 자체를 실행하는 비용과 L1에서 데이터를 제출하는 오버헤드도 있기 때문에 무료가 될 수 없습니다. 사용자가 레이어 2 네트워크 내에서 트랜잭션을 시작할 때, 가스비는 다음과 같이 구조화됩니다. 가스비는 주로 시퀀서가 제출하는 배치(각 배치에는 많은 사용자 트랜잭션이 있습니다. 많은 사용자 트랜잭션)에서 발생하며, 비용은 궁극적으로 트랜잭션 개시자 간에 균등하게 분담됩니다. 데이터 퍼블리싱에 발생하는 수수료의 가격 책정 알고리즘은 동적이며, 시퀀서는 최근 손익, 배치 크기, 현재 이더리움 가스 가격을 기준으로 가격을 책정합니다.

사용자가 레이어 2 리소스에 대해 부담하는 비용은 시스템을 안정적으로 운영하기 위해 초당 처리되는 최대 가스 양(현재 Arbitrum One의 경우 700만)으로 제한되며, L1 및 L2 가스 가이드 라인 가격은 ArbOS에서 추적하고 조정하며 공식은 현재로서는 여기에 설명되어 있지 않습니다. 여기서는 반복하지 않겠습니다.

특정 가스 가격을 계산하는 과정은 비교적 복잡하지만, 사용자는 이러한 세부 사항을 알 필요가 없으며, 롤업 거래 수수료가 이더리움 메인넷보다 훨씬 저렴하다는 것을 분명히 느낄 수 있습니다.

낙관적 사기 증명

위에서 다시 상기해보면, L2는 실제로 패스트박스에서 시퀀서가 제출한 트랜잭션 입력의 배치에 대한 투영일 뿐이며, 즉

Transaction 입력 -> STF -> 상태 출력. 입력이 이미 결정되고 STF가 일정하면 출력도 결정되고, 그리고 사기 증명 시스템과 Arbitrum Rollup 프로토콜은 출력의 상태 루트를 가져와서 L1에 RBlock (일명 어설션)으로 게시하고 다음을 수행하는 시스템입니다. 낙관적 증명을 위한 일련의 시스템입니다.

L1에는 시퀀서가 게시한 입력 데이터와 검증자가 게시한 출력 상태가 있습니다. 레이어2의 상태를 체인에 게시할 필요가 있는지 좀 더 신중하게 생각해 봅시다.

입력이 이미 출력을 완전히 결정하고 입력 데이터도 공개되어 있는데 출력 결과 상태를 다시 제출하는 것은 불필요한 것 같지 않나요? 그러나 이 생각은 실제로 두 시스템 L1-L2 간에 상태가 정산될 필요가 있다는 사실, 즉 L2가 L1에 대한 인출을 수행하려면 상태 증명이 필요하다는 사실을 무시하고 있습니다.

;

롤업을 구축할 때 가장 신중하게 고려한 사항 중 하나는 L1의 높은 비용을 피하기 위해 대부분의 연산과 스토리지를 L2에 두는 것이었는데, 이는 L1이 L2의 상태를 알지 못한다는 의미이며, L2 시퀀서가 모든 거래에 입력을 게시하는 것을 도울 뿐 L2의 상태를 파악할 책임이 없다는 것을 의미합니다.

L1에서 자금을 인출하는 것은 본질적으로 L2의 크로스체인 메시지에 따라 L1의 컨트랙트에서 자금을 잠금 해제하고, 사용자의 L1 계정으로 이체하거나 다른 작업을 수행하는 것입니다.

이 시점에서 레이어1 컨트랙트는 다음과 같이 질문합니다: 레이어2에서 귀하의 상태는 어떠한가, 그리고 귀하가 크로스체인을 선언한 자산을 실제로 소유하고 있다는 것을 어떻게 증명할 것인가? 이 때 사용자는 해당 머클 증명 등을 제공해야 합니다.

따라서 인출이 없는 롤업을 구축한다면, 이론적으로 L1에 상태가 없는 롤업을 구축하는 것입니다. 이론적으로는 L1에 대한 상태 동기화를 수행하지 않고도 현금 인출 기능이 없는 롤업을 구축할 수 있으며, 사기 증명과 같은 상태 증명 시스템이 필요하지 않습니다(다른 문제를 일으킬 수 있지만). 그러나 실제 사용 환경에서는 이것이 불가능합니다.

소위 낙관적 증명에서는 컨트랙트가 L1에 제출된 출력 상태가 올바른지 확인하지 않고 모든 것이 정확하다고 낙관적으로 가정합니다. 낙관적 증명 시스템은 특정 시점에 정직한 검증자가 한 명 이상 존재한다고 가정하며, 잘못된 상태가 있을 경우 부정 증명에 의해 이의를 제기합니다.

이 설계의 장점은 L1에 게시된 모든 R블록을 사전에 검증할 필요가 없어 가스 낭비를 피할 수 있다는 점이며, 실제로 각 R블록에는 하나 이상의 L2 블록이 포함되어 있기 때문에 OPR이 모든 언어를 검증하는 것은 비현실적이며, 각 R블록에 하나 이상의 L2 블록이 포함되어 있기 때문에 L1에서 모든 트랜잭션을 재실행하는 것보다 훨씬 더 어렵다는 점입니다. L1에서 각 트랜잭션을 다시 실행하는 것은 L2 트랜잭션을 L1에서 직접 실행하는 것과 같으며, 이는 레이어2 확장의 목적에 어긋납니다.

이것은 ZKR에서 문제가 되지 않는데, 그 이유는 ZK 증명은 해당 증명 뒤에 있는 많은 트랜잭션을 실제로 실행하지 않고도 아주 작은 증명을 검증할 수 있는 단순성을 가지고 있기 때문입니다. 따라서 ZKR은 낙관적으로 운영되지 않으며, 스테이트가 게시될 때마다 수학적으로 검증됩니다.

부정 증명은 영지식 증명만큼 단순하지는 않지만, 아리트럼은 순환적인 "다회전 분할-단일 단계 증명" 상호작용 프로세스를 사용하여 상대적으로 적은 비용으로 단일 VM 연산 코드를 증명할 수 있습니다. 비용이 상대적으로 적게 듭니다.

롤업 프로토콜

챌린지를 시작하고 증명을 시작하기 위한 진입점인 롤업 프로토콜이 어떻게 작동하는지부터 살펴봅시다.

롤업 프로토콜의 핵심 컨트랙트는 롤업프록시.sol이며, 데이터 구조를 일관되게 유지하면서 드물게 이중 프록시 구조를 사용하는데, 하나의 프록시가 두 개의 구현 롤업유저로직.sol과 현재 Scan과 같은 도구에서는 잘 해결되지 않습니다.

또한 챌린지를 관리하기 위한 ChallengeManager.sol 컨트랙트와 부정 행위의 증거를 확인하기 위한 OneStepProver 컨트랙트 제품군도 있습니다.

(출처: L2BEAT 웹사이트)

롤업프록시에서는 서로 다른 검증자가 제출한 일련의 R블록(일명 어설션)을 기록합니다(아래 이미지의 사각형): 녹색-확인, 파란색-확인되지 않음. , 노란색 - 위조됨.

RBlock은 마지막 RBlock 이후 실행 후 하나 이상의 L2 블록의 최종 상태를 포함합니다. . 이러한 R블록은 공식적인 롤업 체인을 형성합니다(L2 원장 자체는 별개임에 유의하세요). 낙관적인 시나리오에서 이 롤업 체인에는 포크가 없어야 하는데, 포크가 있다는 것은 검증자가 서로 충돌하는 롤업 블록을 제출했음을 의미하기 때문입니다.

어설션을 생성하거나 동의하려면 검증자가 먼저 해당 어설션에 대해 일정량의 이더를 스테이킹하여 스테이커가 되어야 합니다. 이렇게 하면 부정 증명에 대한 도전이 발생하거나 사기성 증명이 발생할 경우, 패자의 지분은 몰수되며, 이는 검증자의 정직한 행동을 보호하는 경제적 기반이 됩니다.

도표의 오른쪽 아래 모서리에 있는 파란색 블록 111은 부모 블록(104)이 잘못되었기 때문에 결국 위조될 것입니다(노란색).

또한, 검증자 A는 롤업 블록 #106을 제안하지만, B는 이에 동의하지 않고 이의를 제기합니다.

B가 챌린지를 시작한 후 챌린지 매니저 컨트랙트는 챌린지 단계의 세분화 과정을 검증할 책임이 있습니다. :

1. 세그멘테이션은 두 당사자가 교대로 상호 작용하는 프로세스로, 한 당사자가 특정 롤업 블록에 포함된 기록 데이터를 세그멘테이션하고 다른 당사자가 데이터 조각의 어느 부분에 문제가 있는지 지적하는 것입니다. 이분화(실제로는 N/K)와 유사하게 범위를 지속적으로 점진적으로 좁혀나가는 과정입니다.

2. 그런 다음 계속해서 어떤 트랜잭션과 결과에 문제가 있는지 찾아낸 다음 해당 트랜잭션에서 문제가 되는 특정 머신 명령어로 더 세분화할 수 있습니다.

3. 챌린지 매니저 컨트랙트는 원본 데이터의 세분화 결과인 '데이터 스니펫'의 유효성만 확인합니다.

4. 챌린저와 피 챌린저가 챌린지할 머신 명령어 조각을 찾으면 챌린저는 oneStepProveExecution()을 호출하고 이 머신 명령어의 문제가 있는 실행 결과에 대한 1단계 사기 증명을 전송합니다.

1단계 증명

1단계 증명은 전체 아비트럼의 사기 증명의 핵심입니다. 원스텝 증명이 정확히 무엇을 증명하는지 살펴보겠습니다.

이를 위해서는 먼저 ArbOS 모듈과 Geth(이더 클라이언트) 코어 모듈로 컴파일된 가상 머신인 WAVM, Wasm Arbitrum 가상 머신에 대한 이해가 필요합니다. L2는 여러 가지 면에서 L1과 매우 다르기 때문에 원래의 Geth 코어를 약간 수정하여 ArbOS와 함께 작동하도록 해야 했습니다.

따라서 L2의 상태 전환은 실제로 ArbOS + Geth 코어의 공동 작업입니다.

아비트럼의 노드 클라이언트(시퀀서, 검증인, 풀 노드 등)는. 는 위의 ArbOS+Geth Core가 처리하는 프로그램을 노드 호스트가 직접 처리할 수 있는 네이티브 머신코드(x86/ARM/PC/Mac 등용)로 컴파일하는 것입니다.

컴파일 후 얻은 타겟 언어를 Wasm으로 변경하면 검증자가 부정 증명을 생성하는 데 사용하는 WAVM을 얻게 되고, 단일 단계 증명을 검증하는 것은 컨트랙트 상에서 시뮬레이션되는 WAVM VM의 기능입니다.

그렇다면 왜 사기 증명을 생성할 때 Wasm 바이트코드로 컴파일해야 하나요? 주로 단일 단계 부정 증명을 검증하는 컨트랙트가 테라플롭 스마트 컨트랙트로 특정 명령어 집합을 처리할 수 있는 가상 머신을 에뮬레이션해야 하는데, WASM은 컨트랙트에서 에뮬레이션을 구현하기 쉽기 때문입니다.

그러나 WASM은 네이티브 머신 코드에 비해 약간 느리기 때문에, 아비트럼의 노드/컨트랙트가 WAVM을 사용하는 유일한 경우는 사기 증명 생성 및 검증에 한합니다. 컨트랙트는 WAVM만 사용합니다.

여러 차례의 이전 대화형 고장 후, 단일 단계 증명은 결국 WAVM 명령어 세트의 단일 단계 명령어를 증명하는 것으로 끝납니다.

아래 코드에서 볼 수 있듯이, 원스텝프로프엔트리는 먼저 증명할 명령어의 옵코드가 어느 클래스에 속하는지 확인한 다음 Mem, Math 등과 같은 해당 증명자를 호출하여 단일 단계 명령어를 해당 증명자 계약으로 전달합니다.

애프터해시의 최종 결과는 챌린지매니저로 돌아오며, 해당 해시가 롤업 블록에 기록된 것과 일치하지 않으면 인스트럭션이 실패합니다. 연산 후에도 해시가 롤업 블록에 기록된 해시와 일치하지 않으면 챌린지는 성공한 것입니다. 일치하면 롤업 블록에 기록된 명령의 결과가 정상이며 챌린지는 실패합니다.

다음 포스트에서는 아비트럼과 레이어2와 레이어1 간의 크로스체인 메시징/브리징을 처리하는 컨트랙트 모듈을 분석하고, 진정한 레이어2가 어떻게 작동해야 하는지에 대해 더 자세히 알아보도록 하겠습니다. 검열에 저항하기 위해 레이어2가 어떻게 구현되어야 하는지에 대한 진정한 의미입니다.