Attack
In a decentralized environment, one of the key design challenges is how to deal with potential adversarial attackers. This is especially crucial for Opera due to the financial applications of Opera blockchain.
We will describe several common attacks and how they are circumvented. We will also present possible solutions to prevent potential new attacks that might arise due to our design.
In a DAG-based protocol, a parasite DAG is made with a malicious purpose to revert the transaction history. Due to our 1/3-aBFT Lachesis consensus, the finality may be violated, only if more than 1/3W nodes are Byzantine (malicious).
Like other previous 1/3-BFT systems, our Lachesis consensus assumes that less than 1/3W of the stake holders are malicious.
A malicious participant may run a large number of valid transactions from their account under their control with the purpose of overloading the network. In order to prevent such a case, the blockchain will impose a minimal transaction fee. Since there is a transaction fee, it's very expensive to flood the transactions pool.
There's another way to flood the network with transactions - by emitting huge events with large number of conflicted transactions, as quickly as possible. Each event consumes the certain amount of validator's gas power (depending on GasLimit of originated transactions). The gas power value will limit the maximum number of transactions per second which may be originated by a validator.
A malicious validator may try to overload the network by emitting valid events as fast as possible. Each event consumes a certain amount of validator's gas power, which limits the maximum number of events per second.
A malicious validator may also try to overload the network by emitting fork events rapidly.
If a fork is observed by self-parent of a validator V, then validator V will not include events from the cheater as parents.
It will limit the maximum number of fork events from the cheater as n, where n is number of validators).
Hence, the total number of fork events in a graph is limited by n^2, in a case if all validators are cheaters.
In the example below, the red edges are forbidden, and green/black edges are allowed:
Additionally, epochs gets sealed and hence cheater gets pruned immediately from the validators group after the first finalized block which observes the doublesign.
A double spend attack is when a malicious entity attempts to spend their
funds twice. Account A has 10 tokens, it sends 9.99 tokens to B and 9.99 tokens to C.
Both A->B and A->C transactions are valid, since A has the funds to send to B or C.
Yet transactions are dependent (in our example, transactions have equal nonce) -
they may both get into event(s) (which is unlikely due to internal protections,
but still possible),
but they cannot both get confirmed.
Our aBFT consensus algorithm determines the ordering of events, which is consistent on all the
nodes unless more than 1/3W nodes are Byzantine. Once the order is computed, a new block is created and
transactions in that block get executed. One of the transactions {A->B, A->C} will get ordered before another
(let's assume it's A->B). Then A->B will be executed successfully, and so A->C will get
skipped because the tx nonce was already "occupied" by the A->B transaction.
'A' will pay fee only for A->B transaction. Yet validator(s)'s gas power will get decreased by GasLimit of both transactions,
as a penalty for originating conflicting transactions.
An adversary could bribe nodes to emit malicious fork events. This is a common concern for existing PoS blockchains. However, Lachesis can avoid it.
Since 2/3W participating nodes are required to create a new block in a malicious DAG, this would require the adversary to bribe at least 2/3W+1 of all validators to begin a bribery attack.
If a fork is observed by Atropos (i.e. subgraph of Atropos includes a pair of events with the same sequence number, from the same validator), then the penalty is applied against the 'cheating' validator.
If a fork is posted for a past epoch which was already sealed, then a Misbehaviour proof may be filed if a part of fork events is observed
in an epoch which is not older than MaxLiableEpochs.
Here, a pseudo scenario on a PoS chain is presented. An attacker may acquire private keys from an old validator, who has already withdrawn stake, to activate validators
with a condition that misbehaviour will be done only in epochs which are at least MaxLiableEpochs old.
This way, the attacker will be able to escape slashing by construction of the attack.
An attacker may buy private keys of either:
- old validators who have already withdrawn stake
- active validators with a condition that misbehaviour will be done only in epochs which are at least
MaxLiableEpochsold.
However, such a misbehaviour can be avoided in Lachesis, as it can be only attempted in old epochs. More details are as follows:
- Lachesis consensus is irreversible locally and so existing nodes won't be affected. Even in case double-signed votes (for a past or current epoch) can be attempted by some dishonest nodes, those votes imply that a different Atropos must be calculated, the node will continue to accept the first calculated Atropos. Moreover, go-opera node doesn't have technical means to re-evaluate past Atroposes. Thus, this attack will affect only nodes that were syncing from scratch the affected epoch during or after the attack.
- New genesis files are periodically updated to include latest epochs (more often than
MaxLiableEpochs). If a new node uses an up-to-date genesis file, it won't be affected even though there were an attack on a past epoch.
We are a leaderless system requiring 2/3W participation. An adversary would have to deny > 1/3W participants to be able to successfully mount a DDoS attack.
Validators are participants with stake >= minimum validator stake.
Holding minimum validator stake is expensive enough to prevent a Sybil attack.
Cryptographic protocols are susceptible to attack by the development of a sufficiently large quantum computer. Of specific interest to cryptocurrencies is how this relates to the elliptic curve signature scheme. Optimistic estimates state that this can be broken by a quantum computer as early as 2027, it is therefore important to adopt a post-quantum signature scheme.
Our signatures are based on the Elliptic Curve Digital Signature Algorithm secp256k1 curve. The security of this system is based on the hardness of the Elliptic Curve Discrete Log Problem (ECDLP).
How quickly can a quantum computer compute the Elliptic Curve Discrete
Log Problem? An instance with a n bit prime field, can be solved using
9n + 2 \[log2(n)]+10 logical qubits and (448*log2(n)+4090)n3 Toffoli
gates. We use n=256 bit signatures.
For 10GHz clock speed and error rate of 10−5, the signature can be cracked in 30 minutes using 485550 qubits.
So if all Elliptic Curve Digital Signature Algorithms are susceptible, then how can you implement a quantum proof solution?
We're limited about signature and public key lengths, since these have to be stored to fully verified.
Hash based schemes like XMSS have provable security. Grover’s algorithm can still be used to attack. DILITHIUM at 138 bits require time 2125
A truly quantum proof cryptographic algorithm does not currently exist. Instead, our architecture allows for multiple cryptographic implementations to be plug and play, given the modular architecture design. Since we aren’t focusing on tightly coupled architecture, it means we could implement XMSS and DILITHIUM (and something new we haven’t announced yet).
See LLR page.