Hashing It Out
Hashing It Out

Episode 20 · 4 years ago

Hashing It Out #20: Quantstamp - Kacper Bak

ABOUT THIS EPISODE

In this episode, we interview Kacper Bak, Research Engineer at Quanstamp. Quantstamp has created a system for auditing smart contracts automatically, testing for known exploits. They verify the more common attack vectors, and provide a report to the user about the potential threat. We go into how their product is built, the future of their product, and how it can benefit and drive future innovation.

Links: – smart contract security alliancesecureth communityquantstamp website

Entering work. Welcome to hashing it out, a podcast where we talked to the tech innovators behind blocked in 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. Hello, Hello, Hello, episode twenty hashing it out. Today, as always, my cohost Colin is with me. Say Hello Colin. Look going and our guest today is Casper from quant stamp. Casper, why don't you give us a brief introduction as to who you are, how you got in the space, what Quan stamp is and what you're solving? Hi, this is Casper. I'm a senior research engineer work at Kuan Stemp here I work on the protocol or performing decentralized autists for smart contracts. I also help with doing in depth audits of smart contrasts, which means that sizes randed tools. We also manually review the code. Before that that was work. It month works. There's a the company that makes Matt Love and Sing Link. I did in my PhD. So in software engineering I have a lot of background, a lot of expertise in software verifications for modeling and I've been interested in Crypto for many years but I never really got into it professionally. A year ago I pulled the trigger because my former colleagues from the University of Warreloo started working on constant and I want them to be part of this team. It's interesting. I friends that work in the Quind of computing section of a University of Waterloo. Small world, yeah, and I got friends all over cryptospace. So we probably know a few people. I also used to work, I thought about working for Mathematica. So I'm very like my first language, I think was, was Mathematica, if you want to call that a large right, and then I moved into other type of stuff in my previous dissertation type work. But let's let's start with like what is decentralized smart contract auto. So so the problem we are building wants to decentralize other thing in the sense that we like to have a network of computers which run our note software and then the notes there they run analyzers that do certain checks on smart contracts. Right now we are focusing on the pretty fined properties. So you can for example, check for reentrancy or for transaction ordering dependency and so on. So the the idea is that if you have a decentralized network, basically you eliminate a single point of failure of doing an audit. Now, when we are talking about these audits or assessments, they are not exactly the same as doing manual code review, because if you check for a pretty fine set of properties, then obviously you can end up with false positives. Right, so something maybe an issue, but it doesn't mean that it is an issue in the context that's your smart contract runs. And the reason is that often, besides having just your contract, you have other contracts that that you're interacting with. and well, by doing purely automated audits for pretty fine property, you don't have all the we don't have all the context, and that's why the state of the art right now is that automated audits are good in the since that they give you a quicker view of the code, but they are not perfect. Our goal is to improve them, that to eliminate false positives and also to have a network that can run audits that can take long time to compute because under knee the wrong silvers and it...

...could you know, and basically they're live in solving great difficult moth about code problems. That's that's the theory, all right, and that's that's a I gotta live I think, but I phone, I'm trying to recapture that. It's you're using this. This platform is a tool set to give you a high level view of things that everyone typically can't like that things that are easy to do with in the smart conturing to aren't tracting world and showing you that you know, Oh, here's a problem here, look into it further as well as I and then you can. Of course, there is no automated tooling that does everything in terms of security. We don't have a push to secure button across the security community or in any aspect, whether it be decentralization world or or sub centralized world, and what you're doing is providing twolling for people to go in and look. It's been more time looking at things that are going to be issues versus wondering whether or not they have simple things that happen to everybody that have maybe decent way to put it. Yeah, this correct and I also I like one thing you just mentioned sound like having push button verification tools. So actually what we are building right now is push button in the sense that we have these prett defined properties that we check for. Now, you know, there is there is a difference between the verification and validation. So, like we can do the checks where the properties. Now there is a the results, the question where the smart contract does exactly what the developer intended it to do, which is the validation step. And unfortunately this part cannot be automated unless you have a formal specification of your requirements and so on. So, to be very precise, here we are doing a verification for the pretty fine properties that the can tell you that all there are potential issues with this smart contract. Does that mean you're looking at the bike code? Are you looking at the like the solidity version of the bike code? Yeah, so the tools underneath. They work with the Byte Code. However, source code is also useful because if you work with the bike Cole you want to report back your findings to the developer and the developer doesn't work with the Byte Code. There are like they work with the source code. So you want to point to a specific line or lines of code where the issue maybe features you're right, they do. They do work with the bite they do analyze the byte code. Does it matter? So do you? So? Because you're working with a bike code, you don't really care what version of compiler they're using. So particular exploit exists in, you know, a particular version of SULC you know, it compiles this incorrect this vulnerability into the into the bike code. Will you be able to make recommendations based off of that? Would you even be able to detect something like that? Well, so it's so compiler does have dusk of an impact and also ym right, because you still need to be compatible with certain versions, like so, like any breaking change at the Byte Co level is definitely not desirable when you do and analysis. Okay, and so can you can you repeat your re question now? Yeah, certain certain vulnerabilities exist in compilers as a result of the sulcie compiler having compiling to bite code, which is got a you know, the way it compiles enables a vulnerability, and so the future version would fix that vulnerability. So you might want to be able to kind of like testing to make sure your old contracts are still working in the new. The new you know, souls eat take art susceptible to the vulnerability that was in the context of the the compiler which they were posted onto the blockchain with something sense. I see what you were saying. Yes, so basically now you're a concern with issues in the compilers themselves. So we are not doing with verification of compilers, we are just dealing with with the byte code itself. So if there is an issue with the compiler, it may slip through, you know, but it's no different than wandering about issues with Vm. There may be issues, you know, and the implementation versus the assumptions that were specified and the white paper or whatnot. Yeah, but this is my real if do you give recommendations on what caused the issue? Sayferen so, say, for instance, there's that you you find a problem within the bike code when you're doing your analysis or using or using tool set to do the analysis, and if you were able to see what created that byte code would be...

...a the source code and the compiler used to then compile it down into bye code. Can you give recommendations based on things you see from your analysis to how actually got to buy code? So right now we are not doing that. I would lat I would love to see that. Now, when you talk about recommendations, do you mean something like quick fixes in, for example, eclipse? You know where you have your source code and then you know the twin can detect some error in the source code and then provide a recommendation how to fix it. I think is this. I think colins question was more onlines like say I find a problem with the bike coode and I see that you're use this source code file in this version of SALC to the compiled on the Bi Code. You say, Oh, this version has this particular issue, I shouldn't switch to something else or move up to about update this and you won't have that type of issue in your more based on what that compiler used to do. If you have you have that kind of resolution, or is it something that you can even see from what you do? I see so cross. Yeah, and, to be honest, I never considered this idea. However, I know that there are some issues that are detected by the tooling and these issues were relevant in the old versions and in the current versions they are not relevant. But as of now we simply don't report some of the issues that are no longer relevant. But I do like this recommendation that that you just mentioned, that you know, may makes think you need a base yeah, sorry, you need a base one. You may basically say this is where cost stamp is starting. You know, these with the known rotability prior to this version of SALCY. We're starting on this base line and then recommendations can't happen till after that baseline. So that's totally fine. Is if it's a feature in the road map. That makes perfect sense to me. It's just something that I know as a developer. Like if a new if a votability is spotted in in Sulcie version, versionally on now point two four. Is that right? Whatever? Uh Huh, yeah, it's twenty four. Yeah. So like, let's say point twenty five comes out and introduces the vulnerability. Your baselines at twenty four. The voterability spotted in twenty five. It's passion twenty six. So many compiles on twenty five and then releases and then or you can just twenty four has a voterability that we haven't spotted yet and then I would like to know that, hey, this can put this code that I've already deployed to the network is potentially vulnerable as a result of the compiler that I chose to use and and that that to me, is extremely useful information to getting alert on and, you know, and to have somebody's monitoring. That would be like a great service for me personally, you know. But I understand the need for a baseline on that. So yeah, no, I was just kind of curious if that's that's where you guys are were aheaded, because this is the thing about these smart contracts is that they exist forever. Once they're in the blockchain, people start interacting with them forever, and if you use an unknown vulnerability in any particular piece of software which generates the bike code for these smart contracts and you deploy it and people start using it, that vulnerability exists forever. So you need to find a way to migrate or get or or get your you know, your contracts patch somehow, which I'm not really sure how you do right now. I mean certain certain paradigms of development can enable that, but not full fully enable it. So it's it's just an interesting problem that I'm constantly struggling with is that when you have a regular software development life cycle, if you if you've posted a like windows, does this all the time. Linux does it all the time, even Mac does it. They if there's a vulnerability in your software, you can post a patch, but with these smart contracts as the real simple way of doing that. And a lot of these tools are common. So if a if a problem exists on the tool set itself, there's no solid way to even recognize that issue and some clever little hacker out there could go out there right as script which detects that issue and then exploit your contracts. So the kind of tools I'm really looking for maintenance level tools or kind of like upkeep tools or kind of like alerting tools, and the verification tools once so that they want to when I get it on board and I know that it's working at this baseline on this compiler and it goes to the network and it's in this state, and then from then forward I want to know if that particular state I've uploaded has any sort of issue that at that that I should be aware of as a decentralized application developer. And and this is this is the kind of stuff that a lot of people...

...are kind of struggling with. I feel like this is the kind of errors that we're seeing our you know, known bugs that people don't know that we're in their code and, you know, business level people can't necessarily one hundred percent even depend on one particular developer. Our organizations into all this stuff. So having that hub of information, that hub that sets a baseline for your work that's been posted, is super useful. So I was kind of seeing what your road map was in that direction. With any yeah, so this is great. Let me give you a bit of context, like where we are at right now. So what you are talking about is, if we call it, a monitoring service. So we just started working on that. And but this, this piece of work was separated from our protocol because, when comes to our procol you, development, the main use case we are focusing on right now is pre predeployment analysis of the contract. So this is this is one thing. Now the monitoring service is anotter is another thing. So we even started monitoring some of the CON trucks for a certain properties, like, for example, that the supply is more or as stable, or that that somebody doesn't meant, you know, like a huge number of tolkins. But overall, yeah, I do like your a suggestion a lot and I think it is an important use case that we should look more into and Ridge. You know, I think it will bridge this monitoring service with within network or, if you prefer this, this pre deployment analysis though, on their life contract and a lot of what Colin just referred to is a lot of things that they guess Security Community of these centralized technology or trying to figure out and build. Like a part of that endeavor is, like, I know quanstant is also part of this. I am to the a security or secure a community and we're having a kind of a workshop meeting get together in Berlin before f Berlin, of trying to come together with, you know, resources, tools, practices and protocols of what is security in this space, because it's kind of different in terms of what security is across like traditional architecture and the at how we approach these things. What we need to look for, the types of tooling that Colin just referred to and what you use right now is is all necessary as the as the I guess, security expert in the space makes himself useful, and I think that's just a time like a sign of the times and that it's legit it like the space has become legitimate enough where security people are like, Oh shit, we need to figure out how to make sure we maintain this wealth and people have good practices on both deploying things correctly, which is what you're working on, looking at the analysis of how things are deployed from the smart contract level and then all the tooling above that to make sure that that information coming for the blockchain to the actual end user is secure, and then, you know, monitoring services to make sure that, as we upgrade things in terms of smart cracks or whatever, we do that in a good way or we even know that we need to do it in the first place. And so there's like a there's a whole landscape of things that call on just basically explain decenting on what he'd like to see as a developer, and you're like what constamp is is a part of that, of like a very important part of that, of making sure that you have a high level of confidence when you put something out there in the first place. Yeah, yeah, I think I agree with that. So we want to provide tools for developers, but, you know, tools are important, but I don't than that. What is also important our best practices right and that's where, if you guys are from there, with small contract security allies. So recently, to say, it was Manchul or in constant. We published on the website some practices, and they are not low level practices that tell you, you know, how to organize functions and so on, but they most they mostly talk about the whole process of developing a smart contract and focusing on security from the beginning. And the reason why it is so is that, you know, as we are doing my your orders to learn more about the code and to improve our tooling, we often get we get requestional like one or two days before deployment, to somebody comes to us with a big smart contract and like Hey, guys, can you added this,...

...because give out tomorrow. Yeah, you know, this is not the right way of thinking about security. So I think that you know this. This this whole this whole collection of tools, processes, best practices. This is what we need to to have secure smart contract. But then, like you mentioned, we also need some services to monitor post deployment health of the smart contract and maybe even insurance, you know, because even if the contract was checked, maybe there are still some some bogs, and you know, you can deal with it through the insurance where you bed that the contract is safe or you bet it is unsafe to some degree and you're willing to stake your own funds on this. Oh Wow, now that's a really interesting concept. You just perked my ears up with that because, I mean, this applies. This is like one of the one of the things I kind of straight out of radical markets, that book that we keep kind of like talking about every once in a while. Our pauser has this great book called radical markets. He talks about different ways of handling a more decentralized, less central planning sort of way of dealing with things, and insurance is one of the one of the more centralized, central planning kind of things that out that a monolithically. You know, it would be pretty awesome if people could pay for insurance to guarantee the basically have auditors literally bet on the security of their contracts. Exactly. They would pay those auditors from an escrow a regular amount as long as it lives through the lifetime that the auditor bets that it would be correct. I bet this contract will be fine forever. For I will put a stake on it for twelve months. I'll put a stake on it for six months, you know, like that. Can you multiple auditors doing this, and that enables like proactive auditing communities, which could be a market place for smart contract auditing based around this insurance model, and they can take up, they could take up, you know, you know, a certain budget of insurance capital that is held in escrow until it's untils used up and then they add that to me is just extremely interesting and it really ties in a little bit more with the get get coined bounty system we just had on last this week we've released in that it's sort of a mechanism for assuring quality through through markets and for having features. There's just to have features develop, but this is a bounty for Quality Assurance, which is just super interesting. Like, I love that you brought that up. That's fantastic idea. Hell, I'd start getting into auditing if that really case. Well, yeah, and I like that. But if they could stick their own skin in the game so they actually lose their own bed if there is a bug like that, that in synthivizes the the insurance backward. So you have bilateral skin in the game on this. That's fantastic. Like it incynthivizes both sides of the equation and yeah, I'd be super cool. Yeah, I think that's neat. So I guess my question next is like how do you differentiate quanstant from things like mythroll? So my throw was a tool. My throll is not a network. My thrill is a tool that typically, I mean as of now, you run locally. The difference between Metro and our network is that constant would like to be open to multiple tools. Like technically, basically, we take the tools and they are round and they are run in separate Docca containers and then the notes of recollects the APP from the tool out. Now the thing is that I don't know to what degree use a methrill or orient a, but typically these tools, if you analyze a simple contract, differentish within seconds. However, if you have a complex contract, it may take minutes or maybe tens of minutes, or maybe longer, of course, depending on the hardware you're running the tool on. So we having the network, we'd like to provide computational resources to do these analysis efficiently for a compass smart contract, because our hypothesis is that complexity of smart contracts will be growing with time. Like in a similar way, as we've seen that with, you know, any other software. You know, the more time passes, the more complex the software becomes. What, in terms of defulie valid network are is each note independently doing its own sort of work and can people just join us...

...that work right? So I can tell you how it is as of now, because right now we are finishing our second iteration of the network. We started a beginning of the year. So in the current iteration we will have whitelisted notes that are assumed to be non malicious. Now, in the next iteration that will start around September, would like to precisely look into the issue you just brought up because in that essentialized network, of course you cannot trust the notes. Does the whole point of the centralization and there are multiple approaches to making sure that the the report is is correct, and it was not. It was not change on purpose or manipulated on purpose. So we will be looking into multiple approaches and you know a lot of them. They have certain there are certain Tradeos two or to all of these approaches. Some of the approaches I like is something similar to true, but not sure if you're familiar with it. Yeah, we can review them and I was actually going to Suggesta if you got to do it eat centralized and we looked at the true bit. So that's great. Yeah, the true it is it's pretty cool as a protocol because you need only one note to provide a good result, because then you allow every other note to challenge this result and then prove on chain who is right and and who is wrong. So you know, at least theoretically, it's I think it's very cool. Of course, true bu it is needs a little bit more research to figure out the incentive structure and also verification of the results on chain is not exact efficient, and the rest of the assumptions about, you know, being deterministic and so on. I think it is a step in the right direction. We definitely, definitely want to look more into it, but there are also out approaches. So as of today we are not, you know, we haven't picked any single approach. We will see, will reach research them and we'll see which one we pick. But the idea is to have, you know, these distant, distributed the centralized computations and then making sure that the developer or our user will get will get the correct report. So so I got something going on sorry, you know I ambitious on me. Yeah, so I a part of scaling. As of right now, I'm assuming that your your network is relegated to a single smart contract. Is that correct? So right now we have a bunch of nodes and we have our own smart contract on the etherom network. And I mean I mean like when you're when you're doing an analysis, you're you're analyzing a single smart contract, a single set of by code. Oh, yes, yes, if that's what yes, so we part of complexity in the space, especially if we're looking into the far future, is going to be a series of smart contracts that interact with each other. Do you have any type of roadmap that can start to handle that type of thing? Because I know the tooling, automated tooling for this type of stuff is obviously works better if it's self contained within a single set of bye code. You can you can look at that type of thing better. But as we scale out, especially in terms of like modularity practices and keeping things cinct and simple, the complexity or the vulnerabilities may exist in the connections between smart contracts that talk to each other. You have a plan on trying to like deal with that? Attacked tax surface to be more to even asking even more succinct than that. Would it have caught the parity bug for the parody, multi signature, mult whatever, that they're smart contract like? That's the that's that's an example of what core he's talking about. So existing twin can find can detay both bugs, the contentialed bug of Party. They could the same one that's having with parody. Now when it comes to analyze multiple smart contracts, we can. Let's be study more precise here, because it we definitely want to deal with this problem. But, as everything we do, we want to deal in iterations. So first you can imagine sound like having a travel project with which has a much of smart contracts. You have all the code available. So I do hope we can. We can address this one and the you know, in the next iteration. And another thing that can that is also related to an asymunk was smart contract contracts, is that, let's say you have your travel project, but you may be interacting with some outter contracts that are already deployed on the chain and not so probably towards what...

...what you're saying. So you work up on my end. Did you say you would? You it does that now or you're working towards it? No, we are. We we will be working towards it in the iteration that will start in September. Yeah, because a lot of these a lot of these contracts that were hit by the parody multi signature. But we're dependent on a library that was deployed as a singleton libraries, or technically singletons, on the on the on the network already. So you know, there's a couple of the couple things here. You need to check that contract if it hasn't already been checked, and if it's already been checked, you need to learn them. Hey, this contract that we know is bad is being used in your code, and that kind of stuff is, like, also extremely useful as things become more complex. So I'm glad you're working in that direction, because that's that's one of the things we need. Yeah, yeah, I and you know, there's this whole business of dealing with dependencies and some days perhaps you want to avoid recomputing. You know, the same analysis and you know and optimizing. You know there is there is still a lot of work to do there, but it's definitely something that we do want to address. Obviously, two things that kind of help that success is. I mean, first off, people need to understand that these tools are available, see in sort of education that one, that they need to use them, and then that they're available to use. And then you have like the usability aspect of like, how difficult is it to incorporate these types of things into my workflow so that I can get stuff done and I'm not spending all of my time trying to get things done? When ever doing anything, you have like at how easy it is to use this, and then what type of things are you're doing in terms of, like to educate people that they need to use things like this? I agree with you. I think that's USABILITY is one of them major concerns. Like, okay, first of all, I'm not sure whether there is enough education and where developers are familiar with these tools. Second thing, basically, if you want to use these tools, what do you do? You go to get help. Then you need to clone the repost door, you have to compile it, we have to build it. Of course, things don't work out, does the reality, because some libraries whatever. But let's say you build it, go let's say you can even run it, and then you want to analyze your travel sweet sweet. Well, turns out that you cannot analyze one contract that has some dependencies. Maybe you need to run the flattner that flattens the source code into one file, and then you can. You can analyze it. Okay, that's great. So then let's see you finally do the analysis. Let's say it finishes on time, some reasonable and then you get the report. You look at the report and you also need to know how to interpret the results. You need to know that a lot of a lot of the the potential bugs or vulnerabilities that are reported, they are really false positives. And that's does a reality right now because these tools, they don't make assumptions about your environment or the other contracts that you're interacting with. They are they always assume the worst. So, for example, often you see some like reentrancy or as assertion failure with regard with the relation to the safe math library, which is pretty standard. So you need to know how to interpret the results and also relate them to the code. Also, what you get from these tools right now is not exactly related to your source code. That may be shifted by eighteen or twelve lines whatever. So usability is definitely a concern because a lot of these tools they were created by experts and, of course, authors of these tools. They know all the quirks and all the potential issues, so they know how to how to use them. But if you're, let's say you are a newcomer to smart contracts solidity, I believe that the experience is pretty frustrating. So we know it's a company what we do right now. So so we do talk about the tools, but we also created this demo version where we have web interface to that was running one of the tools, specifically Oriente, and you would get the results on the on the web page and the report would tell you what the issue is, would provide a description and and severity. So that was, you know, our first attempt to slightly improve usability of these of these tools, because the only thing you had to do was to actually submit them and and work for the result. I believe,...

I'm not hundred percent sure, but I think that the smart security alliance standards either. They already mentioned, you like, some of the tools, maybe not explicitly by name, but I think they mentioned that it is a good practice to run these tools or if not, then we should incorporate a at barograph like that. Yeah, I'm definitely, definitely be working on that stuff in the ECOMING workshop. To see you like what is currently like the, I guess, the Golden Standard across the entire community to how to do this type of stuff and then how to put it in a spot or to bule can access it and learn from it so that they can. You can start with best practices. is supposed to like, learning shitty practices, having fun and then, after unlearn all the bad things you learned. To get and get to a point where you can actually deploy a smart contract on made network and not worry about it's funds getting stolen. Is a better route. In order to do that, you need to educate people on the best way to do it from the start, as opposed to like, let's make it token, all right, don't ever use that token. Let's make a better token now, right, yeah, let's you know what. So let me add a little bit to to what you just said. So I would say that's running these tools and understanding their results requires certain expertise, maybe some rigor, familiarity press with software engineering, and maybe verification, like something that goes beyond will she typically do when you develop software is when you develop Seltwat you. Maybe you have a spect, you write the code and you have tests. I'm does the regular let's a web to point no workful. And there are a lot of people, I think that who came from that background to the Smart Constructs. There are also a lot of new people who may be they don't have even software engineering background. Maybe they don't know that much about programming. And all these developers they attempt to create tokens and believe or not, we do get a request where we get a code of the smart contract and even that Co has nothing to do with even the reasonable practices in regular software engineering. So, you know, like when I see a code like that, I don't even think that this person would ever imagine the tools like orient a or mithrill exist and they can do some analysis. So it's definitely you know, this part, I think, can be addressed by education. But if some just comes to this new domain, I don't think that they are even aware of these tools and I don't think that they could effectively use them. Well, that's kind of the part of I don't know, permissionless decentralization. People are there would be people who try to do things that they never should. But projects that are seriously I see like a will hire the people in requisite auditing to get that that's like commensurate with the amount of value they're trying to put into these things. And let me I I hope so. Like projects like that, we saw, you know, code that has nothing to do with even the reasonable practices. Oh Man, that's that's that's the scary part is because it's still, I guess, maybe a sign of times. It's the wild west and people are excited about doing something and they think if they deployed to contract on the on the on the main net, that it's secure because they deploy a contract on this ultrasecure platform, and that's by no means the case. But like, so, who's the demographic of these tools? Is that the auditors that are trying to make sure people are doing things appropriately? Is it the is that the you know, smart contract evs working for these ICOS and decentralized companies that are in charge of deploying these things? Is it? Who Do we go after to educate? Do we try and educate the masses so that people are like, Hey, I want to try some stuff on atherium. I want to learn how to build a token. They get the tools to build at least like decent levels practice contracts, like I'm trying to figure out, because you can't reach everybody, but we don't want to be so seclusive that we only reach the select few and then we charge a shitload of money to render our services. Like who do we go after and how do we do it? So now you're really quick, like one of the things I'm envisioning, and I know that I'm sorry to one of the things I'm envisioning when to hear this stuff, is that even in web two, point of practices, there are security experts, there are people who who specifically deal with like database security, who should specifically deal with network security. And then web three, point, oh, we're just adding people who are specifically deal with smart contract and decentralization, decentralized network security, and to me it seems like this is like a marriage made in heaven for...

...something like a bounty network where your we can literally I'm done with my smart contracts, I throw it over the wall over to your network. I don't care how long it takes. I let it run over night, but I put out I automatically allocate bounty assets to this and I could wake up in the morning with all of my problems with proposed solutions and which I could then integrate back into my software tools, like I feel like. I feel like the target audience for security is always everyone, in that everyone needs to be aware of it, but there will only be so many experts and, you know, interpreting all of the security rules all the time is just UN reasonable expectation of inefficient use of internal company resources when developing something, especially something that's handling highly secure financial transactions, and people current financial systems have experts in financial transaction security, code standards, you know, legal aspects of it, PCI compliance like these are all things that there are people who specifically get certified for that, and we have millions, if not potentially billions, of dollars flowing through these smart contracts. I think it's it's going to have to go to the way where there are experts in the field. And now your tool is awesome in my mind, because I am not an expert in the field and I'm a decentralized I'm a product developer. I develop products and you know, I can I can understand like ninety percent of the security vulnerabilities that exist, but that last ten percents the one that always gets you right. So it'll be great for me to just code up the ninety ninety percent and throw it over the wall and get the ten percent back. Yeah, so I totally agree with you. Of course, we are not here to solve all of the problems of the world. Our mission is to pre the roof bar of the standards what developers can get. Yeah, let's not be naive and I think that we alsolve all the problems, because it's not going to happen. And now getting back to bug bounties, it is something that we are looking into, as there are other projects that are looking into that as well, but right now it is this on the parking lot for us because, you know, our resources are limited. And now going back to Corey's question about the target audience. So right now, right now, I think that target audience of all of these tools are our auditors or companies that do assessment, like security assessments. So I think this is how it is right now. When the USABILITY gets improved, disability easy views and perhaps there is better education, I do hope that some of these tools, specifically push button verification tools, will find their way into the developers workflow. Now, when I when I mean push button verification tools, I mean the tools were you just a men the code and you get a report. You don't have to specify anything. I kind of said this as like as like an extension to something like truffle or embark versus like, you know, you make your contracts and the dad through the bills, flash deployment process. It checks its right, right exactly, and again you get you get some result. It's not perfect, it's better than what we have right now. If you want to go one step further, you can start atating your code with certain invariance or poverties that you'd like to check and so on. You know, it's all great in theory. We've seen that in regular software engineering, you know, being discussable literature for decades, but in practice, developers, they don't specify these variants and properties. First of all, it is difficult, so you need to have certain expertise to because often these specifications are mathematical in their nature. Also, they don't play very well with code evolution. So whenever you evolved the code, you also have to change the properties. Well, nice thing and maybe hope for a smart contracts is that, fortunately, they are not meant to evolve very often. Like the current workflow is that you write a smart contract, you deploy and it should be running. So, you know, I would love developers to write these, these properties to check and environs, but I'm skeptical about widespread adoption of these techniques. I think that for these techniques still the audit team, businesses and an expert will be the the target...

...audience. So this makes sense, absolutely, perfect sense, absolutely, and it really primes a lot with a lot of the things we've been discussing on this program in the past. One of the things we discussed in the program in the past is a language called packed which, by removing that's Goodna right, yeses, by removing it recursion and infinite loops, you're able to bake formal verification into the language itself. Do you see quant stamp supporting other languages or even implementing their own kind of like language which policy for some of the stuff that they check, or do you still see it as being mostly just for Theorem by by, you know, by code? How do you see the future of this going, as more languages are developing which challenge solidities dominance. Yeah, so I'm hoping. You mentioned you mentioned pack and Canya. I was really impressed. I spoke with them a few times. was really impressed with with their work and I really like their approach that in that specific project they take security seriously. So they started to think about it from from the beginning. For it is by restricting the language and then providing some support for verification. I think this is definitely the right way to go. Another nice thing is that they require you to publish the code, the source code, not the Byte Code, on the blockchain. Is that anybody can can see what what your software is doing. Getting back to your question, we definitely want to support Marko block chains. As of now, we are working with it thrim because this is where most of the businesses this were first contract. Our tools, to sound degree, abstract away right now and will abstract the way the different block chains and execution and environments and analysis. So definitely when. I don't know, in the future, but I cannot be more specific right now because, as as you know, there are so many different blockchain and distributiful ledger projects it's hard to say which one is worth putting effort into, because it's hard to say which one will be successful. And it's or a business. You know, you're not a charity, so that's fortunately not yeah, so one of the things I keep bringing up is the need for more package manager like system in the way that we deal with with these code, this code. So you know, I shouldn't have to wonder where the what packages are being used to even build the the code itself, and it seems to be like really redundant to post the same, virtually the same bite code every time on to the blockchain when you know it's really the same code. It's just, Hey, this is my I seeo and using these exact copy of this smart contract and a lot of people are just posting that smart contract over and over and over again, and it's it's shame to me because the blockchain is permanent storage and the grows forever. So yeah, that's nothing. That also kind of interested me about pact is that it's getting closer to that kind of vision that I have, like a reference to a package manager right that the full bike code itself. One other thing that I think is interesting that could actually benefit from a network like yours at some point. Is the idea of letting the network compile your code for you. In other words, you set the standard on want compilers being used, you set the standard on what on what is an acceptable thing to be posted, and then that compilation. All you do is post the source code, like maybe an IPFs reference to the source code, and then the network picks that up, does the compilation for you, along with the security assessment, bundles those things together and post out on the chain. I mean not even post on the chain, which just gives it, gives it to you. So you could post that on the chain right now. I mean eventually, I would like to rather just see that that it's post on the chain and the network does the compiling, because I don't see any point in like, having my own internal compiler other than for testing purposes, when really I just want a reference to my code and a reference to the bike code, if the bike codes necessary for the VM. So everybody has the same thing, but that can all be stored as a reference in one ipfs file and so like the artifact for a contract could essentially be part of the same the same one and the same as the actual contract code, as the actual bike code. These are...

...just things I'm envisioning that would improve your system if we could kind of move the talk in the direction of how, like the EVM is handled or you Wah, some goes on in the future, and how, if you mean treats code differently. But yeah, sorry, so be going to twitter. No, this is a good remark and I think it's good that you know, you mentioned packed earlier because from what they remember, they pose the actual code and the code is not compiled. It is interpreted whenever you execute the contract. So I think that it plays very well with what you just mentioned. I think it's Gezy to like the source cards cheezepped under the sort under the block chain. I would like to okay, so if the next iteration of your network will be permissionless, I am assuming that involves some type of token, because you need to incentivize people to act with good behavior amongst the network so that and then you can need to have checks, a verifications that someone acted poorly. How does that work? Is there a token? Why do you need it? So on so forth. Right, so we do have a token even now in the permission network. The the audit notes. They will be rewarded with tokens and the developers who submit the smart contract to analyze, they submit the payment. Each note can set up their own minimum payment that they were willing to accept. Also, there is a certain time out for analysis because we don't want to get the net ord dost. So even right now developers basically paid the the other notes for doing the hard work of doing the computations and producing their reports. So now that's the function of the token. If we go into opening up the network, to making it permission less, one of the ideas we are considering is having a staking mechanism for the audit knows and perhaps very fire notes if we if we have them, so that nobody is really incentivized to do malicious things to the network, but they are incentivized to do correct computations and are in some rewards. The specifics of that will be we want to figure out in the in the next iteration or two. Cool. So is there anything that we should have asked at this point that you you're really excited about with your project, that we might have missed? Well, sorry, I'm install. Interesting that is about is that we are launching this we call it Beta net network. We are launching it really like with every week right sweet finishing, and first want to open up the network for our universe steep partners and then, of course, depending how the network operates, we would love to open up to to outer actors. So the next rule still be permissioned, but we will try to incorporate as many notes as as we can. Very cool, awesome. How to people reach you in terms of like, say, they want to learn more. So they want to like to participate in this if they're if they're if you know, have the right skill set to do so. Like, where do they? Where do they go? Certainly there is a so we do have a website. And then I think that's most of the interaction with the community happens through telegram. I believe I'm guilty of not participating enough, but we have other people like jared who are very active on on the telegram chats and that's probably the best will the people in the network. All right, great. So, listeners, if you enjoyed this, click the link with the like button, not the link. You already click the link as you're listening. Now, share it, tell your friends, tell your family, tell your dog. Subscribe to us on spotify, itunes, whatever we're you can find us both in the Bitcoin podcast network fire hose, which has all the shows in the Bitcoin podcast network as well as our own, so you can just want to listen us. You can subscribe to that. We get all the great content from the Bitcoin podcast subscribe to that. I guess that's it. You can find me a core Patty on twitter, Cor Petty, and Colin on twitter at Colin Cuche. That's COLLN cus CEE. Thanks, thanks, thank you very nice. Thank you.

In-Stream Audio Search

NEW

Search across all episodes within this podcast

Episodes (127)