Subscribe to Untitled
Subscribe to Untitled
Share Dialog
Share Dialog
<100 subscribers
<100 subscribers
If you find yourself asking “What is Abacus?” I’d suggest going here for a quick primer!
As of late, the Sybil attack has resurfaced as a very real threat to protocol security. This article will address Abacus’ defensibility against a Sybil attack. This article will briefly explain what a Sybil attack is, how this attack could be used against something like Abacus, and how the Abacus protocol defends against it.
When operating on a globally shared computer, such as Ethereum, there is a limited amount of processing power available to that machine. A miner provides the network with this necessary computing power and is paid by the network for contributing computing power to secure the network. Due to a limited amount of contributed power and the lack of an identity system (beyond a wallet address) in the Web3 world, this creates a clear attack vector for any malicious actor looking to disrupt the network. A Sybil attack in the case of a shared network such as Ethereum would take the form of constantly sending transactions between wallets (which the attacker owns). This can be done an infinite amount of times which would affect the availability of the network’s shared computing power and therefore clog the system with “fake” transactions. Doing this, would halt all real transactions and basically render the network bugged. Something similar like this happened to Solana recently and I’ll attach an interesting thread about what can come out of a successful Sybil attack on a network here. How does Ethereum fight against this? With gas fees! Now, for every transaction attempted in this Sybil attack the user will have to pay for computing power used. Therefore, an attack like this will be incredibly costly to the attacker. Gas fees are a form of each user paying the network for using its power.
Attack -- Forcing a price to be above or below a certain amount: A user has an interest to force a price above a certain value. Attack vector would be submitting as many votes at the maximum value available. This would need to be tailored to the amount of users participating in the session and the amount of Ether currently staked. With that information the attacker can then go and check Etherscan to check what each user’s stake amount was and calculate the total amount of votes in the session. With this information they can now come in at the end of the session and submit the exact amount of maximum votes required to force the price above a certain value.
Defense:
An attack like this assumes a few things. One, the attacker is willing to lose all of the money spent to carry out the attack. Losses are harvested based on margin of error - 5% which means that any extreme entry (i.e. each entry that pushes the price higher) will come at a cost to the attacker. So, the value that they are gaining through this manipulation must be higher than the amount required to actually execute it. For the purposes of this post, let’s assume that it does. Let’s take a tour through the mindset of an attacker and what they may gain through price manipulation of this form.
Case 1 - seller scam: Why would a user need to push a price above a certain threshold? We can posit that the attacker isn’t a buyer, because pushing the value higher is in the interest of the seller. So, we can first focus on the case in which an attacker is attempting to sell an NFT and is willing to spend a certain amount in order to scam a buyer and earn a profit on the flip. In this case, a basic economic concept of price elasticity comes into play. A buyer is likely only willing to pay a certain amount for an NFT of interest. Therefore, in the case of a seller trying to scam a buyer, if the seller attempts to price NFT at some ludicrous price, the buyer will walk away and the attacker just lost money in this attempt. Additionally, if the buyer was curious to re-run a session or even do diligence (if the price seems fishy) they could look at the session history and very easily see an actor came in and jacked up the price at the very end. Furthermore, there are many other factors that keep the extremity of this price in check. For example, if an NFT is part of a collection the buyer can take one look at the collection and see something is very off about the offered sale price (if it was manipulated). All of these scenarios are very likely in the case of an attempted sale scam. In every case, the attacker will lose a significant sum of money.
Case 2 - DeFi manipulation: Why would a user need to push a price above a certain threshold? We can posit that the attacker isn’t the LP, rather they are likely the borrower in one of two cases: a) seeking more liquidity or b) fabricating price level to avoid liquidation. In this case, price elasticity comes back into play. In the case where a user is seeking liquidity, demand to provide liquidity at that price must exist. So in the case where a price is incredibly high due to manipulation, a user may end up being required to pay a higher interest rate for less liquidity than they would’ve received for a non manipulated price. Additionally, we must not forget to add on the cost of forcing the session to be above a certain price in this case which should be considered as a net negative to the users level of liquidity. In the case of attempting to stop a liquidation event if an NFT’s true value drops below a certain value. The volume of votes required to guarantee the value of the NFT in a blind valuation system would be incredibly high. Furthermore, any funds spent trying to guarantee this will more than likely have a return of -90%+ on the amount invested to do this. So, the amount required must be below either the cost of the NFT or the cost of topping off a session to stop liquidation. In the case where all of the stars align for a successful attempt at this, the liquidity providers and lenders are both incentivized to run pricing sessions as often as possible. Therefore, this attack will likely be overwritten by a new session very quickly, in which case now the compounded costs of the attacker must satisfy the condition of being below the cost of the NFT
Attack -- Buy 95% of a session, set final appraisal to extreme value, siphon 95% of all other stakes in session. A profit seeking entity (i.e. anyone) may seek to manipulate a session in order to guarantee that they steal all user profits.
A malicious user tracks multiple sessions and (same as above) tracks the amount of votes in each session through a script that watches Etherscan transactions related to sessions of interest. In doing so, the attacker will know the amount of votes required to take control and can then create as many fake accounts needed to reach that vote count and set the price to the price of their choice. What does this accomplish? If they take control of 95% of a pricing session and set an extreme price they can steal 95% of other participants’ stake that have now been put in the “opposing” 5% of the session. This attack can be carried out over and over to harvest Abacus tokens or just general profits.
Defense:
In order to do this, the user would need to have a large sum of money to counteract the quadratic staking mechanism used by the protocol. For purposes of this paper, let’s assume the attacker has enough money to buy 95% of a session. The protocol has a built-in Sybil protection which checks if 90% of a session’s participants are “in the money”. In this case, the only claimable reward by “in the money” users will be the session bounty. How does this stop a profit seeker from exploiting the system? This is because if a single user tries to come in and attack a session, all of their rewards from their sybil attack will be crunched into that 5%. Furthermore, since the capital required to be able to buy 95% of a session is so high (due to quadratic staking) a profit seeker will not be willing to take on any risk of uncertainty that would result in a 1% loss of a large sum of money. Therefore, by setting the limit at 90% we’re opening this up to at least a 5% loss in an attempted attack. So, what if there is a bounty on a session, why wouldn’t an attacker come hit the session? This is because a bounty is fixed, in this case a bounty is likely to drive traffic to a session. If there is traffic the cost of the attack is likely to outweigh the reward. Additionally, if this reasoning isn’t enough, the larger the session the more accounts that need to be created. As the amount of accounts increases, the cost of claiming the value to each account increases while the amount that each account can actually claim decreases. Meanwhile, if the session reached a true 95% consensus (no bad actor involved) on the value the reward per user that is taken away by removing the slashed stakes from the reward pool would be negligible.
TLDR of the above is that if you’re a bad actor, don’t come knocking on Abacus’ door because you’ll have a bad time.
Any thoughts, questions, concerns please reach out to me via discord (medici#2970) or twitter (@0x_Medici)!
To stay up-to-date with Abacus:
Twitter: https://twitter.com/abacus_wtf
Discord: discord.gg/WZUv4y5rPd
If you find yourself asking “What is Abacus?” I’d suggest going here for a quick primer!
As of late, the Sybil attack has resurfaced as a very real threat to protocol security. This article will address Abacus’ defensibility against a Sybil attack. This article will briefly explain what a Sybil attack is, how this attack could be used against something like Abacus, and how the Abacus protocol defends against it.
When operating on a globally shared computer, such as Ethereum, there is a limited amount of processing power available to that machine. A miner provides the network with this necessary computing power and is paid by the network for contributing computing power to secure the network. Due to a limited amount of contributed power and the lack of an identity system (beyond a wallet address) in the Web3 world, this creates a clear attack vector for any malicious actor looking to disrupt the network. A Sybil attack in the case of a shared network such as Ethereum would take the form of constantly sending transactions between wallets (which the attacker owns). This can be done an infinite amount of times which would affect the availability of the network’s shared computing power and therefore clog the system with “fake” transactions. Doing this, would halt all real transactions and basically render the network bugged. Something similar like this happened to Solana recently and I’ll attach an interesting thread about what can come out of a successful Sybil attack on a network here. How does Ethereum fight against this? With gas fees! Now, for every transaction attempted in this Sybil attack the user will have to pay for computing power used. Therefore, an attack like this will be incredibly costly to the attacker. Gas fees are a form of each user paying the network for using its power.
Attack -- Forcing a price to be above or below a certain amount: A user has an interest to force a price above a certain value. Attack vector would be submitting as many votes at the maximum value available. This would need to be tailored to the amount of users participating in the session and the amount of Ether currently staked. With that information the attacker can then go and check Etherscan to check what each user’s stake amount was and calculate the total amount of votes in the session. With this information they can now come in at the end of the session and submit the exact amount of maximum votes required to force the price above a certain value.
Defense:
An attack like this assumes a few things. One, the attacker is willing to lose all of the money spent to carry out the attack. Losses are harvested based on margin of error - 5% which means that any extreme entry (i.e. each entry that pushes the price higher) will come at a cost to the attacker. So, the value that they are gaining through this manipulation must be higher than the amount required to actually execute it. For the purposes of this post, let’s assume that it does. Let’s take a tour through the mindset of an attacker and what they may gain through price manipulation of this form.
Case 1 - seller scam: Why would a user need to push a price above a certain threshold? We can posit that the attacker isn’t a buyer, because pushing the value higher is in the interest of the seller. So, we can first focus on the case in which an attacker is attempting to sell an NFT and is willing to spend a certain amount in order to scam a buyer and earn a profit on the flip. In this case, a basic economic concept of price elasticity comes into play. A buyer is likely only willing to pay a certain amount for an NFT of interest. Therefore, in the case of a seller trying to scam a buyer, if the seller attempts to price NFT at some ludicrous price, the buyer will walk away and the attacker just lost money in this attempt. Additionally, if the buyer was curious to re-run a session or even do diligence (if the price seems fishy) they could look at the session history and very easily see an actor came in and jacked up the price at the very end. Furthermore, there are many other factors that keep the extremity of this price in check. For example, if an NFT is part of a collection the buyer can take one look at the collection and see something is very off about the offered sale price (if it was manipulated). All of these scenarios are very likely in the case of an attempted sale scam. In every case, the attacker will lose a significant sum of money.
Case 2 - DeFi manipulation: Why would a user need to push a price above a certain threshold? We can posit that the attacker isn’t the LP, rather they are likely the borrower in one of two cases: a) seeking more liquidity or b) fabricating price level to avoid liquidation. In this case, price elasticity comes back into play. In the case where a user is seeking liquidity, demand to provide liquidity at that price must exist. So in the case where a price is incredibly high due to manipulation, a user may end up being required to pay a higher interest rate for less liquidity than they would’ve received for a non manipulated price. Additionally, we must not forget to add on the cost of forcing the session to be above a certain price in this case which should be considered as a net negative to the users level of liquidity. In the case of attempting to stop a liquidation event if an NFT’s true value drops below a certain value. The volume of votes required to guarantee the value of the NFT in a blind valuation system would be incredibly high. Furthermore, any funds spent trying to guarantee this will more than likely have a return of -90%+ on the amount invested to do this. So, the amount required must be below either the cost of the NFT or the cost of topping off a session to stop liquidation. In the case where all of the stars align for a successful attempt at this, the liquidity providers and lenders are both incentivized to run pricing sessions as often as possible. Therefore, this attack will likely be overwritten by a new session very quickly, in which case now the compounded costs of the attacker must satisfy the condition of being below the cost of the NFT
Attack -- Buy 95% of a session, set final appraisal to extreme value, siphon 95% of all other stakes in session. A profit seeking entity (i.e. anyone) may seek to manipulate a session in order to guarantee that they steal all user profits.
A malicious user tracks multiple sessions and (same as above) tracks the amount of votes in each session through a script that watches Etherscan transactions related to sessions of interest. In doing so, the attacker will know the amount of votes required to take control and can then create as many fake accounts needed to reach that vote count and set the price to the price of their choice. What does this accomplish? If they take control of 95% of a pricing session and set an extreme price they can steal 95% of other participants’ stake that have now been put in the “opposing” 5% of the session. This attack can be carried out over and over to harvest Abacus tokens or just general profits.
Defense:
In order to do this, the user would need to have a large sum of money to counteract the quadratic staking mechanism used by the protocol. For purposes of this paper, let’s assume the attacker has enough money to buy 95% of a session. The protocol has a built-in Sybil protection which checks if 90% of a session’s participants are “in the money”. In this case, the only claimable reward by “in the money” users will be the session bounty. How does this stop a profit seeker from exploiting the system? This is because if a single user tries to come in and attack a session, all of their rewards from their sybil attack will be crunched into that 5%. Furthermore, since the capital required to be able to buy 95% of a session is so high (due to quadratic staking) a profit seeker will not be willing to take on any risk of uncertainty that would result in a 1% loss of a large sum of money. Therefore, by setting the limit at 90% we’re opening this up to at least a 5% loss in an attempted attack. So, what if there is a bounty on a session, why wouldn’t an attacker come hit the session? This is because a bounty is fixed, in this case a bounty is likely to drive traffic to a session. If there is traffic the cost of the attack is likely to outweigh the reward. Additionally, if this reasoning isn’t enough, the larger the session the more accounts that need to be created. As the amount of accounts increases, the cost of claiming the value to each account increases while the amount that each account can actually claim decreases. Meanwhile, if the session reached a true 95% consensus (no bad actor involved) on the value the reward per user that is taken away by removing the slashed stakes from the reward pool would be negligible.
TLDR of the above is that if you’re a bad actor, don’t come knocking on Abacus’ door because you’ll have a bad time.
Any thoughts, questions, concerns please reach out to me via discord (medici#2970) or twitter (@0x_Medici)!
To stay up-to-date with Abacus:
Twitter: https://twitter.com/abacus_wtf
Discord: discord.gg/WZUv4y5rPd
Forcing a price to be below a certain amount: The same inherent protocol defenses deployed above apply to the case of attempting to force a session below a certain value. Any cost incurred trying to force a price down will require more capital than what is required in the opposite case. The reason for this is because a single user can coordinate (at a high cost) increasing the maximum appraisal value. On the downside a user can’t appraise an NFT at below 0 ETH (limit will likely be set at 0.001 eth). Therefore, more capital will need to be sacrificed and lost in an attempt to force the value below a certain amount.
Forcing a price to be below a certain amount: The same inherent protocol defenses deployed above apply to the case of attempting to force a session below a certain value. Any cost incurred trying to force a price down will require more capital than what is required in the opposite case. The reason for this is because a single user can coordinate (at a high cost) increasing the maximum appraisal value. On the downside a user can’t appraise an NFT at below 0 ETH (limit will likely be set at 0.001 eth). Therefore, more capital will need to be sacrificed and lost in an attempt to force the value below a certain amount.
No activity yet