Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Violating PoS protocol assumptions by 2/3+ attack (increasing a motivation by OTP-only transfers) #70

Open
ivan-homoliak-sutd opened this issue Aug 9, 2021 · 2 comments
Assignees

Comments

@ivan-homoliak-sutd
Copy link
Collaborator

ivan-homoliak-sutd commented Aug 9, 2021

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).

@polymorpher
Copy link
Owner

Would 20% be too high to assume? Let's keep this in mind and revisit after 10k users

@polymorpher
Copy link
Owner

We should also set up proper analytics to track usage and consumption at every level. It was scheduled for September. Might need it sooner than that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants