DA 확장성: Avail의 현재 상태

avatar
ODAILY
11-20
이 기사는 기계로 번역되었습니다
원문 표시

DA 확장성: Avail의 현재 상태

사용자가 Avail을 체인 설계에 통합하기 시작하면 "Avail이 처리할 수 있는 트랜잭션 수는 얼마나 됩니까?"라는 질문이 자주 발생합니다. 이 기사에서는 두 체인의 현재 아키텍처를 기반으로 이더 과 Avail을 비교할 것입니다.

이 기사는 Avail의 확장성에 관한 기사 시리즈 중 첫 번째로, Avail의 현재 성능과 단기 및 장기적으로 확장할 수 있는 능력을 논의합니다.

어베일과 이더리움

이더 의 블록은 최대 1.875MB의 데이터를 담을 수 있으며, 블록 시간은 약 13초이다. 그러나 이더 블록은 일반적으로 채워지지 않습니다. 실행과 결제 모두 가스를 소비하기 때문에 거의 모든 블록이 가스 한도에 도달하여 데이터 상한선에 도달하지 못합니다. 따라서 각 블록에 저장되는 데이터의 양은 가변적입니다.

동일한 블록에서 실행, 결제 및 데이터 가용성을 결합해야 하는 필요성은 단일 블록체인 아키텍처의 핵심 문제입니다. L2 롤업은 모듈 블록체인을 향한 움직임을 시작하여 실행 전용 체인 블록이 있는 별도의 온체인 에서 실행 작업을 처리할 수 있게 되었습니다. Avail은 데이터 가용성을 분리하기 위해 모듈 설계를 채택하여 체인 블록을 데이터 가용성 전용으로 사용할 수 있습니다.

DA 확장성: Avail의 현재 상태

현재 Avail의 블록 시간은 20초이며 각 블록은 약 2MB의 데이터를 보유할 수 있습니다. 평균 트랜잭션 크기를 250바이트로 가정하면 현재 각 Avail 블록은 약 8,400개의 트랜잭션(초당 420개의 트랜잭션)을 수용할 수 있습니다.

또한 Avail은 항상 저장 용량 한도까지 블록을 채우고 필요에 따라 크기를 늘릴 수 있습니다. 필요한 경우 블록당 트랜잭션 수를 500,000개(초당 25,000개 트랜잭션) 이상으로 늘릴 수 있도록 신속하게 조정할 수 있는 다양한 레버가 있습니다.

처리량을 늘릴 수 있나요?

처리량(특히 초당 트랜잭션)을 늘리려면 체인 설계자는 블록 크기를 늘리거나 블록 시간을 줄여야 합니다.

온체인 에 추가되려면 각 블록은 약속을 생성하고, 증명을 구성하고, 전파해야 하며, 다른 모든 노드에서 이러한 증명을 확인해야 합니다. 이러한 단계에는 항상 시간이 걸리므로 블록 생성 및 확인 시간에 자연스러운 상한선이 적용됩니다.

따라서 단순히 블록 시간을 1초로 줄일 수는 없습니다. 이는 약속을 생성하고, 증거를 생성하고, 이러한 부분을 네트워크 전체의 모든 참가자에게 전파하는 데 충분한 시간을 허용하지 않습니다. 이론적으로 1초의 블록 시간 동안 모든 네트워크 참가자가 즉시 약속과 증명을 생성할 수 있는 가장 강력한 시스템을 실행하더라도 병목 현상은 데이터 전파입니다. 인터넷 속도 제한으로 인해 네트워크는 모든 전체 노드에 블록을 충분히 빠르게 알릴 수 없습니다. 따라서 우리는 합의에 도달한 후 데이터가 네트워크에 배포될 수 있을 만큼 블록 시간이 충분히 길도록 보장해야 합니다.

반대로 블록 크기를 늘려 처리량을 늘릴 수도 있습니다. 즉, 블록당 포함할 수 있는 데이터 양을 늘립니다.

현재 아키텍처: 온체인 에 블록 추가

먼저 온체인 블록을 추가하는 데 필요한 단계를 살펴보겠습니다. 각 블록을 온체인 에 추가하려면 세 가지 주요 단계가 필요합니다. 여기에는 블록을 생성하고, 블록을 전파하고, 블록을 검증하는 데 걸리는 시간이 포함됩니다.

DA 확장성: Avail의 현재 상태

1. 블록 생성

이 단계에는 Avail 트랜잭션을 수집 및 순서 하고 약정을 구축하고 데이터 매트릭스를 확장(삭제 코드)하는 데 필요한 시간이 포함됩니다.

블록 생성은 항상 최소한 어느 정도 시간이 걸리기 때문에 블록을 생성하는 데 걸리는 시간을 측정합니다. 따라서 우리는 최상의 경우 시간뿐만 아니라 다양한 시스템의 평균 경우와 최악의 경우 시간도 고려해야 합니다.

새로운 블록 생성에 참여할 수 있는 가장 약한 기계는 평균적인 상황에서 성능 한계에 도달하는 기계입니다. 모든 느린 기계는 더 빠른 기계를 따라잡지 못하기 때문에 결국 뒤처지게 됩니다.

2. 전파 지연

전파 지연 시간은 블록을 생산자에서 검증자 및 P2P 네트워크로 전파하는 데 걸리는 시간을 측정한 것입니다.

현재 Avail의 블록 크기는 2MB입니다. 현재 블록 시간 제한인 20초 내에서 이러한 블록 크기가 전파될 수 있습니다. 블록 크기가 클수록 전파가 더 까다로워집니다.

예를 들어 128MB 블록을 지원하도록 Avail을 늘리면 계산이 확장될 수 있습니다(약 7초). 그러나 병목 현상은 이러한 블록을 네트워크를 통해 전송하고 다운로드하는 데 필요한 시간이 됩니다.

P2P 네트워크를 통해 5초 안에 128MB 블록을 전 세계로 보내는 것은 아마도 현재 달성 가능한 것의 한계일 것입니다.

128MB 제한은 데이터 가용성이나 약정 계획과는 아무런 관련이 없지만 통신 대역폭 제한의 문제입니다.

전파 지연을 고려해야 하는 이러한 필요성은 Avail의 현재 이론적 블록 크기 제한을 제공합니다.

3. 블록 검증

일단 전파되면 참여 검증인은 블록 제안자가 제공한 블록을 단순히 신뢰하는 것이 아니라 생성된 블록이 실제로 생산자가 주장한 데이터를 포함하는지 확인해야 합니다.

이 세 단계 사이에는 일정한 긴장감이 있습니다. 우리는 모든 검증인을 강력한 기계로 만들고 동일한 데이터 센터의 우수한 네트워크로 긴밀하게 연결되도록 할 수 있습니다. 이를 통해 생산 및 검증 시간이 단축되고 더 대량 의 데이터를 확산할 수 있습니다. 그러나 우리는 다양한 유형의 참가자가 있는 탈중앙화 다양한 네트워크를 원하기 때문에 이는 이상적인 접근 방식이 아닙니다.

대신, Avail 체인에 블록을 추가하는 데 필요한 단계와 최적화할 수 있는 단계를 이해함으로써 처리량 향상을 달성할 수 있습니다.

DA 확장성: Avail의 현재 상태

현재 Avail을 사용하는 검증자는 블록 전체를 가져와 제안자가 생성한 모든 커밋을 복사하여 블록을 검증합니다. 이는 블록 생산자와 모든 검증자가 위 다이어그램의 각 단계를 수행해야 함을 의미합니다.

단일 블록체인에서는 각 검증자가 전체 블록을 재구성하는 것이 기본 관행입니다. 그러나 Avail과 같이 트랜잭션이 실행되지 않는 온체인 이러한 재구성이 필요하지 않습니다. 따라서 Avail을 최적화할 수 있는 한 가지 방법은 검증자가 블록을 재구성하는 대신 샘플링을 통해 데이터 가용성에 대한 자체 보장을 달성할 수 있도록 하는 것입니다. 이는 검증자에게 모든 약속을 복제하도록 요구하는 것보다 리소스를 덜 요구합니다. 더 많은 관련 내용은 후속 기사에서 소개하겠습니다.

탐색 데이터 가용성 샘플링은 어떻게 작동합니까?

Avail에서 라이트 클라이언트는 샘플, 약속, 증명이라는 세 가지 핵심 도구를 사용하여 데이터 가용성을 확인합니다.

  • 라이트 클라이언트는 현재 샘플 작업을 수행하여 Avail 네트워크에서 특정 셀의 값과 관련 유효성 인증서를 요청합니다. 더 많은 샘플을 수집할수록 모든 데이터를 사용할 수 있다는 확신이 커집니다.

  • 커밋은 블록 제안자에 의해 생성되며 Avail 블록의 전체 데이터 행을 요약합니다. (팁: 이는 이 시리즈의 뒷부분에서 최적화할 단계입니다.)

  • 네트워크의 모든 셀은 증거를 생성합니다. 라이트 클라이언트는 자신에게 제공된 셀의 값이 올바른지 확인하기 위해 증명과 약속을 사용합니다.

이러한 도구를 사용하여 라이트 클라이언트는 세 단계를 수행합니다.

  • 결정: 필요한 가용성 신뢰도에 따라 라이트 클라이언트가 실행하는 샘플 수가 결정됩니다. 99.95% 이상의 가용성 보장을 달성하기 위해 많은 샘플(8-30개 샘플)이 필요하지 않습니다.

  • 다운로드: 라이트 클라이언트는 이러한 샘플과 관련 증명을 요청하고 네트워크(풀 노드 또는 기타 라이트 클라이언트)에서 다운로드합니다.

  • 검증: 블록 헤더(라이트 클라이언트가 항상 액세스할 수 있음)의 약속을 살펴보고 약속에 대한 각 셀의 증거를 확인합니다.

이것만으로도 라이트 클라이언트는 블록 내용의 대부분을 다운로드하지 않고도 블록 내 모든 데이터의 가용성을 확인할 수 있습니다. 라이트 클라이언트가 수행하는 추가 단계도 Avail의 보안에 기여하지만 여기에 나열되지 않습니다. 예를 들어, 라이트 클라이언트는 필요할 경우 다운로드한 샘플과 교정본을 다른 라이트 클라이언트와 공유할 수 있습니다. 하지만 이것이 라이트 클라이언트가 데이터 가용성을 확인하는 방법입니다!

이 시리즈의 두 번째 부분에서는 단기적으로 Avail의 처리량을 향상시키는 방법을 살펴보겠습니다. Avail이 내년에 모든 네트워크의 요구 사항을 충족할 수 있다고 믿는 이유와 향후 과제를 해결하기 위해 네트워크를 개선할 수 있는 방법에 대해 설명하겠습니다.

출처
면책조항: 상기 내용은 작자의 개인적인 의견입니다. 따라서 이는 Followin의 입장과 무관하며 Followin과 관련된 어떠한 투자 제안도 구성하지 않습니다.
라이크
즐겨찾기에 추가
코멘트