Understanding blockchain network security
2022 has witnessed some of the largest hacks in the history of Web3, challenging previously held assumptions about blockchain infrastructure and highlighting the importance of robust engineering practices. A closer look at the majority of these hacks reveals serious architectural vulnerabilities, which fortunately can be addressed by ensuring greater diversification and decentralization within networks.
Blockchain’s ethos: Economic freedom through decentralization, yet centralization is prevalent
The future of Web3 promises to be multi-chain, however many cross-chain applications like bridges have demonstrated significant security vulnerabilities to date. Proof-of-Stake (PoS) networks, DeFi transactions and blockchain bridges are generally governed by a series of validator nodes that require a certain number of signatures and a certain number of validators to approve and process transactions.
For example, many DeFi projects and bridges follow an N-of-M validator setup, meaning at least N of all M validator nodes operating the network must sign a particular transaction for an ‘event’ (transfer, withdrawal and/or deposit) to occur. The problem is that for the majority of today’s PoS or delegated PoS projects, there is a small number of M and an even smaller N controlled by just a few central parties — such as investors, foundations or third-party staking providers — which defeats a large portion of the decentralization purpose. When a single entity is running a large number of nodes, the network becomes highly centralized and its security is compromised — resulting in a honeypotstructure.
As of May of this year alone, over $1.5 billion has been hacked in nine of the largest DeFi cross-chain bridge attacks. In the case of the Ronin chain, which became 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 and utilized a 5-of-9 validator setup, meaning only five signatures were required to sign any deposit or withdrawal event. Not only that but four of those nine nodes were run by a single entity — in this case, Sky Mavis.
What’s worse, a fifth node run by Axie Dao enabled Node Allowlist Permissioning (e.g., admin_addPeer) by the Sky Mavis nodes. Essentially, the fifth node handed over its ‘signature’ to the four nodes. And the IP from the admin_addPeer allowlist was never removed. Obviously, running four of nine is already problematic, but handing over effective rights to a single entity is even more concerning.
So, once the attackers were able to exploit a backdoor in the four nodes through a gas-free RPC node, they acquired access to the fifth (now controlling the smart contract with 5-of-9). Therefore, not only was this not a decentralized setup, but it also was not even trust-minimized. Sky Mavis’ centralized control of the network meant that the Ronin bridge was an easy target for private-key leakage and subsequent attack.
Why then do projects opt for low validator and signature requirements? It is revelatory of an unfortunate trend: projects are prioritizing a quicker platform launch, lower fees and faster transaction speeds at the expense of network security. This has also resulted in poor smart contract design and cryptographic standards, as in the case of other recent attacks. While user experience plays an important role in the success of a project, the security of users and the assets they entrust to those platforms are absolutely vital.
If the hacks have shown us anything this year, it’s that blockchain projects and their applications need to 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, in the short term, institute minimized-trust setups with robust security standards.
In the long-term, projects need to improve their engineering practices to maintain security. 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 a number of different client implementations for diverse setups. Hackers exploit these accounts and gain access to the client’s private keys, allowing them to sign transactions on their behalf. If only three signatures are required, the hacker would only need to hack three nodes to approve their fraudulent transactions. However, if client implementation setups are all different, the same code manipulation would not work for them all, making the project much more difficult to hack.
Projects should consider thorough smart-contract auditing and application stress-testing, such as implementing systems that monitor and alert the network during a hack in a timely fashion. It took Ronin almost a week to notice that the hack had occurred, meaning they were unable to react and remedy the situation immediately.
While these additional practices may be more tedious and slower upfront, in the end, they set up projects for a massively decentralized, trustless organization in the long-term. Network security should always be kept top of mind for blockchain projects.
There have been too many hacks involving losses in the hundreds of millions of dollars due to design failures and a lack of robust security standards. Projects can and should invest more time and resources in security practices, or it may very well come back to bite them eventually.
Anthony Georgiades is the co-founder of Pastel Network.
This article was published through Cointelegraph Innovation Circle, a vetted organization of senior executives and experts in the blockchain technology industry who are building the future through the power of connections, collaboration and thought leadership. Opinions expressed do not necessarily reflect those of Cointelegraph.