Arbitrum — Rollup & Bridging
본 글은 아비트럼에 관한 두번째 글로, 이더리움의 L2 솔루션인 아비트럼의 롤업 프로토콜과 L1-L2 브릿징에 대해 다룬다. 아비트럼 시스템과 관련한 high-level 내용은 ‘Arbitrum — Architecture & Economics’ 글에서 다루고 있다.
1. Arbitrum Rollup Protocol
롤업 프로토콜은 아비트럼 체인(L2)에서 생성되는 롤업 블록(이는 이더리움 메인넷 상의 블록과는 다른 것이다)의 결과물을 확인 및 검증하는 역할을 한다.
롤업 프로토콜이 필요한 이유는 무엇일까? 첫째, 누군가가 트랜잭션 실행결과에 대한 거짓말을 할 수 있고, 이 주체가 누구인지 잡아낼 수 있어야 한다. 둘째, 이더리움은 L2트랜잭션 처리의 개별 내용은 모르기 때문에, 믿을 수 있는 결과를 볼 수 있도록 검증된 결과를 제공해야 한다.
2. Optimistic Rollup in Arbitrum
본 단락에서는 아비트럼이 사용하는 롤업 기법인 Optimistic Rollup의 특징과 역할에 대해 알아보고자 한다.
2.1. Optimistic Rollup
옵티미스틱 롤업은 EVM 호환의 L2 솔루션으로, 주요 특징은 다음과 같다.
- 트랜잭션 데이터가 온체인(L1)에 보관된다.
- 실행은 오프체인(L2)에서 일어난다.
- 새로운 스테이트가 정기적으로 L1 스마트 컨트랙트에 제안된다.
- EVM compatible하여 일반적인 스마트 컨트랙트 로직을 지원하며, 따라서 기존재(pre-existing)하는 L1 어플리케이션을 L2로 넘기기 쉽다.
노드 운영자(Node operator)들은 다수의 L2 거래데이터를 batch 로 묶어 L1에 포스팅한다. 이때 타 검증인 노드(Validator Node operator)들에 의해 Batch의 유효성에 관한 챌린지를 받게 될 수 있지만, 검증인은 유효하다고 예상하는 Rollup batch를 우선적으로 포스팅하여 스테이트를 진행시킨다.
2.2. Optimistic Rollup: Optimistic Ethereum vs Arbitrum
옵티미스틱 롤업 기술을 사용하고 있는 가장 대표적인 프로젝트는 옵티미스틱 이더리움(Optimistic Ethereum)과 아비트럼(Arbitrum)이다. 두 서비스의 가장 큰 차이는 Fraud Proof Logic에 있는데, OE에서는 single-round proving을 사용하고, 아비트럼은 interactive multi-round proving을 사용하고 있다.
2.3 Multi-round Interactive Fraud Proving
아비트럼 노드운영자는 N개의 L2 트랜잭션을 batch로 묶어서 L1에 퍼블리쉬하며 새로운 스테이트 트랜지션를 제안한다. 만약 도전자가 트랜지션이 잘못되었다고 주장하면, 아비트럼의 fraud proof logic 이 발동한다.
도전자가 문제점을 명확히 찝어낼 수 있도록, 노드 운영자는 N개 인스트럭션 집합을 반으로 나누어 제시해주고, 도전자는 양분된 집합 중 어디에 유효하지 않은 transition이 있는지 찾아낸다. 이때 L1의 사기 증명 컨트랙트에서 운영자의 스테이트 해쉬와 오전자의 스테이트 해쉬를 비교하는 single step proof로 검증이 이루어진다. 이 같은 과정은 하나의 instruction이 남을 때까지 반복되어 multi-round interactive fraud proving이 된다.
도전자의 도전이 있었음에도, 분쟁조정기간 내에 스테이트 변화의 유효성에 관한 증명이 이루어지지 않으면, 분쟁조정기간의 만료시점에 운영자의 원주장과 도전자의 도전은 모두 유효하지 않은 것으로 간주된다. 도전자는 성공적인 태클을 위하여, 분쟁조정시간 내에 하나의 유효하지 않은 거래를 찾아내어야 하는 것이다.
Arbitrum의 multi-round interactive proving이 OE의 single-round proving에 비해 가지는 장점은 다음과 같다.
- OE의 single round proving에서는 L1 사기 증명 컨트랙트가 증명을 위하여 전체 트랜잭션을 모사(emulate)해야 하는반면, 아비트럼의 interactive proving에서는 운영자와 도전자의 스테이트 해쉬값을 비교하므로, 아비트럼은 L1 가스 사용량 측면에서 효율적이다.
- Arbitrum 롤업은 매우 복잡한 트랜잭션도 수행할 수 있게 되었다. OE의 싱글라운드 롤업에서는, 싱글 볼록에 담길 수 있는 트랜잭션만이 지원된다. 반명 멀티 라운드 proving에서는, 개별 트랜잭션이 온체인 가스 리밋에 제한되지 않으며, 컨트랙트 사이즈 제한도 없다.
3.Bridging L1-L2
위 그림은 L1에 이더리움을 예치하여, L2에서 사용할 수 있는 이더리움을 만드는 과정이다. 반대로 L2 아비트럼에서 사용하던 이더리움을 인출하여 L1에서 다시 사용할 수도 있다. 이를 가능하게 하는 것이 아비트럼 브릿지로, 아비트럼 브릿지는 현재 이더리움 뿐 아니라, ERC-20, ERC-721 토큰의 브릿징까지 지원하고 있다. 이는 이더리움 위에서 사용하는 어떤 자산이든 아비트럼 L2위에서 사용할 수 있음을 의미한다.
L1 컨트랙트와 L2 컨트랙트는 어떻게 상호소통할까? L1과 L2 체인은 서로 비동기적으로 운영되어서 두개의 체인이 하나의 트랜잭션을 통해 결과를 만들어내는 크로스체인 콜은 실행하기 어렵다. 즉, 크로스체인 콜은 콜링 컨트랙트(콜을 부른 주체)에게 보이는 단일결과를 절대 만들어낼 수 없다. 이를 해결하기 위해서는 크로스체인 콜 역시 비동기적으로 이루어져야 한다. 이는 콜러가 특정시간에 콜을 제출하면 일정 시간 이후에 해당 콜이 돌아가는 방법을 의미한다.
3.1. L1 to L2 : L1 contracts can submit L2 transactions
L1 컨트랙트는 EthBridge 컨트랙트를 호출하여 L2에 트랜잭션을 제출할 수 있다. L2 트랜잭션은 직전에 상술한 ‘비동기의 원칙’에 따라 특정 시간 이후에 돌아갈 것이다. L2트랜잭션에 의해 만들어진 결과물은 L1 콜러가 확인할 수 없다.
이런 방식의 시스템은 L1 콜러가 L2 가스가격과 맥스 가스량을 제대로 예측하지 못했을 때, L2 트랜잭션이 결국 revert 될 수 있다는 단점이 있다. L1 콜러는 L2 트랜잭션의 결과를 볼 수 없어서, L2 트랜잭션이 성공할 것이라는 보장을 할 수 없다.
L1에 토큰을 예치하고, L2 특정주소에 토큰을 생성하는 트랜잭션이 있다하자. 만약 L1쪽 트랜잭션은 성공하고, L2 쪽 트랜잭션은 revert 되면, L1 inbox 컨트랙트에 구제불가능한 상태의 토큰을 전송한 것이 된다.
3.2. L1 to L2 : ticket-based transactions
다행히도, L1 to L2 call 을 위한 다른 방법이 있는데, 이는 가스 관련 실패 관련해서 더욱 로버스트한 ‘티켓 방식’을 사용한다. L1 컨트랙트는 예비포장된 트랜잭션을 제출하여, 제출을 증빙하는 티켓ID를 받는다. 이후, 누구나 이 티켓ID를 제공하여, L2상의 기컴파일된 특수한 컨트랙트를 부를 수 있고, 티켓ID를 소각해서 이 트랜잭션을 실행할 수 있게 된다.
예비포장된 트랜잭션은 sender의 주소와, 목적지 주소, 콜밸류, 그리고 콜데이터를 가지고 있다. 필요시, callvalue 만큼 sender의 잔고에서 토큰을 차감하여, 예비포장된 트랜잭션에 부착한다.
티켓이 소각되면, 트랜잭션이 처리되는 동시에 영수증이 발금된다. 만약 티켓 소각이 진행되지 못하면, 티켓 ID는 다음을 위해 유효하게 남아있게 된다.
트랜잭션을 제출하면, 제출한 당사자는 ETH 로 책정된 비용을 지불해야 하는데 이 가격은 트랜잭션의 콜데이터의 사이즈에 따라 달라진다. 한번 제출이 이루어지면, 티켓은 약 일주일동안 유효하며, 이를 살리기 위한 주단위 렌트 비용을 지불하면 그 이후에도 유효하게 남아있을 수 있게 된다. 만약 이 렌트비용이 미지급되면 티켓은 삭제 된다.
이러한 rent-based 메커니즘은 다이렉트한 L1 to L2 통신 과정에 비해 장애가 많지만, 이렇게 하면 제출 비용이 예측가능하고, 제출비용을 지급하기만 하면 티켓을 언제든 구제할 수 있다는 장점이 있다. 티켓을 구제하고자 하는 욕구가 있다면, L2 트랜잭션은 결국 실행이 되고, 드랍되지 않을 것이다.
3.3. L2 to L1 : ticket-based calls
L2에서 L1을 부르는 방식도 위와 비슷한 ticket 방식을 채택한다. L2 컨트랙트가 기컴파일 된 ArbSys 컨트랙트의 메소드를 불러서, L1으로 트랜잭션을 보낼 수 있다. L2 트랜잭션의 실행을 L1에서 확인하게 되면, L1의 EthBridge를 통해 티켓ID가 만들어진다. 이 티켓은 L1 트랜잭션이 무사히 실행되었을때에 비로소 소각된다. L1에서 트랜잭션이 처리되지 못하면 티켓은 계속 남아 있게 되는데,이때는 티켓의 존속을 위해 사용자가 렌트비용을 지불할 필요가 없다. 해당 비용은 네트워크 수수료로 보전되는데, 이 수수료는 아비트럼의 다른 부분들에서 모여진다.
