How does ADKG work?
Arcana employs ADKG algorithms to securely generate key shares, allowing authenticated users to easily sign Web3 blockchain transactions. Our implementation follows the Practical Asynchronous Distributed Key Generation protocol, providing non-custodial key pairs for SDK users to sign transactions. This approach guarantees security and robustness by preventing any single node from accessing a user's key.
How is ADKG better?
ADKG improves upon Arcana's previous DKG protocol by eliminating the need for a trusted dealer or third party, addressing issues such as key exposure and automating share regeneration. Unlike synchronous DKG protocols, ADKG is resilient to malicious adversaries and operates effectively in asynchronous network conditions.
The ADKG protocol works under the assumption that in an asynchronous network of
n ≥ 3t + 1 nodes, where at most
t nodes could be malicious.
The protocol can achieve an expected communication cost of O(
κn\(^3\) ) and terminates in expected O(log n) rounds. Here
κ is the security parameter. For example, if a collision-resistant hash function is used, in that case,
κ denotes the size of the hash function's output.
ADKG requires a set of at least 4 connected nodes at a minimum for accommodating a maximum of 1 malicious node.
At a very high level, the protocol requires each node to independently generate secrets and then share a part of that secret with the other nodes. Each node then shares a proposed set of key shares with other nodes. Asynchronous Binary Agreement (ABA) voting is done by the nodes for each proposed set. Only the accepted and agreed-upon set is used to derive the key shares and then those key shares are combined to arrive at the final key pair. None of the nodes have full access to the secret key.
There are four key phases in the ADKG protocol:
- Asynchronous Complete Secret Sharing (ACSS)
- Keyset Proposal Broadcast Phase
- Asynchronous Binary Agreement (ABA)
- Key Derivation Phase
For more details on each of these ADKG phases, see here