Multi-Party Computation (MPC) Network

The meta-protocol describes the code that will orchestrate all the functionality. This includes but is not limited to:

  • The MPC network

  • The tap-scripts

  • Pulling data from ordinal inscriptions to the client side.

The MPC network, on the other hand, will distribute the computational load of the meta-protocol to a broader audience. The meta protocol can be used in isolation, but the stablecoin protocol will require a wider network for high availability.

The MPC network functions as a decentralised seizing entity that blocks, but never owns, the BTC of vaults whose loan-to-collateral ratio has dropped below the protocol safety threshold. It can be run by any number of parties locally and is triggered by either a user request or an Oracle signal. It is a decentralised service that can be run on top of a Bitcoin node to offer high availability.

Leveraging the Multi-Party Computation Network

At Ducat, the overarching objective is to offer a decentralised, secure service independent of an L2 that can execute complex code while not relying on an internal state system independent of Bitcoin.

Several options exist to achieve this, and they all involve compromises; there is no silver bullet to achieving a fully decentralised network with high availability and speeds faster than the BTC block time while inheriting its security. We have, however, created a pseudo rollup process that the MPC network will use to prove the validity of its function.

The diagram below showcases the flow of the network and users:

The network will have two states and two triggers. It can be described as computing on demand and will not process anything unless directly commanded by one of the two triggers. As described above, the node will run the meta-protocol and distribute the computation effort for some actions. However, there will be specific triggers that are lightweight enough to be executed locally and with which the user can interact without having to query the network.

In the diagram above, we can see the user triggers an action that is processed by the network; after the network comes to a consensus about what the right outcome should be, it will collectively gather enough signatures to submit the transaction over the Bitcoin network, it will do so à la BitVM2. Among the possibilities, the tap-script will have to check the validity of the ZK system and block-height lock, which will be the available time to contest the transaction validity.

This allows the network to execute code that is orders of magnitude more complex than ZKs. The network will not have any autonomy in and of itself; it will just be programmed to follow precise steps that can later be verified.

Network setup

We've selected a Distributed Key Generation (DKG) framework that embraces dynamic membership, enabling our network to adapt seamlessly to the changing landscape of participation. This approach isn't just about flexibility; it's a critical pillar of our commitment to maintaining an unbreakable security posture. Our DKG protocol is predicated on the assumption that certain mathematical problems, specifically those related to discrete logarithms, are extremely difficult to solve. This complexity forms a robust barrier against potential attackers, ensuring our cryptographic processes remain secure against any entity without an unrealistic amount of computational power.

Our operational blueprint includes a threshold signature scheme requiring the consensus of at least 70% of nodes to validate any transaction or to enact any significant network action. This threshold is meticulously calibrated to prevent any small group from exerting undue influence over the network, ensuring that our operations reflect the collective will of a substantial portion of the participants. It's a safeguard against centralisation, a commitment to collective decision-making that underpins the democratic ethos of our network.

Moreover, this threshold approach serves a dual purpose: it secures our network against internal and external adversities and facilitates a smooth and efficient operational flow. In a landscape where the speed of transactions and decisions can be critical, our model ensures that the network remains agile and responsive without compromising on its foundational principles of security and decentralisation.

Last updated