Arbitrum (1) — Architecture & Economics
1. Intro
2021년 8월 21일, 아비트럼의 개발사 Offchain Labs는 Arbitrum One Mainnet을 출시하였다. 아비트럼 체인은 이더리움이 가직 보안성의 장점을 취하면서, 저비용으로 확장성을 달성하는 L2 Scaling 솔루션이다.
‘옵티미스틱 롤업’이라는 기술을 사용하여 L2에서 트랜잭션을 수행하고, 트랜잭션을 모아 batch를 형성하여 이더리움 메인체인에 기록한다. 이를 통해 트랜잭션의 처리량(throughput)을 높이고, 수수료는 낮출 수 있다. 또한, 아비트럼 시스템은 높은 호환성으로 EVM 컨트랙트와 이더리움 트랜잭션을 L2에서 변형없이 수행할 수 있도록 하고 있다. 이러한 장점으로 인해 AAVE, Balancer, Band Protocol, Curve, Sushiswap 과 Uniswap 등은 아비트럼을 이미 사용중이거나, 사용을 적극 검토중이다. 본 글에서는 각광받는 L2 솔루션인 아비트럼의 전반적 구조와 토큰 경제에 대해 High-level에서 살펴보고자 한다.
2. Arbitrum Architecture — Layer1
아비트럼 아키텍쳐는 Layer1(Ethereum), Layer2(Arbitrum One Mainnet), Off-chain으로 구성되어있다. Layer1의 구성요소는 아래와 같다.
2.1. Ethereum
이더리움은 아비트럼 시스템의 보안성을 제공하는 원천이다.
2.2. Ethereum Ethbridge Contract
이더리움 상에는 EthBridge가 있는데, 이는 아비트럼 체인을 통제하는 이더리움 컨트랙트의 집합이다. EthBridge Contract들의 구성은 아래와 같다.
- Inbox Contract는 아비트럼 체인의 inbox를 관리한다. inbox는 아비트럼 체인 내에서 트랜잭션을 처리하고 관리하는 공간이다. 이 컨트랙트를 통하여 아비트럼 체인의 인박스로 메시지를 넣을 수 있다.
- Outbox Contract는 아비트럼 체인의 outbox을 관리한다. outbox는 트랜잭션 처리의 결과값들을 보관하는 공간이다. 최종적으로는 아비트럼 체인 위의 롤업 블록에서 생성된 아웃풋들이 outbox에 놓아진다. 이 아웃풋 결과들은 bridging을 통해 이더리움에 다시 투영된다(bridging 과정은 후속 글에서 다룬다)
- Rollup Contract는 아비트럼 체인의 롤업 프로토콜을 관리한다. 아비트럼 체인에서 제안, 승인 혹은 거절된 롤업 블록은 무엇인지, 누가 어떤 롤업 노드에 스테이크했는지 등을 확인한다. 이를 통해 아비트럼 체인 전반의 스테이트를 트래킹하는 역할을 한다.
- Challange Contract는 아비트럼 체인에서 어떤 롤업 블록이 옳은지에 관해 검증인 사이에서 생기는 분쟁을 트래킹하고 해결하는 역할을 한다.
요약하자면, EthBridge는 아비트럼 롤업 프로토콜을 감독하여 L2 아비트럼 체인의 정상적 작동을 보장한다. Ethbridge의 기타 특징들은 아래와 같다.
- EthBridge는 이더리움 위에서 작동하기 때문에 누구나 투명하게 확인할 수 있고, trustless하게 실행할 수 있다.
- User, L1 이더리움 컨트랙트, 아비트럼 노드들은 아비트럼 체인과 통신하기 위해 EthBridge 컨트랙트를 콜해야 한다.
- EthBridge는 아비트럼 체인의 inbox와 outbox를 보관하고 있어서, 유저들과 기타 컨트랙트가 아비트럼 체인에 트랜잭션 메시지를 보내고, 결과를 관찰 및 사용할 수 있도록 한다.
3. Arbitrum Architecture — Layer2
3.1. AVM Architecture
Arbitrum Virtual Machine은 아비트럼 스마트 컨트랙트를 돌리기 위한 환경으로 EthBridge위로 존재한다. 이더리움에서 구동되는 스마트 컨트랙트들은, AVM 에서 돌아가도록 변환되며, AVM 을 기준으로 L1(이더리움)과 L2(아비트럼 체인)가 구분된다. 종합하자면, L1은 inbox와 outbox 결과물 요약체를 가지고 있게 되고, L2의 AVM에서는 인풋을 읽어 아웃풋을 만들어내는 컴퓨터 프로그램을 실행하게 된다.
3.2. ArbOS
오프체인 랩스에서 작성한 소프트웨어 프로그램으로, AVM 을 구동, 기록 보관, 트래픽 관리와 더불어 아비트럼 체인 상의 스마트 컨트랙트 실행을 강제하는 역할을 수행한다. ArbOS는 후술하는 아비트럼 풀노드로 부터 압축된 트랜잭션을 전달받고, 압축을 풀어 오리지널 트랜잭션을 복원시킨다. 후에 ArbOS는 트랜잭션 상의 싸인을 검증하고 트랜잭션을 실행한다. ArbOS 는 완전히 L2 아비트럼 체인 상에서 동작하기 때문에 L2 연산의 저비용과 확장성의 장점을 가지고 있다.
3.3. EVM Compatibility
ArbOS는 스마트 컨트랙트를 위해 EVM compatible한 실행환경을 제공한다. 우리가 컨트랙트를 이더리움에 보내듯이, 컨트랙트의 EVM 코드를 ArbOS에 보낼 수 있다. ArbOS는 해당 컨트랙트를 로드하고 트랜잭션을 지원한다. ArbOS가 compatiblity의 세부사항까지 신경쓰므로, 스마트 컨트랙트 개발자는 코드를 이더리움에서 쓰듯이작성하기만 하면 된다
3.4.EVM Contracts
개발자들에 의해 아비트럼 체인으로 배포된 컨트랙트들이며, 아비트럼 체인으로 제출된 트랜잭션들을 실행한다.
4. Arbitrum Architecture —Off-chain
4.1. Ethereum Nodes
이더리움 체인과 통신하기 위해서 사용된다.
4.2. Arbitrum Nodes
아비트럼 노드는 아비트럼 체인과 통신하기 위해서 사용된다. 일부 아비트럼 노드는 유저들의 요청사항을 서비스하기도 하고, 일부는 아비트럼 체인의 검증자로서만 기능하기도 한다.
- Validator Node
아비트럼 노드중 Validator Node는 아비트럼의 롤업 프로토콜에 참여하는 ‘검증인’ 노드를 의미한다. 이들은 아비트럼 체인의 스테이트를 안정적으로 진행시키는 역할을 한다. 원한다면 누구나 검증인 노드가 될 수는 있지만, 실제에서는 다음과 같은 주체들이 아비트럼 검증에 참여할 것으로 예상된다. 1) 오프체인 랩스로 부터 보상을 제공받고 아비트럼 체인 상의 검증인으로 고용된 자, 2) dapp 개발자나, 거래소, 헤비유저, 유동성 공급자 처럼 아비트럼 체인에 많은 양의 재산을 보유하여 투자자산을 지키고자 하는 자
또, 검증인 노드는 이더리움 상의 EthBridge 컨트랙트에 ETH를 스테이킹하여 스테이킹 노드가 되고, 새로운 아비트럼 블록을 제안할 수 있다. 신규로 제안된 블록은 처음에 unresolved 상태에 놓인다. 이 블록은 시간이 지남에 따라 confirm 되거나 reject되어 resolved 된 상태로 놓인다. 최종적으로 confirm 된 블록들이 confirmed history of chain 을 형성하게 된다.
만약 스테이킹 검증인 노드가 거짓말을 하거나, 챌린지에서 패배하는 경우 스테이킹으로 맡긴 수량 중 일부를 잃게 되며 이는 정직한 검증인들에게 분배된다.
EthBridge 컨트랙트는 현재 요구되는 스테이킹 양을 지속적으로 트래킹한다. 일반적인 경우에 필수 스테이킹 량은 아비트럼 체인의 디폴트 값으로 유지되지만, 아비트럼 체인의 생성이 너무 더디게 진행된다면, 요구량이 높아지게 된다. 스테이크 요구량이 높아지면, 딜레이 어택의 비용이 지수적으로 증가하게 되어 프로세스를 늦추는 악의적 주체의 행동을 막아낼 수 있다.
스테이킹 하지 않은 검증인 노드는 ‘watchtower validator’가 된다. 이들은 아비트럼 블록 형성에 참여하지는 않지만, 관찰하기만 하며 악의적 행동을 목격하면 블록에 참여하는 검증인들에게 주의를 주는 역할을 하게 된다.
- Full Node
아비트럼 체인 풀노드는 built-in AVM 에뮬레이터(emulator) 를 가지고 있어, 로컬하게 AVM의 카피를 돌린다. 이들의 중요한 역할 중 하나는 aggregator(이하, 집합자) 역할이다. 집합자는 유저로부터 싸인이 완료된 L2트랜잭션들을 받아서 트랜잭션 집합으로 된 배치(batch)를 형성하고, L1 의 인박스 컨트랙트로 제출한다.
트랜잭션 제출은 EthBridge의 inbox contract를 호출하는 L1 트랜잭션이기 때문에 트랜잭션을 하나씩 제출하는 것보다 배치단위로 제출하는 것이 가스비측면에서 효율적이다. 단, 아비트럼은 필요에 따라 개별 트랜잭션도 ‘배치’로 제출할 수 있도록 하였다.
풀 노드는 L1 공간차지를 줄이기 위해 압축을 진행한다. 유저가 제출한 일반 트랜잭션을 받아서, 압축을 진행하여 트랜잭션 내의 ‘헤더정보’를 훨씬 작게 만든다. 이렇게 압축처리가 진행된 트랜잭션을 L1의 인박스 컨트랙트에 보낸다. 이는 결국 L2의 ArbOS로 전달되고 L2에서는 해당 압축이 풀려서, 트랜잭션이 실행된다.
4.3. User
유저는 아비트럼과 통신하여 이를 사용한다. 유저들은 이더리움 사용하기 위한 툴들을 그대로 이용하여 아비트럼을 사용할 수 있다. 한편, 개발자들은 이더리움에 배포했던 디앱을 재작성 및 수정할 필요가 없다.
5. Economics
5.1. No Native Tokens!
아비트럼은 별도의 토큰을 가지고 있지 않다. 공동창업자 goldfeder에 의하면, 아비트럼은 단기에 토큰을 발행할 계획이 없으며, 투자 받은 $120M 은 순전한 현금자본조달(equity financing)이었다. 이는 대규모의 현금투자를 통해, 토큰발행수익없이 아비트럼 모델을 운영하겠다는 의지로 해석된다. 한편, goldfeder는 커뮤니티가 좌우하는 완전한 탈중앙 시스템이라는 장기적 목표를 위하여 추후에 자체 토큰을 발행될 수도 있음을 시사했다. 단기에 토큰을 발행 계획이 없어도 추후에 DAO가 토큰의 발행을 결정할 수 있다.
5.2. Transaction Fees — 트랜잭션 수수료를 받는 주체들
사용자는 L2에서 트랜잭션을 처리하기 위해 수수료를 내야 하며, 아비트럼 시스템은 이 수수료로 체인을 운영하기 위한 수익을 얻는다. 이 수수료는 L2의 ArbOS를 통해 측정되고 모아진다. 수수료는 ETH 단위이다.
오프체인 랩스 역시 자사의 수익모델로 아비트럼 L2체인의 수수료를 내세우고 있다. 오프체인 랩스는 ‘core fee structure’ 명목으로 아비트럼의 트랜잭션 수수료 중 일부를 징수하고 있는데, 팀은 현재의 수수료 구조가 성장에 적합하다고 믿고 있다.
또한, 아비트럼 시스템의 수수료 중 일부는 L2 아비트럼 체인의 거래를 모아서 L1에 제출하는 aggregating full node들에게 제공된다. 수수료의 나머지 부분은 검증인과 같은 네트워크 참여자에게 분배된다.
5.3. Transaction Fees — 트랜잭션 수수료를 내는 주체들
아비트럼 수수료는 크게 네가지 부분해서 발생하며, 모두 ETH 단위로 과금이 된다. 수수료가 발생하는 세부부분은 아래와 같다.
- L2 Transaction: L2 각 트랜잭션을 위한 기본수수료 (아비트럼에서 dApp을 사용하기 위한 비용, ArbGas를 감당하기 위해 아비트럼 체인에도 Eth를 예치해야한다)
- L1 calldata: L2 트랜잭션으로부터 직접적으로 발생하는 L1의 데이터 단위마다 발생하는 수수료
- Computation: L2 트랜잭션이 사용하는 ArbGas 단위마다의 수수료
- Storage: L2 상의 EVM 컨트랙트 스토리지 위치마다의 수수료. L2 트랜잭션으로 인한 EVM 스토리지의 순증가에 기반한다.
6. Conclusion
본 글에서는, L1과 L2로 이루어진 아비트럼의 구조와 아비트럼에서의 경제적 인센티브 구조를 살펴보았다. 위 내용에 따라 트랜잭션의 처리 흐름을 요약하자면 다음과 같다.
유저는 트랜잭션을 Aggregator 노드에게 제출한다(직접 EthBridge Inbox Contract로 보낼 수도 있다). Aggregator노드는 순서를 정하여 이를 싱글 배치로 만들고 Ethbridge Inbox Contract로 보낸다. 이후 이 트랜잭션은 L2의 ArbOS로 전달되어 블록을 생성하는 사람들에 의해 연산이 진행되고, 검증인에 의해 블록의 유효성이 검증되면, 트랜잭션 실행 결과는 L1에 기록된다.
아비트럼의 위와같은 흐름에서는 모든 수수료가 별도 토큰없이 ETH 단위로 부과된다. 또한 아비트럼의 L2는 이더리움과 바이트코드 레벨까지 호환이 되어서, 사용성은 아주 높다. 이로써 아비트럼은 이더리움의 확장성 제약으로 문제를 겪고 있는 많은 이가 쉽게 접근할 수 있는 L2솔루션이 될 수 있었다.
후속 글에서는, 아비트럼의 L1-L2간의 브릿징과 롤업 프로토콜에 대해 살펴보고자 한다.
