이 튜토리얼에서는 여러 번의 트랜잭션 서명이 필요해요. 이를 위해 지갑 private key 환경변수를 세팅해야합니다.
export TEST_PRIVATE_KEY=0x...
Chain Client 설정
ETH 브릿징을 위해 chain client를 설정합니다.
Deposit ETH (이더리움 -> GIWA)
이제 이더리움에서 GIWA로 ETH를 브릿징 해볼까요?
아래 코드를 실행하면 이더리움에 있던 여러분의 ETH가 실제로는 OptimismPortal 컨트랙트로 전송되고, 전송한 수량만큼 여러분의 GIWA 지갑으로 전송되는 것을 확인할 수 있어요. 이러한 방식을 Lock-and-Mint 라고 해요.
1
구성
레이어 1에서 deposit 트랜잭션 전송
이에 대응되는 레이어 2 deposit 트랜잭션이 sequencer에 의해 생성
Deposit 완료
2
코드 작성하기
3
실행하기
왜 레이어 1 deposit 트랜잭션을 전송하고, 레이어 2 지갑 잔고에 반영되기까지 수 분이 소요되나요?
여러분이 레이어 1 deposit 트랜잭션을 전송하면, 레이어 2 sequencer가 이를 확인하고 레이어 2 deposit 트랜잭션을 생성해요. 이 과정에서 레이어 1 체인이 reorg가 발생할 수 있기 때문에 시스템 안정성을 위해 레이어 2 sequencer는 레이어 1 deposit 트랜잭션이 발생하고 대략 N 블록 이후에 이를 처리하는 형태입니다.
Withdraw ETH (GIWA -> 이더리움)
이더리움에서 GIWA로 ETH가 잘 전송되었나요? 이제 반대로 GIWA에서 이더리움으로 ETH를 브릿징해요.
아래 코드를 실행하면 GIWA에 있던 여러분의 ETH가 실제로는 L2ToL1MessagePasser 컨트랙트로 전송되고, 전송한 수량만큼 여러분의 이더리움 지갑으로 전송되는 것을 확인할 수 있어요. 이때는 Deposit에 의해 OptimismPortal 컨트랙트에 Lock되어있던 ETH가 다시 Unlock되는 형태에요. 이러한 방식을 Burn-and-Unlock 이라고 합니다.
L2ToL1MessagePasser 컨트랙트로 전송된 ETH는 사실상 소각(burn)되었다고 볼 수 있어요. Balance를 조회하면 남아있지만 언제든 해당 컨트랙트의 burn() 함수를 호출하면 모든 balance가 소각되는 구조에요.
1
구성
레이어 2에서 withdrawal 개시 트랜잭션 전송
레이어 1에서 withdrawal 증명 트랜잭션 전송
레이어 1에서 withdrawal 완료 트랜잭션 전송
Withdrawal 완료
2
코드 작성하기
3
실행하기
Withdrawal은 왜 이렇게 오래걸리나요?
Prove 대기시간: 레이어 2에서 발생한 withdrawal 트랜잭션을 레이어 1에서 증명하기 위해서는 해당 레이어 2 트랜잭션이 포함된 dispute game이 레이어 1에서 개시되어야해요. 현재 GIWA는 최대 2시간마다 dispute game을 개시하기 때문에, withdrawal을 prove할 수 있을 때까지 최대 2시간이 소요될 수 있습니다.
Challenge Period: GIWA는 Optimistic Rollup 방식을 채택한 OP 스택(OP Stack) 을 기반으로 한 레이어 2에요. 이에 따라 dispute game, 즉 레이어 2의 특정 시점의 상태가 올바르다는 것을 확정 지을 수 있기까지 대략 7일이 소요됩니다. 때문에 withdrawal을 finalize할 수 있을 때까지 대략 7일이 소요될 수 있습니다.