L2 거래 확인 수익의 다양한 단계 해석

2024.01.03

L2 거래 확인 수익의 다양한 단계 해석

L2 거래 구현의 전체 프로세스를 소개하고, 거래 프로세스 각 단계의 보안 성능을 분석합니다.

2024.01.03 - 11:27:07

Web3 심층 보도에 집중하고 흐름을 통찰

L2 거래 구현의 전체 프로세스를 소개하고, 거래 프로세스 각 단계의 보안 성능을 분석합니다.

글: Nic @imToken Labs

L2(Layer2) 거래가 블록에 포함된 것을 언제 확신할 수 있을까? L2 거래로 인한 수입이 Re-org(리오르그)로 인해 폐기되지 않을 것임을 언제 확신할 수 있을까?

본문은 독자들에게 L2 거래의 전 과정을 소개하고 각 단계별 보안 성능을 분석한다.

사전 지식:

L1(Layer1) 거래의 전체 프로세스
Re-org 발생 원인과 그 영향
현재 이더리움 PBS 아키텍처의 역할과 작동 방식 이해
Optimistic Rollup과 Validity(ZK) Rollup의 차이점 이해

L1 거래 이해하기

거래 프로세스

사용자가 거래를 생성하고 서명하면, 이는 p2p 네트워크로 전송되며 PoW 합의 하에서 마이너 또는 PoS 합의 하에서 Proposer가 해당 거래를 블록에 포함시킬 때까지 기다린다. 사용자는 자신의 거래가 최신 블록에 포함되었음을 확인하더라도 100% 확신할 수는 없다. 왜냐하면 블록체인이 'Re-org'라 불리는 상황을 겪을 수 있기 때문이다. 사용자는 특정 블록이 Re-org될 가능성이 충분히 낮아질 때까지 기다려야 비로소 거래가 블록체인 역사에 기록되었다고 확신할 수 있다.

L1 거래 흐름도

거래가 블록에 포함된 후에도 여전히 Re-org가 발생할 수 있으므로, Re-org가 거의 불가능하다고 판단될 때까지 기다려야 거래가 Finalized(확정) 되었다고 확신할 수 있다.

Re-org 가능성 및 비용은 체인의 합의 알고리즘과 자산 시가총액에 따라 달라지며, 본 문서에서는 Re-org 비용 계산 방법은 다루지 않는다.

L2 거래 이해하기

거래 프로세스

L2 사용자가 거래를 생성하고 서명한 후, 일반적으로 이를 트랜잭션 순서를 정렬하는 Sequencer에게 직접 전달하며, Sequencer가 해당 거래를 L2 블록에 포함시킨다. 이후 Sequencer가 L2 블록 데이터를 하나의 L1 거래를 통해 L1에 기록하면, 사용자는 자신의 거래가 최신 L2 블록에 포함되었음을 확인할 수 있다.

하지만 주의해야 할 점은, L2 블록 데이터가 L1 거래를 통해 L1에 업로드되기 때문에, 여전히 L1에서 Re-org가 발생하여 해당 L2 블록이 결국 블록체인 역사에 기록되지 못할 수 있다는 것이다. 즉 L2 Re-org와 동일한 상황이 발생할 수 있으므로, 사용자는 L1 Re-org 가능성도 충분히 낮아질 때까지 기다려야 비로소 자신의 거래가 블록체인 역사에 기록되었다고 확신할 수 있다.

L2 거래 흐름도

사용자는 먼저 거래가 L2 블록에 포함되는 것을 기다린 후, L2 블록이 L1 거래를 통해 L1에 업로드되는 것을 기다리고, 마지막으로 L1 거래가 Finalized되는 것을 기다린다.

L1 거래와 비교했을 때, L2 거래는 거래가 Sequencer에 의해 L2 블록에 포함되기까지의 시간이 추가되지만, 실제로 L2 블록 용량이 충분히 크고 블록 생성 속도가 빠른 경우 이러한 대기 시간은 매우 짧으며, 대부분의 시간은 L1 거래가 포함되는 것을 기다리는 데 소요된다. 따라서 전반적인 사용 경험 측면에서 L1과 L2 거래는 유사하다.

하지만 사용자가 일정한 타협을 감수한다면 더 나은 경험을 얻을 수 있을까?

Pre-Confirmation/Fast Confirmation/Soft Confirmation

사용자는 (L2 거래를 포함하는) L2 블록이 L1 블록에 포함되고, Re-org 가능성이 충분히 낮아질 때까지 기다린 후에야 자신의 L2 거래가 포함되었다고 믿어야 한다.

하지만 사용자가 Sequencer를 신뢰한다면 어떨까? 아마도 Sequencer는 L2 개발팀이나 명성이 높은 기관이 운영할 수도 있으며, Sequencer가 사용자의 거래를 받을 때 즉시 포함하거나 X번째 블록에 포함하겠다고 약속한다면, Sequencer를 신뢰하는 사용자에게는 이러한 약속만으로도 충분할 수 있다. 마치 사용자가 자신이 사용하는 지갑을 신뢰하여, 지갑에서 거래가 포함되었다고 알림을 받은 후에도 Etherscan에서 반복적으로 확인하지 않는 것과 같다.

이러한 Sequencer 제공의 거래 포함 보증은 Pre-Confirmation, Fast Confirmation 또는 Soft Confirmation이라 불리며, '사전의', '유연한' 거래 포함 보증으로 이해할 수 있다. L2 거래가 L1 블록에 포함되기까지 기다릴 필요는 없지만, 이것은 오직 Sequencer의 구두 약속일 뿐이며, 버그로 인해 Sequencer가 약속을 잊거나 악의적인 Sequencer가 약속을 위반할 수 있고, 가벼운 경우 사용자의 시간을 낭비시키고 심각한 경우 '이중 지출 공격(double-spend attack)'을 당할 수 있다.

다음에서는 다양한 L2 거래 포함 상태 표시 방식을 소개한다.

Arbitrum/Optimism의 거래 포함 상태

현재 Arbitrum이나 Optimism에서 사용자가 거래를 제출하면 거의 즉시 거래 영수증(Transaction Receipt)을 받게 되며, 여기에는 거래 실행 결과가 포함되어 있다. 이는 Sequencer가 로컬에서 거래를 정렬하고 한 번 시뮬레이션 실행을 완료했다는 의미이며, 이 거래 영수증이 바로 사용자에게 제공되는 Pre-Confirmation이다.

Arbitrum의 거래 생명주기에 대한 보다 자세한 정보는 아래 링크를 브라우저에 복사하여 공식 문서를 참조하시기 바랍니다: https://docs.arbitrum.io/tx-lifecycle
Optimism의 거래 생명주기에 대한 보다 자세한 정보는 아래 링크를 브라우저에 복사하여 공식 문서를 참조하시기 바랍니다: https://community.optimism.io/docs/protocol/txn-flow/#posting-to-l1

Arbitrum에서 거래 포함 상태 확인하기

Arbitrum Explorer에서 확인되는 거래는 Pre-Confirmation 상태의 거래, 즉 아직 L1에 업로드되지 않은 거래도 포함된다. 아래 그림의 거래를 보면 Block Number 145353000 옆에 Confirmed by Sequencer라는 표시가 있다:

위 그림은 Sequencer에 의해 확인되었으나 아직 L1에 업로드되지 않은 거래

반면 아래 그림처럼 이미 L1에 업로드된 거래의 경우 상태는 "69 L1 Block Confirmations"으로 표시되며, 이는 해당 거래 데이터가 L1에 업로드되었고 해당 Layer1 블록 이후로 69개의 블록이 추가되었음을 의미한다:

해당 거래 데이터를 포함한 L1 블록 이후로 69개의 블록이 추가됨. 더 많은 블록이 추가될수록 안정성은 높아진다.

또는 아래 스크린샷의 거래처럼 해당 거래 데이터를 포함한 L1 블록 이후로 이미 6174개의 블록이 추가되었으며, 매우 안전한 상태이다.

하지만 더 나은 방법은 L1의 Finality 정보를 결합하여 표시하는 것이다.

단순히 사용자에게 몇 개의 L1 Block Confirmation이 있는지를 알려주는 것은 도움이 제한적이며, 사용자는 스스로 해당 수치가 의미하는 보안 수준을 이해하고 계산해야 한다. 반면 Layer1(즉, 이더리움)은 이미 Casper FFG와 같은 Finality 메커니즘을 갖추고 있으므로, Explorer는 해당 Layer1 블록이 Layer1에서 이미 Finalized되었는지 여부를 직접 표시할 수 있다. 현재 Optimism의 Explorer는 이러한 기능을 이미 구현했다.

Optimism에서 거래 포함 상태 확인하기

Optimism Explorer에서 확인되는 거래 역시 Pre-Confirmation 상태의 거래, 즉 아직 L1에 업로드되지 않은 거래를 포함한다. 아래 그림의 거래를 보면 Block Number 111526300 옆에 Confirmed by Sequencer라는 표시가 있다:

Sequencer에 의해 확인되었으나 아직 L1에 업로드되지 않은 거래

하지만 현재 이 Explorer는 Confirmed by Sequencer의 의미를 명확히 규정하지 않은 듯하다. "Sequencer confirmations are equivalent to a few block confirmations on L1."이라고 설명하며, Confirmed by Sequencer가 L1에 업로드되었고 여러 개의 블록이 뒤따랐음을 의미한다고 주장한다:

하지만 실제로 가장 최근에 나타난 거래도 여전히 Confirmed by Sequencer로 표시되며, 수십 일 전에 이미 챌린지 기간이 지난 거래도 상태가 Confirmed by Sequencer로 남아 있다:

수십 일 전의 거래 상태도 여전히 "Confirmed by Sequencer"

읽기 참고: 위의 상황은 해당 Explorer가 서로 다른 상태를 다른 위치에 표시했을 가능성도 있다. Block Number 뒤의 Confirmed By Sequencer는 이 블록이 Sequencer에 의해 확인되었음을 알려주는 것이며, L1에 업로드된 후의 상태는 사용자가 다른 정보를 통해 직접 확인해야 한다. 예를 들어 다음 문장에서 언급할 'L1 State Batch' 정보 등이다.

또한 아래 스크린샷처럼 L1에 이미 업로드된 거래의 경우 두 가지 추가 정보를 제공한다: 'L1 State Batch Index'와 'L1 State Root Submission Tx Hash'. 이 두 정보는 해당 L2 거래가 어느 State Batch에 포함되었는지, 그리고 이 State Batch가 어떤 L1 거래를 통해 L1에 업로드되었는지를 나타낸다:

'3480'이라는 State Batch를 클릭하면 상태가 Finalized임을 알 수 있다. 이 Finalized는 L1(즉, 이더리움 메인넷)의 Finalized 상태에 해당하며, 두 개의 Epoch 검증자 투표가 성공적으로 누적된 매우 안전한 상태이다.

△ State Batch 3480이 L1 Block 18457449에 포함되었으며, Block 18457449는 이미 Finalized되었다.

출처:https://etherscan.io/block/18457449

업로드되었지만 아직 L1에서 Finalized되지 않은 Batch의 경우 Unfinalized로 표시된다:

State Batch 3494는 L1에 업로드되었지만, 해당 Batch를 포함한 L1 블록은 아직 Finalized되지 않았다.

Arbitrum Explorer와 비교해 Optimism Explorer는 거래에 대해 더 많은 정보(State Batch)를 제공하며, L1 Finality 정보를 L2 Explorer에 직접 연결하여 사용자가 L1 블록이 Finalized되었는지 여부를 직접 알 수 있도록 해주며, 블록 확인 수에 따른 보안 수준을 스스로 판단하도록 요구하지 않는다.

StarkNet의 거래 포함 상태

현재 StarkNet에서 사용자가 거래를 제출하면 거래 영수증을 빠르게 조회할 수 있지만, 영수증에 표시되는 거래 상태는 일반적으로 RECEIVED 상태이다. 이는 노드가 거래를 수신했으며 검증 후 문제가 없어 Sequencer가 L2 블록에 포함하고 실행할 것을 기다리는 상태를 의미하며, RECEIVED 상태의 거래는 아직 거래 실행 결과를 포함하지 않는다. 사용자는 StarkNet Explorer에 표시된 거래 상태를 통해 자신의 거래 처리 진행 상황을 알 수 있다.

읽기 참고: 만약 Sequencer가 충분히 빠르게 처리한다면 RECEIVED 상태를 건너뛰고 바로 거래가 처리된 상태로 넘어갈 수 있다. StarkNet의 거래 흐름에 대한 보다 자세한 설명은 아래 링크를 브라우저에 복사하여 공식 문서를 참조하시기 바랍니다.

공식 문서: https://docs.starknet.io/documentation/architecture_and_concepts/Network_Architecture/transaction-life-cycle/

Starkscan이라는 StarkNet Explorer에서 확인되는 거래 역시 Pre-Confirmation 상태의 거래를 포함한다. 아래 그림의 거래를 보면 Status가 현재 Accepted on L2이며, 이는 이미 Sequencer에 의해 L2 블록에 배치되었음을 의미한다:

'Accepted on L2'는 이미 Sequencer에 의해 L2 블록에 포함되었지만 아직 L1에 업로드되지 않았음을 의미

Accepted on L2 이전의 두 가지 상태는 Received와 Pending이며, 각각 '거래가 수신되어 검증 통과'와 '거래가 Sequencer에 의해 처리 중'을 의미하며, 거래 처리가 완료되면 Accepted on L2 상태로 진입한다:

거래가 수신되어 검증 통과

거래가 Sequencer에 의해 처리 중

거래 데이터가 L1에 업로드된 후에야 상태가 Accepted on L1으로 바뀌며, 아래 그림의 거래처럼 된다:

거래 데이터가 이미 L1에 업로드됨

StarkNet의 거래는 더 풍부한 상태를 가지고 있어 사용자가 거래 처리 진행 상황을 알 수 있지만, 거래 데이터가 L1에 업로드되기까지 4~5시간 정도 기다려야 할 수 있다(제로지식 증명 생성에 시간이 더 오래 걸릴 수 있기 때문). 따라서 이 기간 동안 사용자는 Sequencer의 Pre-Confirmation에 의존하게 된다.

또한 Explorer는 L1에 업로드된 거래에 대해서도 Accepted on L1만 표시하며, L1 Finality나 Block Confirmation 정보를 함께 제공하지 않아 사용자가 직접 L1 블록에 충분한 후속 블록이 추가되었는지 혹은 Finalized되었는지 확인해야 한다.

전반적으로 StarkNet 자체의 성능 병목으로 인해 사용자가 오랫동안 Pre-Confirmation에 의존해야 하고, Explorer가 L1 Finality 정보를 지원하지 않아 StarkNet 거래 포함 확인의 사용자 경험(UX)이 좋지 않으며, 이는 향후 개선이 필요한 부분이다.

zkSync의 거래 포함 상태

StarkNet과 유사하게 zkSync도 PENDING 상태를 가지며, 이는 노드가 거래를 수신하고 검증 후 문제 없음을 의미하며, Sequencer가 L2 블록에 포함하고 실행할 것을 기다리는 상태이다. PENDING 상태의 거래는 아직 거래 실행 결과를 포함하지 않는다.

사용자는 zkSync Explorer에 표시된 거래 상태를 통해 자신의 거래 처리 진행 상황을 알 수 있다.

읽기 참고: 만약 Sequencer가 충분히 빠르게 처리한다면 PENDING 상태를 건너뛰고 바로 거래가 처리된 상태로 넘어갈 수 있다.

zkSync의 거래 흐름에 대한 보다 자세한 설명은 아래 링크를 브라우저에 복사하여 확인하시기 바랍니다: https://era.zksync.io/docs/reference/concepts/finality.html#finality-on-ethereum

zkSync Explorer에서 확인되는 거래 역시 Pre-Confirmation 상태의 거래를 포함한다. 아래 스크린샷의 거래를 보면 Status가 현재 zkSync Era Processed이며, 이는 이미 Sequencer에 의해 L2 블록에 포함되었음을 의미한다:

이 거래는 이미 Sequencer에 의해 L2 블록에 포함되었으며, 현재 L1(Ethereum Sending)에 업로드되는 것을 기다리는 중

Sequencer가 L2 블록을 생성한 후, 해당 블록과 내부 거래는 Committed, Proven, Executed 세 단계를 차례로 거친다. 각각 '블록이 L1에 업로드됨', '블록 유효성이 입증됨', '블록 내 거래 실행 후 L2 상태가 L1에 업데이트됨'을 의미한다. 아래는 서로 다른 단계에 있는 블록과 거래를 각각 보여준다:

Batch 292700이 L1에 업로드되어 Committed 단계에 진입함. 출처: https://explorer.zksync.io/batch/292700

Batch 292700 내부 거래의 현재 상태는 Ethereum Sending에서 Ethereum Validating으로 변경되어 제로지식 증명을 통해 유효성 검증을 기다리는 중임.

Ethereum Validating 아이콘 위에 마우스를 올리면 서로 다른 단계가 표시되며, 이전 단계(Sending)의 거래 링크도 함께 제공된다:

이 거래가 'Validating' 단계에 진입하였으며, 이전 단계(Sending)에서 Batch를 L1에 업로드한 거래 링크를 여기서 바로 확인할 수 있음.

Batch 292000의 유효성이 입증되었으므로 Proven 단계에 진입:

Batch가 입증된 후 Proven 상태가 되며, Prove 동작을 수행한 거래 링크가 함께 제공됨.

내부 거래도 'Validating'에서 'Executing' 단계로 진입하여 실행을 기다리는 중임.

Batch가 입증된 후에는 일정 시간(공식 문서상 약 21시간)의 대기 시간을 거친 후 내부 거래를 실행하고 L1에 기록된 L2 상태를 업데이트한다. 이는 현재 Alpha 단계에서 Bug 발생 시 충분한 대응 시간을 확보하기 위한 보호 조치이다. Batch가 실행된 후 최종 Executed 단계에 진입:

Batch 실행 후 최종 Executed 상태에 진입하며, Execute 동작을 수행한 거래 링크가 함께 제공됨.

Batch 내부 거래 상태도 'Executed'로 업데이트됨

StarkNet의 경우 L2에서 L1으로의 전환이 한 단계 내에 완료되는 것과 달리, zkSync는 L2에서 L1으로의 과정을 더욱 세부적인 세 단계로 나누었다: Committed → Proven → Executed.

보호 조치로서 전체 거래 시간이 약 하루 정도로 길어졌지만, Committed 상태 덕분에 사용자는 거래가 포함되었는지 매우 빠르게 확인할 수 있으며(거래가 Committed 상태가 되면 더 이상 Pre-Confirmation이 아님), Sequencer에 대한 신뢰에 계속 의존할 필요가 없다.

또한 zkSync Explorer는 각 단계에 대해 풍부하고 완전한 데이터를 제공하여 누구나 Explorer를 통해 거래의 최신 상태를 파악할 수 있으며, 각 단계 전환(예: Committed에서 Proven, Proven에서 Executed)의 거래 실행을 직접 검증할 수도 있다.

하지만 주의할 점은, Alpha 단계의 보호 조치로서 현재 zkSync Sequencer는 기록을 수정할 수 있다는 점이다.

이는 거래가 Pre-Confirmation에서 벗어나 Committed 단계에 빠르게 진입할 수 있더라도, 실제로 Executed 단계에 도달하기 전까지는 Sequencer가 사용자 거래를 기록에서 제거할 수 있음을 의미한다. 따라서 사용자는 여전히 하루 동안 Sequencer를 신뢰해야 한다.

L1도 Pre-Confirmation을 지원할 수 있음

블록을 생성하는 주체를 미리 알 수 있다면, L1도 Pre-Confirmation을 지원할 수 있다.

예를 들어 이더리움의 경우, 실제로 블록을 생성하는 주체는 Builder이며, Builder가 Pre-Confirmation 서비스를 제공하여 사용자에게 거래 포함 보장을 줄 수 있다. 하지만 Builder가 반드시 특정 블록 생성 권리를 획득하는 것은 아니며, 각 블록 생성 권리를 경매를 통해 획득해야 하므로, 이러한 Pre-Confirmation의 효력은 상대적으로 낮다. 또한 Builder의 실력을 고려해야 하며, Builder의 경쟁력이 부족하면 블록 생성 권리를 얻기 어려우므로, 해당 Builder가 제공하는 Pre-Confirmation 서비스는 크게 떨어진다.

위 문제를 피하려면 Proposer가 Pre-Confirmation 서비스를 제공하는 것이 더 좋은 방법이다. 왜냐하면 '몇 번째 블록을 어떤 Proposer가 제안하는지'는 일반적으로 사전에 계산되어 결정된 확정적인 상황이기 때문이다.

하지만 현재 PBS 아키텍처에서는 Proposer는 단지 블록을 제안하는 역할일 뿐, 실제 블록을 제작하고 내용을 결정하는 역할은 Builder가 맡고 있으므로, Proposer는 특정 거래를 블록에 삽입하거나 Builder에게 삽입을 요구할 수 없다. 미래에 PBS 아키텍처가 Inclusion List를 도입하거나 Proposer가 블록 제작에 참여할 수 있도록 변경된다면, Proposer가 Pre-Confirmation 서비스를 제공할 기회가 생길 것이다.

읽기 참고: PBS에 대한 보다 자세한 소개는 아래 링크를 브라우저에 복사하여 읽어보세요: https://mirror.xyz/0x347c9872A2a1dE370D798f9FE96341A9A0E05af8/oG_4j_-TweXHX_LMag656k_pAyJWIBXpEDrzpUfVsss.

Pre-Confirmation 개선하기

Pre-Confirmation은 Builder나 L2 Sequencer의 구두 약속일 뿐이며, 상대방은 약속을 이행할 법적 의무가 없고, 위반이라도 처벌 메커니즘이 없다.

이러한 약속을 더 강력하게 만들 수 있을까? 사실 가능하다. 블록 생성 주체와 그들이 약속하는 내용(예: '1350000번 블록에 이 거래를 포함')은 모두 조건 검사로 작성할 수 있기 때문이다. 따라서 스마트 계약을 통해 Builder나 Sequencer를 규제할 수 있으며, Pre-Confirmation 서비스 제공 시 스마트 계약에 보증금을 예치하도록 하고, 거래 포함 약속을 할 때는 내용에 서명하도록 요구할 수 있다. 사용자가 Builder나 Sequencer가 약속을 이행하지 않았음을 발견하면, 약속 내용과 상대방의 서명을 스마트 계약에 제출하면, 스마트 계약이 약속 이행 여부(예: '1350000번 블록에 이 거래를 포함')를 검사할 수 있다.

위 계약의 활용 사례는 아직 개념 검증 단계이지만, 아래 링크의 연설 영상은 그 중 하나의 사례를 보여주고 있다. 자세한 내용은 아래 링크를 브라우저에 복사하여 확인하시기 바랍니다: https://www.youtube.com/watch?v=Uw5HxSYXwYo

결론

L1 거래가 L1 블록에 포함된 후 Re-org 가능성은 점차 감소하며, 사용자가 거래 포함에 대해 갖는 신뢰도는 점차 증가한다.
L2 거래는 L1 거래보다 'L2 거래가 L2 블록에 포함되고 L1에 업로드될 때까지 기다리는' 단계가 추가된다.
하지만 L2 거래가 L1 거래보다 추가된 이 단계에서 데이터가 아직 L1에 업로드되지 않았기 때문에 변수가 발생할 가능성이 여전히 존재하므로, 사용자가 이 단계에서 얻을 수 있는 거래 포함 보장은 Sequencer의 구두 약속뿐이며, 이를 Pre-Confirmation 또는 Fast Confirmation, Soft Confirmation이라 부른다.
Sequencer가 악의적이거나 단순한 버그로 인해 약속을 위반할 경우, 사용자의 L2 거래가 포함되지 않을 수 있다.
현재 대부분의 L2는 Explorer에서 거래 상태에 Pre-Confirmation 상태를 포함하고 있으며, 예를 들어 Arbitrum/Optimism의 Confirmed by Sequencer나 StarkNet의 Accepted on L2 등이다. 이러한 정보를 볼 때는 제공되는 거래 포함 보장의 시간적 유효성을 주의 깊게 살펴야 한다.
Sequencer가 제공하는 Pre-Confirmation을 신뢰하지 않으려면 더 오랜 시간을 기다린 후 L2 Explorer가 제공하는 L2 데이터가 L1에 업로드되었는지 여부를 통해 검증해야 한다.
Pre-Confirmation에 경제적 인센티브 메커니즘을 추가할 수 있다. 예를 들어 Sequencer가 약속을 위반할 경우 스마트 계약을 통해 처벌받도록 하여 사용자가 더 명확한 보장을 얻을 수 있게 한다.