WARNING: This codebase is a proof-of-concept demonstration developed rapidly with AI assistance in less than half a day. It has NOT undergone comprehensive security auditing, formal verification, or extensive testing required for production cryptographic systems.
DO NOT USE THIS CODE IN PRODUCTION ENVIRONMENTS where real assets, private keys, or sensitive data are at stake.
Intended Use: Educational purposes, research, and demonstrating technical feasibility of DKG concepts with OrbitDB.
For Production Systems: Engage qualified cryptographic engineers, conduct thorough security audits, and implement industry-standard protocols with extensive testing.
This project demonstrates how Distributed Key Generation (DKG) can be coordinated using OrbitDB, a decentralized, peer-to-peer database. It showcases how multiple participants can collaboratively generate cryptographic keys and coordinate threshold signatures without relying on a central server.
Distributed Key Generation is a cryptographic protocol that allows multiple parties to jointly generate a shared cryptographic key without any single party knowing the complete key. This is crucial for:
- Multi-signature wallets where multiple parties must approve transactions
- Threshold cryptography where a subset of participants can sign transactions
- Decentralized governance systems
- Multi-party computation scenarios
OrbitDB provides the perfect infrastructure for DKG coordination because it offers:
- Decentralized coordination - No central server required
- Automatic replication - All participants see the same data
- Event-driven architecture - Participants can react to protocol steps
- Immutable audit trail - All DKG steps are permanently recorded
- Browser & Mobile compatible - Works in web browsers and mobile apps
├── test/
│ ├── dkg.test.js # Basic DKG simulation
│ ├── simple-real-dkg.test.js # Real Shamir's Secret Sharing math
│ ├── orbitdb-dkg.test.js # DKG coordination with OrbitDB
│ ├── orbitdb-replication.test.js # Official OrbitDB replication test
│ ├── real-dkg-orbitdb.test.js # Complete DKG protocol (advanced)
│ ├── chainlink-vrf-dkg.test.js # Mock Chainlink VRF integration
│ ├── real-chainlink-vrf-dkg.test.js # REAL Chainlink VRF on Sepolia
│ └── utils/ # OrbitDB utility functions
├── package.json
└── README.md
This test demonstrates the core cryptographic concepts of DKG:
// 1. Generate participants with individual keys
const participants = Array(3).fill().map(() => ({
privateKey: ec.genKeyPair().getPrivate().toString('hex'),
publicKey: null,
shares: []
}));
// 2. Mock Shamir's Secret Sharing
// 3. Combine shares to reconstruct group key
// 4. Sign transaction with group key
// 5. Verify signatureWhat it shows:
- Key generation for multiple participants
- Secret sharing simulation (simplified)
- Group key reconstruction
- Collaborative transaction signing
- Signature verification
This test demonstrates actual mathematical foundations of Shamir's Secret Sharing:
// Real polynomial: f(x) = secret + random*x + random*x^2
const shares = [
{ x: 1, y: evaluatePolynomial(1) },
{ x: 2, y: evaluatePolynomial(2) },
{ x: 3, y: evaluatePolynomial(3) }
];
// Lagrange interpolation to reconstruct f(0) = secret
function reconstructSecret(shares) {
// Mathematical reconstruction using any threshold number of shares
}What it demonstrates:
- Real polynomial evaluation with proper mathematics
- Lagrange interpolation for secret reconstruction
- Threshold property - any k shares can reconstruct the secret
- Security property - k-1 shares reveal nothing about the secret
This test demonstrates how OrbitDB coordinates the DKG protocol between distributed participants:
// Participant 1 creates database and adds commitment
db1 = await orbitdb1.open('dkg-commitments', {
AccessController: IPFSAccessController({
write: [orbitdb1.identity.id, orbitdb2.identity.id] // Both can write
})
});
await db1.add(commitment1);
// Participant 2 joins and adds their commitment
db2 = await orbitdb2.open(db1.address);
await db2.add(commitment2);
// Both participants see both commitments through automatic replication// Store partial signatures from each participant
await db1.add({
type: 'partial_signature',
participantId: 'participant1',
signature: partialSig1.toDER('hex')
});
// Automatic replication ensures all participants see all partial signaturesWhat it demonstrates:
- Real distributed coordination - Each participant runs their own OrbitDB instance
- Access control - Proper permissions for multi-party writing
- Automatic replication - Changes propagate between all participants
- Event-driven protocol - Participants react to each other's actions
- Audit trail - All protocol steps are immutably recorded
These tests demonstrate integration with Chainlink VRF for verifiable randomness in DKG:
// Mock VRF for development
class MockChainlinkVRF {
async requestRandomness() {
return { requestId: '123', randomValue: '0xabc...', verified: true };
}
}
// Real VRF connecting to Sepolia testnet
class RealChainlinkVRF {
async getLatestVRFRandomness() {
// Searches Sepolia for actual VRF fulfillments
const events = await vrfCoordinator.queryFilter(fulfillmentFilter);
return realBlockchainRandomness;
}
}What it demonstrates:
- Verifiable randomness - Using Chainlink VRF for polynomial generation
- Real blockchain integration - Connects to Ethereum Sepolia testnet
- Production-ready randomness - Cryptographically secure entropy source
- On-chain verification - All randomness is verifiable on Ethereum
Answer: NO! Our implementation proves it's completely decentralized:
// Each participant independently:
1. Generates their own random polynomial
2. Creates shares for all participants
3. Distributes shares via OrbitDB P2P network
4. Collects shares from others via OrbitDB
5. Verifies shares using public commitments
6. Participates in threshold operationsOrbitDB provides only:
- Message passing (like a decentralized bulletin board)
- Eventual consistency (everyone sees the same data)
- No orchestration or coordination logic
Mock Implementation (dkg.test.js):
// Just takes first 10 characters - NOT cryptographically secure!
p2.shares.push(p.privateKey.slice(0, 10)); Real Implementation (simple-real-dkg.test.js):
// Proper polynomial evaluation: f(x) = secret + random*x + random*x^2
const shareValue = polynomial[0] + polynomial[1]*x + polynomial[2]*x*x;
// Lagrange interpolation for reconstruction
const secret = shares.reduce((sum, share, i) => {
return sum + share.y * lagrangeBasis(share.x, otherXValues);
}, 0);Key Differences:
- ✅ Mathematical foundation - Real polynomial arithmetic
- ✅ Threshold security - k-1 shares reveal nothing about secret
- ✅ Cryptographic soundness - Provably secure reconstruction
- ✅ Verifiable shares - Public commitments enable verification
"If secret shares are stored on a public ledger like OrbitDB/IPFS, does this create a security vulnerability for private key reconstruction?"
Answer: NO - This is cryptographically secure by design! Here's why:
// In a 2-of-3 threshold scheme:
const shares = [
{ participant: 'Alice', x: 1, y: share1 }, // Public on OrbitDB
{ participant: 'Bob', x: 2, y: share2 }, // Public on OrbitDB
{ participant: 'Carol', x: 3, y: share3 } // Public on OrbitDB
];
// ANY 2 shares can reconstruct the secret
// But 1 share reveals ZERO information about the secret❌ NEVER stored publicly:
// Each participant's individual secret shares FROM others
participant1.receivedShares = [
{ from: 'Bob', value: secretShare_Bob_to_Alice }, // PRIVATE
{ from: 'Carol', value: secretShare_Carol_to_Alice } // PRIVATE
];✅ Safe to store publicly:
// Only polynomial commitments (public keys) are broadcast
await orbitdb.add({
type: 'polynomial_commitment',
from: 'Alice',
commitments: [
'G^coeff0', // Public key = G * coefficient (NOT the coefficient itself)
'G^coeff1', // These allow verification but reveal no secrets
'G^coeff2'
]
});-
Public commitments are cryptographically safe - They're elliptic curve points (public keys) that allow verification but cannot be reversed to find private coefficients
-
Secret shares are transmitted privately - Each participant encrypts shares using recipients' public keys before sending
-
Threshold property holds - Even if an attacker sees all public commitments, they cannot reconstruct the private key without collecting enough private shares
-
Information-theoretic security - With k-1 shares, the secret could be ANY value with equal probability
// Attacker sees all public data on OrbitDB:
const publicData = {
commitments_Alice: ['G^a0', 'G^a1', 'G^a2'], // Alice's polynomial commitments
commitments_Bob: ['G^b0', 'G^b1', 'G^b2'], // Bob's polynomial commitments
commitments_Carol: ['G^c0', 'G^c1', 'G^c2'] // Carol's polynomial commitments
};
// ❌ ATTACK FAILS: Attacker cannot:
// 1. Reverse G^coefficient to find coefficient (discrete log problem)
// 2. Access private shares (encrypted point-to-point)
// 3. Reconstruct without threshold number of shares✅ Conclusion: Storing polynomial commitments on public ledgers is not only safe - it's essential for verification and the core security model of verifiable secret sharing!
Alice (Browser) ←→ Bob (Browser) ←→ Charlie (Mobile)
↘ ↓ ↙
OrbitDB Network (P2P)
- No central server required for wallet coordination
- Real-time synchronization of signing requests
- Cross-platform support (web + mobile)
- Offline resilience - participants can catch up when reconnected
- Proposal coordination through OrbitDB
- Multi-party approval processes
- Transparent voting with immutable records
- Global accessibility through P2P networks
Mobile App A ←→ Mobile App B ←→ Web Wallet
↘ ↓ ↙
IPFS/OrbitDB Network
- Direct peer-to-peer coordination
- No backend infrastructure costs
- Censorship resistant operations
- Global accessibility without geographic restrictions
- Device key management without central authorities
- Distributed firmware signing
- Secure device onboarding
- Resilient network coordination
- No single points of failure
- No server infrastructure costs
- Censorship resistant
- Global accessibility
- Runs entirely in JavaScript
- No plugins or extensions required
- Cross-platform compatibility
- Real-time peer-to-peer communication
- Industry-standard elliptic curve cryptography
- Verifiable multi-party protocols
- Immutable audit trails
- Identity-based access control
- Modern JavaScript/ES6+ syntax
- Event-driven architecture
- Comprehensive test coverage
- Well-documented APIs
- Node.js 22+ (required for OrbitDB v3)
- npm
# Clone and setup
git clone <this-repo>
cd dkg-test-project
npm install
# Run all tests
npm test
# Run specific test suites
npm test -- --grep "DKG Test" # Basic DKG
npm test -- --grep "DKG and Transaction Signing" # OrbitDB coordination
npm test -- --grep "Replicating databases" # OrbitDB replication
npm test -- --grep "Mock Chainlink VRF" # Mock VRF integration
npm test -- --grep "Real Chainlink VRF" # Real VRF on Sepolia# Setup environment (optional - tests work without this)
cp .env.example .env
# Edit .env and add your Sepolia RPC URL:
# SEPOLIA_RPC_URL=https://eth-sepolia.g.alchemy.com/v2/your-keyNote: Real VRF tests connect to Ethereum Sepolia testnet. They work with the free Alchemy demo endpoint but you can add your own RPC URL for better reliability.
✓ DKG Test
✓ should generate shared key and sign transaction (146ms)
✓ DKG and Transaction Signing with OrbitDB
✓ should coordinate DKG commitments between participants (1440ms)
✓ should coordinate threshold signature creation (199ms)
✓ Replicating databases
✓ returns all entries in the replicated database (3945ms)
✓ returns all entries after recreating instances (363ms)
✓ pins all entries in the replicated database (114ms)
✓ Simple Real DKG Test
✓ should demonstrate basic polynomial evaluation
✓ should demonstrate Shamir secret sharing concept
8 passing (7s)
- OrbitDB v3 - Decentralized database
- Helia - IPFS implementation for JavaScript
- libp2p - Peer-to-peer networking
- Elliptic - Cryptographic operations
- Mocha/Chai - Testing framework
- Node.js 22+ - Runtime environment
- ✅ Real Shamir's Secret Sharing - Mathematical implementation with polynomial evaluation and Lagrange interpolation
- ✅ Decentralized coordination - No central coordinator needed
- ✅ Multi-participant DKG - 3 participants with 2-of-3 threshold
- ✅ Access control - Proper multi-party write permissions
- ✅ Event-driven protocol - Participants react to each other's actions
- ✅ Cryptographic verification - Share validation using public commitments
- ✅ Threshold signatures - Partial signature creation and coordination
- Advanced DKG protocols - Pedersen DKG, FROST, more sophisticated schemes
- BLS threshold signatures - More efficient signature aggregation
- Browser demo application - Interactive web interface
- Mobile app integration - React Native/Flutter examples
- Production optimizations - Performance improvements for large participant sets
- Real encryption - Replace demo encryption with proper ECIES
- Network resilience - Handle participant failures and recovery
- OrbitDB Documentation
- IPFS Documentation
- Distributed Key Generation (Wikipedia)
- Threshold Cryptography
This project demonstrates the potential of decentralized key generation. Contributions are welcome for:
- More sophisticated DKG implementations
- Browser/mobile demo applications
- Performance improvements
- Additional test scenarios
- Documentation enhancements
Built with ❤️ for the decentralized future