TheFrozenFire
commented
1 year ago Here are some materials worth reading:
Shamir's Secret Sharing: https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing FROST: https://eprint.iacr.org/2020/852.pdf A Go implementation of FROST: https://github.com/taurusgroup/frost-ed25519
In my proof of concept, I used an older implementation of threshold ed25519 signatures that uses two rounds with coordination. FROST is a better target, as it supports one-round threshold signatures as long as all parties behave correctly, or two-round if there are misbehaving parties.
If you're unfamiliar with Schnorr threshold signatures, the basic concept is that Shamir's Secret Sharing is used to split a private key into a specified number of shares, which are then distributed to different parties. You can think of these shares as each being a percentage of the bits of the whole private key, which can be used separately to produce a signature, and then those separate signature "shares" can be combined to form a signature that is indistinguishable from one produced directly with the whole private key.
The big advantage with this approach is that it's transparent during signature verification. You don't need special code to check threshold signatures, you can use the standard signature verification process. This is particularly useful for threshold IPNS, as it doesn't require peers to upgrade or be aware of the use of this scheme.
More key advantages of this approach are that additional shares of the private key can be generated, to add additional signers, and producing a signature only requires a "threshold" of shares - so if some people lose their shares, or are offline, or misbehave, a valid signature can still be produced so long as a quorum of signers cooperate. Schnorr threshold signatures are also very widely supported across curves, so if another signature scheme is added to IPFS, there's a good chance that a generic FROST implementation would be supported for that new scheme.
As disadvantages go for this approach, the major ones are complexity and newness. Schnorr threshold ed25519 has some proof of concept implementations out there, but they aren't battle-tested or audited, so far as I'm aware. Additionally, distributed key generation requires either a trusted coordinator who knows the whole private key and produces shares of it, or an MPC solution which decentralizes this role, but which doesn't currently exist to my knowledge.
This is a placeholder issue for tracking this topic.
Why
Publishing updates is important. Being able to do it without dependency on censorable DNS, or paying for Gas to some blockchain grows the pie of use cases IPNS could serve.
Would be beneficial to the IPFS ecosystem if
How (Feature Set)
TBD, topics to discuss:
TODO
Prior Art