The revolution on blockchain

Proof of Unity

Proof-of-Unity protocol works by selecting a number of stakeholders competing to mine the hash with artificially created mathematical difficulties. It is more strenuous to generate them than Proof-of-Stake, but much simpler in contrast to Proof-of-Work. Then, the rest of the stakeholders then validate the block and the transactions.

Transmission does not take place between all nodes in the network linearly, but rather in a cycle between the nodes of the P2P Group that will assess the transaction's quality. The final node picked as the closing node must assimilate and confirm all transactions, shut the block, and release it to the network.

Once the first transaction is transmitted to the first node from the pool of transactions that node will check the transactions it's correct with the parameters of the protocol. After the node will transmit the transaction to the P2P group where it will work together with the other node chosen by the protocol randomly. After receiving the transaction, the P2P nodes evaluate the communication's correctness/quality and issue a receipt confirmation with a score based on its quality. The higher the value and the number of confirmed transactions, the greater the node's chance of becoming the closing node for the next block. Assume the node is non-compliant or of substandard quality. In that event, the transmitting node will earn a lower score, penalizing it on the scale for subsequent block closures; each node will begin with a score. If the node's score falls to zero, the node will be removed from the network due to its unreliability. If a transaction is of low quality or does not adhere to the protocol, it will be returned to the first node with a bad receipt and a low score.

Network P2P safe and trustless

Group P2P

The network is based on the concept of trustlessness. Each node establishes a P2P network with other random nodes; after the first check, each node sends the transaction to all nodes in the P2P group. Each node checks the transactions and returns the receipt with the given score. After the final transaction, the node is elected to close and validate the block with all transactions.

These nodes contribute to the validation and creation of the block, but they cannot independently choose which blocks to include in the peer network; they must collaborate with those given to them.

The network's security improves over time as the quality of the nodes and transactions communicated improves and their longevity in the network increases.

From a security standpoint, this protocol is crucial since the independent peer system enables the simultaneous review of all transactions in the network. Excluding non-compliant transactions, as in double transaction attacks, also prevents the creation of a critical element in the blockchain, known as the factor 51%. This is significant because the algorithm does not allow for probability calculation and the choice of nodes is predetermined, making it impossible to create a network with 51% of nodes accepting non-compliant transactions.

Another essential element is that as our network expands in size, the number of nodes increases, the amount of coins awarded as prizes increases, and therefore the entire ecosystem becomes more democratized. Additionally, the peer system limits the number of nodes that can work on a single transaction to a predetermined number, boosting the potential of scalability with more efficiencies on work on transactions concurrently and always with excellent quality.

How work the receipt on PoU?

The main objects in Proof of Unity Consensus are receipts. Each indicated receipt contains several attributes, each of which is accompanied by the creator's digital signature.

Every node receives transactions from users and transmits them to all nodes in the P2P group. This group will examine the transactions sent by each node and, if they are correct, a receipt will be sent with a score based on the following factors:

  • Transaction processing time
  • Transaction quality
  • Connection Quality
  • The time the node worked in the network
  • Transaction value
  • Number of blocked tokens
  • Hash Power

These receipts will only be sent if the transaction is completed correctly. In case the transaction is not completed correctly, all nodes will send a receipt with a low score. When a node's score reaches 0, the network will automatically kick the node out of the network and block the amount at stake.

Monolith block will be made one time every day by the node with the highest score in all network.

Monolith block

Metada contents on Monolith Block

The new way for join in Blockchain

Monolyte Block

The Prometeo architecture generates a special block called a Monolith block once per day, which is also chained to the previous monolith block. These blocks form a series of hops that allow a node to skip regular blocks between the genesis block and the current time. This allows for quick access to any point in the blockchain's history. Monolith blocks are generated once per day on average and contain major updates to the node registry (which nodes joined and which left) and a list of hash names of all blocks in the day, but no transactions, resulting in a very light set of blocks to download. The Monolith will be created by the node with the highest score reached in the day in all networks, this is for incentive good work. After the Monolith block will be confirmed by only the group of nodes with the highest score in the day.

The first step for any new node is to download all Monolyte blocks starting with the genesis block (choosing the set of blocks with the highest cumulative difficulty in the event of a fork) until it reaches the latest available Monolyte block. The node then uses the most recent blockchain snapshot hash found in a Monolyte block (more on this later) to locate and download a blockchain snapshot from network peers. This allows a new node to catch up with the live blockchain in a matter of minutes, even if Prometeo has been running for decades and the blockchain contains many gigabytes of data.

Each spine block also contains a list of public key nodes, which have been added or removed from the node registry. It also contains the list of block's hash names minted in the previous cycle since the Last ‌‌Monolyte ‌‌block‌. ‌As ‌‌the ‌‌node‌‌ applies ‌‌Monolyte ‌‌blocks ‌‌in‌‌ sequence,‌‌ the set of additions and removals tracks a “key pool”. It roughly follows the set of node public keys in the node registry. Each Monolythe block must contain a collection of digital signatures on its contents. The set of keys which may be legally signed, and how much value each‌‌ of‌‌ their‌‌ signatures‌‌ contribute to‌‌ the‌‌ cumulative‌‌ difficulty‌‌ of‌‌ the‌‌ Monolythe block, are governed by the consensus mechanism.