Monad Lianchuang: 칸쿤 이후 롤업의 성능 병목 현상은 무엇입니까?

Azuma

Odaily资深作者

@azuma_eth

2024-03-26 09:15

이 기사는 약 2634자로, 전체를 읽는 데 약 4분이 소요됩니다

L2 가스가 감소하지 않고 증가하는 이유 중 하나는 하드 코어 분석 부분입니다.

AI 요약

펼치기

L2 가스가 감소하지 않고 증가하는 이유 중 하나는 하드 코어 분석 부분입니다.

원저자: Monad 공동 창립자 Keone Hon

편집 : 오데일리 아즈마

편집자 주: 베이징 시간으로 3월 26일 오전, Monad 공동 창업자인 Keone Hon은 Rollup on Personal X의 성능 상태에 대한 심층 기사를 게재했습니다. 기사에서 Keone은 Cancun 업그레이드 후 Rollup의 이론적 TPS 한도를 계산하는 방법을 자세히 설명하고 일부 Layer 2(Base)의 단일 트랜잭션 수수료가 업그레이드 후에도 여전히 몇 달러에 달하는 이유를 설명했습니다. 롤업이 직면한 과제를 간략하게 설명하고 일부 병목 현상 제한 사항과 잠재적인 개선 사항을 설명합니다.

다음은 Odaily가 편집한 Keone의 원본 내용이며, 독자의 편의를 위해 번역가가 원본 텍스트에 일부 내용을 추가했습니다.

최근 시장에서는 레이어 1뿐만 아니라 레이어 2와 관련된 롤업 실행 병목 현상과 가스 제한에 대한 논의가 있었습니다. 아래에서는 이러한 병목 현상에 대해 설명합니다.

데이터 가용성(DA)

칸쿤 업그레이드에 Blob 데이터 구조(EIP-4844)가 도입되면서 이더리움의 데이터 가용성(DA)이 크게 향상되었으며 레이어 2 데이터 동기화 트랜잭션은 더 이상 일반 레이어 1 트랜잭션과 동일한 수수료를 청구할 필요가 없습니다. 시장에 입찰하세요.

현재 Blob의 용량은 블록(12초)당 125kb Blob 3개 정도, 즉 초당 31.25kb 정도인데, 트랜잭션 크기가 약 100바이트라는 점을 감안하면 모든 Rollup이 공유하는 TPS는 약 300 정도라는 뜻입니다.

물론 여기에는 특별한 언급이 필요한 몇 가지 정보가 있습니다.

첫째, Rollup이 더 나은 트랜잭션 데이터 압축 기술을 채택하여 단일 트랜잭션의 크기를 줄이면 TPS가 성장할 수 있습니다.
둘째, 이론적으로 Blob을 사용하여 데이터를 동기화하는 것 외에도 Rollup은 계속해서 calldata를 사용하여 데이터를 동기화할 수 있습니다(즉, Cancun 업그레이드 이전의 기존 솔루션). 하지만 그렇게 하면 복잡성이 더 커집니다.
셋째, 다양한 ZK 롤업 게시 상태(특히 zkSync Era 및 Starknet) 방식에 차이가 있으므로 이러한 롤업의 경우 계산 방법 및 결과도 달라집니다.

롤업 가스 한도

최근 베이스(Base)는 네트워크상의 일반 거래에 가스비가 몇 달러까지 인상되면서 폭발적으로 주목을 받고 있다.

왜 베이스 네트워크는 칸쿤 업그레이드 이후 일정 기간 동안만 성능이 저하되었다가 이제는 업그레이드 이전 수준으로 돌아가거나 심지어 이를 초과하게 되었습니까? 이는 Base의 블록에는 코드의 매개변수를 통해 적용되는 총 가스 제한이 있기 때문입니다.

현재 Base에서 사용하는 가스 매개변수는 Optimism과 동일합니다. 즉, 네트워크의 수요(총 거래 수)가 공급을 초과할 때 레이어 2 블록(2초)당 가스 총 500만 개로 제한됩니다( 블록 공간) 가격 정산은 온디맨드 실행 메커니즘을 채택하여 네트워크에 가스가 급증하게 됩니다.

Base가 총 가스 한도를 늘리지 않는 이유는 무엇입니까? 즉, Rollup이 총 가스 한도를 설정해야 하는 이유는 무엇입니까?

위에서 언급한 데이터 가용성에 대한 TPS 상한 외에도 실제로 실행 처리량의 병목 현상과 상태 증가의 숨겨진 위험이라는 두 가지 주요 이유가 있습니다.

문제 1: 실행 처리량 병목 현상

일반적으로 EVM 롤업은 Geth에서 분기된 EVM을 실행합니다. 이는 Geth 클라이언트와 유사한 성능 특성을 가짐을 의미합니다.

Geth의 클라이언트는 단일 스레드(즉, 한 번에 하나의 작업만 처리할 수 있음)이고 LevelDB/PebbleDB 인코딩을 사용하며 상태를 MPT(merkle patricia trie)에 저장합니다. 이는 SSD(Solid-State Drive)에 데이터를 저장하기 위해 다른 트리 구조(LSM 트리)를 기본 계층으로 사용하는 범용 데이터베이스입니다.

Rollup의 경우 상태 액세스(머클 트리에서 값 읽기)와 상태 업데이트(각 블록 끝에서 머클 트리를 업데이트)는 실행 프로세스에서 가장 비용이 많이 드는 링크입니다. SSD에서 단일 읽기 비용이 40~100 마이크로초이고, 머클 트리 데이터 구조가 다른 데이터 구조(LSM 트리)에 내장되어 있기 때문에 불필요한 추가 찾기가 많이 필요하기 때문입니다.

이 링크는 복잡한 파일 시스템에서 특정 파일을 찾는 과정으로 상상해 볼 수 있습니다. 루트 디렉터리(trie 루트 노드)에서 대상 파일(리프 노드)까지 이동해야 합니다. 각 파일을 검색할 때 데이터베이스 LevelDB에서 특정 키를 찾아야 하며, LevelDB 내부에서는 LSM 트리라는 또 다른 데이터 구조를 통해 실제 데이터 저장 작업을 수행해야 하는데, 이 과정에서 많은 추가 검색이 발생하게 된다. 이러한 추가 단계는 전체 데이터 읽기 및 업데이트를 상당히 느리고 비효율적으로 만듭니다.

Monad 설계에서는 MonadDb를 통해 이 문제를 해결했습니다. MonadDb는 머클 트리를 디스크에 직접 저장하여 LevelDb의 오버헤드를 피하고, 비동기 IO를 지원하여 여러 읽기를 병렬로 처리할 수 있으며, 파일 시스템을 우회하는 맞춤형 데이터베이스입니다.

또한 Monad가 채택한 낙관적 병렬 실행 메커니즘을 사용하면 여러 트랜잭션이 병렬로 진행되고 상태가 MonadDb에서 병렬로 추출될 수 있습니다.

그러나 Rollup에는 이러한 최적화 기능이 없으므로 실행 처리량에 병목 현상이 발생합니다.

Erigon/Reth 클라이언트에는 데이터베이스 효율성을 위한 특정 최적화 기능이 있으며 일부 롤업 클라이언트도 이러한 클라이언트(예: OP-Reth)를 기반으로 구축되었습니다. Erigon/Reth는 플랫 데이터 구조를 사용하므로 어느 정도 읽을 때 쿼리 비용을 줄일 수 있지만 비동기 읽기나 멀티스레드 처리는 지원하지 않습니다. 또한 머클 루트는 각 블록 이후에 다시 계산되어야 하는데, 이는 다소 느린 프로세스이기도 합니다.

질문 2: 국가 성장의 숨겨진 위험

다른 블록체인과 마찬가지로 Rollup은 활성 상태가 너무 빨리 증가하는 것을 방지하기 위해 처리량을 제한합니다.

시장에서는 상태 성장률이 우려되는 이유가 상태 데이터가 크게 증가하면 솔리드 스테이트 드라이브(SSD)에 대한 장치 수요도 높아져야 하기 때문이라는 주장이 일반적입니다. 그러나 나는 이것이 약간 부정확하다고 생각합니다. SSD는 상대적으로 저렴하며(고품질 2TB SSD는 약 200달러입니다), 이더리움의 전체 상태는 거의 10년의 역사에서 고작 200GB 정도였습니다. 순수한 스토리지 관점에서 보면 여전히 성장할 여지가 많습니다.

더 큰 숨겨진 위험은 상태가 계속 증가함에 따라 지정된 상태 조각을 쿼리하는 시간이 길어진다는 것입니다. 이는 현재 머클 패트리샤 트리가 노드에 자식 노드가 하나만 있다라는 조건이 충족되면 단축키를 사용하기 때문인데, 이는 트리의 유효 깊이를 줄여 쿼리 처리 속도를 높일 수 있다. 머클 트리가 점점 더 가득 차면 사용 가능한 단축키가 점점 더 적어질 것입니다.

요약하면, 국가 성장의 숨겨진 위험은 궁극적으로 국가 접근 효율성의 문제이므로 국가 접근을 가속화하는 것이 국가 성장을 더욱 지속 가능하게 만드는 열쇠입니다.

하드웨어 최적화만으로는 작동하지 않는 이유는 무엇입니까?

레이어 2는 여전히 상대적으로 중앙 집중화되어 있습니다. 즉, 네트워크는 여전히 단일 시퀀서에 의존하여 상태를 유지하고 블록을 생성합니다. 모든 상태가 메모리에 저장될 수 있도록 매우 높은 RAM(랜덤 액세스 메모리)이 있는 하드웨어에서 분류기를 실행하는 것은 어떨까요?

여기에는 두 가지 이유가 있습니다.

첫째, 이것은 이더리움 메인 네트워크의 데이터 가용성 병목 문제를 해결하지 못할 것입니다. Base의 현재 상황을 기준으로 볼 때 네트워크 가스의 급증은 메인 네트워크의 데이터 가용성 역량 부족으로 인한 것이 아니라 장기적으로 볼 때 이는 결국 롤업을 제한하는 주요 병목 현상이 됩니다.

두 번째는 탈중앙화 문제입니다. 시퀀서는 여전히 고도로 중앙화되어 있지만 네트워크 운영과 관련된 다른 역할도 중요합니다. 또한 노드를 독립적으로 실행하고 동일한 거래 내역을 재생하며 동일한 상태를 유지할 수 있어야 합니다. .

레이어 1 위의 원시 트랜잭션 데이터와 상태 커밋은 전체 상태를 잠금 해제하는 데 충분하지 않습니다. 전체 상태에 액세스해야 하는 모든 역할(예: 판매자, 거래소 또는 자동 거래자)은 전체 레이어 2 노드를 실행하여 트랜잭션을 처리하고 상태의 최신 복사본을 보유해야 합니다.

롤업은 여전히 블록체인이며, 블록체인은 공유된 글로벌 상태를 통해 글로벌 조정을 달성할 수 있는 능력 때문에 흥미롭습니다. 모든 블록체인에는 강력한 소프트웨어가 필요하며, 하드웨어 최적화만으로는 문제를 해결할 수 없습니다.

커뮤니티 상호 작용

Keone이 이 기사를 게시한 후 여러 헤드 Layer 2 프로젝트의 주요 인력이 게시물 아래에서 상호 작용했습니다.

zkSync의 공동 창립자인 Alex Gluchowski는 머클 루트는 각 블록 후에 다시 계산되어야 한다는 기사의 내용과 관련하여 Monad에게 이 점에서 어떻게 다른지 물었습니다.

Keone의 대답은 각 블록 이후에 머클 루트를 계산하기 위한 최적화된 알고리즘이 있을 것이라는 것이었습니다.

Base 담당자인 Jesse Pollak도 이를 이용해 칸쿤 업그레이드 이후 Base의 가스 비용이 떨어지지 않고 오히려 늘어난 이유를 설명하며, EIP-4844가 Layer 1 수준에서 DA 비용을 대폭 줄였다고 말했다. 가스 비용을 줄여야 했지만 네트워크 거래로 인해 수요가 5배 이상 증가했으며, Base 네트워크의 블록은 250 Gas/s 제한이 있어 수요가 공급보다 많아 가스 요금이 상승합니다.