Additional Functionalities/Hybrids Used in the Security Proof

The security of Ouroboros Praos and Genesis is proven in a hybrid world with access to a multicast-network with upper bound on the message delay (unknown to the protocol), a global random oracle, a functional- ity that idealizes verifiable random functions (VRF), a functionality that idealizes key-evolving signature schemes (KES), and a setup functionality that distributes the initial tokens for proof-of-stake blockchains. The network, clock, RO, and initialization (genesis block), are assumed resources (see Section 2). On the other hand the VRF and KES functionalities are only hybrids used in the proof and are shown to be UC- realizable in [14] by concrete constructions. Therefore, hence they are only employed for simplicity in the proof (the overall security once instantiated by the constructions follows from the UC composition theorem). For completeness we include their definition below.

Verifiable Random Functions. The following functionalityFVRF capturing a verifiable random function

was introduced in [14].

FVRFinteracts with its set of registered partiesP(denoted byU1, . . . , U|P|) as follows:

– Key Generation.Upon receiving a message (KeyGen, sid) from a stakeholderUi, hand (KeyGen, sid, Ui) to the adversary. Upon receiving (VerificationKey, sid, Ui, v) from the adversary, ifUiis honest, verify thatvis unique, record the pair (Ui, v) and return (VerificationKey, sid, v) toUi. Initialize the tableT(v,·) to empty. – Malicious Key Generation.Upon receiving a message (KeyGen, sid, v) fromS, verify thatvhas not being

recorded before; in this case initialize tableT(v,·) to empty and record the pair (S, v).

– VRF Evaluation.Upon receiving a message (Eval, sid, m) fromUi, verify that some pair (Ui, v) is recorded. If not, then ignore the request. Then, if the valueT(v, m) is undefined, pick a random valueyfrom{0,1}`VRF and setT(v, m) = (y,∅). Then output (Evaluated, sid, y) toUi, whereyis such thatT(v, m) = (y, S) for someS.

– VRF Evaluation and Proof.Upon receiving a message (EvalProve, sid, m) fromUi, verify that some pair (Ui, v) is recorded. If not, then ignore the request. Else, send (EvalProve, sid, Ui, m) to the adversary. Upon receiving (EvalProve, sid, m, π) from the adversary, if valueT(v, m) is undefined, verify thatπis unique, pick a random valueyfrom{0,1}`VRF _{and setT(v, m) = (y,{π}). Else, ifT(v, m) = (y, S), set}

T(v, m) = (y, S∪ {π}). In any case, output (Evaluated, sid, y, π) toUi.

– Malicious VRF Evaluation.Upon receiving a message (Eval, sid, v, m, π) fromS for somev, do the following. First, if (S, v) is recorded andT(v, m) is undefined, then choose a random valueyfrom{0,1}`VRF and setT(v, m) = (y, S) and output (Evaluated, sid, y) toS. The same is performed in case (Ui, v) is recorded andUicorrupted. Else, ifT(v, m) = (y, S0) for someS06=∅, unionS toS0and output (Evaluated, sid, y) toS, else ignore the request.

– Verification.Upon receiving a message (Verify, sid, m, y, π, v0) from some partyP, send

(Verify, sid, m, y, π, v0) to the adversary. Upon receiving (Verified, sid, m, y, π, v0) from the adversary do: 1. Ifv0=vfor some (·, v) and the entryT(v, m) equals (y, S) withπ∈S, then setf= 1.

2. Else, ifv0=vfor some recorded pair of the form (·, v), but no entryT(v, m) of the form (y,{. . . , π, . . .}) is recorded, then setf= 0.

3. Else, initialize the tableT(v0,·) to empty, and setf= 0. Output (Verified, sid, m, y, π, f) toP.

Key-Evolving Signatures. Ouroboros Praos and Genesis also make use of a key-evolving signature scheme for signing blocks. In our treatment, we reflect the fact that signing a message is a local operation performed by a slot-leader and invoke the proposed formalism of Camenisch et al. [7] and declare signing request as restricting. This means that although activated to provide a signature, the adversary has to provide the answer, i.e. the signature string, to this request immediately (no other output to another protocol machine is allowed) and return the activation token back to the functionalityFKES. In this sense, the adversary and

the environment are calledresponsiveon signing queries.

The following formalization of key-evolving signatures was given in [14] and we adopt it slightly using the notation from [7, Section 6] to indicate that signing request have to be answered immediately: we indicate the request by prefixing the query with the keyword Respond (and hence this query is considered to be restricting).

FKESis parameterized by the total number of signature updatesT, interacting with a signerUS and registered parties inP(denoted byU1, . . . , U|P|) as follows:

– Key Generation.Upon receiving a message (KeyGen, sid, US) from a stakeholderUS, send

(KeyGen, sid, US) to the adversary. Upon receiving (VerificationKey, sid, US, v) from the adversary, send (VerificationKey, sid, v) toUS, record the triple (sid, US, v) and set counterkctr= 1.

– Sign and Update.Upon receiving a message (USign, sid, US, m, j) fromUS, verify that (sid, US, v) is recorded for somesidand thatkctr≤j≤T. If not, then ignore the request. Else, setkctr=j+ 1 and send (Respond,(Sign, sid, US, m, j)) to the adversary. Upon receiving (Signature, sid, US, m, j, σ) from the

adversary, verify that no entry (m, j, σ, v,0) is recorded. If it is, then output an error message toUSand halt. Else, send (Signature, sid, m, j, σ) toUS, and record the entry (m, j, σ, v,1).

– Signature Verification.Upon receiving a message (Verify, sid, m, j, σ, v0) from some stakeholderUido: 1. Ifv0=vand the entry (m, j, σ, v,1) is recorded, then setf= 1. (This condition guarantees completeness:

If the verification keyv0 is the registered one andσis a legitimately generated signature form, then the verification succeeds.)

2. Else, ifv0=v, the signer is not corrupted, and no entry (m, j, σ0, v,1) for anyσ0is recorded, then set

f= 0 and record the entry (m, j, σ, v,0). (This condition guarantees unforgeability: Ifv0is the registered one, the signer is not corrupted, and never signedm, then the verification fails.)

3. Else, if there is an entry (m, j, σ, v0, f0) recorded, then letf=f0. (This condition guarantees consistency: All verification requests with identical parameters will result in the same answer.)

4. Else, ifj <kctr, letf= 0 and record the entry (m, j, σ, v,0). Otherwise, ifj=kctr, hand

(Verify, sid, m, j, σ, v0) to the adversary. Upon receiving (Verified, sid, m, j, φ) from the adversary letf=φ

and record the entry (m, j, σ, v0, φ). (This condition guarantees that the adversary is only able to forge signatures under keys belonging to corrupted parties for time periods corresponding to the current or future slots.)

Output (Verified, sid, m, j, f) toUi.

Following the treatment of [7], the above functionality is realized by the same construction as in [14] because the simulator in that proof is responsive upon signing requests. We refer to [7] for more details.