zkBitcoin Roadmap

Single-UTXO zkapps

Align with the way things are in Bitcoin. Just as creating and spending multiple UTXOs by one transaction is normal in Bitcoin, the same should be normal in zkBitcoin.

This means, zkapps should be fully contained within single UTXOs.

Alternative proof systems

Beside snarkjs / Circom, add support for Gnark (and, in the future, SP1).

Dynamic MPC signing committee

Implement DKR (distributed key rotation), e.g. as described in https://eprint.iacr.org/2021/339

Move MPC signature orchestration to the client

Since FROST MPC coordination is stateless and doesn't involve anyone's secrets, clients are perfectly capable to perform it on their own.

This removes a centralized component from the system, which is nice.

This does not impose additional requirements on MPC nodes (except maybe take their security seriously, since now they are known to the public, which should not be a problem, since that's a common assumption towards blockchain validators anyway).

MPC node stakes

To become a signing committee member, a node owner locks their stake in a stake-tracking zkapp. Stake can be increased / decreased at any time. Growing (or shrinking) the stake would make the node more (or less) appealing (both in the eyes of the users and to the weighted random signer selection algorithm), so will result in more (or less) business.

Stake-weighted sortition of nodes to sign a transaction

Since users know the signing MPC nodes and their stakes, they can use that information to make weighted random selection of a subset of these nodes (of size $t+\delta$, where $t$ is the threshold, $\delta$ — small number of additional nodes) and send them a signing request. If the client doesn't hear back from up to $\delta$ nodes — fine (if less than $t$ respond, the client can always contact more nodes). Of course, $\delta$ better be chosen high enough to not need contacting more nodes.

Clients may choose whatever nodes they want — this is fine 🔥. Weighted random selection is basically a suggestion, but one that is aligned with users' interests: they want to trust signers with higher stakes in the protocol (lower stake means lower probability of selection).

When all necessary signature shares are available, the client takes $t$ signature shares and constructs the final signature.

MPC node rewards

Each zkapp user transaction contains a fee output (fee jar). Fee jars are zkapps tracking fee amounts for participating MPC nodes. Several fee jars can be aggregated into a single one (e.g. when a node owner takes their share of fees from several fee jars).