Blockchain is not Secure?
Wallets can improve Blockchain Security…
When we search for the benefits of blockchain technology, the first thing we always read or hear is how it can bring an extra layer of security to our web2 technologies. I do not doubt that in general cases digital cryptography has served as a great shield against cyber attacks. With an introduction to Zero-Knowledge Proof protocols, there is no doubt that blockchain technology will be the future of digital security.
However, blockchain adoption is in the future. To make such a technology ready for bigger and universal applications, it needs to become better (obviously just like any new technology). I have seen over the years that blockchain technology has improved with verification protocols to improve mining energy consumption and reduce the probability of a 51% attack, introduce Zero-Knowledge Proofs, etc. However, what the industry lacks in improvement are wallet and smart-contract security that are not verification protocols.
Although such protocols do a great job in maintaining security, for bigger DAOs and organizations, protocols are not enough as such contracts are faced with stronger attacks. One of the most common attacks larger web3 exchanges and organizations face is supply depletion — something that FTX and various other small crypto exchanges have also similarly faced.
How does Supply Depletion Occur?
Supply Depletion is simple but yet currently very dangerous for web3 organizations and exchanges. Supply depletion often occurs when one account creates multiple transactions to remove the supply of the main contract. These transactions are often called ‘spam’ transactions as they happen frequently. Such transactions are used to reduce the total supply such that the holder of all spam accounts now becomes the majority stakeholder of the currency. This type of attack is predominantly used either for financial gain or to gain legitimacy in a DAO where the majority vote would be towards the account that has created the spam transactions.
Stopping Supply Depletion
Currently, there is no ‘efficient’ way to stop supply depletion. However, the most we can currently do while ensuring web3 organizations keep its ‘decentralized’ nature is to cross-check sender accounts based on certain parameters in a wallet. Essentially, if an account fails to meet certain parameters of verifying that it is not a bot or spam account (these parameters can be established by an organization or exchange of their currency), the transaction will not go through and will warn the sender’s wallet. As a result, one way to reduce such an attack is to improve wallet security.
Over the past few days, I came up with wallet parameters that may seem practical for organizations right now. It should be recognized that both implementation and ideas will be improving in the near future as I conduct more research.
Verifying the Amount in a Wallet
It is common to see bot or spam accounts with our fiat currency have very small amounts. This concept can also be translated into the web3 world where various bot accounts will have small amounts of a token. I like to call this the breadth approach where one may create multiple spam accounts and make transactions of small amounts to slowly deplete the supply of a token from an organization without being caught.
To stop this from happening, wallets must consider an amount parameter. This amount parameter is a certain amount of a token that a wallet must have to be considered ‘legitimate.’ Anything lower will be considered a spam or bot account and the transaction will not occur.
You may ask however, “How does a new account gain that certain amount in the first place?” It should be recognized that not all accounts can gain this certain amount initially otherwise the bot accounts will bypass the parameter. This is where the need for a ‘centralized’ actor comes in. Using protocols like Proof-of-Humanity or an actor that can manually verify identity is one’s best bet in differentiating spam and real wallets. If there is a real wallet, they can be gifted the ‘small amount’ that portrays as a ‘verified’ user.
Sending to Multiple Accounts
Two cases can occur when it comes to depleting the supply of an overall token. The first is that the attacker sends small amounts of the currency to various accounts or sends small amounts to one account. In the second case, it is fairly easy to create a parameter for wallets. It is just that the wallet must flag any wallet address that has been used as a receiver more than 5 times for example within the last 12 hours.
Another way to ensure that the same receiver account is not used is to query recent transactions done by the attacking wallet. For example, if there have been multiple recent transactions (i.e., 3 transactions) sent to the same address in a row, this can be flagged because it symbolizes an act of depleting a supply. This is because if this was a genuine user, they would not want to spend extra on transaction or gas fees (this spotlights an indirect importance of such fees), and as a result, would send all the money in one transaction rather than multiple — it is the complete opposite for supply attacks.
The algorithm here below is very simple and portrays both methods of protecting the second case as mentioned above:
The first case is interesting because there isn’t a solution. The best way currently is to query the number of transactions and find the average amount spent. If the average amount spent over the number of transactions is smaller than some parameter, p, then it can be flagged. The parameter here will act as a certain average that the organization believes the user will spend on (this average should not be communicated otherwise attackers will find out, and thus, create transactions above the average). We use the average because it is a consistent measure of spread relevant over a large range compared to if we summed all the values which will create a value that will be to large to compare with.
The average to compare (p) set by an organization does not have to be too high but must be high enough, which can be audited by a centralized actor. It is like with fiat currency where large transactions are often questioned… Although this may ruin the ‘decentralized’ nature, it is our best bet in protecting such a scam until a more efficient decentralized approach comes into play.
Additionally, centralization does not have to mean an exposure to a user’s identity, unless they are starting to be questioned from the frequency of large transactions. In such a case, it will be a common vote in an organization to add a centralized actor to audit wallets with the frequency of large transactions to keep the supply chain healthy and safe (this is because, for other participants, a healthy supply will ensure their vote remains legitimate in an organization).
It should be noted here that the algorithm I have created does not average the total spent, but rather, only compares the number of transactions.
I have made a small firewall app for web3 wallets as an example to portray the potential of wallet security. You can check it out here!
A Diverging Branch
The methods I talked about above are some of the very basic ways wallets can be further secured to stop currency depletion. Another promising method, which has not been discussed above is changing the wallet hash. After making a transaction, a wallet’s hash and possibly even the private key can change while keeping their identity the same. Assuming that a centralized actor is present to verify identities, altering cryptography algorithms can ensure that no hacker can track hashes and attack specific users of a token, which is a common way to indirectly attack a token’s supply. Altering cryptography algorithms can be created by simply using hash-maps having the wallet address and private key be directed to a new pair where the link is also cryptographically encoded or even through Zero-Knowledge approaches.
It is surprising to me how supply depletion attacks are often not brought up or emphasized despite being so frequent. It is for these reasons that there has not been much development in wallet security to stop such attacks. Though, it is promising to see OpenSea introduce their security protocols injected in Metamask as it shows to us as web3 enthusiasts and users that wallet security is indeed improving. I hope that I sparked a realization about how wallet security and reducing supply depletion needs to be emphasized, and I certainly look forward to seeing other web3 companies like OpenSea make similar security protocols for injected wallets!
Resources
WalletWall (small platform to portray wallet security potential): Link
jaivalpatel.com
