Is Upgrading Blockchain Security Useful For Avoiding And Preventing Cyber Hacks?
Some of the largest hacks in Web3 history occurred in 2022, challenging long-accepted presumptions about blockchain infrastructure and emphasizing the importance of rigorous engineering practices. A closer examination of the majority of these hacks reveals serious architectural flaws, which can, fortunately, be addressed by increasing network diversification and decentralization.
Web3’s future appears to be multi-chain, but many cross-chain applications, such as bridges, have shown significant security vulnerabilities. Proof-of-Stake (PoS) networks, DeFi transactions, and blockchain bridges are typically governed by a network of validator nodes requiring specific signatures and validators to approve and process transactions.
For example, many DeFi projects and bridges use an N-of-M validator setup, meaning that at least N of the network’s M validator nodes must sign a specific transaction for an ‘event’ (transfer, withdrawal, and deposit) to occur. The problem is that the majority of today’s PoS or delegated PoS projects have a small number of M and an even smaller number of N controlled by a few major parties — such as investors, foundations, or third-party staking providers — which defeats a large portion of the decentralization purpose. When a single entity manages many nodes, the network becomes highly centralized, and its security is jeopardized, resulting in a honeypot structure.
Over $1.5 billion has been hacked in nine of the most significant DeFi cross-chain bridge attacks since May of this year. In the case of the Ronin chain, which was the victim of one of the most notorious blockchain hacks to date, with over $600 million lost, a total of nine validators controlled the bridge. It used a 5-of-9 validator setup, which meant that any deposit or withdrawal event only required five signatures. Furthermore, four of the nine nodes were managed by a single entity — in this case, Sky Mavis.
Worse still, Axie Dao’s fifth node-enabled Node Allowlist Permissioning (e.g., admin addPeer) by the Sky Mavis nodes. The fifth node essentially handed over its signature’ to the four nodes. Furthermore, the IP address from the admin addPeer allowlist was never removed. Running four of nine is problematic, but handing over effective rights to a single entity is even more so.
As a result, once the attackers exploited a backdoor in the four nodes via a gas-free RPC node, they gained access to the fifth (now controlling the smart contract with 5-of-9). As a result, not only was this not a decentralized setup, but it was also not trust-minimized.
Also Read,
Latest Worst Case Scenario For Bitcoin Predicts Its Bottom In The Bear Market To Be Close To $6000
Because of Sky Mavis’ centralized network control, the Ronin bridge was an easy target for private-key leakage and subsequent attack.
So, why do projects choose to have low validator and signature requirements? It exemplifies an unfortunate trend: projects prioritize faster platform launch, lower fees, and faster transaction speeds over network security. As in other recent attacks, this has resulted in poor, smart contract design and cryptographic standards. While user experience is important in project success, the security of users and the assets they entrust to those platforms are critical.
If the hacks have shown us anything this year, blockchain projects and their applications must maintain core security principles and cryptographic standards at the forefront of their development roadmap. A fully decentralized network can take years to achieve and can become costly. Projects should institute minimized-trust setups with robust security standards in the short term.
Projects must improve their engineering practices to maintain security in the long term. A large part of this is ensuring the nodes running on the system are distributed across a diverse base of users and entities, thus increasing network decentralization and, in turn, network security.
A second measure that can be taken is to invest in several different client implementations for diverse setups. Hackers gain access to the client’s private keys through these accounts, allowing them to sign transactions on their behalf. If only three signatures are required, the hacker would only need to compromise three nodes for their fraudulent transactions to be approved. If client implementation setups differ, the same code manipulation will not work for all of them, making the project much more challenging to hack.
Thorough smart-contract auditing and application stress-testing should be considered in projects, such as implementing systems that monitor and alert the network during a hack on time. It took Ronin nearly a week to notice the hack, which meant they could not immediately respond and correct the situation.
While these additional practices may be more time-consuming and labour-intensive, they ultimately lay the groundwork for a massively decentralized, trustless organization in the long run. Network security should always be prioritized in blockchain projects.
Too many hacks have resulted in hundreds of millions of dollars lost due to design flaws and a need for robust security standards. Projects can and should invest more time and resources in security practices; otherwise, it may come back to bite them later.
Also Read,
