Auditable Blockchain Randomization Tool ^†

Abstract

Randomization is an integral part of well-designed statistical trials, and is also a required procedure in legal systems. Implementation of honest, unbiased, understandable, secure, traceable, auditable and collusion resistant randomization procedures is a mater of great legal, social and political importance. Given the juridical and social importance of randomization, it is important to develop procedures in full compliance with the following desiderata: (a) Statistical soundness and computational efficiency; (b) Procedural, cryptographical and computational security; (c) Complete auditability and traceability; (d) Any attempt by participating parties or coalitions to spuriously influence the procedure should be either unsuccessful or be detected; (e) Open-source programming; (f) Multiple hardware platform and operating system implementation; (g) User friendliness and transparency; (h) Flexibility and adaptability for the needs and requirements of multiple application areas (like, for example, clinical trials, selection of jury or judges in legal proceedings, and draft lotteries). This paper presents a simple and easy to implement randomization protocol that assures, in a formal mathematical setting, full compliance to the aforementioned desiderata for randomization procedures.

Meos tam suspicione quam crimine judico carere oportere.

My people should be free from either crime or suspicion.

Julius Caesar (62BC), in Suetonius (119CE, Sec.I.74.2).

1. Introduction: Bad and Good Practices in Randomization

Randomization is a technique used in the design of statistical experiments: in a clinical trial, for example, patients are randomly assigned to distinct groups receiving different treatments with the goal of studding and contrasting their effects. Randomization is nowadays considered a golden standard in statistical practice; its motivation is to prevent systematic biases (like an unfair or tendentious assignment process) that could distort (unintentionally or purposely) the conclusions of the study. For further comments on randomization see [1,2,3], for Bayesian perspectives see [4,5]. In the legal context, randomization (also known as sortition or allotment) is routinely used for the selection of jurors or judges assigned to a given judicial case; see [6]. For these applications, our initial quotation, from the Roman emperor Julius Caesar, suggests the highest standards of technical quality, and auditability, see [7].

Rerandomization is the practice of rejecting and discarding (for whatever reason) a given randomized outcome, that is subsequently replaced by a new randomization. Repeated rerandomization can be used to completely circumvent the haphazard, unpredictable or aimless nature of randomization, allowing a premeditated selection of a final outcome of choice. There are advanced statistical techniques capable of blending the best characteristics of random and intentional sampling, see for example [8,9,10,11,12]. Nevertheless, rerandomization is often naively used, or abused, with the excuse of (subjectively) “avoiding outcomes that do not look random enough”, see for example [13,14]. In the legal context, spurious manipulations of the randomization process are often linked to fraud, corruption and similar maladies, see [6] and references therein.

In order to comply with the best practices for randomization processes, the authors of [6] recommend the use of computer software having a long list of characteristics, for example, being efficient and fully auditable, well-defined and understandable, sound and flexible, secure and transparent. Such requirements are expressed by the following (revised) desiderata for randomization procedures:

Given the juridical and social importance of the themata under scrutiny, we believe that it is important to develop randomization procedures in full compliance with the following desiderata: (a) Statistical soundness and computational efficiency, see [15,16,17,18]; (b) Procedural, cryptographical and computational security, see [19,20,21,22]; (c) Complete auditability and traceability, see [23,24,25]; (d) Any attempt by participating parties or coalitions to spuriously influence the procedure should be either unsuccessful or be detected, see [26,27,28]; (e) Open-source programming; (f) Multiple hardware platform and operating system implementation; (g) User friendliness and transparency, see [29,30]; (h) Flexibility and adaptability for the needs and requirements of multiple application areas (like, for example, clinical trials, selection of jury or judges in legal proceedings, and draft lotteries), see [6].

Such requirements conflate several complementary characteristics that may seem, at first glance, incompatible. For example, strong security is often (but wrongly) associated with excessive secrecy, a doctrine known as “security by obscurity”, computer routines may be efficient but are often tough as hard to audit, and mathematically well-defined algorithms may be perceived as hard to understand. The bibliographical references given in the formerly stated desiderata for randomization procedures already hint at technologies that can be used to achieve a fully compliant randomization procedure, most preeminently, the blockchain. This is the key technology supporting modern public ledgers, cryptocurencies, and a host of related applications.

A technical challenge for the application under scrutiny is the generation of pseudo-random number sequences that reconcile complementary properties related to computational efficiency, statistical soundness, and cryptographic security. In this respect, the excellent statistical and computational characteristics of linear recurrence pseudo-random number generators (or their modern descendants and relatives), like [16], can be reconciled with the needs concerning unpredictability and cryptographic security by appropriate starts and restarts of the linear recurrence generator. A sequence start for a linear recurrence generator is defined by a seed specified by a vector of (typically 1 to 64) integers, while a restart is defined by a jump-ahead or skip-ahead specified by a single integer (kept small relative to the generator’s full period), see [22].

Unpredictable and cryptographically secure seeds and jump-aheads can be provided by high entropy bit streams extracted from blockchain transactions, an idea that has already been explored in the works of [31,32,33,34].

The next section develops a possible implementation of a fully compliant core randomization protocol based on blockchain technology, and also makes a simple prototype available for study and further research. Moreover, in order to make it simple and easy to use, we develop the prototype on top of a readily available crypto-currency platform. We use Bitcoin for this example, but other alternatives like Ethereum or other cryptocurrencies whose miners work under the same incentives model can be used with minor adaptations.

2. Results: Core Randomization Protocol in Blockchain

We intend to establish a protocol able to deliver on demand pseudo random numbers, from an auditable and immutable ledger. The procedure will start as follows: the user (the part that wants to receive a random number) shall send a Bitcoin transaction with a register of its purpose embedded in it. (One way to embed a message in a transaction is using the OP_RETURN script, which allows to store up to 40 bytes in a transaction.) The recipient of this transaction may be a proxy representing a competent authority, a pertinent regulatory agency, an agreed custodian, etc. When this transaction is first attached to the blockchain, we concatenate the transaction ID (a 32 bytes, hexadecimal number) and the block header (a 80 bytes, hexadecimal number). In case someone tries to generate more than one transaction for a same purpose, just take the one that was attached first. The resulting 112 bytes hexadecimal number will be the input for some known Verifiable Delay Function (VDF), that should be calibrated accordingly to the purpose of the random number. For instance, a less critical purpose should have a VDF that delays the result in just a few seconds, or even skip completely the VDF step. A critical purpose, with significant interests involved, should have a more complex VDF, with a delay of minutes or even hours. The final result, after the VDF, will be the source for our seeds and jump-aheads.

With the aid of this protocol, one is able to find a different pseudo-random number for each user that demands it. Note that the user does not have any incentive to try to modify its transaction ID, because he does not have any control of the block header. We assume that the user and the miner are not the same person, so a miner will only be interested in trying to control his block header if he is paid to do so. Since the last stage of our protocol involves the calculation of a VDF, it will take a certain amount of time to the miner to decide if the the block he has found will be of interest of the user. Thus, he might even lose his block, if some other miner broadcasts a block of his own before he finishes calculating the VDF.

In the following subsection, the miner’s payoff and the necessary delay T for the Verifiable Delay Functions will be explicitly calculated.

 2.0.1. Preventing Collusion for Spurious Manipulation

Suppose a malicious user tries to bribe a miner that controls a fraction p of the network’s computational power. A prize $P=nB$, where B is the Bitcoin block reward, will be paid to the miner if he successfully mines what we call a “desirable block”: a block that will deliver a random number in a set A, chosen by the malicious user. Let also $\lambda$ be the average rate of incoming blocks and q the probability of a randomly generated number being an element of A, i.e., the measure of the set of desirable results for the malicious user. Finally, let T be the expected amount of time needed for the VDF calculations. The moment a miner finds a block that can be accepted by the network, he faces the decision of broadcasting it before checking the VDF, or calculating the VDF before broadcasting. If he decides to check the VDF before broadcasting, he might start another attempt to find a block rightaway.

First, we calculate the expected absolute payoff for the first and second options, called ${\mathbb{E}}_1$ and ${\mathbb{E}}_2$, respectively. ${\mathbb{E}}_1$ will be larger than B, since the miner might issue a desirable block by chance:

$${\mathbb{E}}_1=B+qP=B(1+nq)$$

(1)

On the other hand, if the miner chooses to calculate the VDF, he will receive the block reward and the prize P, but with a probability given by

$$\begin{array}{cc}\hfill {\mathbb{E}}_2=& (B+P)q\mathbb{P}\{\mathrm{no}\mathrm{other}\mathrm{node}\mathrm{finding}\mathrm{a}\mathrm{block}\mathrm{before}t=T\}\hfill \\ \hfill & +(B+P)(1-q)\mathbb{P}\left\{\mathrm{successfully}\mathrm{mining}\mathrm{a}\mathrm{desirable}\mathrm{block}\mathrm{in}\mathrm{another}\mathrm{attempt}\right\}\hfill \\ \hfill =& B(1+n)qexp(-(1-p\left)\lambda T\right)\hfill \\ \hfill & +B(1+n)(1-q)\sum _{i=1}^{\infty }\mathbb{P}\left\{\mathrm{successfully}\mathrm{mining}\mathrm{a}\mathrm{desirable}\mathrm{block}\mathrm{after}i\mathrm{attempts}\right\}\hfill \end{array}$$

(2)

The probabilities inside the summation, in the last equation, can be calculated as the product of the probability of finding a desirable block after i attempts (that will be a geometric distribution with probability of success q) and the probability of finding and checking i blocks before the rest of the network mines one.

Considering

$$P\left\{\mathrm{attacker}\mathrm{finding}\mathrm{and}\mathrm{analyzing}i\mathrm{blocks}\mathrm{before}\mathrm{another}\mathrm{node}\mathrm{mining}\mathrm{one}\right\}$$

$$={\int }_{t=0}^{\infty }p\lambda exp(-p\lambda t)\frac{{\left(p\lambda t\right)}^{i-1}}{(i-1)!}exp(-(1-p)\lambda (t+T))dt$$

$$=\frac{{\left(p\lambda \right)}^{i}exp(-(1-p)\lambda T)}{(i-1)!}{\int }_{t=0}^{\infty }exp(-\lambda t)t^{i-1}$$

$$=\frac{{\left(p\lambda \right)}^{n}exp(-(1-p)\lambda T)}{(i-1)!}{\lambda }^{-i}(i-1)!$$

$$=p^{i}exp(-(1-p)\lambda T)$$

it follows that

$$\begin{array}{cc}\hfill {\mathbb{E}}_2=& B(1+n)\left[qexp(-(1-p)\lambda T)+(1-q)\sum _{i=1}^{\infty }q{(1-q)}^{i-1}{p}^{i}exp(-(1-p)\lambda T)\right]\hfill \\ \hfill =& B(1+n)exp(-(1-p)\lambda T)\left(q+\frac{(1-q)pq}{1-p+pq}\right)\hfill \end{array}$$

(3)

Finally, in order to make accepting the bribe not lucrative, we must have ${\mathbb{E}}_1>{\mathbb{E}}_2$, i.e.:

$$\lambda T>\frac{1}{1-p}log\left(\frac{1+n}{1+nq}\frac{q}{1-p+pq}\right)$$

(4)

Since for every $n>0$ we have $\frac{1+n}{1+nq}<\frac{1}{q}$, if we choose $\lambda T^{*}=\frac{1}{1-p}log\left(\frac{1}{q}\frac{q}{1-p+pq}\right)$, we guarantee that the attack will not be lucrative for any bribe $P=nB$. Also, since it can be assumed that $p<1/2$, a value $\lambda T^{*}=2log\left(\frac{2}{1+q}\right)<2log\left(2\right)$ will be high enough to prevent an attack for any bribe and any acceptable value of p.

3. Conclusions and Final Remarks

We formalized a simple and effective protocol to generate on demand pseudo random numbers, in a fully auditable way. We have demonstrated that none of the involved parts has enough financial incentives to try to affect the random number outcome: the part that issues the transaction lacks this power, since it does not have any control on the block header; and the miners do not have enough financial incentives to collude with an attacker, provided a suitable Verifiable Delay Function is applied.

The essentially decentralized, yet completely traceable and auditable nature of the protocol presented in this article, makes the resulting randomization process eminently reliable without recourse of blind trust in any central authority. The authors believe the adoption of such a protocol by the the Brazilian Supreme Court (STF), as recommended in [6], would significantly increase public confidence in the judicial system and be a contributing factor for political and social stability. A simple prototype of the randomization tool described in this article is available in the supplementary materials; it is not intended to be used in a full-fledged application, but only to provide a working example of the key procedures.