저자: 톨리, 솔라나 랩스 공동 창립자 출처: X, @aeyakovenko 번역: 굿오바, 골든파이낸스
솔라나에서 상태는 평평한 키-값 저장소로 구성됩니다. 프로그램은 이 스테이트에서 실행되어 합의를 위한 키 투표 프로그램을 포함한 값을 업데이트합니다. 비동기 실행의 주요 목적은 투표 절차가 다른 모든 절차와 독립적으로 실행될 수 있도록 하는 것입니다. 이 목표를 일관되게 달성하기 위해서는 몇 가지 핵심 원칙을 지켜야 합니다.
실행 도메인
실행 도메인은 실행 시 서로 독립적인 프로그램과 그 연산의 키 및 값의 집합입니다. 실행 도메인은 서로 다른 스레드와 코어에서 실행될 수 있으며 다양한 컴퓨터에서 서로 다른 시간에 완료될 수 있습니다. 중요한 것은 실행 도메인(예: 도메인 A)은 다른 도메인(예: 도메인 B)의 값을 읽거나 쓸 수 없다는 것입니다. 그러나 도메인은 두 도메인이 실행되는 동안 일관되게 유지되는 상태를 공유할 수 있습니다. 도메인 간에 상태를 동기화하고 키와 값의 이동을 용이하게 하려면 프로토콜이 필요합니다.
거래 수수료 납부자가 트랜잭션이 실행되는 도메인을 결정합니다.
주요 도메인: VED와 UED
솔라나에서는 투표 실행 도메인(VED)과 사용자 실행 도메인(UED)이라는 두 가지 도메인에 중점을 둡니다. 목표는 모든 사용자 절차가 실행되기 전에 검증자가 투표할 수 있도록 하는 것입니다.
VED의 구성 요소
시스템 절차: 송금에 사용
투표 절차 시스템 변수: 투표에 사용되는 투표 절차 시스템 변수
투표 절차: 핵심 투표 절차. 이 절차는 정적이고 일관적이며 UED와 VED 모두에 있어야 합니다.
투표 권한: 투표할 권한이 있는 계정
투표 비용 납부자: 투표와 관련된 비용을 지불하는 계정
비용 납부자 자금 /strong>: 솔을 VED로 옮기는 데 사용할 수 있는 갱신 가능한 계정
UED에 배치된 다른 모든 계정
VED 상태 계산
에포크 N-1과 N의 경계에서 런타임은 N+1 도메인의 VED 상태를 계산합니다. 이 계산은 에포크 N이 끝나기 전에 완료되어야 하며, 에포크 N-1이 시작되기 전에 UED 계산을 완료해야 합니다.
VED 상태 기준
폴링 계정: 5,000솔 이상을 약정하고 활성화한 계정.
비용 지불자 및 투표 권한, 비용 지불자 펀드: 위의 투표 계정과 연결된 계정.
새로 생성된 투표 계정은 처음에 비활성 상태로 설정됩니다. 사용자는 이러한 계정을 활성화해야 하며, 활성화되면 다음 VED 상태 계산에 포함됩니다. 사용자는 계정을 비활성화할 수 있으며, 비활성화된 계정은 N+1 기간 동안 VED 상태에서 제거됩니다.
VED에서 자금 이동
투표 계좌에 신고된 비용 납부자 자금 계좌는 VED에서 자금을 이동하는 데 사용할 수 있습니다. 투표 계정에서 수수료 납부자 펀딩 계정을 업데이트한 후에도 현재 수수료 납부자 펀드는 다음 에포크가 끝날 때까지 활성 상태로 유지됩니다. 재계산된 VED가 활성화되면 새 수수료 납부자 펀드는 VED 상태가 되어 수수료 납부자에게 추가 솔을 추가하는 데 사용할 수 있으며, 기존 수수료 납부자 펀드는 UED 상태가 되어 자금을 UED의 계정으로 다시 옮길 수 있습니다.
이를 비용 지불자와 병합할 수도 있지만, 투표당 사용되는 서명 수를 최소화하기 위해 비용 지불자는 일반적으로 투표 권한과 동일한 값으로 설정되므로 VED와 UED 간에 솔을 전송하려면 별도의 계정이 필요합니다.
유니버설 실행 도메인
위의 방법은 투표 절차에 매우 적합하게 되어 있습니다. 한 단계 더 나아가 이 접근 방식을 여러 실행 도메인으로 확장할 수도 있습니다. 계정은 OS 하이퍼바이저가 물리적 페이지에서 VMID를 추적하는 것과 마찬가지로 매핑된 실행 도메인을 추적합니다. 이 특정 프로젝트의 경우 유용한 몇 가지 매핑이 있습니다.
계정은 여러 도메인에서 동시에 읽고 쓸 수 없으므로 다른 매핑은 유효하지 않습니다.
시스템 스냅샷은 투표 프로그램과 시스템 프로그램을 RX-UED-VED로 구성합니다.시스템 프로그램은 시스템 계정과 투표 프로그램 계정을 VED로 이동하기 위한 인터페이스를 제공합니다. 인터페이스를 제공합니다. 실제 업데이트를 활성화하려면 여전히 전체 에포크가 필요합니다.
오너 프로그램이 대상 도메인에 있는 경우에만 도메인 간에 계정을 다시 매핑할 수 있습니다. 따라서 투표 프로그램과 시스템 프로그램 계정만 VED와 UED 간에 이동할 수 있습니다.
유니버설 접근 방식에서는 더 이상 명시적인 비용 지불자 펀드 계정이 필요하지 않습니다. 개발자는 VED와 UED 간에 시스템 계정을 리매핑하여 도메인 간에 자금을 이동할 수 있습니다.
VED 해시 계산하기
블록을 수신한 후 노드는 모든 트랜잭션을 실행합니다. 프로세스는 다음과 같습니다:
생성된 VED 상태 업데이트는 은행 해시인 VED 해시를 계산하는 데 사용됩니다. 이제 검증자는 기존 은행 해시 대신 VED 해시를 사용하여 투표할 수 있습니다. 포크에 대한 마지막 투표 이후 UED 해시 업데이트가 있었다면 해당 해시 및 슬롯이 투표에 포함됩니다.
UED 해시 계산
블록을 수신한 후 노드는 모든 트랜잭션을 처리합니다.
생성된 UED 상태 업데이트는 은행 해시인 UED 해시를 계산하는 데 사용됩니다.
완결성
완결성은 변경되지 않습니다.
거래 실행 상태 코드
비동기 실행의 부작용은 비결정성이 투표 포크 시점에 동기적으로 즉시 감지되지 않을 수 있다는 것입니다. 1/3 이상의 검증자가 서로 다른 UED 해시를 제출하면 모든 노드는 확인과 투표를 중단하고 운영자에게 경고해야 합니다.
상태 코드를 얻으려면 RPC API 요청에서 사용자가 동일한 UED 해시를 계산하는 관찰된 서약을 지정할 수 있어야 합니다. 실행 상태는 ExecutionStatus(서명, 서약 = X)로 표현할 수 있으며, 여기서 X는 0 또는 기본값일 수 있습니다. 여러 노드와 클라이언트가 있는 설정에서는 X의 값이 0이 허용되며, 이는 사용자에게 비결정성이 발생할 가능성이 매우 낮다는 확신을 줍니다.
비확정성은 확인된 트랜잭션에 대해 상태 코드가 사용자에게 반환되기 전에 감지해야 하는 유일한 결함이므로 일반적으로 X의 기본값은 낙관적 확인 임계값 또는 약 5%만큼 낮을 수 있습니다.
리더와 블록 생성
리더는 VED가 완료되는 즉시 블록 생성을 시작할 수 있어야 합니다. 이는 리더가 UED 수수료 납부자의 상태에 대한 부분적이고 불완전한 정보를 갖게 된다는 것을 의미합니다.
투표 절차의 기능 활성화
투표 절차 투표 절차가 기능적으로 활성화될 때 VED 투표가 에포크 경계를 넘을 수 있다는 가정 하에 투표 절차에 영향을 미치는 UED의 다른 거래 타이밍과 다르게 작동하도록 설계되어야 합니다.
보상
VED 상태의 투표 계정만 보상을 받을 수 있습니다.
벌칙
모든 투표 계정은 활성 상태인지 VED 상태인지에 관계없이 벌칙을 받을 수 있습니다.
글로벌 시계 업데이트
시계 시스템 변수는 투표를 통해 업데이트됩니다. 다른 방법을 사용해야 합니다. 대신, 각 블록 리더는 시계를 최대 1초까지 앞당길 수 있습니다. 시계가 실제 시간보다 빠르게 증가하려면 네트워크의 최소 40%가 악의적이어야 합니다. 시계는 기본적으로 400밀리초 앞으로 이동할 수도 있습니다. 50밀리초의 드리프트가 있다고 가정하면, 12.5%의 리더만이 시계 시간을 조정하여 동기화를 유지해야 합니다.