Polygon Avail 테스트넷이 현재 가동 중입니다. 사용자가 Avail을 체인 설계에 통합하기 시작하면서 자주 제기되는 질문은 "Avail이 얼마나 많은 트랜잭션을 처리할 수 있습니까?"입니다.
이것은 Polygon Avail의 현재 성능과 장단기 확장 능력을 다루는 일련의 기사 중 첫 번째입니다. 우리는 이미 Avail이 기술적으로 구현되는 방법을 설명하는 자료를 게시했습니다. 시작하려면 두 체인의 현재 아키텍처를 고려하여 Ethereum과 Avail의 처리량을 비교하겠습니다.
폴리곤 어베일 대 이더리움
이더리움 블록은 최대 1.875MB를 저장할 수 있으며 블록 시간은 ~13초입니다. 그러나 Ethereum 블록은 일반적으로 채워지지 않습니다. 거의 모든 블록은 데이터 제한에 도달하기 전에 가스 제한에 도달합니다. 실행 및 결제 모두 가스 비용이 발생하기 때문입니다. 결과적으로 블록당 저장되는 데이터의 양은 가변적입니다.
동일한 블록에서 실행, 결제 및 데이터 가용성을 결합해야 하는 필요성은 모놀리식 블록체인 아키텍처의 핵심 문제입니다. 레이어 2(L2) 롤업은 실행 전용 블록을 사용하여 별도의 체인에서 실행을 처리할 수 있도록 함으로써 모듈식 블록체인 운동을 시작했습니다. Polygon Avail은 데이터 가용성을 분리하고 데이터 가용성 전용 블록이 있는 체인을 허용하여 모듈식 설계를 한 단계 더 발전시킵니다.
현재 Avail의 블록 시간은 20초이며 각 블록은 약 2MB의 데이터를 보유할 수 있습니다. 평균 트랜잭션 크기가 250바이트라고 가정하면 오늘날 각 Polygon Avail 블록은 약 8,400개의 트랜잭션(초당 420개의 트랜잭션)을 보유할 수 있습니다.
더 중요한 것은 Avail이 스토리지 한도까지 블록을 일관되게 채우고 필요에 따라 크기를 늘릴 수 있다는 것입니다. 필요에 따라 블록당 500,000개 트랜잭션(초당 25,000개 트랜잭션) 이상의 숫자를 얻기 위해 우리가 끌어낼 수 있는 많은 수단이 있습니다.
처리량을 늘릴 수 있습니까?
처리량(특히 초당 트랜잭션 수)을 늘리려면 체인 설계자는 블록 크기를 늘리거나 블록 시간을 줄여야 합니다.
체인에 추가되려면 각 블록이 약속을 생성하고, 증명을 구축하고, 전파하고, 다른 모든 노드가 증명을 확인하도록 해야 합니다. 이러한 단계는 항상 시간이 걸리며 블록 시간에 한계를 제공합니다.
결과적으로 블록 시간을 1초 정도로 줄일 수는 없습니다. 약정을 생성하고, 증명을 생성하고, 이러한 조각을 전체 네트워크의 모든 참가자에게 전파할 시간이 거의 없습니다. 1초의 이론적 블록 시간에서 모든 네트워크 참여자가 즉시 약속과 증명을 생성할 수 있는 가장 강력한 시스템을 실행하더라도 병목 현상은 데이터 전파입니다. 네트워크는 인터넷 속도 제약으로 인해 모든 전체 노드에 신속하게 블록을 전달할 수 없습니다. 따라서 우리는 합의에 도달한 후 네트워크 전체에 데이터를 배포할 수 있도록 블록 시간이 충분히 길도록 해야 합니다.
대신 블록 크기를 늘리면 처리량이 증가합니다. 즉, 각 블록에 포함할 수 있는 데이터 양이 증가합니다.
현재 아키텍처: 체인에 블록 추가
시작하려면 체인에 블록을 추가하는 데 필요한 사항을 살펴보겠습니다. 각 블록을 체인에 추가하려면 세 가지 주요 단계가 필요합니다. 블록을 생성하고 해당 블록을 전파하고 해당 블록을 확인하는 데 걸리는 시간입니다.
1. 블록 생산
이 단계에는 Avail 트랜잭션을 수집 및 주문하고, 약정을 구축하고, 데이터 매트릭스를 확장(삭제 코드)하는 데 걸리는 시간이 포함됩니다.
블록 생산은 항상 최소한 어느 정도 시간이 걸리기 때문에 블록을 생산하는 데 필요한 시간을 측정합니다. 결과적으로 우리는 최선의 시간뿐만 아니라 다른 기계에 대한 평균 및 최악의 시간도 고려해야 합니다.
새로운 블록의 생산에 참여할 수 있는 가장 약한 기계는 평균 케이스 시간에서 용량이 최대가 되는 기계입니다. 더 느린 기계는 더 빠른 기계를 따라잡을 수 없기 때문에 필연적으로 뒤처지게 됩니다.
2. 전파 지연
전파 지연은 생산자에서 검증자 및 P2P 네트워크로 블록을 전파하는 데 걸리는 시간을 측정한 것입니다.
현재 Avail에는 2MB 블록이 있습니다. 이 크기의 블록은 현재 20초 블록 시간 제약 조건 내에서 전파될 수 있습니다. 블록 크기가 클수록 전파가 더 까다로워집니다.
예를 들어 128MB 블록을 지원하도록 Polygon Avail을 늘리면 계산이 확장될 수 있습니다(~7초). 그러나 병목 현상은 네트워크를 통해 이러한 블록을 보내고 다운로드하는 데 걸리는 시간이 됩니다.
피어 투 피어 네트워크를 통해 전 세계에 128MB 블록을 5초 만에 전송하는 것이 현재 달성할 수 있는 작업의 한계일 가능성이 높습니다.
128MB 제한은 데이터 가용성이나 약속 체계와 관련이 없으며 오히려 통신 대역폭 제약의 문제입니다.
전파 지연을 고려해야 하는 이러한 필요성은 Polygon Avail에 대한 현재 이론적 블록 크기 제한을 제공합니다.
3. 블록 검증
일단 전파되면 참여하는 유효성 검사기는 블록 제안자가 제공한 블록을 단순히 신뢰하는 것이 아니라 생성된 블록에 실제로 데이터 생산자가 말한 내용이 있는지 확인해야 합니다.
이 세 단계는 서로에게 약간의 긴장감을 줍니다. 우리는 동일한 데이터 센터에서 우수한 네트워킹을 통해 모든 검증자를 강력한 기계로 긴밀하게 연결할 수 있습니다. 그러면 생산 및 검증 시간이 줄어들고 훨씬 더 많은 데이터를 전파할 수 있습니다. 그러나 우리는 또한 다양한 종류의 참가자가 있는 분산되고 다양한 네트워크를 원하기 때문에 바람직한 접근 방식이 아닙니다.
대신 Avail 체인에 블록을 추가하는 데 필요한 단계와 최적화할 수 있는 단계를 이해함으로써 처리량을 개선할 수 있습니다.
현재 Polygon Avail을 사용하는 유효성 검사기는 블록을 확인하기 위해 전체 블록을 가져와 제안자가 생성한 모든 커밋을 재생산합니다. 이는 블록 생산자와 위 그래픽의 모든 단계를 수행하는 모든 유효성 검사기로 해석됩니다.
각 검증자가 전체 블록을 재생성하는 것은 모놀리식 블록체인의 기본값입니다. 그러나 트랜잭션이 실행되지 않는 Avail과 같은 체인에서는 필요하지 않습니다. 결과적으로 Avail을 최적화할 수 있는 한 가지 방법은 유효성 검사기가 블록 재생성과는 반대로 샘플링을 통해 데이터 가용성에 대한 자체 보증에 도달하도록 허용하는 것입니다. 이는 모든 약속을 재생산하도록 요청받은 경우보다 검증자에게 더 낮은 리소스 요구 사항을 부여합니다.