Satellite Blockchain with Hardware Security Modules
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current blockchain maintenance methods, such as proof-of-work and proof-of-stake, are energy-intensive and vulnerable to malicious attacks, while permissioned blockchains rely on central authorities, limiting their applicability and security.
Innovation Solution
The Bounce Blockchain system utilizes a satellite-based architecture with sending and listening stations to determine the order of blocks without proof of work or stake, ensuring immutability and security through a communication protocol involving Cubesats and Hardware Security Modules, which are fail-stop and resistant to Byzantine failures.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If proof-of-work is used to maintain blockchain integrity, then security against malicious attacks is improved, but energy consumption increases dramatically
Solution Approach 1:
The patent introduces a trusted computing platform (Intel SGX) as an intermediary to perform proof-of-elapsetime operations. This mediator verifies the elapsed time for block creation without requiring energy-intensive proof-of-work computations, thereby maintaining blockchain security while dramatically reducing energy consumption.
Solution Approach 2:
The patent replaces the mechanical computation-based proof-of-work system with a time-based proof-of-elapsetime mechanism verified by trusted hardware. This substitution eliminates the need for energy-intensive computational puzzles while preserving the core security function of preventing blockchain forks.
2Use of energy by moving object
If proof-of-stake is used to determine block order, then energy consumption is reduced, but vulnerability to Sybil attacks increases
Solution Approach 1:
The trusted computing platform acts as an intermediary that verifies the identity and eligibility of block producers through proof-of-elapsetime. This mediator prevents Sybil attacks by ensuring that only legitimate participants who have waited the required time can produce blocks, while still maintaining low energy consumption compared to proof-of-work.
3Use of energy by moving object
If trusted computing platforms are used for proof-of-elapsetime, then energy consumption is minimized, but vulnerability to platform compromise increases
Solution Approach 1:
The patent applies local quality by implementing fail-stop security at the trusted computing platform level. If the platform is compromised or behaves maliciously, it can be isolated and stopped without affecting the entire blockchain network. This localized security approach minimizes the impact of platform vulnerabilities while maintaining overall system reliability.
Solution Approach 2:
The patent incorporates fail-stop mechanisms as a preemptive security measure. The trusted computing platform is designed to detect and respond to compromise attempts by shutting down operations, providing a cushion against potential attacks before they can propagate through the network. This prior cushioning protects the system from the harmful effects of platform compromise.
4Use of energy by moving object
If permissioned blockchain with central authority is used, then energy consumption is reduced, but adaptability and security are limited
Solution Approach 1:
The patent segments the blockchain network into permissionless participants who can freely join and a trusted computing platform that provides security services. This segmentation allows the system to maintain low energy consumption through the trusted platform while preserving the adaptability and openness of a permissionless blockchain for various applications.
Data Source
AI summary
The basic idea of this invention is to send one or more cubesats into orbit, each equipped with a hardware security module. Users would send their transaction to the cubesats which would collect them into blocks, sign them, and send (bounce) them back to earth (and to one another). Bounce Blockchain provides scalability through sharding (transactions will be partitioned over cubesats). Because modern hardware security modules are tamper-resistant (become inoperable if tampered with) or tamper-responsive (erase their keys if tampered with), take their keys from physical processes, and have been validated, socio-technical protocols can ensure that it is infeasible to forge the identity of a hardware security module in a cubesat with another cubesat. If, however, some cubesats are destroyed, the blockchain will continue to execute correctly though some transactions will be lost. New cubesats can be sent up in short order as they are quite cheap to launch. If, in spite of these assurances, some cubesats fail traitorously, the blockchain can survive through algorithms similar to Practical Byzantine Fault Tolerance techniques.