이 논문은 탈중앙화를 유지하면서 확장성을 향상시키기 위한 데이터 가용성 샘플링(DAS)과 샤드 블롭 멤풀의 새로운 설계를 제안합니다. 전통적인 단크샤딩 전략은 블록을 생성하고, 소거 코드를 적용한 후 전체 P2P 네트워크에 완전한 데이터를 배포하는 블록 빌더/제안자를 가정합니다. 이는 네트워크 대역폭 측면에서 매우 까다로우며, 특히 블록 빌더와 제안자가 동일한 노드인 소규모 홈 스테이커의 경우 더욱 그렇습니다. 이 논문의 제안은 두 가지 새로운 아이디어를 통해 분산 블록 빌딩(DBB)을 구현함으로써 이 문제를 극복합니다: i) 샤드 블롭 멤풀, ii) 부분 열 배포.
이 논문의 나머지 부분은 다음과 같이 구성됩니다. 먼저, 이 새로운 설계의 기반이 되는 기본 가정을 설명합니다. 그런 다음 현재의 DAS 및 블롭 멤풀 설계를 제시합니다. 마지막으로 제안된 설계와 그 장점을 설명합니다.
가정
이 연구에서 작업하는 주요 가정은 다음과 같습니다.
네트워크 규모: 현재 이더리움의 네트워크 규모는 약 10,000개의 노드로 추정됩니다. 이 논문에서는 네트워크 규모가 5,000에서 50,000개의 노드 사이를 유지할 것으로 가정하며, 향후 변경될 수 있음을 이해합니다.
블록 구조: 모든 데이터 블롭이 512바이트 요소인 "셀"로 구성되며, 이후 소거 코딩(리드-솔로몬)을 사용하여 그룹화되고 확장되어 2차원 행렬을 생성한다고 가정합니다.
슬롯 처리량: 목표 처리량은 각각 128KB의 256개 블롭으로, 소거 코딩 확장 전 슬롯당 총 32MB입니다. 따라서 2D 소거 코딩 확장 후 크기는 128MB입니다.
데이터 배포: Gossipsub은 P2P 네트워크 내 여러 채널에서 합의 계층(CL)에 데이터를 배포하는 데 사용됩니다. Gossipsub이 수천 개의 주제로 확장될 수 있다고 가정합니다.
부분 열 전송은 전체 열 전송과 반대로, 이 새로운 설계의 중요한 부분입니다. 수평적으로 샤딩된 멤풀에서는 대부분의 노드가 실행 페이로드를 받을 때 전체 열을 전파할 수 없기 때문입니다. 따라서 부분 열 전송은 부분 데이터를 전파하고 블록 확산 속도를 높이는 데 필요합니다. 예를 들어, blob 멤풀이 16개의 샤드로 나뉘어 있다면, 노드가 전체 열을 얻으려면 해당 열의 gossipsub 주제에서 16개의 부분 열 메시지를 받아야 합니다. 모든 노드가 실행 페이로드를 받는 즉시 부분 열을 전파함으로써, 네트워크는 블록 빌더/제안자의 업로드 속도에 의존할 필요가 없습니다. 이는 블록 제안자가 제한된 업로드 대역폭을 가진 홈 스테이커인 경우 특히 중요합니다. 또한, 모든 EL 노드가 멤풀에 모든 blob을 가지고 있고 블록 제안자 병목 현상을 피하기 위해 전체 열을 공유한다고 해도, 여전히 전체 열을 업로드하게 됩니다. 반면에 이 설계는 각 노드가 열의 1/16만 보낼 수 있게 하여 대역폭 소비를 줄입니다.
새로운 설계 슬롯 주기
1. 멤풀
이 설계와 기존 설계의 주요 차이점은 샤딩된 멤풀의 도입입니다. 이 설계에서 노드는 특정 수의 3유형 트랜잭션과 관련 blob 사이드카(즉, blob 데이터)만 다운로드합니다. 각 노드가 보관해야 하는 blob은 노드 ID로부터 결정론적으로 계산되어, 모든 노드가 자신을 위해 다운로드할 blob과 피어들이 보관하는 blob을 알 수 있습니다. blob 멤풀에 저장해야 할 최소 수의 3유형 트랜잭션이 있습니다. 검증자가 있는 노드는 검증자 보관과 유사하게 blob 멤풀에 더 많은 blob을 보관할 수 있습니다. 노드는 많은 검증자가 있거나 작업에 필요하기 때문에(예: 블록 빌더, 롤업, 탐색기) blob 멤풀에 모든 blob을 다운로드하도록 선택할 수 있습니다.
2. 빌딩
목표는 소거 코딩 전에 슬롯당 각각 128KB의 256개 blob, 총 32MB의 blob 데이터를 도입하는 것입니다. 이 새로운 설계에서 블록 빌더/제안자는 블록에 추가할 제한된(즉, 샤딩된) 3유형 트랜잭션 목록을 가집니다. 제한된 목록의 blob만 추가하기로 결정할 수 있습니다. 그러나 다른 전략도 있습니다. 블록 제안자가 미리 알려져 있기 때문에, 다음 에포크에 블록을 제안해야 하는 노드는 블록이 제안되는 순간까지 일시적으로 blob 멤풀의 동작을 변경하여 모든 3유형 트랜잭션과 blob을 다운로드하기 시작할 수 있으며, 이후 표준 blob 멤풀 동작으로 돌아갈 수 있습니다.
3. 전파
블록 빌더/제안자가 먼저 전파해야 할 것은 블록에 첨부된 3유형 트랜잭션 및 blob 목록을 포함하는 실행 페이로드입니다.
CL 노드는 EC-확장 블록의 일정 수의 행과 열을 보관(즉, 저장)해야 합니다. 이 설계에서는 CL이 보관해야 할 행이 EL이 멤풀에 다운로드해야 할 blob과 동일해야 한다고 제안합니다. 이렇게 함으로써, 블록에 포함된 blob과 관계없이 프로토콜을 따르는 모든 CL 노드가 네트워크를 통해 수평 행을 받을 필요가 없도록 보장합니다. 대신 수평적으로 확장하고 EL blob 멤풀에서 CL 보관 저장소로 전송할 수 있습니다. 이 맥락에서 어떤 노드도, 블록 빌더조차도 CL 네트워크를 통해 수평 행을 밀어내서는 안 됩니다. 수평 전파가 EL에서 발생하기 때문입니다. 어떤 이유로(예: 네트워크 또는 하드웨어 장애) 노드가 blob 멤풀에 있어야 할 blob을 가지고 있지 않다면, 피어로부터 풀링을 통해 요청할 수 있습니다.
열 전파와 관련하여, CL 노드가 블록의 실행 페이로드를 받으면 블록에 포함될 blob을 알게 됩니다. 노드는 블록의 일부 행을 가지고 있으므로 책임져야 할 열의 일부 셀도 가지고 있지만 전체는 아닙니다. 따라서 (슈퍼노드가 아닌 한) 전체 열을 보내는 대신 노드는 Gossipsub 주제를 통해 부분 열을 전파합니다. 이를 통해 열 주제의 모든 피어로부터 빠르게 열을 검색할 수 있습니다. 노드가 비확장 열의 모든 셀을 받으면 소거 코딩으로 열을 수직으로 확장합니다. 이 시점에서 네트워크의 모든 노드는 해당 행과 열을 보관해야 합니다.
4. 샘플링
이 새로운 설계에서 샘플링에는 큰 변화가 없습니다. 모든 것이 이전 설계와 동일하게 진행됩니다.
몇 가지 숫자
어느 시점에나 블록 빌더가 선택할 수 있는 약 천 개의 3유형 트랜잭션이 있다고 가정해 보겠습니다. 이는 blob 멤풀에 모든 blob을 원하는 블록 빌더의 경우 대략 128MB가 됩니다. 검증자가 없는 노드가 노드 ID의 마지막 4비트로 끝나는 blob을 보관한다고 가정하면, 평균적으로 1024개 중 64개 blob(~8MB)을 보관하게 됩니다. 8,000개의 노드와 균일하게 분포된 노드 ID를 가진 네트워크를 가정하면, 모든 blob은 약 500개의 노드에 저장되어 충분한 중복성과 견고성을 제공합니다. 크롤러 덕분에 현재 네트워크의 EL 노드 목록을 가져와 이 설계에 따라 샤딩했습니다. 위 그림은 각 샤드에 있는 노드 수를 보여줍니다.
(번역 계속됨...)
