Nonlinear Feedback Control and Stability Analysis of a Proof-of-Work Blockchain

In this paper a novel feedback controller and stability analysis of a blockchain implementation is developed by using a control engineering perspective. The controller output equals the diﬃculty adjustment in the mining process while the feedback variable is the average block time over a certain time period. The computational power (hash rate) of the miners is considered a disturbance in the model. The developed controller is tested against a simulation model with constant disturbance, step and ramp responses as well as with a high-frequency sinusoidal disturbance. Stability and a fast response is demonstrated in all these cases with a controller which adjusts it’s output at every new block. Finally the performance of the controller is implemented and demonstrated on a testnet with a constant hash rate as well as on the mainnet of a public open source blockchain project.


Introduction
The enabling technology in a cryptocurrency is a blockchain.A blockchain works by linking cryptographic information from previous blocks with the current block.The most common method currently used in blockchain implementations to calculate the cryptographic puzzle linking the blocks is called proof-ofwork (POW), first coined and formalized in Jakobsson and Juels (1999).In modern blockchain implementations POW is performed by computers called miners, typically utilizing massive parallelization in graphical processing units (GPUs) or Application-Specific Integrated Circuits (ASICs).
In most blockchain implementations it is desirable to have a near constant number of blocks generated per day to ensure timely execution of transactions.For example, if the goal is to generate blocks every 60 seconds, then the average number of blocks per day is 1440.The blockchain implementation must try to keep the number of blocks generated per day near constant even if there is large variation in computing power, also called hash rate, provided by the miners.Most POW blockchain implementations achieve a near constant generation of blocks per day by adjusting a parameter called "difficulty".
The difficulty relates to the complexity of the cryptographic puzzle which the miners have to solve.Hence, if the difficulty level increases proportionally with the combined hash rate of the miners, then the average block time should stay constant.Examples of recent algorithms for difficulty calculcations are described in Booth (2017) and Sechet (2017).
In Sechet (2017) some of the goals for the developed difficulty adjustment algorithm are stated as: 1) avoid sudden changes in difficulty when hash rate is fairly stable, 2) adjust difficulty rapidly when hash rate changes rapidly and 3) avoid oscillations from feedback between hash rate and difficulty.The algorithm in Sechet (2017) calculates an estimated hash rate, and then uses that as the basis of calculating a target.Booth (2017) presents an alternative algorithm where the difficulty starts with the difficulty target of the previous block, and then "nudges" it up or down, depending on the observed timestamps of past blocks.In this way the algorithm in Booth (2017) acts as a "feedback" mechanism.
Even though developers of recent difficulty adjustment algorithms use terms such as stability, oscillations, rapid changes and feedback there are currently, to the authors knowledge despite an extensive literature review, no publications available adressing the blockchain difficulty adjustment problem from a feedback control engineering perspective.
In this paper a novel nonlinear feedback controller and blockchain stability analysis is presented.The controller is tested and the performance is demonstrated in simulations as well as in both the testnet and mainnet of a real blockchain implementation.The selected blockchain implementation for the developed controller is the Bismuth project programmed in Python.The open source code of the Bismuth project is available at Kučera (2017).
The approach taken in this paper to develop a blockchain difficulty adjustment controller and to study the stability of the closed-loop system from a control engineering perspective may become a standard approach in the future.

Bismuth Blockchain Overview
Fig. 1 shows an overview of the proof-of-work algorithm used by the Bismuth blockchain.The sha224 cryptographic hash function is used.For a description of this function, see for example Penard and van Werkhoven (2007).A hash function is a mathematical algorithm which maps data of any length to a bit string of a fixed size.A hash function is also designed to be a one-way function, ie. a function which is infeasible to invert.
The algorithm in Fig. 1 makes use of nonces, see for example Rogaway (2004).In cryptography, a nonce is a pseudo-random number used only once.Pseudorandom nonce generators are often seeded by computers (milli-or nanosecond) clocks to make the generated nonces different on two or more computers running the same code.The proof-of-work algorithm in Fig. 1 works as follows: • The last stored block hash in the blockchain, the last stored miner address and the last stored nonce are hashed with sha224 generating a string of length 28 bytes or 224 bits.
• In Bismuth version 4.2.1.9the 28 bytes hash is run through a binary conversion function which doubles the number of bits to 448, see Table 1.
• A mining condition string is created by using the first D (difficulty) bits of the 448-bit string from the previous step.
• Several miners (computers) running in parallel on the network are using the last block hash stored on the blockchain, their own miner address and pseudo-random generated nonces to create unique sha224 hashes converted to 448 bit strings using the binary conversion in Table 1.The total number of such 448-bit strings generated per second in the entire network of computers is denoted H (hash rate) in this paper.
• The first miner to generate a 448-bit string which contains the difficulty adjusted mining condition substring becomes the winner.This miner's block hash, address and nonce are stored on the blockchain and the entire process repeats.

Simulation Model
In this section a simulation model for the Bismuth blockchain in Matlab/Simulink is developed.The developed model differs from typical simulation models, since the discrete time step in the model is selected as one block.In other words, the Simulink model is discretized and the simulation steps 1, 2, • • • , N correspond to block numbers in the blockchain.The actual time as measured in seconds between the blocks is given by the following equation.
where T is the estimated block time in seconds, D is the current difficulty in bits and H is the current hash rate in hashes per second.The floor() function in eq.(1) makes the system highly nonlinear and the model linearization for the frequency analysis becomes dependent on the perturbation levels used in the linearization.Hence, for the simulation and controller development in this paper the block time calculation is approximated by the following Matlab code: The effect of this approximation will be studied later in the paper.The developed controller will be designed with stability margins for robustness against the approximation.The ceil() function in eq. ( 1) results in a much smaller sensitivity with respect to variations in D and is kept in the simulated model.
The estimated current block time from Fig. 2 is fed into a moving average filter implemented by the following Matlab function: With an average block time of 60 seconds, there will be 1440 blocks per 24 hours.Hence, the moving average filter outputs the average block time over this period.In the function above Tin is the current block time while Tout is the averaged block time over the last 1440 blocks.The vectors T1 and T2 store the previous block times.The unit delay in Fig. 3 connects the two vectors T1 and T2.The initial condition of the unit delay when the simulation starts is a vector of size 1440 with all values equal to 60 seconds.The moving average filter is the most common filter in digital signal processing, mainly because it is the easiest digital filter to understand and use (implement), see Smith (1999).Fig. 4 shows the frequency response (Bode) plot of the moving average filter.As noted by Smith (1999): In spite of its simplicity, the moving average filter is optimal for a common task: reducing random noise while retaining a sharp step response.This makes it the premier filter for time domain encoded signals.However, the moving average is the worst filter for frequency domain encoded signals, with little ability to separate one band of frequencies from another.Relatives of the moving average filter include the Gaussian, Blackman, and multiple-pass moving average.These have slightly better performance in the frequency domain, at the expense of increased computation time.The closed-loop control system to be presented in Section 4 of this paper operates in frequencies where the moving average filter has a gain close to 1 (0dB).Hence, the drawback mentioned in Smith (1999) is not a major concern for the developed controller.

Feedback Controller
The proposed controller is illustrated in Fig. 5.The constant T d is the desired average block time equal to 60 seconds, T is the current average block time from the moving average filter presented in the previous section.T 1 is the average block time from the previous step, calculcated by the unit delay function.D is the difficulty and also the controller output.The Matlab In the code above H is the estimated network hash rate calculated from the current average block time T and the current difficulty D. D new is the approximated new difficulty to achieve the desired block time of T d = 60 seconds.The formula is an approximation because the current block time D is kept on the right-hand side of the equation.The effect of this approximation is small because of the ceil() function and also the division of 16, but it could have an effect at certain integer values of D. The effect of this approximation will be discussed in Section 5.The controller also contains a derivative term with a gain factor K d which is multiplied by the difference between the current and the previous average block time, T and T 1 .This term is subtracted from D new because of negative feedback.
In series with the difficulty estimation and the derivative term, there is a gain K and a discrete-time integrator with a feedback loop which is an easy and practical way to implement a lowpass filter.In the continuous time domain, the closed-loop transfer function of a gain and an integrator with a feedback loop is: Hence, the gain factor K becomes the cutoff frequency for a first-order lowpass filter.In practice, this low-pass filter is used to limit the frequency range of the derivative term previously described to low frequencies only.
In summary, the controller consists of a nonlinear model inversion term which estimates the next difficulty level from the desired block time, the current average block time and the previous difficult level.In addition there is a lowpass filtered derivative term with controller parameters K and K d .
Figure 6: The overall hash rate from the miners modelled as a disturbance into the system.
The hash rate of all the miners in the network combined is modelled as a disturbance into the system.In order to analyse the closed-loop performance of the simulated system Fig. 6 shows the disturbance modelled as a constant hash rate of 1.8 gigahashes per second (GH/s) plus three optional terms which allow to vary the disturbance as a step, ramp and sinusoidal function, respectively.Fig. 7 shows the overall control system model used in the Bismuth blockchain, version 4.2.1.9.The blocks marked in blue represent the blockchain system, the blocks marked in yellow represent the control system (difficulty adjustment calculation plus lowpass filtered derivative term) while the blocks marked in magenta represent the disturbance into the system (variation in the overall hash rate of the miners).The simulation step time defined in the zero-order hold function and the discrete-time integrator is set to 1, corresponding to one block in the blockchain.
The closed-loop system's bandwidth is defined as the frequency where the closed-loop gain equals -3dB, which occurs at 0.00202 rad/sec in Fig. 8 (blue curve).The frequency response plot was generated using Matlab's Control Systems Toolbox.The frequency 0.00202 rad/sec corresponds to B bw = 2π/0.00202= 3111 blocks or approximately 2.16 days with 1440 blocks per day.The red curve shows the closed-loop frequency response when the floor() function in eq. ( 1) is included.As can be seen from Fig. 8 the closed-loop bandwidth increases when the floor() function is included.A study of the closed-loop eigenvalues of the system, by using Matlab's Control Systems Toolbox, shows that the sta-bility margin is reduced when the floor() function is included.The amount of stability margin reduction depends on the perturbation levels used when linearizing the model.Fig. 9 shows the transfer function from the hash rate (disturbance) to the average block time (blue curve).The amplitude of this transfer function is always below −200dB, which is equivalent to a disturbance rejection of at least 10 −10 .Hence a sinusoidal disturbance hash rate of 10GH/s will cause a disturbance in the average block time of less than 1 second.The red curve shows the same frequency response with the floor() function in eq. ( 1) included.Interestingly, the disturbance rejection is improved by approximately 50dB, or a factor of more than 300, for low frequencies when the floor() function is included.
The absolute values of all the eigenvalues of the discrete state space model were found using Matlab's Control System Toolbox and the feedback control system is found to be stable.The largest absolute value of the eigenvalues when K = 1 720 and K d = 10 was found to be 0.9991 which is inside the unit circle and guarantees that the closed-loop system is stable, see Table 2.The controller parameter K can be increased by a factor 4.7 before the largest absolute eigenvalue is on the unit circle.Hence, the gain margin of the closed-loop system with respect to K is 4.7 = 13.4dB.The parameter K d can be increased to a large value without causing instability but the drawback is a reduction in closed-loop bandwidth when K d increases.

Simulation Results
This section contains simulation results using the Simulink model in Fig. 7. Fig. 10 shows the simulated average block time when the hash rate (disturbance) is doubled from 1.8 terrahashes (1.8 • 10 12 ) per second (TH/s) to 3.6TH/s at block number 10,000.The blue and the red curves are with K d = 0 and K d = 10, respectively.The simulation results show that the block time oscillates between 39 and 65 seconds, the settling time is approximately 4,000 blocks, there is zero steady-state error for a step disturbance and that the differentiation term of K d = 10 increases phase margin / reduces overshoot.The initial condition for the diffi-  Fig. 12 shows the simulation results when the hash rate is ramped up from 1.8TH/s to 5TH/s at a rate of 0.1GH/s per block.The ramp disturbance causes the block time to drop initially, but the error goes to zero as time goes to infinity, also if the ramp was not stopped at block 50,000.Fig. 13 shows the corresponding controller output (difficulty level for the mining condition).
Fig. 14 shows the simulated block time when a high-frequency sinusoidal disturbance with amplitude of 0.2TH/s and period of 100 blocks is added to the hash rate.100 blocks correspond to a frequency of 2π 100 = 0.0628rad/sec in the plot.At this frequency the disturbance rejection in Fig. 9 equals approximately −250dB or a gain of 3.16 • 10 −13 .This gain multiplied by 0.2TH/s gives a disturbance in the block time of 0.06s, which corresponds to the oscillations observed in Fig. 14.As can be seen in the figure, the derivative term K d = 10 has no negative impact on the highfrequency disturbance rejection.Fig. 15 shows the corresponding controller output.
In eq. ( 1) and implemented in Fig. 2 there is the expression ceil(28-D/16).When developing the controller it was assumed that this term was constant, but at certain difficulty levels this will not be the case.For example, if D=112 we get ceil(28-D/16)=21, while D=111.99 results in ceil(28-D/16)=22.These discontinuities in the system model will affect the closed-loop control system.Consider a case when the overall hash rate (disturbance) is set to a constant of 55.9TH/s and the initial difficulty D=110.Fig. 16     Figure 16: Stable oscillations in average block time between 58.3s and 61.7s when hash rate is constant at 55.9 TH/s.K d = 0 for the blue curve, while K d = 10 for the red curve.oscillcations are reduced to an amplitude of 0.81 seconds.In other words, the derivative term K d increases the damping in the closed-loop system and reduces the oscillation in this particular case by a factor 2.7.Fig. 17 shows the corresponding controller output (difficulty) as it initially starts at 110 and goes towards 112.The stable oscillations in the controller output are caused by the discontinuous ceil() function in the system model.This behaviour of the closed-loop system will occur at the following discrete set of difficulty levels D ∈ {8, 16, 24, • • • , 432}.

Blockchain Network Results
In addition to simulations the difficulty adjustment feedback controller developed in this paper is implemented in the Bismuth blockchain as of version 4.2.1.9.The code in Fig. 24 shows the actual code implemented in Python.Fig. 18 shows the block time when the developed controller is running on testnet with a constant hash rate.In this example testnet consisted only of one single node and two miners.Fig. 19 shows the corresponding difficulty level which initially started at 86.25.Since the initial difficulty in this test was too high for the available hash rate from the miners, the block time increases from 60 seconds to about 105 seconds, before the feedback controller reduces the difficulty and brings it back to the desired level of 60 seconds.Since the miners only generate solutions with integer difficulties, it is interesting to notice from Figs. 18 and Fig. 19 that the best level of control is achieved when the difficulty is close to the integer value of 84.This occurs near block number 7,500.If the block time goes above the desired value of 60 seconds, then the controller adjusts the difficulty to slightly below 84.0.Similarly, if the difficulty goes below the desired value of 60 seconds, then the controller adjusts the difficulty to slightly above 84.0.
From block 8,000 to 10,000 in Fig. 18 the mean value of the block time is 59.80 seconds while the standard deviation is 0.66 seconds, which is considered a good result.Mining and generation of blocks is a stochastic process, hence on testnet the block time will not settle exactly at the desired reference level as it does in the simulations when the hash rate is constant.at block 427,000 on December 15, 2017 at UTC time 22:36:51. Figs. 20,21 and 22 show the mainnet block time, difficulty and estimated hash rate starting from block 427,000.The initial condition for the block time was slightly above 45 seconds, due to the previous difficulty adjustment algorithm used on mainnet.For the first 500 blocks in the plots the new controller and the previous algorithm were compatible, then at block 500 the chains forked and as a result the hash power was divided between the two chains.Due to the reduced hash rate the block time increased sharply to above 70 seconds while the controller reduced the difficulty below 103, as shown in Figs.21-20.Then at approximately block 2000 in the plots all the major miners updated to the new version and the hash rate increased sharply as seen in Fig. 22, which as a result caused the blocktime to decrease sharply to 37 seconds.For the remaining blocks 2000-13000 the feedback controller works continuously to keep the blocktime near 60 seconds, de-spite large variations in the hash rate (disturbance) as miners come and go.The results from mainnet demonstrate that the proposed feedback controller presented in this paper stabilizes the system.In eq. ( 1) it can be seen from 2 floor(D/2) that the block time should theoretically increase by a factor of √ 2 when D increases by 1 and the hash rate is constant.The developer EggdraSyl at EggPool.Net which is one of the largest mining pools for the Bismuth blockchain, has analyzed the theoretical increase in difficulty vs. the real solutions generated by the miners contributing to the pool.Fig. 23 (top) shows that there is some discrepancy between the modelled difficulty increase and the statistical analysis.While the overall reduction in block generation matches well with 1/ √ 2, there are variations between the different levels.For example, the reason why D = 104 occurs relatively seldom and 105 relatively often, is that 104/8 is a whole integer.The first bit in the next byte is then always a zero introduced by the binary conversion in Table 1.This means that hits on 104 will almost always also give hits on 105.This behavior occurs for other integer values of D/8, for example 96 and 112 (± 8 bits from 104).

Discussion and Conclusions
In this paper a simulation model for the Bismuth blockchain has been developed and implemented.The model has been validated by a statistical analysis of miners solutions vs. difficulty levels from a sample of more than 500,000 solutions provided by EggPool.Net.
Although there are variations in the increase at different levels of difficulty, the overall trend of increase matches the theoretical average of √ 2. A novel control algorithm for the difficulty adjustment has been developed, analyzed and implemented.The controller estimates the total hash rate H in the network based on the current levels of difficulty D and average block time T .This part of the controller is an approximated model inversion of the system model illustrated in Fig. 2. A discontinuous function (floor()) in eq. ( 1) is not invertible and hence has not been included in the inversion and system simulation.Instead, this approximation is seen as a model uncertainty and handled by the stability margins of the closed-loop controller.In addition to the model inversion, a derivative term multiplied by the gain K d is introduced, which significantly reduces oscillations and increases the stability margin of the closed-loop system.
The proposed controller has been tested not only in simulations but also on a testnet using a constant hash rate and on the mainnet of the Bismuth blockchain starting from block 427,000 where there are relatively rapid changes in the overall hash rate.In both implementations the proposed controller has performed as expected and in correspondance with the simulation results.By using the simulation model presented in this paper controller designs can be tested and analyzed in a few seconds compared to typically several days for an implementation on a testnet.

Figure 1 :
Figure 1: Overview of the proof-of-work algorithm used by the Bismuth blockchain.

Figure 2 :
Figure 2: Block time T as a function of hash rate H and difficulty D.

Figure 3 :
Figure 3: Calculation of the average block time from the last 1440 blocks using a moving average filter.

Figure 4 :
Figure 4: Frequency response of the moving average filter of length 1440.

Figure 5 :
Figure 5: Proposed controller for the difficulty adjustment.

Figure 8 :
Figure 8: Closed-loop frequency response from desired block time T d to moving-average block time T with controller parameters K = 1 720 and K d = 10.The red and blue curves are with and without the floor() function in eq.(1), respectively.

Figure 9 :
Figure 9: Frequency response from disturbance (hash rate) H to moving-average block time T with controller parameters K = 1 720 and K d = 10.The red and blue curves are with and without the floor() function in eq.(1), respectively.

Figure 11 :Figure 12 :
Figure 11: Difficulty when hash rate is doubled from 1.8TH/s to 3.6TH/s at block 10000.K d = 0 for the blue curve, while K d = 10 for the red curve.

Figure 15 :
Figure 15: Controller output (difficulty) when a highfrequency sinusoidal disturbance with amplitude of 0.2TH/s and period of 100 blocks is added to the hash rate.K d = 0 for the blue curve, while K d = 10 for the red curve.

Figure 17 :
Figure 17: Stable oscillations in controller output (difficulty) between 111.98 and 112.02 when hash rate is constant at 55.9 TH/s.K d = 0 for the blue curve, while K d = 10 for the red curve.

Figure 18 :
Figure 18: Block time as a function of block number on testnet.Initial difficulty equals 86.26.

Figure 19 :
Figure 19: Difficulty as a function of block number on testnet.Initial difficulty equals 86.26.

Figure 20 :Figure 21 :Figure 22 :
Figure 20: Block time as a function of block number on mainnet starting from block 427,000.

Figure 23 :
Figure 23: Top: Analysis of solutions from miners vs. difficulty.The blue curve shows a statistical sample of 556,728 solutions from Egg-Pool.Net, while the red curve is based on eq.(1).Bottom: Real increase in difficulty at different difficulty levels.Figures based on data from EggPool.Net.

Figure 25 :
Figure 25: Python3 code for extracting the Simulink model in Fig. 7 from the blockchain, block 406,054, transaction 0. The JSON data for the Simulink model is stored in the OpenField, array index 11.

Table 2 :
Closed-loop performance as a function of the controller parameters K and K d .
then shows the response in the average block time.With K d = 0 stable oscillations with amplitude 2.18 seconds around the desired block time occur, while with K d = 10 these