확장을 희망합니까 아니면 잘못된 개념입니까? Layer3가 왜 그렇게 논란의 여지가 있습니까?

원본|오데일리

작가│아즈마

레이어 3를 둘러싼 논란은 지난 이틀 동안 더욱 심화됐다.

한편, Degen Chain과 같은 대표적인 Layer 3 프로젝트의 관련 토큰은 지난 며칠 동안 놀라운 증가를 경험했습니다. DEGEN 자체는 Aavegotchi가 기본 기반 레이어로 전환하기로 선택한 후 주간 최대 143% 증가했습니다. 3, GHST도 역대 최고치를 대폭 갱신했다.

그러나 반면에 레이어 3에 대한 커뮤니티의 의구심은 점점 커지고 있습니다. Vitalik은 오늘 직접 나서서 반대 의사를 표명했습니다.레이어 3은 마법처럼 처리량을 늘리지 않습니다.

어제는 만우절이었는데, 많은 프로젝트들이 이것을 초점으로 삼아 Layer 4와 Layer 5에 대해 다소 농담적인 방식으로 농담을 했습니다. 예를 들어 dYdX는 새 버전은 L4를 기반으로 구축될 것입니다.라고 농담을 한 적이 있습니다. 이 농담은 일부 언론 매체에서도 뉴스로 취급되기도 했습니다.

레이어 3에 대한 타당성 가정

그렇다면 레이어 3이 왜 그토록 의문을 제기하는 걸까요? 롤업 + 롤업이라는 마트료시카 논리가 정치적으로 충분히 올바르지 않은 이유는 무엇입니까? 커뮤니티의 논의에 따르면 레이어 3를 둘러싼 의구심의 초점은 주로 레이어 3가 실제로 확장 의미를 갖는지 여부에 있습니다.

고전적인 정의에서 보면,레이어 2는 결제를 위해 이더리움 메인 네트워크에 의존하고 확장 가능한 네트워크로 정의되는 경우가 많으며, 비유적으로 레이어 3은 결제를 위해 레이어 2에 의존하고 확장성이 뛰어난 네트워크로 정의됩니다.

Layer 2 환경에서는 소위 결제를 위해 Ethereum에 의존하는 것이 기술적으로 구현됩니다. 대량의 Layer 2 거래 데이터를 패키징 및 압축한 후 이를 Ethereum 네트워크에 동기화하고 Calldate를 통해(초기 솔루션) 또는 저장을 위한 Blob(현재 구성표) 데이터 공간.

이상적으로 Layer 2의 결제 로직이 가능하다면 결제를 위해 Layer 2에 의존하는 Layer 3의 로직이 사실인 것으로 보입니다. 기술적 구현 메커니즘은 대량의 Layer 3 트랜잭션 데이터를 패키징하고 압축해야 합니다. 그런 다음 레이어 2 네트워크에 동기화됩니다.

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

Layer 2 자체는 네트워크의 최종성을 확인하는 역할을 담당하지 않고 이더리움에 의존하기 때문에,이론적으로 레이어 3 데이터는 결국 이더리움에 제출되어야 하며 이더리움이 최종 결정권을 갖게 됩니다.

Layer 2에 제출된 Layer 3 압축 데이터의 경우 두 가지 잠재적인 제출 모드(압축 계속 또는 더 이상 압축 안함)가 있지만 안타깝게도 현재로서는 어떤 모드에든 특정 문제가 있습니다.

레이어 3 데이터 제출의 이중 역설

첫 번째는 첫 번째 잠재적인 제출 모드입니다.압축된 데이터는 다시 압축되어 다른 레이어 2 거래 데이터와 함께 이더리움 메인 네트워크에 제출됩니다.

듣기에는 훌륭하지만 현실은 잔인합니다.

Vitalik은 2022년 레이어 3에 대한 분석 기사를 작성했습니다.어떤 종류의 레이어 3이 의미가 있나요? 기사에서는 거래 데이터를 여러 번 압축할 수 없는 이유를 설명했습니다.

Rollup은 일련의 압축 방식을 사용하여 트랜잭션에 저장되는 데이터의 양을 줄입니다. 단순 전송의 경우 약 100바이트에서 약 16바이트로 압축할 수 있으며, EVM 호환 체인의 ERC 20 전송은 약 180바이트에서 압축할 수 있습니다. 약 23바이트로 ZK-SNARK 트랜잭션을 약 600바이트에서 약 80바이트로 압축할 수 있습니다. 위의 모든 경우는 약 8배의 압축 효율성을 달성할 수 있습니다... 하지만 Rollup은 여전히 ​​모든 데이터에 대해 사용자가 액세스하고 확인할 수 있도록 하기 위해 체인에서 데이터 가용성을 유지해야 하기 때문에(예: Rollup의 상태를 독립적으로 계산하거나) 기존 검증 노드가 오프라인 상태일 때 새로운 검증 노드로 합류하게 되는데...데이터는 한 번 압축할 수 있지만 반복적으로 압축할 수는 없습니다.이는 일반적으로 가능하다면 두 번째 압축기의 논리를 첫 번째 압축기에 넣을 수 있음을 의미하지만 단 한 번의 압축으로 동일한 효과를 얻을 수도 있음을 의미합니다. 따라서 롤업 위에 다른 롤업을 놓는 것은 실제 용량 확장 솔루션이 아닙니다.

간단히 말해서, 데이터 가용성 고려 사항으로 인해 트랜잭션 데이터를 압축하는 데 특정 제한이 있습니다.

이 전제하에,두 번째 압축 논리를 첫 번째 압축 프로세스에 통합하여 레이어 3 데이터의 다중 압축을 달성할 수 있다면 이는 레이어 2 데이터에 대해 직접 다중 압축을 수행한 다음 레이어 2 데이터에 대해 다중 압축을 수행할 수도 있음을 의미합니다. 레이어 3에서도 동일한 확장 효과를 얻을 수 있는데 왜 레이어 3이 필요한가요?

그 이유는 압축 알고리즘은 본질적으로 데이터 중복성을 어느 정도 제거하여 데이터를 더욱 컴팩트하게 만들기 때문입니다. 그러나 이러한 중복성을 제거하면 이미 압축된 데이터를 다시 압축하기가 점점 더 어려워집니다. 제거할 수 있는 중복성. 따라서 데이터 압축은 무한히 반복될 수 있는 프로세스가 아니며, 압축에 따른 수익도 점점 줄어들고 있습니다.

다음으로 두 번째 잠재적인 제출 모드를 살펴보겠습니다.즉, 레이어 3 데이터는 더 이상 압축되지 않고 다른 레이어 2 트랜잭션과 함께 이더리움 메인 네트워크에 직접 제출됩니다.

이것도 좀 당혹스러운 느낌이 듭니다. 왜냐하면 전반적으로,현재 이더리움 생태계의 확장을 제한하는 주요 병목 현상은 레이어 2(레이어 3 포함)의 블록 공간 부족이 아니라 메인 네트워크의 제한된 데이터 가용성 및 전송 용량입니다.——계층 2 데이터를 저장하는 데 사용되는 Blob 저장소 공간은 여전히 ​​제한되어 있습니다.

Monad 공동 창립자인 Keone Hon은 이전에 현재 Blob 용량이 블록당 약 125kb Blob 3개(12초), 즉 초당 31.25kb라고 게시한 바 있습니다. 트랜잭션 수가 약 100바이트(주어진 숫자보다 약간 높음)임을 감안할 때 Vitalik 작성) 이는 모든 레이어 2의 공유 TPS가 약 300임을 의미합니다.

이러한 전제 하에 모든 Layer 2(Layer 3 포함)에는 동일한 데이터 가용성 상한이 적용되며, 이로 인해 Layer 2와 Layer 3에서 아무리 많은 블록 공간을 제공하더라도 최종성 확인을 완료할 수 없습니다. .때때로 한명씩 줄을 서야 할 때도 있습니다.

이것이 Vitalik이 레이어 3이 이더리움 생태계의 확장을 마술처럼 향상시키지는 않을 것이라고 강조한 이유입니다.

레이어 3은 의미가 없나요?

위의 분석을 바탕으로 압축 효율성의 한계와 데이터 가용성의 상한으로 인해 현재 Layer 3는 일반적인 확장에 큰 효과를 제공할 수 없음을 알 수 있습니다. 그렇다면 이는 레이어 3이 순전히 의사 개념이고 실질적인 의미가 없다는 것을 의미합니까? 대답은 그리 절대적이지 않습니다.

스타크웨어는 L2에서 L3으로 계층적 확장》는 Layer 3의 몇 가지 잠재적인 개발 방향을 간략하게 설명합니다. 예를 들어, Layer 2는 범용 네트워크로 작동할 수 있고, Layer 3는 사용자 정의 기능을 강화하여 전용 네트워크로 작동할 수 있습니다. 또 다른 예는 Layer 2가 무신뢰 확장에 집중할 수 있다는 것입니다. 레이어 3은 무신뢰 확장에 집중할 수 있으며, 그런 다음 데이터 가용성과 같은 더 어려운 문제를 처리하기 위해 특정 외부 신뢰 조건을 도입함으로써 약한 신뢰 확장에 집중할 수 있습니다.

마지막으로 에서 Vitalik을 적용하십시오.어떤 종류의 레이어 3이 의미가 있나요?특히 두 레이어가 동일한 기술 메커니즘을 사용하는 경우 롤업 위에 다른 롤업을 놓는 것은 분명히 불가능합니다. 그러나 레이어 2와 레이어 3의 디자인이 다르고 목표가 다른 경우 이러한 3계층 확장 아키텍처가 가능합니다.