Arbitrum 아비트럼 트랜잭션 라이프사이클

아비트럼에서 다양한 컴포넌트에 대한 설명부터, 클라이언트가 서명한 트랜잭션이 생성되어 레이어 1에서 컨펌되는 과정을 단계별로 정리해본다.

지난 포스팅에서 블록체인의 간단한 구조를 정리했는데, 트랜잭션의 라이프사이클만 확인해도 전체적인 프로세스를 이해하는 데 많은 도움이 된다.

Arbitrum Tx 전체적인 lifecycle

1. Sequencer의 트랜잭션 수신

트랜잭션 라이프사이클의 시작은 Sequencer가 클라이언트로부터 트랜잭션을 수신하면서 시작된다. Sequencer는 두 가지의 방법으로 트랜잭션을 수신한다.

Directly/Offchain / Delayed Inbox

• Directly/Offchain
  아비트럼의 Dapp에서 발생하는 트랜잭션은 클라이언트가 지갑을 L2 노드에 연결하여 서명된 트랜잭션을 직접 전달함

• Delayed Inbox
  클라이언트는 아비트럼의 Delayed Inbox에 L1 트랜잭션에 서명하고 POST하여 Sequencer로 메시지를 전송함. 이는 일반적으로 브릿지를 이용해 ETH와 토큰을 보관할 때 사용.

2. Sequencer 트랜잭션 오더

Sequencer가 트랜잭션을 수신하면 다음과 같이 수행하게 된다.

• 오프체인 Inbox에서 오더
• 아비트럼 Nitro VM을 사용하여 로컬환경에서 실행(L1, L2 수수료 징수 및 할당)
• 즉시 클라이언트에 트랜잭션 receipt 제공(추가적인 온체인 컨펌이 필요하지 않기 때문에, 1~2초도 걸리지 않음)

이 단계에서는 클라이언트의 finality 여부는 Sequencer의 신뢰에 달려있다. 악의적인 Sequencer는 트랜잭션 receipt으로 클라이언트의 트랜잭션을 위조하거나 잘못된 상태 업데이트를 발생시킬 수 있음

(현재 아비트럼은 시퀀서를 개발사에서 직접 관리하고 있으나, 시퀀서 또한 탈중앙화 시킬 예정이라고 한다)

3. Sequncer의 일괄적인 트랜잭션 POST

시퀀서는 최종적으로 클라이언트 트랜잭션을 포함한 L2 트랜잭션 batch를 L1(calldata)에 POST함. 통상적으로 몇분 간격으로 batch를 POST함.

만약 Sequencer가 특정 트랜잭션을 포함하지 않으면 클라이언트는 Delayed Inbox에 POST하여 L2에 트랜잭션을 포함시키게 되는데, 여기서 일정 시간이 초과하면 강제로 batch화 하여 L1(calldata)로 POST하게 함.

아비트럼에서는 이 일정 시간이 약 24시간으로 정해져 있음.

4. Validator는 트랜잭션을 포함한 Rollup Block을 Assert함

active Validator는 Inbox의 인풋을 아비트럼 VM으로 실행하고 체인의 최신 state(rollup block)에 대해서 On-chain assertion을 수행한다. Rollup block은 일반적으로 30분~60분 마다 assertion됨

5. L1에서 Rollup Block 확인

Validator의 챌린지가 해결되고 충분한 시간이 흐르면, Rollup block을 L1에서 컨펌된다. (L1의 모든 Ethereum account에서 확인가능)

5단계 전까지 클라이언트는 L2-to-L1 메시지의 Finanlity 권한(을 가지고 있기 때문에 Rollup Block이 컨펌되기 전까지 자금을 클레임할 수 없다.