Issue #37: Securing Web3

When I left EY in April, I had a sense of closure. My career in crypto started in 2013 and I had spent the last eight years working to legitimize cryptocurrency in the eyes of regulators, financial institutions, and the average person. I remember talking with a friend in 2014 - we were saying institutional adoption of Bitcoin was “right around the corner”. Well it turned out to be a loooong corner, but the institutions eventually showed up. This year. Banks, custodians, hedge funds, university endowments and pension funds all jumped on the bandwagon. Crypto is now a legitimate asset class and I felt like I had climbed my first mountain.

I had the incredible fortune of getting to work with the best at every level of the industry - from the largest exchanges (Poloniex, Coinbase, Binance), consumer applications (Blockfolio) and DeFi protocols (MakerDAO), to the most forward looking banks and fintechs (Square, Paypal, BNY Mellon). I had a front row seat to the biggest trend in tech and finance for the last eight years.

And that was the problem.

I didn’t want to be in the front row, I wanted to be on the field. I was ready to double down on this technology (again), take more risk and build something.

I discovered DeFi in 2018 and knew immediately it was the next thing. I’m no Nostradamus, the Web3 user experience was just so different...and better. I had found my second mountain. The only question was “how would I climb it?”

Since May, I have been working with OpenZeppelin, the leading blockchain security company, on a new initiative. This week, we officially announced Forta, a decentralized runtime security network for smart contracts. 

Decentralized. Runtime. Security. 

I’m going to unpack each of those terms, and explain why I’m so excited about it. At the end of this issue, you’ll have a better understanding of both smart contract security and what we’re trying to achieve with Forta.

Let’s zoom in…

Security is continuous, and really f’ing hard

Smart contracts are the literal building blocks of crypto, DeFi and NFTs. If these ecosystems were lego sets you could buy at a toy store, smart contracts are the individual pieces. Like other types of software, they can have bugs, be manipulated and get hacked. In 2021 alone, there have been over $1B of DeFi hacks. Some of these were due to negligence. Some fraud. Others were just honest mistakes. In every case though, people lose money. 

It’s a big problem, and securing smart contracts is really hard. 

Smart contract security can be broken down into two phases: pre-deployment and post-deployment. Pre-deployment is everything that happens before a smart contract is deployed on a blockchain. Post-deployment is everything that happens after a smart contract gets deployed on a blockchain. The fact that there are both pre and post deployment measures means security is a continuous effort. It never stops.

Let’s talk pre-deployment.

For my sports fans, pre-deployment security is like practice. You want to establish good fundamentals and practice in-game situations so when you actually get in a game, you aren’t surprised. Pre-deployment security is dominated by two things: reusable code libraries and audits.

Reusable code libraries are your fundamentals - battled tested smart contract templates. These templates are the closest thing we have to “off the shelf”. By using existing templates, you can minimize a lot of the errors and bugs that go along with writing new code from scratch.

Audits, aka penetration testing, are your in-game simulations. When a smart contract auditor sits down with a newly written contract, they do their best to review the code and anticipate all the ways something could go wrong. Just like in a game however, no matter how thorough the audit, you can’t anticipate everything.

Now let’s talk post-deployment. If pre-deployment is practice, then post-deployment is the actual game. 

Once contracts are deployed on a blockchain, code can’t be edited. Naturally, from a security standpoint the focus shifts from the code to operations and transactions. Operations means how live smart contracts are managed by the owner. Transactions means the blockchains transactions that involve the smart contract.

In the tech world, this type of real-time monitoring of systems and activity is called runtime monitoring, or runtime security. It’s happening as the software is running. Runtime monitoring isn’t specific to software either. Pilots have instrumentation in the cockpit monitoring all aspects of the plane’s performance in real time. Same thing for Formula 1 race cars when they are flying around a track at 200 mph. Monitoring your systems in real time is just best practice, regardless of industry.

In Web 3 (DeFi, DAOs), where reusable code libraries and code audits are reasonably mature, runtime monitoring and security is the opposite. There are a couple reasons for this:

First, it’s early. Teams are focused on core product and supporting functions take a backseat.

Second, DeFi teams are smaller than their centralized counterparts. Most teams are a few dozen people at most because they intend to decentralize the project. In lieu of a full-time security team, the monitoring function falls to someone on the engineering team. This person (and it’s usually a single person) oftentimes doesn’t have a software/network security background.

Third, there is a common misconception that if your contracts don’t experience issues in the first few months, they won’t ever have any issues. This is naive and something we are trying to change.

Runtime monitoring is important because when you’re managing complicated software systems, knowledge is power. The more you know, the quicker and more precisely you can react. Most smart contract exploits are multi-transaction events that take place over 15 - 60 minutes. If you can catch it early, you have a chance at preventing damage.

This is why we built Forta.

Forta - “the security cameras and alarm system for the open economy”

The goal of Forta is to detect threats and other system critical issues in real time. We want you to know the second something happens.

The Forta Protocol has two main components – agents and nodes. Agents are the equivalent of virtual security cameras - pieces of code watching for certain on-chain behavior. Nodes are the alarm system - they orchestrate the monitoring, running agents against each block of transactions. If the cameras see something, the system fires an alert.

When an alert fires, the team responsible for that contract can take appropriate action. Maybe the alert is benign and nothing needs to happen. This is often the case. Maybe it’s suspicious and requires further investigation or monitoring. This is common too. However, on rare occasions the alert may detect a high severity threat requiring emergency response. If the team has the ability, they may need to pause the market or shutdown the system completely. Responding quickly could be the difference between catastrophic loss of funds and temporary inconvenience.

There is value in the negative signal as well. Simply knowing the alarm system is on and working offers piece of mind. This alone is a big improvement for teams that aren’t doing comprehensive monitoring of their contracts today.

We talked about security. We talked about runtime. Now let’s talk about decentralization.

For a Web3 runtime security solution to be successful, we believe it needs to be decentralized. Practically, this means anyone can run nodes, and anyone can write agents. The pace of innovation on public blockchains is exhausting. And because of composability, every time a new protocol or contract is deployed, new risk vectors are introduced. No single company with a centralized solution can effectively address these evolving risks. We need to crowdsource this. A decentralized community-based approach that properly incentivizes stakeholders is the most effective and efficient way to cover the landscape of risk.

Parting Thoughts

I’m excited about Forta and excited to work on this problem because I know improving smart contract security will accelerate DeFi adoption. Regulated institutions simply will not integrate with infrastructure that can’t be secured.

This won’t happen overnight, and Forta is only one piece of the puzzle. It requires more seasoned security professionals coming into the industry. It requires the industry to continue developing and enforcing best practices (some of which may come from Web 2). And it requires VCs to continue funding projects focused on solving these problems (which I’m confident they will).

I’m at the bottom of my next mountain looking up, and it’s going to be a fun climb :). We have a great team and an amazing community.

Thanks for reading,

Andy

—

Not a subscriber? Sign up below to receive a new issue every Sunday.