After BNB Chain Hack, Operators Must Face Question of Decentralization

Following attackers exploiting Binance’s BNB Chain and withdrawing 2 million BNB, the crypto industry is now grappling with questions of decentralization, responses to security incidents and the prevalence of hacks.

Operators and protocols in the space must choose to become fully decentralized or be better prepared to respond to hacks, said Michael Lewellen, head of solutions architecture at blockchain security firm OpenZeppelin.

BNB Chain said in a statement Friday that the latest exploit affected BSC Token Hub — the native cross-chain bridge between BNB Beacon Chain and BNB Smart Chain.

Blockchain analytics unit Chainalysis estimated in August that $2 billion worth of crypto had been stolen across 13 cross-chain bridge hacks. Attacks on bridges accounted for 69% of total funds stolen this year, the company said at the time.

“Decentralized chains are not designed to be stopped, but by contacting community validators one by one, we were able to stop the incident from spreading,” BNB Chain said in a statement Friday.

BNB Smart Chain has 26 active validators and 44 in total, the network stated, adding that it seeks to expand the validators to boost further decentralization.

Though BNB Chain reported “the vast majority of the funds remain under control,” a spokesperson did not immediately return a request for further comment. 

The latest hack is likely to spur operators to address the lack of automated response to security incidents in the crypto space, Lewellen told Blockworks. 

Founded in 2015, OpenZeppelin has a platform allowing users to manage smart contract administration, such as access controls, upgrades and pausing. The company safeguards tens of billions of dollars in funds for organizations such as Coinbase and the Ethereum Foundation.

Keep reading for excerpts from Blockworks’ interview with Lewellen following the hack.

Blockworks: What do you make of this latest hack on the BNB Chain?

Lewellen: This is actually kind of a weird one, as this is a bug that was in a pre-compiled smart contract.

With Binance Chain, they were just adding a lot of features into the native protocol to support smart contracts, and that’s where the bug ended up coming in. So I think there needs to be a question of whether these sorts of changes should be in a native protocol. Maybe it should be contained within a smart contract and kept outside of the scope of the protocol because these things are risky.

We don’t know how the bug appeared inside of the protocol or its original source. But where code is — and the level of safety pieces of code have depending on what layer they’re in — need to be better.

These proof-of-authority chains and bridges kind of complicate that. It’s no longer a clear hierarchy. There’s now a lot of different layers happening in parallel that people need to be a lot more conscious of.   

Blockworks: How could the response to this hack have been better?

Lewellen: While I think they responded well overall here, there’s a larger question of…was this really the best that could be done if that role was embraced.

I can’t speak to what the Binance Chain validator community does or how they coordinate or practice for these sorts of things…but they’ve obviously practiced it once now.

I’m speaking as someone from the outside, but seeing other DeFi projects respond to this as their client, I think there could be a lot more diligence and embracing the role of someone that has the ability to respond to security incidents. 

And if they don’t have the role, they just need to be very up-front with that. Whether there’s a hesitancy to utilize it in some cases and maybe not in others, right now obviously it exists and I think it could be done better in the future if we learn a lot from this.   

Blockworks: Can you point to any examples of an effective automated instant response to a hack?

Lewellen: We’re still in the early stages. I think we’re seeing teams that are getting better at detecting things and responding, but I think honestly these hacks have been occurring on bridges that I don’t think have been embracing that same level of due diligence.

I don’t think we’ve seen a good case for that. We know it’s possible, we’ve done the simulations at OpenZeppelin to know it’s feasible, and we’ve built tools to address it. But ironically I think the teams best prepared for that might be the teams that are least susceptible to being hacked in the first place.

The people that are being hacked the most are also the ones that I think are the least prepared to be hacked.

Blockworks: What sorts of tools or practices should be used to quickly defend against hacks?  

Lewellen: What [operators] really need is something that gives you immediate notification, or basically something that is watching everything on-chain…analyzing it and then determining, “were any risks exposed here?”

If large amounts of funds get moved, it’s probably fine and part of the day-to-day operations, but if it falls out of the norm…[it’s important to have] immediate notification of that.

If you can go further and detect things that should never occur, such as money moving out of a vault that should be locked or more tokens than what should be in the token supply existing…you know something’s happening. If not getting people immediately on call to respond, maybe even automating some of the ways that you might immediately cut down some of the exit ramps…or getting your validators to be ready to respond and maybe even doing drills with them.

Blockworks: What is the key for operators as they seek to address security risks going forward? 

Lewellen: I think it’s going to be becoming a little bit more honest with the role of different operators and protocols and what the administrative powers are. 

With the Ethereum blockchain, the way that Binance Chain responded would not have been possible for Ethereum, but Ethereum also creates this expectation that the chain isn’t going to step in and save you.

If you’re going to have that sort of approach where you have a network where people can respond, either embrace it or move away from it. Either be fully decentralized, or be centralized enough to have responsibility for responding to security incidents. Embrace the role fully by trying to be as prepared as possible and telling node operators for your network that this will be their responsibility.

This interview has been edited for clarity and brevity.

Attend DAS:LONDON and hear how the largest TradFi and crypto institutions see the future of crypto’s institutional adoption. Register here.