@@ -19,40 +19,69 @@ open import Ledger.Core.Specification.Crypto hiding (CryptoStructure)
1919
2020## Leios Voting Crypto
2121
22- In Leios the committee consists of a certain number of pools with the largest
23- stake, with ties broken by pool id. Therefore the ` KeyHash ` {AgdaDatatype} type
24- carries a strict total order, the implementation's byte-wise comparison.
25- (See the [ Epoch Boundary section] of [ CIP-0164] .)
22+ Leios ([ CIP-164] ) adds a second signature scheme beside the payment scheme
23+ above: an epoch's voting committee signs endorser-block announcements with
24+ registered voting keys, and a certificate compresses a quorum of votes into
25+ one aggregate signature. The scheme enters the specification abstractly and
26+ verification-only, like ` isSigned ` {.AgdaField} above; the implementation
27+ instantiates it with BLS12-381 MinSig, 96-byte verification keys with 48-byte
28+ signatures and proofs of possession. It lives here, beside the payment
29+ scheme, so other protocol extensions that aggregate votes (Peras) can share
30+ it.
2631
2732``` agda
2833record CryptoStructure : Type₁ where
29- field pkk : PKKScheme
34+ field
35+ pkk : PKKScheme
3036
3137 open PKKScheme pkk public
3238
33- field ⦃ khs ⦄ : isHashableSet VKey
34- ScriptHash : Type; ⦃ DecEq-ScriptHash ⦄ : DecEq ScriptHash ; ⦃ Show-ScriptHash ⦄ : Show ScriptHash
39+ field
40+ ScriptHash : Type
41+ VRF : Type
42+ BlsVKey BlsSig BlsPoP : Type
43+ isValidPoP : BlsVKey → BlsPoP → Type
44+ isSignedBy : BlsVKey → Ser → BlsSig → Type
45+ isSignedByAggregate : List BlsVKey → Ser → BlsSig → Type
46+ ```
47+
48+ ` isValidPoP ` {.AgdaField} checks a key's * proof of possession* , required with
49+ every registration because aggregation is otherwise open to rogue-key attacks
50+ (a key crafted relative to others' keys, making an aggregate appear to include
51+ voters who never signed). ` isSignedBy ` {.AgdaField} verifies a single vote,
52+ the meaning by which consensus filters votes before aggregation;
53+ ` isSignedByAggregate ` {.AgdaField} verifies a certificate's aggregate signature
54+ against its signers' keys. Only verification enters the rules: the ledger
55+ never creates votes or certificates, so the scheme has no signing side and no
56+ correctness law relating one.
57+
58+ <!--
59+ ```agda
60+ field ⦃ khs ⦄ : isHashableSet VKey
61+ ⦃ DecEq-ScriptHash ⦄ : DecEq ScriptHash
62+ ⦃ Show-ScriptHash ⦄ : Show ScriptHash
63+ ⦃ DecEq-VRF ⦄ : DecEq VRF
64+ ⦃ DecEq-BlsVKey ⦄ : DecEq BlsVKey
65+ ⦃ DecEq-BlsSig ⦄ : DecEq BlsSig
66+ ⦃ DecEq-BlsPoP ⦄ : DecEq BlsPoP
67+ ⦃ Dec-isValidPoP ⦄ : isValidPoP ⁇²
68+ ⦃ Dec-isSignedByAggregate ⦄ : isSignedByAggregate ⁇³
3569
3670 open isHashableSet khs renaming (THash to KeyHash) hiding (DecEq-T) public
71+ ```
72+ -->
3773
38- field VRF : Type
39- ⦃ DecEq-VRF ⦄ : DecEq VRF
74+ In Leios the committee consists of a certain number of pools with the largest
75+ stake, with ties broken by pool id. Therefore the ` KeyHash ` {AgdaDatatype} type
76+ carries a strict total order, ` _<ᵏʰ_ ` {.AgdaField}, analogous to the
77+ implementation's byte-wise comparison.
78+ (See the [ Epoch Boundary section] of [ CIP-0164] .)
4079
80+ ``` agda
4181 -- Byte-wise ascending order on key hashes; the Leios committee tie-break.
4282 field _<ᵏʰ_ : KeyHash → KeyHash → Type
4383 <ᵏʰ-isSTO : IsStrictTotalOrder _≡_ _<ᵏʰ_
44- ⦃ Dec-<ᵏʰ ⦄ : _<ᵏʰ_ ⁇²
45-
46- -- BLS12-381 signature scheme used for Leios voting (CIP-0164).
47- field BlsVKey BlsSig BlsPoP : Type
48- isValidPoP : BlsVKey → BlsPoP → Type
49- isSignedByAggregate : List BlsVKey → Ser → BlsSig → Type
50- ⦃ DecEq-BlsVKey ⦄ : DecEq BlsVKey
51- ⦃ DecEq-BlsSig ⦄ : DecEq BlsSig
52- ⦃ DecEq-BlsPoP ⦄ : DecEq BlsPoP
53- ⦃ Dec-isValidPoP ⦄ : isValidPoP ⁇²
54- ⦃ Dec-isSignedByAggregate ⦄ : isSignedByAggregate ⁇³
55-
84+ ⦃ Dec-<ᵏʰ ⦄ : _<ᵏʰ_ ⁇²
5685```
5786
5887[ CIP-164 ] : https://github.com/cardano-foundation/CIPs/blob/master/CIP-0164/README.md
0 commit comments