Hey everybody, this is Mitchell Amador, CEO of Immunefi, and welcome back to the Immunefi show. Today we have a very special guest. We have Giannis Smaragdakis, the co-founder of Dedaub and an achiever of so many other interesting things. I've had the pleasure of knowing Giannis for four years now. I think it's well over that. It's well over five years.
First time I can tell you the first time we chatted.
Okay. Well, we'll keep that a secret for now. Give me a little bit of time. But despite Giannis's, you know, wisened figure and mature age, he remembers these things better than I. He's a really interesting guy. He's done a ton of interesting stuff in crypto. I've seen a lot of it firsthand and I want to share it with you guys. And he's done a lot of stuff before I think crypto really took off over the years in computer science and above. And I'm hopeful Giannis that you will share some of your secrets with us today. So without further ado, welcome Giannis. And the first thing I always ask, I want to ask give you a chance to set the floor is who is Giannis? Tell us about yourself.
Well, thank you for having me, Mitchell. First of all, who is Giannis? I've been a researcher and professor for about 25 years now. So I've been doing research in program analysis primarily and at some point some seven now eight years ago I guess I started working on the smart contract space. So started getting into web 3. Obviously the blockchain was very very exciting as a domain. But then I started dabbling a bit in the actual technology of analyzing smart contracts. And in the past five years it's become my number one priority let's say both research wise and company wise because we've had Dedaub, my company for the past five years. The company I co-founded with Neville Grech.
I feel like you undersell a little bit there because I know and I do want to touch we'll probably spend most of the time talking about your adventures with Dedaub, but you also had quite a distinguished career on the program analysis and security side before crypto really blew up. Could you tell us a little bit about that side of things when in your work as a scientist, as a professor, as a researcher?
Yeah. So I mean I have been indeed a professor and researcher for a while and I guess I've been fairly successful in this space in the research space. So I've had many publications. I was a professor at multiple universities. I was in the US for a while. I taught there for about 11 years at Georgia Tech, at the University of Oregon, the University of Massachusetts after having done my PhD there. And I did get I mean I'm fairly well known as a program analysis researcher and I've been at the University of Athens for the past 15 years although like I said before in the past few years I've primarily focused on Dedaub the company. Now it's hard to tell what's academic research recognition like people who are in the biz they know the metrics and the indications but I've done fairly well in that space. I've had a couple of ERC grants. They're the most prestigious European Union research grants that the best research funding that you can get worldwide. That's kind of a feather in one's cap as a researcher. So I've been pretty successful I would say in that space. But the blockchain security space is an entirely different domain even though technically it may borrow many of these techniques. I think that the kind of recognition that you get for doing actually applied stuff does not have much carryover from the pure research community. So in that sense I was trying to reinvent myself and start from scratch and show that we can do something very interesting in the blockchain security space. Although of course we are leveraging all the program analysis research that I've been doing for decades.
Well, you certainly succeeded at that. And for context, one of my first touch points with Giannis here was in the application of these exact same techniques and the technology that he and Neville had built in order to save a mutual customer of ours for millions of dollars in potential losses. And I've seen him do this over and over and over again. And that brings me to the first thing because I think your approach like when we look at early security in crypto most of us really come of it as craftsmen. Most of us have this kind of applied background. A lot of these people are learning security in the course of learning crypto, loving crypto and getting involved because you didn't necessarily have I think a lot of the people working on Ethereum or a lot of these technologies having a very strong web 2 security background or secure engineering background that wasn't really where people came from. There were some but it wasn't for the most part. Now you guys came at it with a very different approach right you came as researchers first and foremost you knew the tools of the trade you had, I think, a great knowledge of what was on the frontier and then you were taking these ideas and applying it to this kind of net new space to see what worked and what didn't. You end up finding a lot and you guys built a lot of interesting tooling which is different I feel from most of the major security firms. I would love to hear as you know what has been your experience building tooling on the security side. Obviously, we're familiar with Dedaub's decompiler, which is probably the best of its kind in the business. Tell me about that journey because that's something that most of us have never done.
Yes. So it's true that our approach has always been automating security analysis. So we want to write automatic algorithms that understand the essence of a smart contract and they go and establish properties for all possible executions. And the number one thing that we did was the decompiler. First of all, it's a necessary step if you get a smart contract and it doesn't have source code like is the case for deployed smart contracts either protocols or much more often attack contracts you want to be able to decompile it to lift it to a human understandable representation. So some of our early research work was decompilation and this has been our main product for I think for over seven years now for around seven and a half years now we've had continuously the Dedaub decompiler running and we called it different names before we called it contract library originally but it was always the Dedaub decompiler has been running for a while and we've been improving it continuously and this gives us a platform because if you decompile contracts into a new intermediate representation you can then write analysis algorithms that process contracts regardless of where they come from. So the decompiler is also a normalizer of code so to speak. So this has been practically our approach since 2018 2019. Decompile and then write analysis algorithms over the output of a decompiler. And then of course the decompiler by itself is a useful artifact and we've had many many users. Right now we have over 10,000 registered users for the Dedaub decompiler. So and many hundreds of people use it every day. So it was a good tool and it was a good approach. The kind of surprising thing about the decompiler is that it also used the same algorithms that we use for program analysis. So we used algorithms that we have established during research for context-sensitive program analysis to emulate all possible executions of a smart contract in a very compact way. So that's one of the technically interesting aspects that our decompiler is really a static analyzer. Now in terms of experience now let's get to broader lessons. The story there is not terribly great. I mean we've had some successes obviously as Dedaub we've had successes in finding vulnerabilities. I think we've gotten 13 or 14 bug bounties overall. And the vast majority of those were bugs that we discovered automatically like nobody was reading the code before the analysis algorithm warned us about a vulnerability there. So we've had some successes like and even those 13 14 bug bounties I think they were worth over $3 million in actual bounties. So it was not negligible by any means and we have used the decompiler as a very successful substrate for analysis technology but at the same time I don't think anyone has really made scalable reliable money out of analysis technology on the blockchain and that has to do also with the size of the market like the number of developers which is a tiny fraction of the overall developers the way smart contracts are getting deployed etc. So I would say a measured success in applying analysis technology to smart contracts. But certainly the potential is still huge. The unexploited potential is still huge in this space.
Sure. Well, I'm very curious about that because you touched on the limited success of analysis, but I get the feeling that you might apply that to the tooling space in crypto in general. Like everything that you just said might equally apply.
That's true. That's the way I would also phrase it. Anything in the tooling space in crypto has not had scalable sales, reliable scalable sales. I mean obviously there have been some successes and that's not a surprise because if we're talking about the developer community that numbers maybe 30,000 people across all blockchain technologies are developers still not much more than that for sure. It's a tiny number like traditional development numbers has numbers in the millions in terms of developers.
Sure. So it's different that the needs for tooling or the potential for tooling to become revenue generating is entirely different.
Well, here's a thought. If you had to go back in time seven years ago, would you have gone about the tooling and decompiler journey in the same way? How would things have been different? And remember, a lot of the people listening to this call have built tooling and may build more tooling in the future, including myself. So tell us like warn us, save us from our future suffering.
Well so I will be really boring here I fear because that's part of coming from a research journey. If you're coming from a research journey if you've been a researcher and then you migrate to something practical the sex appeal of the actual technical domain trumps everything. So would I have gone the same way? I fear I would have gone exactly the same way just because it looked cool and it was the kind of stuff that I've wanted to learn. Is this the most business rational thing to do? Maybe not. Do I know what would have been the optimal way to make a bigger business perhaps? Probably not. But at the same time, the best way perhaps to build a business in an innovative domain is to do what you're passionate about. So to be brief, if you're asking, would you have done things the same way or do you have a better suggestion? I'm afraid I would have done things largely the same way. And probably I don't have a better suggestion off the top of my head. And I fully admit that that's not a winning proposition.
Well, sometimes you just got to follow your heart, Giannis. So, I think that's an honest answer in the right direction. There's lots of foolish things I would do all over again for the same reasons.
Okay. Now, I want to go a little bit more in the applied direction. We're all practitioners here, right? I mean, some of us have the fortunate benefit also to be researchers, but all of us are practitioners. And so, you're dealing with teams all day, every day about their problems and how to stay secure. Now, what do you do? How do you feel when a team says and this could be any number of our peers right in more and more competitive security market when they say or our customers specifically we can guarantee right the security of our code trust me bro it's safe I did a great job.
I mean I really respect that attitude but we all know that in practice it's really a very dangerous attitude like you can always invest everything on a single line of defense and build it as best as possible. Build a Maginot Line that you think can withstand any attack. But realistically diversity in defense I think is extremely valuable. So if someone tells me trust me that my code is secure because I've done all these things to secure my code then great I respect that we certainly want high assurance code but if a single small bug which can be something that you've never even thought of to verify against like a rounding error if a single small bug can bring down your entire financial model and can cause losses of tens of millions or hundreds of millions as in the Balancer case for instance recently then you know maybe you need to also have some other safeguard and not just proving properties of the code or having very very high quality code I mean it's really a great first step but at the same time we have multiple examples now of top quality teams that have followed top practices, absolutely state-of-the-art practices. And I don't say this lightly, they've done everything they could, not just in development, but also in verification, in getting multiple audits. Excellent teams that in the end they either got hacked or they narrowly survived being hacked.
Then what do you think? So let's extend that. So you go to the guys and you say, "Guys, I appreciate your enthusiasm, but you're wrong and everybody else got pwned. Why will you be the exception?" And they say, "Okay, Giannis, you got a good point there. Why will we be special relative to all these other amazing people that you've seen and work with? What is the right approach? Tell me, give me the frame of reference. How should I be looking at security to get as close to guaranteed security as I can possibly get? Guide us."
In the rest of the software development world. Do we rely entirely on correctness of the software? Like you are running a server right now. You're running servers. You're running daemons on your laptop on all your machines. Even if you don't know it, you're running continuous services that listen for connections. Do you rely entirely on the safety of these services and that on being high quality software? No. You put in place as many safeguards as you can. And what could these safeguards be? At the very least, you have a firewall. You have something that either you put in place, your admin put in place. Definitely your service provider, your internet service provider may have put something in place even before anything gets to you. So there's filtering. So people in all kinds of software development domains will try to have multiple fail safes. Not just the code is in the best shape it can possibly be. But also we will question who is contacting me. Are they reliable? Are they someone that I want to allow contacting me? What are the patterns of contact? Someone is talking to my server. Like what are the patterns of contact? Could they constitute an attack? And in the web 3 space, it's a feature as well as a bug that we don't have any of those multiple safeguards. I mean, it's great because we have immediacy and that's what we want. That's the whole story of decentralization and of smart contracts that you can build an entire decentralized permissionless finance system ultra fast. And you can let anyone interact with anything. But I think it's the most valid question ever whether there could be some more filtering that is not based on code quality on the defense side but it's based on some analysis or some filtering on the side of who's contacting you.
That's where the firewall is.
I see. So if you I guess you're saying then like do everything that you can but if you can do one more thing the way you should be looking at it is how do you set up those extra safeguards and in your view that safeguard is the firewall.
Yes that's exactly what I'm saying and I'm not even saying that the firewall should always be on and should always be at the same level of alert. You can have it mostly disabled, mostly like a pass through 99% of the time, but there are obvious cases where having the prediction, having the infrastructure, a connection to a firewall and then enabling it selectively at the very least it makes perfect sense. At the very least, I think every protocol should have such functionality. Even if they choose most of the time to never have any firewalling, no filtering on who can contact who can interact with the smart contracts. In some cases, it makes perfect sense to say, "Hey, now I want to be more restrictive" and I can elaborate, but we can get to that point later. I feel we may get to that point later as well.
I suppose this is a good time to introduce our work together. So we, you know, Immunefi and Dedaub have partnered to create the Immunefi firewall service. All of which under the hood is built by you guys. You guys are powering the whole thing. Tell us a little bit more about what this firewall is and what you have envisioned here. You've set the stage. We understand. I agree with everything you just said, by the way. I think it's like a no-brainer step forward that will have a huge difference in terms of hack impact rates. But what exactly have we created here? What have you created here?
Yeah. So I mean the Immunefi firewall is an on-chain firewall. It's a service that sits on-chain. It consists of smart contracts as well as an off-chain component obviously and the protected protocol. Let's say you have a financial protocol that you want to protect via this firewall. It will ask the firewall every time should I allow this connection to go through? So it's standard firewalling in that sense. Now it's a kind of firewall that we believe should be in place at all times and it offers two distinguishing features and one is kind of pedestrian, kind of straightforward. It's more of an engineering thing. It's a highly configurable firewall. You can tune it to be always on very selective or you can make it be I will let everything go through because right now I'm pretty confident of the security of my code. So it has a very high degree of configurability. That's the first feature. And just to give a couple of examples by what I mean high degree of configurability you can say I will do firewalling based on who calls me. I can do firewalling based on invariants that are specific to the protocol. I can do firewalling based on what's the transaction simulating the transaction. That's a pretty intrusive approach, but I can actually fully simulate the transaction that comes in and sign it off-chain, give you a signature and only then accept it on-chain. I can have a firewall that just says, "Oh, I'm very restrictive right now. We are in restrictive mode. I will only allow these thousand investors to interact with me" or I can have a firewall that's very permissive to say I will allow everyone to interact with me except for these blacklisted addresses that have directly been funded by North Korea various previous hacks whatever so all of these policies are part of the configuration of the firewall so you can make something that's very configurable and I think this goes to what we were saying before. Let's say you have a protocol. When you develop it, you build a lot of invariants in the code and most of the time those invariants if you've deployed, they've never been violated, right? You know these properties, they've always been true. Like you know the current yield rate if you multiply by all the stored funds is never more than whatever some quantity that's the sum of your obligations. That's a financial property that gives you something useful about your property. And let's say someone you've deployed and a few months later someone comes in and says, "Hey, I ran some weird tests. I run a fuzzing campaign and after many tens of hours, I found a violation. Could this be the basis of a hack?" It has not been weaponized yet, but you know that one of your assumptions has been violated. It would be irresponsible at that point if you don't put your protocol in high protection mode because you know that something is wrong in the code and you can very well for a few weeks at least even if you are in fully permissive mode before that turn the firewall to protective mode and say hey while I'm investigating this violation I don't want to allow anyone to call me I will only allow callers that have been vetted in some way. So that's what I mean by going through different modes at different parts of the lifetime of the protocol. Now the second and more unique technically innovative part of the Immunefi firewall is that we have this mode called caller vetting where we restrict who can call the protected protocol and that sounds straightforward and obviously on the on-chain part on the smart contract side you just say hey this is the guy who called me should I accept the call so it's very brain dead on the smart contract side so the smarts come in on the off-chain side. How do we know who to let through if you are in this mode? And this is a very restrictive mode to be clear. You may not want to be running this at all times. So how do I know whether to let a guy through. And what we do there the innovative part is that we have a separate step where everyone who calls the protected protocol and runs code like every smart contract that calls your protected smart contracts their code needs to have been pre-vetted. Get submitted through a separate application and we have automated algorithms and in rare cases human inspection that will vet that this is actually legitimate integration code a bot or an integrator DeFi protocol and not a hack attempt. So we are putting extra scrutiny in cases where we need high assurance we will put extra scrutiny on the caller code. That's the big part. That's the big new thing of the Immunefi firewall.
I see. For most of this stuff, and I've been following the firewall space since the beginning, like literally since before we effectively had DeFi and need for firewalling in any serious sense, I was following attempts to create these types of controlled restrictions to mitigate unwanted activity. And right from the beginning with the first firewall products, you know, I was there poking around, playing with them, trying to understand if these things were going to be the next big thing. Remember the first iteration, we didn't call them firewalls. We called them circuit breakers, right? We're only now over really the past two years getting around to calling them firewalls, which is probably what they should have been called the whole time, but you know, it is what it is. And help me understand this, but as far as I can tell, I never saw this feature set in any of the other major firewall products. In fact, most of them had exactly that highly restrictive, you know, off-chain signature approach that you described where they have to review and check and approve of every single transaction. Whereas what you're describing is kind of a sea change in how we approach an adaptive, responsive, flexible defense.
