Web3 : Performance, Scale, Cybersecurity and DePIN

Ever since I’ve been in the blockchain space, scale and performance have always been a concern. Over the years there have debates on whether or not performance is actually required, or if users actually care. While at the same time, we’ve also seen that sufficient scale varies from protocol to protocol and at times with varying results on availability. There continues to be a lot of ongoing learnings on how to sufficiently scale networks, while at the same time achieving what I would describe as “business ready” performance. One challenge that I continue to see is persistence of software bloat that plagues achieving the fine balance between scalability and performance. Over the years, we’ve certainly seen significant improvements, the Erigon client for Ethereum based networks being one of them. Whether PoW, PoS, or something else, blockchain protocols are still quite resource hungry, and managing systems to achieve the desired performance and scale is still hard.

As many people know, or may not be aware of, the hyperscalers power a significant portion of many protocols and blockchain solutions. At the same time a handful of “strategic” colo providers have made it their mission to give the hyperscalers a run for their money as they fiercely compete for blockchain customers. In my opinion this is all great for super heavy but non-optimized workloads. These players definitely have a role to play in our ecosystem, however I often wonder if they are doing more harm than good. Hyperscalers most definitely help projects get going quickly, but from my experience, that quickness also comes with some potentially show stopping technical debt if not kept in check.

Suffice to say, in 2024, blockchain technology is still hard to build, manage, and deploy. Cheers to those that continue to pursue operational excellence here!

So let’s assume for the moment that we’re on track to addressing some of these scale and performance challenges at the network level. I for one certainly believe this to be true, else we wouldn’t have a growing ecosystem of L1’s and L2’s that are pushing the boundaries of technology while at the same time delivering an “open and free market” effect. The next phase is the evolution of Decentralized Physical Infrastructure Networks, or DePIN.? Of course, DePIN has been around for a while. Projects like IoTeX., Helium, and Foam.Space have been leading the charge. I fondly recall tinkering with some of the first Helium prototypes years ago, and with IoTeX, we co-founded the Trusted IoT Alliance that led the charge on exploring what it meant to blockchain enable things that talked to the internet and delivered all sorts of interesting operational and telemetry use cases that could be tokenized and delivered to markets for consumption. In my mind DePIN represents an opportunity to address some of the bloat challenges that have held back some networks in their goal of achieving performance and sufficient scale.? Being forced to learn how to write efficient software for resource constrained operational environments is both challenging and an art form.?

So all this got me thinking about our own software stack here at Trugard. Yes, it’s designed for cloud, high performance, and scale. It’s not a L1 or L2, but a security software platform that inspects blocks at scale and delivers security and intelligence insights just moments after a block is committed. We provide smart contract risk, safety, and intelligence data that aids in pre-transaction due diligence for retail users of digital wallets, investment and hedge fund managers, custodians, researchers, and exchanges who seek to invest in, manage, investigate, or list digital assets. We’ve scoured the ecosystem to find vendors with the chops to support our growing infrastructure and data needs, but sadly, many suffer from the scale, performance, and hyperscaler problems that I described above. Simply, our platform is hyper efficient, resulting in us discovering architectural issues behind the curtain of many vendors. Again, building these systems is hard, and providing a highly responsive and data complete service is not for the faint of heart. This too is an art form. We applaud those who take up the challenge and are more than happy to work with anyone who is pushing the boundaries on this.

… but I digress…

So we decided to execute a little thought experiment, and prototype what a DePIN model of our platform might look like. The question being, could we take our highly composable and “cloud scaled” enterprise grade smart contract risk and intelligence platform and deploy it on a set of super resource constrained edge or IoT-like devices. In short, real-time smart contract risk identification operating at the edge in a perimeter-less environment. For those with a cybersecurity mindset, perimeter-less security is the new norm. Gone are the days of classic enterprise Web2 security where CISO’s are charged with protecting the four walls of the business…but that’s a conversation for another article. So this became my Monday morning experiment. Grab a few Raspberry PI 5’s, and load them up with our data driven microservices.

For maximum flexibility and composability, we’ve designed our platform architecture following the classic Extract-Transform-Load (ETL) methodology. Extract, extracts smart contracts and ancillary metadata from blockchain networks, Transform then transmits our unified smart contract data to a number of detection mechanism in our inference layer where ML/AI models are served, and Load then persists all extracted and inferred data for later retrieval for model training or delivery to customers. Of course we would never suggest training models on a Raspberry PI 5, but that may be doable sometime over the next decade, or maybe sooner across networks of thousands of low end devices organized by an appropriate incentive mechanism. Instead, for the purpose of this experiment, these devices are configured to serve pre-trained ML models which they do pretty efficiently as one would expect.

After spending about an hour getting the right build and developer environment setup and pulling our code base down from Github, I spent about 5 min in total building, configuring, and deploying our enterprise grade production software onto the Raspberry PI's. Leveraging our partner, Alchemy, as an end point provider, the device extracts contracts from an Ethereum end point, streams them to the co-resident inference engine, and then deposits insights to a graph database on a different Raspberry PI where further insights can be extracted.

Add a consensus protocol, and a speed, performance, and maintenance based incentive, and we just might have an operating model for a DePIN based smart contract security and intelligence framework that can provide network wide support for hyper fast discovery and maybe even localization of high risk smart contract onboarding. A natural perimeter-less defensive capability for a decentralized operating environment.

Below is an image of the setup taken at our opulent Silicon Valley HQ, where it can be seen that the experiment consumes no more that 3 Watts of power from a portable power supply while processing contracts at about 200 per second. Not bad for four ARM cores and 8 gig of ram ??.