이전 Arbitrum 기술 대사가 해설하는 Arbitrum의 구성 요소 구조 (하)
글: 루오벤벤, 전 Arbitrum 기술 대사, 웹3 기여자
지난 기사 『전 Arbitrum 기술 대사가 해설하는 Arbitrum 구성 요소 구조(상편)』에서는 Arbitrum 핵심 구성 요소 중 정렬기(Sequencer), 검증자(Validator), Sequencer Inbox 계약, Rollup 블록, 비대칭 사기 증명의 역할에 대해 소개했습니다. 오늘은 오늘날의 기사에서 우리는 크로스체인 메시지 전달 및 검열 저항 거래 진입과 관련된 Arbitrum 핵심 구성 요소에 집중하여 설명합니다.
이전 기사에서 우리는 Sequencer Inbox 계약이 1단계(Layer1)에서 정렬기가 게시한 트랜잭션 데이터 패킷 배치를 수신한다고 언급했습니다. 동시에 우리는 Sequencer Inbox를 '빠른 우편함(Fast Inbox)'이라고도 부르며, 이에 상응하는 것이 지연된 우편함(Delayed Inbox, 약칭 Inbox)라고 지적했습니다. 아래에서는 Delayed Inbox 등 크로스체인 메시지 전달과 관련된 구성 요소들을 자세히 설명하겠습니다.
크로스체인 및 브리징 원리
크로스체인 트랜잭션은 L1에서 L2로(충전)와 L2에서 L1로(출금) 두 가지로 나눌 수 있습니다. 여기서 말하는 충전과 출금은 반드시 자산의 크로스체인과 관련되는 것은 아니며, 자산을 직접 포함하지 않는 메시지 전달일 수도 있습니다. 따라서 이 두 단어는 단지 크로스체인 관련 행동의 두 방향을 나타낼 뿐입니다.
순수한 L2 트랜잭션과 비교할 때, 크로스체인 트랜잭션은 L1과 L2라는 서로 다른 시스템 간 정보 교환이 이루어지므로 그 과정이 더 복잡합니다.
또한 일반적으로 우리가 말하는 크로스체인 행위는 서로 전혀 관련 없는 네트워크 사이에서 위임자(witness) 모델 크로스체인 브리지를 통해 이루어지는 것입니다. 이러한 크로스체인의 보안성은 브리지 운영자에게 달려 있으며, 역사적으로 위임자 모델 크로스체인 브리지가 해킹당한 사건이 반복적으로 발생했습니다.
반면 롤업(Rollup)과 ETH 메인넷 사이의 크로스체인 행위는 위와 본질적으로 다릅니다. 왜냐하면 Layer2의 상태는 Layer1에 기록된 데이터에 의해 결정되기 때문입니다. Rollup 공식 크로스체인 브리지를 사용한다면, 운용 구조상 절대적으로 안전합니다.
이는 롤업의 본질을 강조하는데, 사용자 입장에서는 독립된 체인처럼 보이지만 실제로所谓 「Layer2」는 사용자에게 열린 빠른 전시장에 불과하며, 실제 체인 구조는 여전히 Layer1에 기록되어 있습니다. 따라서 우리는 L2를 반쪽짜리 체인 또는 "Layer1 위에 만들어진 체인"이라고 생각할 수 있습니다.
재시도 가능한 티켓(Retryables)
주의할 점은 크로스체인이 모두 비동기적이며 비원자적이라는 점입니다. 마치 한 체인에서 트랜잭션을 수행하고 결과를 즉시 확인하듯 할 수 없으며, 다른 측에서 특정 시간 내에 무언가가 일어날 것이라는 보장도 없습니다. 따라서 크로스체인은 일부 소프트웨어 문제로 인해 실패할 수 있지만, 올바른 방법—예를 들어 재시도 가능한 티켓(Retryable Ticket)—을 사용하면 자금이 막히는 등의 하드한 문제가 발생하지 않습니다.
재시도 가능한 티켓은 Arbitrum 공식 브리지를 통한 충전 시 사용되는 기본 도구이며, ETH 및 ERC20 충전 시 모두 사용됩니다. 그 수명 주기는 세 단계로 나뉩니다:
1. L1에서 티켓 제출. Delayed Inbox 계약에서 createRetryableTicket() 메서드를 사용하여 충전 티켓을 생성하고 제출합니다.
2. L2에서 자동으로 현금화. 대부분의 경우 정렬기가 사용자를 대신하여 티켓을 자동으로 현금화해주므로 추가 조작이 필요하지 않습니다.
3. L2에서 수동으로 현금화. 일부 예외적인 경우, 예를 들어 L2의 가스 가격이 갑자기 급등하여 티켓에 미리 지불한 가스가 부족할 경우 자동 현금화가 불가능합니다. 이때 사용자가 수동으로 조작해야 합니다.
참고로, 자동 현금화가 실패할 경우 7일 이내에 수동으로 티켓을 현금화해야 하며, 그렇지 않으면 티켓이 삭제되어(자금 영구 손실) 또는 티켓 보관을 위해 일정 수수료를 지불하여 연장을 해야 합니다.
또한 Arbitrum 공식 브리지의 출금 프로세스는 충전 프로세스와 일정한 대칭성을 갖지만 Retryables 개념은 존재하지 않습니다. 이것은 부분적으로 Rollup 프로토콜 자체에서 이해할 수 있으며, 몇 가지 차이점을 통해 이해할 수 있습니다:
-
출금 과정에는 자동 현금화가 존재하지 않습니다. EVM에는 타이머나 자동화 기능이 없으며, L2에서 자동 현금화가 가능한 것은 정렬기의 도움 덕분이므로, L1 사용자는 Outbox 계약과 수동으로 상호 작용하여 자산을 회수(Claim)해야 합니다.
-
출금에는 또한 티켓 만료 문제가 없습니다. 도전 기간이 지나면 언제든지 수령할 수 있습니다.
ERC-20 자산 크로스체인 Gateway
ERC-20 자산의 크로스체인은 매우 복잡합니다. 다음 질문들을 생각해볼 수 있습니다:
-
L1에 배포된 토큰은 L2에 어떻게 배포될 수 있을까요?
-
그 L2 대응 계약은 사전에 수동으로 배포되어야 하나요, 아니면 시스템이 아직 계약이 배포되지 않은 토큰에 대해 자동으로 자산 계약을 배포할 수 있을까요?
-
L1의 ERC-20 자산은 L2에서 어떤 계약 주소를 가져야 하나요? L1과 동일해야 하나요?
-
L2에서 원생 발행된 토큰은 어떻게 L1으로 크로스체인 될 수 있나요?
-
수량 조절이 가능한 Rebase형 토큰, 자동 성장 수익 토큰 등 특수 기능을 가진 토큰은 어떻게 크로스체인 되나요?
우리는 이러한 모든 질문들에 답하려 하지 않으며, 이는 너무 복잡하기 때문입니다. 이 질문들은 오직 ERC20 크로스체인의 복잡성을 설명하기 위한 것입니다.
현재 많은 확장 솔루션들이 다양한 복잡한 문제와 경계 사례를 피하기 위해 화이트리스트 + 수동 목록 방식을 사용하고 있습니다.
Arbitrum는 Gateway 시스템을 사용하여 대부분의 ERC20 크로스체인 문제를 해결하였으며, 다음과 같은 특징을 가지고 있습니다:
-
Gateway 구성 요소는 L1과 L2에 쌍으로 존재합니다.
-
Gateway Router는 Token L1<->Token L2 사이의 주소 매핑, 그리고 some token<->some gateway 사이의 매핑을 관리합니다.
-
Gateway 자체는 StandardERC20 gateway, Generic-custom gateway, Custom gateway 등으로 나뉘어 다양한 유형과 기능의 ERC20 브리징 문제를 해결합니다.
보다 간단한 WETH 크로스체인 예를 들어 사용자 정의 gateway의 필요성을 설명하겠습니다.
WETH는 ETH의 ERC20 동등물입니다. Ether는 주화폐로서 많은 dApp의 복잡한 기능을 실현할 수 없으므로 ERC20 동등물이 필요합니다. WETH 계약에 일정량의 ETH를 입금하면 계약 내에 잠기게 되며, 동일한 수량의 WETH가 생성됩니다.
마찬가지로 WETH를 소각하여 ETH를 인출할 수도 있습니다. 분명히,유통되는 WETH와 예치된 ETH의 수량은 항상 1:1 비율입니다.
만약 지금 WETH를 직접 L2로 크로스체인 한다면 이상한 문제가 발생합니다:
-
L2에서 WETH를 언랩(Unwrap)하여 ETH로 바꾸는 것이 불가능합니다. 왜냐하면 L2에는 해당하는 ETH 예치가 없기 때문입니다.
-
랩(Wrap) 기능은 사용 가능하지만, 새로 생성된 이 WETH를 다시 L1으로 크로스체인할 경우 L1에서 ETH로 언랩할 수 없습니다. 왜냐하면 L1과 L2의 WETH 계약이 '대칭적'이 아니기 때문입니다.
분명히 이것은 WETH의 설계 원리를 위반합니다. 따라서 WETH를 크로스체인할 때 충전이나 출금 모두 먼저 ETH로 언랩한 후 크로스체인하고, 그다음 다시 WETH로 랩해야 합니다. 이것이 바로 WETH Gateway의 역할입니다.
더 복잡한 논리를 가진 다른 토큰들도 마찬가지로, 더 복잡하고 정교하게 설계된 Gateway가 있어야만 크로스체인 환경에서 정상적으로 작동할 수 있습니다. Arbitrum의 사용자 정의 Gateway는 일반 Gateway의 크로스체인 통신 로직을 상속받아 개발자가 토큰 논리와 관련된 크로스체인 행동을 커스터마이징할 수 있도록 하여 대부분의 요구사항을 충족시킵니다.
지연된 우편함(Delayed Inbox)
빠른 우편함(Slow Inbox), 즉 SequencerInbox와 대응되는 것은느린 우편함(Inbox, 전칭 Delayed Inbox)입니다. 왜 빠름과 느림의 구분이 필요할까요? 왜냐하면 빠른 우편함은 전적으로 정렬기가 게시한 L2 트랜잭션 배치(Batch)를 수신하기 위한 것이며, 정렬기에 의해 L2 네트워크 내에서 사전 처리되지 않은 트랜잭션은 빠른 우편함 계약에 나타나서는 안 됩니다.
지연된 우편함의 첫 번째 역할은 L1에서 L2로의 충전 행위를 처리하는 것입니다. 사용자가 느린 우편함을 통해 충전하면, 정렬기가 이를 감지하여 L2에 반영하며, 결국 이 충전 기록은 정렬기에 의해 L2 트랜잭션 시퀀스에 포함되고, 빠른 우편함 계약(Ssequencer Inbox)에 제출됩니다.
이 예시에서, 사용자가 직접 충전 트랜잭션을 빠른 우편함에 제출하는 것은 적절하지 않습니다. 왜냐하면 빠른 우편함(Ssequencer Inbox)에 제출된 트랜잭션은 Layer2의 정상적인 트랜잭션 정렬을 방해하고, 정렬기의 작업에 영향을 줄 수 있기 때문입니다.
지연된 우편함의 두 번째 역할은 검열 저항입니다. 사용자가 직접 느린 우편함 계약에 제출한 트랜잭션은 정렬기가 일반적으로 10분 이내에 빠른 우편함에 집계합니다. 그러나 정렬기가 악의적으로 요청을 무시할 경우, 느린 우편함에는 강제 집계(force inclusion) 기능이 있습니다:
거래가 Delayed Inbox에 제출된 후 24시간이 지났음에도 불구하고 느린 우편함의 거래가 정렬기에 의해 거래 시퀀스에 포함되지 않았다면, 사용자는 Layer1에서 force inclusion 함수를 수동으로 트리거하여 정렬기에 의해 무시된 거래 요청을 강제로 빠른 우편함(Ssequencer Inbox)에 포함시킬 수 있으며, 이후 Arbitrum One 노드 전체가 이를 감지하게 되고, Layer2 거래 시퀀스에 강제로 포함됩니다.
앞서 언급했듯이, 빠른 우편함의 데이터는 L2의 역사적 데이터 실체입니다. 따라서 악의적인 검열 상황에서도 느린 우편함을 통해 거래 명령이 궁극적으로 L2 장부에 포함될 수 있으며, 이는 강제 출금 등 Layer2 탈출 시나리오를 포함합니다.
이를 통해 어느 방향과 계층의 거래라도 정렬기는 궁극적으로 당신을 영구적으로 검열할 수 없다는 것을 알 수 있습니다.
지연된 우편함(Inbox)의 주요 핵심 함수들:
-
depositETH(), 가장 간단한 ETH 충전 함수.
-
createRetryableTicket(), ETH, ERC20 및 메시지 충전에 사용 가능. depositETH()에 비해 더 높은 유연성을 제공하며, 예를 들어 충전 후 L2 수취 주소를 지정할 수 있습니다.
-
forceInclusion(), 즉 강제 집계 기능, 누구나 호출 가능. 이 함수는 느린 우편함 계약에 제출된 특정 거래가 24시간 이상 처리되지 않았는지 검증합니다. 조건이 충족되면 메시지를 강제로 집계합니다.
다만 참고로, force Inclusion 함수는 실제로는 빠른 우편함 계약에 위치해 있지만 이해를 돕기 위해 느린 우편함에서 함께 설명합니다.
아웃박스(Outbox)
아웃박스(Outbox)는 출금과만 관련되며, 출금 행위의 기록 및 관리 시스템으로 이해할 수 있습니다:
-
Arbitrum 공식 브리지의 출금은 약 7일의 도전 기간이 지난 후, Rollup 블록이 최종 확정된 후에야 실행될 수 있다는 것을 알고 있습니다. 사용자는 도전 기간 종료 후 Layer1의 아웃박스 계약에 해당 Merkle Proof를 제출하고, 이는 다른 기능 계약과 통신하여(예: 다른 계약에 잠긴 자산 해제) 최종적으로 출금을 완료합니다.
-
아웃박스 계약은 어떤 L2에서 L1로의 크로스체인 메시지가 이미 처리되었는지를 기록하여, 누군가 이미 실행된 출금 요청을 반복 제출하는 것을 방지합니다. 이는
-
mapping(uint256 => bytes32) public spent를 통해 출금 요청의 spent Index와 정보의 대응 관계를 기록하며, 만약 mapping[spentIndex] != bytes32(0)이면 해당 요청은 이미 출금되었습니다. 원리적으로 재송 신공격 방지를 위한 트랜잭션 카운터 Nonce와 유사합니다.
아래에서는 ETH를 예로 들어 충전 및 출금 프로세스를 완전히 설명하겠습니다. ERC20의 경우 단지 Gateway를 거쳤다는 점만 다르며, 이에 대해서는 따로 설명하지 않겠습니다.
ETH 충전
1. 사용자가 느린 우편함의 depositETH() 함수를 호출합니다.
2. 해당 함수는 bridge.enqueueDelayedMessage()를 계속 호출하여 bridge 계약에 메시지를 기록하고 ETH를 bridge 계약으로 전송합니다. 모든 ETH 충전 자금은 bridge 계약에 보관되며, 일종의 충전 주소 역할을 합니다.
3. 정렬기가 느린 우편함의 충전 메시지를 감지하여 L2 데이터베이스에 충전 작업을 반영하며, 사용자는 L2 네트워크에서 자신이 입금한 자산을 확인할 수 있습니다.
4. 정렬기는 이 충전 기록을 트랜잭션 배치(batch)에 포함하여 L1의 빠른 우편함 계약에 제출합니다.
ETH 출금
1. 사용자가 L2에서 ArbSys 계약의 withdrawEth() 함수를 호출하여 L2에서 해당 수량의 ETH를 소각합니다.
2. 정렬기가 이 출금 요청을 빠른 우편함으로 전송합니다.
3. 검증자(Validator) 노드는 빠른 우편함의 트랜잭션 시퀀스에 따라 새로운 Rollup 블록을 생성하며, 이 블록에는 위의 출금 거래가 포함됩니다.
4. Rollup 블록이 도전 기간을 지나 승인되면, 사용자는 L1에서 Outbox.executeTransaction() 함수를 호출하여 앞서 언급된 ArbSys 계약에서 제공된 매개변수를 증명할 수 있습니다.
5. 아웃박스 계약이 확인 후 bridge 계약에서 해당 수량의 ETH를 해제하여 사용자에게 전송합니다.
빠른 출금
낙관적 롤업 공식 브리지를 사용하여 출금하면 도전 기간 대기 문제가 발생합니다. 이 문제를 회피하기 위해 민간 제3자 크로스체인 브리지를 사용할 수 있습니다:
-
원자적 스왑. 이 방식은 양측이 각자의 체인 내에서 자산을 교환하는 것으로, 원자성이 있으며, 한쪽이 Preimage를 제공하면 양측 모두 필요한 자산을 반드시 얻을 수 있습니다. 하지만 문제는 유동성이 비교적 부족하며, 상대방을 일대일로 찾아야 한다는 점입니다.
-
위임자 크로스체인 브리지. 일반적인 유형의 크로스체인 브리지는 모두 위임자 브리지에 속합니다. 사용자가 자신의 출금 요청을 제출하면, 출금 목적지는 제3자 브리지 운영자 또는 유동성 풀을 향합니다. 위임자가 L1의 빠른 우편함 계약에 크로스체인 거래가 제출되었음을 발견하면 L1 측에서 사용자에게 즉시 송금할 수 있습니다. 이 방식은 본질적으로 또 다른 합의 시스템을 사용하여 Layer2를 감시하고 Layer1에 제출된 데이터에 따라 작동합니다. 문제는 이 모델 하에서의 보안 수준이 Rollup 공식 브리지만큼 높지 않다는 점입니다.
강제 출금
force Inclusion() 강제 집계 기능은 정렬기의 검열에 대항하기 위해 사용되며, L2 로컬 거래, L1에서 L2로의 거래 및 L2에서 L1로의 거래 모두 이 기능을 사용할 수 있습니다. 정렬기의 악의적 검열은 거래 경험에 심각한 영향을 미치며, 대부분의 경우 L2를 떠나 출금을 선택하기 때문에 아래에서는 강제 출금을 예로 들어 forceInclusion의 사용법을 설명합니다.
ETH 출금 단계를 되돌아보면, 정렬기 검열과 관련된 것은 단지 1단계와 2단계뿐이므로 이 두 단계만 변경하면 됩니다:
-
L1의 느린 우편함 계약에서 inbox.sendL2Message()를 호출하고, 입력 매개변수는 L2에서 withdrawEth()를 호출할 때 입력해야 하는 매개변수입니다. 이 메시지는 L1의 bridge 계약과 공유됩니다.
-
24시간의 강제 집계 대기 기간 후, 빠른 우편함의 force Inclusion()을 호출하여 강제 집계를 수행하며, 빠른 우편함 계약은 bridge에 해당 메시지가 있는지 확인합니다.
최종적으로 사용자는 아웃박스에서 출금할 수 있으며, 나머지 단계는 정상적인 출금과 동일합니다.
또한 arbitrum-tutorials에는 Arb SDK를 사용하여 forceInclusion()을 통해 L2 로컬 거래 및 L2에서 L1로의 거래를 수행하는 방법에 대한 자세한 튜토리얼이 있습니다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
@godrealmx
