Building a truly decentralized system with a distributed key generator
Any system that still requires a trusted entity to hold secrets is by nature not decentralized and suffers from a number of weaknesses including: single point of failure, susceptibility to Denial of Service attacks and, worst of all, having the secret stolen.
When we set out to build a new wireless network for machines at Helium, we had a number of design goals, key among them was to be truly decentralized in nature (other goals included permissionless, byzantine fault tolerance, useful proof of work/identity, high confirmed transaction rate, and transactions being censor resistant. For more details see the Helium whitepaper ).
Since centralized organizations dictate network cost and coverage, we decided a decentralized approach would be an effective way to provide broad, affordable wireless coverage for low power devices over long distances.
To build our decentralized machine network we chose to reward our community to provide wireless network coverage by hosting gateways.
To ensure community members provide valid coverage we created a new proof of work system we call Proof of Coverage. Proof of Coverage is the first proof protocol that leverages radio waves to validate network coverage and uses it to achieve consensus on a physical blockchain.
Community members providing coverage with gateways are rewarded with Helium utility tokens through mining and transaction fees from users of the network.
For a gateway to mine it needs to belong to the consensus group. Gateways can be elected to a consensus group by earning a score based on providing legitimate wireless coverage.
In Helium, this consensus group is temporarily assigned the task of running the consensus protocol to accept transactions and create blocks. The Helium consensus protocol needs to use threshold encryption for two tasks: to agree on transactions for the next block without censoring them and to provide a ‘ common coin ’ to break deadlocks in agreement. These kinds of threshold cryptosystems require a key to be shared between all members of the consensus group. Obviously a single party knowing the complete key is a big security hole, so that‘s why we needed to build a distributed key generator.
A distributed key generator is a way for a group of nodes to collectively agree on a public/private key pair without any single party knowing the private key (everyone knows the public key). This is actually very hard to achieve, but it relies on the fact that lagrange interpolated shares are homomorphic (in that operations can be performed on shares even without knowing the full value). For example, you can add A{share1}+B{share1} to get C{share1} that you can add to someone else’s C{share2} to get the full value of C (assuming A and B were split into 2 shares each).
I wanted to explain how a DKG works over pairing based keys in a way that should be understandable to a non-technical audience. I’ve played with a few metaphors, but the one that comes closest to how it actually works is based on pin-tumbler locks.
A pin tumbler lock works by the key pushing several ‘key pins’ to the right height such that the shear line between the key pin and the driver pin lines up with the shear line between the part of the lock that rotates (the core), and the part of the lock that is fixed:
When the correct key is inserted, all the pins line up so the shear line is clear and the core can rotate. If even one pin is wrong the lock won’t open.
Imagine with me, if you will, that I design a lock (with the corresponding key). I know how deep each cut for each pin on the key needs to be, but nobody else does. I give all my peers a share of the key pin information such that T+1 (T+1 is the threshold number of shares you need to reconstruct the original data) shares of the key pin information are enough to make a key that opens the lock. This is called secret sharing .
Now, this is fine if everyone trusts me to not leak my knowledge of the key. However, it is not sufficient if we want the property that nobody should know what the key looks like, and this is where a distributed key generator comes in.
In addition to ‘normal’ pin-tumbler locks, locks exist with a ‘cross key’ where the key has several blades, each one with a corresponding set of pin tumblers:
‘Cross Key’ Keys require two sets of combination blades
Now, imagine the key had N blades (where N is the number of people you are generating the key with). Each member generates the pin tumbler configuration for their blade and shares it as described above. Then once everyone has shared their blade and received their share of the other blades we now have a lock that nobody knows how to open, but T+1 members can combine their shares to construct a key to unlock it. This is distributed key generation.
Blades combining to form a newkey
In normal usage the full key is not usually recovered, rather holders of the key shares work together to perform operations in a threshold cryptosystem (eg. T+1 of N are required to participate in signing a message or T+1 of N parties are required to participate in decrypting a message).
Building a distributed key generator is hard but necessary work to achieve a more secure system, but these challenges excite the team knowing we’re building the world’s first decentralized machine network.
To follow progress of our dkg work, check out our github repo .
