devops

Arbitrum L1 <-> L2 Bridge 원리 및 Contract 알아보기 본문

Layer2

Arbitrum L1 <-> L2 Bridge 원리 및 Contract 알아보기

vata500 2023. 5. 14. 17:20
반응형

L2의 핵심 중 하나는 L1 자산의 이동이 가능한 'Bridge'다. 이 Bridge를 위한 레이어간 메시지는 L1의 컨트랙트와 L2 컨트랙트 간의 호출을 말한다. 쉽게 말해서 크로스체인 컨트랙트 콜이다.

원활한 메시지 송수신을 위해서 L1과 L2에 여러 컨트랙트를 배포해야한다. 이 컨트랙트들의 역할과 원리를 간단히 살펴보자.

L1 → L2 Contract 메시지

L1에서 L2로 메시지를 전달하려면, 함수를 호출하는데, 먼저 L1의 Inbox를 거쳐서 Bridge를 거쳐야한다. 여기서 L2의 alias Account는 L1 컨트랙트의 Account다.

그래서 L2 Contact 호출하는 것은 L2 네트워크의 alias Account에서 시작하며, 호출에 의한 트랜잭션 수수료도 부과된다. L1에서 L2로 메시지를 보내는 것은 아비트럼에서 Retryable Ticket이라고 한다. 이 Ticket은 트랜잭션을 후에 처리가 가능하다. 

inbox.createRetrybleTicket의 파라미터는 다음과 같다.

  • L2 callvalue(전송 ETH)
  • L2 컨트랙트 주소
  • Retryable tx 수수료
  • 수수료 환불 account
  • Ether 환불 account
  • L2 Contract 실행 가스
  • 가스비
  • calldata

Retryble Ticket?

아비트럼에만 존재한 특이한 메시지 표준이다. Retryble ticket은 L1 가스가 제공되면 바로 실행되어 Ethereum(L1) 에서 Arbitrum(L2)에 전달되는 메시지다. 

여기서 이 티켓의 주요 역할은 'L1에서 L2 메시지 전달에 요구되는 가스비를 줄이는 것'과 'L2 메시지 전달의 안정성 보장'이다. 이더리움의 수수료는 매우 비싸기 때문에 L2로 전송하는게 쉽지않지만, 이 티켓은 실행되면 Retryble Buffer에 저장되어 일정 기간동안 유저가 재실행할 수 있다. 

아무튼, L2의 수수료는 (실행가스 * 가스비) + Retryable 수수료라고 볼 수 있다. 그럼 코드를 통해서 hardhat으로 간단히 테스트해보자. 

L2 → L1 Contact 메시지

L2에서 L1으로 갈때는 User가 tx를 보내면 Sequencer가 Inbox로 전송한다. 그리고 동시에 Contract를 호출해서 ArbSys라는 미리 배포된(Precompile) 컨트랙트를 거치고, outbox로 가게 된다.

outbox에 전송된 것을 User가 확인하고 Claim하여 L1의 Bridge Contract를 실행(인출)하게 된다. 물론 여기서 챌린지 기간이 지나야한다. (약 일주일)

ArbSys.sendTxToL1

이걸 호출해주면 위 과정들이 처리된다고 볼 수 있다. 여기서 이 ArbSys 컨트랙트의 파라미터는 다음과 같다.

# ArbSys.sol
...
 /** 
    * @notice Send a transaction to L1
    * @param destination recipient address on L1 
    * @param calldataForL1 (optional) calldata for L1 contract call
    * @return a unique identifier for this L2-to-L1 transaction.
    */
function sendTxToL1(address destination, bytes calldata calldataForL1) external payable returns(uint);
...
  • L1 컨트랙트 주소
  • Calldata

(return 값으로는 L2 to L1에 대한 unique identifier)

여기서 챌린지 기간동안 L1으로 전송된 메시지는 여러 상태를 거치게 된다.

Pending  → Waiting → Ready for Relay(챌린지를 끝나고 컨펌된 상태, outbox에서 조회가 가능) → Relayed(최종 상태)

https://arbiscan.io/txsExit

 Arbiscan에서 트랜잭션의 Status를 보면 Pending, Waiting 상태를 확인할 수 있다.


참고로 Arbitrum은 Builtin Contract들에 대한 문서도 정리해놓았기 때문에 스터디하려는 분들은 아래 링크를 참고 https://github.com/OffchainLabs/arbitrum/tree/master/docs/sol_contract_docs/md_docs/arb-os/arbos/builtin 

 

GitHub - OffchainLabs/arbitrum: Powers fast, private, decentralized applications

Powers fast, private, decentralized applications. Contribute to OffchainLabs/arbitrum development by creating an account on GitHub.

github.com

위 내용은 coldmind님의 강의 내용을 보고 정리했음.

https://inf.run/49Uj

반응형
Comments