Consensus: MatchMin

Matchmin

    A fundamental aspect in the blockchain area, if not the most important, is the consensus of the network of participants. It constitutes the basis of what is permissive and what is not in the network, which must be taken into account for the correct verification of the data, and how to act accordingly following a logic and algorithm through a common agreement between the participants.

The Matchmin scheme is the following: the network is made up of 2 types of participants, Validators and Clients, each node is identified with a unique ID that the rest of the participants know, this is a cryptographic public key which it itself derived before joining the network and who only knows and uses its private key.

further to recognizing each other within the network, the key is used to sign and corroborate the data that is sent between nodes and certify the authenticity of the sender. If someone tried to falsify data in advance, they would not be able to prove its authenticity, due to the requirement of the signature of the author node as a security condition in addition to other parameters that the signature message must contain.

Validators are responsible for corroborating whether the information provided by participants is correct and permissible within the network, decided by the majority following a common criterion. They also decide, based on a pseudo-random selection, who among them will build the next block of transactions/operations, in addition to obtaining commissions as an incentive for processing and adding the transactions or operations to the new block. When the Validator builder has filled the maximum transaction space or after a time limit has elapsed or he does not wish to process more transactions, the integrity of the block will continue to be verified in the network with the counterpart of the rest of the participants, expecting at least 51% affirmation, in order to guarantee that the data has been correctly propagated in the network. This verification, being true, marks the block as validated and immutable.

If the validator wishes, he can serve the network publicly without registering a client, providing more decentralization in the network. These parameters can vary depending on the context in the configuration with which the blockchain is to be operated (public, mixed or private).

The Client can make requests for processing new transactions to the validators, which are subsequently signed and verified after having verified that the status of the account in transaction is valid for said operation. He can also request resources in the network and its states such as the indexing of accounts, transactions and general information supplied through the network.

Pseudorandom choice algorithm

To start building a new block of transactions, First it is necessary to start a round from a list-queue of all Validators that participating in the blocks construction , they’ll follow this order having only one construction turn per round, whoever's turn it is will the queue of the new transactions with rest of the network that make up the new block and reward the charge commission for it. This list is built in a pseudo-random way as follows:

1) Each Validator node must choose a random number that only it knows. We will call this number "Antecedent." This antecedent will have a Consequent, which is the result or product of implementing a function that makes it complex and very difficult to recover its antecedent (such as the SHA function). Each node will share its Consequent on the network without first revealing its Antecedent.

2) When all the validator nodes have contributed the product of their function with each participant, they proceed to make their antecedent public. It must also be verified that the one contributed by the others is correct.

3) After this, a hash is derived from a chain that contains all the antecedents together with the hash of the last block, this derived hash must be interpreted as an integer.

4) the list is built in such a way that the node whose hash of its public address is algebraically closest to the hash derived by the algorithm will be placed next on the list in ascending order and so on with the rest, in this order it is decided who and how will build the following blocks and reward fees.

This in turn could be integrated with a PoS scheme (currently used by Ethereum) or similar in the registry of validator nodes.

In terms of attack mitigation, trying to manipulate the list to alter the order to an advantage would not make sense since the malicious node would have to know all the antecedents beforehand. In a network where the majority are trustworthy, this should not happen and would be sufficient. Otherwise, it could try to crack the SHA, which would require a very high computing force that ends up mitigating the profitability of an attack. However, let's suppose that in the remotely hypothetical case that this happened, the structure of the scheme is to follow a previously assembled queue, once its turn ends, it must wait for the others to build the block that is theirs. This reason makes no sense to attempt fraudulent actions in this area to gain an advantage in mining.

This is what Matchmin relies, this algorithm proves not to require the computing power used in consensus such as PoW (bitcoin), having as a characteristic to be efficient, and continuing to maintain security and transparency in the network allowing everyone to participate equally, without requiring large investments in energy infrastructure or hardware in this area.

Thank you for reading this entrie I’m looking forward to sharing more about CryptoDbSS. any questions or suggestions
steevenjavier@gmail.com

GitHub: github.com/Steeven512/CryptoDbSS