Topic: <IDEA> How to protect a blockchain from terminal attacks (Read 211 times)
Thank you!
Hi! Can you please provide any links?
We thought, how can we help other blockchains to be protected from terminal attacks today (without forks, encryption changes etc)? This is kind of attack that destroys the network. This is the solution we came up with: persistent mirror copying of operating blockchains with quantum safe encryption to an external protocol (to Cellframe) to protect it from any kind of terminal attacks and provide secured backup.
Hello, everyone. I want to share an idea that we came up to a week ago. This is our view of contributing the whole blockchain ecosystem.
Background.
For the last couple of years we’ve been developing our vision of the blockchain of the future (its called Cellframe) based on several key principles:
1) Low level architecture. It is extremely important to get maximum from the hardware you use, because semiconductor size arguably has its limits (1 nm). When we face it we’ll have 2 options – revolutionary (e.g. quantum computing) or evolutionary (effectiveness in usage of the hardware). It is difficult to re-write core things when you have huge system so we decided to build everything from the scratch with plain C. Plus, most of the world computer systems are Unix-based (at least its kernels) so it will be easy to interoperate with them.
2) Encryption variability and post-quantum encryption by default (we are kinda quantum geeks). We’ve implemented several signatures but then we knew about NIST contest (google PQC NIST) and decided to wait until they announce its final results and then use it in our protocol. Plus, we’ve been talking about true quantum safe systems with some guys from Harvard on BCI Summit NYC in May and we all agreed that the real way of quantum resistance is encryption variability (or agilability). So that confirmed our ideas. That means you can change the type of encryption “on the fly”. We don’t have a universal quantum computer now and all we can do now is stay prepared.
3) Flexibility and performance. Basically we achieve this by our own sharding implementation and DAG. You can launch a shard with customizable subchain in it. E.g. this is how you can launch a copy of any blockchain. +WASM and EVM support. If you want to know more about this, check github.com/cellframe or PM me. Don’t want to make an ad out of this post.
Cut to the chase.
We thought, how can we help other blockchains to be protected from terminal attacks today (without forks, encryption changes etc)? This is kind of attack that destroys the network. This is the solution we came up with: persistent mirror copying of operating blockchains with quantum safe encryption to an external protocol (to Cellframe) to protect it from any kind of terminal attacks and provide secured backup.
Cellframe Protocol is capable to launch an infinite number of shards with customized subchains in it. Particular subchain can be modeled as a mirror of an existing public chain. Mirror chain duplicates all the information recorded in the Existing Blockchain (EB), but with an application of the post-quantum encryption.
Any address owner of the EB can use the service of PQ key issuance after proof of ownership procedure which is shown at Pic.1 (i’ll insert it later from a pc). The user saves this PQ key in a safe place just as he did it with the private key of EB. In case of terminal attack, the main problem is that trustworthy system becomes untrustworthy, so nobody knows who can be trusted UNLESS the user has a PQ key from the Mirror chain, issued beforehand. In case of a terminal attack in the system where every key gets insured in Mirror chain, it is possible to restore all the balances and keep everybody safe, i.e. this procedure create a situation where a quantum attack has no point at all.
Also possible to protect your EB address with more than one key, ever with different alghorythms of encryption. Thats provide ultra high level of protection.
If a real quantum thief appears it would attack rather unmirrored network than mirrored. This is a Deterrence Theory in application to blockchain security.
I decided to make this post to get some feedback. At first I propose to consider this as vacuum situation without comments about “market that won’t let it happen”. Right now we’re preparing a proper documentation for this case. We’ll be happy to discuss any of the issues and questions.
To know more about the project itself and test net pm me.
Background.
For the last couple of years we’ve been developing our vision of the blockchain of the future (its called Cellframe) based on several key principles:
1) Low level architecture. It is extremely important to get maximum from the hardware you use, because semiconductor size arguably has its limits (1 nm). When we face it we’ll have 2 options – revolutionary (e.g. quantum computing) or evolutionary (effectiveness in usage of the hardware). It is difficult to re-write core things when you have huge system so we decided to build everything from the scratch with plain C. Plus, most of the world computer systems are Unix-based (at least its kernels) so it will be easy to interoperate with them.
2) Encryption variability and post-quantum encryption by default (we are kinda quantum geeks). We’ve implemented several signatures but then we knew about NIST contest (google PQC NIST) and decided to wait until they announce its final results and then use it in our protocol. Plus, we’ve been talking about true quantum safe systems with some guys from Harvard on BCI Summit NYC in May and we all agreed that the real way of quantum resistance is encryption variability (or agilability). So that confirmed our ideas. That means you can change the type of encryption “on the fly”. We don’t have a universal quantum computer now and all we can do now is stay prepared.
3) Flexibility and performance. Basically we achieve this by our own sharding implementation and DAG. You can launch a shard with customizable subchain in it. E.g. this is how you can launch a copy of any blockchain. +WASM and EVM support. If you want to know more about this, check github.com/cellframe or PM me. Don’t want to make an ad out of this post.
Cut to the chase.
We thought, how can we help other blockchains to be protected from terminal attacks today (without forks, encryption changes etc)? This is kind of attack that destroys the network. This is the solution we came up with: persistent mirror copying of operating blockchains with quantum safe encryption to an external protocol (to Cellframe) to protect it from any kind of terminal attacks and provide secured backup.
Cellframe Protocol is capable to launch an infinite number of shards with customized subchains in it. Particular subchain can be modeled as a mirror of an existing public chain. Mirror chain duplicates all the information recorded in the Existing Blockchain (EB), but with an application of the post-quantum encryption.
Any address owner of the EB can use the service of PQ key issuance after proof of ownership procedure which is shown at Pic.1 (i’ll insert it later from a pc). The user saves this PQ key in a safe place just as he did it with the private key of EB. In case of terminal attack, the main problem is that trustworthy system becomes untrustworthy, so nobody knows who can be trusted UNLESS the user has a PQ key from the Mirror chain, issued beforehand. In case of a terminal attack in the system where every key gets insured in Mirror chain, it is possible to restore all the balances and keep everybody safe, i.e. this procedure create a situation where a quantum attack has no point at all.
Also possible to protect your EB address with more than one key, ever with different alghorythms of encryption. Thats provide ultra high level of protection.
If a real quantum thief appears it would attack rather unmirrored network than mirrored. This is a Deterrence Theory in application to blockchain security.
I decided to make this post to get some feedback. At first I propose to consider this as vacuum situation without comments about “market that won’t let it happen”. Right now we’re preparing a proper documentation for this case. We’ll be happy to discuss any of the issues and questions.
To know more about the project itself and test net pm me.
Jump to: