SPECTER : A New Scalable and Fast Cryptocurrency Protocol

One of the big issues with bitcoin’s blockchain is the scalability of the protocol which means that the blockchain cannot process a high transaction throughput rate, mainly because the block size has to be kept to a minimum, and their production rate has to be low to guarantee that mining nodes can reach consensus in a secure manner. As of today, the bitcoin blockchain can process no more than 7 transactions per second and it takes a transaction an average of a few minutes to be confirmed and recorded on the public ledger.

A group of researchers from The Hebrew University of Jerusalem, Israel, have published a paper that introduced a new cryptocurrency protocol, SPECTRE, that can promote security with high rates of transaction throughput while also markedly reducing transaction confirmation times. Given any transaction throughput rates, SPECTRE is resistant to attackers even if they control up to 50% of the mining nodes across the network (up to the limit determined by bandwidth constraints and network congestion is reached). SPECTRE was coded to adapt to high rates of block production, so a transaction on its blockchain would be confirmed in a few seconds and the confirmation time is mainly determined by the round-trip-time of the SPECTRE network.

Simulation Results of Implementation of the SPECTRE Protocol:

I won’t delve into the technical aspect of the SPECTER protocol as you can check this via reading the paper published a few days ago.

The researchers used Python to implement the SPECTER protocol, while also utilizing an event driven network dynamics simulator. During each of their simulation experiments, they used 20 nodes to create an Erdӧs-Rḕnyi network topology randomly. Each node would create 5 outgoing links. Each link faced a time delay that is uniformly distributed and then scaled in a linear manner to achieve a graph diameter of d (for any given d). Each point on the graph would represent the average of the outcome of at least 500 simulation experiments.

The main focus of SPECTER is to promote a short transaction confirmation time. To achieve this, the creators of SPECTER utilized 7 algorithms. They used the online acceptance policy, which is formulated using Algorithm 7, to measure the exact time for each transaction to be confirmed on SPECTRE’s blockchain. However, the receiver of the payment would have to wait for an additional time equal to d seconds to ensure that there are no double spend attacks linked to the transaction.

At high block production rates, the time needed to confirm a transaction is mostly determined by propagation delay of the block across the nodes of the network. The below figure represents the confirmation time of SPECTRE’s transactions, ahead of different delay diameter d values, and various security thresholds ϵ. Unlike Satoshi Nakamoto’s consensus, the value of d can only affect the confirmation time of a given transaction, but not its security. The protocol will return ACCEPT when a transaction is confirmed after excluding the possibility of a double spend attack.

How Can Confirmation, or Acceptance, Time Be Affected By The Block Production Rate?

The below figure plots the acceptance times at different block production rate values λ, within a constant delay period of 5 seconds. The graph proves λ’s rule in the symptotic bound. In other words, increasing the block production rate will lead to an increase in the transaction confirmation rate as well. On the contrary, with a block production rate of 1/600 on bitcoin’s blockchain, this will lead to a periods of confirmation that are very high.

Can Attacking Nodes Delay Confirmation of Transactions?

Censorship attacks is a type of malicious attacks throughout which a group of dishonest nodes will broadcast blocks that don’t represent the blocks produced by the miners. SPECTER has a property that was referred to “Weak Liveness”, by the coin creators, which ensures fast confirmation of transactions that don’t seem to be part of double spend attacks whenever a censorship attack takes place. However, such attacks will still cause some delay in confirmation of transactions, which is minimal in case of small attacks. The below figure illustrates this effect by comparing the confirmation times in normal states to those when a censorship attack is taking place. The parameters shown below are at d = 5 seconds, ϵ = 0.01 and λ = 10 blocks per second. The graph shows a mild effect due to the attack, and it also concludes that an attacker has to control a high percentage of the network’s hash power to be able to delay transaction’s confirmation time by more than 5-10 seconds.