This is epicenter episode 346 with guest Dan Guido. Hi, welcome to epicenter. My name is Sebastian quechua. Today, our guest is Dan Guido, he's a CEO of trail of bits there, a software security firm that has been around since 2012, and they work quite a bit in the blockchain space, but not only. They also do work in the sort of broader software security space. They work for government institutions as well in the US.
They're very good at. I mean, one of the things that I Love About Your Love B is that they're great communicator. So they have an amazing blog that just captures a lot of the work that they do. And so if you want to learn about software security, I think like their blog is a great place to start. They also have a Publications repository on their GitHub where they publish all their security Audits and also all the research that they're doing.
So they're really sort of a great thought leader in the space of blockchain security. Research. And I've been want to get down on the podcast since about a year. Now, I mean, they were previously a sponsor of the show and we're supposed to do this interview at ECC and Paris. Obviously, I didn't happen because Den didn't come over, so it was glad to finally get them on the podcast and it was really great conversation Federica.
And I did this one together and Dan is just so articulate and explains things with lots of clarity. Also, you know, in a way that for us software, security Lehman's, Are able to understand. So after the interview for a taken and I went on for an extra 10 minutes talking about, you know, our thoughts and what we learned from the interview. Also, describing her experience
with security audits. Obviously, you working at gnosis, she's had to deal with that quite a bit and we also discuss the potential for more Gatekeepers and the DAP ecosystem in order to create a safer space, for people, to invest their money and used apps that have been vetted by Gatekeepers. So, You want to hear that conversation? Please subscribe to epicenter premium. You can do.
So it, premium epicenter, dot TV, that gives you access to host, debriefs, where we go on for an extra 10 to 20 minutes. Share our own thoughts about the interview, also Roundtable discussions and bonus content that will put out from time to time. So with that, here is our interview with Dan Guido We're here with Dan Guido then. Thanks for joining us today. Thanks for having me actually. We've been wanting to get you on the podcast for some time.
Actually, we were supposed to talk at ECC and you didn't make it. I think that was probably a wise decision of, you'd not to fly over. Yeah. Turns out the professional risk manager knows how to avoid certain downsides, thanks for joining us. I mean, you know, we've been talking for quite some time also because our listeners, remember that trilobites was a sponsor of the podcast about a year ago and So it was great to get to talk to you then also and kind of get
into this topic of security. And so this is an episode that I've been wanting to do for a long time because we obviously talked about security, a lot on the podcast but never really done any episodes that focus on security and there's a lot of things here I think that will learn. And also maybe be surprised about like, you know, some misconceptions and things like that that I'd like to get into. So yeah, tell us a bit about your background and how you came
about founding trailer pets. So I've been doing security stuff for the better part of my adult life started. Probably when I was about 13 14 breaking into my school computers like one does as one does luckily escaped being severely punished for that but I ended up going to college for a concentration program in cyber security.
It was called Polytechnic University when I went there but now it's the NYU tanton School of Engineering and they have one of these NS a center of excellence programs that teach kids a formalized education in cybersecurity. I think that Well that are a little bit younger than me, have a lot more formalized education and people that are a little bit older than me, don't they learned from their peers?
They learned in kind of like a master Apprentice kind of set up so I'm right on the cusp of that. So I have a formal background in computer science and computer security, and this is the only field that I've ever been interested in working in. So I've worked at the FED Reserve doing incident response helping prevent people hacking into the currency. Reserve, the United States. I've been a consultant Sultan tat isec Partners now, NCC group. So I was, I sick Partners before
there were required. Help start their office in the, on the East Coast worked with dozens of technology companies across the globe. But I was pretty frustrated that it seemed like an unending treadmill that you kind of go back to clients year after year. And there's always the same bugs and they don't really internalize the information that you give them. I thought that there was some improvement that we could make and I wanted to make fundamental
improvements to the whole field. So I found a trail It's with two friends of mine back in 2012 to fundamentally Advance the science of computer science and computer security. I think we've by and large succeeded at doing that and very small ways. You know, the company started as a DARPA contractor, we worked on for year-long research, programs and automated program analysis and advanced cryptography.
And then from there, we branched out to help provide those advances to commercial firms and now to blockchain firms. So that's the, I guess the medium-length overview of where I came. Came from and what we're doing now. Tell us about how you got interested in blockchain as a cryptographic field. Because I mean basically you found a trade-off B in 2012 and obviously then it was still pretty new. So what exactly spoke to you about it?
Yeah, a couple of things, I think it was really driven by employee interest. There about two or three people in the company that were just really enamored with blockchain has technology because it was a green field not necessarily because it was anything that you could do with blockchain, but because the field was in it, Infancy was a chance to start over it was there were no security tools.
There was no security knowledge, people were building their own, programming languages, building their own compilers, the execution environment, looked a little bit different. So there was this huge gap of knowledge that we could rush in to fill and create things that were correct from the first step. So, back about three to four years ago, we had a couple people dabbling in that area of technology and what we contributed was a symbolic
verifier. That was our very first thing, we didn't raise our hands and say, hey Will audit your code for you. We're Engineers. So we set up a little unit of people that wrote symbolic capable etherium virtual machine into a tool that we have called Manticore. And then once we were able to do that, we realize that hey this is actually kind of valuable and people would love to work with us to improve their own
security. So because we'd already mastered the field through that activity that research activity. That's how we started offering services for blockchain. How much of your client base today is blockchain base because you told us just before we started the coil, that we should update our versions of Zoom because you just release the fixed. So, how much is basically in the web tool where and how much is in the web three word of your company clients? Trail bitches.
A company is split into a bunch of different pieces. We have a research team that continues to work with DARPA, the National Science Foundation Department of Defense, like various other agencies of the US government to fund long-term research. That's probably about 10 to 15 people, depending on how you count. We have an engineering team. So, because we have these expert software developers that can apply research and make real
software with that research. We also have an extraordinarily capable team of people that you can hire to build software for you doesn't need to include research. It just needs to be something that you need. Usually, it's security software, sometimes it's high Assurance software, things like cryptographic libraries. So our engineering team is about another, you know, 10 or 15 people and then we have an assurance team. And our Assurance team is who the blockchain industry.
Typically collaborates with their people that are specialized at taking owner door, taking a look at other peoples code and helping identify hotspots weaknesses and specific security risks inside them, and that Team Works across the defense Tech and finance space. So we've reviewed things like autonomous drones satellites cryptographic protocols for satellites. We've looked at embedded firmwares. Self encrypting hard drives and most famously right now.
We're working. Zoom, when people have a need to really rapidly, get to the root of difficult problems, especially ones that involve compiled code, and cryptography, trailer, b is among the top choices for that assistance. So blockchain right now I'd say takes up about like a third of the company's business, maybe a little bit less, maybe 20%.
But you know, we have a really healthy Diversified business when we work across a lot of areas of technology and I try to shuffle kind of things that we've learned and the tools. We've built and the talent that we've acquired across all those different Industries which is what makes us kind of a unique company in the blockchain security space. So it's interesting that you work with zoom because they just bought key base and brought on that entire team of
cryptographer. So you're saying that they bought key base, they got all these cryptographers but they also need to get extra cryptography. Experts in addition to that team, Oh, yeah, I mean, look, they're code base has been evolving over the better part of 10 years. It's got hundreds of thousands, millions of lines of code. That's cross-platform with Linux Mac Windows. They even have a Blackberry client, like, there's server infrastructure out there.
It's a custom Network protocol, custom cryptographic protocol. There is just a voluminous amount of stuff there and when you have that level of scrutiny on you as a firm like zoom in, you know, No, today's environment. You need to really apply a lot of effort to uncover flaws before other people, find them and to keep your clients safe as
best as possible. So we've done a really detailed review of all the client software, other firms were brought in to. Look at all the server software, but a really key part of our responsibility was to. Look at the existing implementation of end-to-end cryptography. We've helped them kind of analyze, the current state figure out where it's hooked into the client, how it exactly Works. What the kind of cryptographic properties of it art.
A. And then the key base folks are working a lot more on what it should be tomorrow. So, a lot of the initial value that the key base folks, provided is a white paper, that's now, published up on
GitHub that. I think a lot of people have read and that's great and that proves kind of like where things should go. But it's going to take weeks months, you know, possibly even longer to get there and in the meantime you need to make sure that the software you've got today is safe, which is what I'm working on. Is that in your career? You've been working on on security-related stuff since you were in your early. Teens, how has software security changed the most in your view?
What's been the most like, fundamental shift between say how software security was looked upon and conducted, like, maybe like the early 2000s to now, I'm kind of jaded. I don't think it's changed really at all. There's been a lot of movement between programming languages like everyone jumped on the node.js bandwagon at some point and then everybody jumps on the rust bandwagon and everybody jumps on the Swift bandwagon and its history repeating itself to
a great extent. Like we saw this with the iPhone and Android, right in the first versions that came out, they didn't really apply any of the best practices or Lessons Learned of the previous generation of software. That weren't sandbox. They weren't hardened with compiler protections. And they didn't have a great user experience like there. Just wasn't a lot there and some of those early mobile phones for some of the easiest software to
hack on the planet. But now, you know, they took all their punches and they had to learn from failing, which is kind of unfortunate. And now, an iPhone is kind of the most secure consumer device that you can buy. There's not a single device that I could go to Best Buy and say, is more secure than a, than an iPhone. And I think that's kind of the process that a lot of fields of Technology go through for better for worse.
So really, Means as a security professional is that you've got to learn this kind of fundamental underpinning. There's a lot of like foundational security knowledge that you need, but the technology that you work with from day to day over the course of your career, is going to shift pretty rapidly as things. Get to be less mature, more mature, All right, so it's more about technology changes.
So much as it is about changes to, like, how you secure software or Hardware, the risks are the same or fundamentally the same, but the tools that people are building to use the infrastructure are changing On any given day, our Assurance team is working with people that write code and, you know, Java PHP, Ruby rust rails, Django various see Frameworks, or C++ Frameworks and blockchain software and like everything
under the sun. And everybody just kind of expects you to know that stuff and really like learning how to code in C or learning how to code. And rust is not the hard part. People challenged us to do that all the time which is why the whole block chain thing. Also comes kind of naturally to us like if you're a good security, but then you're going to be able to figure out exactly what's going wrong in a smart contract.
To the most important part is the security expertise, which is something that you have to learn and grow over, you know, a decade or a lifetime, or a full career If you look at blockchain technology and smart contract, technology are their unique design and security challenges in these protocols.
The unique security challenge is really that the tools that people are using to build blockchain software are awful, what changes between different languages and Frameworks is that sometimes certain tools have a lot more foot guns in them than
others. So it's a lot easier to write security vulnerabilities and PHP than it is to write security vulnerabilities and rust because there's a lot of safety to fall back on in terms of the language and the compilers and the development Frameworks. But with solidity, especially not just a little, but many other blockchain. Languages, they've managed to reinvent the entire history of software security flaws and make it the developer's responsibility to be aware of all of them.
So, really the key difference here is that developers are not getting any help at all from the tools, in the language that they're using to develop blockchain software, which makes the after-the-fact Assurance that's provided by companies like mine critical. Now, on the other hand, what blockchain has that's going for it. That other languages don't is that smart contracts tend to be a lot more testable code than Traditional code.
It's really easy for me to throw it into an emulator and for me to send inputs to Any Given function and to evaluate what the impact is on a really simplistic State machine but on regular software like if I want to set up a fuzz test client for Google Chrome or something like that, there's a lot of global mutable State. There's a lot of libraries that change their behavior depending on what operating system you're running on or what specific configuration of your operating
system you have. Have. That's why I like, you know, when your parents call you and you're, you know, some software on their computer crashed. You have no idea how to debug it because you have to be aware of every single setting on their entire computer. All the other software that's installed alongside all the shared libraries that are there. But on the blockchain, everything runs on the same Block Chain.
So if I have a copy of the blockchain and you have a copy of the blockchain, then it means that we're testing, we're running the same code, so that's actually made things a lot easier for blockchain software. Despite the fact that there's incredible insecure In the tools that you're using to build it. Can you give us an idea of what a mature to link it should look
like? So basically if you look at like languages that have been around for a while like rust for instance, what ideally would we have in terms of tools in order to be able to have the same trust in the tooling as you do in traditional systems? Yeah. So it's not a question of third-party tools. It's more question of the language in the compiler itself, right? Like everybody's familiar with the fact that solidity can't seem to make it more than one
release without a critical flaw. Everybody's also familiar with the fact that tools like Slither, you know, one of my own static analyzers from trailer, b have to watch out for 90 specific flaws or that the use of integers is inherently unsafe inside solidity. And you need a third party Library like safe math in order to catch you when you fall. So the kinds of things that make a language safe.
Our the avoidance of those issues that, you know, I shouldn't have to worry about the order of operations because the order of operation should be the same as every other language that I use. They shouldn't be different like they are in solidity. That's a big part of the language design. Their just should not be so many foot guns, there should be right now. I think that there's kind of a pressure to make solidity more feature full to add additional, kind of things to it, that help
you develop code. And as a security engineer, I'd pull back, I would want to make something that looks like solidity - - not. So, Aditi plus plus I want something that's a little bit more simplistic that fits 99% of people's use cases, but that 100% of those potential uses are safe and that it's much, much harder to screw up. That's why you see, you know, rust things like memory safety. Type safety. It takes the universe of things that could go wrong and limits it.
We're now, I just have to worry about logical flaws. That's much better other things that but, you know, tools like rust have that are really nice is that it specifically declares when you're doing something that's unsafe. These. He's like I as a security engineer, the most precious resource I have is time when I'm looking at a piece of code, it might be larger than the amount of time that I have to fully review.
All of it end to end if I could specifically identify like, hey, this part of the code base is insecure because the developer told me so because the compiler force them to then, I know where to spend my review, effort to get the most bang for my buck. So rust again, is really good. There. It helps identify ahead of time. What you're doing is unsafe All those are features and capabilities that solidity and
particular lakhs. But that also aren't present in most other smart contract language has to kind of summarize here for the lemons in the audience. What you're saying is that social stability has sort of inherent issues that make it unsafe because as a developer you're able to do things instability that in other languages would just be impossible to get wrong or the compiler or your tooling what alert you that what you're doing. Is unsafe. Yeah, absolutely. We actually have a whole talk
about this. We can have a conference presentation, called anatomy of an unsafe smart contract. Programming language. It's up on the trail of its YouTube, it's really entertaining. It's got tons of great graphics and a little bit of some movies and a jingle in the middle of it. So if you're interested in looking at it further that dives into the specifics of why we think solidity is a poor choice that we're kind of stuck with now for developing smart
contracts. But again, luckily, what we've proven is that over time Is possible to build secure solidity, smart contracts because they're more testable because it's easier to do. After the fact, verification of them means that you can still produce secure code and possibly even more secure code than if the compiler tools helped you. But it's not a question of either or like, obviously, why
not both right. You shouldn't have one set of tools undercut, you and then you're testing tools, lift you back up. And that's kind of the struggle that I always have in the, in the blockchain community is, I would love to work on the compiler tools. I would love to To improve them. And the things that we've done with slither specifically to formally kind of model things like the you'll parser and the AST for solidity are things.
That should be adopted Upstream. We have all of these testing tools and everything that allow us to in the end essentially, right secure smart contracts, right? Because we're able to catch all these bugs and were able to fix all these little inherent issues with solidity. Does this introduce other Is or other security vulnerabilities that perhaps another language like rust or more mature has language like C++ wouldn't encounter like what are some of
the negative effects? Perhaps of, like having a language that is inherently insecure by its construction even if we can go in and fix all the bugs after the fact, I mean it just puts a lot more cost into the process of delivering good software. So you know, a lot of blockchain firms don't go through a 50 million dollar Ico, a lot of blockchain firms. Have difficulty hiring a security engineer to work full-time on their team and then my resources are always stretched.
Then, people are complaining all the time about how I try to hire Trail bits. And they told me that they couldn't start until a month from now, or two months from now, or whatever it is. And I need them tomorrow. And that's because there's only like, you know, two dozen people on my entire team that are trying to hold up the entire What it means to have good compiler tools, is it means that
security is easier. It means that more people can produce more secure code without expert help so that entire gap of the poor tools and poor language that the etherium community currently end. Others are suffering under slows down the whole field. It has a systemic effect on the ability of teams to ship software. It's really important to solve and I'm surprised that more people haven't been angry about that. And they are about angry about my project lead time or
something. It's more systemic risk, its ecosystem risk rather than individual project risk you'd say yeah. I mean this specific design of solidity is what handed teams like mine, kind of the the power and position that we have in the community. I'm self-interested of course, like it's great that people turn to me for help and everything but I would love it.
If people didn't like ultimately I like to try and put myself out of a job that's why I produce tools like Slither and why I released them open source and let people use them without talking to me is, I would like to have to try harder. And from day to day, and I want people to give me new challenges to solve, but the position that we're in is that there's just this influx of people that continue to try and write new
smart contracts every day. And they fall into the exact same traps as the last person and that's kind of a poor State of Affairs. Can you just briefly explain what it's leather and what it does and how it helps. People save time. I guess trilobites has a suite of etherium. Security tools, Slither is kind of the first layer of them, that's what we use. Where it's the lowest effort highest value at the other end. You can just press the big red button and it tells you bugs
that are in your code. The way that it works is when you compile solidity code with the solidity compiler, it produces an AST and Abstract syntax tree, and intermediate representation of some sort prior to creating by code that goes in the blockchain. So we take that AST, parse it and we parse it into something called Static single assignment
form SSA form. And then using SSA form, we use a whole bunch of stuff from compiler Theory to kind of process it and analyze it as well as Traverse it for the security issues that we know how to find. So every single project that we do where we review a client's code, we have a process afterward where we collect what we learned. If we found a new bugged like a class of bug or some That's prevalent within the clients.
Codebase, we try to encode that programmatically into what's called a detector inside Slither and then in the future Slither should be capable of finding bugs of that type. The goal for trail of B is I never want to find the same book
twice. I only ever want to find a bug once and slithers the primary tool that lets us do that in very layman's terms like a spell checker your for your code, sort of thing, kind of, but way more advanced than that, because this thing can parse like it can understand English grammar. Yeah, it's primarily for your good. Yeah. Maybe do you think solidity is beyond fixing? Should we just scrap it and try a new language, or do you think we can turn this around?
And what are you thoughts about Viper? So I think vipers a great Improvement. I do think it's possible to fix solidity. It needs somebody to come in with a really strong vision of. Here's where we need to be. And here's why and right now, the kind of iterative, you know baby steps kind of approach that I see of each incremental. Kind of Marching In The Same Direction, isn't really trending.
The direction that I'd like to see it go I think it needs fundamentally a really strong leader to come in and say this is hurting our entire Community. It's hurting our ability to ship software. It's making people lose money and it makes us too dependent on security Engineers. We have to fix this problem. Do you think it would be wise for aetherium just to say, like, adopt rust or something like that? I mean, where would that put too
much of a learning tax? Say, on developers, to have to learn this skill of complex language, there's pros and cons, right? Like as a security engineer, I know that I'm not the most important person in the room, like the most important person in the room is usually the product manager because you don't have a product unless you have users, unless you have a market unless you're providing value to those users and you actually do something that care
about a perfectly secure. No one uses this valueless trying to say that everybody should stop development pick up rust over the next six months is, you know, it would hurt a lot of people. It would you wouldn't be able to ship software, you lose all your users, there'd be a lot of developers to fall off a lot of companies to fall over.
So the kind of hard break, I don't think is really in the realm of possibility, but I do think it's possible to get incrementally better, and it's possible to have other Alternatives, like Viper. So, you know, a lot of the criticism lately that I've seen a Viper, I don't think is On Target, The Viper compiler. You know, while it's suffered a couple of setbacks now and then people find bugs in it.
We found bugs in it, right. Somebody paid us to do a Viper Security review, or we work for computable. They had their entire code base written Viper, and we found a compiler bug during the project, but just because we found one issue doesn't mean the whole thing is fundamentally unsafe.
I think from architectural like high-level perspective, there's a lot of things about Viper that I like We've talked a lot about formally verified languages on this podcast and lots of blockchains have implemented this programming Paradigm.
I think I can kind of explain what a formally verified languages but I'd like for you to perhaps try to do better explanation and one of the things I think people think when they think formally verified language is like no bugs or it's basically free of being able to be hacked, right? And I think that's like a misconception, obviously, can you explain what a firm believer? Foreign languages and what people are getting wrong about it. When it comes to security, Yeah,
sure. See if only verify code that you wrote, right? And the way that you do that is you express some security properties about it and then you prove them, you use a tool to prove them and there's two main components here, there's what properties you express, and then there's how you prove them, which creates this widespread difference in what it means to be formally verified. Like, if I write a smart contract and it's two thousand lines of code, and I write a single security property.
Is it formally verified? Yes or no. So like trying to say the code is formally verified or not as a binary. It tells me that you don't know what you're talking about. What's really at issue, here is what the properties are, the Fidelity of them, like how accurately they explain the critical functionality of the
code. And then the method that you used to prove them, because you could prove a security property with a unit test, but a unit test might only test one, positive interaction in the contract. It might not test all the potential negative interactions all the things that you didn't think about. So then you start getting into things like fuzz testing where that's a test case generator so you can use a test Generator to probabilistically, generate a wide variety of potential
inputs. That might break a security property and that's good. But then is that the same thing as a symbolically verified security property or an abstract interpreted security property. So, all these things kind of change the Fidelity of the security properties that you've defined, we're at a very low level, you know, maybe unit test might be really good place to start, but then over time you prove that security property with stronger and stronger methods. That are harder to kind of
Escape gaps in coverage. That's one take on formally verified software. Another is we published an academic study trail of bits went back and look through two years of etherium Security reviews that we had performed. And we split all the bugs we found into one of two categories bugs that you can find automatically with a verifier or other tool and bugs. You can bugs that require a human brain and we didn't talk about the state of Current
tools, we did that. We actually just talked to theoretically like, is it possible to build a tool that finds this bug? And what we found is that 50% of the bugs that we find could never be found by an automated tool. Now, there's some gaps in that, there's, there's some really nice things that came out of that paper. One thing that came out is that for the highest risk bugs for the bugs that were the highest severity and the easiest to exploit. 80% of them can be
found by automated tools. So if you're effectively using automated tools, including verification tool, Rules. Then you are wiping away 80% of the highest risk issues that could show up in your projects which is a great result. There's a lot here about formally verified software that I think people don't understand. So when you when you say you split these bugs up into two categories, the ones that can be automatically found in the ones that couldn't.
So if this just by like some sort of program that kind of checks against known bugs is there like some machine learning artificial Intelligence involved in. We hand reviewed every single bug. We had a, we had a team of smart people sit down and think about every single bug. We found for two years and tried to imagine in their head. If you know a supercomputer, you know, alien came down from the future.
And provided us with the perfect tools in the universe to find software security bugs, would it be possible to find this bug with that tool? And for 50%? The answer was no. So you still To have a smart human. How do you determine that though? Yeah, exactly. I have exactly the same question if you kind of have computer and you don't know that it's a human inside, right away. See how is that different from a?
Just a super smart computer that you can say, look, you really need a human to identify this bug. No computer could ever do it on its own well. So a lot of it means that you have to think about, okay? So here's how you talk about it. There's a lot of bugs that are generic to the programming language, like Access Control issues. It's a problem if If you forget to control the access to some kind of function that lets you upgrade the contract, right? Or kill, kill the contract.
That is a fundamental invariant that you can express for the entire programming language in all programs written in it. On the other hand, there are security properties that you might need to Define that are specific to your contract. There's something that you are trying to do, and the only way for me to tell that this is a bug, or this is not a bug, is if Have a smart developer tell me that that's what their intention
was. But if you have a specification of some sort that specifies that then you could presumably also have a computer. I mean I guess that's maybe what formally verified languages. A lot of you do is you create kind of this like this framework or the spec in the traditional software sense, like let's say, so the reason why fathers are really prevalent inside of like compiled code C and C++ is that I know that when I get a crash that that's going to be a bug.
Right software should never crash. So therefore, if I find a crash it is a bug on the other hand. If I have a smart contract and I managed to, you know, transfer some money to somebody out on the blockchain. Is that a bug or not a bug? I don't know because that might have been my intention to do it. So you really need some element of guidance that you typically don't need for traditional
software. The other thing here is that a lot of these vulnerabilities, there's just like high level logic involved, there's high level thinking. But a machine is not going to discover on its own and that it would be incapable of kind of creating on its own. But there's a blog post that summarizes. It called 246 findings from a smart contract Audits and executive summary and we will link to that in the show notes.
Great. We've kind of jumped in the deep end here, so maybe maybe that's go back to square one. So basically say I've built a project on E, theorem say some type of decks and that's a team of developers on the projects. And we're making the leap to men it. But of course, we think we should get this audited in. This is probably one of the times when people call you and say oh, why can't we start tomorrow? But you know, like only 2 months from now. So we call you and what do you guys do?
So they see what us the journey look like first off. You know, I think there's a misconception that people should hire security firms. The second that they finish their software. Usually, that's way too late for. Exactly the reasons that we just got done discussing a lot of your Depends on the ability of the developers to express, what their intentions are. What are they trying to do with the software?
Did you write a spec for it? And then, did you write the minimum amount of code necessary to actually Implement that spec? Because complexity breeds and security and the more unnecessary parts of your code that you write the more bugs that you're going to have so engaging with the security professional early is really critical. We really like it. When people engage with us at the design stage, we can talk through different implementation
strategies. That might reduce the foot guns that they leave in the code base. The areas where they're likely to have bugs that ends up making the after-the-fact review the final stamp. You know, the final test before it goes into the Thunderdome on the blockchain, it makes that process a lot easier.
So when we do actually get hired for a security review, a lot of what we end up trying to do is reverse engineer the intentions of the development team because the developers don't always know what they are. So it involves a lot of communication, a lot of, you know, back and forth conversation about Hey, what were you trying to do here? What is the intention of the system?
And then will encode that into a spec for the team that we work with or write out the security properties ourselves will prove them with property, testing fuzzers, like Echidna or will prove them with a symbolic verifier, like Manticore. And in addition to that, we'll find those. Generic language level invariance, things like a lack of access control, or integer overflows or re-entrance E and that kind of stuff that might sink your ship in different ways
that process continues. For, as many weeks of the weeks of the review that we have and then what we do at the end, we sort of doing this a couple months ago, about two months ago, is now, we also include a code maturity evaluation because security isn't really like, okay, great, you're done now, like somebody looked at your code, all the bugs are gone, that's not how it works. Because you created that code, you could have hidden any number of potential issues in there.
And really what we're doing is assisting you that's why I call it a Security review, not a security audit, right? This isn't like accounting or I can tell you Everything is like you know all the dollars are properly accounted for and therefore you're not committing fraud. This is more of a probabilistic check where hey, you know I noticed you're doing some things that aren't so great.
It's like you know, when I used to play baseball as a kid, I videotape myself swinging the bat and then watch it. And I'd have somebody else that new a lot better. How to play baseball? Take a look at it and say, oh, you need to step like this and then you'll connect with the ball better. That's kind of what a Security Professionals doing. They're trying to tune you up. So, you produce the most secure code And so, the code maturity evaluations, give you a long-term view as to where you
are in the process. Like, what is the state, what is the maturity of your testing and verification? What are the maturity of your access controls? What is the maturity of your use of assembly? And how is that going to cause or not? Cause issues in the future? Because this doesn't really end
after you release. Usually, you've got a version to that's cooking, or there might just be advances in the field or the Block Chain itself could change underneath you, you know, who knows what the etherium foundation.
I was going to push in there. You know, next biannual hard Fork that might eliminate all the kinds of security protections that you put in place or or the next person to invent flash loans that all of a sudden takes the security margin that you had for interacting with the all your oracle's and drops it to the floor. What for exactly these reasons. Basically, what we see more and more upgradeable contracts, right? So upgradeable smart contracts,
but they come with them. Their own pitfalls. Can you talk about that? Yeah, so upgradeable contracts are really interesting case study because there, another example, where the solidity language shoots itself in the foot, like, in order to do upgradable contracts, you have to, you have to use a substantial amount of low-level
solidity to get them done. And the fact of the matter is that we've identified 17 unique ways that upgradeable contracts can fail and either lock your contract or lose everyone's data or be exploitable. After you put them on the blockchain and It's really not as simple as people think. Not only that, but it creates risk because now you're, you have to handle private keys on your corporate. It like, you know, you've got a network somewhere.
You've got a computer somewhere. That's got some keys that let you manipulate the functionality of a smart contract on the blockchain, which is massively fraught with risk for a number of reasons. Doesn't that defy, the whole point of a blockchain, it does. It really does. So I trilobites were not too big fans of upgradeable contracts. We understand the need for them, like it's Critical that people have you know contracts that can pause when they're having a
security issue. It's critical that people can recover from an incident when they experienced one.
But the methods that people use for upgradeable contracts today tend to be inherently unsafe again Slither is a tool that enables us to only find bugs once or only have to find bugs ones and we've encoded all those strategies for, you know, accidentally failing threatened, upgrade will contract correctly into Slither. So it checks for all those 17 cases of failure, Doesn't mean that's exhaustive. There's probably more and there's a lot of other ways that
can go wrong. Like, you can just get hacked and lose your keys, which is another thing that we consult on like how to use an HSM to store them like a professional. But upgradeable contracts tend to carry a lot of risk with them. So, instead we try to promote the use of contract migration, which is just burning the whole house down. When you've got a contract or token or whatever out there on the blockchain, you can save all the data and roll it over to a brand new car.
I tracked that presents a lot of issues. Since clearly you have to notify people that might be using your old code to use your new code. Also has implications that defy space since there might be some, you know, defy app that's sitting up there on the blockchain that's hard-coded to think that you're at a certain address but now you're not how do you fix that? So you know, there's not challenges to it but it's inherently safer since there's a lot less moving Parts, it's cleaner.
I also think it's more honest I totally see that. I mean, that's that's pros and cons, right? So I totally see that. It's probably the most secure way or it's definitely the most secure way. Then the question is, do you kind of leave it up there and just tell people to migrate and then, basically, you have the problem of split liquidity and different versions. And you can't do that too often and it's kind of fraud, both
ways. So, when we think about Security in blockchain technology, we almost invariably go straight to Smart contract failures that There's also plenty of, you know, like front-end and back-end vulnerabilities, that we pay not as close of a mine too and so they're often overlooked. So for instance, with what happened with Luke, bring a couple of months ago, I don't know whether you remember that. I don't.
It was about the way that hash was stored somewhere and there was like a limited number of hashes that they were actually using. They were they were, they were generating hashes and 32-bit space. That sounds bad. Do you think we pay too little attention to the things that happen around the smart contract? So, basically, the front-end and back-end infrastructure brother, because everyone goes straight
to the smart contract, right? And people do smart contract audits, but I know a few of fewer companies who actually do complete front and back-end audits, just because it's an expensive thing to do, right? Yeah, I mean I think there's some properties about smart contracts that make them a little bit more. Like I think it's correct that you focus on them for the first line of your Security review. They're fully exposed to the public.
Anybody can go read and run the code which is really unique. Right? If you have like server infrastructure up in the cloud somewhere, I can easily grab the source code to that and start messing with it. I have to I have to just poke a black box which is a fundamentally different kind of problem to solve on the other hand the information you know, quote unquote. Formation that you steal from a smart contract is inherently
financially valuable. So when you think about this, from an attackers perspective, what they love, what they ultimately usually want to do is make money, sometimes they want to get Fame, sometimes they just want to, harass people and troll, but for the most part, they want to make money.
It's much easier to make money, hacking a smart contract than it is to hack a server somewhere on the internet because once you hack the server, usually, that's a pivot point axis, something else that does have Financial value. So there's more Steps involved in cashing out, right? So for those reasons, it's definitely appropriate to focus on the smart contract, part first, but, yeah, by no means
don't stop there. You absolutely need to think through the entire perspective because again, how secure is your smart contract. If you publish the keys for upgrading it on the internet, right? If you're just throwing them on your personal laptop and that person laptop attacked then. So does the smart contract and every single piece of data on it. So, yeah, depending on You trust.
And the way that you designed your system, the security of your oracle's, the security of cloud infrastructure, the security of your mobile applications, the security of your authentication system can all play a role in. Ultimately, the security of your product, which is what you need
to think about. You need to think about, is this product, doing the things that my clients expect it to or am I going to unintentionally lose all their body or unintentionally, do something that they don't expect, right? And and that's a larger problem than simply is your smart contract safe. For a lot of clients. We've actually started doing threat models people in the Block Chain. Space haven't been to up on it because they're more like interested in the really quick.
Kind of like, you know, rush out to production. I know what I need and, you know, I'm really kind of ego-driven secure Tech Master of the Universe and not a lot of people stop and think, like, okay, well, what don't I know and what should the interactions be between the systems that I've designed and what are the risks that I need to mitigate against?
So, for a lot of people in more mature Fields, we've been doing threat models, for instance, election systems voting systems, not closely related to governance systems but not quite for those. You know, you could throw security at the wall and see what sticks you could just go and say hey I've got 10 code bases, I'm going to have somebody do an application Security review. I'm going to make sure that I can't crash.
But really what you want to understand is how easy is it for someone to manipulate this election? How do users interact with the voting system that I've Designed is it possible to hack the end-user and somehow convince them to use the system in a way that they're not supposed to, like, you know, can I tell people to download the wrong mobile app? Maybe it's not even a security issue in my system, but it's the way that I communicate things about it, so we've done a lot more threat models.
We've tried to figure out like, what's actually important for the blockchain. This is the same thing. Like if you want to sit down and start developing security properties, for a piece of blockchain software, what properties are you going to write? What are the interesting properties to express? And in order to answer that question, you need an accurate understanding of your threat model. We use a couple tactics for building threat models. We use Mozilla has rapid risk assessments.
Most frequently there are really gray 30 to 60-minute scripted interview that you have with a developer to help them understand, what's actually, at risk in the software they've built. But then other times, there's nist standards, there's all this Adam szustak kind of literature that came. Microsoft, that are a lot more heavyweight, but the rapid risk assessment stuff fits really well into a one or two week Consulting engagements.
That's what we end up referring. If you want to see an example of that. We have a great example of a really well developed threat model up on our Publications repository. That we did four votes, a blockchain voting system. That's the area where all this stuff overlapped. It was quite entertaining to us to get a client that had both but you know, you can see what it looks like and we'll be publishing more of those as time goes on. So hopefully there's stuff that
people can learn from. Okay, we link to that as well. We've talked about the security vulnerabilities of individual smart contracts but now it gets even trickier. Right? So basically in the defy space and then the open finance space composability is key. And we have seen several attacks and vulnerabilities over the just over the last past months who's Gateway was leveraging some weakness in composed protocols.
So what do you think we should be doing about that so who Be responsible for checking that thing's actually fit together and that basically interfaces work. And is it the people who actually build the blocks and thereby also the interfaces or is it the people who are kind of use these money Legos to build, like more complex, protocols or should the users check? Or should we have like an external body? That kind of satisfies, these kind of composed protocols, what's your take on this?
Yeah, so I mean for better for us, there's no gatekeeping. Like I can't, you can't tell me that I can't put code on the blockchain. So, ultimately, this is what creates all bunch of surprises that people have to deal with the defy space. I think is really immature like it's a beta, use case for etherium, and for blockchain technology in general. And people need to understand that people are throwing a lot of money in to defy applications right now and are kind of holistic, end-to-end
understanding of exactly. A whole Field. Works is very limited. So I expect that there's going to be failures and that there's going to be these new use cases that people come up with whether it's a flash loan or a deflationary token or like, whatever people end up designing, that flips, all the security properties. I thought I had on its head. So the D5 space, I think users really need to understand. It is a work in progress.
This is not like, just because I've got a couple of Legos, doesn't mean I can just start using them today and not suffer any potential consequences like theirs. Always going to be some downside risk and the downside risk in the D5 space right now, is really high because that level of maturity just is not there yet. I think there's a lot of other things than defy space that kind
of caused me concern. And for people listening to this, they can't see my body language right now, as I'm kind of like nervously, rubbing myself just like all the defy space stuff, stresses me out. You know, there's assets with really low liquidity, even ignoring flash loans, there's things that people Very limited amount of money can interact with and cause failures for other people. There's all this Reliance on external oracle's we're not everybody that's deploying a defy application.
Has evaluated how secure their system is against that Oracle being manipulated or how many oracle's being manipulated or what the cost is to manipulate an oracle. Like just that kind of full system thinking really isn't there. How can you have full system thinking, when, if the number of oracle's you can have in a system is basically unlimited. And then, on top of that, like the number of bugs, you can have per Oracle is unlimited, right?
You're basically just reducing the security to the lowest common denominator and you don't know what that is. So it's like, you know, it's virtually impossible. Then in that case, if you have external inputs to a system to ensure full security Yeah, I mean, it gets even worse. When you start thinking about external contract, interactions, right? Like, there's a lot of players out there, you know? The compound folks, I think are one of the best where they whitelisted.
A lot of the interactions they have with external contracts because you just don't know exactly what everyone's going to do and you need to carefully, consider all the interactions between yourself and a counterparty before you start engaging with them. There's a lot of contracts out there that say that they're ERC 20 but don't actually implement
the spec is the easiest example. There's a lot of Acts out there that, you know, if you don't flow through all the second third, fourth order, effects of what it is to interact with a given contract. Then there's the potential that somebody finds one of those composability issues and gives
you a really bad day. So I think it's really incumbent on defy applications at least right now to take these baby steps towards full decentralization and not exactly go for hey I'm going to interact with the whole world and everybody on the blockchain could call every single function of mine. And I'm going to call every single function with areas and it's going to be great because it ends up taking On too much risk to quickly.
So I think a lot of people in the D5 space need to take some baby steps and be sure of themselves. When they take those steps through either Security, review really effective and thorough modeling work with economists to figure out a second sentence and actually understand what kind of risk their inheriting. Maybe do a threat model, right? Understand what kind of risk that they're inheriting by interacting with those systems or creating certain features so
I thank you that stupid. Resting. So there's a different kind of bug that we don't think about often after basically composed abilities and everyone's at the Forefront of everyone's mind. But there's one thing that a lot of people who've been in the ecosystem for a very long time. I deathly afraid about but that we rarely talk about.
So bugs in the compiler just because if there's a bug in the compiler that kind of causes a certain era and basically it's kind of people don't generally check bytecode and in their audits. We kind of rely on on the code itself and the AST and so on. We don't really check the bad code. So do you have thoughts on this? So are we too reliant on individual? Contact compilers a little bit? You know I like I said earlier the quality of the compiler that most of us are using solidity
compilers extremely low. So the testing just really isn't there and there's an ongoing discussion right now. About improving. Some of that testing by actually importing some of the techniques from Slither and offering more standardized interfaces for Or software like ideas and testing tools so that we don't accidentally break the entire ecosystem of tools that people rely on to test the software that they that they create, you know, by updating the compiler.
But it is a little bit of a misconception that we're not testing by code. Most the tools out there that are doing property, testing, or doing some bollocks verification, or are doing abstract, interpretation are actually working on the bike code. So, when you get a manual review, normally that manual review is of the solidity. That Wrote. And then if you have a static analyzer, that's that economizers. Usually, again, going to be of
the solidity that you wrote. So, you inherit some potential bugs from the compiler, but when you're writing properties, writing security properties. In general, the approach that Engineers have taken towards building. Those tools has been to evaluate those security properties on the byte code that gets put into the blockchain.
The risk is that the emulation that you're doing for the etherium virtual machine to evaluate that bytecode, might not Be identical to the etherium virtual machine that powers the blockchain. I have a python aetherium virtual machine that's built inside Manticore. Is that identical to the execution of the etherium virtual machine on the real blockchain, I try to get it to be as close as possible but there's always the potential that there's Divergence was there as well.
So, you know, this is a little bit of a like, you know, Turtles all the way down but every single one of these things that you do ends up reducing the scope of what can go wrong. Like it doesn't hurt you. To do a manual code review and find bugs and solidity. That only helps, it doesn't hurt you to depend on a from scratch python implementation of the etherium virtual machine. It generally only helps you find
bugs. So these things over time like you get this preponderance of evidence like okay I've reviewed the the source code I've statically checked it with a linter. I have property tests that run on the etherium virtual machine and then I'm only going to compile it with a safe version of the compiler. So for instance, a wreck mendacious that your lab it's makes and our reports is. We don't want you to use the latest version of the solidity, compiler.
We actually roll back two versions that we think are safe. I don't know the exact version that we recommend now, but generally, we look at the maturity of new features, they're developing and take our own view as to how safe we think. The long term will be for each of those those features and then we you know, recommend something before those features were introduced. So things like the API encoder version to the Parsing, that kind of stuff, I would absolutely avoid and use a
version of the solidity. Compiler. That's older since less likely to have bugs, you know, introduced into your code. Sure. And so are there other dark horses in the blockchain security space for that should keep us up at night? I mean, how do you feel about non Quantum resistant code? Is that something we should worry about? What, what should we do? What should we worry about that? We're currently not worrying about. So give us some nightmares. Yeah, sure.
I mean the post Quantum stuff. I'm not I'm not super worried post. Quantum stuff does not keep me
up at night. I think it's still an open question if quantum computer can even exist, you know, a lot of people talk about the the number of qubits and whatever that you can get and how that's growing over time and there's a larger number of cubic quantum computers, but that's not actually the, the metric that people use to evaluate, a quantum computer works or not because you have to deal with noise, the larger, your Quantum system is the more noise that
you To look through in order to get results out the other end. And what we've seen is that as these quantum computers scale up, so does the noise and the end up kind of equaling each other out. So I don't think that like, Quantum Computing is a five-year problem. It's definitely not a 10-year problem either.
I think it's more of like a 30-year problem and when you look at it on that time Horizon, there are some really good research results that are out for developing post Quantum cryptography trailer B has a great guide on our blog called a guide to post Quantum cryptography. Where we review you'd a lot of the nist candidates for Quantum, cryptography and broke down the different categories of lattices. I saw Jenny's codes hash functions and all the other kind of potential ways to get there.
So I think that on that kind of time Horizon, cryptography can kind of Mosey along and end up giving us a good result and prepare us for the future if quantum computers were ever to exist. And that's, you know, I'm not discounting that's a possibility, but I'm just saying that it's hard. So that's, that's definitely not what keeps me up at night, honestly. Like, I think the outlook for, Contracts is pretty good.
Like I think that in 2020 we figured out a lot of the things that we needed to know to build smart contracts safely, like there are tools that are available for people to use. There's a process that they can follow. There's a lot of lessons learned from other failures and we generally know the foot guns that exists inside solidity. Even though we'd prefer they weren't there.
And I think that four teams now that are developing software, they have the tools to have the knowledge judge and its capability within the realm of capability for them to produce secure software. It's just a matter of whether they do it or not. So generally, what keeps me up at night is that there are people just sling and code that there are people that just ignore all these lessons that don't do their research that don't use the best tools available to them to produce software.
The adherence that we have two people that use Slither to check code before they put it on. The blockchain is still pretty low. I don't know exactly what the numbers are, but I'm sure it's not 100% and that's a, that's a huge problem. There's 90 flaws that slither finds that the solidity compiler can't. That's kind of what keeps me up at night. There's all kinds of new stuff that gets developed like the defy space. I'm kind of like, I've learned
to love the bomb, right? Like, I know that's an immature space. I know there's going to be hacks and failures and that's what I expect to have happened. So when I see it happen, I'm not surprised. So I'm comfortable with the fact that we're going to discover more potential things that cause issues like like flash loans or deflationary. Tokens or people that just don't implement, the ear C20 spec properly, and people inadvertently, trust them that they do.
There's a lot of stuff there, I don't know, I'm a little bit jaded, so I think I've seen all this stuff before, so it doesn't really scare me. I have to be able to sleep easy like that. I wouldn't be able to work in this field. If I went to bed every night, what's the worried about the world being there? When I woke up in the morning, Balmy as the space continues to grow and more say like real world assets or like institutional Finance comes into this space.
Like, do you think at some point there will be a trade-off where we either have to go towards more centralization or more white listing or like kind of pull back because you know, if just composability just grows exponentially. That means also like exponentially more. Purity issues and security, vulnerabilities, and institutional Finance is not going to want to deal with that. So what's the future look like? Yeah. So the defy space I think is a really special case, right?
Where if you want to have some defensively unit of code out there, that's capable of remaining safe, despite changes to the environment around it forever. Then you need a really solid understanding of all the economics of that system and all the incentives that people have to interact with it and all the safety margins for all the bad things that could potentially happen. You know, we recognize that. So we partnered with prison group, a small team of extremely talented.
Economists that, Like us used to work professionally with large financial institutions and Central Central Banks and that sort of thing to offer a combined service offering called maenette 360 where we look at things from a combined economic and security perspective. What was good in 2019, what? What used to pass the bar in 2019 of like, okay, I don't have re-entering. See my contracts. I can put this thing up on the blockchain.
That is not the bar in 2020. So like there's a higher standard of proof that I think people are going to need as time goes on. So we're certainly not done like just because I wrote Echidna and Manticore and Slither doesn't mean I also security solved and if everybody runs this stuff before they put on the blockchain, the totally safe.
Like there's certainly much farther that we have to go and I think having a really solid formal understanding of the economic security of your smart contracts is probably the next level to that and that's where trilobites is investing. A lot of our tool development and a lot of our Partnerships and a lot of our own teams kind of internal knowledge transfer and learning. So what's the future of software security? And you know what role is a i play in terms of being able to detect bugs.
I mean like right now there's like human Auditors but you're also relying on a whole lot of tools like we kind of gave this analogy to like a spell checker or something like that. Right. Like grammarly. Right. But the next logical, step would be my mind. Be like, let's now build like some artificial intelligence that goes in and tries to figure things out and perhaps based on in some input or some like that. But like what's the future look like?
Your opinion. Yeah, I don't know AI plays a huge role. So a eyes been really cool. There's a company of things are called tab 9 that created an AI driven software, development tool like an IDE, they took the entire universe of source code on GitHub and they trained a model around it. And then when you're inside of your IDE, you can just type out one word and then press tab a
lot of times. And when you press tab, a lot of times just fills in the code that it thinks you're writing based on the model that range from GitHub, which is super cool. But for security, you know, a lot of what makes the program secure is, an understanding of your security properties and the ability of you to test them and the tools that you use to do, that aren't probabilistic their deterministic, that's what you want.
I don't want like a model that's kind of fuzzy that like, you know, the these guys out on the internet so that it was safe. Therefore, it is like, that's not the standard of proof that I want. I don't want to train a model to tell me that my code is safe knowing that it might be wrong or that there might be, you know, things I trained it on that are incorrect. Instead. What I want is I want like symbolic execution to Fork off every potential configuration of every single function in my
entire smart contract. I'm provided deterministic result back to me that it's impossible for me to reach a state that I don't want. That's kind of what security looks like in the future. You know, we participated in this DARPA program that tried to examine the exact same thing. Back in, 2014, 15 and 16. It was called the For cyber Grand Challenge. The way it worked was I don't know if you know the development of computers like deep blue. But back in the 60s and 70s, they used to.
That was the first time that people created robots that would play chess my robots computer programs that would play chess and the computer programs were just so awful at their jobs that they would get creamed with even an amateur chess player and there was no way that they would ever win a game. So they ended up making a league of only chess-playing robots. Where the chest Robots would play against each other where they're all, just as dumb as the other one.
And then, eventually they learned from each other and they figured out strategies that worked, and they build up a huge repertoire of potential attacks and defenses. And then after years of training against each other, they were able to play against him. Beat human participants. So the DARPA cyber Grand Challenge was supposed to be the same thing for computers. It was a league where computers could play Capture the Flag, a simulated hacking exercise,
against each other. And then the winner of that competition would play a capture the flag. In Defcon CTF, which is the largest Capture the Flag Channel. Our most prestigious, let's say I capture the flag challenge in the world.
We put forth a machine to do that, but the kinds of advancements that you need to improve software security, tools are things like automated crash, triage better program analysis, tools that help you understand and model, what a program is doing and where data is going, those kinds of things are really critical to the future of software security, not so much the AI portion. It's not a clean kind of Relationship between software security and chess.
If any of that makes sense. I actually have a great talk with smartphones are Revolution where I try to review all the research that's been made and the progress that's been made in the last 10 years or so at automated program analysis and software security. Generally, I think the future for this kind of stuff is that a lot of the tools are going to get embedded into IDs. Like right now it's a specialized task for me to use a program analysis tool.
Like a symbolic executor Or some other kind of program verifier you need a security expert to do it and it's a third-party tool. We have to go download it separately, but I think the availability of a lot of these tools inside standard development tool kits will increase over time, so hopefully the bar of knowledge required to use them goes down, more people. Take advantage of them and then we end up finding a lot more
bugs. There's also the potential of like using them as Gatekeepers in the talk. I talked about things like you know, a lot of people that are developing apps today they deploy them to an app store. The go out to the IOS app store or the Android App Store and there's a really nice point of control where you can use these program analysis techniques to ensure that every app that everyone has access to meets a minimum bar of safety.
And I think that the blockchain kind of has a lot of the similar characteristics as an App Store where there's probably some upfront verification that could happen prior to entry. Like are you this tall to board the ride, kind of deal that might end up making things safer. So that's where I see kind of, you know, maybe the two-year A lot of the stuff in two years, there might be a test to see if you're tall enough to board the ride to get on.
Maybe the ethereum blockchain but that might be an anathema to a lot of the like cypherpunks out there that really don't want to do gatekeeping. Yeah. They'll go for kit and take their toys somewhere else. And yeah, and then they'll go build their own blockchain and we'll start with the same problems all over again. Dan, thanks so much for coming on. Working people, find you and Reid and we'll link to all of these great post you mentioned in the show notes.
But where would you like some people? Sure. Yeah, you can follow me personally on Deke. We do that on Twitter. You can also get the trail B at drill bits. Our blog is exceptional. Are highly recommend is getting it. We try to have fun with it.
Yeah. Blog dot trailer b.com and then if you're in the market for building smart contracts you should go look up our repository called building secure contracts which includes the accumulated lessons learned from all of our security reviews and how we recommend clients, build secure contracts without us. That's going to walk you through all of our Tools a lot of our guidance checklists, tips and tricks. All that good stuff is right there. Awesome, thanks.
Thanks a lot. Thanks for having me. It doesn't end here there's much more of this conversation and you can hear it by signing up for epicenter premium as a premium subscriber, you'll get access to a private RSS feed where you can hear the interview debrief which goes on for an extra 20 minutes. You'll also get exclusive access to Round Table conversations with epicenter hosts and bonus content. You won't hear anywhere else.
Go to epicenter dot rocks / premium to join the community and support the podcast.