전 아비트럼 기술 홍보대사가 설명하는 아비트럼의 구성 요소 구조(아래)

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

소개. 전 아비트럼 기술 홍보대사이자 스마트 컨트랙트 자동화 감사 회사인 고플러스 시큐리티의 공동 창업자인 베니 로가 아비트럼 원에 대해 기술적으로 설명합니다.

이전 게시물 "전 아리럼 기술 홍보대사 설명하는 아리럼의 구성 요소 구조 (위)"에서는 아리럼의 핵심 구성 요소인 시퀀서, 검증자, 시퀀서 인박스 계약, 롤업 블록, Non. 인터랙티브 사기 증명, 그리고 오늘 포스팅에서는 크로스체인 메시징 및 검열 방지 트랜잭션 포털과 관련된 아비트럼 핵심 구성 요소에 대해 집중적으로 살펴보겠습니다.

본문: 이전 글에서 이 글에서는 시퀀서 컨트랙트가 시퀀서가 레이어 1에 게시한 트랜잭션 패킷 배치를 독점적으로 수신한다고 언급했습니다. 동시에 시퀀서 인박스는 느린 인박스, 지연된 인박스(또는 줄여서 인박스)와 달리 빠른 인박스로도 알려져 있다는 점을 지적했습니다. 아래에서는 지연된 받은 편지함과 크로스 체인 메시징과 관련된 기타 구성 요소에 대해 자세히 살펴보겠습니다.

크로스 체인 및 브리징 원칙

크로스 체인 거래는 L1에서 L2로(충전), L2에서 L1로(인출)로 분류할 수 있습니다. 여기서 말하는 충전과 출금은 반드시 자산 크로스체인과 관련이 있는 것은 아니며, 자산이 직접적으로 연결되지 않은 메시징일 수도 있다는 점에 유의하세요. 따라서 이 두 용어는 단순히 크로스 체인 관련 행동의 두 가지 방향을 나타냅니다.

크로스체인 트랜잭션은 서로 다른 두 시스템인 L1과 L2 간에 메시지를 교환하기 때문에 순수한 L2 트랜잭션보다 더 복잡합니다.

또한 크로스체인 작업은 보통 서로 관련이 없는 두 네트워크에서 증인 모델에 기반한 크로스체인 브리지를 사용하여 수행되며, 브리지 운영자에 따라 보안이 달라지는데, 역사적으로 증인 모델에 기반한 크로스체인 브리지의 도난이 빈번하게 발생했습니다.

롤업과 이더리움 호스트 네트워크 간에 크로스 링크가 수행되는 경우, 레이어 2의 상태는 레이어 1에 기록된 데이터에 의해 결정되기 때문에 위에서 설명한 것과 근본적으로 다르며, 롤업 관계자의 크로스 링크 브리지를 사용하는 한 그 운영 구조는 절대적으로 안전합니다. 롤업 공식 크로스 링크 브리지를 사용하는 한 구조적으로 안전합니다.

이 또한 사용자 입장에서는 별도의 체인처럼 보이지만 실제로는 롤업이 사용자에게 제공한 '레이어2'에 불과하다는 롤업의 특성을 강조하는 것입니다. 하지만 실제로는 "Layer2"는 사용자에게 보여주기 위한 쇼케이스일 뿐이며, 실제 체인 구조는 여전히 Layer1에 내장되어 있습니다. 따라서 L2는 체인의 절반, 즉 "Layer1 위에 생성된 체인"이라고 생각할 수 있습니다.

리테이블

크로스체인은 비동기적이고 비원자적이라는 점에 유의하세요. 하나의 체인처럼 트랜잭션이 완료되고 확인된 후에 그 결과를 알 수 없으며, 어느 시점에 다른 쪽에서 어떤 일이 일어날지 보장할 수 없습니다. 따라서 크로스체인이 일부 소프트 이슈로 인해 실패할 수는 있지만, 재구매 가능한 티켓과 같은 적절한 수단을 사용하면 자금이 묶이는 것과 같은 하드 이슈는 발생하지 않습니다.

재구매 가능 티켓은 공식 아티럼 브리지를 통해 충전할 때 사용되는 기본 도구이며, 이더리움 및 ERC20 충전에 모두 사용됩니다. 수명 주기는 세 단계로 나뉩니다.

1. L1에서 티켓을 제출합니다. 지연된 받은 편지함 컨트랙트에서 createRetryableTicket() 메서드를 사용하여 재충전 티켓을 생성하고 제출합니다.

2. L2에서 자동 재충전. 대부분의 경우 시퀀서는 후속 수동 작업 없이 자동으로 사용자에게 티켓을 현금화할 수 있습니다.

3. L2에서 수동 현금화. L2에서 유가가 갑자기 급등하거나 티켓에 선불 가스가 충분하지 않은 경우와 같은 일부 예외적인 경우에는 자동으로 현금화할 수 없습니다. 이 경우 사용자가 수동으로 현금화해야 합니다.

자동 상환에 실패한 경우 7일 이내에 수동으로 상환해야 하며, 그렇지 않으면 항공권이 삭제되거나(영구적으로 자금이 손실됨) 항공권 보존을 위해 임대를 갱신하는 데 수수료를 지불해야 한다는 점에 유의하세요.

또한, 아비트럼 공식 브리지 출금 프로세스의 경우, 특정 대칭적 유사성 과정에서 재충전 동작이 있지만 재시도 가능성은 없지만 이 개념은 한편으로는 롤업 프로토콜 자체에서 이해할 수 있고, 다른 한편으로는 다음과 같이 이해할 수 있습니다. 이해해야 할 몇 가지 차이점 :

• 자동 상환 과정에서는 현금 인출 과정이 존재하지 않으며,자동 상환 과정에서는 현금을 인출할 수 있는 시간이 없기 때문입니다. strong>EVM에는 타이머나 자동화가 없는 반면, L2에서는 자동 현금 인출이 가능하기 때문에 이를 지원하는 것은 시퀀서이므로 L1의 사용자는 자산을 돌려받기 위해 아웃박스 컨트랙트와 수동으로 상호 작용하여 클레임해야 합니다.

• 출금 또한 티켓이 만료되는 문제가 없으며, 출금은 언제든지 청구할 수 있습니다. strong>도전 기간이 지나지 않았다면 언제든지 신청할 수 있습니다.

ERC-20 자산 크로스체인 게이트웨이

< strong>ERC-20 자산의 크로스체인은 복잡합니다. 고려해야 할 몇 가지 질문 :

• L1에 배포된 토큰을 L2에 어떻게 배포할 것인가? L2에는 어떻게 배포될까요?

• L2 대응 토큰을 미리 수동으로 배포해야 하나요, 아니면 교차했지만 아직 컨트랙트를 배포하지 않은 토큰에 대해 시스템이 자동으로 자산 컨트랙트를 배포할 수 있나요?

• L1에 있는 ERC-20 자산의 L2 컨트랙트 주소는 무엇인가요? L1과 동일해야 하나요?

• 기본적으로 L2에서 발행된 토큰을 어떻게 L1으로 크로스체인하나요?

• 수량 조절이 가능한 리베이스형 토큰이나 스스로 성장하는 이자형 토큰과 같은 특별한 기능을 가진 토큰은 어떻게 크로스체인을 하나요?

이 모든 질문에 답하기에는 너무 복잡할 수 있기 때문에 이 질문에 모두 답할 생각은 없습니다. 이러한 질문은 ERC20 교차 연결의 복잡성을 설명하기 위한 것일 뿐입니다.

현재 매우 많은 확장성 시나리오는 화이트리스트 + 수동 목록 체계를 사용하여 다양한 복잡성과 경계 사례를 해결합니다.

아비트럼은 게이트웨이 시스템을 사용하여 대부분의 ERC20 크로스체인 문제점을 해결하며, 다음과 같은 특징을 가지고 있습니다:

• 게이트웨이 구성 요소는 L1과 L2에 쌍으로 나타납니다.

• 게이트웨이 라우터는 토큰 L1과 토큰 L2 사이의 주소 매핑을 유지 관리할 책임이 있으며,또한 일부 토큰과 일부 토큰 사이의 매핑을 유지 관리합니다. strong>그리고 일부 토큰과 일부 게이트웨이 간의 매핑을 유지 관리합니다.

• 게이트웨이 자체는 표준ERC20 게이트웨이, 일반-사용자 지정 게이트웨이, 사용자 지정 게이트웨이, 일반-맞춤형 게이트웨이, 사용자 지정 게이트웨이 등으로 분류할 수 있으며, 다양한 유형과 기능의 ERC20 브리징 문제를 해결하는 데 사용됩니다.

비교적 간단한 예시를 들어보겠습니다. WETH 크로스체인 예시를 통해 커스텀 게이트웨이의 필요성을 설명해 보겠습니다.

WETH는 이더리움에 해당하는 ERC20입니다. 이더를 기본 코인으로 사용하면 디앱의 복잡한 기능 중 상당수를 사용할 수 없으므로 ERC20에 상응하는 코인이 필요합니다. 이더리움 컨트랙트에 일부 이더를 전송하면 컨트랙트에 락업되고 동일한 양의 이더리움이 생성됩니다.

비슷하게 이더리움을 파괴하고 이더를 가져올 수 있으며, 유통되는 이더리움의 양과 락업된 이더리움의 양은 항상 1 : 1.

이제 WETH를 L2에 직접 크로스체인하면 몇 가지 이상한 문제가 발견됩니다.

• 잠금 위치에 해당하는 이더리움이 L2에 없기 때문에 L2에서 WETH를 이더리움으로 언랩할 수 없습니다.

• 랩 함수는 를 사용할 수 있지만, L1과 L2의 WETH 컨트랙트가 "대칭"이 아니기 때문에 새로 생성된 WETH를 L1에서 ETH로 언래핑할 수 없습니다.

이것은 분명히 WETH의 설계 원칙에 위배됩니다. 그렇다면 WETH는 반대편으로 건너가기 전에 이더리움으로 언랩한 다음, 충전이나 인출 등 체인을 통과할 때 이더리움으로 랩핑해야 합니다. 이것이 바로 WETH 게이트웨이의 역할이기도 합니다.

동일하게 더 복잡한 로직을 가진 다른 토큰은 크로스 체인 환경에서 제대로 작동하기 위해 더 복잡하고 잘 설계된 게이트웨이가 필요하며, Arbitrum의 맞춤형 게이트웨이는 일반 게이트웨이의 크로스 체인 통신 로직을 상속하여 개발자가 다음을 수행할 수 있도록 합니다. 아비트럼의 커스텀 게이트웨이는 일반 게이트웨이의 크로스체인 통신 로직을 이어받아 개발자가 토큰 로직과 관련된 크로스체인 동작을 커스터마이징할 수 있으며, 이는 대부분의 요구 사항을 충족합니다.

지연된 받은 편지함

이것은 시퀀서인박스와 동일합니다. 느린 받은 편지함(전체 이름 지연된 받은 편지함)과 반대되는 SequencerInbox입니다. 빠른 받은편지와 느린 받은편지에 차이가 있는 이유는 무엇인가요? 빠른 받은 편지함은 시퀀서로부터 L2 트랜잭션 배치를 받도록 설계되었으며, L2 네트워크 내에서 시퀀서에 의해 사전 처리되지 않은 트랜잭션은 빠른 받은 편지함 계약에 포함되지 않아야 하기 때문입니다.

슬로우박스의 첫 번째 용도는 L1에서 L2로의 탑업을 처리하는 것입니다. 슬로박스의 첫 번째 용도는 L1에서 L2로의 충전을 처리하는 것입니다. 사용자가 슬로박스를 통해 충전을 수행하면 시퀀서가 이를 수신하여 L2에 반영하고, 최종적으로 해당 충전은 시퀀서에 의해 L2의 트랜잭션 시퀀스에 포함되어 패스트박스 컨트랙트인 시퀀서 인박스에 제출됩니다.

이 예시에서는 사용자가 직접 패스트박스에 충전을 제출하고, 패스트박스에 직접 제출하는 방식으로 설명합니다. 사용자가 퀵박스에 직접 충전 트랜잭션을 제출하는 것은 적절하지 않은데, 이는 퀵박스 시퀀서 받은 편지함에 제출된 트랜잭션이 레이어2의 정상적인 트랜잭션 정렬을 방해하여 시퀀서의 작업에 영향을 미치기 때문입니다.

슬로우박스의 두 번째 용도는 검열에 저항하는 것입니다. 사용자가 트랜잭션을 슬로우박스 컨트랙트에 직접 제출하면, 시퀀서는 보통 10분 이내에 트랜잭션을 패스트박스에 넣습니다. 그러나 시퀀서가 악의적으로 사용자의 요청을 무시하는 경우, 슬로우박스에는 강제 포함 기능도 있습니다.

거래가 지연된 수신함에 제출되었는데 24시간이 지나도 시퀀서에 의해 아직 슬로우박스에 포함되지 않은 경우, 슬로우박스가 이를 처리하지 못할 수 있습니다. 24시간이 지난 후에도 느린 수신함의 트랜잭션이 시퀀서에 의해 트랜잭션 시퀀스에 포함되지 않은 경우, 사용자는 수동으로 Layer1에서 강제 포함 기능을 트리거하여 시퀀서에 의해 무시된 트랜잭션 요청을 빠른 수신함의 시퀀서 수신함으로 그룹화할 수 있으며, 그 후 모든 Arbitrum One 노드가 이를 수신하고 강제로 시퀀서 수신함에 포함될 것입니다. 강제로 레이어2 트랜잭션 시퀀스에 포함될 것입니다.

퀵박스에 있는 데이터는 L2의 기록 데이터 엔티티라고 앞서 언급했습니다. 따라서 악의적인 검열의 경우 슬로우박스를 사용하면 거래 주문이 L2 원장에 포함될 수 있으며, 이는 레이어2를 빠져나가는 강제 인출과 같은 시나리오를 다룰 수 있습니다.

이것에서 알 수 있듯이 시퀀서는 어느 방향과 레이어에서든 트랜잭션을 영구적으로 검열할 수 없습니다.

슬로우박스의 몇 가지 핵심 기능 :

• ETH를 충전하는 가장 간단한 함수인 depositETH().

• createRetryableTicket(), ETH와 ERC20 및 메시지를 충전하는 데 사용할 수 있습니다. 입금ETH()에 비해 충전 후 L2 수령 주소를 지정할 수 있는 등 더 많은 유연성이 있습니다.

• 강제 포함 함수인 forceInclusion()은 모든⼈에서 호출할 수 있습니다. 이 함수는 슬로우박스 컨트랙트에 제출된 트랜잭션이 24시간이 지나도 처리되지 않았는지 확인합니다. 조건이 충분하면 메시지에 강제 포함이 적용됩니다.

하지만 강제 포함 함수는 실제로는 는 패스트박스 컨트랙트에 있지만, 이해를 돕기 위해 여기서는 슬로우박스에서 설명하겠습니다.

아웃박스

아웃박스는 출금과만 관련이 있습니다. 출금 행위에 대한 로깅 및 관리 시스템으로 이해할 수 있습니다.

• 우리는 알고 있습니다. 약 7일간 지속되는 챌린지 기간 종료 시 롤업 블록이 완료된 후에만 Arbitrum 공식 브리지에서 출금할 수 있습니다. 챌린지 기간이 끝나면 사용자는 해당 머클 증명을 레이어1의 아웃박스 컨트랙트에 제출하고, 이는 다른 기능적 컨트랙트(예: 다른 컨트랙트에 잠긴 자산 잠금 해제)와 통신하여 인출을 완료합니다.

• 아웃박스 콘트랙트는 어떤 L2-L1 크로스체인 메시지가 처리되었는지 추적합니다. 처리된 메시지를 추적하여 사람들이 이미 실행된 인출 요청을 반복적으로 제출하는 것을 방지합니다. 이는

  mapping(uint256 => bytes32) 공개 지출을 통해 메시지에 대한 캐시아웃 요청의 지출 인덱스를 기록합니다. mapping[spentIndex] ! = bytes32(0)이면 요청이 이미 소비된 것입니다. 이 원리는 리플레이 공격을 방지하기 위한 트랜잭션 카운터 논스와 유사합니다.

다음 섹션에서는 이더리움을 예로 들어 충전 및 출금 과정을 자세히 설명하겠습니다.

ETH 충전

1. 사용자가 슬로우박스의 depositETH() 함수를 호출합니다.

2. 이 함수는 브리지 컨트랙트에 메시지를 기록하고 ETH를 브리지 컨트랙트로 전송하는 bridge.enqueueDelayedMessage()를 호출합니다. 컨트랙트로 전송합니다. 모든 이더리움 충전 자금은 충전 주소에 해당하는 브리지 컨트랙트에 보관됩니다.

3. 시퀀서는 슬로우박스에서 충전 메시지를 수신하고 충전 작업을 L2 데이터베이스에 반영하여 사용자가 L2 네트워크에서 충전된 자산을 볼 수 있도록 합니다.

4. 시퀀서는 트랜잭션 일괄 배치에 충전 기록을 포함하고 이를 L1의 패스트박스 컨트랙트에 제출합니다.

이더리움 출금

1. 사용자는 L2에서 ArbSys 컨트랙트의 withdrawEth() 함수를 호출하여 L2에서 해당 금액의 이더리움을 소멸시킵니다.

2. dir="ltr" role="presentation" style="text-align: left;">2. 시퀀서가 출금 요청을 체스트에 보냅니다.

3.검증자 노드는 퀵박스의 트랜잭션 순서를 기반으로 새로운 롤업 블록을 생성하며, 여기에는 위에서 설명한 출금 트랜잭션이 포함됩니다.

4. 롤업 블록이 챌린지 기간 동안 살아남고 유효성을 검사한 후, 사용자는 L1에서 Outbox.execute Transaction() 함수를 호출할 수 있습니다. 함수를 호출할 수 있으며, 앞서 언급한 ArbSys 컨트랙트에서 제공한 증명 매개변수를 사용합니다.

5. 아웃박스 컨트랙트가 확인되면 잠금 해제된 브리지에 있는 해당 금액의 이더가 사용자에게 전송됩니다.

빠른 출금

옵티미스틱 롤업 공식 브릿지를 이용한 출금에는 챌린지 기간이 적용될 수 있습니다. 기본 잠금 교환. 이 방법은 단순히 두 당사자가 각자의 체인 내에서 자산을 교환하는 것으로, 한 당사자가 프리이미지를 제공하기만 하면 다른 당사자는 항상 그에 상응하는 자산을 받을 수 있다는 점에서 원시적인 방식입니다. 문제는 유동성이 상대적으로 부족하기 때문에 P2P 방식으로 거래 상대방을 찾아야 한다는 것입니다.

강제 인출

force Inclusion() 강제 포함 함수는 모든 L2 로컬 트랜잭션, L1에서 L2 트랜잭션, L2에서 L1 트랜잭션에 대한 시퀀서 감시에 대응하는 데 사용됩니다. 시퀀서의 악의적인 검열은 트랜잭션 경험에 심각한 영향을 미치며, 대부분의 경우 L2에서 철회를 선택하게 되므로 다음은 강제 철회를 통해 forceInclusion의 사용법을 소개하는 예시입니다.

이더리움 출금 단계에서는 시퀀서 검토가 포함된 1단계와 2단계만 있으므로 이 두 단계만 변경하면 됩니다.

• L1의 슬로우박스 컨트랙트에서 inbox.sendL2Message()를 호출하고, 입력 파라미터는 L2에서 withdrawEth()를 호출할 때 입력해야 하는 파라미터를 사용합니다. 메시지는 L1의 브리지 컨트랙트와 공유됩니다.

• 강제 포함을 위한 24시간 대기 기간을 기다린 후, 퀵박스에서 강제 포함을 호출합니다. Inclusion() 함수를 호출하여 강제로 포함시키면 퀵박스 컨트랙트가 브리지에서 해당 메시지가 있는지 검토합니다.

최종 사용자는 아웃박스에서 돈을 인출할 수 있으며, 나머지 단계는 일반 인출과 동일합니다.

또한 Arb SDK를 사용하는 방법에 대한 자세한 튜토리얼을 통해 사용자에게 L2 로컬 및 L2-L1 트랜잭션에 대한 forceInclusion()을 안내할 수 있는 arbitrum-tutorials가 있습니다.