## Why Live, Trustless MPC Key Share Rotation Is Hard The short answer: share refresh protocols do exist (proactive secret sharing), but "safe, trustless, and live" simultaneously is an unsatisfied combination due to several interlocking problems. --- ### The Core Tension Proactive secret sharing (Herzberg et al., 1995; GJKR variants) lets parties refresh shares so old shares become cryptographically useless, without ever reconstructing the private key. What it can't do is make that refresh **atomic, live, and trustless at once**. --- ### Specific Failure Modes **1. The transition window is not atomic** Refresh takes time across a distributed network. During the handoff, old and new shares coexist. An adaptive adversary who can corrupt parties across epoch boundaries can combine shares from both epochs. Proactive security assumes the adversary can corrupt at most `t-1` parties *per epoch* -- but if the epoch boundary is blurry, that assumption erodes. **2. Who coordinates the epoch boundary?** Rotation needs parties to agree on: when the old epoch ends, who participates in the new epoch, and whether enough parties completed the protocol. In a synchronous setting with a trusted coordinator, this is manageable. In a truly trustless, asynchronous setting, you need Byzantine-fault-tolerant consensus just to agree on "did the refresh succeed?" That consensus layer itself has trust assumptions (honest majority, network synchrony bounds). **3. Partial completion is dangerous either way** If only `k < n` parties finish refreshing before a timeout: - Accept the partial refresh: parties are now in inconsistent states, some holding old shares, some new. Signing may silently fail or leak information. - Roll back: requires agreement on rollback, same consensus problem. There's no safe default. **4. New-party trust bootstrapping** If rotation involves changing the signer set (re-sharing to a different group), new parties have no shares to verify against. They must trust that the dealers are honest or that an on-chain proof is sound -- that's a trust assumption, not trustless. **5. Authenticated channels require PKI** The refresh protocol needs parties to authenticate each other's sub-shares. This typically requires a PKI or pre-established keys, which means trust is already encoded in who controls key registration. --- ### Why Blockchain Coordination Doesn't Fully Solve It Posting commitments on-chain helps with ordering and auditability, but: - It adds latency and cost to every refresh - The chain only orders events; it cannot make the cryptographic handoff atomic - It introduces a liveness dependency on block finality --- ### What Exists and Where It Falls Short | Protocol | What It Provides | What It Assumes | |---|---|---| | GJKR proactive SSS | Refresh without reconstruction | Synchronous network, honest majority | | FROST/DKLs23 refresh | Round-efficient refresh | Semi-synchronous, authenticated channels | | On-chain VSS | Verifiable dealing | Chain liveness, honest-majority for threshold | All current production MPC systems (Fireblocks, ZenGo, Capsule) make network synchrony or honest-majority assumptions during refresh. None are trustless in the cryptographic sense -- they move trust from a single custodian to a quorum and a network model. --- ### The Fundamental Bound A result related to the CAP theorem applies here: you cannot simultaneously guarantee **consistency** (all parties end on the same epoch), **availability** (rotation completes even if some parties are offline), and **partition tolerance** (the network may drop messages). Safe live rotation under network partitions requires either a trusted coordinator or a consensus round -- both exit "trustless." The field is active (YOSO model, fluid MPC), but nothing deployed today satisfies all three constraints.