Hashing It Out
Hashing It Out

Episode 21 · 4 years ago

Hashing It Out #21: Mythril - Bernhard Mueller

ABOUT THIS EPISODE

The famous Bernhard Mueller joined us today to talk about the fantastic work being done to beef up his already amazing tool, Mythril. The new Mythril platform beefs up the symbolic analyzer as well as adding static analysis tools and linters (Maru), a dynamic analyzer and input fuzzer (Harvey) and an API for easy integration into a developer's processes. We dive into what brought Bernhard to write Mythril and how it's taken off as a premier auditing tool. We also get into the future of security tools and how the processes being developed today will inform best practices of the future.

Jing work. Welcome to hashing it out, a podcast where we talked to the tech innovators behind blockchain infrastructure and decentralized networks. We dive into the weeds to get at why and how people build this technology the problems they face along the way. Come listen and learn from the best in the business so you can join their ranks. Episode Twenty one of Hashing it out. I'm Dr Corey Patty, as always, with Collins. Say Hello Colin, Hello Cohen, and today we're here with Bernard Mueller with mythyl but want you give us a quick introduction as to who you are, how you got in the space and what mythral is. Yeah, thanks for having me, guys. My name is bred huts. I'm a software and secure the engine yet consensus diligence, but a joint it is here, but my background is actually in software security. So we'll look my most of my life. Fact don't break stuff like republications over apps and like everything else that you could think of. And I got interested in the theium about a year ago and I was out of a job for a while, so I started writing this year basically as a hobby project. Yeah, mystery is an open source security analyze of for the therium by its code, and originally it was actually meant as an attack too. So it's initial purpose was just too anice contracts on chain and detect anything that's off base. So it was only compatible with spyte code. But then people actually started using it and started to be more request for also processing solidities or edited as well, and then I think it became quite popular. So developers use it in their field process and so on. Even though it's it's still more of an experimental tool, in my opinion, but the result such nights are not bad and also quite usefulizing most things in the space. You're still experimental. Technically. I think etherium is experimental chain. It's not supposed to be used as a thing. Is Driving Actual company platform. You know court thea founder, but you know that said, I mean the experiments are really helping companies actually do stuff with this. So I thank you for your work, even though you built it exist molitious intent. I'd be curious to know, coming from a traditional security background, especially from an offensive standpoint, how have you viewed the etherium ecosystem and the I guess, what security is in a completely decentralized kind of permissionless manner. Like I've I also work security for for status, and I'm trying to kind of wrap my mind around how the ideas or a tax surface of what I would typically go after. Things that would typically be the main target of an attacker change as you move into a decentralized company, decentralized platform and the things that are built on top of it. Yeah, I think it's very challenging for developers that's come from a traditional background to understand what happens if you're run code in the context of what decentralized system. That's. So basically, you are you are you're doing state changes to a to a vote computer, to about states that ship between anyone, and the stuff that you deploy on the blockchain is supposed to be immutable, right. So if you fuck it up, then you can change it, but before it is and if the code works in the way that you didn't expect, and there's also no way for you to revert that, except that you can ask the community to do a heart folk and restore all your funds, but at this point is probably not going to happen, and so you cannot roll back bad actions, unintended actions. So that's very challenging. But also just to consider the weight of the code runs and debated transactions are...

...processed. Like, for example, debated blocks I created. You can really predict the order of transactions that people will see, transactions in the men pool, because they get added to the change to the chain. So you have things like front running and that's not very intuitive unless you really understand how the system works. Right. Yeah, so I can see that. If you come from a javascript background and you did publications before and then you see also thed is like chavascript. Awesome, I can use that, but you don't really understand implications of what you're doing, then it's very easy to make mistakes. We talked about that previously on the show and and just generally in our slafe channel on other shows. Is is the idea of the intuitions involved with creating web APS and how you program and what your cavalier about when doing that. Programming doesn't doesn't transition well when starting to build at least the smart contract aspect part of a decientialized application like yeah, that you can't be so cavalier. You have to be much more. I guess scientific computing minded or high performance computing minded and that it should work exactly how it's supposed to without fail the moment you deployed, and that that type of thing is, I think, now starting to become like it's. It's more in the mindset developers now because we've had public, public problems like the down and the parody hack and things like that. So people are starting to become more aware of these types of things. But, like you said earlier, from a initial standpoint of a web developer jumping in because of familiar javascript, they poured over all those bad habits of Web webification development. That's a completely different cult text. Have you audited any SMUTH contracts you'll set before? Nothing, nothing like official. I've used some of the tooling to kind of play around with and look at how things work and I've definitely looked into halt like all the different vulnerabilities that associated or smart contracts and the compilers and the bike coode and things like that, but I haven't done hodess for other people. I'm more interested in the in the security of everything else. So like the blockchain is, you know, quote unquote, secure. Once it's in there, it works as intended. Getting that information to the user is a witany of other problems that I don't think people are looking at. That's really interesting. But in my opinions, smart contract all this are very, very difficult to do because you have to be very you have to be extremely precise and you cannot allow yourself to make any mistakes right, because it's if you added like an enterprise, that replication. You always have this disclaimer that's nobody can find anything and we have this limited time and then if you overlook something, okay, then then you didn't find it in the smart contract. It's not complect itself is not that complex, but especially if you have my propriate contracts or something that's a little bit more offense did and can be very, very difficult to to really grasp all of its and consider all the things that can go wrong. Like if you look at something like a Darmacccle like that's a really like set of smart contracts. I mean they're very like intertwined and and timing based in and they deal with settlement lending and interest calculation and stuff like that. All of those things have possible attack factors, especially with transaction ordering like you, like you mentioned earlier. It's not just about the bike code, it's about the entire system. So what kind of things that you noticed as you've been doing this that most developers aren't cognizant of that you like to kind of shout out to basically say hey, you're developing a large smart contract platform, you need to look at these things. Well, well, it's kind of a top ten this thrids like reentrancy and unprotected functions and stuff like that. So I don't have any anything in particular. I think just in general we need a clear classification, classification of what those things are and and practical guidelines that programmers can follow. So, since you've dealt with a bike code side of things, have you noticed any attacks that only appear in the biker but may not be particularly noticeable from the code standpoint? So particular ways of people use traditional coding models might actually enable a bikee code attack whereas you know, you wouldn't notice it in the actual code itself. Very well, yeah, that's one very interesting thing that I brought about in my last paper. I don't know if you read it. It's called smashing smart contracts for fun and real profits.

I have not and I'm going to link it in a show notes for others who are interested. And does what very one very nice feature of dynamically sized arrays, so you know how dynamically size the race works and solidity to basically, if you're an array but you don't know how many elements is going to have, when it has a length variable, and if you manage to underfload at lengths variable, you can basically and address any element into array and overbright arbitrary storage locations. So you can, example, who right storage slot, Cerro, which has the owner start? And that's, let's say, something you. It's very, very hard to see from the source cute alone, because you need to know how so they did. You computees the offsets that it uses and you reference an element in their array. So if you note that, then you can calculate the exact number that you have to put that to to reach that location that you want. But if you, as a programmer, don't really have notice specifics, and or almost nobody does, then I don't think you would realize that this is exploited this. Yeah, there's actually there's kernel protections, but those kind of things in a lot of modern operating system for certain types of look a pilers bake that in? I should say. Yeah, M is so light that it really doesn't have these kind of protections baked in. And the hooks in order to facilitate those, those kind of protections like that actually be a standard kind of like thing. You know, Oh, you can't underflow an array because it can go outside the index bounds. Well, you know, that's not something that the solidity compiler will be able to they would have to write actual solidity code to protect that, whereas you know, in an operating system you could just do a call. Let's say, Hey, this is bounded by this amount, you should allow it to go outside this memory space. That's big. That's a that's a major problem. I was not aware of and I did glance over your paper, but you know, it's not it's it's not something that I think anybody would even think to notice. If they come from a traditional space, you just wouldn't know. They would there too too dependent on the robust environment that they typically work in, and so especially travel script obstructs everything. Over, you know, you don't need to to varry about memory allocation, garbage collection. Yeah, yeah, and how much? How many bits of what's the largest Walt Ali that than integer. Very every can hold. Yeah, because travels could controls for that right, but thing solute if you doesn't. That's what I mean. becaues, that initial that initial intuition or things you expect to happen when you come from a higher level, like script. Script like language doesn't work well for the things you need to care about when writing smart contracts. Mean that I guess that that Viper or the Python version or the python like version of of making smart contracts helps with that. But still python is not much better. I came from a Fortran background, so, like you really have to care about all of those things in order to for your program to work. And at are other level languages that are similar, and I think that type of intuition helps people make better smart contracts from the start. So and also tooling around the smart contracts to provide better checking to make sure that what's actually created from the source code is what you want it to do and not necessarily like have these weird these weird quirks about the actual Bi coade that's deployed to the contract, to the to the blockchain. Yeah, so you've a facilitate the creation of better smart contracts. Mis role is grown from just a simple tool me thross, to suiteen tools and our platform API. So maybe you could talk to us a little bit, going one by one through what you've guys kind of built, like Harvey Mare, methro plus plus, to tell us you know you're going with this like like. Obviously this is a good first stop. I like we've got a long way to go and there's a lot of different tools of people need in order to securely build and deploy a smart contract. So what are you doing to fix the problem when we try to get tools into the hand of developers that developers can actually use and should be point and shoot tools that if good to results and goods coverage within the short amount of time, because nobody's going to await like three or four days for the results of an analysis, and it should back a lot of the books and it should fit into different realier environmental developers are working with, like it pipe plans, ideas and so on. So the ideas to have one API that's hopefully offers the best security analysis available and...

...the first version of that API you will submit solidly disource code and Byte Code for the same contract and you basically have this sieved of tools that all run and the results of the tools get correlated and inform each other to improve, to get to get it so that the grade that becomes more than the some of its parts like to say. So, for example, you could say you do do a first part of static analysis and then you feed the input into the symbolic analyzer and symbolic analyze and those what parts past important to cover so you can speed up the analysis and the recycle of debt generates test cases for the fuss and the fuss than very fast that the bugs actually exploitable. So that's the basic idea and it will not be all that. Also in version one of the API, but we're going to expand and that gradually. So I guess to like tooling like this especially maybe has different audiences. And who who your Democrats, effeca is one could be the general developer who this gets built into their pipeline, like you just mentioned. The other is like for the specialists, the excite auditors or who are doing like who word, getting paid to make sure that they go over with a fine tooth, calm any potential vulnerabilities or problems a smart contracts from other people? Is there a differentiation in the in the product between these two audiences, or do you see it more along the lines of just becoming more like, you know, automatic linting? Are Checking things like that so that when someone tries to make a smart contract, I say, Oh, this is a problem, fix it before you send it off to an actual auditor? Yeah, exactly. That's what we're targeting. So they targeting developers and the stages of development. So the earlier the possible. It's a good it's a good place to be. This ide immigration to write. Yes, yes, exactly. So we have issues to ther, quote plug in, for example, and experimental one, and with a few people working on really cool ideas like book. Simply one guy came up with with a solidity watch it POPs up at the step of multification if does any vulnerability, and think there's unlimited things that you can do. Other ideas would be just like the tools like that you install from MPM truffery. Integration is very important. So you know, this phase mostly looking for partners that want to integrate misrial in some way. I can probably facilitate some of that, considering status R creates embark which, okay, one of the larger, the larger ideas in the space. It's go one through, one by one, through some of the tools that you're developing a network. talked to us a little bit about marrow. My speciality is misteral to be honest. Okay, three, three different teams back from one each. Okay, so are we is actually told? It already exists. So it was built by a guy called Volentine, and I think you did it for a speech DDAYS's thesis, and was playing with on start up, but ultimately he decided to sell the tool to us and join our team, which was very cool. So that's already done. And can't tell you too many details about the internets, but basically it's something that can accept test cases from Misrael and run them on chain and then do motation based fussing and interpretive results. So I guess in the beginning this will be at the end of the part plan. And Maru is built by another colleague, get had partner, and that's esthetic source code analyzer, Abow in the first situation, and data also bud could analyzer, and this will also call all the low hanging fruit. Like you know, like style and that you should lock your compiler version and all that stuff that it's also important to know. Yeah, yeah, we interviewed for constant lasted the call and ask the question about whether or not, like if they're a net bike on analysis, could look to see what kind of what compiler was used along with the source code to see if there's any weird, weird issues along on side of that, or like backwards compatilly better issues or like Oh, if you change their compiler, it would fix this particular...

...issue of compiling from source code to by code and things like that. You look for your stuff like that. I think in that kids is just smallest senergly say to use the datist compiler version. It just if you have the source code. But if you've wanted a bite quodes, I guess it's not too easy to tell what's comparables used. I mean you could detect it with some pat and recognition or something, I guess. But that case I think it's not too important which compiler was used because if the bucks in the you will detect them anyway. But it would be the more part of the recommendations to say, okay, we found this book and it was probably because you used compiler x. So you can fix it by using one your compiler. It's mentioned it's. So it sounds to me, then, that the logical step, in the next logical step in this process is to control the compiler, meaning that you know you have the code Linter, static analyzer input fuzzing, but like at the end of the day, like if the solidity compiler has a problem, you know it's it's. It's the problem with the compiler. We don't need necessarily to use the default solidity compiler to make contracts. It's just you know it's. It's, you know, like SIGNAC. Basically, you know it builds bytecode and and the protections we spoke about earlier in the podcast could be baked in to some of these contracts. You know, yes, it would increase the cost of launching the contract, but you would have some security baked into the contract itself on the bytecode level. This is those kind of protections don't exist in the current solildity compiler. What kind of efforts would would you consider efforts for myth ral to contribute those kind of things to the solidity compiler or create your own either composed solidity compiler or language, take the Viper route where you have protections baked into the language itself. RECTI producing these smart contracts so that you can actually provide two users of your tool set a more robust, secure environment for their bike code to existence. Yeah, I think it's a very cool idea. I don't know if anybody working on a more secure solidity compiler, but we have one person on the team, Mario, who is working on a kinder called ELM, which is which comes with its own its own language, and the compiler is family verified and the language is also formerly verifiable. Is that the at functional programming language? Yes, yes, exactly, it's got exact yeah, it's really, really cool, and the only question is how you get people to actually adopt it, I guess, because the reason why everybody develops of the room is because it's easy. But if you have to deal with function languages and and proofs and form a verification, it's gets a bit less accessible. Right. Well, hold on, just watching biker. It doesn't matter what language you use, and I think that's something that a lot of initial developers don't initially. Now, for from a community standpoint, of course, make the face from a community standpoint yes, it has. There are there are, there are benefits to having something that the community can kind of understand and get behind. But you know, if solidity winds up being a problem, it's just a language. You know, vipers just the language which l is just the language. They all compiled to Byte code which runs on the virtual machine. You know, solidity isn't a theorem. And so, you know, to me it just seems like if there are you know, controlling the code environment itself, in the compiler environment, is advantageous to anybody who has a real pinnage for security in this particular field. It just seems like the logical extension what you're doing like next step, control the compiler. Yeah, yeah, it's a quil idea, definitely, but I think it's a little different challenged and what we are doing currently. I hear. Yeah, I have a I have a feeling like there's a there's the next trend in at least the etheroreum ecosystem or the majority of any any like successful smart contracting platforms, is going to be security. Researchers mean like it's it's they're becoming very aware that blockchain doesn't give security or blockness. It doesn't see. How do I say this? Security doesn't need blockchain. Blockchain need security and a lot of ways and...

...what and what we call in the previous years, what you said, like, you know, blockchain is more secure, blockchain is everything, and all these these guarantees that we mentioned only really really apply to a very small subset of what blockchain offers and the rest of the ecosystem around it is just wrought with security vulnerabilities. And and if we keep making it as inclusive and open source permissioners, as we say, lowering the barriers of entry to allow people look create smart contracts that are bad and put them on the network, it's just going to make this massive open space of of issues that security researchers are going to need to tackle and until we have better practices and protocols on how to do things or it becomes less like, I don't know, we change the narrative so that we maybe everyone shouldn't be making smart contracts and people who are good at it should be making them, as opposed to say, of course, anybody can do it, that's a good part, having the option to be able to do it, but not everyone should do it. Yeah, I think everybody who does smut complex thinks that he's would it. Yeah, but he's most most stupid. I suck at it, I mean that's why I don't really tell that. Know I'm bad at it, like I know that there's things that I'm missing because there's so many details in what actually gets out by the compiler that I don't feel equipped to know all those details. And anything that helps we know about them, you know, is awesome. I appreciate your work. So what's so? If you ever saved anybody's ass, and what's the biggest ass you saved? You mean you mean physically biggest ass, battest person? who say that's a part of the the invoice. Like what's like? You don't have this name any means, but like just what's the biggest bug you caught? That? That that just like, Oh God, if you didn't see this, you'd have been totally bound and they probably wouldn't cart it. If it work for you, Pooh, okay, let me think. Well, well, it's difficult to give it out because I'm not really sure about in the AH is that we had in recent audits. I mean there was some some nice there are some nice fins definitely really mean is you don't have to say who, you don't have to say you know. But the end, yeah, it's been like these are all open. Yeah, the code, the bike code one is produced, is open and on the box chain. Right. So, talk about the bug where we had in a recent project, actually a part where you could check the arbitrary bite code into the contract and execute it like only make delegate compsic here. Is it here command execution in the block chain? I'm not sure if it was delicate care or I think it was kind of a scripting system that was implemented and so you could in check these scripts and perform arbitrary actions in the context of this smot contract, something like that. It was the cool yeah. So, yeah, things getting more and more complex and people start doing things that, in my opinion, smart complex shouldn't what do. So I think the smart contracts should be really simple and should implement distance rules that you can only if you want to hear from the block chain. But they shouldn't be like complex APPs, wet or the lot. You should be in the the depth should be easy to reason about, like the smart contract should be very easy to reason about. What this function is supposed to be and and what like, very functional in that, like, if you give it input, gives this output and you understand why and what and like what scenarios around it, so that when you are auditing, because it any of to day an any type of audit has to be manual. Use tooling to facilitate manual auditing and if you can't reason about it, if it's too complex, that it just becomes a nightmare or impossible. Yeah, so there's only so many simple things in the L I think things get interesting when this complexity, but as far as you know, simple things, that's a limited subset of possible stuff. And one of the things we've talked about is cryptoconomic primitives. Do you feel like we have too many smart contracts out there? Do you feel like people are relying too heavily on smart contracts and auditing and security and can we can we water this down to some basic core principles that we know are correct and we know how they interact together? Then then what we're currently doing, which is to build, you know, is our contract platform for x, Y and Z. You know, you feel like we have to Manas our contracts, or can we really just build some basic crypt economic...

...privileges and build the world on that through. That's why you open and that's question the best kind. I think. What's doing is it? This is maybe not that ambitious, but you're trying to create a standard benchmarks and standard standard sets of underability classes for smart contracts. So we have a project called historium analyzer benchmarks, and this benchmarks we combine benchmarks from different authors like, for example, we have not so smart contracts from trailoff bits. You have our own set, was developed by researcher and then now editing more, and were trying to cover every possible type of vulnerability and to have microtests, but also really about contracts that implement this vulnerabilities. And then you also have an automated runner that's run security tools against this benchmarks and and esses whether the wing to bilities are detected or not. And so the first is part of this. The backing will now is kind to have a classification of things that you should not do and a cessification of what nobilities that exists, that everybody agrees on, and based on that you can do best practices and benchmarks and really create standards people should photo. I'm hoping that's a good portion of that, or at least the clear road of what that will look like will come from this upcoming security conference are going to in Berlin. And, like, I don't know, I I've always said that an expert is someone who knows what not to do, because you could never know everything, like the right way to do everything. It's more along the lines of, you know, the really big mistakes, of what not to do to avoid them and through this process of what you're trying to do, and what I think the entire I guess security community, avitherium or blockchain, is trying to do is create these protocols and standards and the kind of resource or repository of what not to do, making it easier to become an expert quicker. Yeah, okay, so I guess my next I noticed that you're building Myth Rol plus plus. What's so plus plus about it? Right, it's it does small stuff and it has sped up a build the analysis models. So I actually wanted to talk about some of the improvements that we're making to the engine recently. So one of the things that came up in the car with constant blast them, which I listened to before, was butter. Inter contract interactions are supported. So like, for example, if you have something like the Parodybug, where there was a delegate call to the inner valid function that depends on multiple contracts, we can detect it. So mithrill has a built in dynamic loader. It's called and if you run it against any contract on the chain, will automatically detect when other contracts are called and also download the dependencies and then also simulate the cause into that contract. And this was one of the first things we built in and that's pretty cool, I think. And it works against Wallet Babby as well. Cool. So you also mentioned some speed improvement. Kind of curious what you've done to make the process of auditing. I guess adding might be the analyzing smart contracts for security faster. Yeah, yeah, there's a lot, lot of things that you can do in that direction. Source we did a lot of refectoring of the car engines. We built in socalled search strategies. That's mystery. Can Use to determine what states are relevant and whatnot, and also pruning of states that are probably not interesting. So you just try to get this space of states to be inspected as small as possible and try to throw moll stuff that doesn't have to be analyzed. That's one thing. You another thing about that a little more and detail on on how that, how that works, how you do these these kind of these search states or well, one very simple thing you can do, for example, is this if you have a conditional jump and you discover that's all of the conditions can never be fulfilled and you just throw away that pass. But I...

...guess you can build that into a lot more complex things. That's where I have a master's students currently working on. So he's in charge of refactoring the core analysis stuff. His name is your run and we'll have a couple of other people that are more academically inclined than me join the team as well to work on that. Costing go ahead. It's a very scientific aspect of it, right. So there's a lot of research and papers and one of our one of my colleagues, so happy about the paper about state space reduction, so about exactly that problem. So you'll get his input as well. And Yeah, so far we haven't had big problems with runtime because in the original question of myth will, we were always analyzing onetime by the code of a single contract and just running one transaction against it and that usually finishes pretty fast, so, you know, a few seconds up to a few minutes. So it really hasn't been a pressing issue so far. But what we have now is called multi transactional analysis, and in this type of analysis you actually simulate subsequent transactions. So you look at one contract, you execute it symbolically, then you get all the possible ending states, or closing states, how we call them, and then from those states you continue with a second transaction. And by doing that, because every execution has multiple states, the state space grows exponentially. So then why you do? The larger it gets, and at the moment we can only reasonably do too. So, yeah, I also think about solutions for that, and that's where you get into a situation where you need a lot of computing power. Yeah, I can see that. That the pruning becoming quite difficult. I like any type of algorithm that would that would prune away, I guess, dead ends quickly to increase that search. Yeah, also has even this that, as you will even with that, you you just have a certain limited you can reach. We're talking a lot to constant at the moment. We are very good friends with us and also investigating ways if it was to be possible to customize misery in a way that it's that it's analysis can be distributed to some multiple vegetation notes, which would be pretty cool, because then then you could combine the best of both words. Also seeing. It's almost like this true bit of smart contract uding. Sorry that, yes, it's like a yeah, the true bit of some more contract guiding is you're using, you know, conversation, recurns eye. Maybe through constant you can get this type of analysis that takes maybe multiple hours or days, but this very thorough and really goes down like entransactions and runs on a lot of notes, which you cannot do with the stand alone miswill or the API, because it's just the computation power is limited. And this is kind of a it's kind of like I come from an a scientific computing background and this is a very this is very reminiscent of the way a lot of sciences have progressed as computational resources have gone and become much more available, and so what happens is you've had these relatively new branches of each science called like computational acts. Like I worked in computational chemistry where a lot of the frontloading work gets pushed onto computationally modern these things virtually so that you try and catch a lot of issues before you actually do it in real life, right, and it's the same thing we're happening here. We're we're trying to then have like a I guess, I I don't know, virtualization area of deploying these smart contracts and then trying to and trying to, you know, analyze what happens as you interact with them virtually more and more and more, which is computationally heavy, as you just as you're just outlined, and I think that's going to become possibly the future of how we do things that are will hold any type of relevant value. Is that the future that you see with regards to like, guess, smart contract security is having this very robust system that you can employ a spark contract to and it's saying, you know, based on a tremendous amount of computation, we can give you this percent guarantee that's safe. Yet that's supplicit Bitity, I think definitely. So it sounds to me like you're fighting something compiler develot people develop pilers that...

...have been fighting for since the impension of a compiler, the holding problem. You're fighting the halting problem. For those who don't know, the halting problem is a problem computer science where it is actually completely proven that in a turn complete system you cannot have one hundred percent verified execution of code, that you cannot write a program which checks to make sure your program does what what's the program is intended to do. To give a small example why this is the case, in what this you know, if you were to write such a program that takes code in as input and tells you whether or not it works one hundred percent on output, what happens if you take that same program and put it in itself into it? It would go into this infinite regress, and these kind of infinite regress situations occur all over computer science. It's not just that one case. It's a very common problem. Common case, anything dealing with recursion, which fortunately smart contracts don't deal with very often, would have that like immensely. Anything dealing with, you know that unbounded loops would have that, you know, immensely abound. The loops off pretty common, although not as in common and smart contracts. Anything that calls another program that then calls another program would call, would have this kind of issue as well. Now you've got to inter dependency. You can formally verify other programs that well, so so these the holding problem is a fundamental, cold problem. It's just a fact. It's a it's a like goodell and completeness. Is a fact that you're going to encounter these kind of you know, things that just not every system can handle and in a form of in a verification system and for analyzing code, you will never get a complete answer for anything. And what you seem to be fighting is that. That that exact halting problem, and ultimately the only solution that has any sort of like ability to solve that at the moment is the human mind, meaning that humans can spot problems that computers cannot, and that is why we don't get paid fifteen an hour. Yeah, so this leads me to my next my next thing for you. I noticed in your recent medium article where announcing them throw platform API, you spoke that you're working with giitcoint. We just had Kevinal walkeey on the show. I'm wondering how you see the kind of process pipeline working between you know static analysis, you know distributed analysis through things like quant stamp and then further bug hunts and bounties for auditing smart contracts and confidence levels being built as a result of that and reputation models being built around that. You see all these tools kind of chaining together and what kind of partnerships you working with actually make that and a process flow smooth in the system? and Are you the point of entry right? Bait for the for the first point you brought up about the hurting problem, I think we have a slight advantage that because because of gas, so it's the room has a block gast limit. So you can guarantee that if the block gast limit, if the gas used, goes up to the block gast limits, then execution will always terminate. That question is. The question is if you if how resource INS intensive is it is to get up to that point right, but I haven't made the calculations yet. So I hope that it's possible, maybe maybe even the that that is a unique selic point of using distributed competitution to do it and using a lot of computing power. And Yeah, that definitely has right. Actually forgot that that's whole purpose of guests is to fight that that exact problem. But the formal verification of these like these models, to know where the state is so they exist. This is a state machine that exists over multiple transactions. So even though a single transaction can have a, you know, a halting problem, if you send multiple transactions, you don't know how the state machine itself will update and whether or not that will be correct. Does that makes us that that's true, and we actually writing test cases for exactly this kind of situation. Like, for example, let's say you have an integer variable and you have a function that increases is but increases that variable by one with each call. So basically what you would have to do would be to send to to the poll of two hundred and fifty five, fifty six transactions and then...

...integer with overflow, right, and this kind of thing. So this kind of thing is kind of related to the halting problem, right, because you cannot seem, similate undimited transactions. You can never be a hundred percent sure that not eventually the integer overflow can happen. Yep, and so you go through all these and state conditions, and these and state conditions are based on predictions. If this is how we're going. But these are over multiple transactions. So the gas only solves one type of this ship, which is how much, you know, how much can a single transaction consume? But it which stops the whole network if you don't. But it doesn't secure a small smart contract itself, because these halting problem exist in multiple in over the course of the lifetime of a contract. That's true, if you see it like that. That's true. You cannot have a hundred percent you cannot have a hundred percent proof where. The good thing is that smart contracts use loops. I mean sometimes to do but not very often, which makes things a little bit easier for us. And mean you could, I guess, come up with a subset of solidity that you could use and, if you're here too, certain rules that would make the contract verifiable. And yet this is also something I've been thinking about a little bit of not too much. I think people are already working on that as well. So let's say you cannot call external contracts to prevent recression and you cannot have unbounded loops, etc. Etc. And then the contract can be verified, but the contract itself is an unbounded loop. Well, I guess it depends what you are very fine as well. So maybe there's certain properties that you can verify and can prove that they are impossible to happen, no matter how many iterations transactions are called. But that's probably a sub subset things, right. That's where you were talking about the end states and how how there can be trains that, you know, you only go two layers deep and it becomes an exponentially difficult problems to get through all possible states as our contract. Okay, wait, where that I think, way to kind of reward. That is that you have. You have a limited amount of end execution states from a single transaction, but a much, much, much larger space of in states for the contract itself, which can be gotten to through multiple transactions. Searching that ladder space, that that like where the actual contract can go to through multiple transactions, is a very difficult, exponentially growing transact, exponentially of growing problem with the number of transactions done, and what he's trying to do is create a system that allows you to search that space efficiency efficiently. Yes, and so I think it's really interesting that still, no matter matter how many tools we throw it this because of the halting problem. We will never get one hundred percent, and so ultimately, building in a human audit model is actually essential for security of your smart contract. That's the only automate to a limit, and that automation takes care of, I'd say, a solid ninety percent of the possible things. That's be pull in the stat out my ass. But you know, I saw a module a supermajority of of the the problems that that we can encounter with these smart contracts. But the end of the day you still need a human. But a human doesn't want to go through the process of doing these automatable things in order to look for that assume that they're done already. So what I'm asking is, and I did a really long roundabout way of getting to that point, is we're building an ecosystem. It's not just about mythral it's not just about distributed you know, throwat over the wall, I'll come back two days later with your answer. You know, systems like Quan stamp. It's not about it's not it's it's not just about bud bounties, because they don't want to look at all the details of every little thing. There's there's there's an ecosystem, a chain of security flow here that we're building in a very decentralized way, mean that mithroll takes care of their one, your static analyzers, your one particular part where you get the low hanging fruit right off the bat quickly. You know what's normal, you know what's abnormal, you know what's going to be causing a problem right off the bat. That you got quant stamp doing these state analysis on the talent trying to produce prediction as fine errors where there might be issues down the road. And then you've got the creative side, and I call it creative because securities a very creative field. People think of it that way, but to think like a hacker you have to think outside the box tremendously, and that's where the code auditors come in at the very tail end. And so we're building this...

...literal flow of like myth rol to quant stamp to get to get coin and they and these, you know, from static analyzer to state analysis to stay prediction analysis to to human auditing, and each one is essential. And I just wanted to pull out that everybody is part of this and that everybody has a role here and everybody is a niche and that the key that I'm looking for in this as a consumer of your products, is in. I think you've touched on this already. is in because of your partnerships with costume and with Geitcoin. I think you're going instruction as well. I was kind of hoping you can expound on this. Is How we facilitate that flow seamlessly to developers. Yeah, so it's a it's a it's a proposed partnership with constant. So I don't want to announce anything that's not not really yet signed or anything me to. Yeah, security tier say the security community is is talks very regularly and and collaborated each other, like informulate on a regular basis. Yeah, so, just having said that, I agree with a lot of what you said before, including the exact numbers. So I think that's ninety percent of stuff should be called with, should be caught with automatic tools, and auditors should really only have to look at the rest of the ten percent, because nobody wants to report old compiler versions and bugs that you can you can easily catch with static analysis. Right's just boring. So as an Oditor, you want to look at the business logic and want to really understand the system and what it's meant to do and find the really complex and awesome bugs. And so I come from a penetration, testing and audit background and have been mostly doing that in my whole life and in the last five years or so I discovered that I really want to ultimate everything away that can be ultimated away. And Yeah, that's the boring stuff, right, that's stuff that's that that you have to do every single time. And it's the same problem every single time and there's you know, it's like, Oh, this guy has this issue again, or let's just say, Oh, look, they've got w get on this machine. That's not secure. Blah, blah, blah. I like there's a lot of own install of your c compiler on this down this machine. We need to remove that for this type of secure securities. You know. Well, I think that the important part here is that as this space grows, it's going to become intractable for the small, relatively small, kicked security community to to get a lot done. If we're spending all of our time looking at, you know, trivial, trivial matters. They can be automated away, like the experts should be spending their time looking at that small ten percent or less of really, really, really hard problems and not all of their time looking at trivial, I mean I want say trivial, but things that can be automated away. That's the important part here. So I think the overall vision is that the tools for everyone and developers have the right tools. In the STEALC they have to write best practices to follow and the right code that's as secure as possible. So as what's what you see is an auditor in the end is already pretty solid and then you audit and then you find the last few business logic flaws and cryptoeconomic flaws and whatever a and those good fixed and then maybe it gets on the main mat and that gets verified validation notes and at diligency. Also working on a second product. It's called Hanvala. Not sure if you already heard about that. It's a token created registry for smart contracts, for smart contracts that are secure. So busically what you can do if you've done an audit for someone, you can and you're very confident that the contract is secure, you can apply for that registry and the contract will be listed along with your audit material and report and everything you have done, and other people can look at that and can challenge your submission. So basically there's a staking system and if it's proven that there's a vulnerability in the contract that was overlooked, then you lose your steak and the ideas to create a whole ecosystem or community of auditors that's all keep an eye on the contract, that's get deployeds and that vote on whether this contract should be considered secure or not. And once you e this registry, you will have a client side plugins, for example, for me, the mask that will just showed the very fight some bolted with set endeavors.

So we've got a very easy to see as an end use a if the contracts is considered secure, but it community of auditors an't. That is awesome. That is something I actually did I hear about that till just now. So that is something that I think is super cool. Having that verified, you know, sort of system as well, being kind of like the very sign of smart contracts has is definitely exactly. Yeah, yeah, that's really I'm glad somebody's doing that. And the other thing is that it doubles. It doubles it doubles it's use use case that. If so, they decided to publish their code or make a market place for the code so that, yeah, you can see the security Audi you can see what is past, you see how long it's been on the on the system you can actually license license to code to some degree, if there's some sort of way that you can have somebody doing, you know, the actual original source. So so they could do, you know, that's just the bike code, that you can gain access to the original source, you know, for fee, like, Oh yeah, I'll send this to you, you know, here's your license. That's send. It also goes into more of a package manager like system where, which is something I've been calling for a lot, and that we have a lot of these smart contracts doing this same thing and they're just minor tweaks here and there and building more. I feel like we need less smart contracts, not more on and you know, everybody just deploying the same smart contract over and over again is kind of problematic. I would rather have people reference another smart contract, maybe add a little bit of tweak to it and then that'll be their thing. You know. So more package manager like system for managing the code seems kind of essential to me. Yeah, so, and how? You know, this whole system lends to one other area of concern from business standpoint that has we brought up before in our episodes get rerous with get coin or constant, but the idea of ensuring smart contracts. Right now, anybody wants in the insurance space, you run your business on Theorem smart contracts, you are essentially they have no way of doing some sort of like proper risk analysis on the business itself. You know what I mean, like whoever invests in a particular you know, investors want to have some sort of assurance that the money that they're putting in, whether it be through ICO or traditional VC models have, is going to be protected once it's on chain. And at the moment there's there's no real good way of doing this risk analysis other than saying that everything that goes on the chain is risky. This this particulars particular tools enable people who ensure, who invest, to actually do the kind of actuary and pot work that's necessary to determine the risk of of of of a business that runs it's entire model off of a smart contract. And this could open up whole new avenues of funding. It could enable greater funding for particular projects through traditional models and it can enable businesses to have that insurance to know that Hey, yeah, oh, we just got a hundred eighty million dollar token hack. No worries, are insurance covered it. But very already, probably we had no shut we had no token hack to begin with. You know, already thinking like five steps I had. Now, what's that you're you're already thinking five steps. I had. Now, I think from very hand town, like you're starting from the TCR. I think a very great first use case for it would be to to add all kinds of verified libraries that are reusable. So you have a library listit in the TCI. You know that at that address, this this contract can be trusted and this secure and safe, and then people would start hopefully reusing those instead of deploying like copies of the same contract or over and over again. So that's could all be. Thinks that it naturally built on top of STIP TCI. I think, yeah, yeah, yeah, totally, and that's that's what I'm looking forward to, because we've got a lot of work to do in this industry. Should we do? And you know, it's not all about scaling. You know, obviously securities the fundamental, one of the more fundamental problems we're dealing with immediately. That's that's the ten foot in front of your face issue. I would say that scaling is the you know, one thousand, one thousand feet out and then, you know, we've got the issue of, you know, layer two and stuff like that,...

...like I don't even know where they are and like actually, integration with enterprise is probably another mile out, you know as far. But to have all this work you need to have the fundamental funding mechanisms, be able to be confident in the work that's being done and the traditional funding, because we're still on a feed out world and you know, the tradicial funding mechanisms are a little sketched about blockchain right now, and so I feel like you know some of them, not all. There's certain was like poly capital, which are all that, but you know, it's or probably chain. Sorry, it's important that we give them confidence. It's important for us. It's support for the ecosystem, is support for builders and what you're doing is just one of the best things you've be done right now. You are in the right place the right time. I think the people you're talking to are are, you know, the right people to talk to. I love everything in the throw is doing in a really looking forward to playing with the mythrall platform API. Now I know we're running late on the show a little bit, but I was thinking maybe you could talk a little bit about your token. I guess, how that would work and how and how licensing and and up the additional tools and features weed unlock with your token, what those kind of are and where you plan on that going. It's so the idea is tolf to have a license token. So if I look a evert an artic group by a Chunk Griffin is one of the initiators of R s nine hundred and forty eight, the recurring subscription subscription models, and he was fighting about non fungibusm non fungible licenses. So basically you represent licenses as assets on the chain that you can just send around and the exchangeable which I found pretty cool. And so we started talking to him and became opposity of doing a fungible license token and holding some amount of the token represents a license to access the API. So let's say the token probably going to be called myths, even though there's already another token that's called missed with an eye, which is, I'm not pretty annoying. But I think we're still going to get the trademark in dead because mystery was around earlier than the other project. So let's see and I hope it will be okay. So, assuming it's called myth, we will have a license contract. So you will need to own myth and you will have deposits some amount of that in the contract and then it will be your balance will be deduced based on how much you use the API and you can pick between between a daily model, monthly model and yearly model. It is different token prices, what the exact packages are and whether the pro packages that have more features and stuff. We haven't completely figured that out yet, but we still have, I think, half a year time to do that, because we want to finish the product first and really have everything tested and working and possibly already have people building tools and people using them. And then you're going to do the token and we will not have an ICO but instead we will sell them through so called market contract, and this contract allows you to mint tokens for eath and the East sent into the contracted Stata, so you can lay the sell back the tokens for eat and it's tell me price. You know, show me, don't tell me. You know you're going at first and then you put on your article. Built and Hoddle, buildld and hall. You know, that's that's great. I love that. This is a lot of the promising things and investments and I see has been basically off nothing more than a white paper and a power point. So, you know, I think it's I think it's great. Built the first yeah, thanks, but I think they really we really want to talking the plant took me in a cap careful way. So that's it's really realistic. Right. So, because a lot of tokens have like a market cap of a hundred million dollars without a product, but we want to have supplied. It kind of matches to use a base that we are expecting and the price the day would probably pay for the API. If you think that it is in the beginning, people would probably be willing to spend a dollar for using the API for a...

...day, which is one metric we be considered and we're probably we're hoping to get to maybe tenzero users or so by two thousand and twenty and then a lot more over the next five years. So the total supply is tailored to that. And the price is still very burn so depending on how many uses the are, the price can get higher, but it's kept, I think, at zero point. Zero five is so if it ever reaches a maximum price, because we have a huge user based and it will basically be and east stable coin, so to say, always be worse. And then our model completely switches to a revenue based model where people pay talkings and the Tokens go back to too, developers and team and the other important aspect is that we want to build. We want people to build mystery tools. We want we don't want to build everything else elves, and we will share revenues that comes through the API with those tool builders. Plus we will have like bounty pools and community pools and a capacitor that people can vote on where funds should be allocated in a lot of like community staff like that, so that people really feel incentivized and involved in the project. Yeah, so that's there's a lot of exciting things. Yeah, and I feel like we can probably go on for another half hour, but we are coming to a close. Or are there any other questions that that maybe we should have asked but but we didn't know? I thinking that you particularly are excited about in the space that maybe you'd like to name drop and mention. Well, I think that's most important to us right now. It's to build a community and to have people experiment with the API and start building tools, and we're doing that. Obviously you will also get talkings earlier. Well, you might get counties, etc. So that's also an incentive to join. So we have a discord community and you'll find the link to that on the website. So if you just ping us there, you you can briefew and what's going on and maybe see if there's any possible contribution that you could do, or maybe even still add more team members to the court. Team is alway still it's a still pretty much open. So the pig at the community gets, the better. Yeah, totally agree. This is a a community effort the whole way. That's one of the things I like about a theireum is how community driven it is and how it's attracting the best in the fields. And, you know, I feel humberous to even be, you know, allow to speak in front of you guys. So thank you can burnout for your work. I really appreciate it. Yeah, that was great. Thanks for coming on. I look forward to seeing you next week. Yeah, you are going to be in burden and I will be I'll be there for all of the festivities and for us to watching week. Okay, cool, and see you there.

In-Stream Audio Search

NEW

Search across all episodes within this podcast

Episodes (127)