솔라나 백서 번역

원문: https://solana.com/solana-whitepaper.pdf

 

솔라나 : 고성능 블럭체인을 위한 새로운 아키텍처

 

초록

 

본 논문은 이벤트 사이의 주문과 시간의 경과를 검증하는 역사 증명(PoH)에 기반한 새로운 블럭체인 아키텍처를 제안한다. PoH 는 신뢰할 수 없는 시간의 경과를 추가 전용 데이터 구조의 원장으로 인코딩하는 데 사용된다. 작업 증명(PoW)이나 지분 증명(PoS)와 같은 합의 알고리즘과 함께 사용되면 PoH 는 비잔틴 장애 허용 복제 상태 머신에서 메시징 부하를 감소시켜 수 초 내에 처리할 수 있다. 본 논문은 PoH 원장의 시간 유지 속성을 활용하는 두 가지 알고리즘, 즉 모든 크기의 파티션으로부터 복구할 수 있는 PoS 알고리즘과 효율적인 스트리밍 복제 증명(PoRep)을 제안한다. PoRep 와 PoH 의 조합은 시간 순서와 저장에 대한 원장의 위변조를 방지한다. 이 논문은 1Gbps 네트워크와 최신 하드웨어 하에서 초당 710K 트랜잭션까지 처리 가능함을 보인다.

 

1. 소개

 

블럭체인은 장애 허용 복제 상태 머신의 구현체이다. 현재 공개적으로 사용 가능한 블럭 체인은 시간에 의존하지 않거나, 참여자들이 시간 준수 능력에 대해 약한 가정을 한다. 네트워크 내의 각 노드는 일반적으로 네트워크 상 다른 참여자의 시간에 대한 지식 없지 자신의 로컬 시간에 의존한다. 신뢰할만한 시간 원천이 없다면, 메시지의 승인이나 거부에 사용되는 메시지 타임스탬프에 대해 네트워크의 다른 참여자가 동일한 선택을 한다는 보장이 없다. 여기서 제안하는 PoH 는 검증 가능한 시간의 경과, 즉 이벤트 사이의 시간과 메시지 순서를 기록한 원장을 생성하기 위해 설계되었다. 네트워크 내의 모든 노드가 신뢰 없이 원장에 기록된 시간 경과도 의존할 수 있을 것으로 기대된다.

 

2. 개요

 

이하의 구성은 다음과 같다: 3장에서 전체 시스템 설계를 기술한다. 4장은 역사 증명을 상세하게 설명한다. 5장은 제안된 지분 증명 합의 알고리즘을 설명한다. 6장은 제안된 고속 복제 증명을 설명한다. 7장은 시스템 아키텍처와 성능 한계를 분석한다. 7.5 장은 고성능 GPU에 친화적인 스마트 컨트랙트 엔진을 설명한다.

 

3. 네트워크 설계

 

그림 1에서 볼 수 있듯이, 시스템 노드는 언제나 네트워크 전역 읽기 일관성과 검증 가능한 시간 경과를 제공하는 역사 증명 시퀀스를 생성하는 리더로 선출될 수 있다. 리더는 시스템의 다른 노드에서 효율적으로 처리할 수 있도록 사용자 메시지를 시퀀싱하고 순서를 지정하여 처리량을 극대화한다. 램에 저장된 현재 상태에 대해 트랜잭션을 수행하고, 트랜잭션과 최종 상태의 서명을 Verifiers 라 불리는 복제 노드에 발행한다. Verifiers 는 상태 복제본에 대해 동일한 트랜잭션을 실행하고, 검증을 위해 계산된 상태의 서명을 발행한다. 발행된 검증은 합의 알고리즘의 투표 역할을 한다.

 

그림 1 : 네트워크 상 트랜잭션 흐름

 

파티션이 없는 상태에서 네트워크에는 언제나 하나의 리더가 있다. 각 Verifier 노드는 리더와 동일한 하드웨어 성능을 갖추고 리더로 선출될 수 있으며, 이는 PoS 기반 선거를 통해 수행된다. 제안된 PoS 알고리즘에 의한 선거는 5.6 절에서 다룬다.

CAP 이론 관점에서 보면, 부분 결함(Partition)이 발생하면 대부분 일관성(Consistency) 이 가용성(Availability)에 우선한다. 대규모 파티션의 경우, 본 논문은 모든 규모의 파티션으로부터 네트워크의 제어를 복구하는 매커니즘을 제공한다. 5.12 절에서 이에 대해 상세히 다룬다.

 

4. 역사 증명

 

역사 증명은 두 이벤트 사이의 시간 경과를 암호화된 검증 방법을 제공하는 일련의 연산이다. 이는 입력으로부터 출력을 예측할 수 없도록 작성된 암호화된 보안 함수를 사용하며 출력을 생성하기 위해서 완벽하게 실행되어야 한다. 이 함수는 단일 코어에서 순차적으로 실행되는데, 이전의 출력이 현재의 입력이 되고, 주기적으로 현재의 출력과 호출 횟수를 기록한다. 출력은 별도의 코어에서 각 시퀀스 세그먼트를 병렬로 검사함으로써 외부 컴퓨터에 의해 재계산 및 검증이 가능하다. 

이러한 시퀀스에 데이터 또는 일부 데이터의 해시를 함수의 상태에 추가함으로써 데이터는 타임스탬프가 될 수 있다. 상태, 인덱스, 데이터를 시퀀스에 추가될 때 기록함으로써, 데이터가 시퀀스에서 다음 해시가 생성되기 전에 생성되었음을 보장하는 타임스탬프를 제공한다. 또한 이러한 설계는 다수의 생성자가 상태를 다른 시퀀스에 혼합함으로써 서로간에 동기화할 수 있기 때문에 수평 확장도 제공한다. 수평 확장은 4.4 절에서 상세하게 다룬다.

 

4.1 설명

 

시스템은 다음과 같이 동작하도록 설계되었다. sha256, ripemd 과 같이 함수를 실행하지 않으면 출력을 예측할 수 없는 암호화 해시 함수를 이용해서, 임의의 시작 값에서 함수를 실행하고 결과 값을 취해서 동일한 함수의 입력으로 다시 전달한다. 함수를 호출한 횟수와 각 호출의 출력을 기록한다. 임의의 시작 값은 그날의 뉴욕 타임즈 헤드라인과 같이 어떤 문자열도 가능하다. 

 

예를 들어:

이 때 hashN 은 실제 해시 결과값을 나타낸다.

 

시간 간격에서는 해시와 인덱스의 일부만 발행하면 된다. 

 

예를 들어:

 

해시 함수가 충돌 저항성이 확보만 된다면, 이러한 해시 집합은 단일 컴퓨터 스레드에서 순차적으로 계산할 수밖에 없다. 300번째 해시 값을 알아내는 방법은 시작 위치에서 실제로 300번 계산하는 방법 밖에는 없다는 사실은 이에 비롯한다. 따라서 이러한 데이터 구조에서 0번째 인덱스와 300번째 인덱스 사이의 시간이 지났음을 추론할 수 있다. 

그림 2의 예에서, 해시 62f51643c1 은 510144806912 번째 생성됐고 해시 c43d862d88 은 510146904064 번째 생성됐다. 앞서 논의된 PoH 알고리즘의 특성에 따라, 510144806912 번과 510146904064 번 사이에 실제 시간이 흘렀음을 신뢰할 수 있다. 

 

 

그림 2. 역사 증명 시퀀스

 

4.2 이벤트 타임스탬프

 

이러한 해시 시퀀스는 데이터 일부가 특정 해시 인덱스가 생성되기 전에 생성되었음을 기록하기 위해 사용될 수도 있다. 컴바인 함수를 사용해서 데이터 일부를 현재 인덱스의 현재 해시와 결합할 수 있다. 데이터는 간단하게 임의의 이벤트 데이터에 대하여 암호화된 고유 해시가 된다. 컴바인 함수는 단순히 데이터를 추가하거나 충돌 저항성이 있는 연산이 될 수 있다. 다음번에 생성된 해시는 데이터의 타임스탬프를 나타내는데, 이는 특정 데이터가 삽입된 후에만 생성될 수 있기 때문이다.

 

예:

 

사진 촬영 혹은 임의의 디지털 데이터 생성과 같은 외부 이벤트가 발생했다고 하자:

 

 

Hash336 은 hash335 의 이진 데이터에 사진의 sha256 을 추가해서 계산된다. 사진의 인덱스와 sha256 은 시퀀스 출력의 일부로 기록된다. 따라서 이러한 시퀀스를 검증하는 사용자는 시퀀스에 이러한 변경을 다시 생성할 수 있다. 검증은 병렬로 수행할 수 있으며 4.3 절에서 이에 대해 다룬다.

초기 프로세스는 여전히 순차적이므로, 시퀀스에 입력된 것들은 미래의 해시값이 계산되기 이전에 발생했음을 알 수 있다.

표 1. 2개의 이벤트에 대한 PoH 시퀀스

표 1에 나열된 시퀀스에서, photograph2 는 hash600 이전에 생성됐고, photograph1 은 hash336 이전에 생성됐다. 데이터를 해시 시퀀스에 삽입하면 시퀀스의 모든 후속 값이 변경된다. 사용된 해시 함수가 충돌 저항성이 있을 때 데이터가 추가되면 어떤 데이터가 시퀀스에 통합될지에 대한 사전 지식을 기반으로 미래의 시퀀스를 계산하는 것은 불가능해야 한다.

시퀀스에 혼합되는 데이터는 원시 데이터 자체일 수도 있고, 메타데이터가 포함된 데이터의 해시일 수도 있다.

 

그림 3. 역사 증명에 데이터 추가

 

그림 3의 예에서 cfd40df8… 이 역사 증명 시퀀스에 삽입됐다. 삽입된 카운트는 ​​510145855488 이고, 이 때의 상태는 3d039eef3 이다. 미래에 생성되는 모든 시퀀스는 이러한 변화에 따라 변경되며, 이는 그림에서 색상 변화로 표시했다.

이 시퀀스를 관찰하는 모든 노드는 모든 이벤트가 삽입된 순서를 결정하고 삽입 간의 실제 시간을 추정할 수 있다.

 

4.3 검증

 

시퀀스는 멀티코어 컴퓨터에 의해 이를 생성하는 데 걸린 시간보다 훨씬 더 짧은 시간에 정확하게 검증될 수 있다.

 

예:

 

4000개의 코어를 가진 현대의 GPU 처럼 일정 수의 코어가 주어지면, 검증자는 해시와 인덱스의 시퀀스를 4000개의 슬라이스로 분할한 뒤, 시작 해시부터 슬라이스의 마지막 해시까지 각각의 슬라이스가 정확한지 병렬로 검증할 수 있다. 만약 시퀀스를 생성하기 위한 예상 시간이 다음과 같다면:

전체 해시 개수1 코어에 대한 초당 해시 수

 

시퀀스가 정확한지 검증하는 예상시간은 다음과 같다:

전체 해시 개수(1 코어에 대한 초당 해시 수 * 검증에 사용할 수 있는 코어 수)

그림 4: 다중 코어를 이용한 검증

 

그림 4의 예에서 각 코어는 시퀀스의 각 슬라이스를 병렬로 확인할 수 있다. 모든 입력 문자열이 카운트와 추가된 상태와 함께 출력에 기록되기 때문에 검증자는 각 슬라이스를 병렬로 복제할 수 있다. 붉은 색으로 표시된 해시는 시퀀스가 데이터 추가에 의해 변경되었음을 나타낸다.

 

4.4 수평 확장

 

각 생성자에서 다른 생성자로의 시퀀스 상태를 혼합함으로써 다수의 역사 증명 생성자를 동기화할 수 있고, 그 결과 역사 증명 생성자의 수평 스케일링을 달성할 수 있다. 이 스케일링은 샤딩 없이 수행된다. 두 생성자의 출력은 시스템에서 이벤트의 전체 순서를 재구성하는 데 필요하다.

 

주어진 생성자 A와 B에서, A는 B(hash1b)로부터 데이터 패킷을 수신하고, 해당 패킷은 생성자 B 의 최종 상태를 포함하며, 최종 상태 생성자 B는 생성자 A 를 관찰한다. 생성자 A의 다음 해시는 생성자 B에 의존하므로 hash1b 는 hash3a 이전에 발생했음을 도출할 수 있다. 이 속성은 이행적(transitive)일 수 있으므로 만약 세 개의 생성자가 단일한 공통 발생기 A ↔ B ↔ C를 통해 동기화되면, A와 C가 직접 동기화되지 않았더라도 종속성을 추적할 수 있다.

주기적으로 생성자를 동기화함으로써 각 생성자는 외부 트래픽의 일부를 처리할 수 있으므로, 전체 시스템은 생성자 간의 네트워크 지연에 따른 실시간 정확성을 희생하여 많은 양의 이벤트를 추적하고 처리할 수 있다. 해시 값 자체와 같이 동기화 윈도 내의 모든 이벤트를 정렬하기 위한 결정론적 함수를 선택함으로써 전체 순서를 정할 수 있다.

 

그림 5. 두 개의 생성자 동기화

 

그림 5에서, 두 생성자는 서로간의 출력 상태를 삽입하고 연산을 기록한다. 색상 변화는 피어 데이터에 의해 시퀀스가 수정되었음을 나타낸다. 각 스트림에 혼합되어 생성된 해시는 굵게 강조했다.

동기화는 이행적이다. A와 C 사이에는 B 를 통해 증명 가능한 이벤트의 순서가 존재한다. 

이러한 방식의 확장은 가용성을 희생한다. 가용성이 0.999인 1 gbps 의 10개 연결 시 가용성은 0.99910 = 0.99 이다.

 

4.5 일관성

 

사용자는 자신이 타당하다고 간주하는 시퀀스의 마지막으로 관찰된 출력을 입력에 삽입함으로써 생성된 시퀀스의 일관성을 강화하고 공격에 대항할 수 있을 것으로 예상된다.

 

 

악의적인 PoH 생성자는 한 번에 모든 이벤트에 액세스할 수 있거나 더 빠른 숨겨진 시퀀스를 생성할 수 있는 경우 이벤트를 역순으로 사용하여 두 번째 숨겨진 시퀀스를 생성할 수 있습니다.

 

이 공격을 방지하기 위해 각 클라이언트에서 생성한 이벤트는 클라이언트가 유효한 시퀀스로 간주하는 것으로부터 관찰한 최신 해시를 내부에 포함해야 한다. 따라서 클라이언트가 "이벤트1" 데이터를 만들 때 마지막으로 관찰한 해시를 추가해야 한다.

 

 

시퀀스가 발행될 때 이벤트3는 해시30a를 참조하게 되며, 해당 해시가 이벤트 이전 시퀀스에 없으면 해당 시퀀스의 소비자는 이것이 유효하지 않은 시퀀스임을 알 수 있다. 따라서 부분 순서 변경 공격은 클라이언트가 이벤트를 관찰하는 동안 생성된 해시 수와 이벤트가 입력된 시간으로 제한된다. 그러면 클라이언트는 마지막으로 관찰된 해시와 삽입된 해시 사이의 짧은 기간 동안 순서가 정확하다고 가정하지 않는 소프트웨어를 작성할 수 있다.

악의적인 PoH 생성자가 클라이언트 이벤트 해시를 다시 쓰는 것을 방지하기 위해 클라이언트는 데이터 대신 이벤트 데이터와 마지막으로 관찰된 해시의 서명을 제출할 수 있다.

 

 

이 데이터를 검증하려면 서명 검증과 이 데이터 이전의 해시 시퀀스에서 해시를 조회해야 한다.

 

검증:

(Signature, PublicKey, hash30a, event3 data) = Event3

Verify(Signature, PublicKey, Event3)

Lookup(hash30a, PoHSequence)

 

그림 6. 역 참조를 포함한 입력

 

그림 6에서 사용자 제공 입력은 삽입되기 전에 생성된 시퀀스에 존재하는 해시 0xdeadbee… 에 의존한다. 왼쪽 위 파란색 화살표는 클라이언트가 이전에 생성된 해시를 참조하고 있음을 나타낸다. 클라이언트 메시지는 해시 0xdeadbeef...를 포함하는 시퀀스에서만 유효하다. 시퀀스의 붉은 색은 클라이언트 데이터에 의해 시퀀스가 수정되었음을 나타낸다.

 

4.6 처리 비용

 

초당 4000개의 해시는 160킬로바이트의 데이터를 추가로 생성하며 4000개의 코어와 0.25-0.75밀리초의 시간을 가진 GPU에 액세스해야 확인할 수 있다.

 

4.7 공격

4.7.1 리버설

 

역순을 생성하려면 공격자가 두 번째 이벤트 이후에 악의적인 시퀀스를 시작해야 한다. 이에 따른 지연 시간 동안 정상적인 P2P 노드는 원래의 순서로 통신할 수 있다.

 

4.7.2 속도

 

생성자가 많으면 배포 시 공격에 대한 내성을 높일 수 있다. 하나의 생성자는 높은 대역폭으로 시퀀스에 혼합할 많은 이벤트를 수신할 수 있고, 다른 생성자는 주기적으로 고대역폭 생성자와 혼합되는 고속의 저대역폭일 수 있다.

고속 시퀀스는 공격자가 이를 되돌려야만 하는 2차 데이터 시퀀스를 생성할 수 있다.

 

4.7.3 장거리 공격

 

장거리 공격은 만료 폐기된 클라이언트 비밀키를 획득하고 위조된 원장을 생성하는 것이다. 역사 증명은 장거리 공격에 대해 부분적인 보안을 제공한다. 오래된 비밀키에 대한 접근 권한을 얻은 악의적인 사용자는 위조하려는 원본과 동일한 시간이 걸리는 기록 레코드를 재생성해야 한다. 이렇게 하려면 네트워크에서 현재 사용 중인 것보다 빠른 프로세서에 액세스해야 하며 그렇지 않으면 공격자가 전체 기록 시간을 따라잡을 수 없다.

또한 단일한 시간 원천으로 더 간단한 복제 증명을 구성할 수 있다(섹션 6 참조). 네트워크의 모든 참가자가 이벤트에 대한 단일 기록 레코드에 의존할 수 있도록 네트워크가 설계되었기 때문이다.

PoRep과 PoH는 함께 위조된 원장에 대한 공간과 시간의 방어를 제공한다.

 

5 지분 증명 합의

 

5.1 설명

 

여기서의 특정한 지분 증명 사례는 역사 증명 생성자가 생성한 현재 시퀀스를 신속하게 확인하고, 다음 기록 증명 생성자를 투표 및 선택하며, 잘못된 행동을 하는 검증자를 처벌하기 위해 설계되다. 이 알고리즘은 특정 시간 제한 내에 모든 참여 노드에 최종적으로 도착하는 메시지에 따라 달라진다.

 

5.2 용어

 

채권(bonds) 채권은 작업 증명에서의 자본 비용과 동일하다. 채굴자는 하드웨어와 전기를 구매하여 작업 증명 블럭체인의 단일 브랜치에 커밋한다. 채권은 검증자가 트랜잭션을 검증하는 동안 담보로 제출하는 코인이다.

 

삭감(slashing) 지분 증명 시스템의 nothing at stake 문제에 대해 제안된 솔루션. 다른 브랜치에 대한 투표 증명이 발행되면 해당 브랜치는 검증자 채권을 파괴할 수 있다. 이것은 검증자가 다수의 브랜치를 인증하지 못하도록 고안된 경제적 인센티브이다.

 

압도적 다수(super majority) 압도적 다수는 채권으로 가중치가 부여된 검증자의 3분의 2 이다. 압도적 다수 투표는 네트워크가 합의에 도달했음을 의미하며, 이 브랜치를 무효화하기 위해서는 적어도 네트워크의 3분의 1이 악의적으로 투표해야만 했을 것이다. 이렇게 되면 공격에 따른 경제적 비용은 코인 시가총액의 3분의 1에 해당한다.

 

5.3 예치(Bonding)

 

예치 거래는 많은 양의 코인을 사용자 식원 하의 예치 계정으로 옮긴다. 예치 계정의 코인은 사용할 수 없으며 사용자가 인출할 때까지 계좌에 남아 있어야 한다. 사용자는 시간이 만료된 코인만 인출할 수 있다. 채권은 현재의 지분 소유자의 압도적 다수가 시퀀스를 확정한 후에 유효하다.

 

5.4 투표

 

기록 증명 생성자는 사전에 정의된 기간 동안 상태의 서명을 발행할 수 있을 것으로 예상된다. 예치된 각 신원은 각자가 서명한 상태의 서명을 게시함으로써 그 서명을 입증해야 한다. 투표는 반대가 없는 단순한 찬성 투표이다.

만약 예치된 신원의 압도적 다수가 제한 시간 내에 투표했다면, 이 브랜치는 유효한 것으로 인정된다.

 

5.5 인출(Unbonding)

 

N표가 누락되면 동전은 오래되어 더 이상 투표할 수 없게 된다. 사용자는 그것들을 제거하기 위해 인출 거래를 발행할 수 있다.

N은 유효 투표 대비 무효 투표 비율에 기반한 동적인 값이다. N은 무효 투표의 수가 늘어날수록 증가한다. 네트워크 파티션이 큰 경우 큰 브랜치가 작은 브랜치보다 더 빨리 복구할 수 있다.

 

5.6 선거

 

PoH 생성자 오류가 감지되면 새로운 PoH 생성자를 투표한다. 가장 큰 투표권을 가졌거나, 동수일 경우 공개키 주소값이 가장 큰 검증자가 새로운 PoH 로 선출된다. 새로운 시퀀스에는 압도적 다수의 확인이 필요하다. 압도적 다수의 확인을 받기 전에 새로운 리더가 실패하면, 다음으로 높은 검증자가 선택되며, 새로운 확인 집합이 필요하다.

투표를 전환하려면 검증자는 더 높은 PoH 카운터에서 투표해야 하며, 새로운 투표는 전환하려는 투표를 포함해야 한다. 그렇지 않으면 두 번째 투표는 삭감될 수 있다. 투표 전환은 압도적 다수가 존재하지 않는 선에서만 발생하도록 설계될 것으로 예산된다.

PoH 생성자가 정해지면 거래 처리 업무를 인계받을 2차 생성자를 선택할 수 있다. 2차 생성자가 존재하면, 1차 오류시 다음번 리더로 지정될 수 있다.

이 플랫폼은 예외가 탐지되거나 사전에 정의된 일정에 따라 2차 생성자가 1차 생성자가 되고 하위 순위 생성자가 승격되도록 설계되었다.

 

5.7 선거 트리거

 

5.7.1 역사 증명 생성기 포크

 

PoH 생성자는 생성된 시퀀스에 서명하는 ID로 설계된다. PoH 생성자 ID가 손상된 경우에만 포크가 발생한다. 동일한 PoH 생성자 ID 에 두 개의 다른 기록 레코드가 발행됨으로 인해 포크가 감지된다.

 

5.7.2 런타임 오류

 

하드웨어 에러, 버그 또는 의도적인 PoH 생성자 오류로 인해 유효하지 않은 상태가 생성되고 로컬 검증기 결과와 일치하지 않는 상태의 서명이 게시될 수 있다. 검증자들이 가십을 통해 정확한 서명을 발행하면 이 이벤트가 새로운 선거를 촉발할 것이다. 유효하지 않은 상태를 수락하는 모든 검증자들의 채권은 삭감될 것이다.

 

5.7.3 네트워크 시간초과

 

네트워크 시간초과는 투표를 촉발한다.

 

5.8 삭감(slashing)

 

검증자가 두개의 개별 시퀀스에 투표하면 삭감된다. 악의적인 투표가 증명되면 예치된 코인은 유통되지 못하고 채굴장에 추가되도록 한다. 

경쟁하는 시퀀스에 대한 이전의 투표를 포함하는 투표는 악의적인 투표로 보기는 어렵다. 채권을 삭감하는 대신, 경쟁하는 시퀀스에 대한 현재의 투표권을 없앤다.

PoH 생성자에 의해 생성된 유효하지 않은 해시에 대한 투표 또한 삭감된다. 이 생성자가 잘못된 상태를 임의로 생성하면, 2차 생성자로 장애 처리가 넘어갈 것으로 기대된다.

 

5.9 2차 투표

 

2차 이하 등급의 역사 증명 생성자를 제안하고 승인할 수 있다. 제안은 1차 생성자 시퀀스에 따라 결정된다. 제안은 시간초과가 포함되며, 제한시간 내에 동의안이 압도적 다수의 투표에 의해 승인되면 2차 생성자가 승인된 것으로 간주되어 정해진 대로 업무를 인계받는다. 1차 생성자는 인계가 발생함을 명시한 시퀀스를 포함한 메시지를 삽입함으로써 2차 생성자에게 soft handover 를 수행할 수 있다. 

2차 생성자가 선출되고 1차 생성자가 실패하면, 2차 생성자가 선거 중 우선 장애 처리자로 간주된다.

 

5.10 가용성

 

파티션을 다루는 CAP 시스템은 일관성과 가용성 중에 선택해야 한다. 우리의 접근 방식은 최종적으로 가용성을 선택하지만, 우리에게는 객관적인 시간 척도가 있으므로, 상식적인 시간 범위 내에서 일관성도 선택된다.

지분증명 검증자들은 특정 거래에 투표할 수 있는 스테이킹된 코인 일정량을 락업한다. 코인 락업은 다른 거래와 마찬가지로 PoH 스트림에 입력되는 거래이다.

투표를 하려면 PoS 검증자는 상태의 해시를 서명해야 하는데, 상태는 모든 거래를 PoH 원장의 특정 위치에 처리한 뒤 계산되었기 때문이다. 이 투표 역시 PoH 스트림에 입력된다. PoH 원장을 통해 각 투표 사이에 얼마나 많은 시간이 흘렀는지, 파티션이 발생한 경우 각 검증기를 얼마나 오래 사용할 수 없는지 등을 유추할 수 있다.

파티션을 합리적인 시간 내에 처리하기 위해 우리는 사용할 수 없는 검증자를 언스테이킹하는 동적인 접근법을 제안한다. 검증자 수가 많고 3분의 2 이상이면, 언스테이킹 프로세스는 빠르게 처리될 수 있다. 사용할 수 없는 검증자가 완전히 언스테이킹되고 합의에서 제외되기까지 원장에 생성되는 해시의 수는 적다.

검증자 수가 2분의 1 이상 3분의 2 미만 인 경우, 언스테이킹 타이머는 느려지므로 누락된 검증자가 언스테이크되기 전에 더 많은 해시를 생성해야 한다. 절반 이상의 검증자가 없는 파티션처럼 파티션이 큰 경우에서는 언스테이킹 프로세스가 매우 느리다. 거래는 여전히 스트림에 입력할 수 있고 검증자는 여전히 투표할 수 있지만, 3분의 2 이상의 완전한 합의에 이르기 까지 매우 많은 해시가 생성되고 사용할 수 없는 검증자가 언스테이킹되어야 한다. 네트워크가 다시 활성화되는 시간의 차이로 인해, 네트워크 인간 시간 프레임의 고객으로서 우리는 계속 사용하고자 하는 파티션을 선택할 수 있다.

 

5.11 복구

 

우리가 제안하는 시스템에서는 어떤 장애에서도 원장을 완전히 복구할 수 있다. 즉, 전 세계 누구나 원장의 임의의 지점을 골라 새로 생성된 해시와 트랜잭션을 추가하여 유효한 포크를 만들 수 있다. 이 포크에서 모든 검증자가 누락되면, 추가 채권이 유효해지고 이 브랜치가 3분의 2 압도적 다수의 합의를 달성하는 데 매우 오랜 시간이 걸릴 것이다. 따라서 가용 검증자가 0인 완전 복구는 장부에 매우 많은 양의 해시를 추가해야 하며, 사용할 수 없는 검증자가 모두 언스테이킹된 후에야 새로운 채권이 원장의 유효성을 확인할 수 있을 것이다.

 

5.12 불변성(Finality)

 

PoH는 네트워크의 검증자들이 과거에 무슨 일이 일어났는지 어느 정도 확실하게 관찰할 수 있게 해준다. PoH 생성자가 메시지 스트림을 생성할 때 모든 검증자는 500ms 이내에 상태 서명을 제출해야 한다. 이 시간은 네트워크 상태에 따라 더 감소할 수 있다. 각 검증이 스트림에 입력되기 때문에 네트워크의 모든 사람은 실제로 투표를 관찰하지 않고도 모든 검증자가 필요한 시간 제한 내에 투표를 제출했는지 검증할 수 있다.

 

5.13 공격

 

5.13.1 공유지의 비극

 

PoS 검증자는 PoH 생성자에 의해 생성된 상태 해시를 확인하기만 하면 된다. 그들은 아무런 작업도 하지 않고 단순히 생성된 모든 상태 해시를 승인할 경제적 동기가 있다. 이 조건을 피하기 위해 PoH 생성자는 임의의 간격으로 유효하지 않은 해시를 주입해야 한다. 이 해시에 찬성하는 유권자는 누구든 삭감해야 한다. 해시가 생성되면 네트워크는 즉시 2차로 선출된 PoH 생성기를 승격해야 한다.

각 검증자는 짧은 시간 제한(예: 500ms) 내에 응답해야 한다. 시간 초과는 악의적인 검증자가 다른 검증자 투표를 관찰하고 자신의 표를 스트림으로 충분히 빠르게 가져올 가능성이 낮도록 설정해야 한다.

 

5.13.2 PoH 생성자와의 충돌

 

PoH 생성기와 결탁한 검증자는 유효하지 않은 해시가 언제 생성될지 미리 알고 투표하지 않을 것이다. 이 시나리오는 실제로 PoH 객체가 더 큰 검증자 지분을 갖는 것과 같다. PoH 생성기는 여전히 상태 해시를 생성하기 위해 모든 작업을 수행해야 한다.

 

5.13.3 검열

 

검열이나 서비스 거부는 채권 보유자 중 3분의 1이 신규 채권의 시퀀스를 검증하는 것을 거부할 때 발생할 수 있다. 프로토콜은 채권이 얼마나 빨리 노후화하는지를 동적으로 조절함으로써 이러한 형태의 공격으로부터 방어할 수 있다. 서비스 거부가 발생할 경우, 더 큰 파티션은 비잔틴 채권 보유자들을 분기하고 검열하도록 설계될 것이다. 더 큰 네트워크는 시간이 지남에 따라 비잔틴 채권이 오래됨에 따라 다시 회복될 것이다. 작은 비잔틴 파티션은 더 오랜 시간 동안 진행할 수 없다.

이 알고리즘은 다음과 같이 작동한다. 네트워크의 과반수가 새로운 리더를 선출할 것이다. 그리고 나서 지도자는 비잔틴 채권 보유자들이 참여하는 것을 검열할 것이다. 역사 증명 생성자는 시간의 흐름을 증명하기 위해 충분한 비잔틴 채권이 오래되어 더 큰 네트워크가 압도적 다수를 보유할 때까지 시퀀스를 계속 생성해야 할 것이다. 채권이 오래되는 비율은 채권의 활성 비율에 따라 동적으로 결정된다. 따라서 네트워크의 비잔틴 소수 포크는 다수의 포크가 압도적 다수를 회복하기까지 보다 훨씬 더 오래 기다려야 할 것이다. 일단 압도적 다수가 되면, 비잔틴 채권 보유자들을 영구적으로 처벌하기 위해 삭감이 사용될 수 있다.

 

5.13.4 장거리 공격

 

PoH는 장거리 공격에 대한 원천적인 방어 기능을 제공한다. 과거의 어떤 지점에서든 원장을 복구하려면 공격자가 PoH 발생자의 속도를 앞질러 유효한 원장을 제시간에 추월해야 한다.

합의 프로토콜은 두 번째 방어 계층을 제공하는데, 모든 유효한 검증자를 언스테이크하는 데 걸리는 시간보다 공격 시간이 더 오래 걸리기 때문이다. 그것은 또한 원장 기록에 가용성 격차를 발생시킨다. 동일한 길이의 두 원장을 비교할 때, 최대 파티션이 가장 작은 원장이 객관적으로 유효한 것으로 간주될 수 있다.

 

5.13.5 ASIC 공격

이 프로토콜에는 파티션 기간과 불변성에서의 치팅 타임아웃이라는 두 가지 ASIC 공격 기회가 있다.

파티션 중 ASIC 공격의 경우, 채권이 언스테이킹되는 속도는 비선형이며, 파티션이 큰 네트워크의 경우 속도가 ASIC 공격의 예상 이득보다 훨씬 느리다.

불변성 중 ASIC 공격의 경우, 이 취약성을 통해 연결된 지분을 가진 비잔틴 검증자가 다른 노드의 확인을 기다리고 협업하는 PoH 생성자로 투표를 주입할 수 있다. 그런 다음 PoH 생성기는 더 빠른 ASIC를 사용하여 500ms 짜리 해시를 더 짧은 시간에 생성하고 PoH 생성기와 협력 노드 간의 네트워크 통신을 허용할 수 있다. 그러나 PoH 발생기도 비잔틴이라면, 비잔틴 발생기가 오류를 삽입할 것으로 예상할 때 정확한 카운터를 통신하지 않았을 이유가 없다. 이 시나리오는 PoH 생성기와 모든 공동작업자가 동일한 ID를 공유하고 하나의 결합된 지분을 가지며 하나의 하드웨어 세트만 사용하는 것과 다르지 않다.

 

6. 복제 증명 스트리밍

6.1 개요

 

파일코인은 복제 증명 버전을 제안했다. 이 버전의 목표는 복제 증명의 빠른 스트리밍 검증을 수행하는 것이며, 복제 증명 생성 시퀀스에서 시간을 추적함으로써 가능하다. 복제는 합의 알고리즘으로 사용되는 것이 아니라 블록체인 이력이나 상태를 고가용성으로 저장하는 비용을 고려하는 데 유용한 도구다.

 

6.2 알고리즘

 

그림 7과 같이 CBC 암호화는 이전에 암호화된 블록을 사용하여 입력 데이터를 XOR로 암호화한다.

각 복제 ID는 역사 증명 시퀀스가 생성된 해시에 서명하여 키를 생성한다. 이것은 복제자 특성 및 특정 기록 증명 시퀀스와 관련이 있다. 특정 해시만 선택할 수 있다. (해시 선택에 대한 섹션 6.5 참조)

 

그림 7. 순차적 CBC 암호화

 

데이터 세트는 블록 단위로 완전히 암호화된다. 그런 다음 증명을 생성하기 위해 키는 각 블록에서 임의의 32바이트를 선택하는 유사 난수 생성기의 시드에 사용한다.

머클 해시는 선택한 PoH 해시가 각 슬라이스 앞에 추가되어 계산된다.

루트는 키 및 생성된 선택한 해시와 함께 발행된다. 복제 노드는 역사 증명 생성기에 의해 생성된 N 해시의 또 다른 증명을 발행해야 한다. 여기서 N은 데이터를 암호화하는 데 걸리는 시간의 약 2분의 1 이다. 역사 증명 생성기는 미리 정의된 기간에 복제 증명에 대한 특정 해시를 발행한다. 복제자 노드는 증명을 생성하기 위해 다음에 발행된 해시를 선택해야 한다. 다시 해시가 서명되고 블록에서 임의의 슬라이스를 선택하여 머클 루트를 생성한다.

N개의 증명 기간이 지나면 데이터가 새 CBC 키로 다시 암호화된다.

그림 8. 빠른 복제 증명

6.3 검증

 

N개의 코어를 사용하여 각 코어는 각 ID에 대해 암호화를 스트리밍할 수 있다. 이전의 암호화된 블록이 다음 블록을 생성하기 위해 필요하기 때문에 필요한 총 공간은 2블록 * N 코어이다. 각 코어는 현재 암호화된 블록에서 파생된 모든 증명을 생성하는 데 사용될 수 있다.

증명을 확인하는 데 걸리는 총 시간은 암호화하는 데 걸리는 시간과 같을 것으로 예상된다. 증명 자체가 블록에서 랜덤 바이트를 거의 사용하지 않기 때문에 해시할 데이터의 양이 암호화된 블록 크기보다 상당히 적다. 동시에 확인할 수 있는 복제 ID 수는 사용 가능한 코어 수와 동일하다. 현대의 GPU는 CPU의 클럭 속도의 ½ - ⅓ 이지만 3500개 이상의 코어를 사용할 수 있다.

 

6.4 키 로테이션

 

키를 순환하지 않으면 동일한 암호화된 복제로 여러 개의 역사 증명 시퀀스에 대한 증명을 손쉽게 생성할 수 있다. 키는 주기적으로 순환되고 각 복제는 고유한 역사 증명 시퀀스에 연결된 새 키로 다시 암호화된다.

CPU보다 코어당 속도가 느린 GPU 하드웨어에서 복제 증명을 검증할 수 있을 만큼 순환이 느려야 한다.

 

6.5 해시 선택

 

역사 증명 생성기는 전체 네트워크에서 복제 증명 암호화 및 빠른 증명에서 바이트 선택을 위한 의사 난수 생성기로 사용할 해시를 발행한다.

해시는 데이터 세트를 암호화하는 데 걸리는 시간의 ½ 에 해당하는 주기적인 카운터에 발행된다. 각 복제 ID는 동일한 해시를 사용해야 하며 해시의 서명된 결과를 바이트 선택 시드로 사용하거나 암호화 키를 사용해야 한다.

각 복제자가 증명을 제공해야 하는 기간은 암호화 시간보다 작아야 한다. 그렇지 않으면 복제자는 각 증명에 대해 암호화를 스트리밍하고 삭제할 수 있다.

악의적인 생성기는 이 해시 이전의 시퀀스에 데이터를 주입하여 특정 해시를 생성할 수 있다. 이 공격은 5.13.2 절에서 더 자세히 논의한다.

 

6.6 증명 유효성 검증

 

역사 증명 노드는 제출된 복제 증명의 유효성을 검사하지 않는다. 복제자 ID가 제출한 보류 중 및 확인된 증명의 수를 추적할 수 있을 것으로 기대된다. 증명은 복제자가 네트워크에 있는 대다수의 검증자가 증명에 서명할 수 있을 때 검증될 것으로 예상된다.

검증은 복제자가 P2P 가십 네트워크를 통해 수집하며, 네트워크에서 대다수의 검증자를 포함하는 하나의 패킷으로 제출한다. 이 패킷은 역사 증명 시퀀스에 의해 삭제된 특정 해시 생성 이전의 모든 증명을 검증하며, 한 번에 여러 복제자 ID를 포함할 수 있다.

 

6.7 공격

6.7.1 스팸

 

악의적인 사용자는 많은 복제자 ID를 생성하고 잘못된 증명 스팸을 네트워크에 보낼 수 있다. 더 빠른 검증을 위해 노드들은 검증을 요청할 때 암호화된 데이터와 전체 머클 트리를 네트워크의 나머지 부분에 제공해야 한다.

본 논문에서 설계된 복제 증명은 추가 공간이 필요 없기 때문에 추가 증명에 대한 저렴한 검증을 가능하게 한다. 그러나 각 ID는 암호화 시간의 1코어를 소모한다. 복제 대상은 즉시 사용할 수 있는 코어의 최대 크기로 설정해야 한다. 최신 GPU에는 3500개 이상의 코어가 탑재되어 있다.

 

6.7.2 부분 삭제

 

복제자 노드는 전체 상태를 저장하지 않기 위해 일부 데이터를 부분적으로 지우려고 할 수 있다. 증명의 수와 시드의 임의성이 이 공격을 어렵게 만들 것이다.

예를 들어, 1 테라바이트의 데이터를 저장하는 사용자는 각 1 메가바이트 블록에서 1 바이트를 지운다. 매 메가바이트당 1바이트를 샘플링하는 하나의 증명은 삭제된 바이트와 충돌할 확률이 1-(1-1/1,000,0000)1,000,000 = 0.63 이다. 5번의 증명 시 가능성은 0.99이다.

 

6.7.3 PoH 생성자와의 충돌

 

서명된 해시는 샘플을 시드하는 데 사용된다. 복제자가 특정 해시를 미리 선택할 수 있는 경우, 복제자는 샘플링되지 않을 모든 바이트를 지울 수 있다.

역사 증명 생성자와 결탁한 복제자 ID는 임의 바이트 선택을 위해 미리 정의된 해시가 생성되기 전에 시퀀스의 끝에 특정 트랜잭션을 주입할 수 있다. 코어가 충분하면 공격자는 복제자 ID보다 선호되는 해시를 생성할 수 있다.

이 공격은 단일 복제자 ID에만 도움이 될 수 있다. 모든 ID는 ECDSA(또는 이와 동등한)로 암호화되어 서명한 동일한 해시를 사용해야 하기 때문에 결과 서명은 각 복제자 ID에 대해 고유하며 충돌에 강하다. 단일 복제자 ID는 한계 이득만 가질 것이다.

 

6.7.4 서비스 거부

 

복제자 ID를 추가하는 비용은 스토리지 비용과 동일할 것으로 예상된다. 모든 복제자 ID를 확인하기 위해 추가 계산 용량을 추가하는 비용은 복제 ID당 CPU 또는 GPU 코어의 비용과 동일할 것으로 예상된다.

따라서 유효한 복제자 ID가 많이 생성되어 네트워크에 대한 서비스 거부 공격이 발생할 수 있다.

이 공격을 제한하기 위해 네트워크에 대해 선택된 합의 프로토콜은 복제 대상을 선택하고 네트워크의 가용성, 대역폭, 지리 위치 등과 같이 필요한 특성에 부합하는 복제 증명을 선정할 수 있다.

 

6.7.5 공유지의 비극

 

PoS 검증자는 아무런 작업 없이 PoRep을 간단하게 확인할 수 있었다. 경제적 인센티브는 PoS 검증자와 PoRep 복제 노드 간에 마이닝 지급액을 분할하는 것과 같은 작업을 수행하기 위해 PoS 검증자와 연계되어야 한다.

이 시나리오를 더 피하기 위해 PoRep 검증자는 적은 시간 동안 잘못된 증명을 제출할 수 있다. 그들은 거짓 데이터를 생성한 함수를 제공함으로써 증명이 잘못되었음을 입증할 수 있다. 잘못된 증명이 확인된 PoS 검증자는 모두 삭감된다.

 

7. 시스템 아키텍처

7.1 컴포넌트

7.1.1 리더, 역사 증명 생성자

 

그림 9. 시스템 아키텍처

 

리더는 선출된 역사 증명서 생성자이다. 임의의 사용자 거래를 받아서 시스템에서 전역적으로 고유한 순서를 보장하는 모든 거래의 역사 증명 시퀀스를 출력한다. 각 거래의 배치 처리 후 리더는 해당 순서대로 거래를 실행한 결과 상태의 서명을 출력한다. 이 서명은 리더의 ID로 서명 된다.

 

7.1.2 상태

 

사용자 주소로 인덱싱된 단순한 해시 테이블. 각 셀은 전체 사용자 주소와 이 계산에 필요한 메모리를 포함한다. 예를 들어 총 32바이트 트랜잭션 테이블에는 다음이 포함된다 :

총 64바이트 지분 증명 채권 표에는 다음이 포함된다 :

7.1.3 검증자, 상태 복제

 

검증 노드는 블록체인 상태를 복제하고 블록체인 상태의 고가용성을 제공한다. 복제 대상은 합의 알고리즘에 의해 선택되며, 합의 알고리즘의 검증자는 오프체인 정의 기준에 따라 자신이 승인한 복제 증명 노드를 선택하고 투표한다.

네트워크는 최소 지분 증명 채권 크기와 결합당 단일 복제자 ID로 구성할 수 있다.

 

7.1.4 유효성 검증자

 

이러한 노드는 검증자(Verifier)의 대역폭을 사용하고 있다. 이러한 노드는 가상 노드이며 검증자나 리더와 동일한 시스템에서 실행되거나 이 네트워크에 대해 구성된 합의 알고리즘과 관련된 별도의 시스템에서 실행될 수 있다.

 

7.2 네트워크 제한

그림 10. 생성자 네트워크 제한

 

리더는 입력되는 사용자 패킷을 가장 효율적인 방법으로 주문하고 다운스트림 검증자에 발행된 역사 증명 시퀀스에 배열할 수 있어야 한다. 효율성은 트랜잭션의 메모리 액세스 패턴을 기반으로 하기 때문에 장애를 최소화하고 선인출을 극대화하기 위해 트랜잭션이 정렬된다.

 

입력 패킷 형식:

사이즈는 20 + 8 + 16 + 8 + 32 + 3232 = 148 바이트.

 

지원 가능한 최소 페이로드는 1개의 목적지 계정이 될 것이다. 페이로드는 다음과 같다 :

페이로드 시 최소 크기: 176바이트

 

역사 증명 시퀀스 패킷에는 PoH 시퀀스에 추가된 모든 새 메시지의 현재 해시, 카운터 및 모든 메시지를 처리한 후 상태 서명이 포함된다. 이 패킷은 N개의 메시지가 브로드캐스트될 때마다 전송된다.

역사 증명 패킷 : 

출력 패킷의 최소 크기는 132바이트이다.

 

1Gbps 네트워크 연결에서 가능한 최대 트랜잭션 수는 초당 1기가비트/176바이트 = 710k tps이다. 이더넷 프레임으로 인해 1-4%의 손실이 예상된다. 네트워크의 목표량을 초과하는 여유 용량은 Reed-Solomon 코드로 출력을 코딩하고 사용 가능한 다운스트림 Verifier로 스트라이핑하여 가용성을 높이는 데 사용할 수 있다.

 

7.3 연산 제한

 

각 트랜잭션에는 다이제스트 검증이 필요하다. 이 연산은 트랜잭션 메시지 자체의 외부 메모리를 사용하지 않으며 독립적으로 병렬화할 수 있다. 따라서 시스템에서 사용할 수 있는 코어 수에 따라 처리량이 제한될 것으로 예상된다.

GPU 기반 ECDSA 검증 서버는 실험 결과 초당 900K 연산을 수행했다.

 

7.4 메모리 제한

 

각 계정에 대해 32바이트 엔트리가 있는 50% 풀 해시테이블로서 상태를 단순하게 구현하면 이론적으로 640GB에 100억 개의 계정을 넣을 수 있다. 이 테이블에 대한 정상 상태 랜덤 액세스는 초당 1.1 * 107 회의 쓰기 또는 읽기로 측정되었다. 트랜잭션당 읽기 2회, 쓰기 2회 기준으로 메모리 처리량은 초당 2.75만 건의 트랜잭션을 처리할 수 있다. 이는 Amazon Web Services의 1TB x 1.16xlarge 인스턴스에서 측정되었다.

 

7.5 고성능 스마트 컨트랙트

 

스마트 컨트랙트는 거래의 일반적인 형태이다. 각 노드에서 실행되며 상태를 수정하는 프로그램이다. 이 설계는 빠르고 분석하기 쉬운 확장 버클리 패킷 필터 바이트코드와 스마트 계약 언어로 JIT 바이트코드를 활용한다.

제로 코스트 대외 기능 인터페이스도 주요 장점 중 하나다. 플랫폼에서 직접 구현되는 기능들은 프로그램에 의해 호출될 수 있다. 속성 호출은 해당 프로그램을 일시 중단하고 고성능 서버에서 내장 프로그램을 예약합니다. 본질은 GPU에서 병렬로 실행하기 위해 함께 일괄 처리된다.

위의 예에서, 두 개의 다른 사용자 프로그램은 동일한 내장 함수를 호출한다. 각 프로그램은 내장 함수의 배치 수행이 완료될 때까지 일시 중단된다. 내장 함수의 예로는 ECDSA 검증이 있다. GPU에서 실행하기 위해 이러한 호출을 일괄 처리하면 처리량이 수천 배 증가할 수 있다.

이 트램폴린은 BPF 바이트코드가 사용하는 모든 메모리에 대해 잘 정의된 컨텍스트를 가지고 있기 때문에 기본 운영 체제 스레드 컨텍스트 전환이 필요하지 않다.

 

그림 11: BPF 프로그램 실행

 

eBPF 백엔드는 2015년부터 LLVM에 포함되었으므로 스마트 컨트랙트를 작성하기 위해 모든 LLVM 프론트엔드 언어를 사용할 수 있다. 2015년부터 리눅스 커널에 있었고 바이트코드의 첫 번째 반복은 1992년부터 있었다. 단일 패스는 eBPF의 정확성을 확인하고 런타임 및 메모리 요구 사항을 확인하고 x86 명령으로 변환할 수 있다.