One of the frustrations of the blockchain as a decentralized system is the considerable duration of delay before a transaction gets completed. A single confirmation in the Bitcoin network takes an average of ten minutes, but in practice, because of statistical phenomena, when one initiates a transaction, a confirmation can only be anticipated within ten minutes approximately 63.2% of the time; 36.8% of the time it will require more than ten minutes, 13.5% of the time longer than twenty minutes, and 0.25% of the time longer than an hour. Due to intricate technical aspects related to Finney attacks<\/a> and sub-50% double spends<\/a>, for numerous applications, even a single confirmation is inadequate; gambling platforms and exchanges frequently have to wait for three to six blocks to emerge, often exceeding an hour, before a deposit gets verified. In the period before a transaction is included in a block, security is nearly negligible; although many miners decline to propagate transactions that conflict with previously sent ones, there is no financial incentive for them to do so (in fact, quite the opposite), and some do not, making it possible to reverse an unconfirmed transaction with about a 10-20% success rate.<\/p>\n <\/p>\n In numerous situations, this is acceptable; if you purchase a laptop online and manage to retract the funds five minutes later, the seller can simply cancel the shipment; online subscription services function in a similar manner. However, in the scenario of certain face-to-face transactions and virtual goods purchases, it is quite inconvenient. Specifically, in the context of Ethereum, the inconvenience is heightened; we aim to be not merely a currency, but a comprehensive platform for decentralized applications, and especially regarding non-financial applications, users typically expect a significantly quicker response time. Therefore, for our aims, having a blockchain that operates faster than 10 minutes is crucial. The inquiry then is, how low can we go, and if we decrease it too much, does that cause any destabilization?<\/p>\n <\/p>\n <\/p>\n To begin with, let\u2019s provide a brief overview of how mining operates. The Bitcoin blockchain consists of a series of blocks, with each one linking to (i.e., containing the hash of) its predecessor. Each miner in the network endeavors to generate blocks by first gathering the required data (previous block, transactions, time, etc.), constructing the block header, and then repeatedly adjusting a value known as the nonce until the nonce fulfills a condition referred to as “proof of work” (or “mining algorithm”). This algorithm is stochastic and generally fails; on average, in Bitcoin, the network must collectively make approximately 1020<\/sup> attempts before discovering a valid block. Once a random miner discovers a block that is valid (i.e., it references a legitimate prior block, its transactions and metadata are accurate, and its nonce meets the PoW condition), then that block is disseminated across the network and the process restarts. As compensation, the miner of that block receives a certain quantity of coins (25 BTC in Bitcoin) as a reward.<\/p>\n <\/p>\n The “score” of a block is defined in a simplified manner as the total number of blocks in the chain leading back to the genesis (formally, it\u2019s the cumulative mining difficulty, meaning that if the difficulty of the proof of work condition escalates, blocks generated under this new more rigorous condition count for more). The block with the highest score is regarded as “truth.” A subtle, yet significant, detail is that in this model, the motivation for miners is consistently to mine on the block with the highest score, because the block with the highest score is what users ultimately prioritize, and there are never any considerations that make a lower-score block preferable. If we alter the scoring model, then if we’re not vigilant this might change; but more on this later.<\/p>\n <\/p>\n We can represent this kind of network as follows:<\/p>\n However, complications emerge when we consider that network propagation is not instantaneous. According to a 2013 study<\/a> by Decker and Wattenhofer in Zurich, once a miner generates a block, on average it takes 6.5 seconds for the block to reach 50% of nodes, 40 seconds for it to reach 95% of nodes, with a mean delay of 12.6 seconds. Consequently, a more precise model might be:<\/p>\n This gives rise to the subsequent issue: if, at time T = 500, miner M mines a block B’<\/span> on top of B<\/span> (where “on top of” indicates “pointing to as the previous block in the chain”), then miner N may not learn about the block until time T = 510, thus until T = 510 miner N will continue mining on B. If miner B produces a block in that timeframe, the rest of the network will reject miner B’s block because they have already observed miner M’s block which has an equivalent score:<\/p>\n <\/p>\n So what are the issues with this? In reality, there are two concerns. Firstly, it undermines the absolute strength of the network in defense against attacks. At a block time of 600 seconds, as in Bitcoin, this isn’t a problem; 12 seconds is quite a brief period, and Decker and Wattenhofer estimate the total stale rate to be around 1.7%. Therefore, an attacker does not necessarily require 50.001% of the network to execute a 51% assault; if the attacker is a single node, they would need only 0.983 \/ 1 + 0.983<\/span> = 49.5%. We can evaluate this through a mathematical expression: if transit time is 12 seconds, then after a block is produced, the network will generate stales for 12 seconds prior to the block propagating, so we can presume an average of 12 \/ 600 = 0.02<\/span> stales per valid block or a stale rate of 1.97%. However, with 60 seconds per block, we encounter 12 \/ 60 = 0.2<\/span> stales per valid block or a stale rate of 16.67%. At 12 seconds per block, we discover 12 \/ 12 = 1<\/span> stale per valid block, indicating a stale rate of 50%. Hence, we can observe the network becoming substantially weaker against attacks.<\/p>\n <\/p>\n Nevertheless, there is also an additional unfavorable effect of stale rates. One of the more urgent challenges within the mining ecosystem is the issue of mining centralization<\/a>. Presently, the majority of the Bitcoin network is divided into a small number of “mining pools”, centralized entities where miners collaborate resources to receive a more even reward, and the largest of these pools has been fluctuating between 33% and 51% of the network hash power for several months. In the future, even individual miners <\/p>\n How do stale rates influence centralization? The response is quite astute. Imagine having a network of 7000 pools each with 0.01% hashpower, alongside a single pool holding 30% hashpower. 70% of the time, the last block is generated by one of these miners, which the network acknowledges in 12 seconds, reflecting some inefficiency but ultimately maintaining fairness. However, 30% of the time, it is the mining pool with 30% hashpower that creates the last block; consequently, it “receives” the notification of the block immediately, resulting in a 0% stale rate, while all others continue to sustain their complete stale rate.<\/p>\n <\/p>\n Due to the simplicity of our model, we can still engage in some calculations using an approximation in a closed form. With a transit time of 12 seconds and a block duration of 60 seconds, we ascertain a stale rate of 16.67% as elucidated earlier. The mining pool holding 30% will have a 0% stale rate for 30% of the time, resulting in an efficiency multiplier of 0.833 * 0.7 + 1 * 0.3 = 0.8831<\/span>, while the rest will have an efficiency multiplier of 0.833; this translates to a 5.7% efficiency improvement, which is rather economically notable, especially for mining pools where the fee disparity is merely a fraction of a percent in either direction. Therefore, to achieve a 60-second block time, a more effective strategy is essential.<\/p>\n <\/p>\n <\/p>\n The inception of a more effective method arises from a document titled “Fast Money Grows on Trees, not Chains<\/a>“, published by Aviv Zohar and Yonatan Sompolinsky in December 2013. The concept posits that although stale blocks are not presently considered part of the total weight of the chain, they could be; hence they advocate for a blockchain scoring framework that incorporates stale blocks even if they are not part of the main chain. Consequently, even if the primary chain is only 50% effective or even 5% efficient, an assailant attempting a 51% attack would still need to surpass the weight of the complete network. This, in theory, addresses the efficiency dilemma down to 1-second block times. However, a challenge arises: the protocol, as delineated, only factors stales into the blockchain scoring; it does not allocate stales a block reward. Thus, it does nothing to rectify the centralization issue; indeed, with a 1-second block time, the most probable outcome would entail the 30% mining pool simply generating every<\/em> block. Naturally, the 30% mining pool producing every block on the main chain<\/em> is acceptable, but only if the blocks off chain are also equitably compensated, ensuring the 30% mining pool does not accumulate significantly more than 30% of the revenue. However, for that, rewarding stales will be necessary.<\/p>\n <\/p>\n Currently, we can’t reward all stales perpetually; that would result in a bookkeeping catastrophe (the algorithm would need to meticulously verify that a newly included uncle had never been incorporated previously, thus necessitating an “uncle tree” alongside the transaction tree and state tree in each block) and, more critically, it would render double-spending costless. Therefore, let\u2019s formulate our initial protocol, single-level GHOST, which executes the minimum requirement and accounts for uncles only up to one level (this is the methodology employed in Ethereum to date):<\/p>\n <\/p>\n <\/p>\n Thus, in the illustrated blockchain example provided earlier, we will have something resembling this:<\/p>\n Here, the calculations become more intricate, prompting us to make some intuitive assertions and subsequently take a more relaxed approach by simulating the entire scenario. The fundamental intuitive assertion is this: in the basic mining protocol, for the reasons previously explained, the stale rate is approximately t\/(T+t)<\/span> where t<\/span> signifies the transit time and T<\/span> represents the block interval, as t\/T<\/span> of the time miners are mining on outdated information. With single-level GHOST, the failure threshold shifts from mining one stale to mining two stales in succession (as uncles can be included but relatives with a divergence of two or higher cannot), thus the stale rate should be (t\/T)^2<\/span>, approximately 2.7% instead of 16.7%. Now, let us utilize a Python script<\/a> to verify that hypothesis:<\/p>\n <\/p>\n <\/p>\n The findings can be interpreted as such. The top five figures serve as a centralization metric; in this instance, it indicates that a miner with 25% hash power receives 25.39 times the reward of a miner with 1% hash power. The effectiveness is 0.9798, implying that 2.02% of all blocks are completely excluded, resulting in an average of 0.158 uncles per block; consequently, our assumptions regarding a ~16% stale ratio without uncle consideration and 2.7% with uncle consideration are nearly verified. It’s noteworthy that the actual block interval stands at 70.85 seconds because, despite a valid proof of work solution existing every 60 seconds, 2% of those are lost while 14% enter the subsequent block as an uncle instead of the primary chain.<\/p>\n <\/p>\n At this point, an issue arises. The initial authors of the GHOST document omitted uncle\/stale rewards, and although I think deviating from their guidance is warranted for the reasons outlined previously, they chose to forgo this for a specific rationale: it complicates the economic analysis. Specifically, when only the primary chain receives rewards, there exists a clear justification for consistently mining on the head rather than a previous block, primarily due to the fact that the sole differentiating factor between any two blocks is their score, with higher scores evidently being preferable to lower ones. However, once uncle rewards are introduced, additional factors complicate the scenario.<\/p>\n <\/p>\n To illustrate, let\u2019s consider when the main chain has its latest block M<\/span> (score 502) with parent L<\/span> (score 501) and further parent K<\/span> (score 500). Assume also that K<\/span> has two stale offsprings, both of which were created after M<\/span>, thus there was no possibility for them to be included in M<\/span> as uncles. By mining on M<\/span>, you would generate a block with a score of 502 + 1 = 503<\/span> and a reward of 1. Conversely, by mining on L<\/span>, you could incorporate K<\/span>‘s children, yielding a block with a score of 501 + 1 + 2 = 504<\/span> and a reward of 1 + 0.0625 * 2 = 1.125<\/span>.<\/p>\n Furthermore, there exists a selfish-mining<\/a>-like assault against single-level GHOST. The premise is as such: if a mining pool possessing 25% hash power were to exclude any other blocks, in the short run, it would be detrimental to itself as it would miss out on the 1\/16x nephew reward, but it would inflict greater harm upon others. Since mining is essentially a zero-sum endeavor over the long haul, as the block interval averages to maintain stable issuance, this suggests that the exclusion of uncles might, in fact, represent a dominant strategy, thus centralization worries are not entirely alleviated (specifically, they still persist 30% of the time). Moreover, if we pursue increasing the speed further, targeting a 12-second block time, the single-level model simply does not suffice. Here’s a result incorporating those metrics:<\/p>\n <\/p>\n <\/p>\n 18% centralization <\/p>\n <\/p>\n The initial concept I experimented with around a week prior was mandating that every block includes five uncles; this would, in a way, further decentralize the creation of each block, guaranteeing that no miner held a distinct edge in generating the next block. Given that the calculations for this are quite frustratingly complex (well, if you devote considerable time to it, perhaps you could devise something utilizing nested Poisson processes and combinatorial generating functions, but I’d prefer not to), here\u2019s the simulation script<\/a>. Take note that there are in fact two methods to implement the algorithm: require the parent to be the lowest-hash child of the grandparent, or mandate that the parent be the highest-score child of the grandparent. The initial method (to implement this independently, adjust line 56 to if newblock[“id”] > self.blocks[self.head][“id”]:<\/span>, we obtain this:<\/p>\n <\/p>\n <\/p>\n Whoops! Let\u2019s attempt the highest-score model instead:<\/p>\n <\/p>\n <\/p>\n Here we observe a surprisingly counterintuitive outcome: the mining pool with 25% hash power yields merely 24 times the reward in comparison to a 1% hash power pool. Economic sublinearity remains a cryptoeconomic elusive goal, however, it also behaves somewhat like a perpetual motion machine; unless one depends on a specific resource that individuals possess a finite amount of (for instance, domestic heating demand, idle CPU capacity), there lacks a method to circumvent the reality that even if you devise some innovative sublinear arrangement, an entity with 25 times the input power can at minimum masquerade as 25 distinct entities and thereby claim a 1x reward. Consequently, we present clear (alright, fine, with 99 point something percent confidence) empirical evidence that the 25x miners are functioning suboptimally, indicating that the best approach in this context is not to consistently mine the block.with the utmost score.<\/p>\n <\/p>\n The rationale here is the following: if you mine on a block that possesses the utmost score, then there exists a possibility that another entity might unearth a new uncle from one level back, subsequently mining a block atop that, thereby generating a new block at the same tier as your block but with a marginally superior score, leaving you in a disadvantaged position. However, if you attempt to be one of those uncles, the block with the highest score at the subsequent level will undoubtedly seek to include you, thus granting you the uncle reward. The emergence of one unorthodox strategy strongly implies the presence of additional, more exploitative, unconventional strategies, hence we will not pursue this path. Nevertheless, I opted to incorporate it into the blog entry to illustrate an instance of the inherent dangers.<\/p>\n <\/p>\n So what is the optimal path ahead? It turns out that it is quite straightforward. Revert to single level GHOST, but permit uncles to originate from as far back as 5 blocks. Consequently, the child of a parent of a parent (hereinafter referred to as the -2,+1-ancestor) is a valid uncle, as is a -3,+1-ancestor, a -4,+1-ancestor, and a -5,+1-ancestor, while a -6,+1-ancestor or a -4,+2-ancestor (for example, c(c(P(P(P(P(P(head))))))<\/span> where no simplification is feasible) is not. Additionally, we enhance the uncle reward to 15\/16 and reduce the nephew reward to 1\/32. First, let’s ensure that it operates correctly under conventional strategies. In the GHOST simulation script, set UNCLE_DEPTH<\/span> to 4, POW_SOLUTION_TIME<\/span> to 12, TRANSIT_TIME<\/span> to 12, UNCLE_REWARD_COEFF<\/span> to 15\/16 and NEPHEW_REWARD_COEFF<\/span> to 1\/32 and observe the results:<\/p>\n <\/p>\nSummary of Mining<\/h3>\n
\n<\/p>\n![](\"https:\/\/blog.ethereum.org\/images\/posts\/2014\/07\/minernet2.png\")
\n<\/p>\n![](\"https:\/\/blog.ethereum.org\/images\/posts\/2014\/07\/minernet3.png\")
\n<\/p>\nStales, Efficiency, and Centralization<\/h3>\n
\n“`may demonstrate hazardous; at present, 25% of all new bitcoin mining apparatus are emerging from a singular plant in Shenzhen, and if the unfavorable interpretation of my economic evaluation<\/a> is accurate, it might ultimately transform into 25% of all Bitcoin miners being confined to one factory in Shenzhen.<\/p>\nGHOST<\/h3>\n
\n
![](\"https:\/\/blog.ethereum.org\/images\/posts\/2014\/07\/minernet4.png\")
\n<\/p>\n### PRINTING RESULTS ###<\/span>\n<\/span>![](\"https:\/\/blog.ethereum.org\/images\/posts\/2014\/07\/minernet51.png\")
\n<\/p>\n### DISPLAYING RESULTS ###<\/span>\n<\/span>
\n“`gain. Hence, we require a different approach.<\/p>\nA Fresh Approach<\/h3>\n
### PRINTING RESULTS ###<\/span>\n<\/span>### PRINTING RESULTS ###<\/span>\n<\/span>### PRINTING RESULTS ###<\/span>\n<\/span>