Subscribe to Zer0Luck
<100 subscribers
✅ Follow me: X: @Younsle1 Warpcast: @zer0luck
Despite the general argument for the adoption of blockchain technology in terms of security, privacy, and immutability, various attacks can occur on blockchain technology in reality. This article summarizes systematic details on Long-Range attacks for Proof-of-Stake protocols. If successful, these attacks can seize the main chain and partially or completely rewrite transaction records stored on the blockchain. To do this, we will explain blockchain, consensus protocol methods (POS, POW, ...), basic properties, disadvantages, and attack vectors.
https://mirror.xyz/zer0luck.eth/s8oFS1oNkrNg7vdGdpStHN4jLSk0OEsYT5y5Duddtgc
The purpose of this article is to review and study the paper "A Survey on Long-Range Attacks for Proof of Stake Protocols" after reading it. The paper was written by:
Evangelos Deirmentzoglou (Department of Informatics, University of Piraeus, Piraeus, Greece)
Georgios Papakyriakopoulos (Cisco Security Services, Marousi, Greece)
Constantinos Patsakis (Department of Informatics, University of Piraeus, Piraeus, Greece)
The paper can be found at
https://ieeexplore.ieee.org/document/8653269/
The main advantages of Proof of Stake protocols can be the main root-cause of attacks.
Proof-of-Stake protocols do not require significant computational effort on the part of the validator, which minimizes energy consumption, but also means that it costs the attacker nothing to execute the attack. This concept is sometimes referred to as Costless Simulation.
This concept is sometimes referred to as `Costless Simulation'. More popularly known as Nothing at Stake. In practice, since validators do not have to take any risk when making consensus decisions, their optimal behavior is to participate in as many chain forks as possible, since they do not know which fork will become the main fork. This undermines the stability and goals of the main chain.
An attacker can create an alternative branch to the main chain of a proof-of-stake-based blockchain at any point in time without incurring any real costs.
This is not possible in a Proof-of-Work-based blockchain because it requires a huge amount of time and computing power.
The term "weak subjectivity" is used to describe a problem that affects two types of nodes
new nodes in a blockchain network
nodes that have been offline for a significant amount of time and then come back online.
In both cases, node synchronization cannot have concise information about the main chain of the blockchain because it lacks a basis for changes in the blockchain over time. For this reason, Weak Subjectivity does not affect online and synchronized nodes.
Nodes that have just joined the network, starting with the genesis block, can retrieve all currently published blockchain branches. However, new nodes cannot immediately distinguish between major branches of the chain. The latter limitation also applies to nodes that have been offline for a long time.
At some point in the past, this node may have known which branch was the main chain, but after a period of dormancy, it won't recognize it.
Because online nodes monitor the blockchain in real-time, they cannot be tricked into accepting another branch as the main chain unless that branch has legitimately become the main chain.
As you can see in the figure above, there are many different branches in a typical blockchain snapshot. Some of them are longer than others, and all of them are candidates to become the main chain.
The figure above shows a type of blockchain where multiple branches of equal length are visible to all nodes participating in the network, but nodes cannot see the main chain and can be tricked into accepting a malicious chain.
Double spending is one of the problems that blockchain technology has been trying to solve since its inception.
Most, if not all, attacks on blockchains target double-spending at some point in their execution.
In this attack scenario, the attacker attempts to spend the same currency at least twice, resulting in double-spending.
This attack is absolutely impossible in terms of physical currency; it is impossible to purchase resources from one vendor and then spend the same coin with another vendor.
The attacker performs the transaction, waits for the merchant to authorize it, then reverses it and tries to use the same currency in another transaction.
On the blockchain, this can be accomplished by presenting the conflicting transactions at different points, and BFT systems that use absoulite finality are considered robust against the double-spending problem.
Generally refers to a peering network that affects network members with equal rights.
This attack can be executed against blockchain protocols, but it can be successfully mitigated by using appropriate consensus algorithms.
In a sybil attack, an attacker uses multiple identities to issue or mislead the network's decisions or opinions. In blockchains, this can cause many problems, such as confirming and forking blocks or electing validators.
In a POW system, an attacker must possess multiple identities with sufficient computational power to exert significant influence on the system.
Consensus protocols directly defeat this logic by requiring the attacker to divide his computing power into smaller chunks.
This does not benefit the attacker and does not amplify their computing power. Instead, the attacker's computing power remains the same if all identities mine the same block, or decreases if each identity mines a different block.
In either case, the attacker must own a significant amount of computing power, which costs the same as concentrating all computing power in one entity or splitting it across multiple entities.
An attacker can work directly against the consensus protocol. The validator election process and voting power is weighted by "stake".
An attacker has the same voting power if a single identity owns all of the attacker's stake or if it is split between multiple identities.
Generally considered an implementation issue and relies on the existence of probabilistic finality.
On blockchains that do not have absolute finality, a transaction may require multiple confirmations before it is considered complete.
Depending on the transaction, more Requirement Numbers may be used at the merchant/user's discretion. Transactions handling significant amounts of funds may require a higher number of confirmations before being accepted as valid.
Services may not be configured correctly to wait for the recommended Requirement number for a particular blockchain.
In this case, a double-spend attack can occur. An attacker can have a fork of the blockchain mined until it meets the service's weak requirements, take the goods from the "Weakly" verified transaction, and then switch computing power from that branch to the main branch.
This way, the "Weakly" verified transaction will soon be lost at one point in the blockchain and will not be valid on any node after the main chain.
This attack is mitigated by BFT-based proof-of-stake protocols that use absolute finality.
Also known as a Short Range Attack, this attack involves bribing validators or miners to work on a particular block or fork.
This allows the attacker to present fraudulent transactions as valid and pay dishonest nodes to verify them.
By paying an amount equal to or greater than the block reward (if the network reverts the block), it provides a high enough incentive for miners to work on the attacker's block or chain.
P+Epsilon attack
In one case, an attack known as the P+epsion attack says that it is possible to bribe users without paying them.
The system bribes the dishonest node by making that branch the main chain. In this case, the attacker is faced with a more serious problem: if the malicious branch reverts for some reason (the attacker is unable to continue bribing or the dishonest nodes stop working on that branch), the attacker will have to pay a huge bribe because the bribe will accumulate for every block that was maliciously issued.
In a POS system, this kind of attack is possible, and it can extend to the problem of taking nothing.
In either case, the POS should address this issue by applying a slashing condition or removing the offender from the location.
This attack is a form of denial of service attack in the POW protocol. Some or all of the validators decide to take action and stop publishing blocks, intentionally blocking transactions.
If validators do not fulfill their validator duties, the blockchain stops because new blocks cannot be validated and published to the blockchain.
An activeness requirement that gradually exhausts the stakes of inactive validators ensures that the network is not compromised if the majority of validators are offline or performing real-time denial-of-service attacks.
If active status cannot be assessed, the community can decide (via off-chain communication) to fork.
The blockchain can be deleted and inactive validators removed. In all cases, validators performing this type of attack jeopardize their status as validators on the network and their stake if slashing conditions exist.
Censorship on a blockchain is a tricky issue that has generated a lot of discussion because it can be considered both an attack and a feature, depending on the nature of the blockchain.
Validators can control which transactions are added to a block, giving them the power to blacklist certain addresses.
The transactions are in a transaction pool, and the validator pulls them and adds them to the upcoming block.
A validator can also remove some transactions from a block.
In a scenario where a single validator performs censorship, some transactions may be delayed or invalidated due to time constraints.
The risk of censorship becoming a reality increases as the number of validators performing these attacks increases.
Liveness requirements ensure that transactions are finalized and can eliminate censorship from the blockchain. Protocols can also punish nodes that don't produce blocks in the order defined by the protocol.
Another effective solution, Zero-Knowledge succinct non-interactive arguments of knowledge (zk-SNARK), can be used to hide the identity of the transaction sender.
This attack is a threat to all consensus protocols. In a POW system, an entity that controls the majority of the hashing power at any given time can take full control of the blockchain.
For example, they can fork the main chain and start mining on their own branch. Slowly and steadily, the attacker can outpace the main chain and allow their branch to take over.
Since block generation is stochastic in the POW protocol, the probability of conflicting forks increases once the 51% limit is crossed. Thus, the attacker gets the main chain, but a branch reversal often occurs at that point.
Due to the stochastic rewards of POW blockchains, miners tend to consolidate their computing power using mining pools. While mining pools ensure that nodes with lower computing power receive block rewards, they can unintentionally lead to 51% attacks. When the computing power of one mining pool reaches a high level, the miner community moves to competing mining pools to stabilize the network and avoid accidental 51% attacks.
In the POS protocol, this attack is still viable, but the impact is slightly different. A single validator or set of co-validators can own more than 34% of the blockchain (in the case of the BFT Proof of Stake protocol). In this case, a majority attack can affect the blockchain by performing a confirmation reversal, where an already confirmed block is challenged for confirmation by another competing block, which can cause Liveness Denial, Censorship.
When a 51% attack occurs, miners are usually notified, and a community-led fork takes place to reset the honest chain to the main chain.
In a shelfish mining attack, also known as block withhilding, the attacker mines blocks on their own fork of the blockchain without publishing the blocks to the network.
After calculating the desired number of blocks, the attacker releases them to the network in an attempt to revert the main chain back to the attacker's chain.
This attack has two main objectives
disrupt the network by wasting the resources of honest nodes
increase the reward received by the dishonest node.
The former attack incentive purely affects the POW blockchain. The POS blockchain is not disrupted by these incentives. The latter incentive affects both protocols and can be mitigated by applying slashing conditions or removing the offender from a position of power, causing them to lose future rewards.
Grinding attack, also called precomputation attack, is an implementation issue and affects POS systems.
It exploits the lack of randomness in the slot leader election process to manipulate the frequency with which slot rudders are elected in subsequent blocks.
This issue can be addressed by introducing randomness into the process and minimizing or eliminating influencing factors in this process that are controlled by the validator.
In early versions of the protocol, the longer a user's stake was staked with no time limit, the more weight was accumulated.
Given enough time, an attacker could accumulate a huge amount of stake in the system that would allow them to take control of the network.
This mechanism works by amplifying the stake of validators. To mitigate this, the mechanism is either limited to a certain amount of time or removed entirely.
Other attacks on blockchains include eclipse attacks, in which an attacker interferes with the transmission of messages by nodes at the peer-to-peer network level, forcing the nodes to operate on a corrupted or distorted snapshot of the blockchain.
https://mirror.xyz/zer0luck.eth/MdyKCwYJXRoYesj59D-og50c9y5Qm6On3wsIzcpQ8Q8
A long-range attack is an attack scenario where the attacker forks the blockchain by going back to the genesis block.
The new branch is populated with records that are partially or completely different from the main chain. The attack succeeds if the branch created by the attacker is longer than the main chain and overtakes it. There are three types of long-range attacks.
Simple
Posterior Corruption
Stake Bleeding
Long-range attacks in Proof of Stake protocols are related to selfish mining attacks in Proof of Work protocols. In both cases, the attacker adds blocks that are kept secret. Of course, Selifsh mining attacks can't go back to the genesis block of a PoW protocol because the computational effort required is prohibitive, so their impact is limited.
Both attacks fork the main chain, and the attacker attempts to add forged blocks containing potentially different transactions.
We'll start with the simplest case of a long-range attack and build up to more complex scenarios.
In the following example, we consider a validator pool with three validators, the latter of which is designated as the attacker.
For simplicity, assume that they all own the same portion of the system's stake. Each owns a 33,3% stake
Before describing the Long Range Attack, let's implement a simple attack to verify it. A naive implementation of the POS protocol, where nodes do not check the timestamps of blocks, would look like this. When the POS protocol is running, any validator can verify the block, as shown in the following figure.
When a malware launches a long-range attack, it creates an alternate branch of the blockchain. Starting from the genesis block, the malware forks the blockchain and begins issuing branches that may contain different transactions.
The lower branch is the main chain, the upper branch is Mallory's branch, and Mallory has the same probability of being elected in both branches. Forfeited blocks are indicated in parentheses. (There are currently 2 blocks in Malory's branch).
As you can see in the figure above, since the validator information is located inside the genesis block, the malware cannot generate blocks at a faster rate than on the main chain.
Therefore, the malware generates blocks at the same rate. Because of this constraint, malware must generate blocks in advance to advance its branch and overtake the main chain, as shown in the figure below.
White shading and three dots are used to represent different forfeited blocks. In Malory's attempt to compete with the main chain, Malory precomputes blocks. In this snapshot, both branches are the same length.
To do this, the malware must forge timestamps. This is because the malware is the only active stakeholder in the branch that can forge the timestamp. As a result, in an implementation where nodes do not consider timestamps, both branches will be valid and nodes will not be able to detect the malware's forgery.
Now consider a scenario where the malware cannot forge the timestamp of a block.
To change the history of the main chain, we need to generate a larger number of blocks in parallel with the main chain. However, Mallory is constrained by the fact that her probability of generating a block is fixed.
To increase its chances of competing with the main chain, it needs to be able to forge blocks from other validators as well.
For example, if Bob agrees to attack the main chain, the attack is rather straightforward since they both have more than 50% stake (but not necessarily).
To clarify the attack, it is important to understand the concept of validator rotation.
Validator Rotation
Due to the nature, requirements, and expectations of blockchains, there shouldn't be any static components or entities beyond the genesis block.
Validators are no exception to this rule and therefore cannot be considered static and must be rotated for a fair system.
Validators should have the option to retire and the system should replace or remove them based on certain conditions, such as a certain period of time or dishonest behavior.
Finally, just because an entity is considered benign and trustworthy doesn't mean it will remain so after it leaves the system.
Consideration must be given to the fact that verifiers' incentives may change over time or the system may be compromised.
For simplicity, suppose Bob decides to retire after validating the first n blocks of the main chain.
Bob removes his stake and cashes out, so he is no longer part of the blockchain, but his blocks exist. While Bob was active as a validator, he may have used security best practices to store and manage his private keys.
However, once Bob no longer owns a stake in the platform, we argue that the security of his private key for block validation is not a priority for him (since he is no longer a validator).
It's important to note that while he can't sign new blocks, Bob (or anyone with access to Bob's key) can sign the first n blocks on any branch of that blockchain.
This practically means that if you have access to Bob's key, you can forge the blocks he validated.
We should also consider that Bob is no longer part of the system, so there is no incentive for him to do so, as he has nothing to gain.
The above problem is called posterior corruption because of its name.
If Malory hacks Bob and steals his private key, or if Malory bribes Bob and Bob joins the attack, in either case Bob's private key is known to Malory, who can sign valid blocks, and Malory can impersonate Bob and get ahead of the main chain with a high probability.
The lower branch is the main chain, and the upper branch is Mallory branch, which is racing to overtake the main chain. Bob joins Mallory's long-distance attack. The alternate (upper) branch is now much more competitive and more likely to overtake the main chain.
Since Bob is directly or indirectly participating in the attack, he generates blocks on Malory's branch each time he is elected as a block validator. As you can see in the figure above, Bob's blocks in the malicious branch are no longer empty, and the malicious branch is more likely to compete with the main chain.
Suppose again that Mallory, the validator, tries a different type of attack: as in the previous case, she forks the main chain and hides her fork.
She plans to publish it when it's ahead of the main chain, and it's clear that when a fork occurs, she has an equal chance of being elected slot leader on all branches of the blockchain.
The bottom is the main chain, the top is Malory's attempt to create a new fork of the main chain, and the dotted line in Malory's branch is mined, stored locally, and currently unpublished.
To increase the probability of this attack succeeding, Mallory begins to delay the main chain. The idea is that by stalking the main chain, it gains the time it needs to generate blocks and outpace the main chain.
Depending on the percentage of total stake held by Mallory, this can lead to a Liveness Denial Attack.
In the following, we assume that validators' rewards are compounded based on their stake. To launch the attack, every time Mallory is elected as a slot leader on the main chain, she skips her turn and loses her position, as shown in the figure below.
However, this does not mean that another validator will take his place. No new blocks are added to the blockchain for that slot/epoch.
Mallory remain part of the main chain while mining their own quarters. By expropriating her blocks from the main chain, Mallory delays the growth of the main chain and gains a competitive advantage in the alternate branch.
As a result, Mallory does not receive any rewards from the system, and her stake will gradually decrease. Eventually, all other validators will issue blocks and receive block rewards/transaction fees. At the same time, Mallory will be the only validator in her branch to publish a block. Therefore, she will publish blocks every chance she gets.
In this attack, Mallory will try to increase his stake in every way possible.
While performing this attack, Mallory can monitor the behavior of the main chain because it is behind it.
For example, it can choose which transactions to add to each block. The malware also has access to the transaction pool and can select transactions in the transaction pool and add them to the blockchain if they are valid in the context of their branch. To do this, the Mallory copies transactions from the main chain and/or the transaction pool and publishes them to its own branch. The latter goal is to maximize transaction fees and use them to increase her personal stake.
Mallory may prefer to copy transactions that are already on the main chain to arouse less suspicion from network monitors.
Mallory's stake gradually increases on the branch (the parent branch), making her a more frequent block validator, while the main chain continues to read her stake and consequently elect her less frequently.
By stopping the main chain and issuing as many blocks as possible on the alternative chain she forked, Mellory eventually gains a majority stake in her branch. Her stake then begins to grow faster than the main chain, as shown in the figure above.
When her branch outpaces the main chain, she will perform the last transaction.
This attack is somewhat slower. An attacker with 30% stake would need about 6 years of blockchain history to successfully carry out this attack. In contrast, we can use Costless Simulation to instantly create a branch with that amount of blockchain history.
While various mitigation techniques have been presented, none of them can be considered a complete defense individually. Therefore, to protect against this type of attack, you need to have a solution for each of them.
This is the simplest technique to overcome Weakly Subjective.
For the POS protocol, this technique can be considered the default option and is always used in conjunction with other techniques.
It should be noted that POW protocols can only use this technique to counteract weakly subjective.
In practice, for Proof of Work protocols, the longest chain is considered to be the chain that performs the most computational operations.
In principle, according to this Longest Chain Rule, the main chain is the branch with the most blocks. In rare cases, a chain reorg can sometimes occur, in which case the blockchain accepts a different branch as the main chain and the blocks are reorganized.
If a branch of the chain becomes longer than the main chain, the blockchain will reorganize itself to keep the longest branch as the main chain.
The idea behind this rule is that the network recognizes the branch with the most work as the main chain, for example, when two miners on a POW discover a valid block at about the same time.
If a transaction from another branch disappears, it is not completely lost. They can be moved to a pool of unconfirmed transactions and then placed in a block. This makes it easier to track and avoid double-spending issues.
Moving checkpoints is a mitigation technique used in almost all POS protocols.
Due to its simplicity and ease of implementation, it is one of the first mitigation techniques to be applied in POS blockchains after the Longest Chain Rule.
The basic idea behind checkpointing is that the last N blocks in the chain have a quota, which can be reordered.
Depending on the protocol, the block quota can change. In the case of Peer-coin, the quota is limited to a month's worth of blocks. This defense mechanism allows for some block reorgs, which can partially mitigate long-range attacks.
Snapshot structure of the blockchain using a move checkpoint with a factor of 2. Only the last two blocks can be reorganized. The gray blocks represent the truly immutable parts of the blockchain, and the red branch is invalid because it attempts to change the gray blocks.
With Moving Checkpoint, the Long-Range Attack is downgraded and now falls into the Short-Range Attack category, since the reorganization does not start from the genesis block. The main chain will not be able to change until the latest n blocks.
In a post-corruption attack, a retired validator can be used by an attacker to sign previous blocks in the blockchain, even if the key is no longer used or valid.
Various key-evolving cryptographies have been proposed to counter this threat.
https://eprint.iacr.org/2017/573.pdf
The idea of Key-Evolving Sign (KES) is that the lifetime of a key is divided into periods when different private keys are used, but the public key remains the same. In this regard, there is a key update algorithm that derives a new private key from the old private key. The epoch in which the signature was issued becomes an integral part of the entire signature. Therefore, even if the key is compromised, it cannot be used to re-sign previous messages.
By forcing the slot reader to sign the block in a KES fashion, the key used is immediately useless to the attacker. Without the ability to use continuously evolving keys and recover previous versions of the signing key, the attack becomes useless.
If Bob decides to sign an old block from a different quarter, he will not be able to use key-Evolving again for the genesis block because he has already used it to sign a different quarter.
Every block on the blockchain contains a hash of the previous block in its header. This is used to identify the point at which the block is located and to concatenate blocks. Context-Aware Transaction takes this linkage a step further by including the hash of the previous block within the transaction. This allows you to associate a transaction with a specific block in a specific branch of the blockchain.
Because transactions contain references to the blockchain's past history, they can't be copied to other branches. They can be copied to other branches and still be valid. It can't be copied unless the reference also exists in that branch.
Malory copies the transaction from the red branch to advance her chain, but the transaction is linked to Bob's block. Malory’s branch will be rejected as inconsistent by honest nodes.
Additionally, research has been done on universal hash time, which uses a time hash to establish a transaction reference tied to a specific point in time. With Context-Aware Transactions, an attacker will not be able to copy transactions from the main chain to their own branch. While this doesn't completely eliminate the attack, it can greatly reduce the impact of the attack because it requires the attacker to create a completely different record. Therefore, it can be considered an effective mitigation technique for Long-Range Attacks.
A more sophisticated countermeasure to the Long-Range Attack is the Plenitude Rule, which was first proposed as part of the POS-based protocol Ouroboros Genesis among other mitigation techniques. This chain selection rule is based on detecting the sparsity and density of blocks on conflicting branches.
https://eprint.iacr.org/2017/573.pdf
An attacker cannot manipulate their stake in the main chain, so an attacker with a 20% starting stake will have the same stake in every branch of the blockchain, assuming all branches are derived from the same starting block, as shown in the flow below.
In the case of a Long-Range Attack, the attacker starts generating blocks with a small probability, earning block rewards and accumulating more and more stakes as the stakes accumulate.
The more stakes a validator has, the more chances they have to generate a block. It is calculated that the remaining validators, i.e., the honest validators, generate 80% of the blocks before the malicious validators accumulate enough stakes to accelerate the rate of block generation. According to the latter, it is clear that one point will only generate a fraction of the block.
A snapshot of the blockchain up to the target point, validators have an equal probability of generating a block from a particular branch. If the top branch is Mallory's fork, Bob and Alice are still elected as block validators, even though they don't know the branch and therefore can't generate a block for it (a forfeited block is generated).
The same is not true for the other branches. This is because in a given slot, one branch may account for more than 80% of the block generation, while the other branch may only account for at most 20%.
In a blockchain snapshot where the malicious branch is sparsely populated by the first segment, the total number of blocks published by both branches is the same, but upon inspection, the block generation rate of the first segment is very different.
In the blockchain snapshot, we can observe how stake accumulation works. In the first two segments, the top quarter, which is the malicious quarter, generates blocks quite infrequently compared to the third quarter.
In the other branches, we observe a smoother distribution of block generation across all segments.
If a block is empty, it doesn't necessarily mean that the validator (in this case, Alice) is intentionally blocking the chain; sometimes the slot is empty because no transactions have been performed for a certain period of time.
In the third segment, the parent chain accumulates enough stake and block generation starts to become dense. When this happens, the attacker's stake continues to grow from the point at which they minted, while the honest validator's stake gradually decreases. As a result, blocks from the alternate branch are issued more frequently and eventually overtake the main chain.
The majority rule determines block density from the formation of branches and uses it as a measure to detect substantial changes in block density. Assuming that malicious validators are always a minority, the main branch will always be denser than competing branches. This rule can be used to identify whether an attack has occurred on a blockchain fork and to identify honest branches, eliminating subjective judgment.
To discourage malicious behavior by validator nodes on the blockchain, implementations such as the Ethereum POS version use a slashing mechanism, a financial penalty that results in the loss of the underlying blockchain currency when a validator is found to be guilty of misconduct.
If one or more validators utilize their stake to sign two different blocks at the same point in the chain, they risk losing their leveraged stake.
With economic finality, the protocol guarantees that all validators have something to lose if they misbehave, and in this way deals a bigger blow to the problem of staking nothing.
While economic integrity does not eliminate long-range attacks, it reduces the likelihood of them because validators lose the incentive to carry out any kind of attack on the network.
By definition, storing data on a blockchain is contradictory to maintaining user privacy. Several storage solutions have been proposed to solve this problem, such as IPFS, but secure multiparty computation (SMC) seems to be the only viable solution in the long run.
Currently, SMC is not efficient enough to adequately support arbitrary operations at the speeds required by modern blockchains, so using a trusted execution environment (TEE) to securely execute some of the necessary operations is a viable alternative. Software Guard Extensions (SGX) is the most prominent TEE technology today and is available with commodity CPUs for servers and desktops.
SGX uses execution contexts, called trusted enclaves, on the CPU to isolate data and programs from the underlying operating system, ensuring that the output is correct. An enclave can run only a few dedicated parts of an application, or it can contain an entire legacy system, including some operating system support.
We propose to use a TEE so that all signing is done within the trusted application and the signing key is not available outside of the TEE. This protects the private key from being leaked to an attacker, reducing the likelihood of a Long-Range Attack due to hacking attempts.
Basically, this means that all key pairs are generated by TEE when a node first joins the blockchain.
The key problem with integrating this solution is that each validator has to prove to their peers that they are using TEE for all these procedures. The latter cannot be considered a minor implementation issue that prevents the adoption of this solution.
Blockchain is recognized as a revolutionary technology because it provides a decentralized architecture for storing and processing data among entities that do not trust each other. However, with the widespread adoption of blockchain in various domains, there is a need to provide mechanisms to study and protect related security issues.
In the PoS protocol, the Long-Range Attack is one of the biggest threats to the immutability of the blockchain. This attack may stem from design issues rather than implementation and can be difficult to deal with. This research analyzes the causes of long-range attacks, how they are carried out, and reviews possible countermeasures. The referenced paper, "A Survey on Long-Range Attacks for Proof of Stake Protocols," introduces various types of long-range attacks and their countermeasures, and concludes that no countermeasure can provide complete protection against all threats. Partial countermeasures exist for specific threats, and each protocol implements them differently. Due to hardware limitations, the use of TEEs is promising, but not yet implemented in protocols.
Therefore, when a node comes online, there is no single branch of the blockchain and it cannot determine which is the main chain, creating a Weak Subjectivity issue.
✅ Follow me: X: @Younsle1 Warpcast: @zer0luck
Despite the general argument for the adoption of blockchain technology in terms of security, privacy, and immutability, various attacks can occur on blockchain technology in reality. This article summarizes systematic details on Long-Range attacks for Proof-of-Stake protocols. If successful, these attacks can seize the main chain and partially or completely rewrite transaction records stored on the blockchain. To do this, we will explain blockchain, consensus protocol methods (POS, POW, ...), basic properties, disadvantages, and attack vectors.
https://mirror.xyz/zer0luck.eth/s8oFS1oNkrNg7vdGdpStHN4jLSk0OEsYT5y5Duddtgc
The purpose of this article is to review and study the paper "A Survey on Long-Range Attacks for Proof of Stake Protocols" after reading it. The paper was written by:
Evangelos Deirmentzoglou (Department of Informatics, University of Piraeus, Piraeus, Greece)
Georgios Papakyriakopoulos (Cisco Security Services, Marousi, Greece)
Constantinos Patsakis (Department of Informatics, University of Piraeus, Piraeus, Greece)
The paper can be found at
https://ieeexplore.ieee.org/document/8653269/
The main advantages of Proof of Stake protocols can be the main root-cause of attacks.
Proof-of-Stake protocols do not require significant computational effort on the part of the validator, which minimizes energy consumption, but also means that it costs the attacker nothing to execute the attack. This concept is sometimes referred to as Costless Simulation.
This concept is sometimes referred to as `Costless Simulation'. More popularly known as Nothing at Stake. In practice, since validators do not have to take any risk when making consensus decisions, their optimal behavior is to participate in as many chain forks as possible, since they do not know which fork will become the main fork. This undermines the stability and goals of the main chain.
An attacker can create an alternative branch to the main chain of a proof-of-stake-based blockchain at any point in time without incurring any real costs.
This is not possible in a Proof-of-Work-based blockchain because it requires a huge amount of time and computing power.
The term "weak subjectivity" is used to describe a problem that affects two types of nodes
new nodes in a blockchain network
nodes that have been offline for a significant amount of time and then come back online.
In both cases, node synchronization cannot have concise information about the main chain of the blockchain because it lacks a basis for changes in the blockchain over time. For this reason, Weak Subjectivity does not affect online and synchronized nodes.
Nodes that have just joined the network, starting with the genesis block, can retrieve all currently published blockchain branches. However, new nodes cannot immediately distinguish between major branches of the chain. The latter limitation also applies to nodes that have been offline for a long time.
At some point in the past, this node may have known which branch was the main chain, but after a period of dormancy, it won't recognize it.
Because online nodes monitor the blockchain in real-time, they cannot be tricked into accepting another branch as the main chain unless that branch has legitimately become the main chain.
Therefore, when a node comes online, there is no single branch of the blockchain and it cannot determine which is the main chain, creating a Weak Subjectivity issue.
As you can see in the figure above, there are many different branches in a typical blockchain snapshot. Some of them are longer than others, and all of them are candidates to become the main chain.
The figure above shows a type of blockchain where multiple branches of equal length are visible to all nodes participating in the network, but nodes cannot see the main chain and can be tricked into accepting a malicious chain.
Double spending is one of the problems that blockchain technology has been trying to solve since its inception.
Most, if not all, attacks on blockchains target double-spending at some point in their execution.
In this attack scenario, the attacker attempts to spend the same currency at least twice, resulting in double-spending.
This attack is absolutely impossible in terms of physical currency; it is impossible to purchase resources from one vendor and then spend the same coin with another vendor.
The attacker performs the transaction, waits for the merchant to authorize it, then reverses it and tries to use the same currency in another transaction.
On the blockchain, this can be accomplished by presenting the conflicting transactions at different points, and BFT systems that use absoulite finality are considered robust against the double-spending problem.
Generally refers to a peering network that affects network members with equal rights.
This attack can be executed against blockchain protocols, but it can be successfully mitigated by using appropriate consensus algorithms.
In a sybil attack, an attacker uses multiple identities to issue or mislead the network's decisions or opinions. In blockchains, this can cause many problems, such as confirming and forking blocks or electing validators.
In a POW system, an attacker must possess multiple identities with sufficient computational power to exert significant influence on the system.
Consensus protocols directly defeat this logic by requiring the attacker to divide his computing power into smaller chunks.
This does not benefit the attacker and does not amplify their computing power. Instead, the attacker's computing power remains the same if all identities mine the same block, or decreases if each identity mines a different block.
In either case, the attacker must own a significant amount of computing power, which costs the same as concentrating all computing power in one entity or splitting it across multiple entities.
An attacker can work directly against the consensus protocol. The validator election process and voting power is weighted by "stake".
An attacker has the same voting power if a single identity owns all of the attacker's stake or if it is split between multiple identities.
Generally considered an implementation issue and relies on the existence of probabilistic finality.
On blockchains that do not have absolute finality, a transaction may require multiple confirmations before it is considered complete.
Depending on the transaction, more Requirement Numbers may be used at the merchant/user's discretion. Transactions handling significant amounts of funds may require a higher number of confirmations before being accepted as valid.
Services may not be configured correctly to wait for the recommended Requirement number for a particular blockchain.
In this case, a double-spend attack can occur. An attacker can have a fork of the blockchain mined until it meets the service's weak requirements, take the goods from the "Weakly" verified transaction, and then switch computing power from that branch to the main branch.
This way, the "Weakly" verified transaction will soon be lost at one point in the blockchain and will not be valid on any node after the main chain.
This attack is mitigated by BFT-based proof-of-stake protocols that use absolute finality.
Also known as a Short Range Attack, this attack involves bribing validators or miners to work on a particular block or fork.
This allows the attacker to present fraudulent transactions as valid and pay dishonest nodes to verify them.
By paying an amount equal to or greater than the block reward (if the network reverts the block), it provides a high enough incentive for miners to work on the attacker's block or chain.
P+Epsilon attack
In one case, an attack known as the P+epsion attack says that it is possible to bribe users without paying them.
The system bribes the dishonest node by making that branch the main chain. In this case, the attacker is faced with a more serious problem: if the malicious branch reverts for some reason (the attacker is unable to continue bribing or the dishonest nodes stop working on that branch), the attacker will have to pay a huge bribe because the bribe will accumulate for every block that was maliciously issued.
In a POS system, this kind of attack is possible, and it can extend to the problem of taking nothing.
In either case, the POS should address this issue by applying a slashing condition or removing the offender from the location.
This attack is a form of denial of service attack in the POW protocol. Some or all of the validators decide to take action and stop publishing blocks, intentionally blocking transactions.
If validators do not fulfill their validator duties, the blockchain stops because new blocks cannot be validated and published to the blockchain.
An activeness requirement that gradually exhausts the stakes of inactive validators ensures that the network is not compromised if the majority of validators are offline or performing real-time denial-of-service attacks.
If active status cannot be assessed, the community can decide (via off-chain communication) to fork.
The blockchain can be deleted and inactive validators removed. In all cases, validators performing this type of attack jeopardize their status as validators on the network and their stake if slashing conditions exist.
Censorship on a blockchain is a tricky issue that has generated a lot of discussion because it can be considered both an attack and a feature, depending on the nature of the blockchain.
Validators can control which transactions are added to a block, giving them the power to blacklist certain addresses.
The transactions are in a transaction pool, and the validator pulls them and adds them to the upcoming block.
A validator can also remove some transactions from a block.
In a scenario where a single validator performs censorship, some transactions may be delayed or invalidated due to time constraints.
The risk of censorship becoming a reality increases as the number of validators performing these attacks increases.
Liveness requirements ensure that transactions are finalized and can eliminate censorship from the blockchain. Protocols can also punish nodes that don't produce blocks in the order defined by the protocol.
Another effective solution, Zero-Knowledge succinct non-interactive arguments of knowledge (zk-SNARK), can be used to hide the identity of the transaction sender.
This attack is a threat to all consensus protocols. In a POW system, an entity that controls the majority of the hashing power at any given time can take full control of the blockchain.
For example, they can fork the main chain and start mining on their own branch. Slowly and steadily, the attacker can outpace the main chain and allow their branch to take over.
Since block generation is stochastic in the POW protocol, the probability of conflicting forks increases once the 51% limit is crossed. Thus, the attacker gets the main chain, but a branch reversal often occurs at that point.
Due to the stochastic rewards of POW blockchains, miners tend to consolidate their computing power using mining pools. While mining pools ensure that nodes with lower computing power receive block rewards, they can unintentionally lead to 51% attacks. When the computing power of one mining pool reaches a high level, the miner community moves to competing mining pools to stabilize the network and avoid accidental 51% attacks.
In the POS protocol, this attack is still viable, but the impact is slightly different. A single validator or set of co-validators can own more than 34% of the blockchain (in the case of the BFT Proof of Stake protocol). In this case, a majority attack can affect the blockchain by performing a confirmation reversal, where an already confirmed block is challenged for confirmation by another competing block, which can cause Liveness Denial, Censorship.
When a 51% attack occurs, miners are usually notified, and a community-led fork takes place to reset the honest chain to the main chain.
In a shelfish mining attack, also known as block withhilding, the attacker mines blocks on their own fork of the blockchain without publishing the blocks to the network.
After calculating the desired number of blocks, the attacker releases them to the network in an attempt to revert the main chain back to the attacker's chain.
This attack has two main objectives
disrupt the network by wasting the resources of honest nodes
increase the reward received by the dishonest node.
The former attack incentive purely affects the POW blockchain. The POS blockchain is not disrupted by these incentives. The latter incentive affects both protocols and can be mitigated by applying slashing conditions or removing the offender from a position of power, causing them to lose future rewards.
Grinding attack, also called precomputation attack, is an implementation issue and affects POS systems.
It exploits the lack of randomness in the slot leader election process to manipulate the frequency with which slot rudders are elected in subsequent blocks.
This issue can be addressed by introducing randomness into the process and minimizing or eliminating influencing factors in this process that are controlled by the validator.
In early versions of the protocol, the longer a user's stake was staked with no time limit, the more weight was accumulated.
Given enough time, an attacker could accumulate a huge amount of stake in the system that would allow them to take control of the network.
This mechanism works by amplifying the stake of validators. To mitigate this, the mechanism is either limited to a certain amount of time or removed entirely.
Other attacks on blockchains include eclipse attacks, in which an attacker interferes with the transmission of messages by nodes at the peer-to-peer network level, forcing the nodes to operate on a corrupted or distorted snapshot of the blockchain.
https://mirror.xyz/zer0luck.eth/MdyKCwYJXRoYesj59D-og50c9y5Qm6On3wsIzcpQ8Q8
A long-range attack is an attack scenario where the attacker forks the blockchain by going back to the genesis block.
The new branch is populated with records that are partially or completely different from the main chain. The attack succeeds if the branch created by the attacker is longer than the main chain and overtakes it. There are three types of long-range attacks.
Simple
Posterior Corruption
Stake Bleeding
Long-range attacks in Proof of Stake protocols are related to selfish mining attacks in Proof of Work protocols. In both cases, the attacker adds blocks that are kept secret. Of course, Selifsh mining attacks can't go back to the genesis block of a PoW protocol because the computational effort required is prohibitive, so their impact is limited.
Both attacks fork the main chain, and the attacker attempts to add forged blocks containing potentially different transactions.
We'll start with the simplest case of a long-range attack and build up to more complex scenarios.
In the following example, we consider a validator pool with three validators, the latter of which is designated as the attacker.
For simplicity, assume that they all own the same portion of the system's stake. Each owns a 33,3% stake
Before describing the Long Range Attack, let's implement a simple attack to verify it. A naive implementation of the POS protocol, where nodes do not check the timestamps of blocks, would look like this. When the POS protocol is running, any validator can verify the block, as shown in the following figure.
When a malware launches a long-range attack, it creates an alternate branch of the blockchain. Starting from the genesis block, the malware forks the blockchain and begins issuing branches that may contain different transactions.
The lower branch is the main chain, the upper branch is Mallory's branch, and Mallory has the same probability of being elected in both branches. Forfeited blocks are indicated in parentheses. (There are currently 2 blocks in Malory's branch).
As you can see in the figure above, since the validator information is located inside the genesis block, the malware cannot generate blocks at a faster rate than on the main chain.
Therefore, the malware generates blocks at the same rate. Because of this constraint, malware must generate blocks in advance to advance its branch and overtake the main chain, as shown in the figure below.
White shading and three dots are used to represent different forfeited blocks. In Malory's attempt to compete with the main chain, Malory precomputes blocks. In this snapshot, both branches are the same length.
To do this, the malware must forge timestamps. This is because the malware is the only active stakeholder in the branch that can forge the timestamp. As a result, in an implementation where nodes do not consider timestamps, both branches will be valid and nodes will not be able to detect the malware's forgery.
Now consider a scenario where the malware cannot forge the timestamp of a block.
To change the history of the main chain, we need to generate a larger number of blocks in parallel with the main chain. However, Mallory is constrained by the fact that her probability of generating a block is fixed.
To increase its chances of competing with the main chain, it needs to be able to forge blocks from other validators as well.
For example, if Bob agrees to attack the main chain, the attack is rather straightforward since they both have more than 50% stake (but not necessarily).
To clarify the attack, it is important to understand the concept of validator rotation.
Validator Rotation
Due to the nature, requirements, and expectations of blockchains, there shouldn't be any static components or entities beyond the genesis block.
Validators are no exception to this rule and therefore cannot be considered static and must be rotated for a fair system.
Validators should have the option to retire and the system should replace or remove them based on certain conditions, such as a certain period of time or dishonest behavior.
Finally, just because an entity is considered benign and trustworthy doesn't mean it will remain so after it leaves the system.
Consideration must be given to the fact that verifiers' incentives may change over time or the system may be compromised.
For simplicity, suppose Bob decides to retire after validating the first n blocks of the main chain.
Bob removes his stake and cashes out, so he is no longer part of the blockchain, but his blocks exist. While Bob was active as a validator, he may have used security best practices to store and manage his private keys.
However, once Bob no longer owns a stake in the platform, we argue that the security of his private key for block validation is not a priority for him (since he is no longer a validator).
It's important to note that while he can't sign new blocks, Bob (or anyone with access to Bob's key) can sign the first n blocks on any branch of that blockchain.
This practically means that if you have access to Bob's key, you can forge the blocks he validated.
We should also consider that Bob is no longer part of the system, so there is no incentive for him to do so, as he has nothing to gain.
The above problem is called posterior corruption because of its name.
If Malory hacks Bob and steals his private key, or if Malory bribes Bob and Bob joins the attack, in either case Bob's private key is known to Malory, who can sign valid blocks, and Malory can impersonate Bob and get ahead of the main chain with a high probability.
The lower branch is the main chain, and the upper branch is Mallory branch, which is racing to overtake the main chain. Bob joins Mallory's long-distance attack. The alternate (upper) branch is now much more competitive and more likely to overtake the main chain.
Since Bob is directly or indirectly participating in the attack, he generates blocks on Malory's branch each time he is elected as a block validator. As you can see in the figure above, Bob's blocks in the malicious branch are no longer empty, and the malicious branch is more likely to compete with the main chain.
Suppose again that Mallory, the validator, tries a different type of attack: as in the previous case, she forks the main chain and hides her fork.
She plans to publish it when it's ahead of the main chain, and it's clear that when a fork occurs, she has an equal chance of being elected slot leader on all branches of the blockchain.
The bottom is the main chain, the top is Malory's attempt to create a new fork of the main chain, and the dotted line in Malory's branch is mined, stored locally, and currently unpublished.
To increase the probability of this attack succeeding, Mallory begins to delay the main chain. The idea is that by stalking the main chain, it gains the time it needs to generate blocks and outpace the main chain.
Depending on the percentage of total stake held by Mallory, this can lead to a Liveness Denial Attack.
In the following, we assume that validators' rewards are compounded based on their stake. To launch the attack, every time Mallory is elected as a slot leader on the main chain, she skips her turn and loses her position, as shown in the figure below.
However, this does not mean that another validator will take his place. No new blocks are added to the blockchain for that slot/epoch.
Mallory remain part of the main chain while mining their own quarters. By expropriating her blocks from the main chain, Mallory delays the growth of the main chain and gains a competitive advantage in the alternate branch.
As a result, Mallory does not receive any rewards from the system, and her stake will gradually decrease. Eventually, all other validators will issue blocks and receive block rewards/transaction fees. At the same time, Mallory will be the only validator in her branch to publish a block. Therefore, she will publish blocks every chance she gets.
In this attack, Mallory will try to increase his stake in every way possible.
While performing this attack, Mallory can monitor the behavior of the main chain because it is behind it.
For example, it can choose which transactions to add to each block. The malware also has access to the transaction pool and can select transactions in the transaction pool and add them to the blockchain if they are valid in the context of their branch. To do this, the Mallory copies transactions from the main chain and/or the transaction pool and publishes them to its own branch. The latter goal is to maximize transaction fees and use them to increase her personal stake.
Mallory may prefer to copy transactions that are already on the main chain to arouse less suspicion from network monitors.
Mallory's stake gradually increases on the branch (the parent branch), making her a more frequent block validator, while the main chain continues to read her stake and consequently elect her less frequently.
By stopping the main chain and issuing as many blocks as possible on the alternative chain she forked, Mellory eventually gains a majority stake in her branch. Her stake then begins to grow faster than the main chain, as shown in the figure above.
When her branch outpaces the main chain, she will perform the last transaction.
This attack is somewhat slower. An attacker with 30% stake would need about 6 years of blockchain history to successfully carry out this attack. In contrast, we can use Costless Simulation to instantly create a branch with that amount of blockchain history.
While various mitigation techniques have been presented, none of them can be considered a complete defense individually. Therefore, to protect against this type of attack, you need to have a solution for each of them.
This is the simplest technique to overcome Weakly Subjective.
For the POS protocol, this technique can be considered the default option and is always used in conjunction with other techniques.
It should be noted that POW protocols can only use this technique to counteract weakly subjective.
In practice, for Proof of Work protocols, the longest chain is considered to be the chain that performs the most computational operations.
In principle, according to this Longest Chain Rule, the main chain is the branch with the most blocks. In rare cases, a chain reorg can sometimes occur, in which case the blockchain accepts a different branch as the main chain and the blocks are reorganized.
If a branch of the chain becomes longer than the main chain, the blockchain will reorganize itself to keep the longest branch as the main chain.
The idea behind this rule is that the network recognizes the branch with the most work as the main chain, for example, when two miners on a POW discover a valid block at about the same time.
If a transaction from another branch disappears, it is not completely lost. They can be moved to a pool of unconfirmed transactions and then placed in a block. This makes it easier to track and avoid double-spending issues.
Moving checkpoints is a mitigation technique used in almost all POS protocols.
Due to its simplicity and ease of implementation, it is one of the first mitigation techniques to be applied in POS blockchains after the Longest Chain Rule.
The basic idea behind checkpointing is that the last N blocks in the chain have a quota, which can be reordered.
Depending on the protocol, the block quota can change. In the case of Peer-coin, the quota is limited to a month's worth of blocks. This defense mechanism allows for some block reorgs, which can partially mitigate long-range attacks.
Snapshot structure of the blockchain using a move checkpoint with a factor of 2. Only the last two blocks can be reorganized. The gray blocks represent the truly immutable parts of the blockchain, and the red branch is invalid because it attempts to change the gray blocks.
With Moving Checkpoint, the Long-Range Attack is downgraded and now falls into the Short-Range Attack category, since the reorganization does not start from the genesis block. The main chain will not be able to change until the latest n blocks.
In a post-corruption attack, a retired validator can be used by an attacker to sign previous blocks in the blockchain, even if the key is no longer used or valid.
Various key-evolving cryptographies have been proposed to counter this threat.
https://eprint.iacr.org/2017/573.pdf
The idea of Key-Evolving Sign (KES) is that the lifetime of a key is divided into periods when different private keys are used, but the public key remains the same. In this regard, there is a key update algorithm that derives a new private key from the old private key. The epoch in which the signature was issued becomes an integral part of the entire signature. Therefore, even if the key is compromised, it cannot be used to re-sign previous messages.
By forcing the slot reader to sign the block in a KES fashion, the key used is immediately useless to the attacker. Without the ability to use continuously evolving keys and recover previous versions of the signing key, the attack becomes useless.
If Bob decides to sign an old block from a different quarter, he will not be able to use key-Evolving again for the genesis block because he has already used it to sign a different quarter.
Every block on the blockchain contains a hash of the previous block in its header. This is used to identify the point at which the block is located and to concatenate blocks. Context-Aware Transaction takes this linkage a step further by including the hash of the previous block within the transaction. This allows you to associate a transaction with a specific block in a specific branch of the blockchain.
Because transactions contain references to the blockchain's past history, they can't be copied to other branches. They can be copied to other branches and still be valid. It can't be copied unless the reference also exists in that branch.
Malory copies the transaction from the red branch to advance her chain, but the transaction is linked to Bob's block. Malory’s branch will be rejected as inconsistent by honest nodes.
Additionally, research has been done on universal hash time, which uses a time hash to establish a transaction reference tied to a specific point in time. With Context-Aware Transactions, an attacker will not be able to copy transactions from the main chain to their own branch. While this doesn't completely eliminate the attack, it can greatly reduce the impact of the attack because it requires the attacker to create a completely different record. Therefore, it can be considered an effective mitigation technique for Long-Range Attacks.
A more sophisticated countermeasure to the Long-Range Attack is the Plenitude Rule, which was first proposed as part of the POS-based protocol Ouroboros Genesis among other mitigation techniques. This chain selection rule is based on detecting the sparsity and density of blocks on conflicting branches.
https://eprint.iacr.org/2017/573.pdf
An attacker cannot manipulate their stake in the main chain, so an attacker with a 20% starting stake will have the same stake in every branch of the blockchain, assuming all branches are derived from the same starting block, as shown in the flow below.
In the case of a Long-Range Attack, the attacker starts generating blocks with a small probability, earning block rewards and accumulating more and more stakes as the stakes accumulate.
The more stakes a validator has, the more chances they have to generate a block. It is calculated that the remaining validators, i.e., the honest validators, generate 80% of the blocks before the malicious validators accumulate enough stakes to accelerate the rate of block generation. According to the latter, it is clear that one point will only generate a fraction of the block.
A snapshot of the blockchain up to the target point, validators have an equal probability of generating a block from a particular branch. If the top branch is Mallory's fork, Bob and Alice are still elected as block validators, even though they don't know the branch and therefore can't generate a block for it (a forfeited block is generated).
The same is not true for the other branches. This is because in a given slot, one branch may account for more than 80% of the block generation, while the other branch may only account for at most 20%.
In a blockchain snapshot where the malicious branch is sparsely populated by the first segment, the total number of blocks published by both branches is the same, but upon inspection, the block generation rate of the first segment is very different.
In the blockchain snapshot, we can observe how stake accumulation works. In the first two segments, the top quarter, which is the malicious quarter, generates blocks quite infrequently compared to the third quarter.
In the other branches, we observe a smoother distribution of block generation across all segments.
If a block is empty, it doesn't necessarily mean that the validator (in this case, Alice) is intentionally blocking the chain; sometimes the slot is empty because no transactions have been performed for a certain period of time.
In the third segment, the parent chain accumulates enough stake and block generation starts to become dense. When this happens, the attacker's stake continues to grow from the point at which they minted, while the honest validator's stake gradually decreases. As a result, blocks from the alternate branch are issued more frequently and eventually overtake the main chain.
The majority rule determines block density from the formation of branches and uses it as a measure to detect substantial changes in block density. Assuming that malicious validators are always a minority, the main branch will always be denser than competing branches. This rule can be used to identify whether an attack has occurred on a blockchain fork and to identify honest branches, eliminating subjective judgment.
To discourage malicious behavior by validator nodes on the blockchain, implementations such as the Ethereum POS version use a slashing mechanism, a financial penalty that results in the loss of the underlying blockchain currency when a validator is found to be guilty of misconduct.
If one or more validators utilize their stake to sign two different blocks at the same point in the chain, they risk losing their leveraged stake.
With economic finality, the protocol guarantees that all validators have something to lose if they misbehave, and in this way deals a bigger blow to the problem of staking nothing.
While economic integrity does not eliminate long-range attacks, it reduces the likelihood of them because validators lose the incentive to carry out any kind of attack on the network.
By definition, storing data on a blockchain is contradictory to maintaining user privacy. Several storage solutions have been proposed to solve this problem, such as IPFS, but secure multiparty computation (SMC) seems to be the only viable solution in the long run.
Currently, SMC is not efficient enough to adequately support arbitrary operations at the speeds required by modern blockchains, so using a trusted execution environment (TEE) to securely execute some of the necessary operations is a viable alternative. Software Guard Extensions (SGX) is the most prominent TEE technology today and is available with commodity CPUs for servers and desktops.
SGX uses execution contexts, called trusted enclaves, on the CPU to isolate data and programs from the underlying operating system, ensuring that the output is correct. An enclave can run only a few dedicated parts of an application, or it can contain an entire legacy system, including some operating system support.
We propose to use a TEE so that all signing is done within the trusted application and the signing key is not available outside of the TEE. This protects the private key from being leaked to an attacker, reducing the likelihood of a Long-Range Attack due to hacking attempts.
Basically, this means that all key pairs are generated by TEE when a node first joins the blockchain.
The key problem with integrating this solution is that each validator has to prove to their peers that they are using TEE for all these procedures. The latter cannot be considered a minor implementation issue that prevents the adoption of this solution.
Blockchain is recognized as a revolutionary technology because it provides a decentralized architecture for storing and processing data among entities that do not trust each other. However, with the widespread adoption of blockchain in various domains, there is a need to provide mechanisms to study and protect related security issues.
In the PoS protocol, the Long-Range Attack is one of the biggest threats to the immutability of the blockchain. This attack may stem from design issues rather than implementation and can be difficult to deal with. This research analyzes the causes of long-range attacks, how they are carried out, and reviews possible countermeasures. The referenced paper, "A Survey on Long-Range Attacks for Proof of Stake Protocols," introduces various types of long-range attacks and their countermeasures, and concludes that no countermeasure can provide complete protection against all threats. Partial countermeasures exist for specific threats, and each protocol implements them differently. Due to hardware limitations, the use of TEEs is promising, but not yet implemented in protocols.
Share Dialog
Share Dialog
No comments yet