이제 Avail 테스트넷이 활성화되었습니다. 사용자가 Avail을 체인 설계에 통합하기 시작하면서 자주 발생하는 질문은 Avail이 처리할 수 있는 트랜잭션 수는 얼마나 됩니까?입니다. 이것은 확장성에 관한 시리즈의 마지막 기사이며 Avail의 현재 성능과 단기적인 성능에 대해 논의할 것입니다. 그리고 장기적인 확장성. 첫 번째 부분은 여기에서, 두 번째 부분은 여기에서 읽을 수 있습니다.
아래 모델은 블록 제안 및 구성 작업(블록에 포함되는 트랜잭션/데이터 블록 결정)이 분리되어 다양한 행위자에 의해 수행되는 아키텍처를 설명합니다.
이 새로운 블록 빌더 엔터티를 생성함으로써 행 커밋을 생성하고 셀 증명을 생성하는 데 필요한 계산 작업을 여러 참가자 간에 공유할 수 있습니다.
Avail의 핵심 기능은 데이터를 수신하고 정렬된 데이터를 출력하는 것입니다. API처럼 생각해보세요. Avail을 사용하면 누구나 데이터의 가용성을 샘플링할 수 있습니다.
개선할 수 있는 부분을 강조하기 전에 먼저 현재 상태의 블록 제안자 및 검증자/전체 노드에 대한 Avail의 요구 사항을 자세히 설명합니다.
1. 블록 생산자는 블록 본체를 생성합니다.
거래 수집(데이터 제출)
이러한 트랜잭션을 블록 본문이 되는 Avail 데이터 매트릭스로 정렬합니다.
2. 블록 생산자는 블록 헤더를 생성합니다.
매트릭스의 각 행에 대한 약속을 생성합니다.
다항식 보간법을 사용하여 이러한 약속을 확장합니다(생성 및 확장된 약속은 블록 헤더가 됩니다).
3. 블록 생산자는 블록(본문 + 헤더)을 전파합니다.
4. 검증인과 전체 노드가 블록을 수신합니다.
5. 유효성 검사기와 전체 노드는 블록을 디코딩, 재구성 및 검증합니다.
데이터 매트릭스 재구성
약속 재구축
연장된 헌신
수신한 모든 데이터가 생성한 약속과 일치하는지 확인하세요.
전체 노드가 블록 헤더를 재생성하도록 요구하는 다섯 번째 단계는 Avail과 같은 시스템에서는 필요하지 않습니다.
Avail은 실행 작업이 올바르게 완료되었는지 검증자가 확인해야 하는 기존 블록체인의 아키텍처를 상속하기 때문에 현재 전체 노드가 이를 수행합니다. Avail은 실행 작업을 처리하지 않습니다. 블록 제안자, 검증자 및 라이트 클라이언트는 데이터 가용성에만 관심이 있습니다. 이는 Avail 네트워크의 모든 참가자가 데이터 가용성 샘플링을 사용하여 데이터의 가용성을 무신뢰로 확인할 수 있음을 의미합니다.
검증인과 풀 노드는 샘플링을 통해 데이터의 가용성을 확인할 수 있으므로 네트워크 보안을 보장하기 위해 전체 블록을 재구성할 필요가 없습니다.
검증자는 모든 것이 사실인지 확인하기 위해 생산자가 수행한 모든 작업을 다시 실행할 필요가 없습니다. 대신 소량의 샘플링을 통해 확인할 수 있습니다. 라이트 클라이언트와 마찬가지로 통계적으로 데이터 가용성이 보장되면(8~30개 샘플 이후) 검증인은 블록을 체인에 추가할 수 있습니다. Avail에서는 데이터 실행을 처리하지 않기 때문에 이 작업을 안전하게 수행할 수 있습니다.
데이터 샘플링은 검증자에게 번거로운 1:1 검증 프로세스에 대한 훨씬 빠른 대안을 제공합니다. Avail의 마법은 블록 헤더만 사용하면 누구나(이 경우 검증자) 올바른 체인을 따르고 있다는 합의에 도달할 수 있다는 것입니다.
이렇게 할 수 있다면 전체 블록 헤더 재구성 단계를 몇 개의 샘플로 대체할 수 있습니다.
이 글에서는 검증인에 대한 요구 사항의 변화와 기타 개선 사항을 살펴보겠습니다. 우리는 블록 제안자가 (여전히) 블록을 생성하고 전파하지만 다른 모든 네트워크 참여자는 데이터 가용성 샘플링을 통해 네트워크와 상호 작용하는 향상된 시스템을 설명할 것입니다. 그런 다음 두 명의 서로 다른 네트워크 참여자가 운영하는 블록 구성과 블록 제안을 분리하는 추가 시스템을 도입할 것입니다.
이러한 변화는 상대적으로 진보된 것이며 여전히 활발한 연구가 진행 중이라는 점에 유의하는 것이 중요합니다.
Avail의 경우 보다 효율적인 모델은 단일 노드가 약속을 구축하고 네트워크에 전파하는 것입니다. 그런 다음 다른 모든 참가자는 증거를 생성하고 확인합니다.
라이트 클라이언트뿐만 아니라 체인의 모든 부분에서 이를 수행할 수 있게 된 것은 이번이 처음입니다. 우리는 검증인이 라이트 클라이언트와 동일한 방식으로 샘플링할 수 있도록 허용합니다.
이 모델에서는 단일 검증자가 블록을 제안하고 데이터 매트릭스의 모든 행에 대한 약속을 생성한 다음 블록 헤더만 제안합니다.
1단계: 제안자는 블록 헤더 정보만 전파합니다.
2단계: 유효성 검사기는 헤더 정보만 수신하므로 블록을 디코딩하거나 재구성할 수 없습니다. 그러나 데이터 가용성 샘플링을 수행할 수 있으므로 그럴 필요가 없습니다.
이 경우 다른 검증인은 라이트 클라이언트처럼 행동합니다.
이러한 다른 유효성 검사기는 데이터 가용성 샘플링에 대한 약속을 사용하고 가용성 보장이 충족되는 경우에만 블록을 허용합니다.
이 세계에서는 모든 노드가 라이트 클라이언트처럼 실행됩니다. 검증인은 블록 제안자의 올바른 계산을 보장하기 위해 블록 본문을 사용하여 약속을 재생성하는 것을 피할 수 있습니다.
검증자가 단순히 증명 검증에만 의존할 수 있는 경우에는 증명 계산을 위한 약속을 생성할 필요가 없습니다.
블록의 유효한 실행을 확인하기 위해 전체 노드가 필요하지 않기 때문에(Avail은 실행을 수행하지 않습니다!), 전체 노드는 헤더 정보만을 기반으로 올바른 체인을 따르고 있는지 확인할 수 있습니다. 가용성에 대한 증거만 필요하며 헤더 정보(소수의 무작위 샘플과 결합)가 이를 제공할 수 있습니다. 이를 통해 검증자가 되기 위해 필요한 계산량을 줄일 수 있습니다.
이는 잠재적으로 통신 시간을 줄일 수 있다는 추가적인 이점도 있습니다.
복잡성
이 모델을 단기간에 완성하려면 Substrate의 기본 구조에서 벗어나야 하기 때문에 우리는 주저했습니다. Substrate 도구에 대한 모든 액세스를 차단하는 외부 루트를 제거해야 하지만 이는 우리가 적극적으로 탐색하고 있는 개선 사항입니다.
또 다른 모델은 EIP-4844의 샤딩된 blob 모델을 차용한 것입니다.https://eips.ethereum.org/EIPS/eip-4844?ref=blog.availproject.org
다음 시스템을 상상해 보세요.
1. 블록 데이터 매트릭스의 각 행은 서로 다른 빌더에 의해 구축되며 해당 행의 관련 다항식 커밋을 포함합니다.
빌더는 자신의 행을 p2p 네트워크와 공유하고 약속을 제안자에게 전달합니다.
2. 헤더 생성: 단일 블록 제안자는 이러한 약속을 수집합니다.
제안자는 빌더(및 p2p 네트워크)로부터 샘플링하여 특정 약속이 인코딩된 약속을 없애기 전에 유효한 공개 증명을 생성할 수 있는지 확인합니다. 원래 Promise + Extended Promise의 조합이 헤더가 됩니다.
3. 제안자는 이 헤더를 검증자와 공유합니다.
4. 제안자와 검증자는 p2p 네트워크(또는 구축자)에서 무작위 단위를 샘플링하고 데이터가 유효한 공개 증명을 생성하는지 확인하여 데이터 가용성 샘플링을 수행합니다.
5. 검증인이 통계적으로 가용성을 보장하면 블록 헤더가 체인에 추가됩니다.
커밋은 많은 참가자에 의해 생성되므로 블록 제안자는 많은 작업을 수행할 필요가 없습니다.
게으른 제안자 모델은 블록에 대해 단일 제안자를 갖습니다. 그런 다음 위에서 설명한 제안자-작성자 분리와 동일한 방식으로 참가자를 분할할 수 있습니다.
블록의 작은 조각을 만드는 여러 명의 빌더가 있을 수 있습니다. 그들은 모두 이 블록을 엔터티(제안자)에게 보내고, 제안한 헤더를 만들기 위해 각 부분을 무작위로 샘플링합니다.
블록 본체는 논리적 구조를 사용하여 구축됩니다.
한 가지 예
게으른 제안자 모델이 다른 점은 블록 빌더와 블록 제안자가 별도의 개체라는 점입니다.
각각 데이터 매트릭스의 행을 포함하는 4개의 블록 빌더가 있다고 가정합니다. 각 빌더는 이 줄을 사용하여 약속을 만듭니다.
그런 다음 각 빌더는 자신의 행과 빌드된 약속을 지정된 제안자에게 보냅니다. 제안자는 주어진 약속을 확인하기 위해 블록 본문에서 데이터를 샘플링합니다. 그런 다음 제안자는 원래 구성된 약속 중 4개뿐만 아니라 8개도 갖도록 약속을 다항식으로 보간합니다. 이제 데이터 매트릭스가 삭제 인코딩되고 확장되었습니다.
이 8개의 라인과 8개의 약속은 동일한 제안자에 의해 검증됩니다.
전체 매트릭스를 보면 행의 절반은 제안자에 의해 구성되고(삭제에 의해 인코딩됨) 나머지 절반은 제안자에게 제공되는 것을 볼 수 있습니다.
그런 다음 생산자는 블록 헤더를 제안하고 모든 사람이 이를 수락합니다. 이로 인해 더 효율적으로 구축되지만 현재 Avail 테스트넷에서 생성되고 있는 블록과 동일해 보이는 블록이 생성됩니다.
Avail의 게으른 제안자 모델은 더 효율적이지만 상당히 복잡합니다. 전체 시스템을 최적화할 수 있는 다른 더 쉬운 기회가 있지만 Avail 팀은 이 모델 구현을 탐색하게 되어 기쁘게 생각합니다.
전통적인 블록체인 거래와 게으른 제안자 모델 비교
게으른 제안자 모델은 오늘날 비 Avail 블록체인에서 개별 블록체인 거래가 처리되는 방식과 크게 다르지 않습니다.
오늘날 누구든지 거의 모든 체인에서 거래를 할 때 이 거래에 대한 알림을 모든 노드에 보냅니다. 곧 각 노드는 해당 트랜잭션을 해당 멤풀에 갖게 됩니다.
그렇다면 블록 생산자는 무엇을 할까요?
블록 생산자는 자신의 멤풀에서 트랜잭션을 가져와 함께 집계하고 블록을 생성합니다. 이것이 블록 프로듀서의 전형적인 역할입니다.
Avail에서 데이터 블록과 해당 약정은 개별 트랜잭션과 유사하게 처리됩니다. 이러한 데이터 블록 + 약속 조합은 개별 트랜잭션이 기존 체인에서 전송되는 것처럼 시스템에 전파됩니다.
머지않아 모든 사람이 이러한 데이터 덩어리에 전념하게 될 것입니다. 이러한 약속을 통해 제안자는 데이터 가용성을 보장하기 위해 무작위 샘플링을 시작할 수 있습니다. 충분한 샘플링 신뢰도를 통해 노드는 이러한 약속을 확장하고 본문의 데이터를 수락하고 블록 헤더를 구축하여 다음 블록을 생성합니다.
결론
Avail을 위해 제안된 이러한 아키텍처 제안은 블록체인의 다른 핵심 기능에서 데이터 가용성 계층을 분리하는 것의 중요성을 보여주기 위한 것입니다.
데이터 가용성을 별도로 처리하면 데이터 가용성을 독립적인 계층으로 처리하도록 최적화가 이루어질 수 있으며, 이는 데이터 가용성이 실행과 같은 다른 블록체인 기능과 연결되어 있을 때보다 더 큰 개선을 가져올 수 있습니다.
레이어 3 솔루션, 모듈식 블록체인 또는 오프체인 확장 솔루션이라고 부르든, 우리는 새로운 아이디어 팀이 이 전용 데이터 가용성 레이어를 활용하는 것을 보게 되어 기쁩니다. 팀은 Avail이 그 위에 구축된 모든 체인이나 애플리케이션을 통해 직접 확장될 수 있다는 것을 확신할 수 있습니다. 수백 명의 검증인, 수천 명의 라이트 클라이언트, 그리고 앞으로 나올 많은 새로운 체인으로 모듈식 블록체인 네트워크를 구축함에 따라 수요를 충족하는 데 아무런 문제가 없을 것으로 예상됩니다.
