BlockChain Core - Sharding on Blockchain 7

자료 : SoK: Sharding on Blockchain
지난 포스트 - SoK: Sharding on Blockchain 6

---

5 EPOCH RANDOMNESS 본문

In blockchain sharding protocols, when multiple nodes are involved in a consensus protocol, an important issue is how the participating nodes are assigned to which committee so that the generated committee is “fair”. For example, each generated committee requires that it has a majority of hon- est nodes, and the ratio of faulty nodes should not exceed a threshold that the consensus protocol specified for that shard. One approach to assigning nodes to committees is done stat- ically according to a specified policy, in which it assumes the existence of a random source or a trusted third party, e.g., RSCoin [55]. However, such approach can be problematic in a permissionless setting, which requires a shared random coin [47] [73]. Another approach is to dynamically allocate nodes to committees. This dynamic allocation should be a randomized process, aiming to stop an adversary from con- centrating its presence in one committee, and exceeding the Byzantine tolerance threshold. However, generating good randomness in a distributed manner is a known hard prob- lem. For example, the distributed random number generator in [7] can only tolerate up to 1/6 fraction of Byzantine nodes, while still incurring a high message complexity. There exist other randomness generation schemes with different goals or sychrony [83] settings, such as AVSS [30] and APSS [143] for asynchronous communication model, RandHound and RandHerd [127] for scalability in synchronous communica- tion model. In this section, we discuss the potential epoch randomness for sharding-based protocols, and summarize the start-of-the-art epoch randomness generation for block- chain.

5.1 Properties of Epoch Randomness

To generate a seed for sharding securely without requiring a trusted randomness beacon [55] or binding the protocol to PoX, a good distributed randomness generation is required to meet with several features: public-verifiability, unbiasability, unpredictability, and availability. 1). Public-Verifiability: A third party, e.g., not directly par- taking processes, should also be able to verify generated value. As soon as a new random beacon value becomes avail- able, all parties can verify the correctness of the new value using public information only. 2). Bias-Resistance: This is the assurance that any single participant or a colluding adversary cannot influence the future randomness beacon values to its own advantage. 3). Unpredictability: Participants (either correct or adver- sarial) should not be able to predict or precompute future random beacon values in advance. 4). Availability: This property shows that any single partic- ipant or a colluding adversary should not be able to prevent the progress.

5.2 Randomness Generation Methods

Roughly speaking, there exist several ways to generate ran- domness, which can be considered as the baseline of bias- resistance randomness generation. This section introduces these baselines, including Verifiable Random Function (VRF) [105], Verifiable Secret Sharing (VSS) [67], Public Verifiable Secret Sharing (PVSS) [124], and Verifiable Delay Functions (VDF) [21] [113].

1) VRF
Intuitively, the idea behind a VRF is that Alice asks Bob to compute a function fs on some input x. Only Bob is able to compute fs as its result is dependent on some secret value s, which only Bob knows. The result v = fs (x) has the property of being unique and computationally indis- tinguishable from a truly random string v ′ of equal length. Alice wants to be sure that Bob indeed provided the unique correct result of the computations [14]. Formally, VRFs ad- dress the issue of unverifiability of Pseudo-Random Func- tions (PRFs). Consider the case where a party computing fs(x1), fs(x2),..., fs(xn)claims the corresponding outputs are o1,o2,...,on. Without knowledge of s, an observer cannot verify that applying fs to xi indeed yields the corresponding output oi . As soon as s gets published, future output values are not indistinguishable from truly random strings anymore. They get fully predictable and can be efficiently computed by any party.
To obtain verifiability without compromising the unpre- dictability property of future outputs, a party knowing the seed s publishes v = fs(x) together with a proof proofx. This proof allows verification of the fact that v = fx (x ) indeed holds without revealing s. It is crucial that a party knowing s can only construct a valid proof for a unique v for every x [105]. However, for the proof itself, there is no uniqueness requirement. Some proposed solution is based on interactive zero-knowledge proofs [105]. However, in- teractive zero-knowledge proofs incur high communication complexity.

2) VSS
Secret sharing is a scheme to distribute a se- cret S among a certain number of participants, each one receiving a part of the secret, called a share. Shares can be combined by collaborating participants to reconstruct the original secret. A (t,n)-secret sharing scheme is that any group of t (or more) out of n participants can recover S from their shares. Shamir’s secret sharing protocol [120] is based on polynomial interpolation. The key idea behind it is the fact that given t points(x1,y1),(x2,y2),...,(xt,yt) with different x-coordinates, there is a unique polynomial p(x) of degree (t − 1) going through all of the points. However, Shamir’s secret sharing protocol is based on an important assumption: the participants assume that they are given correct shares. And this limits the ability to apply this scheme in, e.g., fault- tolerant or even trust-less distributed systems. For example, this assumption does not hold in Byzantine fault tolerance systems. Thus, a verifiable secret sharing (VSS) is required to protect against malicious dealers/participants.

3) PVSS
A PVSS scheme [124] [118] makes it possible for any party to verify secret-shares without revealing any information about the secrets or the shares. During the share distribution phase, for each trustee i, the dealer produces an encrypted share Ei (si ) along with a non-interactive zero- knowledge proof (NIZK) [41] to prove that Ei (si ) correctly en- crypts a valid share si of s. During the reconstruction phase, trustees recover s by pooling t properly-decrypted shares. They then publish s along with all shares and NIZK proofs showing that the shares were properly decrypted. There also exist some optimized PVSS schemes, such as SCRAPE [35]. Typically, PVSS runs in three steps:
1). The dealer chooses a degree t − 1 secret sharing poly- nomial s(x) = 􏰀t−1 a x and creates, for each trustee i ∈ j=0 j j{1, ...,n}, an encrypted share Sˆ = Xs(i) of the shared secret ii S0 = Gs(0). The dealer also creates commitments Aj = Haj ,where H 􏰂 G is a generator of д, and for each share a NIZK encryption consistency proof Pˆi , Afterwards, the dealer pub-lishesSˆ,Pˆ andA . 2). Each trustee i verifies his share Sˆ using Pˆ and A , and iij x−1 ifvalid,publishesthedecryptedshareS =(Sˆ)i together ii with z NIZK decryption consistency proof Pi . 3). The dealer checks the validity of Si against Pi , discards invalid shares and, if there are at least t out of n decrypted shares left, recovers the shared secret S0 through Lagrange interpolation.
We should notice that VRFs play a different role from VSS and PVSS: VRFs allow individual parties to produce verifi- able randomness, while both VSS and PVSS allow groups of parties to produce collective randomness, a.k.a “common coins".
As a brief comparison between VSS and PVSS, VSS aims to resist malicious share holders, in which there is a verifica- tion mechanism for each share holder to verify validity of its share, while in PVSS, not just the participants can verify their own shares, but anybody can verfiy that the participants re- ceived correct shares. However, most existing PVSS schemes are complex and inefficient, especially in computation. PVSS schemes are typically “single-use", while VSS schemes and the distributed key generation (DKG) algorithms built from them can produce multi-use distributed threshold key pairs.

4) VDF
Essentially, a verifiable delay function (VDF) re- quires a specified number of sequential steps to evaluate, yet produce a unique output that can be efficiently and publicly verified. VDFs have many applications in decentralized sys- tems, including public randomness beacons, leader election in consensus protocols, and proofs of replications. A VDF is a function f : X → Y that takes a prescribed time to compute, even on a parallel computer. However, once computed, the output can be quickly verified by anyone. Moreover, every input x ∈ X must have a unique valid output y ∈ Y. Spe- cially, a VDF that implements a function X → Y is a tuple of three algorithms:
- Setup(λ, T ) → pp is a randomized algorithm that takes a security parameter λ and a time bound T , and outputs public parameters pp. - Eval(pp,x)→(y,π)takesaninputx ∈Xandoutputs a y ∈ Y and a proof π . - Verify(pp,x,y,π) → {accept,reject} outputsaccept if y is the correct evaluation of the VDF on input x.
If (y,π) ← Eval(pp,x) thenVerify(pp,x,y,π) = accept, for all x ∈ X and pp output by Setup(π,T). Besides, a VDF must satisfy three properties: ε -evaluation time, sequentiality and uniqueness. We refer interested readers to [21, 22, 113] for the details.
Besides the above randomness generation baselines, there exist other works, such as random zoo [94], determinis- tic threshold signatures [20] and distributed key genera- tion [83].

5.3 Comparison

Epoch randomness generation in sharding protocols can be treated as a separate module to provide randomness, so that the node can be fairly assigned to the shards according to the public randomness. Thus, any efficient randomness generation algorithm can be implemented as a separated module.

We provide a comparison of the state-of-the-art epoch ran- domness generation schemes, and discuss these approaches. In our comparison, we do not only consider the protocols specifically targeted at implementing random beacons, but also by including approaches that can readily provide ran- dom beacon functionality as a product of their intended ap- plications, such as a provision of a distributed public ledger. Our comparison mainly focuses on the network models, its achieved properties, complexity evaluation metrics, and the baseline technology. However, we must mention that some characteristics were not specified or not available, so we left them blank. Table 1 shows a comparison for generating public-verifiable randomness for blockchain. About the com- plexity evaluation, n refers to the number of the participants in the overall network, and if the protocols are based on clusters/subsets, c denotes the size of some subset of nodes. And then the value c is protocol dependent, and is typically a constant and negligible factor for the resulting complexity in practice.

5 EPOCH RANDOMNESS

블록체인 샤딩 프로토콜에서 여러 노드가 합의 할 때, 중요한 것은 참여하는 노드가 어떤 위원회에 할당되어 생성된 위원회가 “공정”하게 구성되는지이다.

예를 들어)

• 각 생성된 위원회는 선량한 노드의 과반수를 가져야 하며,
• 결함이 있는 노드의 비율은 해당 샤드의 합의 프로토콜에서 지정한 임계값을 초과해서는 안된다.

committee에 노드를 할당하는 방법

1. 정적 할당

   정적 할당은 특정 정책에 따라 노드를 미리 할당하는 방식이다. 이 방식은 무작위 소스나 신뢰할 수 있는 제3자의 도움을 받아 수행된다.(예: RSCoin). 그러나 이 방식은 공개 허가 설정에서 문제가 될 수 있으며, 공유된 무작위 코인이 필요하다.

   단어 설명

   • RsCoin : 네트워크에 참여한 노드가 서로에게 무작위로 코인을 공유하는 방식으로 블록을 생성한다.(비트코인 같이 경쟁하는 형식이 아님)
   • 공개 허가 설정: 누구나 노드를 운영할 수 있는 설정
   • 공유된 무작위 코인: 모든 노드가 공유하는 코인
   • 공개 허가 설정에서 정적 할당을 사용하면 일부 노드가 다른 노드보다 유리한 위치를 차지할 수 있다. 그래서 공유된 무작위 코인을 사용하는 것.
     • 이 때, RsCoin 같은 코인을 사용하는 것 같다.

2. 동적 할당

   동적 할당은 committee의 요구 사항에 따라 노드를 할당하는 방법이다.

   예를 들어,

   • committee가 많은 데이터를 처리해야 하는 경우 더 많은 노드를 할당하거나
   • committee가 많은 트래픽을 처리해야 하는 경우 더 빠른 노드를 할당해야 한다.

   committee의 비용 절감과 유연성을 향상시키는 이점이 있는 동적 할당 이지만

   설정하고, 관리하기가 어렵다. 특히나 적대적인 행동을 막고, 비잔틴 허용 임계값을 초과하는 한 committee에 집중되는 것을 방지하기 위해 ‘무작위성’이 중요시 되는데, 이게 어렵다.

   분산된 시스템에서는 여러 대의 컴퓨터가 난수를 생성하는데, 서로 다른 방식으로 생성될 경우 예측 가능성이 높아진다고 한다.

챕터 5에서는 시간을 기반으로한 난수 생성 방법에 대해 논의한다.

5.1 Properties of Epoch Randomness

샤딩을 위한 안전한 시드(난수 생성 초기값)를 생성하려면 신뢰할 수 있는 무작위성 비콘이나 PoX 프로토콜에 의존하지 않고도 분산된 난수 생성이 필요하다. 이때 분산된 난수 생성은 몇 가지 특징이 있어야 한다. 공개 검증 가능성, 편향성 없음, 예측할 수 없음, 가용성.

1. 공개 검증 가능성: 직접 참여하지 않는 제3자도 생성된 값을 검증할 수 있어야 한다. 새로운 무작위성 비콘 값이 나오면 모든 참여자는 공개된 정보만을 사용하여 새 값의 정확성을 검증할 수 있어야 한다.
2. 편향성 없음: 어떤 개별 참여자나 공모된 적대적 주체도 미래의 무작위성 비콘 값을 자신의 이익을 위해 조작할 수 없도록 보장해야 한다.
3. 예측할 수 없음: 참여자들은 미래의 무작위성 비콘 값을 사전에 예측하거나 미리 계산할 수 없어야 한다.
4. 가용성: 개별 참여자나 공모된 적대적 주체가 진행을 방해할 수 없도록 해야 한다.

5.2 Randomness Generation Methods

여기서는 여러 무작위성 생성 방법들을 소개한다.

1) VRF

VRF의 아이디어

ALICE와 BOB이라는 두 사람이 있다. ALICE는 BOB에게 “어떤 숫자에 대해 무작위한 결과를 만들어 줄래?”라고 부탁한다.

BOB은 ALICE의 부탁에 따라 특정한 숫자를 사용하여 무작위한 결과를 계산한다. 그리고 그 결과를 ALICE에게 돌려준다.

ALICE는 BOB이 계산한 결과를 받고, 그 결과가 정말로 유일하고 무작위한지 확인하고 싶어한다. 그래서 ALICE는 BOB의 계산 결과가 BOB만이 알고 있는 비밀한 숫자에 의해 올바르게 생성되었는지 확인한다.

VRF는 이렇게 동작한다. BOB은 ALICE의 요청에 대해 무작위한 결과를 생성하고, ALICE는 그 결과를 검증하여 신뢰성을 확보할 수 있다. 이 때, VRF는 무작위성을 제공하면서도 다른 사람들이 그 결과를 쉽게 예측하거나 구별할 수 없도록 보장한다. 이는 Pseudo-Random Functions(PRFs)의 검증 문제를 해결하기 위한 방법으로 사용된다.

미래의 출력 값을 예측할 수 없으면서도 검증할 수 있는 기능을 제공하기 위해서는 시드 값 s를 알고 있는 사람은 v = fs(x)와 proofx라는 증명을 함께 공개한다. 이 증명은 시드 값을 공개하지 않고도 v = fx (x)가 정말로 맞는지 확인할 수 있도록 도와준다.

중요한 점은 시드 값을 알고 있는 사람은 각각의 x에 대해 유일한 v에 대한 올바른 증명을 생성할 수 있어야 한다는 것이다. 그러나 증명 자체에는 고유성 요구 사항이 없다. 일부 제안된 해결책은 대화식 영적 증명(interactive zero-knowledge proofs)을 사용한다. 그러나 대화식 영적 증명은 통신 비용이 많이 드는 단점이 있다.

고유성 요구 사항: 각각의 항목 또는 증명이 서로 다른 것이어야 함 → (증명 자체에는 고유성 요구 사항이 없다.) 동일한 입력에 대해 여러 개의 다른 증명을 생성할 수 있음을 의미

• 시드 값을 알고 있는 사람이 동일한 입력에 대해 여러 개의 서로 다른 증명을 생성할 수 있다. 이는 시드 값을 알지 못하는 사람에게는 다양한 증명이 존재하며, 각 증명이 서로 다른 출력 값을 가질 수 있다는 것을 의미.

2) VSS

VSS는 비밀 값을 여러 명의 참가자에게 분할하여 저장하는 방법이다.

논문에서는 (t,n)-secret sharing scheme 에 대해서 설명하고 있는데, 비밀 값을 t개 이상의 참가자들에게 분할하여 저장하는 방법 자체를 의미한다. 이때, 총 n명의 참가자 가 있는 경우, 비밀 값을 복원하기 위해서는 최소 t명의 참가자 들이 모여야 한다는 뜻. 즉, (t,n)-secret sharing scheme은 비밀 값을 분할하여 각 참가자에게 부여하고, 최소 t명의 참가자가 모여야만 비밀 값을 복원할 수 있는 방식

VSS에서 중요한 점은 참가자들이 분할된 부분 값을 통해 실제로 올바른 비밀 값을 복원할 수 있어야 한다는 것.

• 이를 위해 VSS는 참가자들 간의 상호작용을 통해 비밀 값의 일부를 공개하고, 이 공개된 부분 값을 통해 비밀 값을 검증하는 과정을 거친다.

VSS가 BFT 시스템에서 사용하기 어려운 이유

• 악의적인 노드: VSS는 BFT와 다르게 신뢰할 수 있는 참가자들이 제대로 동작한다는 가정을 기반으로 동작한다.
• 동기화: BFT는 모든 참가자들이 동일한 시간에 동일한 정보를 가지고 있어야 하는데, VSS는 일부 참가자들이 비동기적으로 동작해서 시간에 따라 다른 정보를 가질 수 있다.

3) PVSS

PVSS(Public Verifiable Secret Sharing)는 비밀 값을 여러 참가자에게 분산시키는 동시에 비밀 값의 유효성을 공개적으로 검증할 수 있는 기능을 제공한다.

PVSS는 일반적으로 다음과 같은 세 가지 주요 요소로 구성된다:

1. 분배(Distribution): PVSS에서는 비밀 값을 분할된 부분 값(share)으로 나누고, 각 참가자에게 배포한다. 이때, 분할된 비밀 값은 각 참가자에게 부여되는 일련의 부분 값이다.
2. 복원(Reconstruction): PVSS에서는 일부 참가자들이 자신들이 가지고 있는 부분 값들을 조합하여 원래의 비밀 값을 복원할 수 있다. 이를 위해 필요한 수학적 계산이 이루어진다.
3. 공개적인 검증(Public Verification): PVSS에서는 비밀 값의 유효성을 공개적으로 검증할 수 있다. 다른 참가자나 외부 관찰자들은 비밀 값을 검증하는 데 필요한 정보를 확인할 수 있으며, 비밀 값이 제대로 분배되고 복원되었는지를 확인할 수 있다.

이렇게만 보면 VSS와 비슷한 부분이 있는데,

VSS와 차이점

1. 검증 가능성:
   • VSS: VSS는 비밀 공유의 검증 가능성을 제공한다. 다른 참가자들은 각자가 받은 공유가 올바르게 생성된 것인지 확인할 수 있다. 그러나 이를 확인하기 위해서는 추가적인 정보를 공유해야 한다.
   • PVSS: PVSS는 VSS와 달리 공유의 검증 가능성을 제공하는 동시에, 비밀과 공유에 대한 추가적인 정보를 노출하지 않는다. 다른 참가자들은 각자가 받은 암호화된 공유가 올바르게 생성된 것인지 확인할 수 있다.
2. 암호화:
   • VSS: VSS에서는 공유를 암호화하지 않습니다. 따라서 다른 참가자들이 공유를 직접 볼 수 있다.
   • PVSS: PVSS에서는 암호화된 공유를 사용한다. 공유는 암호화되어 있어 다른 참가자들은 공유를 해독하지 않고도 검증할 수 있다.
3. 비밀 유출:
   • VSS: VSS는 비밀을 알지 못하는 참가자가 공유를 통해 비밀을 유추할 수 있는 가능성이 있다. 비밀을 알지 못하는 참가자는 다른 참가자들의 공유를 조합하여 비밀을 계산할 수 있다.
   • PVSS: PVSS는 공유를 통해 비밀을 유추하는 위험이 없다. 각 참가자가 암호화된 공유만을 받기 때문에, 비밀을 알지 못하는 참가자는 비밀을 유추할 수 없다.

즉,

• PVSS는 공유의 검증 가능성을 유지하면서 비밀과 공유에 대한 추가 정보를 노출하지 않으며, 공유를 암호화하여 비밀 유출 가능성을 제거
• VSS는 공유의 검증 가능성을 제공하지만, 암호화되지 않아 다른 참가자들이 공유를 직접 볼 수 있으며, 비밀 유출 가능성이 있다.

NIZK(비대화식 영적 증명)

위의 차이가 날 수 있는 기술적인 이유로는 NIZK(비대화식 영적 증명) 으로인한 부분이 있다.

NIZK(Non-Interactive Zero-Knowledge)은 비대화식 영적증명을 나타내는 암호학적 개념으로, 증명자가 어떤 주장이 사실임을 증명할 수 있고, 동시에 그 주장이 사실임을 확인하는 자에게는 어떠한 추가적인 정보도 노출하지 않는 특징을 갖는다.

일반적인 영적 증명과 다른 점

증명 과정에서 증명자와 확인자가 여러 번의 상호작용을 필요로 하지 않는다. 대신, 증명자는 단일의 증명을 생성하고, 확인자는 이 증명을 검증하는 과정을 수행.

• 일반적인 ZK: 일반적인 ZK는 상호작용을 통해 주장의 증명과 검증을 수행합니다. 주장자는 여러 번의 상호작용을 통해 증명을 생성하고, 검증자는 주장을 검증하기 위해 여러 번의 상호작용을 수행합니다. 이러한 상호작용은 두 당사자 간에 메시지 교환을 필요로 합니다.
• NIZK: NIZK는 비대화식(non-interactive)이기 때문에 주장의 증명과 검증을 수행하는 단일의 증명만으로도 검증이 가능합니다. 주장자는 단일의 증명을 생성하고, 검증자는 이 증명을 검증함으로써 주장의 사실 여부를 확인할 수 있습니다. 이 과정에서 추가적인 상호작용이 필요하지 않습니다.

즉, NIZK는 일반적인 ZK보다 상호작용이 적거나 전혀 필요하지 않는다는 특징을 가지고 있다.

4) VDF

Verifiable Delay Function (VDF)은 특정 시간 동안 실행되는 계산 함수이다.

• 특징:
  • 계산 시간이 길수록 안전성이 높아진다.
  • 분산 시스템에서 다양한 용도로 사용될 수 있다.
    • 블록체인에서 블록 생성 속도를 제어하는 데 사용할 수 있다.
    • 보안 토큰 발행 또는 암호화 키 생성에도 사용할 수 있다.

VDF는 다음과 같은 세 가지 주요 특성을 갖는다.

• 검증 가능성: VDF의 계산 결과를 검증할 수 있어야 한다.
• 지연: VDF는 특정 시간 동안 실행되어야 한다.
• 확장성: VDF는 확장 가능해야 한다. 즉, VDF를 실행하는 데 필요한 컴퓨팅 리소스는 계산 시간이 증가함에 따라 선형적으로 증가해야 한다.

VDF의 세 가지 알고리즘

VDF의 모든 입력은 유일한 출력을 가지게 되며, 세 가지 알고리즘으로 구성된다.

모든 입력 x ∈ X는 유일한 유효한 출력 y ∈ Y를 가져야 합니다. 즉, VDF는 1대1 함수.

• [초기화 알고리즘] Setup(λ, T) → pp는 보안 매개변수 λ와 시간 제한 T를 입력으로 받아 공개 매개변수 pp를 출력하는 무작위 알고리즘.
  • 초기 상태를 생성
  • λ → 람다
• [계산 알고리즘] Eval(pp, x) → (y, π)는 입력 x ∈ X를 받아 y ∈ Y와 증명 π를 출력.
  • 초기 상태를 입력으로 받아 출력을 생성
• [검증 알고리즘] Verify(pp, x, y, π) → {accept, reject}은 입력 x에 대한 VDF의 올바른 평가인 경우 accept을 출력.
  • 출력을 입력으로 받아 계산 결과를 검증

VDF가 성립되려면?

만약 (y, π) ← Eval(pp, x)이라면, Verify(pp, x, y, π) = accept이며, 모든 x ∈ X와 Setup(π, T)에 의해 출력된 pp에 대해 성립합니다.

VDF의 알고리즘이 정상적으로 작동이 된다면 위의 문장을 만족해야 한다.

위 문장은 “Eval 함수로부터 얻은 (y, π)를 Verify 함수에 넣으면 “accept”라는 결과를 얻을 수 있다.” 라는 것.

• Eval(pp, x)은 주어진 pp와 x에 대한 평가 결과인 (y, π)를 의미.
• Verify(pp, x, y, π)는 주어진 pp, x, y, π에 대한 검증 결과를 나타내며, “accept”는 검증이 성공했음을 의미.
• Setup(π, T)는 π와 T에 대한 초기화 설정 결과를 나타낸다.

VDF가 만족해야 할 세 가지 속성

• 첫째, ε-평가 시간 속성은 VDF가 일정 시간 T만큼 소요되어야 한다는 것
• 둘째, 순차성 속성은 VDF가 연속된 단계를 거쳐야 한다는 것
• 셋째, 고유성 속성은 입력 x ∈ X에 대해 유일한 유효한 출력 y ∈ Y가 존재해야 한다는 것

5.3 Comparison

최신 무작위성 난수 생성 방법에 대한 비교를 제공

• 네트워크 모델
• 달성된 속성
• 복잡성 평가 지표
• 기술적 기반

블록체인을 위한 공개 검증 가능한 난수 생성을 비교

• n은 전체 네트워크의 참가자 수
• 프로토콜이 클러스터/하위 집합을 기반으로 하는 경우 c는 일부 노드의 크기

---

다음에 계속…