rapidblocks의 핵심 아이디어는 블록 간 종속성 없이 블록을 구축 할 수 있다면 슬롯 시간을 단축하고 , 거래 포함 시간을 줄이고 , 블록 생산을 상당히 확장 할 수 있는 잠재력이 있다는 것입니다.
그 이유는 주로 다음과 같습니다.
- "재구성" 비용을 절감할 수 있습니다. 값비싼 재구성 없이도 일부 빠른 블록을 건너뛸 수 있습니다. (실제로 훨씬 더 저렴해질지, 아니면 비트(Bit) 더 저렴해질지는 아직 알 수 없습니다.)
- 우리는 이러한 독립적인 블록을 거의 병렬로 구축 할 수 있습니다. 거의 병렬로 말이죠. 왜냐하면 빌더를 정렬하고 약간의 정보 흐름이 필요하기 때문입니다.
물론, 여기에는 비용이 따릅니다. 블록들이 실제로 어떻게든 서로 의존해야 하기 때문입니다. 이 부분은 후반부에서 다루겠습니다.
이 글은 완성된 디자인이라기보다는 아이디어를 떠올리고 토론을 시작하는 용도로 생각해 주세요. 설명이 너무 복잡하고 세부적인 내용이 누락되어 있어, 실제로 구현하기 어려울 수 있습니다.
이 아이디어의 기본은 밸런서(BAL) 게시물에 대한 답변에서 처음 등장했습니다.
"독립적인" 블록을 만드는 방법
수정된 상태
블록 i+1의 빌더가 블록 i에 의해 상태가 수정된 모든 주소(또는 <주소, 저장 키> 쌍)를 알고 있다고 가정합니다.
이제 블록 i에 의해 수정되지 않은 상태 부분만을 기반으로 하는 블록 구축할 수 있습니다. 다시 말해, 블록 i-1의 "이전" 사후 상태 위에 블록을 구축할 수 있으며, 이는 다음과 같은 의미를 가집니다.
- 블록 i는 블록 i+1을 삭제하지 않고도 체인에서 "건너뛸" 수 있습니다.
- 블록 i+1의 빌더는 빌드하기 전에 블록 i를 실행할 필요가 없습니다.
- 블록 i의 상태 변화를 알 필요조차 없습니다.
접근된 상태
이제 블록 i+1의 생성자가 블록 i가 접근(읽기 또는 쓰기)한 모든 주소(또는 <주소, 저장 키> 쌍)를 알고 있다고 가정합니다. 이 정보를 바탕으로 블록 i와 논리적으로 병렬화 가능한 더욱 강력한 블록 생성할 수 있습니다.
- 블록 i+1은 블록 i에 의존하지 않습니다
- 블록 i는 블록 i+1에 의존하지 않습니다
실행 순서가 중요하지 않으므로 이를 통해 "체인"을 더욱 저렴하게 재구성할 수 있습니다.
물론, 독자는 가정 1과 2가 이미 오늘날에도 유효하다는 것을 알아챘습니다. 우리 블록 빌더는 이 모든 주소를 알고 있습니다. 그렇다면 우리는 무슨 말을 하는 걸까요?
여기서 주의해야 할 중요한 점이 두 가지 있습니다.
- a, 다음 블록 빌더가 이 지식을 가지고 있는 반면, 우리는 이를 효율적으로 전달하지 못해 슬롯 시간이 길어집니다.
- b, 다음 블록 빌더가 이러한 지식을 가지고 있는 반면, 우리는 블록 독립성을 강제하지 않고 있습니다. 슬롯 시간을 줄이면 더 빈번하고 비용이 더 많이 드는 재구성이 발생하게 됩니다.
하지만 이건 미친 짓이에요. 블록은 (이제) 이전 블록 에 의존하는 거 아닌가요?
맞아요. 하지만 그중 극히 일부일 뿐입니다. 흥미롭게도, 일반적인 블록 내 거래의 90% 이상이 이전 블록 에 의존하지 않는 거래로 구성되어 있는 것으로 보입니다. 블록 간 종속성의 현재 상태에 대한 자세한 내용은 워밍(warming)에 대한 이 게시물을 참조하세요.
이러한 전제를 바탕으로 repidblocks를 실현하는 데 사용할 수 있는 잠재적인 도구가 무엇인지 살펴보겠습니다.
도구
BAI와 BMI
이러한 아이디어의 주요 영감은 토니의 훌륭한 작품에서 밸런서(BAL) 이라고도 불리는 다양한 형태의 블록 수준 상태 변경 및 액세스 목록을 탐구한 것입니다.
조건 1이 밸런서(BAL) 의 블록 이후 상태 변경의 주소 목록 부분임을 쉽게 알 수 있습니다. 이를 BMI, 즉 블록 수준 상태 수정 지수라고 부르겠습니다.
두 번째 조건은 사전 또는 사후 상태 정보 없이 밸런서(BAL) 매핑합니다. 이를 BAI, 즉 블록 수준 접근 색인이라고 부르겠습니다.
참고: 아마도 이것을 저장 위치/쓰기 위치라고 불러야 할 것입니다. 그러나 Locataion의 L은 이미 Lists의 L로 사용되었습니다.
따라서 이 중 하나를 다음 빌더로 빠르게 전달할 수 있고, 블록 독립성 덕분에 더 저렴한 재구성(reorg)을 활용할 수 있다면 슬롯 시간을 줄일 수 있습니다. 이더리움에서는 이를 단순히 다음 빌더로 빠르게 전달할 수 없으며, 전체 네트워크로 전송해야 합니다. 다음 검증자를 알고 있더라도 네트워크의 어디에 있는지 알 수 없으며, 검증자 ID를 기반으로 하는 라우팅도 없습니다. 이는 당연한 이유입니다.
그래도 네트워크에서 BAI(더 큰 값)나 BMI(더 작은 값)를 우선시하여 슬롯 타임을 줄이는 것을 생각해 볼 수 있습니다.
BAF와 BMF
BAI나 BMI를 단일 IP 패킷으로 압축하여 네트워크에서 빠르게 전송할 수 있다면 더욱 좋을 것입니다. 이를 통해 전체 네트워크에 정보를 300ms 이내에 분산시킬 수 있습니다. 블룸 필터를 사용하는 것도 한 가지 방법입니다. 자세한 내용은 제 BAF 게시물을 참조하세요.
래피드블록 "체인" 구조
마지막 도구는 새로운 "체인" 구조입니다. 사실, 기본 구조는 체인이 아니라 제한된 DAG이지만, 누군가 정말로 필요하다면 체인 뷰로 쉽게 "선형화"할 수 있습니다. (그리고 저는 이것이 호환성과 이 아이디어들의 궁극적인 진화적 도입을 위해 중요한 부분이라고 생각합니다.)
물론 블록 에는 종속성이 있어야 합니다. 하지만 이전에 만들어진 블록에 의존할 필요는 없습니다. 슬롯 시간을 줄일 수 있다면, 이전 블록과의 독립성을 강화하고 이전 블록과의 독립성을 허용하면 실제로 동일한 결과를 얻을 수 있습니다.
위에서 우리가 만든 것은 빌드할 수 있는 블록 생산 파이프라인입니다.
- 서로 독립적인 블록
- 이들 중 어느 것도 다른 블록 의 유효성에 영향을 미치지 않고 "체인"에서 독립적으로 제거될 수 있습니다.
- 엄격하게 정렬되지만 상태에 따라 달라지지 않는 블록
- 블록
b블록a의 BAF 또는 BMF를 기반으로 하는 경우에도 이러한 블록 중 하나를 체인에서 쉽게 제거할 수 있지만 블록ab에 의해 수정된 상태에 액세스할 수 있으므로 역순으로 또는 병렬로 실행할 수 없습니다.
- 블록
분명히 합의 더욱 복잡해지고 있습니다. 적어도 겉보기에는 그렇습니다. 증명은 단순히 블록을 더 자주 생성한다고 해서 마법처럼 빨라지는 것이 아닙니다. 하지만 재구축 비용이 훨씬 저렴하고, 블록을 더 자주 생성할 수 있습니다. 정확히 말씀드리자면, 아직 이것이 어떻게 작동해야 할지 명확하게 알지는 못하지만, 파이프라인을 통해 독립적인 하위 체인을 선택적으로 "병합"하여 안전한 가상의 체인 지평을 만들 수 있는 합의 메커니즘을 만들 수 있다고 생각합니다.
우리가 얻는 것
슬롯 시간 단축
이 디자인을 사용하면 슬롯 시간을 두 가지 이유로 단축할 수 있습니다.
주된 이유는 저렴한 재구성(reorg) 때문입니다. 블록을 표준 체인에서 선택적으로 건너뛸 수 있기 때문에, 사실상 매우 저렴한 재구성을 할 수 있습니다. 즉, 어떤 이유로든 생성되지 않는 블록에 대해 더 관대하게 적용할 수 있습니다.
두 번째 이유는 블록 구축하는 데 필요한 정보가 적고, 네트워크에서 적은 양의 정보를 훨씬 빠르게 배포할 수 있다는 것입니다.
거래 포함 시간 단축
슬롯 시간이 짧을수록 거래 처리 시간도 짧아집니다. 이는 모든 사람에게 중요한 것은 아니지만, 분명히 사용자 경험의 일부입니다.
스케일링 블록 생산
다음 빌더에 도달하는 데 아주 작은 필터만 필요하므로, 블록 빌드를 병렬화하는 것도 생각해 볼 수 있습니다. 미리 정해진 상태 공간 분할 없이 일종의 동적 샤딩을 구현하는 것이죠. 다시 한번 말씀드리지만, 아직 설계가 명확하지는 않지만, BAF 또는 BMF의 빠른 확산을 기반으로 분산 블록 빌드를 병렬화하고 파이프라인화하는 방향으로 나아갈 수 있을 것 같습니다.
다른 아이디어와의 관계
이 아이디어는 BAL과 온난화를 새로운 관점에서 바라보는 것으로 볼 수도 있습니다. 큰 변화를 빠르게 전달하려고 하는 대신, 큰 변화가 발생하지 않도록 노력할 수 있습니다.
충돌 발생 시 트랜잭션 수준의 "건너뛰기"를 허용하는 방향으로 나아가는 아이디어도 있습니다. 이러한 아이디어들을 결합하여 블록 간 종속성을 최소화할 수 있지만, 완전히 없애지는 못할 수도 있다고 생각합니다. 독립적인 변경 사항에는 "빠른 경로"를, 종속적인 변경 사항에는 "느린 경로"(현재보다 느리지는 않지만)를 고안해 볼 수도 있습니다. 이를 통해 특정 "최악의 경우" 트랜잭션에 제한받지 않고 전체 체인 용량을 늘릴 수 있는 설계를 구현할 수 있습니다.
