pezkuwichain/consensus
1
0
Fork 0
mirror of https://github.com/pezkuwichain/consensus.git synced 2026-04-22 07:58:05 +00:00
Code Issues Packages Projects Releases Wiki Activity

Put slothful reduction in the right place

Browse Source
This commit is contained in:
Jeff Burdges
2019-01-07 22:31:30 +01:00
parent fc5ac61737
commit 26249d7013
1 changed files with 3 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
keys/3-session.md
+3 -4
View File
@@ -12,9 +12,11 @@ A session public key should consist of roughly four public keys types:
We know signers can easily batch numerous VRF outputs into a single proof with these, ala CloudFlare's Privacy Pass. If we employ these VRFs for block production then signers could periodically publish a "sync digest" that consolidated thousands of their past block production VRFs into a single check, which improves syncing speed. There is also an avenue to batch verify these VRFs by multiply signers, but it requires enlarging the VRF output and proofs from from 96 to 128 bytes.
- Small curve of BLS12-381 (48 byte public keys, 96 byte signatures)
Aggregated signatures verify can faster when using this key if the signer set for a particular message is large but irregularly composed, as in GRANDPA. Actual signatures are slower than the opposite orientation, and non-constant time extension field arithmetic makes them even slower, or more risky. Aggregating signatures on the same message like this incurs malleability risks too. We also envision using this scheme in some fishermen schemes.
We should consider [slothful reduction](https://eprint.iacr.org/2017/437) as discussed in https://github.com/zkcrypto/pairing/issues/98 for these eventually, but initially key splitting should provide solid protection against timing attacks, but with even slower signature speed.
- Big curve of BLS12-381 (96 bytes public keys, 48 byte signatures)
Aggregated signatures in which we verify many messages by the same signer verify considerably faster when using this key. We might use these for block production VRFs because they aggregating over the same signer sounds useful for syncing. Initially, we envisioned aggregation being useful for some VRF non-winner proofs designs, but our new non-winner proof design mostly avoids this requirement. Right now, we favor the Ristretto Schnorr VRF for block production because individual instances verify faster and it provides rather extreme batching over the same signer already.
@@ -30,6 +32,3 @@ A session public key record has a prefix consisting of the above three keys, alo
We include the recent block hash in the certificate, so that if the chain were trusted for proofs-of-possession then attackers cannot place rogue keys that attack honestly created session keys created after their fork. We recommend against trusting the chain for proofs-of-possession however because including some recent block hash like this only helps against longer range attacks.
We still lack any wonderful aggregation strategy for block production VRFs, so they may default to Ristretto Schnorr VRFs. In this case, the Ristretto Schnorr session key component living longer also help minimize attacks on our random beacon.
We should consider [slothful reduction](https://eprint.iacr.org/2017/437) as discussed in https://github.com/zkcrypto/pairing/issues/98 since GRANDPA uses the small curve key form.