In part 4 I describe the advantages of going quantum resistant from genesis block. Genesis block is the first block of a blockchain. Being quantum resistant from genesis block means that a project launches from the very first beginning while using a quantum resistant signature scheme. This has several advantages I like to discuss in this part of the series.
Part 1 here Part 2 here Part 3 here
Quantum resistance (QR) from genesis block. Why is it a special quality?
Content:
A (Posted here)
What are the challenges of upgrading an existing blockchain to a quantum resistant one?
What you see is what you get: the performance of other blockchains that upgrade later, could be different after the upgrade.
The whole architecture can be designed around post-quantum cryptography.
B (posting tomorrow)
Lost addresses and the human factor: a partly protected circulating supply after a quantum resistant upgrade
The time factor
The case of a black swan event where unexpectedly fast, an entity will appear to have a quantum computer of critical level.
The fourth part is divided into two sub parts: 4A and 4B due to the size of the content. This should be fun and readable so part 4B will follow tomorrow.
What are the challenges of upgrading an existing blockchain to a quantum resistant one?
If a special quality doesn’t solve a certain issue, it would be of no value, so let’s first dig a bit deeper in the future issues for current running blockchains. 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 also need a brush up of code to be compliant with the new changes. Then exchanges will also need to adapt to the new chain. And for example, for a blockchain like Bitcoin and Ethereum this is going to be extra complex, as they need to fully disable their old signature scheme.
The second challenge is that you need consensus, you need the majority of the nodes to upgrade. If you want to change the signature scheme and make sure the old, vulnerable scheme is rejected, you need to upgrade at least the majority of nodes, or you will end up with the old, vulnerable signature scheme or two different blockchains where the main chain will still be using the old signature scheme and thus will not be quantum resistant. As explained in the previous part, we can’t have the old signature scheme to be valid because that would mean that the blockchain would still allow the use of vulnerable old public and private keys and thus the old vulnerable signatures for transactions, so at least the majority of the nodes need to upgrade to make sure that blocks which are constructed using the old rules and thus the old vulnerable signature scheme, are rejected by the network. This will eventually result in a fully upgraded network which only accepts the new post quantum signature scheme in transactions. So, consensus is needed.
The past has proven that reaching consensus in a decentralized system as blockchain, is not a fast, fluent process. You need the nodes to update to your new version. The nodes have the choice to do so or refuse. That makes it, so to speak, a democratic system which makes any change a slow process. The past has proven that a simple change to improve speed and transaction costs couldn’t be realized because miners couldn’t agree on to which of the working solutions would be implemented. There are several solutions to a serious problem, but none is implemented (at least not in the original chain). If you compare this to changing a signature scheme, it’s not going to be any easier. 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 need for QR 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. One option might mean better performance, but 60% of the people running nodes, will need to buy new equipment. The other option might mean lesser investments for equipment, but also slower transactions and the risk of losing users and market share. These discussions and differences in interest and view point, will not help to reach consensus fast.
Another challenge is that post-quantum 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, excludes IOTA from being used by companies. Any company needs a standard address to pay to for the obvious reasons. (qr-code stickers meaning 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+.
So it’s quite a time-consuming and challenging project to implement and upgrade an existing project. As an existing fully quantum resistant blockchain, having your security in check in advance, gives the certainty you’re in time, and all is checked, audited and working properly. Which obviously is a plus.
What you see is what you get: the performance of other blockchains that upgrade later, could be different after the upgrade.
The majority of NIST’s suggested post-quantum signature schemes will drastically increase the block size and take more resources to compute. This may in turn slow down the transactions per second a lot of projects aim to reduce. 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 safer signature scheme will actually be partly a downgrade for pretty much all existing projects. There are only two blockchains who use quantum resistant signature schemes right now: QRL (XMSS) and Mochimo (WOTS+). The only reason for them 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. NIST has initiated the research and review of post-quantum cryptography. https://www.nist.gov/news-events/news/2016/04/nist-kicks-effort-defend-encrypted-data-quantum-computer-threat So 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. (NIST will either come up with something better, more efficient, or there will be nothing new to recommend at all). So while all other projects will partly downgrade performance wise, quantum resistant blockchains will either stay the same or upgrade and perform better.
How 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 whole architecture can be designed around post-quantum cryptography.
Besides the fact a blockchain is from the start designed around post-quantum signature schemes, one of the key points in the architecture would be a flexible signature space for addresses and having a chain that's already designed to handle, for example stateful signatures. The handling of stateful signatures would come naturally if the chain is already using a post-quantum scheme like that, but should another come along that's better, the whole architecture is build and ready to switch. This is compared to one that has a small signature space and can't define them, as well as the lack of capability of handling state in chain (for example Bitcoin).
Take QRL for example: https://docs.theqrl.org/developers/address/#descriptor QRL already implemented a quantum resistant signature scheme: XMSS. But at the same time their chain architecture is build to switch signature schemes: When you form a QRL address, First 3 bytes of your address forms the Descriptor. In Descriptor bit number 4 to 7 are used to specify signature scheme. These 4 bits are used to specify if we have any other signature scheme.
In part 4B I dive deeper in the issue of lost addresses for existing blockchains like for example the ~1 milion BTC in Satoshi's wallet. Also I will get into the time issue and a possible black swan event.
No comments:
Post a Comment