🏗️ UNDER DEVELOPMENT 🏗️
The pNetwork v3’s architecture is completely decentralised from its new design, and new actors (Relayers, Sentinels, Guardians, and the DAO) have been introduced to avoid any centralized entity requirement.
For a more complete overview, read the pNetwork v3 white paper.
How does it work
The new architecture uses the optimistic approach and multi-provers.
The optimistic approach expects an actor, called Relayer, to make a proposal for the issuance or redemption of a pToken; after the proposal, a period of time, called challenge period, allows other actors to verify the legitimacy of the proposal, which is optimistically expected to reflect the original request of the user who instructed the swap.
If the proposal is assessed as illegitimate, it can be cancelled, which means that it is no longer executable after the challenge period has elapsed. Cancellations should come from actors belonging to different classes (multi-provers), which we have identified as Sentinels and Guardians.
Any entity, known as Relayer, can suggest a transfer execution on the destination chain after the challenge period. This differs from pNetwork v2 where transactions were exclusively processed by bridges run by select permissioned nodes.
Being a fully decentralised protocol, pNetwork v3 will naturally fall out of the scope of MICA regulation and therefore it won’t be required for any KYC, AML or other requirements that can bring friction and rise barriers at the user experience level.
Despite the protocol should maintain its decentralisation, pNetwork is actively seeking ways to prevent malicious individuals from using the protocol for unlawful purposes and/or illicit funds.
Further details are expected to be released in the upcoming months to illustrate this new concept.
Fortify v3 security
pNetwork v3's security is ensured through the collaboration of multiple actors tasked to intercept fraudulent cross-chain transactions. These include:
Besides the DAO - which is decentralized by default - the other v3 actors are decentralized by design. They are:
- Relayers: who relay cross-chain operations from the originating chain to the destination chain.
- Sentinels: who check for relayed transaction mismatches via full block and transaction validation and potentially dismiss them.
- Guardians: DAO-elected actors who check for relayed transaction mismatches via watching blockchain-emitted events and potentially dismiss them.
- Challengers: who monitor sentinels and guardians' behaviour and potentially challenge them if they misbehave.
The multi-provers approach challenges user proposals, and if any of these three elements are triggered, a Relayer's request can be dismissed.
In specific (and rare) situations where conflicts arise and Sentinels and Guardians fail to reach a consensus on a Relayer proposal, the intervention of the pNetwork DAO becomes necessary. This intervention serves as a mechanism to address and resolve disagreements. When such conflicts occur, a new vote will be automatically initiated, providing an opportunity for the DAO to express its stance by voting either in favour or against the disputed transaction.
The security of the pNetwork DAO should not be confused with the security of the pNetwork protocol as a whole.
To put it simply: taking over the DAO doesn't mean taking over the pNetwork v3 protocol. Let’s find out why.
While the DAO plays an important role in governance and decision-making, it does not have the authority to change the fundamental behaviour of the pNetwork protocol. Rather, the DAO's security functions are limited to those of one actor among many, and its actions are designed to support and enhance the functionality of the protocol, as it operates in the service of the protocol.
What's more, the DAO Treasury is not part of the protocol itself, and its eventual exploitation will in no way affect pNetwork's cross-chain operations.
The framework of pNetwork v3 can be designed as follow:
.png?table=block&id=b22645ff-3315-4cd1-8d2f-0af1acabd5c9&cache=v2)