Road to Deterministic Masternodes and Systemnodes
Part Two: Limitations within the current System
In the first part of this series we presented an overview of the Masternodes and Systemnodes protocol on Crown, their roles, the exchange of information through P2P messages, and the non-deterministic MN and SN lists. We conclude that, in practice, the MN or SN lists of two clients on the network do not necessarily have to match, and this may depend on the information exchanged with the peers to which those clients are connected. In this post we will expose the main limitations of the current non-deterministic MN and SN lists so that you can understand why we are moving to on-chain deterministic lists.
Consensus Issues
First of all, it is important to clarify that the reasons for the discrepancies in the list of active MN and the list of active SN can be diverse, and is given by the working logic of a P2P network: messages may arrive late, in different order, or not arrive at all, for example. Furthermore, this model forces you to synchronize both lists (MN and SN) after having completely synchronized the blockchain; this is not only slow, but also very prone to failure.
Another cause of the possible failures could occur at the time of forming a quorum and getting consensus, where not necessarily the participants have the same MN list. In Crown when a transaction is sent via InstantX, it is necessary to choose a quorum, i.e. a set of nodes that will participate in a vote via P2P messages to determine if a transaction is valid. Each vote is cast as a message to the rest of the network clients, which verify and store each individual vote. It happens that, in a system based on non-deterministic lists, the nodes may determine different quorums based on their interpretation of the MN list. As a consequence, some nodes could reject transactions, forking away from the network, and ultimately compromise the consensus. In this situation, sporks are often used, a mechanism designed to control network variables through messages sent by the P2P network.
In a model where the lists remain off-chain It's not possible keeping a record of the MN or SN active in the past, or the rewards distributed previously. Additional solutions would be necessary (at Crown there is a community solution to keep the historical counter of active MN or SN through an NFT protocol, stored in the chain itself). But we have data of each MN or SN registered in the past?
Limitations of the current roles
Currently, to run a MN or SN it is necessary to define the input (UTXO) associated with the collateral. The associated CRW address will necessarily be the one that receives the node rewards. This model is not flexible at all considering the possible scenarios in which you would like to distribute the node rewards: What happens if you want a third party to receive the benefits, or the "operator" to receive directly a portion of the rewards for their services?
As we saw in the previous post, when starting a MN or SN, an announcement message is sent to the P2P network using the "masternode start alias" command. We are again in a scenario with little flexibility. If the "owner" can only send this command, whoever executes the node in a different machine ("operator") will depend on the "owner" to start the execution of the MN or SN. Something that does not make much sense if we consider that the role of "owner" is designed to remain offline, both for convenience and security. In practice, it also happens that the servers or machines that execute the node may be down, and in these cases it is necessary for the "owner" to intervene again to send the start command to the network. If the crashes are frequent, then the user who has the collateral must repeat the "start alias" process, even if the error is on the operator side.
Another issue is about the mn-key model. As we mentioned in the previous post, this key does not allow the operator to access the owner's funds. However, in Crown, the mn-key is sufficient to cast a vote on the governance model (only Masternodes can participate in voting on proposals). This means that an operator could use the mn-key to cast a vote on the network: the trust also lies within the "operator" to not misuse this permission. If large hosting providers at a given point support the network, this scenario could be dangerous to the health of the Crown governance.
We see that in the current model there is no clear and well-defined idea of the roles behind an MN or SN. The Crown community has decided to solve these issues and move in a new direction: the deterministic Masternodes and deterministic Systemnodes are coming! This new solution will allow a list of MNs and a list of SNs to be registered on-chain and expand the existing roles. Stay tuned for the third article of the series to learn everything on the deterministic model to be released!
