확장 희망은 여전히 허상인가? Layer3는 왜 논란이 되는가?

오리지널｜Odaily星球日报

저자｜Azuma

Layer 3에 대한 논란이 최근 이틀 동안 점점 더 격화되고 있습니다.

한편으로는, Degen Chain과 같은 Layer 3 대표 프로젝트의 관련 토큰이 지난 며칠 동안 놀라운 상승폭을 기록했습니다 ------ DEGEN 자체의 주간 상승폭은 143%에 달하며; Aavegotchi는 Base 계층 Layer 3로 전환한 후 GHST가 역사적인 최고점을 강하게 갱신했습니다.

하지만 다른 한편으로는, 커뮤니티 내에서 Layer 3에 대한 의문이 점점 더 커지고 있으며, Vitalik은 오늘 직접 나서서 반대 의견을 표현했습니다: "Layer 3는 마법처럼 처리량을 증가시키지 않습니다."

어제는 만우절이었고, 많은 프로젝트가 이를 중심으로 약간의 조롱을 섞어 Layer 4, Layer 5에 대한 농담을 했습니다. 예를 들어 dYdX는 "새로운 버전은 L4를 기반으로 구축될 것입니다"라는 농담을 하였고, 이 농담은 일부 미디어에 의해 뉴스로 전해지기도 했습니다.

그렇다면 왜 Layer 3가 이렇게 많은 의문을 받는 것일까요? "Rollup 위에 또 다른 Rollup을 추가하는" 중첩 논리가 왜 정치적으로 올바르지 않은가? 커뮤니티의 논의를 종합해보면, Layer 3에 대한 의문의 초점은 주로 "Layer 3가 실제로 확장 가능성을 가지고 있는가"에 집중되고 있습니다.

Layer 3의 실행 가능성 가정

고전적인 정의에 따르면, Layer 2는 일반적으로 이더리움 메인넷에 의존하여 결제되며, 확장 가능성을 갖춘 네트워크로 정의됩니다; 이와 유사하게, Layer 3의 정의는 Layer 2에 의존하여 결제되며, 더욱 확장 가능한 네트워크입니다.

Layer 2 환경에서, 소위 "이더리움에 의존하여 결제된다"는 기술적 측면에서의 구현 메커니즘은: Layer 2의 많은 거래 데이터를 패키징하고 압축한 후, 이를 이더리움 네트워크에 동기화하고, Calldate(초기 솔루션) 또는 Blob(현재 솔루션)의 데이터 공간을 통해 저장하는 것입니다.

이상적인 상황에서, 만약 Layer 2의 이 결제 논리가 실행 가능하다면, Layer 3가 Layer 2에 의존하여 결제되는 논리도 성립해야 하며, 기술적 측면에서의 구현 메커니즘은: Layer 3의 많은 거래 데이터를 패키징하고 압축한 후, 이를 Layer 2 네트워크에 동기화하는 것입니다……

이 단계에서 문제가 발생하기 시작합니다.

Layer 2 자체가 네트워크의 "최종성" 확인을 책임지지 않고 이더리움에 의존하기 때문에, 이론적으로 Layer 3의 데이터도 결국 이더리움에 제출되어야 하며, 이더리움이 "최종 결정"을 내려야 합니다.

Layer 2에 제출된 Layer 3 압축 데이터에 대해, 이때 두 가지 잠재적인 제출 모드(계속 압축하거나 압축하지 않음)가 있지만, 안타깝게도 어떤 모드도 현재로서는 일정한 문제가 있습니다.

Layer 3 데이터 제출의 이중 모순

첫 번째 잠재적 제출 모드는, 이미 압축된 데이터를 다시 압축하여 다른 Layer 2 거래 데이터와 함께 이더리움 메인넷에 제출하는 것입니다.

들리는 것처럼 매우 좋지만, 현실은 매우 가혹합니다 ------ 불가능합니다.

Vitalik은 2022년에 Layer 3에 대한 분석 기사《어떤 Layer 3가 의미가 있는가》를 작성했으며, 그 안에서 거래 데이터를 여러 번 압축할 수 없는 이유를 설명했습니다.

Rollup은 거래 저장 데이터의 양을 줄이기 위해 일련의 압축 솔루션을 사용합니다. 간단한 송금은 약 100바이트에서 약 16바이트로 압축될 수 있으며, EVM 호환 체인에서의 ERC 20 송금은 약 180바이트에서 약 23바이트로 압축될 수 있고, ZK-SNARK 거래는 약 600바이트에서 약 80바이트로 압축될 수 있습니다. 위의 모든 사례는 약 8배 정도의 압축 효율을 달성할 수 있습니다…… 그러나 Rollup은 여전히 체인에서 데이터 가용성을 유지해야 하며, 사용자가 접근하고 검증할 수 있는 모든 데이터를 보장해야 합니다. 예를 들어 Rollup의 상태를 독립적으로 계산하거나, 기존 검증 노드가 오프라인일 때 새로운 검증 노드로 참여하는 등의 경우입니다…… 데이터는 한 번 압축될 수 있지만, 반복적으로 압축될 수는 없습니다. 만약 가능하다면, 일반적으로 두 번째 압축기의 논리를 첫 번째 압축기에 통합할 수 있지만, 이는 우리가 한 번의 압축으로 동일한 효과를 얻을 수 있다는 것을 의미합니다. 따라서 "Rollup 위에 또 다른 Rollup을 추가하는 것"은 실제로 확장 효과를 제공하는 솔루션이 아닙니다.

간단히 말해, 데이터 가용성 문제로 인해 거래 데이터를 압축하는 데는 일정한 제한이 있습니다.

이러한 전제 하에, 만약 우리가 두 번째 압축 논리를 첫 번째 압축 과정에 통합하여 Layer 3 데이터의 다중 압축을 구현할 수 있다면, 이는 또한 Layer 2 데이터에 대해 다중 압축을 수행할 수 있다는 것을 의미하며, 따라서 Layer 2 수준에서 직접 동일한 확장 효과를 달성할 수 있다면, 왜 우리는 Layer 3가 필요할까요?

그 이유는 압축 알고리즘이 본질적으로 어느 정도 데이터 중복을 제거하여 데이터를 더 간결하게 만드는 것이기 때문입니다. 그러나 이러한 중복이 제거되면 이미 압축된 데이터에 대해 다시 압축하는 것이 더 어려워지며, 제거할 수 있는 중복은 점점 줄어들기 때문입니다. 따라서 데이터 압축은 무한히 반복할 수 있는 과정이 아니며, 압축의 수익도 감소합니다.

다음으로 두 번째 잠재적 제출 모드를 살펴보면, Layer 3 데이터를 더 이상 압축하지 않고 다른 Layer 2 거래와 함께 이더리움 메인넷에 직접 제출하는 것입니다.

이것 또한 다소 이해할 수 없는 부분이 있습니다. 왜냐하면 전반적으로, 현재 이더리움 생태계의 확장 효과를 제한하는 주요 병목 현상은 Layer 2(및 Layer 3)에서의 블록 공간 부족이 아니라, 메인넷의 데이터 가용성 수용 능력이 제한적이기 때문입니다 ------ 즉, Layer 2 데이터를 저장하기 위한 Blob 저장 공간이 여전히 제한적입니다.

Monad의 공동 창립자 Keone Hon은 이전에 Blob의 용량 상태가 현재 각 블록(12초)마다 3개의 125kb Blob을 생성하고 있으며, 이는 초당 31.25kb에 해당한다고 언급했습니다. 거래의 양이 약 100바이트(비탈릭이 제시한 숫자보다 약간 높음)라는 점을 고려할 때, 모든 Layer 2의 공유 TPS는 약 300 정도입니다.

이러한 전제 하에, 모든 Layer 2(및 Layer 3)는 동일한 데이터 가용성 한계에 의해 제약을 받으며, 이는 Layer 2와 Layer 3가 제공하는 블록 공간이 아무리 많더라도 "최종성" 확인을 완료할 때 하나씩 차례로 대기해야 함을 의미합니다.

이것이 바로 Vitalik이 Layer 3가 이더리움 생태계의 확장 상태를 신비롭게 개선하지 않을 것이라고 강조하는 이유입니다.

Layer 3는 전혀 의미가 없는가?

위의 분석을 종합해보면, 압축 효율 및 데이터 가용성 한계 등의 제약으로 인해 현재 Layer 3는 일반적인 확장성 측면에서 뚜렷한 효과를 제공하지 못합니다. 그렇다면 이것이 Layer 3가 순전히 "허상"이며 실질적인 의미가 없다는 것을 의미할까요? 답은 그렇게 절대적이지 않습니다.

Starkware는《계층 확장, L2에서 L3로》에서 Layer 3의 몇 가지 잠재적 발전 방향을 개요했습니다. 예를 들어 Layer 2는 일반 네트워크로 운영될 수 있으며, Layer 3는 맞춤형 기능을 강화하여 전용 네트워크로 운영될 수 있습니다; 또 다른 예로 Layer 2는 신뢰 없는 확장성에 집중하고, Layer 3는 약한 신뢰 확장성에 집중할 수 있으며, 즉 일정한 외부 신뢰 조건을 도입하여 데이터 가용성 등의 까다로운 문제를 처리할 수 있습니다.

마지막으로 Vitalik이《어떤 Layer 3가 의미가 있는가》에서 한 말을 인용하며 마무리하겠습니다: "Rollup 위에 또 다른 Rollup을 쌓는 것은, 특히 두 층이 동일한 기술 메커니즘을 사용할 경우, 분명히 불가능합니다. 그러나 Layer 2와 Layer 3가 서로 다른 설계와 목표를 가지고 있다면, 이러한 3층 구조의 확장 구조는 실행 가능할 것입니다."