저자: Pavel Paramonov , Hazeflow 설립자
편집자: Felix, PANews
Sei는 최신 Giga 업그레이드를 설명하는 새로운 백서를 발표했습니다. 대부분 독자는 17페이지 분량의 매우 기술적인 내용을 읽는 데 어려움을 느낀다. 따라서 이 글에서는 이 업데이트가 무엇인지, 그리고 이를 통해 다양한 수준에서 블록체인 성능이 어떻게 향상될 것인지 설명하겠습니다.
1. 비동기 블록 생성에 관하여
Giga의 주요 아이디어와 기반은 다음과 같습니다.
"거래 목록이 순서대로 정리되어 있고 블록체인의 초기 상태가 일관되며 모든 정직한 노드가 이러한 거래를 동일한 순서로 처리한다면 동일한 최종 상태에 도달하게 됩니다."
이 경우 결과는 초기 상태와 거래 순서에만 따라 달라집니다. 즉, 합의는 블록 내의 거래 순서에만 동의하면 되고, 각 노드는 독립적으로 최종 상태를 계산할 수 있습니다.
- 이 모델에서는 합의가 실행과 분리되어 블록이 비동기적으로 실행될 수 있습니다.
- 블록이 완성되면 노드는 이를 처리하고 후속 블록에 해당 상태를 커밋합니다.
- 그런 다음 블록은 모든 노드가 올바른 최종 상태를 계산했는지 확인하기 위해 상태 합의를 통해 검증됩니다.
여기서 중요한 세부 사항은 실행과 합의 생성이 동시에 이루어진다는 것입니다. 노드가 블록에 대한 계산을 수행하면 다른 블록도 수신합니다.
따라서 블록은 실제로 전체 순서대로(병렬이 아닌) 실행되고, 블록 생성 프로세스 자체는 합의와 병렬로 진행됩니다. 그러나 주어진 블록에 대해 이러한 프로세스는 완전히 비동기적입니다.
당연히 합의에 도달하고 동시에 같은 블록을 실행하는 것은 불가능해 보입니다. 따라서 블록 n을 실행할 때 노드는 다음 단계를 위해 블록 n+1을 수신합니다.
합의가 왜곡되면(예: 네트워크의 노드 중 3분의 1이 악의적으로 행동하는 경우) 표준 BFT 프로토콜과 유사하게 체인이 중단됩니다.
블록 내에서 실행에 실패한 거래는 블록을 무효화하지 않고, 단지 실패한 상태로 남게 됩니다. 블록 생성과 실행이 별개이고 현재 블록의 최종 상태가 후속 블록에 커밋되기 때문입니다.
2. 다중 제안자 모델은 어떻게 구현되며, 아우토반이란 무엇입니까 ?
합의 프로토콜 자체는 "아우토반"(속도 제한이 없는 독일 고속도로와 유사)이라고 불립니다. 아우토반은 데이터 가용성과 거래 순서를 분리하는 흥미로운 모델을 가지고 있습니다.
고속도로의 모든 차선과 마찬가지로 여러 차선이 있으며 각 노드에는 차선이 하나씩 있습니다. 노드는 이러한 채널을 사용하여 거래 순서에 대한 제안을 합니다. 제안은 단순히 정렬된 거래의 모음일 뿐입니다.
오토반은 때때로 "팁컷" 작업을 수행하는데, 이는 여러 제안을 집계하여 거래 순서를 최종적으로 결정하는 작업입니다.
- 앞서 언급했듯이, 각 검증자는 일괄 거래를 제안하기 위한 자체 채널을 갖고 있습니다.
- 노드가 유효한 제안을 받으면 해당 제안이 수신되었음을 확인하는 투표를 보냅니다.
- 제안이 투표를 수집한 후, 네트워크에서 적어도 하나의 정직한 노드가 데이터를 수신했는지 확인하기 위해 가용성 증명(PoA)이 형성됩니다.
- 팁컷은 밀리초 단위로 발생하며 결국에는 아우토반에서 여러 개의 제안이 "컷"됩니다.
제안자는 블록 게시를 기다리고, 가능하다면 단일 블록을 게시하려는 동기가 있지만, 각 블록의 실행 시간 제한(가스 제한과 유사)이 이러한 역학 관계를 약간 변경합니다.
채널의 제안은 일반적으로 하나의 블록과 동일하므로 팁컷이 발생하면 여러 블록이 동시에 잘립니다.
그 후, 슬롯의 리더는 팁컷을 다른 노드로 보내서 정렬을 완료합니다. 사실, 노드가 단일 팁컷에 투표할 때 이미 다음 팁컷을 준비하고 있는 셈입니다.
배치를 놓친 노드는 PoA에 나열된 검증자로부터 비동기적으로 배치를 얻을 수 있습니다. 이것이 데이터 가용성이 필요한 이유입니다.
동기적 조건에서 리더가 옳다면, Autobahn은 두 라운드의 의사소통을 통해 제안 확인을 완료합니다. 리더가 실패하면 메커니즘은 진행을 유지하기 위해 새로운 리더를 선출합니다.
다음 팁-컷 제안은 실제로 현재 팁-컷의 커밋 단계에서 시작될 수 있으므로 생성과 병렬로 실행이 이루어지므로 지연 시간이 줄어듭니다.
사실, 전체 모델은 여러 노드가 동시에 블록 순서에 대한 제안을 할 수 있는 다중 제안자 모델입니다. 각 검증자는 자신의 블록을 제안하고 네트워크가 해당 블록을 소유하고 있다는 증명(PoA)을 받습니다. 이는 네트워크의 처리량과 전반적인 효율성을 높이는 데 도움이 됩니다.
3. 병렬 실행 및 그 적용성
앞서 언급했듯이, 블록 자체는 실제로 순차적으로 실행되지만, 블록 실행 프로세스는 합의와 병렬로 진행됩니다. 이것이 진정한 병렬 실행인지 궁금할 수도 있습니다.
답은 예이자 아니오입니다.
블록은 순차적으로 실행되지만, 블록 내의 거래는 실제로 병렬로 실행될 수 있습니다. 트랜잭션은 동일한 상태를 수정(쓰기)하지 않고 한 트랜잭션의 결과가 다른 트랜잭션에 영향을 미치지 않는 경우 병렬로 실행될 수 있습니다.
간단히 말해서, 실행 경로는 서로 의존적이어서는 안 됩니다. 기가에는 메모리 풀이 없으며 거래는 노드에 의해 즉시 포함됩니다.
- Giga는 대부분의 거래 간에 충돌이 없다고 가정하고 여러 프로세서 코어에서 동시에 처리합니다.
- 각 거래의 변경 사항은 개인 버퍼에 일시적으로 저장되며 블록체인에 즉시 적용되지 않습니다.
- 처리가 완료된 후, 시스템은 해당 거래가 이전 거래와 충돌하는지 확인합니다.
- 갈등이 있는 경우 거래가 다시 처리됩니다. 충돌이 없으면 변경 사항이 블록체인에 적용되고 완료됩니다.
또한, 충돌이 빈번하게 발생하는 상황이 있을 수 있는데, 이 경우 시스템은 거래를 하나씩 처리하여 거래가 진행될 수 있도록 합니다.
간단히 말해서, 병렬 실행은 트랜잭션을 여러 코어에 분산시켜 충돌하지 않는 트랜잭션이 동시에 실행될 수 있도록 합니다.
4. 저장 문제 및 최적화
거래량이 많기 때문에 데이터는 안전하고 쉽게 접근할 수 있어야 하므로 저장 방법은 기존 블록체인 저장과는 약간 달라야 합니다. 기가는 간단한 키-값 형식으로 데이터를 저장합니다. 이는 데이터가 변경될 때 필요한 업데이트나 확인 횟수를 줄이는 데 도움이 되는 비교적 평평한 구조입니다.
또한, Giga는 계층형 저장 방식을 사용합니다. 즉, 최근 데이터는 SSD(고속)에 보관하고, 덜 자주 사용되는 데이터는 더 느리지만 비용 효율적인 저장 시스템으로 이동합니다.
노드가 충돌하면 로그를 재생하여 올바른 상태를 복원하고 특수 데이터베이스인 RocksDB에 업데이트를 적용하여 데이터를 구성할 수 있습니다.
저장 시스템은 복잡한 계산을 수행하지 않고도 데이터의 정확성을 증명할 수 있는 암호화 누산기를 사용합니다. 축적기는 일괄적으로 업데이트되므로 검증자와 경량 노드가 블록체인의 현재 상태에 대한 합의에 빠르게 도달할 수 있습니다.
5. 다중 제안자 EVM L1 블록체인이란 무엇을 의미합니까?
L1 인프라에는 개선할 점이 많이 있으며, 다양한 L1은 MEV와 같은 경제적 문제부터 국가 관리와 같은 기술적 문제까지 다양한 기술적 과제에 직면합니다.
여러 제안자를 지원하는 최초의 L1 체인이 되는 것은 어려운 일이며, 특히 EVM L1의 경우 더욱 그렇습니다. EVM은 원래 여러 제안자 시스템을 지원하도록 설계되지 않았기 때문입니다.
하지만 Sei는 EVM과 많은 개발자가 사용하는 도구를 보존하기 위해 다른 접근 방식을 시도하고 있습니다.
병렬 거래 실행, 실행 중 합의, 그리고 병렬로 운영되는 여러 제안자 모두 성능을 개선하는 데 도움이 되며, 실행 처리량이 약 50배 증가합니다. 하지만 이러한 개선은 위에서 언급한 위험 중 일부에 직면할 수도 있습니다.
이는 세이의 두 번째 주요 업데이트입니다. 이전에는 Sei가 Cosmos 체인에서 EVM 체인으로 전환되었습니다. 이제 Sei는 속도에 최적화된 실행 클라이언트를 출시했습니다.
앞으로 무슨 일이 일어날지, 그리고 이러한 최적화 조치가 어떤 결과를 가져올지 지켜보는 것이 흥미로울 것입니다.
