Bedrock 이해하기: Optimism의 Rollup 생태계에 대한 첫 번째 단계

원문 제목：《Bedrock Explainer》

작성자：Optimism 공식

편집：Frank, Foresight News

Bedrock는 OP Stack의 역사상 첫 번째 공식 버전의 이름으로, Optimism의 발전을 위한 무료 및 오픈 소스 모듈형 구성 요소 집합으로 설계되었습니다.

개선 요약

Bedrock는 이전 버전을 기반으로 개선되었으며, 주요 내용은 다음과 같습니다:

• 최적화된 배치 거래 압축을 사용하고 이더리움을 데이터 가용성 계층으로 활용하여 거래 비용을 낮춤;
• L1 재구성을 더 잘 처리하여 L1 거래를 롤업에 패키징하는 지연 시간을 단축함;
• 코드 재사용을 통해 모듈화된 증명 시스템을 가능하게 함;
• 설계 부채를 제거하여 노드 성능을 향상시킴.

더 낮은 비용

Bedrock는 데이터 비용을 최소화하기 위해 최적화된 데이터 압축 전략을 사용합니다. 현재 이 변화의 영향을 기준으로 테스트하고 있지만, 비용이 크게 줄어들 것으로 예상합니다.

Bedrock는 또한 L1에 데이터를 제출할 때 EVM 실행과 관련된 모든 가스 비용을 제거하여 이전 버전의 프로토콜에 비해 추가로 10%의 비용을 절감할 것입니다.

더 짧은 입금 처리 시간

Bedrock는 노드 소프트웨어에 L1 재구성 지원을 도입하여 사용자가 입금 처리를 기다리는 시간을 크게 줄였습니다.

이 프로토콜의 초기 버전은 입금 처리를 확인하는 데 최대 10분이 걸릴 수 있었으나, Bedrock를 사용하면 입금이 3분 이내에 확인될 것으로 예상합니다.

개선된 모듈화 증명

Bedrock는 OP Stack에서 증명 시스템을 추상화하여 롤업이 롤업에서 입력 후 올바른 실행을 증명하기 위해 장애 증명 또는 유효성 증명(예: zk-SNARK)을 사용할 수 있도록 하며, 이 추상화는 시스템 내의 장애를 증명하기 위해 Cannon을 사용할 수 있게 합니다.

개선된 노드 성능

단일 롤업 "블록" 내에서 여러 거래를 실행함으로써 이전 버전의 "각 블록당 한 거래" 모델에 비해 노드 소프트웨어 성능이 크게 향상되었습니다.

이로 인해 Merkle Trie 업데이트 비용이 여러 거래에 분산되어 현재 거래량에서 상태 데이터의 증가폭이 매년 약 15GB 줄어듭니다.

이전 버전의 프로토콜에서 기술 부채를 제거함으로써 노드 성능도 더욱 향상되었습니다. 여기에는 L1에 대한 인덱싱을 위해 별도의 "데이터 전송 계층" 노드가 더 이상 필요하지 않으며, L1에서 거래 데이터를 효율적으로 쿼리하기 위해 노드 소프트웨어가 업데이트됩니다.

개선된 이더리움 동등성

Bedrock는 처음부터 가능한 한 이더리움과 "일치"하도록 설계되었으며, 이전 버전 프로토콜에서 이더리움과의 여러 편차가 제거되었습니다. 여기에는 다음이 포함됩니다:

• "각 블록당 한 거래" 모델;
• L1의 블록 정보를 가져오기 위한 사용자 정의 작업 코드;
• JSON-RPC API에서 L1/L2 비용 필드를 분리;
• ETH 잔액의 사용자 정의 ERC20 표현.

Bedrock는 또한 EIP-1559, 블록체인 재구성 및 L1에 존재하는 기타 이더리움 기능에 대한 지원을 추가했습니다.

설계 원칙

Bedrock는 모듈화되고 업그레이드 가능한 설계로 구축되었으며, 이더리움의 기존 코드를 재사용할 수 있으며 가능한 한 100% 이더리움 동등성을 달성하는 것을 목표로 합니다.

모듈화

잘 정의된 인터페이스와 버전 관리 계획을 사용하여 Bedrock는 OP 스택 내의 다양한 구성 요소를 쉽게 교체하고 새로운 기능을 추가할 수 있습니다.

이로 인해 이더리움 생태계의 미래 발전에 적응할 수 있는 유연한 아키텍처를 통해 다음과 같은 기능이 허용됩니다:

• 롤업 노드와 실행 클라이언트 분리;
• 모듈화된 장애 방지 설계.

코드 재사용

Bedrock는 가능한 한 기존 이더리움 아키텍처와 인프라를 사용하여 OP Stack이 이더리움 메인넷에서 사용되는 실전 테스트된 코드베이스로부터 보안성과 린디 효과(Lindy effect)의 이점을 상속받을 수 있도록 합니다.

디자인 전반에서 이러한 예를 찾을 수 있으며, 여기에는 다음이 포함됩니다:

• 최소한의 수정이 이루어진 실행 클라이언트;
• EVM 계약 대신 미리 컴파일된 클라이언트 코드.

이더리움 동등성

Bedrock는 기존 이더리움 개발자 경험과 최대한 호환되도록 설계되었지만, L1과 롤업 간의 근본적인 차이로 인해 몇 가지 예외가 존재합니다: 비용 모델의 차이, 더 빠른 블록 생성 시간(2초 대 12초) 및 L1 입금 거래를 포함하는 특별 거래 유형.

이러한 예외에는 다음이 포함됩니다:

• 최소한의 수정으로 이더리움 실행 클라이언트의 장애 증명을 증명하기 위한 것;
• L2 네트워크의 노드와 정렬기를 위해 이더리움 실행 클라이언트의 코드 재사용.

프로토콜

롤업은 데이터 가용성을 기반으로 구축되며(일반적으로 이더리움과 같은 L1 블록체인), 가장 일반적인 구성에서 롤업 프로토콜은 두 가지 주요 정보 출처에서 "표준 L2 체인"을 파생합니다:

• 거래 데이터는 정렬기(Sequencer)에 의해 L1에 게시됨;
• 입금 거래는 계정과 스마트 계약이 L1의 브리지 계약에 제출함.

다음은 해당 프로토콜의 기본 구성 요소입니다:

• L1의 스마트 계약과 직접 상호작용하여 입금을 "표준 L2 체인"에 기록함;
• 출금은 "표준 L2 체인"에 기록되며 L1의 스마트 계약 및 계정과의 상호작용을 암묵적으로 촉발함;
• 배치는 롤업의 배치와 일치하는 데이터 기록;
• 블록 유도는 L1의 데이터 읽기를 해석하여 "표준 L2 체인"을 이해하는 방법;
• 증명 시스템은 L1에 게시된 출력 루트의 최종성을 정의하여 실행될 수 있도록 함(예: 출금 실행).

입금

입금은 L1의 거래이며 롤업에 포함됩니다. 정의상, 입금은 "표준 L2 체인"에 포함될 것이 보장되며, 이는 L2에 대한 검열 또는 통제를 방지하는 수단으로 작용합니다.

L1에서 전달되는 임의 메시지

입금 거래는 입금의 일부로 수행되는 롤업 거래입니다. Bedrock를 통해 입금은 완전히 일반적인 이더리움 거래로, 이더리움의 계정이나 스마트 계약이 "입금" 계약을 생성할 수 있습니다.

Bedrock는 L1에서 사용할 수 있는 입금 계약을 정의합니다: 이는 스마트 계약으로, L1 계정과 스마트 계약이 L2에 기록하기 위해 상호작용할 수 있습니다. L2의 입금 거래는 해당 입금 계약에서 발행된 거래에서 파생되며, 여기에는 예상되는 매개변수(예: from, to 및 data)가 포함됩니다.

자세한 내용은 입금 계약 프로토콜 규격 부분을 참조하십시오.

L1에서 보장된 L2 가스 구매

Bedrock는 또한 가스 소각 메커니즘과 입금 수수료 시장을 명확히 하여, L2에서 발생하는 입금 거래의 가스는 L1에서 구매된 가스를 통해 소각됩니다.

이 가스는 수수료 시장에서 구매되며, 단일 L1 블록에서 모든 입금 거래에 제공되는 가스 총량에는 하드 리미트가 있으며, 이 메커니즘은 L1에서 L2로 거래를 기록할 때 발생할 수 있는 서비스 거부 공격(DoS)을 방지하기 위해 사용됩니다. 이러한 공격은 L2에서 많은 가스를 소모하지만 L1에서는 저렴한 거래가 발생할 수 있습니다.

입금 거래에 제공되는 가스는 때때로 "보장된 가스"(Guaranteed Gas)라고 불립니다. 보장된 가스의 독특한 점은 L1에서 가스를 소각하여 지불되므로 환불이 불가능하다는 것입니다.

각 단위의 보장된 L2 가스에 대해 소각해야 하는 L1 가스의 총량은 EIP-1559 방식의 요금 메커니즘 보고서에 따라 L2 가스 가격에 따라 달라집니다. 또한 사용자는 계산된 요금 메커니즘에 따라 소모된 L1 가스 양에 대한 동적 가스 보조금을 받습니다.

더 깊은 설명이 필요하면 입금 부분 프로토콜 규격을 읽어보십시오.

출금

출금은 L2에서 시작되어 L1에서 실행된 거래로 완료되는 크로스 레이어 거래입니다. 주목할 점은 L2 계정이 출금을 사용하여 L1 계약을 호출하거나 L2 계정에서 L1 계정으로 ETH를 전송할 수 있다는 것입니다.

출금은 L2에서 Message Passer 미리 배포된 계약을 호출하여 시작되며, 이 계약은 메시지의 중요한 속성을 저장하고, 이후 OptimismPortal 계약을 호출하여 L1에서 출금을 완료하여 이 출금 메시지를 증명합니다.

이렇게 하면 출금과 입금이 다르게 됩니다: 출금 거래는 블록에서 파생된 정보를 의존하지 않고 L1의 스마트 계약을 사용하여 완료해야 합니다.

두 단계 출금 프로세스

출금 증명 검증 오류는 지난 몇 년간 많은 크로스 체인 브리지 해킹 사건의 근본 원인이었습니다. Bedrock 버전은 이전 버전의 출금 프로세스에 추가 단계를 도입하여 이러한 유형의 오류에 대한 추가 방어 설계를 제공합니다.

두 단계 출금 프로세스에서, 각 출금은 최종 퇴출 전 7일 이내에 출금에 해당하는 Merkle 증명을 제출해야 하며, 이 새로운 보안 메커니즘은 모니터링 도구에 무효 출금 증명을 찾고 감지할 수 있는 7일의 시간을 제공합니다.

이 기간 동안 무효 출금 증명이 발견되면 자금 손실 전에 스마트 계약 수정을 배포할 수 있어 크로스 체인 브리지의 타협 위험이 크게 줄어듭니다.

자세한 내용은 출금 프로토콜 규격 부분을 참조하십시오.

배치 거래(Batches)

Bedrock에서는 L1과 L2 간의 메시지 전달을 위한 유선 형식(즉, L2가 L1에서 블록을 파생하고 L2가 거래를 L1에 기록하는 형식)을 정의하며, 이 유선 형식의 설계 목적은 L1에 기록하는 비용과 소프트웨어 복잡성을 최소화하는 것입니다.

최적화된 데이터 압축

데이터 압축을 최적화하기 위해 L2 거래 목록(정렬기 배치라고 함)은 객체 그룹(채널이라고 함)으로 구성되며, 각 채널의 최대 규모는 구성 가능한 매개변수에서 정의할 수 있으며, 초기 설정은 9.5M으로 설정됩니다. 이러한 채널은 압축 기능을 사용하여 압축되고 L1에 제출될 것으로 예상됩니다.

배치 병렬 제출

L1에 압축된 채널 데이터를 제출하는 정렬기 메시지를 병렬화하기 위해 채널은 "채널 프레임"으로 추가 분해됩니다. 이러한 "채널 프레임"은 단일 L1 거래에 적합한 압축된 채널 데이터 블록입니다.

"채널 프레임"이 서로 독립적이고 순서가 알려져 있다면, 정렬기가 L1에 보내는 이더리움 거래는 병렬로 전송될 수 있어 정렬기 소프트웨어의 복잡성을 최소화하고 L1의 모든 사용 가능한 데이터 공간을 채울 수 있습니다.

최소화된 이더리움 가스

Bedrock는 L1 시스템이 "배치 거래"라는 거래에서 L1에 채널 데이터를 제출하는 데 사용하는 모든 실행 가스를 제거했습니다. 이전에 L1 스마트 계약에서 발생했던 모든 검증 논리는 블록 파생 논리로 이동되었습니다. 대신 "배치 거래"는 이더리움의 단일 EOA 주소로 전송되며, 이를 "배치 인박스 주소"라고 합니다.

배치는 여전히 유효성 검사를 받아야 하며(즉, 올바르게 인코딩되어야 함), 배치 내의 단일 거래도 마찬가지입니다(예: 서명이 유효해야 함). 무효 배치와 유효 배치 내의 무효 단일 거래는 폐기된 것으로 간주되며 시스템과 무관합니다.

참고: 이더리움은 곧 EIP-4844를 포함하는 새로운 버전으로 업그레이드될 예정이며, 이는 별도의 데이터 기록 수수료 시장을 도입하고 이더리움 프로토콜이 저장할 수 있는 데이터 양의 상한을 증가시킵니다. 이 변화는 L1에 데이터를 게시하는 것과 관련된 비용을 더욱 줄일 것으로 기대됩니다.

더 깊은 설명이 필요하면 유선 형식 규격을 읽어보십시오.

블록 파생

Bedrock에서는 이 프로토콜의 설계가 L1에 입금된 시간과 "표준 L2 체인"의 블록 파생과 관련이 있도록 보장됩니다. 이는 정렬기, 입금 및 L1 블록 속성을 통해 L1에 데이터를 기록하는 순수 함수로 수행됩니다.

이를 위해 이 프로토콜은 입금이 기록되고 L1 및 L2 타임스탬프가 처리되며 채널 내의 정렬 창을 처리하여 올바른 정렬을 보장하는 전략을 정의합니다.

입금 기록 보장

블록 파생 프로토콜의 목표는 다음과 같이 정의됩니다:

각 "L2 블록 간격"이 지나면 L2 블록이 있어야 하며, L2 블록의 타임스탬프는 L1의 타임스탬프와 동기화되어야 합니다(즉, 입금이 논리적 시간 순서에 포함되도록 보장).

Bedrock에서는 "정렬 에포크"라는 개념이 도입되었습니다: 이는 일련의 L1 블록에서 파생된 L2 블록의 범위로, 각 에포크는 "에포크 번호"로 식별되며, 이 "에포크 번호"는 정렬 창에서 첫 번째 L1 블록의 블록 번호와 같습니다. 몇 가지 제한 사항에 따라 에포크의 크기는 다를 수 있습니다.

배치 파생 채널은 "에포크 번호"와 관련된 L1 블록의 타임스탬프를 L2에서 거래 순서를 결정하는 앵커로 간주합니다. 이 프로토콜은 한 에포크의 첫 번째 L2 블록이 항상 일치하는 에포크의 L1 블록의 타임스탬프보다 늦지 않도록 보장합니다. 한 에포크의 첫 번째 블록은 L1에서 입금이 포함되어야 하며, 이를 통해 입금이 처리될 것임을 보장합니다.

참고로, Bedrock 버전에서 L2의 블록 간격 목표는 2초로 설정되어 있습니다.

L1 및 L2 타임스탬프 처리

Bedrock는 L2의 타임스탬프를 입금 거래에 존재하는 L1의 타임스탬프와 조정하는 문제를 해결하려고 합니다.

이를 위해 에포크 간의 L2 거래에 자유롭게 타임스탬프를 적용할 수 있도록 짧은 시간 창을 허용합니다.

정렬 창(sequencing window)은 L1 블록의 시퀀스로, 여기에서 에포크를 파생할 수 있습니다. 하나의 정렬 창에서 첫 번째 L1 블록의 번호 N은 에포크의 "배치 거래"를 포함합니다.

정렬 창에는 블록이 포함되며, 이는 정렬 창의 크기에 따라 달라집니다: 고정된 롤업 수준 구성 매개변수는 최소 2여야 하며, 이를 증가시키면 정렬기가 입금에 대한 L2 거래를 정렬할 수 있는 기회가 더 많아지고, 이를 줄이면 정렬기가 "배치 거래"를 제출하는 데 더 엄격한 시간 창이 도입됩니다. 이는 MEV 기회를 창출하고 소프트웨어 복잡성을 증가시키는 것 사이의 균형입니다.

"최대 정렬기 드리프트"(max sequencer drift)라는 프로토콜 상수는 블록이 에포크 내에서 가질 수 있는 최대 타임스탬프를 제어하며, 이러한 드리프트를 통해 정렬기는 L1에 연결할 때 일시적인 문제가 발생하더라도 활성 상태를 유지할 수 있습니다.

블록 파생 파이프라인

"표준 L2 체인"은 L2 제네시스 상태에서 시작하여 처음 에포크로 설정된 L2 체인을 시작하고 모든 정렬 창을 처리하여 다음과 같은 간소화된 순서에 따라 정렬기 배치와 입금의 올바른 순서 파이프라인을 결정할 수 있습니다:

장애 증명

정렬기가 하나 이상의 L2 블록을 처리한 후, 이러한 블록에서 실행된 거래 계산의 출력은 L1에 기록되어 L2에서 L1으로의 메시지 전달을 위한 신뢰할 수 없는 실행을 달성해야 합니다(예: 출금 등).

Bedrock에서는 출력을 트리 구조로 해시 처리하여 증명 출력 캡처의 비용을 최소화합니다. 제안자는 정기적으로 전체 "표준 L2 체인"의 Merkle 루트로서 출력 루트를 L1에 제출합니다.

OP Stack의 미래 업그레이드는 장애 증명 변형의 규격을 포함해야 하며, 여기에는 제안자가 올바른 출력 루트를 제출하도록 유도하는 바인딩이 포함됩니다.

자세한 내용은 L2 출력 루트 제안 부분 프로토콜 규격을 참조하십시오.

실행

Bedrock에서 OP Stack은 이더리움 실행 계층과 합의 계층 간의 분리를 미러링하여 이더리움이 지정한 기술적 관심사 분리에 크게 의존해야 했습니다.

따라서 Bedrock는 실행 클라이언트와 롤업 노드의 분리를 동일한 방식으로 도입했습니다.

실행 클라이언트

실행 클라이언트는 정렬기와 기타 유형의 노드 운영자가 "표준 L2 체인" 상태를 결정하는 시스템입니다. 또한 입출 거래 처리, 피어 투 피어 통신 및 시스템 상태 처리와 같은 다른 기능을 수행합니다.

Bedrock를 통해 OP Stack은 이더리움 자체의 실행 클라이언트 규격과 그 많은 실행 작업을 재사용하는 것을 목표로 합니다. 이 버전에서 Bedrock는 이더리움 클라이언트 go-ethereum에 대해 극히 제한된 수정을 보여주며, 그 차이는 2000줄 미만입니다.

차이가 존재하는 근본적인 이유는 두 가지입니다: 입금 거래 처리 및 거래 수수료 청구입니다.

입금 거래 처리

롤업에서 입금된 거래를 나타내기 위해 추가 거래 유형이 도입되었습니다. 실행 클라이언트는 EIP-2718 유형의 거래 표준에 따라 이 새로운 거래 유형을 구현합니다.

거래 수수료 청구

롤업은 본질적으로 거래와 관련된 두 가지 비용이 있습니다:

하나는 정렬기 비용입니다. 이더리움과 동일한 가스 테이블과 동일한 EIP-1559 알고리즘을 사용하여 정렬기 운영 비용을 계산하며, 이 비용은 정렬기 운영 프로토콜에 사용되며 네트워크 혼잡에 따라 변동합니다.

다른 하나는 데이터 가용성 비용입니다. 데이터 가용성 비용은 배치 처리 거래를 L1에 기록하는 것과 관련이 있으며, 이 비용은 정렬기가 L1에 배치 거래를 제출하는 데 필요한 비용을 지불하기 위해 설계되었습니다.

Bedrock에서는 비용의 데이터 가용성 부분이 "GasPriceOracle"이라는 롤업 시스템 스마트 계약의 정보에 따라 결정되며, 이 스마트 계약은 블록 파생 과정에서 각 에포크 시작 시 삽입된 L1 블록 속성에서 검색된 가스 가격 정보를 기반으로 업데이트됩니다.

Bedrock는 JSON-RPC를 사용할 때 이 두 가지 비용을 하나의 필드에 추가하도록 지정합니다.

롤업 노드

이더리움과 달리 Bedrock에는 PoS 합의가 없습니다. 대신 "표준 L2 체인"의 합의는 블록 파생에 의해 정의됩니다. OP Stack의 실행 클라이언트는 롤업 노드라는 블록 파생을 구현하는 새로운 구성 요소와 통신하며, 이 노드는 이더리움과 완전히 동일한 엔진 API를 사용하여 실행 클라이언트와 통신합니다.

롤업 노드는 상태를 유도하기 위해 L1의 데이터를 읽고 입금을 통해 시스템의 상태를 유도하는 무상태 구성 요소입니다. Bedrock에서 롤업 노드는 사용자 또는 다른 롤업 노드로부터의 수신 거래를 정렬하거나 L1에서 게시된 확인된 거래를 검증하기 위해 L1에 독립적으로 의존할 수 있습니다.

롤업 노드의 다양한 용도는 다음과 같습니다:

"표준 L2 체인" 검증

롤업 노드를 운영하는 가장 간단한 모드는 "표준 L2 체인"을 따르는 것입니다. 이 모드에서 롤업 노드는 피어 노드가 없으며, L1에서 데이터를 읽고 블록 파생 프로토콜 규칙에 따라 데이터를 해석하는 데만 엄격하게 사용됩니다.

이러한 노드의 목적 중 하나는 프로토콜 정의에 따라 다른 노드가 공유하거나 L1에 게시한 출력 루트가 올바른지 검증하는 것입니다. 또한 L1에 출력 루트를 제출할 의도가 있는 제안자는 optimism_outputAtBlock을 사용하여 필요한 출력 루트를 생성하고 L2 출력 루트에 해당하는 32바이트 해시 값을 반환할 수 있습니다.

이를 위해 노드는 "최종화"(finalized)된 블록 헤드를 따르기만 하면 됩니다. "최종화"라는 용어는 이더리움 PoS 합의(즉, 표준화되고 거의 되돌릴 수 없는)를 의미하며, "최종화"된 L2 블록 헤드는 "최종화"된 L1 블록에서 파생된 "표준 L2 체인"의 블록 헤드입니다.

L2 네트워크 참여

롤업 노드를 사용하는 가장 일반적인 방법은 다른 롤업 노드의 네트워크에 참여하고 L2의 진행 및 상태를 추적하는 것입니다. 이 모드에서 롤업 노드는 L1에서 읽은 데이터와 입금을 동시에 읽고 이를 블록으로 해석하며, 다른 롤업 노드 네트워크의 사용자 및 피어로부터의 수신 거래를 수용합니다.

네트워크에 참여하는 노드는 동기화 중인 L2의 안전한 블록 헤드와 안전하지 않은 블록 헤드를 사용할 수 있습니다.

• 안전한 L2 블록 헤드는 롤업을 구축할 수 있는 것으로, 각 블록(헤드 포함)이 참조 L1 체인에서 완전히 파생될 수 있으며, L1이 "최종화"되기 전에(즉, L1에서 재구성이 여전히 발생할 수 있음);
• 안전하지 않은 L2 블록 헤드는 L1에서 아직 파생되지 않은 안전하지 않은 블록을 포함합니다. 이러한 블록은 롤업 노드를 정렬기로 운영하거나 안전하지 않은 정렬기와 동기화에서 발생합니다. 이는 "최신" 블록 헤드라고도 합니다. 분기 상황에서는 항상 안전한 L2 블록 헤드를 선택하고 안전하지 않은 L2 블록 헤드는 선택하지 않습니다. 분기 상황에서는 체인의 안전하지 않은 부분이 재구성됩니다;

대부분의 경우 최종 사용자 애플리케이션에 대해 L2 네트워크의 롤업 노드는 안전하지 않은 L2 블록 헤드를 참조합니다.

거래 정렬

롤업 노드를 사용하는 세 번째 방법은 거래를 정렬하는 것입니다. 이 모드에서 롤업 노드는 안전하지 않은 L2 블록 헤드 위에 새 블록을 생성합니다. 현재 각 OP Stack 네트워크에는 하나의 정렬기만 있습니다.

정렬기는 또한 배치 거래를 L1에 게시하는 책임이 있으며, 이를 통해 네트워크의 다른 노드가 동기화할 수 있습니다.

배치기

정렬기의 역할은 배치 거래를 생성하는 것입니다. 이를 위해 정렬기는 롤업 노드를 실행하고 별도의 프로세스를 가질 수 있으며, 이러한 프로세스는 실행 중인 신뢰할 수 있는 롤업 노드에서 읽어 배치를 수행합니다.

이것은 OP Stack의 추가 구성 요소인 배치 거래 처리기를 보장하며, 이는 롤업 노드에서 거래 데이터를 읽고 이를 L1에 기록할 배치 거래로 해석합니다. 배치기 구성 요소는 정렬기가 운영하는 롤업 노드의 안전하지 않은 L2 블록 헤드를 읽고 배치 거래를 생성하여 L1에 기록하는 책임이 있습니다.

표준 브리지 계약

Bedrock는 가장 일반적인 유형의 입금을 위한 브리지 계약 쌍인 표준 브리지 계약을 포함합니다. 이러한 계약은 입금 및 출금 계약을 캡슐화하여 ETH 및 ERC-20 토큰의 입금 및 출금에 대한 간단한 인터페이스를 제공합니다.

이러한 브리지 계약의 설계는 크로스 체인 브리지의 한쪽에서 로컬 토큰을, 다른 쪽에서는 발행 및 소각을 관리할 수 있는 포장된 토큰을 포함합니다. 원주율 토큰을 브리징하는 것은 원주율 토큰을 계약에 잠금하고 크로스 체인 브리지의 다른 쪽에서 동일한 양의 포장된 토큰을 발행하는 것을 포함합니다.

자세한 내용은 표준 크로스 체인 브리지 프로토콜 규격 부분을 참조하십시오.

캐논

캐논에서 장애 방지 구축 및 검증이 구현되었지만, 장애 증명 게임 규격 및 출력 루트 도전자를 롤업 노드에 통합하는 것은 후속 규격 이정표의 일부입니다.

추가 읽기

프로토콜 규격

프로토콜 규격은 OP Stack의 기술 세부 사항을 정의하며, 이는 프로토콜 내부 작동의 최신 사실 출처입니다.

Bedrock 차이점

Bedrock와 이전 버전 간의 차이점을 자세히 알아보려면 "Bedrock는 무엇이 다른가"를 참조하십시오.