8 Min Read 
The Bitcoin Cash (BCH) development community has established a culture of continuous, regular improvement. For the time being, the community seeks to upgrade the network twice a year on May 15 and November 15. The purpose of the upgrades are usually aimed at improving the network’s scalability, improving the user experience, and improving the protocol’s ability to evolve.
Although there are a lot of proposals under development or under discussion in the community, we’ll cover two of them that BCH developers are actively working on.
Storm
In the Bitcoin Cash network, blocks of transactions are validated approximately every ten minutes. Unfortunately, waiting ten minutes for a confirmation can be too long in many brick and mortar retail situations. The ten minute block time is an early and somewhat arbitrary choice by the creator(s) of Bitcoin, but its arbitrariness doesn’t diminish its importance because of its relation to BCH’s emission schedule. The emission rate of new Bitcoin Cash is somewhat sacred because of the community. Attempting to shorten the validation time would probably be contentious, and shaving off minutes will still be slower than other payment methods out in the market today.
The Bitcoin Cash development community has been working on a way to work around this long waiting time without altering it. Developers have proposed a method of determining the probability that a transaction will be included in the next block without officially being confirmed by the network. The proposed pre-consensus payment solution is called Storm. The implementation of Storm can give senders and receivers more of the experience they’re used to with other payment mechanisms without changing a key parameter of BCH.
The Storm proposal builds off a concept known as weak blocks. “Weak” blocks are blocks that have been put together by miners, but do not have the appropriate amount of proof of work (POW) to be considered valid. In contrast, blocks that are constructed with the appropriate POW are considered “strong blocks”.
Although weak blocks don’t have the right answer to the proof of work problem, they can be useful for generating an understanding of what transactions are likely to be included in the next strong block.
For example, if the current state of the network requires miners to produce a hash that contains at least 50 leading zeros, producing a hash with 48 leading zeros would be close, but not strong enough to be considered valid. Although work was done, the hash didn’t meet the threshold needed and the associated block is often discarded by the miner. However, this “waste” of a block can be useful for the network if it’s shared. If miners communicate weak blocks to each other they can let each other know which transactions they’re trying to include in their block. When one of the miners finally does produce the correct hash with the appropriate proof of work the rest of the network could already know which transactions the winning miner was working on. This prior knowledge minimizes the amount of data that needs to be communicated by the winning miner to the rest of the network and can give users a high degree of confidence in the eventual validation of their transaction.
However, the incentives to engage and maintain a chain of weak blocks are said to be too weak to be followed by miners reliably. In addition, the rate at which weak blocks can be communicated throughout the network is too slow for instant transactions, a goal of BCH developers. Although it is much faster than waiting for a strong block, reducing wait time to a few dozen seconds, this is still too slow for the instant transactions BCH developers are pushing for. The Storm proposal is an update to the concept of weak blocks that addresses these criticisms with an update called Delta blocks.
Delta blocks are blocks that can be constructed and updated during the time lag between strong blocks by constantly merging all of the weak blocks and their associated transaction sets. By constantly merging weak blocks, everyone on the network can figure out what priority transactions have on the network and the probability of a transaction being included in the next strong block. The delta blocks act as a reference for inference.
For example, imagine there are ten miners on the BCH network and all of them are mining a transaction I’ve made. I don’t know who will produce the hash with the appropriate proof of work, but I know one miner will eventually win the proof of work race. If all of them are mining my transaction I can reasonably assume my transaction will be included in the next strong block regardless of who wins.
By constantly merging weak blocks into delta blocks users can get high statistical assurances that their transaction will be in the next block by scanning the delta blocks. Transactions inside of the delta blocks have a high probability of official confirmation. The statistical assurances allow merchants to accept the validity of a payment in mere seconds rather than waiting 10 min for an official confirmation from a strong block.
This is a big deal in the retail context. Users of cash, credit cards, and payment apps are used to fast transaction times. Creating a fast payment experience without changing the rules of consensus is an elegant solution to a very hard problem.
To solve the incentive problem the Storm proposal advocates amending the proof of work (POW) consensus rule in BCH from the chain of most cumulative POW by adding in a tie breaker between two competing POW chains. The tie breaker would be a weak proof of work chain (wPOW). If two competing chains have equivalent POW then the chain with the most cumulative wPOW associated with it would be chosen as the canonical chain. This tie-breaker encourages a miner to share their weak blocks to the network because when there are disputes between two competing histories, they can nudge the network towards their interpretation of the proper order of transactions.
Graphene v2
The graphene protocol has already been added to Bitcoin Cash, but we’ll cover what it is and describe some of the improvements that will be included in the next version of Graphene.
Graphene, at a high level, is an efficient means of communicating new blocks to the network. The content of blocks, transactions, must be validated by others on the network. The validation process takes some time and some of the validation done by nodes can be unnecessary or redundant, slowing down block propagation. Making this process more efficient and squeezing out bottlenecks can allow bigger and bigger blocks of transactions to flow throughout the network without issues. A more efficient means of propagation means the possibility for greater transaction throughput in the future.
The graphene protocol makes use of two technologies: bloom filters and invertible bloom look up tables (IBLTs). These technologies help reconcile between what a node already knows and what information it needs to know from another node. Previously, without the help of Graphene, nodes were communicating blocks to others by dumping all of the raw transaction data on them without taking into account what the node they’re communicating with already knows.
However, using the filter and the table, nodes can determine with high probability what a node already knows about a certain set of those transactions. After determining what their peer knows they only need to send transaction data that is non-redundant or unknown. This method is more efficient than every node dumping all the transaction data on every other node, regardless of what the receiving node already knows. This makes block propagation more efficient, because it reduces the data that needs to be transmitted between peers on the network.
The Graphene protocol, as described above, has been live in Bitcoin Cash for some time now, but developers are hard at work optimizing the protocol’s performance and lowering the probabilities of failures.
According to preliminary tests of version two of Graphene, developers have been able to dramatically lower block decoding failure rates and they’ve also lowered the time required to construct and deconstruct Graphene blocks by about 30%.
Developers have also been able to improve compression (making blocks smaller) rates of graphene blocks by taking advantage of a previous upgrade of BCH known as CTOR (canonical transaction ordering). Before CTOR was introduced, nodes could organize the transactions in their block in a wide range of ways. As a consequence, nodes had to include information about the way transactions were organized in a block. However, under a CTOR regime every node organizes transactions in the same manner. Graphene developers have updated the protocol to take CTOR ordering into account. This means that nodes don’t have to include transaction ordering information to other nodes in their graphene block, because all transactions are ordered in the same way throughout the network.
Reducing the amount of information that needs to be communicated reduces the time it takes to compress blocks and communicate them. Smoother and quicker block propagation lays the groundwork for increases in transaction throughput, while avoiding a subsequent decrease in performance.
Conclusion
Storm and Graphene address two major issues in cryptocurrency development: user experience and scaling. Bitcoin Cash developers are solving these issues as aggressively and thoughtfully as possible. We’re excited to support users of BCH and look forward to the network’s continued development.
