Trusted Execution Environment Key-Evolving Proof of Stake Protocol
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing Proof of Stake (PoS) blockchain protocols are vulnerable to long-range attacks, particularly posterior corruption, where adversaries exploit secret keys of honest users to rewrite blockchain history, and existing solutions like checkpoints are ineffective in scenarios with intermittent network participation.
Innovation Solution
A method utilizing a key-evolving mechanism within a trusted execution environment (TEE) to generate fresh key pairs for each transaction, ensuring that public key updates are visible on the blockchain, and decoupling stake into currency and mining resources to prevent adversaries from exploiting compromised validators.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If checkpoints are used to mitigate long-range attacks, then security against attacks is improved, but the system fails to protect new users joining the network who may retrieve different blockchains
Solution Approach 1:
The system performs preliminary actions by having users generate fresh key pairs before each transaction and publishing the public key on the blockchain in advance. This preliminary key update mechanism ensures that even new users joining the network can verify the current valid public key and prevent long-range attacks, without relying on checkpoints that assume continuous network participation.
Solution Approach 2:
The system implements dynamic key management where users continuously update their public keys on the blockchain for each transaction. This dynamic approach adapts to new users joining the network at any time, as each user maintains an up-to-date public key record that reflects their current state, making the system flexible and responsive to changing network conditions.
2Loss of energy
If PoS protocols are implemented to improve energy efficiency, then energy consumption is reduced, but the system becomes vulnerable to posterior corruption attacks
Solution Approach 1:
The system performs preliminary key updates by generating fresh key pairs before each transaction and publishing the public key on the blockchain in advance. This preliminary action ensures that even if private keys are compromised later, the attacker cannot forge transactions for past blocks, thus preventing posterior corruption attacks while maintaining the energy efficiency of PoS protocols.
Solution Approach 2:
The system applies preliminary anti-action by proactively updating public keys before potential compromise can occur. By continuously refreshing keys and publishing them on the blockchain, the system pre-empts the posterior corruption threat model, ensuring that compromised private keys cannot be used to create alternative valid blockchains.
3Reliability
If frequent key updates are performed to prevent posterior corruption, then security is improved, but transaction processing time increases
Solution Approach 1:
The system makes the key update mechanism universal by integrating it into the normal transaction flow. The same blockchain infrastructure that records transactions also records public key updates, eliminating the need for separate key management systems. This multi-functionality allows frequent key updates without adding significant overhead, as the blockchain naturally handles the publication and verification of key updates alongside regular transactions.
Data Source
Figure 1
Figure 2
Figure 3~4
AI summary
A method prevents posterior-corruption long-range attacks in a proof of stake blockchain protocol on a blockchain network. The method includes: generating, by a blockchain node, a fresh key pair, having a fresh public key to be included into a transaction and a fresh private key to be used for signing a next transaction; generating, by the blockchain node, the transaction having as an input an overall stake associated to an account of the blockchain node, and as an output a transfer stake to be transferred to a second node's public key, and a remaining account stake to be transferred to the fresh public key; signing, by the blockchain node, the transaction with a previous private key; and broadcasting, by the blockchain node, the generated transaction to the blockchain network.