Arbitrum 아비트럼 블록체인 구조 이해하기

최근 아비트럼이 자체 거버넌스 토큰인 $ARB 를 발행하면서, 많은 관심을 받고 있다. GMX, Camelot 같은 트렌디한 Defi들이 출시되면서 체인의 TVL도 급격히 높이고 있는 추세다. 

다양한 옵티미즘 롤업 기반 체인들이 있지만 그중에서 가장 높은 TPS를 구현한 아비트럼이기에, 이더리움의 보안을 빌려 높은 확장성을 유지하는 아비트럼에 매력적인 서비스들이 많이 운영되고 있는 것같다.

아무튼 간단한 구조를 정리해보면 다음과 같다.

아비트럼 네트워크는 Sequencer와 Validator 이 두 노드에 의해서 실행되어 Ethereum 메인넷과 상호 작용한다.

Sequencer는 유저의 L2 트랜잭션을 가져와 L1에 제출하고, Validator는 L1의 트랜잭션 데이터를 읽고 트랜잭션을 처리하여 L2 state를 갱신하는 역할을 담당한다. Validator는 업데이트된 L2 state 데이터를 L1에 게시하여 누구나 이 새 state의 유효성을 확인할 수 있도록한다.

workflow step 1~6

[Workflow]

1. 유저가 L2 트랜잭션을 Sequencer(Batcher라고도 함)로 보낸다.
2. Sequencer가 트랜잭션을 충분히 수신하면 Batch 형태로 L1 Smart contract에 일괄적으로 POST한다.
3. Validator는 L1 Smart contract에서 이 트랜잭션을 읽고 L2 state의 로컬 복사본으로 처리한다.
4. 처리가 완료되면 새로운 L2 state가 로컬로 생성되고 Validator는 이 새 state 루트를 L1 Smart contract에 POST한다.
5. 모든 Validator는 L2 state의 로컬 복사본의 동일한 트랜잭션을 처리한다.
6. Validator는 이 L2 state 루트와 L1 Smart contract를 비교한다.
7. Validator 중 하나가 L1에 POST된 것과 다른 state 루트를 얻게되면, Validator는 L1에서 챌린지를 시작한다.
8. 챌린지에서 챌린저인 Validator와 원래 state 루트를 POST한 Validator가 번갈아가며 올바른 state 루트를 증명한다.
9. 챌린저에서 지면 스테이킹된 Deposit은 삭감된다.
10. L2 state 루트가 유효하지 않을 경우 Validator에 의해서 삭제되고 L2 체인에 포함되지 않는다.

여기서 주목할 점은 벨리데이터가 로컬로 생성된 L2 State를 검증을 거치지않고 먼저 L1의 컨트랙트에 POST하는 것이다. 그리고 만약 POST된 State가 다를 경우 그때 검증을 위한 챌린지가 시작된다.

Validator

롤업은 Validator가 L2 state 데이터를 제출하고 저장한 Smart contract 세트를 말한다. 각 블록은 L2 상태 데이터의 해시가 포함된다. Validator는 Sequenser Inbox에서 트랜잭션을 읽고 처리한 다음 업데이트된 L2 state 데이터 해시를 롤업 스마트 계약에 POST한다. 이 데이터로 새 블록을 만들고 체인에 최신 블록을 추가한다.

챌린지를 통해 Invalid State Data로 판명날 경우, Staker 4와 Staker 6 검증자의 지분(ETH)은 삭감된다.

다음 조건이 모두 충족되면 L1에 영구적으로 추가된다.

• 블록 생성 후 7일 경과
• 챌린지가 진행 중인 블록이 없음
• 하나 이상의 스테이커가 존재

Transaction Data Store

Aggregator 노드와 sequencer 노드는 L2 트랜잭션을 수신하여 L1 relayed와 sequencer Inbox에 전송한다. 이 데이터를 L1에 전송하는 것은 비용을 발생시키는데, 이는 L2에서 발생하는 비용의 대부분을 차지한다고 볼 수 있다.

따라서, L1에 이 데이터를 저장하는 것과 스토리지 용량을 최대한 줄이는 것이 중요하다.

Aggregator 노드는 유저의 L2 트랜잭션을 수신하고 calldata를 바이트 배열로 압축하고 난 다음, 압축 트랜잭션의 여러 개를 트랜잭션 배치로 알려진 바이트 배열로 결합한다.

마지막으로 트랜잭션 배치를 Delayed Inbox에 제출한다. Inbox는 트랜잭션 배치를 해쉬화하고 이 해쉬를 Contract Storage에 저장한다.

Sequencer노드는 비슷한 패턴을 수행하지만 Sequencer Inbox에는 Delayed Inbox에서 포함된 메시지 수에 대한 데이터도 포함되어야 한다. 이 데이터는 Sequencer의 Inbox의 Contract Storage에 저장하는 최종 해시값을 결정하는 요소가 된다.

State data Storage

Validator는 Sequencer 수신함에서 L2 트랜잭션을 읽고 처리한 후, 업데이트 된 L2 state 데이터를 L1의 롤업 스마트 계약에 제출한다.

그 다음, 롤업 Smart contract는 state 데이터를 해시화하고 해시를 Contract storage에 저장한다.

 

Retrieving Transaction and State Data

Contract storage에는 트랜잭션의 해시와 State data만 저장되지만 다른 노드들은 원본 데이터를 볼 수 있다. 이는 L1에 제출된 트랜잭션의 calldata로 이더리움의 풀노드에서 검색하여 확인가능하다.

Delayed, Sequencer의 Inbox의 트랜잭션의 calldata는 Aggregater, Sequencer가 처리한 모든 L2 트랜잭션에 대한 데이터가 포함된다. 롤업 Contract의 트랜잭션 calldata는 L2에 대한 모든 state 데이터가 포함되어 있다. 이 데이터는 다른 Validator가 그 시점에서 유효한 것인지 판단할 수 있다.

Validator가 POST하는 Smart contract는 전체 트랜잭션이나 State 데이터가 아닌, state 데이터의 해시값만 저장하기 때문에 가스비가 많이 절약된다. 롤업의 주된 비용은 이 데이터를 L1에 저장하는 것에서 시작한다.

참고 : https://medium.com/privacy-scaling-explorations/a-technical-introduction-to-arbitrums-optimistic-rollup-860955ea5fec