실시간 검증을 통한 롤업 간의 동기식 구성 가능성
1. 기반 롤업 및 실시간 검증
기반 롤업은 누구나 새로운 블록 제안할 수 있는 롤업으로, 특정 시퀀서에 대한 권한이 없습니다. 참여자는 누구나 롤업의 현재 상태를 기반으로 일련의 트랜잭션을 적용하여 새로운 블록 생성할 수 있습니다.
데이터 가용성 페이로드와 유효성 증명을 단일 단위로 함께 제출하도록 요구할 때 핵심적인 설계 이점이 나타납니다. 기존의 롤업 방식에서는 데이터가 먼저 게시되고 증명은 나중에 제출되는데, 이로 인해 인센티브 설계가 복잡해집니다. 누가 언제 증명을 생성해야 할까요? 그리고 그들에게 공정하고 신속하게 보상하는 방법은 무엇일까요?
데이터와 증명을 동시에 게시함으로써 이러한 격차를 완전히 해소할 수 있습니다. 블록 제안자는 실행과 증명 모두에 대한 책임을 집니다. 증명이 유효하지 않거나 누락된 경우 블록 존재하지 않습니다. 이는 인센티브 메커니즘을 획기적으로 단순화합니다. 블록 제안자가 곧 증명자이며, 별도의 증명 시장이나 검증 기간 없이 동일한 재원(예: 거래 수수료)에서 보상을 받습니다.
이는 실시간 검증 , 즉 블록 생성과 동시에 유효성 증명을 생성할 수 있을 만큼 빠른 속도로 증명을 만들어내는 능력 덕분에 가능해졌습니다. 이는 비동기적인 사후 처리가 아닌, 블록 생성과 동시에 증명을 생성하는 것을 의미합니다.
실시간 증명은 빠르게 실용화되고 있습니다. 현재 이더리움 블록 하나를 증명하는 데에는 약 12개의 GPU가 필요하며 평균 증명 시간은 약 7초입니다. 하드웨어 개선과 증명 시스템 최적화를 통해 지연 시간을 더욱 줄일 수 있는 여지가 여전히 크지만, 정확히 어느 지점까지 줄일 수 있을지는 예측하기 어렵습니다. 증명자 중앙 집중화는 중요한 문제입니다. 요구되는 하드웨어 사양이 만만치 않고, 모든 블록 생성자가 동일한 증명 인프라에 접근할 수 있는 것은 아니기 때문입니다. 그러나 증명은 본질적으로 병렬화 가능하고 상품화될 수 있으며, 더 저렴한 하드웨어에서 더 빠른 증명이 이루어지는 추세는 분명합니다.
2. 동기식 구성 가능성이란 무엇인가요?
동기식 구성 가능성이란 단일 트랜잭션 내에서 한 체인(L1 또는 롤업)의 스마트 계약이 다른 체인(L1 또는 다른 롤업)의 스마트 계약을 호출 하고 동일한 실행 컨텍스트에서 결과를 수신할 수 있음을 의미합니다. 마치 두 계약이 동일한 체인에 존재하는 것처럼 말입니다.
오늘날 크로스체인 상호작용은 비동기적으로 이루어집니다. 체인 A에서 메시지를 보내고, 체인 B로 전달될 때까지 기다린 후, 결과를 별도로 처리해야 합니다. 이는 이더리움 DeFi 생태계를 강력하게 만드는 구성 가능성 모델을 무너뜨립니다. 프로토콜은 롤업 경계를 넘어 원자적으로 구성할 수 없습니다.
동기식 구성 가능성은 이러한 점을 복원합니다. 개발자 관점에서 다른 롤업의 컨트랙트를 호출하는 것은 동일한 체인의 컨트랙트를 호출하는 것과 똑같이 보이고 동작합니다. 트랜잭션은 관련된 모든 체인에서 원자적으로 성공하거나 완전히 되돌려집니다.
3. 간단한 경우: L2-to-L2 구성 가능성
L1↔L2 상호작용이라는 더 어려운 문제를 다루기 전에, L2 롤업 간의 구성 가능성만 놓고 보면 비교적 간단하다는 점을 알아두는 것이 좋습니다.
L2 상태만 다루는 경우, 영향을 받는 모든 롤업의 데이터 가용성을 단일 블롭으로 묶을 수 있습니다. 블록 빌더는 여러 롤업 상태를 거치는 결합 실행을 구성하고, 이를 모두 함께 검증한 후, 결과를 하나의 원자적 데이터 가용성 제출로 게시합니다. 영향을 받는 모든 상태 전환이 함께 검증되고 게시되므로, 전환이 모두 발생하거나 전혀 발생하지 않는 방식으로 구성 가능성이 자연스럽게 보장됩니다.
이러한 관찰이 기본 토대입니다. 더 어려운 문제는 L1 스마트 계약이 상호작용의 일부일 때 이를 실제로 구현하는 것입니다.
4. 프록시 스마트 계약
크로스체인 호출을 가능하게 하는 핵심 메커니즘은 프록시 스마트 계약 입니다. 프록시는 다른 체인에 있는 스마트 계약을 대신하여 한 체인에 배포되는 스마트 계약입니다.
L1 계층의 컨트랙트가 롤업 R 계층의 컨트랙트를 호출하려고 할 때, R 계층의 코드를 직접 실행하는 것이 아닙니다. 대신, L1 계층에 존재하는 R 컨트랙트의 프록시를 호출합니다. 프록시 컨트랙트는 크로스체인 호출을 캡슐화합니다. 즉, 대상 컨트랙트가 무엇인지 알고, 호출을 처리하고, 롤업에 해당하는 상태 변경을 적용하고, 결과를 반환하는 모든 과정을 동일한 트랜잭션 실행 내에서 수행합니다.
호출자 입장에서 프록시와의 상호 작용은 실제 계약과의 상호 작용과 구별할 수 없습니다. 프록시는 원격 계약에 대한 로컬 인터페이스입니다.
5. L1 ↔ L2 상호작용 모델
거래에 L1 및 L2 스마트 계약이 모두 관련된 경우, 실행은 구조화된 프로세스를 따릅니다.
1단계: 프록시 계약이 존재하는지 확인합니다.
실행 전에 L1과 상호 작용할 L2 계약에 대한 모든 프록시 스마트 계약이 배포되어야 합니다. 롤업 R의 계약이 L1에서 호출될 경우, 해당 계약의 프록시가 이미 L1에 존재해야 합니다.
2단계: 실행 테이블 구축 및 제출
실행 테이블이 생성되어 L1 상태에 임시로 저장됩니다. 이 테이블은 일련의 항목으로 구성되며, 각 항목은 하나의 동작과 그 결과를 설명합니다. 각 항목에는 다음 내용이 포함됩니다.
- 행위 : 주로
CALL또는RESULT. - L2 상태 전환 집합 : 어떤 롤업이 영향을 받는지, 그리고 해당 상태 루트가 어떤 상태에서 어떤 상태로 전환되는지를 나타냅니다.
- nextAction : 다음에 발생할 작업으로, RESULT(반환 데이터 포함) 또는 다른 CALL(다른 L1 스마트 계약에 대한 호출)이 될 수 있습니다.
이 표는 크로스체인 상호작용의 전체 과정을 보여줍니다. 예를 들어, 중첩 호출 시나리오를 생각해 보세요.
A ( on L1) calls B ( on Rollup 2 )→ B ( on Rollup 2 ) calls C ( on L1 )→ C ( on L1 ) returns→ B ( on Rollup 2 ) returns A ( on L1 ) continues execution이 경우 실행 테이블에는 두 개의 항목이 포함됩니다.
| # | Action | L2 State Transitions | nextAction | | ---|-----------------------|-------------------------------|---------------------| | 1 | CALL B ( on Rollup 2 ) - | Rup2: stateRoot₀ → stateRoot₁ | CALL C ( on L1) | | 2 | RETURN from C ( on L1) | Rup2: stateRoot₁ → stateRoot₂ | RETURN to A ( on L1) |첫 번째 항목에는 "A가 Rollup 2에서 B를 호출하면 Rollup은 stateRoot₀에서 stateRoot₁으로 전환되고, 다음으로 L1에서 C를 호출해야 합니다."라고 나와 있습니다. 두 번째 항목에는 "C가 반환되면 Rollup 2는 stateRoot₁에서 stateRoot₂으로 전환되고 최종 결과가 A로 반환됩니다."라고 나와 있습니다.
실행 테이블에는 전체 호출/반환 시퀀스와 각 단계에서 발생하는 모든 상태 전환이 인코딩되어 있습니다. 특히, 테이블에는 테이블 내 모든 실행 단계의 정확성을 보장하는 단일 유효성 검증 문서가 함께 제공됩니다. 이 검증 문서는 테이블 제출 시 한 번만 검증됩니다.
3단계: 프록시 확인을 통한 L1 실행
이제 L1 트랜잭션은 정상적으로 실행됩니다. 실행 과정에서 L1 컨트랙트가 프록시 컨트랙트를 호출하는 시점이 되면, 프록시는 다음과 같은 작업을 수행합니다.
- 실행 테이블에서 해당
CALL액션을 찾습니다. - 영향을 받는 롤업에 대한 상태 루트 변경 사항을 확인하고 적용합니다.
- 시퀀스에 중첩된 L1 호출이 있는 경우, 해당 호출들을 실행합니다.
- 실행 테이블에서 사용된 항목을 제거합니다(L1 스토리지 낭비를 방지하기 위해).
- 호출한 L1 컨트랙트에
RESULT반환합니다.
L1 실행 환경의 관점에서 보면, 호출은 정상적으로 이루어졌고 결과가 반환되었습니다. 크로스체인 상호작용의 복잡성은 프록시와 실행 테이블에 의해 완전히 추상화됩니다.
4단계: L2에서 시작된 거래
L2에서 시작되어 L1과 상호 작용하는 트랜잭션은 동일한 모델을 따르지만, 실행 테이블의 첫 번째 작업은 CALL 아닌 L2TX 입니다. L2 트랜잭션이 실행을 시작하고, L1 컨트랙트에 대한 모든 호출은 테이블의 중첩 항목이 되어 동일한 방식으로 처리됩니다.
5단계: 되돌리기 처리
REVERT 및 REVERT_CONTINUE 두 가지 특별한 작업은 단일 체인 내에서 되돌리기가 작동하는 방식과 동일하게 체인 경계를 넘어 되돌리기를 처리합니다.
L2에서 실행 중에 되돌리기(revert)가 발생하면 L1으로 REVERT 액션이 전송됩니다. 그러면 L1은 되돌려진 실행 경로에 포함된 중첩된 L1 호출을 모두 취소하고 영향을 받는 롤업 상태 루트를 accordingly 업데이트하여 되돌리기를 처리합니다. L1이 되돌려진 호출을 취소하는 작업을 완료하면 L2로 REVERT_CONTINUE 액션이 다시 전송되어 실행이 재개됩니다. 결과적으로 되돌리기는 현재 단일 체인 내에서 작동하는 방식과 동일하게 작동합니다.
6. 추가 사항
계정 추상화 및 인센티브 조정
프록시 계약이 배포되고 사용자와 블록 생성자 간의 인센티브가 적절하게 조정되도록 하는 작업은 기존 이더리움 표준, 특히 이더리움 개선 제안(EIP)-7702 (EOA 계정 코드 설정) 및 이더리움 개선 제안(EIP)-4337 (계정 추상화)을 사용하여 처리할 수 있습니다. 이러한 표준은 핵심 프로토콜을 변경하지 않고도 설정 단계를 조정하는 데 필요한 유연성을 제공합니다.
롤업은 이더리움 가상 머신(EVM) 에만 국한되지 않습니다.
이 시스템에 참여하는 롤업은 EVM 네이티브일 필요가 없습니다. 다른 롤업에 대한 `CALL`을 수락하고 생성할 수 있는 모든 롤업이 참여할 수 있습니다. 각 롤업은 zkVerification 키를 통해 자체 상태 전환 함수를 정의합니다. 롤업은 상태 루트에 대한 완전한 제어 권한을 가진 소유자를 둘 수도 있습니다.
메인 시스템이 부과하는 유일한 제약 조건은 이더(Ether) 책임성 입니다. 시스템은 각 롤업이 보유한 이더의 양을 추적해야 하며, 롤업이 총 이더 잔액보다 높은 값으로 'CALL'을 수행하는 것을 허용해서는 안 됩니다.
네이티브 토큰 및 가치 이전
롤업은 자체 네이티브 토큰을 정의할 수 있습니다. 단, 상태 전환 함수는 롤업이 다른 네이티브 토큰을 사용하는 경우 외부 롤업과의 CALL 요청에서 0이 아닌 이더 값을 허용하거나 사용해서는 안 됩니다. 이는 롤업의 내부 토큰과 L1 시스템에서 추적하는 이더 간의 회계 불일치를 방지하기 위함입니다.
L1 포크(Fork) 필요하지 않습니다.
이 메커니즘 전체는 L1을 포크하지 않고도 구현할 수 있습니다. 모든 것은 기존 이더리움 네트워크에 배포된 스마트 계약을 통해 작동합니다.
사전 확인과 직교하는
이 제안은 사전 확인 메커니즘과 완전히 독립적입니다. 사전 확인에 의존하지도 않고 충돌하지도 않습니다. 오히려 L1 사전 확인 기능이 구현된다면, 더 빠른 L1 완결성 으로 인해 크로스체인 상호작용의 지연 시간이 줄어들기 때문에 이 제안은 L1 사전 확인 기능을 활용할 수 있을 것입니다.
참조 구현
이러한 스마트 계약이 어떻게 작동할지에 대한 첫 번째 초안은 다음 링크에서 확인할 수 있습니다: https://github.com/jbaylina/sync-rollups
