블롭 스트리밍을 이용한 DA 레이어 확장

02-25

이 기사는 기계로 번역되었습니다

원문 표시

블롭 스트리밍

@QED , @fradamt , @Julian 님이 작성했으며, @soispoke , @aelowsson , @casparschwa 님께서 귀중한 의견을 주셔서 특별히 감사드립니다 .

본 논문에서는 블롭 스트리밍을 제안합니다. 이는 기존의 핵심 경로 블롭 레인과 함께, 연속적이고 샘플링된 블롭 데이터의 사전 전파를 프로토콜의 핵심 메커니즘으로 확립하는 것입니다. 사전 전파는 이미 블롭 풀을 통해 이루어지고 있지만, 보장성이 약하고 데이터 가용성 샘플링이 부족하여 처리량 확장에 안정적으로 의존할 수 없습니다. 블롭 스트리밍은 사전 전파 속도를 제한하는 티켓 메커니즘을 도입하여, 핵심 경로를 확장하지 않고도 전체 슬롯에 걸쳐 샘플링을 안정적으로 확장할 수 있도록 함으로써, 자유 옵션 문제를 완화합니다. 확장성 외에도, 이 메커니즘은 블롭 트랜잭션에 대한 완전한 검열 저항성을 제공합니다.

소개

정의: JIT 및 AOT 블롭
데이터가 필요한 슬롯의 중요 경로에 전달되는 경우 해당 데이터를 JIT (Just-In-Time) 블롭이라고 합니다. 그렇지 않은 경우, 해당 블롭을 AOT (Ahead-of-Time) 블롭이라고 합니다.

이더리움의 데이터 가용성(DA) 메커니즘은 원래 JIT 블롭을 중심으로 설계되었으며, 핵심 경로는 합의 계층(CL)에서 전파가 이루어졌습니다. 이 메커니즘은 PeerDAS를 통해 데이터 가용성 샘플링을 가능하게 하도록 업그레이드되었습니다. 그러나 실행 계층(EL) 블롭 풀은 사전 전파 경로를 제공함으로써 실제로 AOT 블롭을 구현할 수 있게 되었습니다.

원칙적으로 JIT 블롭은 AOT 블롭이 제공할 수 없는 기능(L1 서버와의 동기적 구성 가능성을 위해서는 블록과 블롭의 동시 생성이 필수적임)을 가능하게 하지만, 현재 모든 블롭 사용은 실제로 AOT 방식으로 이루어지고 있습니다. 따라서 블롭 풀은 작업을 중요 경로에서 벗어나게 하여 대역폭 사용량을 시간에 걸쳐 분산시키는 역할을 해왔습니다. 그러나 이러한 사전 전파는 데이터 가용성에 대한 보장이 미흡하고 데이터 가용성 샘플링이 이루어지지 않기 때문에 확장성 측면에서 얻을 수 있는 이점은 제한적입니다.

이미지 4440×2600 370KB

그림 1. JIT/AOT 정의를 시각화한 슬롯 타임라인. AOT 블롭(주황색)은 중요 경로 이전에 전파되고, JIT 블롭(노란색)은 가용성이 요구되는 슬롯의 중요 경로 내에서 전파됩니다. 전파 시점 및 방식에 관계없이, 검증자는 모든 블롭의 가용성을 검증합니다.

이 글에서는 블롭 스트리밍을 제안합니다. AOT 블롭을 티켓 기반의 우선 순위 레인으로 만들어 사용자가 블롭을 미리 전파할 권한을 구매하도록 하고, JIT 레인(현재의 프라이빗 블롭과 유사)은 스팟 가격으로 제공됩니다. 스트리밍 레인은 기존 레인과 결합됩니다. AOT 블롭은 중요 경로 이전에 사전 전파되고, JIT 블롭은 중요 경로 내에서 전파됩니다. 특히, 티켓 기반 속도 제한을 통해 전파 부하를 제한함으로써 사전 전파의 신뢰성을 확보하여 노드 뷰의 일관성을 유지하고 DoS 공격에 대한 저항력을 강화합니다. 또한, 전파 권한이 가용성 결정과 분리되어 있기 때문에(블롭 풀과는 달리) 데이터 가용성 샘플링을 안전하게 추가하여 샘플링 범위를 전체 슬롯으로 확장하고 블롭 처리량을 확장할 수 있습니다. 따라서 제안된 메커니즘은 블롭 풀 샘플링 메커니즘(예: 수직 샤딩 ,수평 샤딩 )의 대안으로, 동일한 처리량 확장성을 제공하면서 다음과 같은 이점을 제공합니다.

사용자에게 제공되는 혜택: 강력한 검열 저항 보장, 블롭 공간 사전 확보 가능성, 블롭 트랜잭션에 대한 멤풀 제한 완화.
프로토콜에 대한 개선 사항: 명확한 부하 범위와 더 작은 임계 경로 전파 기간을 통해 자유 옵션 문제를 완화합니다.

이미지 3444×1240 201KB

그림 2. 슬롯의 2차선 보기. AOT 블롭은 중요 경로 이전에 사전 전파되어 시간에 걸쳐 분산됩니다. JIT 블롭은 페이로드와 함께 중요 경로 내에서 전파됩니다. 검증자는 모든 블롭의 가용성을 확인합니다.

티켓 기반 설계는 JIT 및 AOT 블롭 모두에 적용될 수 있습니다. 그러나 사전 용량 계획이 필요하지 않은 사용 사례(예: 순수 기반 롤업 및 궁극적으로 L1 자체의 블롭 사용( 블록 인 블롭 , 네이티브 롤업 ))를 수용하기 위해 티켓으로 용량을 할당하는 대신 스팟 가격으로 용량을 책정하는 기존 JIT 방식을 유지하기로 했습니다.

메커니즘의 구체적인 내용을 살펴보기 전에, AOT 레인을 도입하는 것이 왜 가치 있는지, AOT와 JIT 블롭의 공급 및 수요 측면을 통해 알아보겠습니다.

프로토콜의 관점(공급측)

시스템이 제공할 수 있는 AOT 블롭 처리량은 순수 JIT 처리량보다 상당히 높습니다. 왜냐하면 JIT 블롭은 다음과 같은 제약 조건 하에 좁은 시간 창 내에서 전파되어야 하기 때문입니다.

다음 제안자와 건설업자는 행동에 나서기 전에 가용성을 확인해야 합니다.
자유옵션 문제는 이 기간을 길게 둘수록 더욱 악화됩니다.

이는 전파 시간 동안 대역폭이 급증하는 반면, 나머지 시간 동안에는 대역폭이 실질적으로 활용되지 않는 결과를 초래합니다. AOT 블롭을 이용한 사전 전파를 통해 전파가 더 넓은 시간 창에 걸쳐 분산되므로(그림 2 참조), 대역폭 소비가 고르게 분산되고 병목 현상이 발생하지 않습니다. 효과적인 사전 전파는 최대 대역폭 사용량에서 안정적인 대역폭 사용을 가능하게 하여 처리량을 향상시킵니다.

이미지 1462×1217 103KB

그림 3. JIT와 AOT 블롭에서 슬롯 전체에 걸친 대역폭 변화를 보여주는 그림. JIT 블롭은 더 짧은 시간 간격 동안 대역폭을 필요로 하므로 대역폭 소비가 불규칙적으로 나타나는 반면, AOT 블롭은 전파가 넓게 퍼져 있어 대역폭 소비가 더 부드럽게 나타납니다.

사용자 관점(수요 측면)

JIT 블롭을 이용한 롤업의 주요 사용 사례는 L1과의 동기적 구성 가능성으로, 이는 기반 시퀀싱 과 실시간 검증을 필요로 합니다. 반면, 외부 시퀀싱 롤업이나 사전 확인 기반 롤업 (예: Taiko 참조)은 AOT 블롭을 활용할 수 있습니다.

사전 확인과 동기식 구성 가능성을 모두 결합한 하이브리드 방식의 롤업 설계도 가능할 수 있습니다. 이는 기본적으로 L1 슬롯의 대부분 동안 사전 확인을 사용하다가 L1 블록 생성 기간 동안에는 동기식 모드로 전환하여 이 기간 동안 동기식 상호 작용이 가능하도록 하는 방식입니다. 이러한 롤업은 JIT 및 AOT 블롭을 혼합하여 사용할 수 있으며, L1 블록 생성 기간 동안에는 L1과의 동기식 상호 작용을 위해 JIT 블롭이 필요할 수 있습니다.

무엇보다 중요한 것은, 우리가 빠르게 나아가고 있는 미래를 내다볼 때 JIT 블롭은 L1에서도 중요한 의미를 갖게 된다는 점입니다. 미래에는 zkEVM + DAS를 사용하여 페이로드를 블롭에 배치함으로써 L1 자체를 확장하고, 본질적으로 EL을 유효성 롤업으로 전환하게 될 것입니다.

이러한 사용 사례들을 고려하더라도, JIT 방식과 AOT 방식의 블롭 수요가 미래에 정확히 어떻게 변화할지 예측하기는 어렵습니다. 동기식 구성 가능성이 유익하다는 것은 알지만, 정확히 얼마나 유익한지는 알 수 없습니다. 비용이 많이 든다는 것도 알지만, 정확히 얼마나 드는지도 알 수 없습니다. L1 서버는 JIT 블롭을 필요로 할 것이지만, 전체 블롭 처리량 중 얼마나 많은 부분을 차지할지는 알 수 없습니다.

우리는 프로토콜에 AOT 블롭을 위한 추가적인 기능을 도입할 가치가 있는지 판단하기 위해 이 두 가지 블롭 유형의 미래 수요를 정확하게 예측할 필요가 없다고 주장합니다. AOT 블롭에 대한 의미 있는 수요가 존재하는 한(모든 롤업이 완전 기반 방식을 원하지 않을 것이고, 하이퍼스케일링된 L1 서버조차도 모든 블롭 처리량을 소비하지 않을 가능성이 높기 때문에 이는 매우 가능성이 높습니다), 모든 블롭 사용자는 AOT 블롭 처리량을 별도의 영역으로 분리함으로써 이점을 얻습니다. 위에서 논의한 바와 같이, AOT 블롭은 현재 사용되지 않는 중요 경로 외부의 대역폭을 활용할 수 있습니다. 이러한 리소스를 AOT 블롭이 사용할 수 있도록 함으로써 중요 경로는 JIT 블롭을 위해 확보됩니다. 즉, AOT 블롭을 도입하는 것은 AOT 블롭을 사용하는 사용자뿐만 아니라 제한된 중요 경로 리소스에 더 많이 접근할 수 있게 되는 JIT 블롭 사용자에게도 이점이 됩니다.

설계

이제 기존의 블롭풀(blobpool)에서 시작하여 완전한 2차선 아키텍처로 발전시켜 나가는 설계 과정을 설명하겠습니다.

요약: 블롭풀 티켓

현재 사전 전파는 EL 블롭풀을 통해 이루어지지만, 전파 대역폭을 할당하는 프로토콜 내 메커니즘은 없습니다. 블롭 처리량이 증가함에 따라 블롭풀은 필연적으로 단편화됩니다. 전역적으로 유입량을 제한할 방법이 없으므로 노드 수준에서만 로컬로 제어할 수 있습니다. 더욱이 블롭풀은 데이터 가용성 샘플링의 이점을 누리지 못하며, 이를 도입하는 것 또한 어렵습니다. 블롭풀의 보안 모델은 유효하고 포함 가능한 트랜잭션만 전파하는 것에 의존하는데, 샘플링 노드가 자체적으로 블롭 가용성을 완벽하게 검증할 수 없으므로 샘플링 시 이를 보장하기 어렵습니다.

이미지 4156×1800 275KB

그림 4. 현재 블롭 풀의 사전 전파. 블롭 트랜잭션은 전체 블롭 데이터의 가용성이 트랜잭션의 유효성 기준이 되므로 전체 블롭 데이터와 함께 전파되어야 합니다.

블롭 전파 권한을 경매하는 블롭 티켓팅 메커니즘에 대해서는 많은 연구가 이루어졌습니다( 여기 , 여기 , 여기 참조 ). 최근에는 이러한 방향으로 나아가는 한 단계로 블롭풀 티켓팅 메커니즘이 제안되었는데, 이는 블롭풀 내 블롭의 DoS 공격 방지 사전 전파를 보장하고, 블롭풀 샘플링 메커니즘과 함께 구현되더라도 이러한 보장을 유지하는 것을 목표로 합니다( 수직 샤딩 멤풀 및 EIP-8070: 희소 블롭풀 참조).

블롭풀에 블롭을 제출하고 전파하려면 제출자는 지정된 티켓 계약(예: 최초 가격 경매 구현)과의 상호 작용을 통해 획득한 유효한 티켓을 보유해야 합니다. 이는 블롭풀을 통해 전파되는 블롭 수를 제한하고 제한된 공간을 공정하게 할당하는 데 도움이 됩니다. 블롭풀 참여가 유효성 검사가 아닌 선불 티켓으로 제어되므로 샘플링도 안전하게 도입할 수 있습니다. 즉, 노드는 더 이상 트랜잭션 전파 여부를 결정하기 위해 전체 블롭 가용성을 확인할 필요가 없습니다.

이미지 4156×1744 321KB

그림 5. 블롭풀 티켓을 사용하여 블롭풀을 확장합니다.

블롭 티켓

블롭 티켓은 티켓팅 개념을 한 단계 더 발전시켜 사전 전파를 CL(클라이언트 라인)로 이동시키고 데이터 가용성 파이프라인에 더욱 심층적으로 통합합니다. 이는 블롭풀 티켓과 두 가지 주요 측면에서 다릅니다.

AOT 블롭의 경우, 사용자는 티켓 하나만으로 블롭을 온체인에 포함시킬 수 있습니다. 특히, AOT 블롭 트랜잭션은 블롭 포함 시 기본 수수료를 지불하지 않고 일반 가스 수수료만 지불합니다. 따라서 블 롭풀 티켓이 아닌 블롭 티켓이라는 이름이 붙었습니다. 티켓으로 구매하는 것은 블롭풀 공간이 아니라 블롭 공간입니다. 프로토콜 관점에서 이는 전파 과정에서 실제로 제한된 대역폭 자원이 소모되기 때문입니다. (JIT 블롭은 나중에 설명하며, 현물 가격으로 거래됩니다.)
전파는 CL로 이동하며 , 이미 개발된 DA 샘플링 인프라를 재사용합니다. 그렇지 않으면 EL에서 불필요하게 중복될 필요가 없습니다. 더욱이 DA 샘플링은 합의 메커니즘의 핵심 요소입니다. DA는 블록을 포크 선택에 가져오기 위한 전제 조건이기 때문입니다. 현재 우리는 getBlobs 엔진 API 호출을 통해 EL 사전 전파와 CL 가용성 강제 적용을 결합하고 있습니다.

티켓 관련 워크플로는 다음과 같습니다.

티켓 구매 : 티켓 계약에 거래를 전송함으로써 사용자는 미래의 특정 시점에 블롭을 전파할 권리를 획득할 수 있습니다.
전파 :
1. 블롭 : 사용자는 지정된 시간에 티켓을 사용하여 CL 샘플링 인프라를 통해 블롭 데이터를 전송합니다.
2. 블롭 트랜잭션 : 티켓을 사용하면 블롭 데이터 없이 블롭 트랜잭션도 일반 메모리 풀로 이동합니다.
포함 및 가용성 강제 : 블롭 트랜잭션이 포함되면, 증명자는 현재와 마찬가지로 관련 블롭( blob_tx.versioned_hashes 로 식별됨)의 가용성을 강제합니다.

이미지 4680×1960 365KB

그림 6. 블롭 티켓을 사용한 사용자 워크플로. 사용자는 티켓을 획득하고, CL에서 블롭을 전파한 다음, EL 메모리 풀에 블롭 트랜잭션을 제출합니다. 블록에 포함되면 블롭 트랜잭션은 현재와 동일하게 작동하여 관련 블롭의 가용성에 따라 블록의 유효성이 결정되므로 사용자에게 엄격한 가용성 보장을 제공합니다.

각 티켓은 배포할 수 있는 권리를 부여합니다.

CL 상의 한 덩어리 (전파 방향 오른쪽)
EL에서 여러 개의 블롭 트랜잭션을 처리할 수 있습니다. 예를 들어 최대 16개까지 가능하며, 이는 현재 Geth 블롭 풀에서 허용하는 최대 블롭 트랜잭션 수( maxTxsPerAccount )와 Geth 멤풀에서 일반 트랜잭션에 대해 보장되는 기본 최대 멤풀 슬롯 수( AccountSlots )와 일치합니다. 단, 여기서 제한은 계정당이 아니라 티켓당 입니다.

이 두 권한은 독립적이며, CL과 EL은 각각 티켓 사용 내역을 별도로 추적합니다. 즉, 티켓 소지자는 CL에 블롭 데이터를, EL에 블롭 트랜잭션을 병렬로 전송할 수 있으며, 두 계층 간의 조정이 필요하지 않습니다. 단일 티켓으로 여러 블롭 트랜잭션을 EL 메모리 풀에 전송할 수 있으므로, 예를 들어 기본 요금 변경으로 인해 트랜잭션이 무효화되는 경우처럼 추가 티켓을 구매하지 않고도 재전송이 가능합니다.

사용자 참고 : 블롭 트랜잭션 전파를 유효성이 아닌 티켓에 연결하면 멤풀이 현재 적용하고 있는 엄격한 규칙 없이 운영될 수 있습니다. 특히, 동일한 주소에서 여러 블롭 트랜잭션을 병렬로 큐에 추가할 수 있습니다. 하나의 트랜잭션이 다른 트랜잭션을 무효화하는 문제가 발생하지 않기 때문입니다. 다시 말해, 전파 권한은 유효성이 아닌 티켓에 따라 결정됩니다! 이는 블롭 제출자에게 실질적인 불편 사항이며, 해결되지 않을 경우 개별 L2 서버의 처리량이 증가함에 따라 더욱 악화될 것입니다. 트랜잭션당 블롭 개수 제한으로 인해 각 L2 서버에서 처리되는 트랜잭션 수가 증가하기 때문입니다.

하이브리드 설계: AOT + JIT

지금까지 논의한 내용을 바탕으로, AOT와 JIT는 원칙적으로 구조적으로 동일할 수 있습니다. 모든 블롭 용량(핵심 경로 용량 포함)을 티켓 방식으로 판매하는 시스템을 설계할 수 있습니다. 이러한 시스템에서는 JIT와 AOT의 차이는 단순히 전파 타이밍에 관한 것이 될 것입니다.

티켓 전용 설계는 외부에서 순차적으로 처리되는 롤업 운영자처럼 처리량을 계획하고 티켓을 미리 구매할 수 있는 주체의 대량 데이터 수요에는 효과적입니다. 그러나 표준 티켓 관리자가 없는 개방형 사용자 흐름이 수요에 포함되면 이 설계는 한계에 부딪힙니다. 사용자는 사전에 티켓을 확보할 수 없으며, 빌더가 기본적으로 중간 티켓을 관리하게 되면 재고, 자본, 그리고 중앙 집중화에 대한 압력이 발생합니다. 수요가 급증할 경우, 네트워크가 여전히 핵심 경로 전파 용량을 확보하고 있더라도 티켓 재고가 병목 현상이 될 수 있습니다. 이는 L1 계층에서 대량 데이터( 블록 인 블롭 )를 사용하게 되는 경우뿐만 아니라, 대량 데이터 기반 롤업에도 적용됩니다.

이러한 이유로, 이 글에서 제시하는 최종 아키텍처는 티켓 기반 AOT 블롭과 스팟 가격 방식의 JIT 레인을 함께 도입한 명시적인 하이브리드 방식입니다. 최종 사용자는 트랜잭션을 통해 핵심 경로 블롭 리소스(JIT 블롭, 블롭 기본 요금)에 대해 직접 비용을 지불할 수 있으며, 계획된 흐름(AOT 블롭)은 티켓을 사용하여 처리하고 그 혜택을 누릴 수 있습니다. 페이로드에서는 버전이 지정된 해시 목록 두 개를 도입하여 이러한 분리를 명확히 합니다.

jit_versioned_hashes : 빌더가 JIT(Just-In-Time) 방식으로 커밋하는 블롭에 사용됩니다. 이러한 블롭은 페이로드와 함께 전파(샘플링)되며, 리소스 비용은 즉시 지불됩니다(JIT 블롭 기본 수수료는 \text{bf}^{AOT} bf A O T 로 설정됨 - 자세한 내용은 티켓 계약 섹션 참조). 이는 현재의 블롭 레인과 동일합니다.
aot_versioned_hashes : 티켓과 함께 사전 전파된 블롭이 이제 사용 가능한 것으로 확인되었습니다. 블롭 리소스에 대한 비용은 티켓 구매 시 이미 지불되었으므로 추가 결제가 필요하지 않습니다.

두 목록 모두 페이로드의 유효성을 가용성에 따라 결정합니다 . 즉, 페이로드가 정규화되려면 jit_versioned_hashes 및 aot_versioned_hashes 에 해당하는 모든 블롭이 사용 가능해야 합니다. 차이점은 전파 리소스에 대한 비용 지불 및 소비 방식에만 있습니다.

요약하자면, 네트워크의 전파 자원은 핵심 경로와 핵심 경로 외부라는 두 가지 범주로 명확하게 구분됩니다. 이 두 자원의 할당은 서로 다른 시장을 통해 이루어집니다. 사전 전파 용량은 온체인 티켓 경매를 통해 미리 확보할 수 있으며, 핵심 경로 전파 용량은 빌더가 최종적으로 포함 권한을 갖는 즉시 거래 방식의 스팟 시장을 통해 할당됩니다.

JIT 메커니즘은 현재의 블롭 레인과 동일한 기능을 제공합니다. 즉, 핵심 경로 전파, 빌더 주도의 블롭 포함, 그리고 포함 시 블롭 기본 수수료를 통한 즉시 결제가 이루어집니다. 하지만 JIT 블롭은 블롭 풀 사전 전파가 없으므로 사용자는 블롭을 빌더에게 직접 전달해야 합니다. 따라서 JIT 블롭은 현재의 프라이빗 블롭에 해당합니다 . AOT 메커니즘은 기존 방식에 추가되는 방식으로, 사전 티켓 구매, 사전 전파를 통한 더 높은 용량, 그리고 (이후 살펴보겠지만) 검열 저항성(CR) 보장과 같은 다양한 특성을 가진 추가 경로를 제공합니다. 이 경로는 사전 전파가 가능한 모든 블롭에 대해 기본값으로 사용됩니다.

JIT와 AOT의 역량 비교

하이브리드 설계에서 발생하는 근본적인 질문은 리소스 분할에 관한 것입니다. 블롭 데이터 전송을 위한 네트워크 용량 중 얼마를 JIT 블롭에, 얼마를 AOT 블롭에 할당할 것인가 하는 문제입니다. 본 논문에서는 용량 제약 조건을 세 가지 매개변수로 설정하는 설계를 제안합니다. 이 매개변수들은 현재 블롭 가스 목표치와 제한치를 설정하는 방식과 매우 유사합니다.

B_1 B 1 ( JIT max ): 슬롯당 최대 JIT 블롭 수입니다. 이는 핵심 경로를 완료하는 데 소요되는 시간과 그에 따른 허용 가능한 옵션 창의 크기에 따라 결정되는 상한값입니다.
B_2 B 2 ( blob (JIT + AOT) max ): 슬롯당 최대 총 블롭 수, JIT + AOT에 대한 총 제한값입니다. 이는 슬롯 동안 네트워크의 총 전파 처리량에 따라 결정됩니다.
R \leq B_1 ( 예약 된 JIT 용량 ): AOT 사용으로부터 보호되는 JIT 용량의 일부.

이러한 매개변수는 주어진 슬롯 n 에 대해 다음과 같은 규칙을 유도합니다.

AOT 티켓 판매 : 향후 슬롯에 대해 최대 B_2 - R B 2 − R 티켓을 판매할 수 있습니다. R R은 JIT에 예약되어 있으므로 최대 B_2 - R B 2 − R 개의 블롭만 미리 예약할 수 있습니다.
JIT 용량 : 슬롯 n 에 대해 a ≤ B_2 - R a ≤ B 2 − R AOT 블롭이 스케줄링된 경우 최대 \min(B_1,\, B_2 - a) min ( B 1 , B 2 − a ) JIT 블롭을 포함할 수 있습니다. 이는 최소 R R JIT 용량을 보장하고 AOT 수요가 낮을 때 JIT를 B_1 B 1 까지 확장할 수 있도록 합니다.

B_2 는 순전히 기술적 제약 조건으로, 슬롯에 대한 네트워크의 총 전파 예산을 반영합니다. B_1은 더 많은 재량권을 요구합니다. 슬롯 구조에 의해 제한되지만, 사용 가능한 옵션 창을 제한하기 위해 더 낮게 설정할 수 있습니다. 그러나 B_1은 JIT 와 AOT 중 어느 방식을 선호하는 것은 아닙니다. R R을 초과하는 모든 용량은 공유되므로, B_1이 높을 수록 AOT 수요가 낮을 때 JIT가 공유 풀로 더 확장할 수 있습니다.

가장 흥미로운 설계 선택은 R R 입니다. 예약되지 않은 용량 B_2 - R B 2 − R 은 AOT(티켓을 통해)와 JIT(AOT 수요에 여유가 있는 경우) 모두에서 사용할 수 있는 공유 풀입니다. R R 값을 너무 낮게 설정하면 JIT 수요를 충족하지 못할 위험이 있으며, 이는 L1 자체가 JIT 블롭에 의존하는 경우 특히 문제가 됩니다. R R 값을 너무 높게 설정하면 티켓으로 판매될 수 있었던 용량이 JIT 전용 경로로 몰리게 됩니다. 예약된 용량이 완전히 사라지는 것은 아니지만(원칙적으로 모든 AOT 활동은 JIT 블롭을 사용할 수 있음), 사용자는 빌더를 직접 거쳐야 하므로 프로토콜의 검열 저항 보장을 잃게 됩니다.

기본 가격

기본적으로 기존 블롭 기본 수수료 업데이트 메커니즘을 현재와 같이 적용할 수 있습니다. 명시된 제한을 고려하면, \min(B_1,\, B_2 - a) + B_2 - R min ( B 1 , B 2 − a ) + B 2 − R 블롭은 슬롯에서 판매될 수 있습니다. \min(B_1,\, B_2 - a) min ( B 1 , B2 − a ) 는 현재 슬롯에 대한 JIT 블롭으로, B_2 - R 은 향후 슬롯에 대한 티켓으로 사용됩니다. 슬롯에 스케줄링된 AOT 블롭 수가 적은 경우, 최대 B_1 + B_2 - R 블롭 이 판매 될 수 있습니다 . blobSchedule.target 은 B_2\times2/3 B2 × 2 / 3 에 위치할 수 있으며, blob_gas_used 해당 슬롯에서 판매된 총 JIT 블롭 및 AOT 티켓 수에 GAS_PER_BLOB 곱하여 계산됩니다. 실제로, 전체 메커니즘에서 요구하는 보다 세분화된 용량 제약 조건을 적용하기 위해 blobSchedule 에 새로운 변수 B_1 B1 , B_2 B2 및 R R을 추가해야 합니다.

처리량 증대를 위한 티켓 계약 및 가격 책정 메커니즘

앞서 언급했듯이 티켓을 구매하려면 전용 티켓 계약으로 트랜잭션을 전송해야 합니다. 이 계약은 주로 두 가지 기능을 수행합니다. 새로운 티켓을 출력하고, 사용되었거나 만료된 기존 티켓을 업데이트합니다. 티켓 계약은 앞서 언급한 용량 제약 조건에 따라 AOT 티켓을 출력합니다. 티켓 가격은 AOT 기본 수수료 \text{bf}^{AOT} bf A O T 에 따라 책정되며, 이 기본 수수료는 EIP-1559 유형 컨트롤러 메커니즘을 통해 설정된 목표 AOT 블롭 용량에 의해 결정됩니다. 앞서 언급했듯이 JIT의 기본 수수료는 \text{bf}^{AOT} bf A O T 와 같습니다.

구체적으로 이는 슬롯 i 에서 슬롯 i+ 1 로 이동할 때, 판매된 티켓 수가 AOT_target 보다 많으면 bf^{AOT}가 증가하고, 적으면 bf_AOT 가 감소 한다는 것을 의미 합니다. 여기서 AOT_target 는 AOT 블롭 용량 B_2 - R 의 함수 이며 , 예를 들어 AOT_target = B_2 - R 입니다 . 기본 요금에 대한 업데이트 규칙은 EIP -1559에 사용된 것과 정확히 동일할 수 있습니다.

$$\text{bf}^{AOT} {i+1} = \text{bf}^{AOT} {i} \times \Big(1 + \frac{1}{8} \times \frac{\text{AOT} {i} - \text{AOT} {\text{target}}}{\text{AOT}_{\text{target}}}\Big)$$
여기서 \text{AOT}_{i} 는 i 번째 슬롯 에서 판매된 티켓 수입니다.

각 티켓 거래에는 base_fee , auction_bid , number of tickets (계약에서 auction_bid_per_ticket = auction_bid / number of tickets , base_fee_per_ticket = base_fee / number of tickets 차감할 수 있음), 그리고 티켓을 받을 주소를 지정하는 sender_adress 라는 네 가지 변수를 지정해야 합니다. 티켓 거래가 티켓을 획득할 자격을 얻으려면 base_fee_per_ticket \geq\text{bf}^{AOT} ≥ bf A O T 조건을 만족해야 합니다. 거래는 auction_bid_per_ticket 높은 순서대로 정렬되며, 티켓은 최대 2\times(B_2 - R) 2 × ( B 2 − R ) 까지 할당됩니다.

수요 초과(즉, 특정 슬롯에서 사용자들이 구매하려는 총 티켓 수가 2 × ( B₂ - R ) 의 제한 을 초과하는 경우)가 발생하면, 티켓을 획득한 거래의 base_fee 와 auction_bid 모두 소각되고, 티켓 획득에 실패한 거래의 해당 값은 발신자 주소로 반환됩니다. AOT 블롭 처리 용량은 B₂ - R / ( B₂ - R) 입니다. 따라서 정렬된 거래 목록의 하위에 있는 거래에 해당하는 모든 티켓(용량의 두 배로 제한을 설정했으므로 최대 B₂ - R / ( B₂ - R) 까지)은 다음 슬롯에서 유효하게 됩니다. 예를 들어 B₂ - R = 5 이고 슬롯 N 의 입찰 순서가 다음 과 같다고 가정해 보겠습니다. 앨리스: 3 장 , 밥: 4 장, 찰리: 3 장. 그러면 앨리스는 슬롯 N+ 1 에서 3 장의 티켓을, 밥은 4장의 티켓 을 받게 됩니다. 2 는 슬롯 N + 1 에 2장의 티켓을, 2는 슬롯 N+ 2 에 2 장의 티켓을 받습니다. 반면 Charlie는 슬롯 N+ 2 에 3 장의 티켓 을 받습니다. 수요가 2×(B₂ - R) ² × ( B₂ - R ) 을 초과하지 않는 경우, 각 거래에서 bfAOT × bfAOT × 티켓 수 에 해당 number of tickets 값이 소각됩니다.

마지막으로, 다음 슬롯의 티켓만 판매할 필요는 없다는 점에 유의하십시오. 오히려 슬롯 N 에서 구매 한 티켓이 슬롯 N+ k 까지 유효한 티켓을 판매하는 방안을 고려할 수 있습니다. 티켓을 미리 확보할 수 있다면 L2 서버는 특정 블롭의 가격에 대한 사전 정보를 바탕으로 더욱 정확한 가격 책정을 할 수 있어 중요한 이점을 얻을 수 있습니다. 하지만 이와 관련된 세부 사항, 즉 k 의 크기 는 어느 정도로 해야 할까요? 사용자가 다양한 옵션 중에서 원하는 슬롯의 티켓을 지정할 수 있도록 해야 할까요? 등은 현재로서는 논의가 필요한 부분입니다.

검열 저항

AOT 레인의 핵심 약속 중 하나는 블롭 트랜잭션에 대한 검열 저항성입니다. 티켓을 통해 위원회에서 가용성을 확인하고 포함 보장을 부여할 수 있는 제한된 블롭 집합을 식별할 수 있습니다. 각 티켓은 단일 블롭에 대한 포함 목록 제안자 역할을 부여하는 것으로 볼 수 있습니다. 그러나 블롭 티켓만을 사용하는 기본 시스템은 이러한 약속을 완전히 이행하지 못합니다. 이 글에서는 이러한 격차를 파악하고, DA 계약을 통해 온체인에 가용성을 기록하는 방식으로 이를 해결하는 방법을 보여주고, 그 위에 엔드투엔드 포함 보장을 구축합니다.

블롭 티켓의 제한 사항

블롭 티켓은 매우 의미 있는 개선이지만, 검열 저항 측면에서는 여전히 공백이 있습니다. FOCIL 은 위원회가 특정 트랜잭션(예: 멤풀에서 가져온 트랜잭션)의 포함을 보장할 수 있도록 하는 검열 저항 메커니즘입니다. 그러나 블롭 트랜잭션의 유효성은 가용성에 달려 있습니다. 가용성이 어디에도 기록 되지 않기 때문에 블롭 트랜잭션의 포함을 강제할 수 없습니다. 근본적인 원인은 가용성이 블롭 트랜잭션이 포함되는 순간에만 확인 가능하다는 점입니다. 블롭이 전파되어 모든 사람이 샘플링한 후에도 어떤 블롭이 사용 가능한지에 대한 기록이 없으며, 가용성을 확인하는 유일한 방법은 온체인에 블롭 트랜잭션을 포함하는 것입니다.

녹음 가능 여부: DA 계약

이 문제를 해결하는 깔끔한 방법은 blob 트랜잭션 포함 여부와 관계없이 가용성을 기록하는 것입니다. 두 가지 변경 사항을 도입합니다.

페이로드에는 블롭 트랜잭션과 별개로 버전이 지정된 해시가 포함될 수 있습니다. 빌더는 동일 블록에 해당 블롭 트랜잭션이 없더라도 가용성을 확인하려는 블롭에 대한 버전 지정 해시 목록을 포함할 수 있습니다.
가용성은 DA 계약에 기록됩니다 . 각 블록의 시작 부분에서 시스템 호출을 통해 페이로드의 버전별 해시값이 DA 계약에 기록됩니다. 이렇게 생성된 기록은 노드(멤풀 및 FOCIL 참여의 일부)와 EVM 내부에서 어떤 블롭이 사용 가능한지 조회할 수 있도록 합니다.

가용성 강제 적용은 현재와 완전히 동일하게 작동합니다. 검증자는 사용 가능한 블롭이 있는 블록에만 투표합니다. 블록 생성자가 사용 불가능한 데이터에 대한 버전 해시를 포함하면 해당 블록은 검증을 받지 못합니다. 유일한 변경 사항은 버전 해시가 이제 블롭 트랜잭션뿐만 아니라 페이로드에서도 직접 제공될 수 있다는 점입니다.

또한, 블롭 트랜잭션의 온체인 동작을 컨트랙트와 연동되도록 조정했습니다. 블롭 트랜잭션의 유효성은 해당 블롭의 가용성에 따라 결정되지만, 이를 보장하기 위해 이제 blob_tx 유효성 검사의 일환으로 DA 컨트랙트에서 blob_tx.versioned_hashes 의 가용성을 확인합니다. 특히, 이전 블록에서 이미 사용 가능한 것으로 기록된 경우, payload.versioned_hashes 에 blob_tx.versioned_hashes 포함할 필요가 없습니다. 가용성은 한 번만 확인하면 됩니다.

참고: DA 계약은 EVM 내에서 조회 가능하므로 일반 트랜잭션에서도 블롭 가용성을 확인할 수 있습니다. 예를 들어, 특정 블롭의 사용 가능 여부에 따라 로직을 조건화할 수 있습니다. 블롭 트랜잭션은 여전히 기본 인터페이스로 사용될 수 있지만, DA 계약을 통해 가용성과 더욱 유연하게 상호 작용할 수 있는 가능성이 열립니다.

이미지 2960×1456 209KB

그림 7. 가용성 기록 및 시행, 그리고 블롭 트랜잭션 유효성 검사. 빌더는 사용 가능한 블롭을 참조하는 버전별 해시 목록을 포함하며, 해당 블롭의 가용성은 증명을 통해 시행됩니다. 버전별 해시는 전용 DA 계약에 기록되고, 블롭 트랜잭션 유효성 검사는 계약 내의 가용성을 확인합니다.

또한, 멤풀에서 블롭 트랜잭션을 처리하는 방식을 조정하여 멤풀이 계약의 가용성 정보를 활용할 수 있도록 합니다. 이제 블롭 트랜잭션은 다음과 같은 경우 멤풀에 전파될 수 있습니다.
어느 하나:
1. 가용성 기록 : 참조된 블롭의 가용성은 DA 계약에 기록됩니다.
2. 발신자가 미사용 티켓을 보유하고 있습니다 : 발신자는 EL에서 아직 사용되지 않은 유효한 티켓을 보유하고 있습니다(노드에서 로컬로 확인됨).

즉, 티켓은 블롭 트랜잭션이 가용성 기록 전에 전파되는 경우, 예를 들어 블롭 자체와 병렬로 전파되는 경우에만 필요합니다. 가용성이 기록되면 블롭 트랜잭션은 일반 트랜잭션과 마찬가지로 일반 멤풀 규칙에 따라 전파될 수 있습니다. 이는 기본 티켓 시스템의 실질적인 한계를 해결합니다. DA 계약이 없으면 티켓 하나로 몇 번의 블롭 트랜잭션 제출만 허용되고, 멤풀은 티켓 소지자에게만 블롭 트랜잭션 전파를 제한해야 합니다. 가용성이 기록되면 이러한 제약이 사라지므로, 예를 들어 재제출을 특별히 처리할 필요가 없습니다.

이미지 4160×2244 533KB

그림 8. DA 계약을 사용한 블롭 및 블롭 트랜잭션 전파의 전체 그림. 티켓은 두 가지 독립적인 전파 권한을 부여합니다. 하나는 CL의 블롭 하나이고, 다른 하나는 EL의 몇 개의 블롭 트랜잭션입니다. DA 계약에 가용성이 기록된 후에는 블롭 트랜잭션이 티켓 없이 자유롭게 전파될 수 있으므로 무제한 재전송이 가능합니다.

blob txs에 대한 전체 포용성 스토리

블롭 트랜잭션과 별도로 가용성을 기록함으로써, 블롭의 포함(가용성 확인)을 우선적으로 보장하여 블롭 트랜잭션에 대한 검열 저항성을 확보할 수 있습니다. 이를 위해 블롭 티켓 기반 메커니즘을 사용하고, FOCIL과 유사한 포크 선택 강제 방식을 블롭에 적용합니다.

각 PTC(페이로드 적시성 위원회) 구성원은 블록 생성 전 마감일까지 전파된 블롭을 관찰합니다. 이들은 이러한 블롭을 샘플링하여 가용성에 대한 로컬 관점을 형성합니다.
회원들은 자신들이 사용 가능하다고 확인한 버전별 해시 목록을 보냅니다.
다수결 투표를 통해 제안자가 페이로드에 포함 해야 하는 (따라서 DA 계약에 기록해야 하는) 버전별 해시값이 결정됩니다.
제안자는 추가적인 요소들을 포함할 수 있지만, PTC에서 요구하는 요소들은 제외할 수 없습니다.
검증자는 이를 시행합니다. 검증자는 PTC에서 요구하는 버전 정보가 포함된 해시가 있는 블록에만 투표합니다. 단, 검증자가 로컬에서 해당 블록을 사용할 수 없는 경우에는 예외입니다(안전이 항상 우선입니다).

제안자는 이제 블롭 포함과 관련하여 양방향 제약을 받습니다. 즉, PTC에서 요구하는 사항(활성)을 포함해야 하며, 사용할 수 없는 사항(안전성)은 포함할 수 없습니다.

무엇보다 중요한 것은, 블롭의 가용성이 기록되면 해당 블롭을 참조하는 블롭 트랜잭션은 일반 트랜잭션과 동일하게 취급된다는 점입니다. 왜냐하면 추가적인 유효성 조건이 충족된다는 것이 보장되기 때문입니다.

앞서 언급했듯이, 일반적인 멤풀 규칙에 따라 티켓 없이 전파될 수 있습니다.
일반 FOCIL을 통해 포함될 수 있습니다.

더욱이, 티켓 트랜잭션 자체는 일반 트랜잭션과 마찬가지로 동일한 멤풀 및 FOCIL 인프라를 활용합니다. 따라서 블롭 트랜잭션에 대한 엔드 투 엔드 검열 저항성을 확보할 수 있습니다.

이미지 3840×2076 275KB

그림 9. 블롭 트랜잭션에 대한 엔드 투 엔드 포함 보장. PTC는 전파된 블롭(DA 계약에 기록된 버전 해시)의 포함을 강제하는 반면, FOCIL은 티켓 구매 및 블롭 트랜잭션에 대한 포함 보장을 제공합니다.

이러한 종단 간 검열 저항성은 AOT 블롭을 사용하는 블롭 트랜잭션에 적용된다는 점에 유의하십시오. 특정 슬롯의 PTC 마감일 이후에 전파된 AOT 블롭이라도 사용 가능한 상태라면 다음 슬롯부터는 포함 보장을 받을 수 있습니다. 이는 일반적인 FOCIL 동작과 유사한데, IL(포함 목록) 마감일까지 멤풀에 없는 트랜잭션은 현재 블록에 강제로 포함될 수 없지만 다음 블록에는 포함될 수 있습니다.

반면 JIT 블롭은 정의상 블록에 포함될 때만 전파됩니다. 사전 전파 경로가 없으므로 블롭의 가용성을 확인하고 사전에 포함을 보장할 방법이 없습니다. JIT 블롭이 전파될 수 있도록 허용될 때쯤이면 이미 블록에 포함된 상태입니다. JIT 처리 용량은 제안자에게 티켓의 일부("핵심 경로" 부분)를 할당하고, 제안자는 이 권한을 빌더에게 재판매하는 방식으로 생각할 수 있습니다. 따라서 포함 여부는 전적으로 빌더의 재량에 달려 있지만, 우선 순위 수수료를 통해 인센티브를 제공합니다. 동기식 구성 가능성을 위한 블록과 블롭의 공동 생성과 같이 JIT 블롭이 진정으로 필요한 사용 사례의 경우, 빌더가 직접 수행하는 것 외에는 대안이 없으므로 포함 보장이 부족한 것은 불가피합니다. 공동 생성이 엄격하게 필요하지 않은 사용 사례의 경우, JIT로 포함되지 못한 블롭은 언제든지 AOT로 다시 제출하여 위에서 설명한 검열 저항 보장을 완전히 확보할 수 있습니다.

마지막으로, 현재의 시스템과 비교하며 전체적인 설계상을 제시합니다.

이미지 4720×3320 664KB

그림 10. 현재 방식(위) vs. 블롭 스트리밍 방식(아래). 현재 방식에서는 블롭 데이터, 가용성 확인 및 실행이 단일 블록으로 통합되어 있습니다. 블롭 스트리밍 방식에서는 AOT 블롭이 티켓을 통해 사전 전파되고 가용성 확인 계약(DA 계약)에 대해 유효성이 검증됩니다. JIT 블롭은 현재 방식과 마찬가지로 중요 경로에서 전파됩니다. 가용성 확인 계약은 시스템 호출을 통해 가용성을 기록하고, 이후 블롭 트랜잭션은 해당 기록에 대해 유효성이 검증된 후 정상적으로 실행됩니다.

충수

DA 시스템 계약

설계 고려 사항

작성 패턴: 각 블록의 시작 부분에서 시스템 호출을 통해 해당 블록에서 가용성이 확인되는 블롭의 버전별 해시값이 기록됩니다.
읽기 패턴: 버전 해시를 사용하여 계약 쿼리를 실행하고 블롭이 사용 가능한지 확인합니다. 이 작업은 비용이 저렴하고 간단해야 합니다.
스토리지 관리: 스토리지 증가를 제한하려면 주기적으로 항목을 삭제해야 합니다. 슬롯당 128개의 블롭을 저장할 경우, 스토리지 용량 제한이 없다면 연간 약 10GB씩 증가할 것입니다.
현재 블록 접근: 가용성 기록이 이루어진 동일한 블록 내의 트랜잭션은 방금 기록된 데이터에 대한 증명을 생성할 수 없으므로 외부 증명 없이 가용성을 확인할 수 있어야 합니다.

계약 설계

이 계약은 링 버퍼를 통해 최근 윈도우 (~128 블록)를 유지하여 O(1) 증명 없는 쿼리를 가능하게 합니다. 이는 현재 블록 접근 및 일반적인 롤업 사용 사례를 지원합니다.

그뿐만 아니라, 사용자는 각 블록 헤더에 저장된 versioned_hashes_root 통해 포함 여부를 증명할 수 있습니다. 이를 통해 계약 저장 공간을 최소화하면서도 장기간 동안 가용성 조회를 가능하게 하여, 블록의 가용성이 확인된 후 사용자가 온체인에서 트랜잭션을 실행할 수 있도록 충분한 시간을 제공합니다.

참고로, 현재 페이로드에 versioned_hashes 가 포함되어 있는 경우, 블롭 트랜잭션 검증의 일환으로 DA 컨트랙트를 확인하는 작업은 매우 저렴합니다. 이는 버전 해시가 블록 시작 시 DA 컨트랙트에 기록되어 있기 때문에 즉시 읽기 작업이 가능하기 때문입니다. 따라서 가용성 확인이 실행과 동시에 이루어지는 현재 사용 패턴은 사실상 영향을 받지 않습니다.


 # Constants BLOCK_WINDOW = 128 MAX_BLOBS_PER_BLOCK = 128 RECENT_RING_SIZE = BLOCK_WINDOW * MAX_BLOBS_PER_BLOCK # Storage recent_vhs_buffer: list [ Optional [ bytes ]] = [ None ] * RECENT_RING_SIZErecent_availability: dict [ bytes , int ] = {} # vh => 1 if in recent window recent_write_cursor: int = 0 def record_availability ( versioned_hashes: list [ bytes ] ): """Called via system call at block start.""" global recent_write_cursor for vh in versioned_hashes: # Clear old entry at current position old_vh = recent_vhs_buffer[recent_write_cursor] if old_vh is not None : del recent_availability[old_vh] # Record new entry recent_vhs_buffer[recent_write_cursor] = vhrecent_availability[vh] = 1 recent_write_cursor = (recent_write_cursor + 1 ) % RECENT_RING_SIZE def is_available ( versioned_hash: bytes ) -> bool : """Check availability in recent window (no proof needed).""" return recent_availability.get(versioned_hash) == 1

섹터:

스마트 컨트랙트

레이어 1

출처

면책조항: 상기 내용은 작자의 개인적인 의견입니다. 따라서 이는 Followin의 입장과 무관하며 Followin과 관련된 어떠한 투자 제안도 구성하지 않습니다.

라이크

즐겨찾기에 추가

코멘트