You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Although Harmony blockchain assumes up to 1/3 of malicious staking power to ensure liveness & safety of BFT, the attacker might have the motivation to stake more than this threshold, in particular more than 2/3 of the total stake.
51% attack in PoW
The classic example of violating the minimal honest threshold occurred in PoW blockchain in so-called 51% attack, where the malicious party executed inter-chain exchange, while it was able to revert the weaker blockchain even time to finality has elapsed, and thus accomplished double-spending (e.g., ETC in 2019).
2/3 attack in PoS of Harmony
While the inter-chain exchange is a potential motivation for 51% or 2/3+ attacks, on top of that Harmony contains another motivation that the attacker might benefit from: the nature of commit/reveal protocol in OneWallet using only OTPs - if the commit tx can be reverted after reveal is published, then the 2/3+ attacker can arbitrarily change the address of the transfer to malicious address(es). Assuming a single user using OneWallet will not make the motivation for this attack high. However, if there were millions of users, transferring billions of ONE token within a single staking epoch, then the motivation is substantially increased. The attacker is basically capable of reverting and replacing all OneWallet transfers within the epoch (very close to the end of the epoch). At the early beginning of the next epoch, the attacker can withdraw the funds or at least hide by some mixers.
Slashing from the stake
Even the beacon chain does not help - if attacker has more than 2/3 of the staking power, she will likely have more than 2/3 even in the beacon chain, so it does not help. When the majority attacker finishes the epoch, it is too late to slash her for signing two different blocks at the same height in a shard since the staked amount was already withdrawn and anonymized.
Example and preventive constrains
So, this potential attack should be subject to adjustment of the maximum amount for OTP-only confirmed transfer. If we were to assume 20% of the total block gas limit of the epoch attributed to OneWallet transfers and overall cost of one transfer equal to 367k (i.e., 115k for commit and 252 for the reveal) of gas, then we would end up with ~1.4M txs per epoch (80M / 367k * 2^15 * 0.2). If we were to assume the limit of OTP-confirmed transfer equal to 500$, then the overall transferred amount would be equal to 714M$, which is around 2x higher than the current value of the stake - 376M$ (0.082 * 4562251726). However, these parameters might change, and I demonstrated it only as a model example. Therefore, it is important to keep the upper limit of OTP-only transfers as low as possible (e.g., 100 USD). Also, it is important to monitor the total amount of ONE tokens transferred by OneWallet with regard to the total stake value, while keeping the total stake high enough to make such an attack improfittable (although another issue is a combination of such an attack with double-spending during inter-chain exchange).
The text was updated successfully, but these errors were encountered:
Although Harmony blockchain assumes up to 1/3 of malicious staking power to ensure liveness & safety of BFT, the attacker might have the motivation to stake more than this threshold, in particular more than 2/3 of the total stake.
51% attack in PoW
The classic example of violating the minimal honest threshold occurred in PoW blockchain in so-called 51% attack, where the malicious party executed inter-chain exchange, while it was able to revert the weaker blockchain even time to finality has elapsed, and thus accomplished double-spending (e.g., ETC in 2019).
2/3 attack in PoS of Harmony
While the inter-chain exchange is a potential motivation for 51% or 2/3+ attacks, on top of that Harmony contains another motivation that the attacker might benefit from: the nature of commit/reveal protocol in OneWallet using only OTPs - if the commit tx can be reverted after reveal is published, then the 2/3+ attacker can arbitrarily change the address of the transfer to malicious address(es). Assuming a single user using OneWallet will not make the motivation for this attack high. However, if there were millions of users, transferring billions of ONE token within a single staking epoch, then the motivation is substantially increased. The attacker is basically capable of reverting and replacing all OneWallet transfers within the epoch (very close to the end of the epoch). At the early beginning of the next epoch, the attacker can withdraw the funds or at least hide by some mixers.
Slashing from the stake
Even the beacon chain does not help - if attacker has more than 2/3 of the staking power, she will likely have more than 2/3 even in the beacon chain, so it does not help. When the majority attacker finishes the epoch, it is too late to slash her for signing two different blocks at the same height in a shard since the staked amount was already withdrawn and anonymized.
Example and preventive constrains
So, this potential attack should be subject to adjustment of the maximum amount for OTP-only confirmed transfer. If we were to assume 20% of the total block gas limit of the epoch attributed to OneWallet transfers and overall cost of one transfer equal to 367k (i.e., 115k for commit and 252 for the reveal) of gas, then we would end up with ~1.4M txs per epoch (80M / 367k * 2^15 * 0.2). If we were to assume the limit of OTP-confirmed transfer equal to 500$, then the overall transferred amount would be equal to 714M$, which is around 2x higher than the current value of the stake - 376M$ (0.082 * 4562251726). However, these parameters might change, and I demonstrated it only as a model example. Therefore, it is important to keep the upper limit of OTP-only transfers as low as possible (e.g., 100 USD). Also, it is important to monitor the total amount of ONE tokens transferred by OneWallet with regard to the total stake value, while keeping the total stake high enough to make such an attack improfittable (although another issue is a combination of such an attack with double-spending during inter-chain exchange).
The text was updated successfully, but these errors were encountered: