Proof of Performance Consensus Model and Algorithm

Bulgakov Vladislav Dmitrievich ORCID: 0009-0006-2056-6169 Postgraduate student; Department of Computer Engineering and Automated Systems Software; Belgorod State Technological University named after V.G. Shukhov 46 Kostyukova str., Belgorod, Belgorod region, 308012, Russia bulgakovvlad@yandex.ru

Gvozdevsky Igor' Nikolaevich ORCID: 0000-0002-3235-3869 PhD in Technical Science Associate Professor; Department of Computer Engineering and Automated Systems Software; Belgorod State Technological University named after V.G. Shukhov 308012, Russia, Belgorod region, Belgorod, Kostyukova str., 36, office 421 Gvozdevskiy.in@bstu.ru

Introduction

The urgency of the problem of increasing the performance and scalability of blockchain networks is due to the growing requirements for processing transactions in highly loaded systems such as financial technologies, Internet of Things (IoT) systems and decentralized applications (dApps). Existing consensus algorithms, including Proof of Stake (PoS) based on the Tendermint core, demonstrate limited bandwidth due to high load and limited performance resources of network validator nodes. These limitations create bottlenecks in the functioning of networks and reduce their resistance to load changes^[1].

The purpose of this study is to develop and analyze the Proof of Performance (PoP) model, which aims to increase the efficiency and scalability of blockchain networks through the introduction of horizontal sharding technology. PoP is based on the idea of an equilibrium distribution of transactions between nodes, which reduces the load on individual validator nodes and improves overall network performance.

To achieve this goal, the following tasks are being solved:

• Development of a modified block structure that provides sharding support.
• Construction of a mathematical model of load distribution and calculation of node performance.
• Experimental verification of the correctness of the PoP model in an expanded test network.

The scientific novelty of the work lies in the proposal and description of the latest Proof of Performance algorithm, combining adaptive load distribution and node performance accounting, which can significantly increase network bandwidth and its resistance to load changes.

The presented work lays the foundation for further research aimed at integrating the described consensus algorithm into existing blockchain systems and developing technologies for decentralized load management.

Description of the Proof of Performance model

In the Proof of Stake consensus algorithm, the node offering the block (Block proposer) receives a certain number of transactions from the Transaction pool (mempool) for processing, in order to subsequently publish them in the block, and, accordingly, in the network. This approach limits the number of transactions that can be processed by the network at a certain point in time, and also increases the load on the node that is offering block creation in this iteration. Moreover, the PoS approach to determining the network participant who will be able to add a block to the network is determined by the number of coins of the participant, which in itself adversely affects the philosophy of decentralization of the blockchain network^[2].

The introduction of horizontal sharding technology will make it possible to remove the load from the node offering the block and distribute it in equilibrium to all nodes that are shards, that is, to nodes that provide their computing power for the transaction processing process in the network^[3].

The following is a diagram that describes the transaction processing process in the Proof of Stake consensus algorithms (Figure 1) and Proof of Performance (Figure 2).

Fig.1 – The process of processing transactions in the Proof of Stake algorithm

Fig.2 – The process of processing transactions in the Proof of Performance algorithm

The main advantages of this approach are:

· One-time processing of all transactions in the vault. In the case of Proof of Stake, the algorithm cannot send the number of transactions exceeding a certain threshold to the node for processing, as this will adversely affect the performance of the node offering the block and may cause a network failure if this node fails. In the Proof of Performance model, the algorithm "pulls" all transactions from the storage and distributes them in equilibrium between the shards^[4].

· Load balancing. The lack of diversification in the transaction processing process is a big problem in the field of blockchain^[5]. The failure of the node on which the task of creating a new block lies increases the time of its creation, and if all nodes of the network failed to cope with this task, causes the network to lock down. The introduction of the concept of shards, the description of their algorithm of operation and their implementation into the existing system will allow the node engaged in the process of creating blocks not to waste its computing power on transaction processing. All he has to do is get this data from the shards, check it and publish it in the block.

Block structure in the Proof of Performance model

Since the process of accounting and controlling sharding is a new task, for the decentralized storage of the results of its solution, it is necessary to modify the existing block structure. At the moment, the following structure prevails in Proof of Stake networks, consisting of 15 fields:

· Block #N: Block number. This is a unique identifier of a block in the blockchain, indicating its position in the chain.

· Version: The version of the software or protocol used to create this block.

· chainId: ID of the network to which this block belongs.

· Height: The height of the block. This is the sequence number of the block in the blockchain, starting with the genesis block (block zero).

· Time: A timestamp indicating the time when the block was created.

· LastBlockID: The ID of the previous block in the chain. This value is used to link blocks into a single chain.

· LastCommitHash: Hash of the last confirmed block. This value is used to check the correctness of the previous block.

· DataHash: The hash of the block data. This value is a cryptographic hash of all transactions included in the block.

· ValidatorsHash: Hash of validators. This value is a cryptographic hash of the list of validators involved in block validation.

· NextValidatorsHash: Hash of the following validators. This value is a cryptographic hash of the list of validators who will participate in the validation of the next block.

· ConsensusHash: The hash of the consensus. This value is a cryptographic hash of the parameters of the consensus algorithm used to reach an agreement between validators.

· AppHash: The hash of the application. This value is a cryptographic hash of the application state after all transactions in the block have been completed.

· LastResultsHash: Hash of the results of the last execution. This value is a cryptographic hash of the results of the transactions in the previous block.

· EvidenceHash: A hash of the evidence. This value is a cryptographic hash of all the evidence included in the block, which can be used to identify malicious validators.

· ProposerAddress: The address of the offering block. This is the unique identifier of the network participant who proposed this block to be added to the chain.

This structure in the form of a table that makes up the block is shown in Figure 3.

Fig.3 – Block structure in the Proof of Stake algorithm

Since this structure needs to be refined and parameters added to account for the sharding process, the block structure in the Proof of Performance model will include the following additional parameters:

· ShardsHash: Hash of the list of shards. A cryptographic hash representing a list of all nodes that are shards in the network.

· CurrentShardsHash: Hash of the current shards. A cryptographic hash representing the list of shards involved in processing transactions in this block.

· NextShardsHash: Hash of the next shards. A cryptographic hash of the state of the shards that will participate in the transaction processing process in the next block.

· ShardsEvidenceHash: Hash of shard evidence. A cryptographic hash of all the evidence included in the block that can be used to identify malicious shards.

· DataAccordanceShardsHash: Hash of matching shard data. A cryptographic hash that ensures data consistency between different shards. This field contains the hash of the correspondence between the shards and the transactions processed by them.

According to the updated structure, the block model in the Proof of Performance algorithm, which implements the horizontal sharding process, will look like this:

Fig.4 – Block structure in the Proof of Performance algorithm

These innovations allow the network to take into account the contribution of each shard to transaction processing, ensure data security and distribute the load between nodes in proportion to their performance.

The need for such changes is due to the following factors:

1. Problems with the current block structure:

• Lack of support for horizontal sharding.
• The concentration of the load on the validator node.
• Increased probability of failure due to overload of one node.

2. Advantages of the modified structure:

• Uniform distribution of transactions between nodes.
• The ability to adapt to load changes.
• Improving network stability by decentralizing data processing.

Thus, the proposed changes in the block structure provide the basis for the effective implementation of the PoP model and its further integration into blockchain systems.

Distribution of weights

In order to ensure a fair assessment and load distribution between shards, the Proof of Performance algorithm assumes the role of an arbitrator and provides a process for managing the procedures for assigning, rewarding and punishing shards depending on their performance.

The Proof of Performance algorithm is based on a performance evaluation system for each shard.

The following parameters are used to determine performance, which affect the final result of calculating the shard weight:

· Performance (P): The performance of the shard in processing transactions. It is evaluated based on the success of transactions in the current and previous blocks.

· Weight (W): The weight of the shard, which determines the level of its competitive ability to process transactions in the next block.

· Penalty: Penalty for late or unsuccessful transaction processing

· Reward: Reward for successful transaction processing.

The performance evaluation is based on the following formula:

,

where is the total number of transactions assigned to the shard , is the number of transactions successfully processed by the shard;

Determining the weight of a shard is one of the main tasks of the algorithm, since an incorrectly determined weight can adversely affect network performance (for example, if a shard with small computing power gets a lot of weight). The following formula is used to determine the weight ():

,

where is the weight of the shard in this block, is the reward coefficient for the shard , and is the penalty coefficient for the shard .

The reward and penalty coefficients are determined as follows:

,

where and are constants specifying the effect of rewards and penalties on the weight of the shard.

After calculating the weights for the next iteration, they must be normalized so that the sum of the weights of all the shards does not exceed 1, that is, 100%. The following formulas are used for this purpose:

,

where is the sum of all the non–normalized weights of the shards, and is the normalized weight for the shard .

To distribute transactions between shards, the next block uses weighted random selection based on updated normalized weights. The total number of transactions is divided between the shards in proportion to their weights based on the following formula:

where is the number of transactions assigned to the shard in the next block.

The efficiency of the algorithm

The Proof of Performance algorithm will consist of the following steps:

1. Initialization. At this step, the initial weights of all the shards are set. This step is performed only at the first iteration of the algorithm, that is, when creating the genesis (zero) block;

2. Collecting transactions. All incoming transactions from network users are collected in a common pool (storage);

3. Distribution of transactions. Transactions are distributed among the shards based on the current (or initial) weights;

4. Transaction processing. Each shard processes the transactions assigned to it;

5. Performance evaluation. The performance of each shard is estimated according to the formula ^[6].

6. Updating the scales. Shard weights are updated based on rewards and penalties.

Figure 5 – Transaction processing algorithm in the Proof of Performance model

Proof of the correctness of the algorithm

Let's say there are three shards on the network with the current weights. Let's assume that the values of the coefficients of reward and punishment and .

After creating the block, note that:

· processed 90% of the transactions assigned to him ();

· processed 70% ();

· processed 80% ().

Then:

;

;

;

Similarly for:

;

;

.

;

;

.

Normalization of weights:

;

;

;

.

Then the new sum of the weights of all the shards is: , and the new weight of each shard is:

;

;

.

After updating the weights, transactions are distributed proportionally to the new weights, ensuring fair and efficient transaction processing in the next block.

Let's say 1000 transactions are waiting for publication on the network. Then, based on the new weights, each shard will receive:

;

;

.

Comparison of transaction processing speed in Proof of Stake and Proof of Performance networks

Let's consider an example in which there are 5 nodes in two networks (A and B) that support their operability.

Network A runs on the Proof of Stake consensus algorithm. Let's assume that each validator (node) has the technical equipment to process 1000 transactions per 1 block. Then, when a new block is proposed, the validator processes 1000 transactions and puts them in the block, that is, the processing speed: 1000 tranz/block or 167 tranz/sec (with an average block time of 6 seconds).

At the same time, in network B, which is supported by the Proof of Performance consensus algorithm, when the task of generating a new block arises, each shard takes on the task of processing 1000 transactions. Provided that there are 5 shards in the network, then the transaction processing speed will be: 5000trans/block or 833trans/sec. That is, the network performance based on the Proof of Performance consensus algorithm is X times greater than in networks based on Proof of Stake, where X is the number of shards in the network.

Application of the Proof of Performance consensus algorithm

The PoP algorithm can be implemented and have a positive impact on the performance of those blockchain networks in which high throughput is important when processing transactions, as well as scalability.

The algorithm can be useful in the following types of networks:

· Networks with a large number of decentralized applications (dApps)^[7];

· IoT (Internet of Things) systems^[8];

· Global payment networks^[9];

· Supply chain management systems^[10].

Simulation of the Proof of Performance algorithm and analysis of its impact on performance

To assess the impact of the Proof of Performance (PoP) algorithm on the performance of the blockchain network, an experiment was conducted during which a copy of the Polkadot network deployed on local equipment was subjected to load and measurements of network performance metrics. After the measurements, the network was updated and the Proof of Performance algorithm was implemented to replace the Proof of Stake, which was originally used.

Polkadot uses a blockchain model where several independent blockchains are connected to the main network (relay chain) and use its computing power to function. With the current architecture, the load from the blockchain is concentrated on one node at the time of block creation, which can lead to bottlenecks and delays in transaction processing.

The experiment consisted of the following stages:

1. Creating a copy of the Polkadot network and launching the blockchain:

• Network deployment: A test network based on the Polkadot source code has been launched using the PoS consensus algorithm.
• Parachains: 5 parachains have been deployed, simulating various decentralized applications (dApps) with high transaction activity. To simulate the organic load on the network, transaction generators were used, which published a certain number of transactions to the network, creating a load on the network nodes.
• Node configuration: The network consisted of 10 validators to simulate a real distributed network.

2. Measuring network performance on PoS:

• Transaction throughput: as a result of the network generating 50 blocks (approximately 5 minutes), 15934 events (transactions) were processed. The average throughput was 53 transactions per second.
• Fault tolerance: When 20% of validators were disabled, network performance decreased to 34 transactions per second over the next 50 blocks.
• Node load: the load of the central processors of the computers on which the validator nodes were located was at the level of 90-95%, if the validator that was located on this machine was selected as offering this block and 10-15% if waiting in line for block generation.

3. Migration of the network to the Proof of Performance algorithm:

• Saving the current state: A hash of the current network state has been created to ensure data integrity after switching to a new consensus model.
• Making an update proposal: A proposal has been initiated to update the consensus algorithm, which has been approved by the network participants.
• Software update: changes have been made to the kernel source code to implement the minimum network capabilities based on the Proof of Performance algorithm. The algorithm for selecting shards for processing transactions has been updated, as well as the mechanism for punishing and rewarding shards.
• Launch of the updated network: a PoP-based network was launched with migrated parachains.

4. Measuring network performance on PoP:

• Transaction throughput: as a result of the generation of 50 blocks, the network bandwidth increased to 259 transactions per second, which is an increase of 487%.
• Fault tolerance: When 20% of the shards were disabled, performance decreased by about 20%.
• Node load: the load of the central processors of the computers on which the validator nodes were located was at the level of 40-60% during the entire measurement time.

5. Comparative analysis of the results:

6. Conclusions:

• Performance improvement: The implementation of PoP significantly improves network efficiency, making it more suitable for high-load applications.
• Scalability: PoP provides better scalability without the need to increase the computing resources of individual nodes.
• Improving the user experience: Reducing delays and increasing the speed of transaction confirmation increases user satisfaction.

Scenarios for the implementation of the Proof of Performance algorithm

1. Decentralized Applications (dApps)

Implementation scenario:

In highly loaded dApps (decentralized applications), such as decentralized exchanges, games or social networks, the number of transactions can be very high, which creates a significant load on the network. Network nodes may not be able to handle processing a large amount of data, especially if they have small computing resources.

Recommendations for use:

• Using the PoP algorithm is advisable in situations where dApps generate a large number of transactions and high network bandwidth is required. Usually, in such situations, when using the PoS algorithm, an indicator that the network is not coping with the load can be a long waiting time for transaction confirmation or an increase in block generation time.
• If the network nodes have weak computing power, PoP will help distribute the load and ensure stable operation of the application.

Potential problems and challenges:

• Data synchronization between shards: it may be difficult to ensure data consistency.
• Configuration complexity: Network configuration is required, which includes changing the kernel program code and other network parameters to support sharding and PoP.

Possible solutions:

• Implementation of efficient consensus algorithms between shards to ensure data consistency.
• Providing tools and documentation to simplify the PoP configuration and integration process.

2. Internet of Things (IoT) Systems

Implementation scenario:

In IoT networks, many devices generate data that needs to be processed in real time. The limited computing resources of the devices and the high speed of data generation require an efficient solution for transaction processing.

Recommendations for use:

• The use of PoP in large IoT networks with high device density and large amounts of data.
• Using PoP to distribute data processing between nodes with higher computing power.

Potential problems and challenges:

• Limited device resources: IoT devices may not support the required computing load.
• Data security: Ensuring the security and confidentiality of data in a distributed network.

Possible solutions:

• Using intermediate nodes or gateways with sufficient resources to process data from IoT devices.
• Implementation of encryption and authentication protocols to protect data.

3. Global payment networks

Implementation scenario:

International payment systems require high transaction processing speed and the ability to scale to meet growing transaction volumes. Delays and low bandwidth can negatively affect the user experience and trust in the system.

Recommendations for use:

• Implementation of PoP to speed up transaction processing and increase network bandwidth.
• The use of PoP in systems with a large number of micropayments, where the speed of transaction confirmation is critical.

Potential problems and challenges:

• Regulatory requirements: KYC (Know Your Customer) and AML (Anti-Money Laundering) rules must be followed.
• Transaction security: providing protection against fraud and attacks.

Possible solutions:

• Integration of user identification and verification mechanisms into the system.
• Implementation of additional levels of security and transaction monitoring.

Recommendations for integrating the Proof of Performance algorithm into existing blockchain infrastructures

Recommendations for the use of the PoP algorithm.

To improve performance and eliminate problems caused by the lack of power of individual nodes, the Proof of Performance algorithm should be considered for integration in the following cases:

• In networks with high transaction volume and high bandwidth requirements.
• In case the network nodes have small computing resources and cannot cope with the load.
• If necessary, increase the scalability and fault tolerance of the network.

The use of the algorithm may be optional:

• In small networks with low transaction volume, where standard consensus algorithms such as PoS meet the requirements.
• In cases where performance and processing speed requirements are not critical.

The implementation of the Proof of Performance (PoP) algorithm into an existing Proof of Stake (PoS) network requires a step-by-step approach and interaction with network participants. The general PoP implementation algorithm is presented below:

1. Analysis and preparation.

• Examine the current PoS infrastructure, determine the goals of the transition to PoP (performance improvement, scalability).
• Identify possible bottlenecks and resource requirements.
• Inform validators, developers, and users about the plans.

2. PoP development and testing.

• Develop a PoP version compatible with the architecture and smart contracts of the network.
• Create a test network for PoP tests without affecting the main network.
• Perform load tests and security audits.

3. Saving the network status.

• Create a backup copy of the current network status.
• Generate a check hash to verify the integrity after migration.

4. The proposal to update the consensus.

• Use the network's voting mechanisms to decide whether to upgrade the network.
• Ensure that the required quorum is reached.

5. Updating nodes and software.

• Prepare updated versions of node software with integrated PoP.
• Ensure backward compatibility for a smooth transition.
• Conduct beta testing with a limited number of nodes.

6. Deploying updates

• Determine the sequence of node updates.
• Set up monitoring to track the process and respond quickly.
• Provide detailed upgrade guides.

7. Launching an updated network on PoP

• After updating a sufficient number of nodes and obtaining consensus, make sure that the network is working correctly.
• Compare the current hash of the network status with the control hash to confirm the integrity of the data.

8. Monitoring:

• Ensure monitoring of key network metrics: bandwidth, block time, load on nodes.

Implementing the Proof of Performance algorithm into a Proof of Stake network is a complex but manageable process that, if properly prepared and implemented, can lead to significant improvements in network performance and scalability.

Analysis of the advantages and disadvantages of the Proof of Performance algorithm

Advantages of the Proof of Performance algorithm compared to other consensus algorithms:

1. Improved scalability and throughput

• Horizontal sharding: using PoP allows you to efficiently distribute transaction processing between shards, which significantly increases the scalability of the network. Unlike PoS, where the load is concentrated on validator nodes, PoP distributes the load evenly, allowing more transactions to be processed per unit of time.
• Parallel processing: Thanks to parallel processing of transactions in shards, the network can achieve high throughput without the need to increase the computing resources of individual nodes.

2. Increased fault tolerance and network reliability

• Load balancing: in PoP, the failure of an individual shard does not lead to a significant decrease in network performance, since other shards can compensate for the load.
• Reducing node overload risks: The lack of processing concentration on individual nodes reduces the risks of overheating and failures, which increases the overall stability of the network.

3. Energy efficiency

• Avoiding resource-intensive computing: unlike Proof of Work (PoW), PoP does not require solving complex cryptographic tasks, which reduces power consumption and makes the network more environmentally friendly and economical.
• Resource optimization: nodes use computing power more efficiently, which reduces the cost of maintaining the network.

4. Stimulating high node performance

• Reward and Penalty mechanisms: PoP motivates nodes to maintain high performance through a system of rewards and penalties based on their performance.

5. Flexibility and adaptability

• Dynamic load balancing: PoP allows you to dynamically change the distribution of transactions depending on the current performance of the shards.
• Adapting to changing conditions: The network can quickly respond to changes in load and resources, maintaining optimal performance.

Disadvantages of the Proof of Performance algorithm:

1. The complexity of implementation and integration

• Technical difficulties: The implementation of PoP requires significant changes in the network architecture and a deep understanding of the sharding mechanisms.
• The need to develop new tools: the creation of special tools and protocols is required to ensure the effective operation of PoP.

2. Potential security risks

• Sharding vulnerabilities: The distribution of data between shards can create additional attack vectors if proper security is not provided.
• Difficulties in data reconciliation: Ensuring consistency and integrity of data between shards requires reliable consensus mechanisms.

3. Node Resource Requirements

• Node heterogeneity: Nodes with different computing capabilities may have difficulty maintaining the required performance.
• The need for constant monitoring: Continuous monitoring and resource management are required to maintain optimal network performance.

4. Community resistance

• Changing established processes: switching to PoP may encounter resistance from network participants who are used to current algorithms.
• Training and adaptation: It takes time and resources to train node developers and operators in new working methods.

Comparison with other consensus algorithms:

1. Proof of Work (PoW):

Advantages of PoP over PoW:

• Higher energy efficiency.
• Better scalability and throughput.
• No need for expensive mining equipment.

Disadvantages of PoP compared to PoW:

• A more complex consensus-building system.

2. Proof of Stake (PoS):

Advantages of PoP over PoS:

• Improved scalability due to horizontal sharding.
• More even distribution of load between nodes.
• Less dependence on the steak (the number of tokens) to participate in the consensus.

Disadvantages of PoP compared to PoS:

• The complexity of implementation in existing networks.
• Requires more sophisticated mechanisms to ensure data security and consistency.

3. Delegated Proof of Stake (DPoS):

Advantages of PoP over DPoS:

• A more decentralized approach without concentrating power on delegates.
• Stimulating the performance of each node, not just a select few.

Disadvantages of PoP compared to DPoS:

• A more complex node and load management system.
• Possible difficulties in reaching consensus between a large number of shards.

The problems of the algorithms considered, the solution proposed by the PoP algorithm, the proof of the solution and the conclusions are presented in the following table:

Comparing the views of domestic and foreign researchers on the problem of scaling blockchain networks

Scientific research in the field of consensus algorithms and scalability of blockchain networks is actively developing both in foreign and domestic literature. However, approaches to solving these issues differ significantly.

1. Foreign research.

Foreign works, such as the study "Sharding-Based Proof-of-Stake Blockchain Protocols: Key Components & Probabilistic Security Analysis" focus on security and probabilistic assessment of the stability of consensus algorithms. The main focus is on their applicability in conditions of high network load and the ability to work with a large number of active nodes. In their study of the PoS model, the process of increasing network performance is considered through the introduction of sharding^[11].

Another example of studying the scaling process of blockchain networks is the work of Ittay Eyal, Adem Efe Gencer, Emin Gün Sirer and Robbert van Renesse "Bitcoin-NG: A Scalable Blockchain Protocol", in which the authors present the Bitcoin-NG protocol. He suggests dividing the blockchain into micro- and macroblocks to speed up transaction processing. However, it lacks mechanisms for dynamic load distribution between nodes, which makes it vulnerable to overloads^[12].

2. Domestic research.

In the work of Abdulzhalilov A.Z. "Methods and strategies for scalability of blockchain technologies: analysis, comparison and prospects", the author considers several methods that provide an increase in key network performance parameters through distributed list management systems, the use of sharding, the use of sidechains and the introduction of consensus algorithms friendly to the scaling process^[13].

V.N. Grepan highlights great attention to finding solutions to the problem of scalability in blockchain networks in his work "Practical problems of using blockchain technologies". In his work, he considers the possibility of increasing the size of blocks, the use of consensus algorithms with increased performance, sharding, the development of inter-blockchain solutions and optimization of protocols and algorithms as ways to solve the problem of scaling blockchain networks^[14].

3. The main differences.

According to the considered views on solving the problem of scalability of blockchain networks, it becomes clear that it makes sense to search for a method that would satisfy several tasks at once when building a scalability process.

The Proof of Performance (PoP) model offers several innovations that make a significant contribution to the development of consensus algorithms and scaling of blockchain networks:

1. Integration of horizontal sharding:

• Unlike most existing solutions, PoP combines sharding with adaptive node management, which allows you to simultaneously increase bandwidth and maintain network stability.

2. Dynamic load balancing system:

• PoP introduces a mechanism for calculating node performance and adaptive updating of their weights, which is not present in traditional approaches.

3. Fault tolerance:

• Experiments show that PoP retains network performance even when up to 20% of nodes fail, which surpasses the performance of other algorithms such as PoS.

4. Practical applicability:

• The PoP model was developed taking into account limited computing resources, which makes it especially relevant for implementation in the Russian Federation, including government and commercial projects.

Thus, a comparison of domestic and foreign studies has shown that the PoP model not only solves many well-known problems of consensus algorithms, but also offers new approaches that can be useful under real constraints. The increase in scientific knowledge lies in the development of a flexible node management system that increases the performance and stability of blockchain networks.

Conclusion

The article discusses the principle of operation of the Proof of Performance model, takes into account and describes its features, provides an analysis and an example of the algorithm. The analysis of the transaction processing speed was carried out and possible ways of its application were determined.

The presented and described model will allow to implement an adaptive approach to resource consumption, as well as to find a compromise between the needs for network performance and the costs of maintaining its operability.