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

Moved to w3f/research in d3f0f632ed

Browse Source
This commit is contained in:
Jeff Burdges
2019-02-08 18:19:38 +01:00
parent e73569b23d
commit 93a319ec4d
2 changed files with 0 additions and 252 deletions
Download Patch File Download Diff File Expand all files Collapse all files
NetRNGs.md
-213
View File
@@ -1,213 +0,0 @@
# Network randomness schemes
These are our reviews of collaborative random number generators (RNGs)
or other networked randomness schemes
## Collaborative PRNGs
There are several true collaborative PRNG schemes in which all participants obtain the same output and can then run arbitrary randomised algorithms with identical seeds and results. As a result, we can employ more randomised algorithms that produce exact outputs like permutations of nodes, or require more complexity or tweaking.
### Verifiable Delay Functions (VDFs)
VDFs employ a slow non-parallelizable computation and provide a PRNG with a proof that some time period elapsed between when seeds were available and when the output was available. Right now, the best ideas for this want a group of unknown order, like maybe the class group of an imaginary quadratic number field.
https://crypto.stanford.edu/~dabo/pubs/papers/VDFsurvey.pdf
Justin Drake with Etherium research is very interested in VDFs because VDFs provide a collaborative PRNG in which one honest party suffices to produce a secure random number. We currently fear that VDFs deployment strategies have an excessively small security margin. An attacker might for example compute the VDF 10x faster to gains the random number early or even bias it. ASICS might be achieve this. At the extreme, [superconducting computing](https://en.wikipedia.org/wiki/Superconducting_computing) can achieve speeds of 100 GHz with circuits consisting of 10^5 Josephson junctions. You’d need a rather large time window to use a VDFs, and you’d need an even larger time window to handle the highly optimised VDF node equivocating.
### DFinity style VSS + VRF
We might not fully understand the VRF's roll here because the public
key correctness ultimately depends on the VSS based DKG and this
depends upon validator nodes raising accusations. We believe they
do this so that one DKG yields numerous VRF outputs, maybe because
the DKG is considerably more expensive, or not amenable to some
optimisations.
Almost all the pure cryptography implementation work consists of
following the DKG design in
_Secure Distributed Key Generation for Discrete-Log Based Cryptosystems_
by Rosario Gennaro, Stanisl􏱑aw Jarecki, Hugo Krawczyk, and Tal Rabin.
There is no actual production of a BLS signature produced there
however, so one should also look over section 7 of
_DFINITY Technology Overview Series Consensus System_ (Rev. 1)
by Timo Hanke, Mahnush Movahedi and Dominic Williams.
### Schoenmakers PVSS ala EPFL
"A publicly verifiable secret sharing (PVSS) scheme is a verifiable
secret sharing scheme with the property that the validity of the
shares distributed by the dealer can be verified by any party; hence
verification is not limited to the respective participants receiving
the shares."
An implementation would follow
_A Simple Publicly Verifiable Secret Sharing Scheme and its Application to Electronic Voting_
by Berry Schoenmakers,
as well as the DEDIS group at EPFL's Kyber suite written in Go:
https://github.com/dedis/kyber/tree/master/share
As written, the resulting secret is a random curve point, not a BLS
signature or private scalar. In comparison, DFinity's VSS + VRF
scheme produces a BLS signature, or even shared private scalar.
If the message is known in advance, then PVSS could seemingly
produce a BLS signature, although I need to think more about the
timing of protocol messages in doing so. If correct, this might
answer an important open question of DFinity's Timo Hanke, but
maybe not the answer he wants, as PVSS probably need to be run for
every signature produced, and DFinity's solution runs the DFG
infrequently.
Schoenmakers' PVSS avoids pairings but incorporates two rounds of
DLEQ proofs. These are complex operations, but might prove faster
than DFinity's VSS + VRF scheme, due to pairing based curve.
Also, ee need to verify that a type III pairing does not make the
protocol insecure and worry if components like the DLEQ proofs need
to change for my proposed PVSS + VCF variant. We must also consider
if any attacks can influence the public key.
## Specific random results
There are various schemes that produce specific random results
without actually producing a shared random value, but the result
are necessarily inexact and may need to be simpler or complicate
the consensus process.
These are mostly applications of verifiable random functions (VRFs),
which normally consist of applying a random oracle to the output of
a deterministic signature scheme applied to a shared value.
### Competitive VRFs
It's hard to apply VRFs competitively because attackers may delay
revealing their results, pretend not to see other's results, use
network flood attacks on winners, etc., so roughly the same problems
as simple commit and reveal.
### Ouroboros style "slot filling" VRFs
We avoid the competitive VRFs issues by using VRFs to fill slots
far more numerous than actual winning positions, say slots for block
production. There remain related issues with timing and when block
producers may skip earlier ones, which require more thought, and may
impact other things.
Security proofs exist, but tricky UC ones.
See Ouroboros paper #2
TODO: link
### Alistair's VRF leveraging random block selection
If we have a network randomness scheme picking block producers or
many another specific random results, then they could include a VRF
of the block number. As above, each node's only options are to
produce a block or not produce a block, so whatever alternatives
nodes they have who could produce a block give them influence over
the random number, but another user might produce a block first
scooping them.
Although not a collaborative PRNG per se, this produces random
numbers we might argue can be used like collaboratively produced
ones. Alistair says we cannot wait for finalisation here, but
disagreement results from multiple chains running in parallel.
### Algorand
Algorand has similarities to Tindermint, but selects validators
randomly from a pool, instead of using a fixed set, and does a
Byzantine agreement for each block. All nodes produce possible
blocks and a VRFs helps choose among them.
### RANDAO
Nodes commit to a hash onion and use the layers like a local VRF,
revealing one layer whenever doing so allows them to produce a block.
RANDAO is less outright computation than local VRFs for verifiers.
Also VRFs on different seeds do not aggregate well. RANDAO requires
verifiers verify update records for all other verifiers though,
which sounds more fragile than a VRF, meaning more sensitive code.
RANDAO producers may take a performance hit from storing intermediate
hashes, but if so Merkle trees give another similar option.
We think orphan blocks prevents us from slashing nodes for skipping
their turn, so either all nodes must have a RANDAO contribution for
each slot, or else nodes can increases their control over their
revealed values by skipping blocks.
https://ethresear.ch/t/rng-exploitability-analysis-assuming-pure-randao-based-main-chain/1825/4
https://ethresear.ch/t/randao-beacon-exploitability-analysis-round-2/1980
https://ethresear.ch/t/making-the-randao-less-influenceable-using-a-random-1-bit-clock/2566
# Network randomness uses
## Validator group assignments
We think local VRFs, either competitive or slot filling, do not
produce an even enough distribution and do not permit us to
allocate stake well across validators. So we want a real
collaborative PRNGs here.
Relevant questions:
- Can we produce a security proof for Alistair's VRF leveraging?
- How does Ouroboros handle similar situations?
- Is PVSS + VRF better?
## Finality gadget leader assignments
Alistair thinks rotation solves everything currently.
An alternative is Algorand's local VRF.
## Block production leader assignments
Etherium and Ouroboros handle this with RANDAO and their "slot
filling" VRF, respectively. We think Ouroboros's VRF has
significant implementation advantages, but we may reevaluate
after we take performance more into consideration.
## Fishermen incentivization
We envision creating a small about of random missbehavior so that
fishermen always have some missbehavior to catch. We should do this
with local VRFs so that nobody except the missbehaving node knows in
advance, but the levels should be low enough that such missbehavior
cannot accumulate.
Are there other fishermen related uses? Rob mentioned ordering
fishermen, which sounds problematic.
# Timing
TODO: Comment on relative block time vs. more absolute synced clock times.
ability to have timeout that depend on network activity? (relative absolute time??)
but think about the network conditions
We seemingly need a bound on clock skew between validators, which
we must enforce using the peer-to-peer network.
### RANDAO
We noticed possible timing issues with RANDAO that impact most other
schemes: An attacker can manipulate the timing of their blocks to
help maintain a forked chain. TODO: Add details.
### Ouroboros rate metering
Ouroboros paper 3 describes minimum rate requirement for protection
against long term attacks. The idea goes that a long-term attacker
starts with relatively little stake, so initially they produce blocks
slower than the overall network, but as their stake increases this
rate goes up. Ouroboros wants to prevent this initial slow start,
but this requires
### Ideas
Unavailability game
Time or relative time signing
bridge/swap.md
-39
View File
@@ -1,39 +0,0 @@
UPDATE: This discussion of swaps implemented with ZKCP might prove relevant to building bridges, but a bridge itself exists to support clients who cannot track chains.
We envision a bridge that manages security for atomic swaps by observing the bitcoin blockchain, but does not itself hold bitcoins, and only holds dots as stake. Aside from the bridge nodes and polkadot infrastructure, we have two customers, Paula who trade dots and Brit who trades bitcoin, although atomicity could generalise either to a group.
I'll give a handy wavy sketch that should be informed by going over ZKCP literature:
Step 0. Paula's offer of Dot and Brit's offer of BTC get matched via some trading network, placing them into communication. I donno if MPC helps here.
Step 1. Paula and Brit negotiate their transaction:
- Paula provides Brit with her BTC wallet hash and her bridge supported test for considering the transaction settled on bitcoin.
- If Brits consider the test reasonable, then Brit secretly crafts but does not publish her BTC payment x to Paula, and gives Paula the hash of x.
Step 2. Paula submits a bridge parachain transaction y to Brit that registers the trade with the bridge and time locks the funds she wishes to trade. Registration reveals the test, the Dot and BTC amounts, Paula's BTC wallet hash, and the BTC transaction hash.
Step 3. After the parachain transaction is finalised, Brit submits her BTC transaction x, or maybe gives it to Paula so she can submit it. If Brit does not do so fast enough then Paula's time lock expires.
Step 4. The bridges publish and finalize a transaction signing the release of funds from y to Brit, after recognising that x matches its hash commitment, sends the correct BTC amount to Paula's BTC hash, and has persisted long enough to past the test.
Importantly, we use ordinary parachain finalization logic for the "threshold" signature by the bridges in steps 3 and 4, which should be a simple aggregate signature, not a true threshold signature, which anonymises the signers, so that the individual bridges can be held accountable.
We could improve perceived latency for Brit, and maybe simplify client code, by having Brit threshold encrypt x to the bridges in step 2, so the bridges carry out step 3 after finalising. We expect polkadot to be fast though, so imho Brit should prefer the latency and simpler security model above. Also I'd expect the above scheme simplifies bridge code far more than alternative schemes simplify client code.
In this design, Brit needs to trust the bridges will eventually unlock Paula's transaction y and Paula needs to trust that the bridges will wait until the test for Brit's transaction x checks out before unlicking her transaction y.
Attack 1. Bridges screw Brit. At minimum Brit can appeal to governance to manually slash the bridges. We could automatically slash the bridges based on evidence from bitcoin, but we cannot assess network conditions automatically and someone must assess this evidence, and worse hostil bitcoin miners could attack bridges via slashing. We could make Brit produce a zero-knowledge or WI proof that her transaction worse as desired, but either bridges must still assess bitcoin, or else "dumb" tests much be hard wired into the parachain, like show 12 bitcoin blocks with however many zeros, which sounds game-able by bitcoin miners.
Attack 2. Bridges screw Paula. We could make Brit actually publish a time locked contract x' on bitcoin that requires revealing a hash x'' and the bridges merely wait until passing the bitcoin test before revealing x''. We still have a fair exchange problem in how long x' and y lock funds, which malicious bridges may exploit. If Brit submits a time locked transaction this way, then ultimately the swap requires two BTC transactions, which sounds expensive, and may add latency for Paula.