본문으로 이동
Financial Context Wiki

L2 강제 출금

강제 포함, 강제 출금, 이스케이프 해치를 프로토콜별로 설명하고 각 메커니즘의 보장, 의존성, 출금 경로 검증법을 정리합니다.

업데이트

교육 목적의 자료이며 금융 또는 보안 조언이 아닙니다. 출금 메커니즘, 지연, 수수료, 컨트랙트 권한과 데이터 가용성 가정은 L2마다 다르며 업그레이드 후 바뀔 수 있습니다.

직접 답변

L2 강제 출금은 사용자가 L2 운영자의 승인 없이 출금을 시작하거나 완료할 수 있게 하는 프로토콜 경로입니다. 이 명칭은 표준화되어 있지 않습니다. 어떤 시스템에서는 L1 컨트랙트에 출금 요청을 직접 제출하는 것을 뜻하지만, 다른 시스템에서는 L1에서 시작한 트랜잭션이 L2 실행 대기열에 들어가도록 보장할 뿐인 강제 포함만 제공합니다. 이후에도 사용자는 정식 브리지의 일반 출금 및 최종화 절차를 거쳐야 합니다.

이스케이프 해치는 정상적인 상태 업데이트가 중단될 때 사용하는 더 강한 비상 경로입니다. 애플리케이션을 동결하고 사용자가 커밋된 상태 루트를 기준으로 잔액을 증명하게 할 수 있습니다. 어떤 메커니즘도 즉시 출금, 특정 자산 가치, 컨트랙트 버그나 거버넌스 권한으로부터의 면책을 보장하지 않습니다. 실제 보장은 배포된 코드, 현재 설정, 이용 가능한 상태 데이터, 그리고 필요한 트랜잭션이나 증명을 구성해 제출할 수 있는 사용자의 능력에서 나옵니다.

작동 방식

  • 기본 기능을 식별합니다. 강제 포함, 강제 출금, 이스케이프 모드는 서로 다른 문제를 해결합니다. 강제 포함은 검열하거나 사용할 수 없는 시퀀서를 우회합니다. 강제 출금 요청은 프로토콜이나 운영자가 요청된 출금을 처리하거나 무효임을 증명하도록 합니다. 이스케이프 모드는 보통 일반 업데이트를 멈추고 상태 증명으로 출금하는 최후 수단입니다.
  • L1을 통해 진입합니다. 사용자는 프로토콜 문서가 지정한 L1 인박스, 포털 또는 결제 컨트랙트에 트랜잭션을 보냅니다. OP Stack에서는 L1 입금 트랜잭션이 시퀀싱 윈도 내에 L2 블록으로 파생됩니다. Arbitrum Nitro에서는 메시지가 Delayed Inbox에 들어가며, 시퀀서가 포함하지 않으면 설정된 지연 뒤 메인 인박스로 강제 포함할 수 있습니다.
  • 프로토콜 처리를 기다립니다. L1 확인은 첫 체크포인트일 뿐입니다. 요청은 정식 L2 체인에 들어가 성공적으로 실행되고, 증명 또는 확인된 상태에 나타나며, 챌린지 또는 유예 기간을 거친 뒤 L1에서 최종화되어야 할 수 있습니다. 잘못된 nonce, 부족한 Gas, 잘못된 calldata, 토큰 제한이나 바뀐 L2 상태로 강제 트랜잭션도 되돌려질 수 있습니다.
  • 출금 조건을 충족합니다. StarkEx Spot은 실제 강제 출금 및 이스케이프 흐름을 보여 줍니다. 사용자가 fullWithdrawalRequest를 제출하면 애플리케이션은 요청을 처리하거나 무효임을 증명해야 합니다. FREEZE_GRACE_PERIOD 뒤에도 대기 중이면 동결을 요청할 수 있습니다. 이후 이스케이프에는 동결된 vault root에 대한 Merkle path, 증명 검증, escape 호출과 일반 온체인 withdraw 호출이 필요합니다.
  • 데이터 가용성을 확인합니다. 상태 루트는 커밋먼트이지 그 아래의 잔액이나 Merkle path 자체가 아닙니다. 상태 재구성에 필요한 데이터가 L1에 게시되면 독립된 주체도 원칙적으로 출금 증명을 만들 수 있습니다. Validium 같은 오프체인 데이터 가용성 설계에서는 위원회나 운영자의 데이터 공개에 의존할 수 있습니다. 증명 유효성과 데이터 가용성은 별개의 보장입니다.
  • 통제 권한과 도구를 확인합니다. 일시 중지, 동결, 업그레이드, 거버넌스 권한, 정확한 컨트랙트 주소와 프록시 구현, 지원 자산, 필요한 키, L1 및 L2 Gas, 증명 생성 소프트웨어, 독립 인터페이스 유무를 검토합니다. 데이터, 도구 또는 충분한 L1 자금이 없으면 이론상 올바른 메커니즘도 실용적이지 않을 수 있습니다.

예시

어떤 Rollup의 시퀀서와 공식 인터페이스가 중단됐지만 L1은 계속 최종화된다고 가정합니다. 사용자는 먼저 프로토콜 공식 문서에서 체인 ID와 정식 L1 컨트랙트를 확인합니다. 강제 포함만 제공한다면 정식 브리지의 L2 출금 함수를 호출하는 L1-L2 트랜잭션을 제출합니다. 그 뒤 L1 제출, 강제 포함, L2 실행, 상태 커밋, 해당 챌린지 또는 증명 단계, L1 최종화를 각각 추적합니다. L1 제출 성공만으로 출금 호출 성공이 증명되지는 않습니다.

StarkEx 방식에서는 순서가 다릅니다. 문서화된 강제 요청을 제출하고, 설정된 유예 기간을 기다리며, 요청이 처리됐는지 무효로 증명됐는지 확인한 다음, 컨트랙트 조건이 충족될 때만 동결과 이스케이프를 사용합니다. 필요한 vault 식별자, 키, Merkle path는 동결 상태와 일치해야 합니다. 모두 “강제 출금”으로 불릴 때가 있어도 Arbitrum이나 OP Stack 절차를 그대로 적용하면 틀립니다.

어느 경로든 의존하기 전에 시스템이 정상일 때 소액으로 연습합니다. 컨트랙트 주소, 함수 시그니처, 예상 이벤트, 타이머와 트랜잭션 해시를 기록하고 별도의 신뢰할 수 있는 RPC나 블록 탐색기로 상태를 검증합니다. “긴급 출금” 사이트에 시드 문구나 개인 키를 입력하거나 지원 계정 또는 다이렉트 메시지에 추가 “잠금 해제” 비용을 보내지 마십시오.

위험

  • 강제 포함은 있지만 직접 강제 출금 함수는 없습니다.
  • L1 요청은 확인됐지만 L2 호출이 되돌려졌거나 아직 실행되지 않았습니다.
  • 챌린지, 증명, 유예 또는 최종화 기간이 자금 접근을 늦춥니다.
  • 특히 오프체인 데이터 가용성에서는 상태 데이터나 Merkle path를 구할 수 없습니다.
  • 잘못된 체인, 컨트랙트, 프록시 구현, 함수 또는 vault 식별자를 사용합니다.
  • 출금 컨트랙트가 일시 중지, 업그레이드, 잘못된 동결 또는 버그의 영향을 받습니다.
  • 거버넌스, 보안 위원회 등 권한 있는 주체가 출금 경로를 바꿀 수 있습니다.
  • 자산이 미지원, 비표준, 비유동적이거나 애플리케이션 수준 증거금 규칙의 적용을 받습니다.
  • L1 Gas 급등이나 네이티브 Gas 부족으로 제출 또는 최종화할 수 없습니다.
  • 필요할 때 공식 인터페이스, RPC, 인덱서 또는 증명 도구를 사용할 수 없습니다.
  • 가짜 인터페이스, 검색 광고 또는 지원 메시지가 인증 정보나 자금을 훔칩니다.
  • 지연 중 시장 가치가 하락할 수 있습니다. 출금 가능성은 가격 보호가 아닙니다.

흔한 오해

  • “강제 출금”에는 하나의 보편적 절차가 있습니다. 명칭과 보장은 프로토콜마다 다르므로 배포된 버전의 문서와 컨트랙트를 읽어야 합니다.
  • 강제 포함은 자금을 즉시 L1으로 돌려줍니다. 보통 트랜잭션 순서 또는 실행 접근만 보장하며 이후 브리지 출금에는 별도의 수명 주기가 있습니다.
  • L1 트랜잭션 해시는 출금 성공을 증명합니다. L1 트랜잭션 포함만 증명하므로 이후 L2 실행과 L1 최종화를 별도로 확인해야 합니다.
  • 유효성 증명은 출금 데이터 가용성도 보장합니다. 증명 정확성과 데이터 가용성은 별개이며 오프체인 설계는 추가 의존성을 만듭니다.
  • 함수가 존재하므로 비상 경로는 무신뢰입니다. 사용 가능성은 권한, 현재 설정, 데이터, 소프트웨어, Gas와 키에도 의존합니다.
  • 이스케이프 해치는 금융 위험을 없앱니다. 이는 생존성 또는 검열 실패 경로를 다루며 토큰 가격, 유동성, 스마트 컨트랙트 또는 키 유출 위험을 없애지 않습니다.

관련 주제

출처

탐색

위키 검색...