Quantum resistant blockchain and cryptocurrency, the full analysis in seven parts. Part 4.

Part 1 here, part 2 here and part 3 here

In the next two parts I will be analyzing the challenges of upgrading an existing blockchain to a quantum resistant blockchain.

The first challenge to shed some light on, would be the changing of the signature scheme: It is important to start with mentioning the simple fact that a launched, working blockchain isn’t something that can be adjusted with the flip of a switch. Upgrading a blockchain to a post-quantum signature scheme is no small undertaking. Changing a signature scheme is not just copy paste and change some lines of code. It’s actually a decent amount of coding that needs to be done.

We are not simply talking about a core framework upgrade. Rather, all aspects of the project will end up needing an upgrade. The supporting systems that allow the blockchain to operate will also need to be upgraded. Software wallets, hardware wallets, block explorers, mining operations, pools.., anything connected to an API and more will need a brush up of code to be compliant with the new changes. After that, exchanges will also need to adapt to the new chain.

The second challenge is one that is already mentioned in the previous article: the need for consensus. The quantum resistant signature scheme needs to be implemented through a fork. There would be an option to add the signature scheme through a soft fork. Fork the fork to be a success, it needs the majority of the nodes to upgrade. For the SegWit fork, there was a 95% majority needed for example.

So the majority of the nodes need to upgrade. But people running nodes, have a choice. Do they accept the new scheme and upgrade, or do they prefer the old version or favour another option. There will be different schemes available, different choices to make how to implement them, and thus there will be different options on the table. The nodes have a choice to update or to refuse. That makes it, so to speak, a democratic system which makes any change a slow process. The need for consensus is a challenge.

The past has proven that reaching consensus in a decentralized system as blockchain, is not a fast, fluent process. The most well-known example of how that can be a slow process is Bitcoin’s need to scale. There are several solutions to a serious problem, but none is implemented (at least not in the original chain). Even though everybody agrees on the need for a certain result, reaching consensus amongst the community on how to get to that result is a slow and political process. The discussion is never about the actual result. The discussion is about the method to get to that result and the side effects it causes. (Maybe mining costs go up, or certain hardware isn’t sufficient anymore and will need to be replaced, etc.) Going quantum resistant will be no different. The need for quantum resistance might be a huge incentive to implement as soon as possible, but that doesn’t mean there won’t be different interests for the people running nodes. The level of urgency doesn’t evaporate different economical or political interests. A state of urgency usually hardens ones stance on subjects instead of improving chances on a compromise.

To put it short, there are several quantum resistant signature schemes to choose from, in the upcomming years new schemes will be approved, there are different ways of implementation, and there are choices to be made on the moment of implementation. So the discussion will be which one to use, and how and when to implement it. Reaching concensus is going to be a challenge.

Another challenge is that post-quantum cryptography is a specialized kind of cryptography. Post-quantum cryptography is a real specialty. Choosing the right scheme and implementing it without the right knowledge, might backfire. So implementing post-quantum cryptography without consulting a post-quantum cryptographer and commissioning an external audit is a serious risk. What will you use? Will you use XMSS? How you make sure your blockchain can handle stateful signatures? You use WOTS+? How you make sure this is user-friendly? How will you make sure there is no old debtor who will sent funds to an old address? You use SPHINCS? How you going to handle 41KB signatures? You use BLISS B? How you prevent side channel attacks? You waiting for a NIST outcome? There is no guarantee that will be a magic scheme. Might still take a lot of work to implement.

Just an example: If you will use WOTS+, you will need to find a solution for the fact that you can’t reuse addresses. The most well known example is IOTA. They had some unexpected issues where people actually lost money. The problem went a bit deeper than just not reusing addresses: http://blog.lekkertech.net/blog/2018/03/07/iota-signatures/ This is fixed from the user perspective in the Trinity wallet. The remaining issue to solve now is the fact that constantly changing addresses, is impractical. Any company needs a standard address to pay to, not a different address for every new payment. (qr-code stickers → the quick response code not to be confused with the abbreviation for quantum resistance, invoicing and the random order of customers paying invoices, etc.) Propositions for a solution have been made so this is still an ongoing process for IOTA.

XMSS is even more complex to implement compared to WOTS+. See for a successfull and externally audited implementation of XMSS in blockchain: QRL. Also mentioned in NITS’s request for feedback.

The performance of blockchains that upgrade, could be different after the upgrade.

The current post-quantum signature schemes (Including the submissions to the NIST competition), will drastically increase the block size and take more resources to compute. This may slow down the amount of transactions per second, which a lot of projects aim to speed up instead of slow down. Quantum resistant signature schemes will mean bigger signatures. That has consequences for the performance of a blockchain, unless big innovative changes are made. So at the moment where quantum resistance becomes a must, something unexpected will happen. Projects that have postponed an implementation of quantum resistant signature schemes will be set back. The upgrade to a safe signature scheme will actually be partly a downgrade for pretty much all existing projects. But refering back to the existing quantum resistant blockchain “The Quantum Resistant Ledger: QRL” (uses XMSS) which is fully up and running at this time of writing, the only reason for QRL to change signature schemes is if a better, more efficient post-quantum signature scheme will be developed compared to the post-quantum signature scheme they use right now. Who knows, there might be something better available in the future. If this is indeed better, going from XMSS to something better, will be an over all upgrade. (For example, the competition run by NIST will either come up with something better, more efficient, or there will be nothing new to recommend at all. And as mentioned before, XMSS could be approved and recommended this year.). So while all other projects will partly downgrade performance wise, an already quantum resistant blockchain will either stay the same or upgrade and perform better than before.

How do bigger signatures influence the speed with which transactions are sent and confirmed on a blockchain? First a quick summary of the way transactions are handled: All miners, collect all transactions that people are sending in a transaction pool. There, transactions wait until a miner puts a number of these collected transaction in a block. This is where a block is constructed. After he has constructed a block, he has to solve a hash puzzle applied on his list of transactions that he registered on his block. The miner who has solved his hash puzzle, is allowed to put his block on the network. If this block will eventually be part of the longest chain, the transaction will be confirmed and validated. Either the size of the block will be influenced by bigger signatures, or if the block size is fixed, the amount of transactions that fit in a block will be influenced.

Now there are two types of speed that are influenced and are both important for the performance of the blockchain:

Capacity, so the amount of transactions a blockchain can confirm in a second at maximum capacity. So if BTC for example can confirm 7 transactions a second (it’s max capacity), then as soon as more than 7 transactions per second are added to the network, BTC has reached its maximum capacity. In that case, the individual transactions will need to wait in line and the individual transaction speed is slowed down. (Unless you increase your fee, then your transaction will be prioritized and you might make the standard individual transaction speed. Of course depending on the height of other fees.)

Individual transaction speed. This is the time within which you send a transaction and your transaction is confirmed on the network. This is the speed that applies for the moment where the blockchain is operating under its maximum capacity. So that means a transaction is added to a block almost as soon as it arrives at a node and gets processed right away.

The capacity depends on the block time (the amount of time it takes for a block to be mined) and the amount of transactions that fit in a block. The bigger the signature, the bigger and “heavier” the transaction, which results in either fewer transactions fitting in one block or bigger block size. Which in turn then results in less transactions confirmed per block or bigger block times which both leads to less transactions per second.

Now there could be solutions for the big signature size issue. Solutions being developed right now for scaling, could solve the problem for quantum resistant blockchains. But this is ongoing research to be looked into more in depth.

To overcome the shortfalls of post-quantum signature schemes some developers may decide to roll their own crypto, which has majorly failed in the past with other projects. Cryptography is difficult to understand and implement, much less post-quantum cryptography. Besides that it has to be tested and checked, preferably by external, professional parties to be proven secure. To this end there are only a handful of researchers worldwide even qualified in this specialty field. The NIST approval takes around 5 years of open source research. Self fabricated quantum resistant signature schemes ar a slippery slope.

In the next article, I will discuss some other core challenges: The human factor and lost addresses, the time factor and a black swan event. You can continue reading here: Part 4, part 5, part 6 and part 7