솔라나 공동 창립자: 솔라나의 궁극적 아키텍처 분석
글: Anatoly Yakovenko, Solana 최고경영자(공동 설립자 겸 CEO)
번역: 1912212.eth, Foresight News
Solana의 목표는 물리 법칙의 한계 내에서 가능한 한 빨리 단일의 허가 없는 글로벌 상태 머신을 동기화하는 것입니다. 저는 이를 실현할 수 있는 아키텍처가 다음과 같다고 믿습니다.
-
전체 노드 수 10,000개 이상 (N > 10,000)
네트워크가 글로벌 상태 머신으로 작동하려면 다수의 전체 노드를 지원해야 합니다. Turbine은 현대 하드웨어와 네트워크 상에서 매우 큰 규모의 네트워크에 대한 고속 복제가 확장 가능함을 이미 입증했습니다.
-
블록 생성 리더 수 10,000명 이상 (N > 10,000)
-
병렬적으로 블록을 생성하는 리더들로, 무작위로 4~16 범위 내에서 선택됨
병렬 리더는 사용자 거래 정렬을 위한 여러 위치를 전 세계적으로 제공할 수 있게 해줍니다. 이로 인해 사용자와 네트워크 사이의 물리적 거리 감소가 가능하며, 트랜잭션이 체인에 추가되기 전에 전체 노드가 검증할 필요성이 사라집니다.
-
블록 시간: 120밀리초
짧은 블록 시간은 신속한 최종성 포인트를 만들어내며, 검열 저항성을 강화하고 사용자 경험을 개선하며 재정렬 창구를 줄이고 네트워크 전반적인 속도를 가속화합니다.
-
승인 위원회 내 일부 투표 합의 노드, 200~400개 정도이며 무작위로 리더를 선택하고 각 에포크마다 4~8시간 간격으로 교체
합의는 네트워크 분할로 인해 발생하는 포크 선택에 필수적입니다. 200개 이상의 노드 샘플은 통계적으로 네트워크 내 모든 주요 분할을 대표하며 실제 분포와 밀접하게 일치합니다. 따라서 모든 전체 노드가 투표할 필요 없이 200개만으로 충분합니다. 승인을 위원회로 제한하면 120밀리초 블록을 지원하기 위해 필요한 메모리 및 네트워크 대역폭을 줄일 수 있습니다. 블록 시간을 단축하면 자연스럽게 초당 전송되는 투표 수가 증가하여 합의에 할당된 자원에 부담을 줍니다.
120밀리초 블록에서 진정한 도전 과제는 모든 사용자 거래를 재실행하는 것입니다. 네트워크가 허가 없기 때문에 임의의 사용자 코드를 신뢰할 수 있는 시간 안에 실행하는 동질화된 실행 환경을 보장하는 것은 극도로 어렵습니다. 가능하지 않지는 않지만, 사용자 거래에 사용 가능한 컴퓨팅 자원을 제한하고 각 노드가 최악의 경우에도 초과 구비되도록 하는 방법 외에는 없습니다.
그러나 포크에 투표하거나 포크 위에 블록을 만드는 합의 노드의 경우, 전체 상태를 실행할 이유가 전혀 없습니다. 합의 노드와 리더의 승인이 동기화되도록 유지하려면 상태 계산은 각 기간마다 한 번만 수행되면 됩니다.
비동기 실행
동기부여
동기식 실행은 모든 투표 및 블록 생성 노드가 어떤 블록에서도 최악의 실행 시간을 결정하기 위해 지나치게 과도한 장비를 갖추어야 하게 만듭니다. 비동기 실행은 거의 트레이드오프 없이 달성 가능한 드문 사례 중 하나입니다. 합의 노드는 투표 전에 더 적은 작업만 수행하면 됩니다. 작업은 집계되고 배치 처리되어 실행 시 효율적이며 캐시 미스 없이 진행될 수 있습니다. 심지어 합의 노드나 리더와 완전히 다른 머신에서 실행될 수도 있습니다. 동기식 실행을 원하는 사용자는 실시간으로 각 상태 전환을 실행하기에 충분한 하드웨어 자원을 할당할 수 있으며, 전체 네트워크를 기다릴 필요가 없습니다.
애플리케이션과 코어 개발자의 다양성을 고려할 때 매년 한 차례 주요 프로토콜 변경을 계획하는 것이 가치 있습니다. 반드시 하나를 선택해야 한다면 저는 비동기 실행을 선택하겠습니다.
개요
현재 검증 노드는 각 블록에서 모든 거래를 신속하게 반복하며, 블록의 전체 상태를 계산한 후에야 투표합니다. 본 제안의 목적은 포크에 대한 투표 결정과 블록의 전체 상태 전환 계산을 분리하는 것입니다.
승인에 참여하는 검증 노드는 포크를 선택하기만 하면 되며, 아무런 상태도 실행할 필요가 없습니다. 오직 각 에포크마다 다음 승인을 계산하기 위해 상태가 필요할 뿐입니다.
투표 절차는 독립적으로 실행 가능하도록 조정됩니다. 노드는 투표 전에만 투표 절차를 실행합니다. 검증 거래는 공간을 많이 차지하지 않으므로 메모리 요구사항은 상대적으로 작아야 합니다. 투표는 매우 예측 가능한 실행 시간을 가지므로 투표 절차의 실행은 거의 지터(jitter) 없이 이루어져야 합니다.
모든 비투표 거래는 비동기적으로 계산될 수 있습니다. 이를 통해 모든 비투표 거래를 일괄 재실행하고, 모든 프로그램에 대해 JIT를 사전 추출 및 선제 적용하여 거의 모든 캐시 미스를 제거할 수 있습니다. 장기적인 목표는 실시간으로 낮은 지연 시간의 전체 상태 계산이 필요한 머신만 해당 작업을 위해 특별히 구성하는 것입니다. 아마도 사용자가 추가 하드웨어 비용을 지불하게 될 것입니다.
포크 선택과 상태 실행을 분리하면 진전을 가속화하기가 훨씬 쉬워집니다.
-
비동기 실행
-
각 에포크마다 고정된 수의 투표 위원회 순환
-
200밀리초 블록 시간
사용자 거래 재실행이 포크 선택을 차단하지 않기 때문에 블록 시간을 줄일 때 변동성은 더 이상 문제가 되지 않습니다. 고려해야 할 유일한 요소는 200밀리초 시 검증 노드의 투표 속도가 두 배가 된다는 점입니다. 승인 계산 방식에 비교적 직접적인 변경을 통해 승인 크기를 200 또는 400, 혹은 적절하다고 판단되는 다른 숫자로 고정할 수 있습니다.
실행과 합의를 완전히 분리하는 것도 자연스러운 발전입니다. 재시작은 고정된 크기의 승인 내 투표 절차 계정에 대한 합의 노드만 확인하면 되므로 훨씬 더 빠르게 이루어질 수 있습니다.
실제로 저는 확인 시간이 향상될 것이라고 믿습니다. 왜냐하면 승인의 대부분은 가능한 한 빨리 투표를 진행할 것이며, 동시에 사용자에게 전체 상태 실행 결과를 제공하는 노드들이 거래를 병렬로 실행할 수 있기 때문입니다. 따라서 우리가 오늘 목격하는 모든 재실행 지터는 투표 네트워크 전파와 동시에 발생해야 합니다.
투표
-
투표 계정은 2개의 에포크 동안의 투표 비용을 충당할 만큼 충분한 양의 SOL을 보유해야 합니다.
-
투표 거래는 단순해야 합니다. 복잡한 투표는 반드시 실패합니다. 블록 생성자는 복잡한 투표를 포기해야 합니다.
-
SOL을 투표 계정에서 인출하는 것은 1개의 에포크 동안의 투표 비용보다 잔액이 낮아지지 않는 한 허용됩니다.
-
모든 lamport를 0으로 만들기 위해서는 Vote CLOSE 명령어가 완전한 에포크를 거쳐야 합니다. 에포크 1에서 투표 계정이 CLOSE로 표시되지만, CLOSE는 에포크 2에서만 수행될 수 있습니다. CLOSE는 모든 SOL을 인출하고 투표 계정을 삭제합니다. 한번 CLOSE로 표시된 계정은 완전히 삭제만 가능하며 다시 열 수 없습니다.
-
투표에는 일반 BankHash 대신 VoteBankHash가 포함됩니다.
리더 조절 및 승인
다음 조건을 모두 충족하는 검증 노드만:
-
스테이킹량 > X
-
그리고 SOL > 2개 에포크 분의 투표 비용
-
그리고 CLOSE로 표시되지 않은 경우
리더 스케줄에 포함되며 승인에 산입될 수 있습니다. 버전 2에서는 LeaderSchedule과 Quorum을 분리할 수 있으며, 각각의 요구사항이 동일할 필요는 없습니다.
VoteBankHash 계산
모든 거래를 포함하여 Bankhash를 계산하는 것과 달리, 검증 노드는 LeaderScheduler 내 검증 노드와 관련된 단순 투표 거래에 대해서만 VoteBankHash를 계산합니다. 그 외의 모든 거래는 무시됩니다. 모든 투표를 재실행한 후 VoteBankHash는 현재의 BankHash와 동일한 형식으로 계산됩니다.
VoteBankHash는 전체 BankHash가 아니라 이전의 VoteBankHash를 누적해야 합니다.
BankHash 계산
모든 낙관적 확정 블록(모든 블록으로 구성 가능)에 대해 검증 노드는 UserBankHash 계산을 시작하며, 여기에는 모든 상태 전환이 포함되지만 VoteBankHash 계산에 이미 포함된 거래는 제외됩니다.
그 후 BankHash는 (VoteBankHash, UserBankHash)의 누적값에서 파생됩니다. 상위 99.5%의 검증 노드는 100슬롯마다 한 번씩 BankHash를 투표의 일부로 제출합니다. 100슬롯마다 제출되지만 각 슬롯마다 계속 계산됩니다. 소수의 노드가 gossips 중에 BankHash를 제출하여 비결정성 결여에 대한 약한 신호로 활용하는 것도 의미 있을 수 있습니다.
67% 미만의 검증 노드만이 완전한 BankHash 계산을 제출할 경우, 리더는 사용 가능한 사용자 거래 및 쓰기 가능한 계정의 블록 공간을 50% 줄여야 합니다. 이 조치는 재실행 시간을 과도하게 늘릴 수 있는 남용으로부터 체인을 보호하기 위한 것입니다.
BankHash는 이전의 BankHash를 누적해야 합니다.
뱅크 없는 리더
블록 생성 중 리더는 블록 생성에 필요한 상태를 확보하지 못할 가능성이 높으며, 블록 생성 중 모든 거래를 실행하는 것도 바람직하지 않습니다.
-
리더는 유료 계정 잔액의 캐시를 유지 관리합니다.
-
유료 계정이 시스템 송금의 출처로 사용되거나 시스템 프로그램과 함께 다른 프로그램에 전달되는 쓰기 가능한 계정으로 전달되는 경우, 해당 유료 계정 잔액은 0으로 설정됩니다.
-
선언된 계산 단위(CUs)에 따라 로컬 수수료 우선순위로 블록을 패킹하여 블록이 꽉 찰 때까지 채웁니다.
-
유료 계정 잔액 캐시에서 수수료를 공제합니다.
-
유료 계정 잔액 캐시는 BankHash 계산을 통해 보충됩니다.
스팸 거래로 인해 네트워크가 실패했을 때 발생하는 비용은 저장소에 저장된 바이트와 블록 내 거래 전파에 필요한 대역폭 정도로 상대적으로 작습니다.
검증 노드는 이미 자신의 수익을 극대화하고자 하므로, 정확한 유료 계정 캐시를 유지할 강력한 인센티브를 가지고 있습니다. 또한 처벌 메커니즘이 없더라도 장기적으로 네트워크 내 누구라도 쉽게 캐시를 제공할 수 있습니다. 서버 장애 시 뱅크 없는 리더 운영자는 쉽게 전환하거나 여러 소스에서 샘플링할 수 있어야 합니다.
이는 검증 노드가 수익 극대화라는 동기에 따라 정확한 유료 계정 캐시를 유지하려 노력한다는 것을 의미합니다. 처벌 메커니즘이 없다 하더라도 이러한 캐시는 장기적으로 네트워크 내 어떤 노드에 의해 제공될 수 있습니다. 게다가 서버에 장애가 발생하면 뱅크 없는 리더 운영자는 쉽게 전환하거나 여러 소스에서 샘플링할 수 있어야 합니다.
트레이드오프
주요 트레이드오프는 사용자 상태를 제공하는 전체 노드가 승인의 나머지 부분과 완전히 일치한다는 것을 확인하는 서명된 확인을 받지 못한다는 점입니다. 상태의 유일한 권위적 해석은 분류장에 있는 각 거래를 순서대로 재실행하더라도 변하지 않아야 합니다. 어떤 성능 최적화도 결과를 바꾸어서는 안 됩니다. 따라서 일단 포크가 최종 확정되면, 런타임 구현에 오류가 없는 한 올바른 상태만 계산될 수 있습니다.
신뢰성 있게 상태를 제공하려는 노드는 여러 대의 머신과 클라이언트를 운영해야 하며, 상태 실행에 차이가 발생하면 운영을 중단해야 합니다. 이는 본질적으로 운영자가 현재 해야 할 일이며, 네트워크의 나머지 부분에만 의존하는 것은 정직한 다수 가정을 도입한다는 것을 의미합니다.
사용자는 또한 BankHash를 주장하거나 중단을 유도하는 거래에 서명할 수 있습니다. 정확히 계산된 BankHash가 RPC 제공자가 사용자에게 제공하는 BankHash와 완전히 일치할 때에만 네트워크의 나머지 부분이 해당 거래를 실행합니다.
장기적 무상태 합의 노드 로드맵
고정된 크기의 승인을 가진 네트워크는 시작에 매우 작은 양의 상태만 필요로 합니다. 승인 자체와 그 지분 가중치, 그리고 모든 투표 계정 잔액만 있으면 됩니다. 이는 매우 작은 메모리 용량이며, 빠르게 분배되고 재시작 시 빠르게 초기화될 수 있는 미세한 스냅샷 파일입니다.
승인과 전체 노드가 불일치할 경우, 승인과 상태를 동시에 추적하는 전체 노드는 작동을 중단합니다. 즉, 승인과 상태가 갈라질 경우 거래소, 페시通道, RPC, 브리지 등이 모두 멈추게 됩니다. 이는 결함 있는 무상태 합의 노드의 극소수 비율만으로도 발생할 수 있습니다.
뱅크 없는 리더는 유료 계정의 초기 잔액 캐시를 제공하기 위해 여러 전체 노드의 샘플에 의존할 수 있습니다. 결함이 있더라도 결과는 합의 실패가 아닌 블록 내 스팸이 됩니다. 운영자는 리더의 건강 상태와 블록에 주입된 스팸의 비율을 모니터링하고 고장을 신속하게 대응할 수 있어야 합니다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
@anatolyakovenko![암호 조간: 일본 금융 거물 SBI 와 Solana 재단, 전략적 파트너십 체결, 트럼프 미국 상원에 [Clarity Act] 신속 통과 촉구](https://upload.techflowpost.com/upload/materials/articles/20260701/20260701104056138403.jpg?x-oss-process=image/resize,p_50/quality,q_80)
