Hashing It Out
Hashing It Out

Episode 17 · 4 years ago

Hashing It Out #17: Modular - Chris Brown & Will Dias

ABOUT THIS EPISODE

We talk to Modular's Chris Brown and Will Dias about their work building libraries for the Ethereum community. These guys are doing some very amazing work directed at financial institutions. Using their libraries, developers can build applications secure in the vetting process the Modular group implements. We talk about their approach of using Solidity libraries rather than smart contract templates, how dapp developers can and should integrate these libraries into their code, and what security concerns are addressed using their system.

And doing 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 everyone, episode sixteen of Hashing it out. I guess it's sixteen. The Sixteen Colin sounds right now. This is seventeen. Is it really moving to fast? All right, well, episode seventeen of hashing it out. Today we're here with modular. We have we have Chris, the CEO of modular, and will ds, the CTEO. Why don't you guys start by telling us how you got into the space and then give us a high level bird's eye view of what modular is? Yeah, thanks for the invite. It's Chris Fir CEO of modular. I got into a searing of in two thousand and fifteen after reading the world street curve, a article around the frontier release. So I've got several different paths in my background. Software developer by trade, dabbled in finance for a little while that my MBA, and when etherium came out after, you know, the Bitcoin imaturing became really interesting. The intersection of all the different fields where you have financing, computer science and just business in general, being able to change the way that we coordinate on a decentralized network and bringing transactions closer together. It was really interesting, and so that really drew me in and well ahead will yep. So all over one. Well, that's to be here today and I'm the CDEO and modular and I have a background in scene tech. Best backgrounding feed tech, where I worked with Centralized Ledger as solutions before movie recently to the dark side. So watching technology to work with blotching around a year ago. That's when I enjoin modular and decide to to work together with Chris and Josh to be good things are priced solutions using the watching all right, so let's let's start by figuring out, like what is modular? Why do you why does it exists? What problem does it stand us all? So modular started last year on the heels of some of the security vulnerabilities that were exploited with Wallet's and Josh and I started putting together the set of smart contract libraries that we intended on, you know, being shared across community because we have this, you know, unique ability on atherium to share immutable code. Right. So when you talk about doing things like, you know, issuing arc twenty tokens, doing, you know, some low level operations, whether it be in math or handling things like that, you know, it's code that you can create and post one time and then everybody can use...

...and then ideally you get enough users, enough eyeballs on it, that that any sort of vulnerability would have been considered at some point and then it can become a hardened set of code that that can be used in more robust way. And so that's where we started. We did some services this last year, you know, built the you know, different ICO requests, security audits, things like that, and then we quickly moved into product development and so right now we're in the process of building infrastructure for financial institutions to help them get on blockchain. You know, it's very fragmented, the technology is new and a lot of people are trying out lots of different things and it's pretty scary for a lot of the more mature institutions that have been using technology, you know, for you know traditional technology for decades now and it's hard for them to grasp what's going on here. And then also with all the newness and attack possible attack vectors, is just a lot of opportunity to help them find their way into into the field and get them established. So that's that's what we're looking to do. Cool. So who are you actually working with, if you can disclose that? So we don't have anybody we can discoose right now. We've our biggest players right now, our banks. Banks are very cautiously interested. They they move slow and we know that. So there's a lot of proof of concepts going on right now and they've dabbled and different ideas and it's going to take some time. Hopefully next year we can get them on board to actually, you know, the way to start is basically at the basic use case of watching with that. Everybody's been using it for to this point and that's that's just transactions with cryptocurrency. There's just a lot of demand. If you look at just the exchanges right now, there's just a lot of retail demands to simply hold these things, you know, and a lot of people are speculating them and things like that, and so the meaningful will use of applications where we're actually putting utility tokens to work and things like that. We're still a little bit out there, but people want to own these currencies for whatever reason and I feel like we should be agnostic to those reasons. If people want it and and businesses can offer it, then we should just help connect those two and then, you know, as a technology matures is more inclusions come out, then we can we can be ready to handle those things at that time. So really, right now it's just baby steps, proof of concepts, trying to get them comfortable as holding the currency and when they hold the currency, offer it to the customers and then when the customers have a currency, and then, you know, we start seeing applications that are going to use tokens across the board, whether it be, you know, on a them, whether it be within these potential bridges coming out with polkadon and cosmos. There's just a lot of opportunity that's going to be available about three to five years and we need to be ready for it when it comes right. And it's complicated to get those financial institutions to to be on board to write the next generation of as. More contrast that every rundown chain, when they don't even have like a good because of they and management solution for it at assets yeat like at an enterprise level. Right.

So it's, like Chris said, it's it's a lot of stuff that's we need to developing art to get it and mainstream. Yeah, definitely, and it's not just financial institutions that could benefit from this. Regulators also have a huge problem. So government itself wants to be able to track and also know that the security is adhering to some level of standard. Those standards are not yet written. So it's really interesting that you guys are taken on this early task of basically trying to develop a set of base level just wallet's really like, you know, just anything that you can you can do to sort of, you know, audit and secure the the actual secure and then audit actually the the assets as they're flowing through the network. What kind of second tier applications are also looking to develop with regard to this, I can't just entirely be smart contracts. Are you looking at building other tools to enable these institutions to grow their asset portfolio and asset tracking and security auditing capabilities. Yeah, so, man, there's just a lot going on in that perspect just in general community. So, you know, one of the things with developing in in this ecosystem is it's just there's so many things that need to be done that you can really kind of get lost in the sauce and like and then if you spread yourself too thin and nothing really gets done efficiently. So for modular this is our focus and there's just a lot of other things that we know other people going to take on. You know, if you if you just look at the at the procoll itself, you know, moving into the new concessus algorithms and then you know, getting watching to see stay channels, which are what the potential is for investments, aren't like not just speculating on buying selling the currencies, but also staking them and getting returns from that. Then you've got identity on the blockchain. Is a big deal because, and that goes back to the regulator aspect, is, you know, as much as as much as we have, you know, the anonymity part of blockchain. We know that, you know, in the mainstream and a meaningful way like regulators always going to have a say in the way that people are operating and make sure that, you know, there's not illicit activity taking place. And so identity is going to be a huge thing. It's not something that we're taking on, but we know that there's going to be a lot of people taking on. As far as tools, though, the tools right now are just a lot of community efforts. Right now there's a group that that's getting put together. It's east security and as a lot of big players in that. We've got trailer bits, we've got secure F which came out of East Denver. We've got consensus, Zeppelin's on their people from the foundation are on there, and it's really like a new organized effort to start putting together lists of currently available tools, like things like meth rol, you know, you're slitty coverage tool, and then figuring out what tools we still need to help developers develop better credit code and a secure and efficient way, and and then kind of organizing a what with bench parks we need to meet with these tools. So as far as modulars concern or major, major part of the community, and then we're dependent on a lot of other teams helping put...

...things in place that will be needed without us having to like try and do it all, if that makes sense right. Like and, as Chris said, like focus is a problem because when you try to get from a tob you like there's a missing, a lot of infrastruction stuff that you have to build from the grown up yourself. And also when when you when you were working with with those things, you also time is also in an issue because you usually, if you're building the centralized application or something around those lines, you're going to take like three times longer than if you were building like a regular application, because everything that you need to take into account, everything that you need to build when you're going to work on it. Like we like a few months ago, we were building, just an example. We were build a simple demo where you would like move money from one Ismar contracted the other, some sort of modzig contract working as an account between organization and the user, and we wanted to abstract the gas layer to the user. Like what if the user went went to move funds without paying for gas at what if the CO organization pace for the guests? And we have to be a like all this code and in background to be able to to to make it at work. It's something that's supposed to be semple as. That right. You always like we wanted to to complete a task, but we have to complete all those other amoults, that is, small tests in the middle in order to get it done, and that the things like three times the time to the we're expecting to begin with. I'm kind of curious as to I mean, you're definitely right about the fact that building the centralized applications is inherently more difficult, because I don't think the there's a lot of examples to pull from, and that's part of what I gather from reading your online material. What you're trying to do is create more robust examples for people to build from, and that's part of like looking at your github right now, you have your deploy libraries in which people can use. Can you give us a few examples of what libraries you have built and plan to built that people can use the immediately take advantage of? Because that's that's a great way to push the entire community forward, is to give people working examples of modular pieces of code. I think a lot of people refer to something like Cryptoeconomic Primitives, like little little relationships that are tied under smart contracts that are well written and deployed. So and have examples of usable examples that people can pull from it add to their their software immediately. What do you what? You guys don't preface out a little bit with what? So our audience comes from a wide, wide background. We are more technical podcast, but libraries are not often used in some of the applications that I'm seeing, and so maybe maybe you can also talk a little bit about your approach and why you chose to go that route. Yeah, it's interesting that they're aren't more youse. I mean that was the first thing that stood out for me when I started development on a ferium was right. I mean when you look at just, you know, like look at something like NPM, like packages are big deal and software development so that you don't have to reinvent the wheel, and as thereum just gives us a natural ability to write code once and use it everywhere and it's and it's like a native it's a native thing to this technology. So it's not like you have to like, you know, put together you know Hashes to verify the package and make sure that you're using what was intended like you can look at the source code of something that's deployed and verify it and know that that that codes right there at that address for the rest of time, as far as the theorems concerned. Right. So the other side of it,...

...though, is that there are a lot of unique requirements. So to like give of the paint, you know, everything with a broad struck is difficult. So I say that before I say like one of our libraries, we got a Herc twenty token library that's been it's written, it's got all the functions of a new arc twenty token. It's compiled and deployed at an address and that library is there and can be linked to by anybody and we've got it on on rink be and we've got it on maininet and and if you look at the token contract, example, that's packaged with that token library, you can see like the contract itself is very minimal. It's almost just like an interface that that just calls the functions out of the library. There's no reason that you have to actually write out the logic for a basically arc twenty token ever again, because that that library is deployed and it's on chain and you can link to it in your code. And so if you think about that and you think about you know, and then you kind of part lay that into some of the other other libraries. The reason why we did that so like another popular repo, of course, is Zeppelin's Repo, and the one thing I set out to me when I introduced, when I was introduced to that Repo, was it's it was like it's a lot of contracts, a lot of contract templests and it's a lot of copy and pasting. Right. There's no there was no like definitive source of a deployed source code that you could link to, and so that's where our focus was. Our focus was not to like Redo an entire repot like Zepplin's, because they've got a lot of different contracts. Ours is like not as varied, but they're all deployed on the network. So good documentation and then employment and and so they we got a crowd cell library on there for like this is like a basic crowd cell that we put together last year, and that's another thing. So, like, if you just want to do a basic croud cell where you've taken in an ether and sending out tokens, you actually don't have to write that because there's a library that handles all the functions. You just write the contract that links to it and the logics on chain and its soun chain forever. So yeah, yeah, it is interesting to me that they're in that will. Libraries aren't as widely used, but again, I think a lot of it has to do with the fact that it's new. There's a lot of unique requirements, a lot of different ways to handle things, tokens, you know, even though your c twenty s spelled out like a lot of people have gotten away from the basic implementation. But likewise I think it's people in trouble right. So then we had that one security issue. I forget how long ago, but you know there was an arc twenty token that was overflowing and it hadn't been caught. And there's all these tokens that have been issued using this particular function. I can't remember the details, but yeah, so, you know, I think libraries are natural for thereum. I think we should be used more. And then also then, you know, you get into the question of are they secure. You know, what if you have a bug in the library and affects all the contracts and that's a very real point, right. Yeah, so that's what happened to parody, right, like their library got destroyed and you know, but that goes back to well, if there's no fibe balls on it, like if if you look at our token library right now, is is. That's not going to change. So if you look at it and you say this looks good, then it's good. It's good forever, like as long as you don't have anything to customize on top of that, if you just want to put up basic token out there, that's good forever. You don't have to worry about it. And and the thing with open sources like not a lot of people,...

...like more people use than actually build it, right. So to actually get participation and get people to actually look at and and to contribute and to make meaningful changes and meaningful pull requests and things like that, I mean that's tough. I mean you'd be surprised, I think. I think that's one of the things that we got out of, like out of the Wallet Fiascos last years. Like this code is out for everybody and thus the people are using it. Billions of dollars are in it, right, but like how many people actually took the time to look at the source cut. Obviously not very amity because you know it had those vulnerability. So yeah, you know you do have to depend on the code, but if you put anything in production, if you put anything on main that you have to depend on that code. So it can be something that's been sitting there for a while or it could be something that you build and you just have that much confidence in your team. You know, it just depends. Yeah, and just some hook on. I like every everyone is welcome to contribute to this, to this libraries. They are all avaiable on good hub. A module wars good and that's actually accedent. The Way to get start actually like to understand like what we're trying to accomplish with each library we are building. We have like like contract specific for like could help her functions, for for a raise for strings and stuff like that. So it's a good way to learn a bit of me more if you were getting it started in to eat your arena. That's actually the way that I met Chris and John last year. I, like I was using one of their libraries in a demo project to that I was doing. I saw opportunity to make something better for kids submit a poor request and then we start the conversation and we are working together since then. So everyone is welcome to contribute to that. So yeah, go ahead, Chris pros going to say they definitely need some inter wiving. Cary, you know, I talked about like actual contributions are scarce. You know, that's our repo and I don't think I've I've been able to get to it in about a month. You know, it's stuff keeping up an open source stuff without external help, just because at some point we got to we got to pull in resources and make money and you know, stone that out there. Great. So this is actually this actually brings up a point that's kind of been I'm not really sure if there's a solution. Is Problem. Maybe you guys know it, but contract upgradeability is, I believe, an important part of what any robust, decentralized application should kind of consider when implementing libraries. It makes it kind of difficult to upgrade those libraries. So you made the comparison between MPM and, I don't know, see pan or just APP get on Linux. You know, these are all kind of like package management, you know, module management systems, and there is an analogous relationship there. But how would I upgrade my library in the events that, say, and exploit was found or a new type of exploit was found, that your contract is subple to and you would have no reason to even know that it was there. How can you upgrade your libraries and how could I, as a contract owner, be assured that I'll always have the most recent version? and Or, let's say, a standard? Changes like standards should be upgradable, meaning that something, some new functionality could be required in a standard and I want to implement that functionality. I really want to upgrade my library and my smart contract to adapt to that library. How would you suggest one go about that with the current way that you've built things? Yeah, so there's upgradability as...

...a big deal. It's tough, you know. I think I think that's one of the Zeppelin's like primary models, to solid a upgradeability issue with Zos, where they're, you know, allowing token holders to vote on which contract use. And you need something like that, because if I just create a proxy contract into a library so that I can upgrade that library, I can shift, I can shift the underlying codebase at any time, right so that the centralization there disappears. So you have to be certain that the logic that you link to is going to be available and I'm not going to be able to shift the logic underneath it. And so, you know, there's other implementations that we talked about. We're possibly having, like orangain testing contracts. That would require certain things to be that like if you have these inputs and you have these outputs and you have certain milestones in between, having some sort of arranting mechanism that could validate that. If I did move the code bad based underneath that, it's still met all the requirements and it wasn't doing anything that was unexpected. But that's that's really it's good in theory right, but it's not something that I think is practical anytime soon until well designed and well bought out, which I think. I think the approach of just allowing token holders to determine which which contracts use is the best way to go at this point. But the other thing you have to think about is is upgradeability in general. I think we've gotten used to in web development, you know, constant upgrades, like we're constantly changing things and were constantly, you know, upgrading a software on a daily basis. You know, older or software and more traditional kind of desktop software, the code didn't get upgraded as much. It was very purposeful, you know, when you move from version, I mean you know, way back, you know, you were buying just new software just to upgrade. So I think, I think blotching software smart contracts, I think they're going to be more in the traditional software cadence where we're not necessarily upgrading the code on a on a weekly basis or even a monthly basis. I feel like, especially with the vulnerabilities that are possible when you have unhoudity code deployed, somebody is if you're if you you are successful what you're doing in a lot of people are using it and somebody exploits that. We know that that puts lots of people at risk, a lots of free churches at risk, and so you have to have like dependable source code that that isn't going to be easily changed and exploited. So you get these audits, I think when you get those autostone which are not cheap right. So I mean you're talking, you know, anywhere from fifty two two hundred thousand dollars to get autost done smart contracts when you put that expense in and that you know. You know I find that audit as soon as you change any bit of that Code Right. So once you put that on chain, which you've made that experience and you put it on chain, I think that sits there for a while. I'm not sure we upgrade as often as we're used to with web applications and in that sense the other great ability of the library isn't as isn't really as central to the focus. The focus is on dependability and and getting it right in the context it as it's now. And then if we have an upgrade in six months and twelve months, then we do support the new code. And then if you're going to produce a new software see that uses as a new library, then you also have to deploy a new code. Anyway. I feel like upgrading libraries if if your software, which is also immutable, is going to take advantage of new library functionality, then that also has to be upgraded as is, which means you have to link to the new address anyway. So that's that's my general take at this...

...point on on that problem. So that actually brings up another point. Security. Insurance. First off, I think this is really relevant to bring up right now. I want to congratulate Corey, Dr Corey Betty on starting a new position. He just got hired by status as their security engineer. So that's cory. Appreciate that. Okay, pretty pretty decently set up like so. Yeah, so security is a big role in these companies, not just companies, but just anybody dabbling, even dabbling in building the centralized applications. What's what is your process for ensuring your the security of your libraries as you've built them? What tools are you you using? What things are you looking for? Do you have a checklist that you go through? How do we know what what tests you're actually running off of this? How can we independently verify your libraries to the standards that you've outlined, as well as bring up issues that you may not have noticed? Obviously, probably get hub is the best way to report and issue that we noticed. But what is your standard for for deploying a contract? How do you how do you know it's done? Yeah, good question. It's difficult with open source REEPO, because it's not something that we pulled resources in from and so, you know, getting professional audits and things like that. Is, you know, it's not feasible for us to like pay for a major audit every time we release an update to the library. So there's, you know, several from the organization. Early on it was just Josh and I. You know, we just built the code and we posted it. We put the in M t license disclosure on air. Right, you know, use this, use that, you know, risking. Sure you look at it and as we can need and you're comfortable with it. With that said, when we let so, for instance, when we built a crowd cell contract and we use our library, we did get that audit done. We also got a lout of done on the interactive ICR that we built with Robbie and Jason and Vitalit last year, which was a new procoll that that we were looking to introduce the community and and we actually got a consensus. And is that one audit on those contracts and Quante stamp also Quane Stampo. It is those so on that particular set, which included like the interactive iceo contracts and then the base contracts underneath it, including the math one and the gray one. So those all to get audited. But again, you know, as soon as we upgrade a contracts, so we have the ICO specifically isolated, you know, so that you know which which commit was audited. But yeah, I mean in order to keep them up to day. I mean like cystical language itself, right. So they're all written in the solidity and the flid it these probably, I think it's it's some. It's like four versions ahead of where our last update was. So and then that gets into the whole layers, right. So, like source code is just one layer you've got. You've got to have faith in the in the underlying protocol of codes. You got to have faith and compiler facility. Those are things that you know, when we write a...

...contract, we write, we write it and we get the source goal out of it. But there's not. That's not saying that there's not a vulnerability. And the compiler facility itself right with the new upgrade. So yeah, yeah, it's our process is, you know, we develop it, we put code coverage on it. So we use truffles testing suite. We usedlidity coverage. We get, I think all of them are at a hundred percent coverage. I think I see one and we got up at ninety some percent coverage, but covers is just one part of it. The other part of it is like considering all the attack vectors and what the surface is. I feel like, you know, it's like something I can hit the stake. Coverage. You you give yourself a lower bound, meaning we've tested all the lines of code here and they at least do this minimum thing of what we wanted to do. He still don't really get a the if you do the proper threat analysis and still have an upper bound that you have to consider. So like, even if this code meets the bottom bound of bare minimum of what it needs to do, you haven't really explored, like, all the things that it should not be able to do and you still got to put that upper bound on the on the testing so that there's not unintended consequences that you didn't see that are capable above and beyond what the code should do. So we consider all those things. We did. You know, we have our checklist for when we do others audits for others, and so we got through that process and make sure that we're comfortable enough to put it on main neet. But that's as far as it goes. It's for the open source code. It's completely internal. We have yet to put one of these financial institutions on the net yet, but we will certainly go through several hot it's before we do. I mean that I feel like a portion of this, and I have a feeling you're agree with me based on the name of your company, is keeping things modular. So you want to minimize the amount of code or functionality you put in a single thing that you deploy so that you can have reasonable bounds that you just specified. You don't want massive, Monolithic, monolithic codes that do multiple types of things, because that in introduces a lot of problems that are difficult to test for, or potential problems they are difficult to test for. How do you is that kind of the the way you see proper software development in decitualized the applications, and I'm assuming so based on the name of your company. If so, like, how do you how do you try and define what is enough for a package that could be deployed? Yeah, yeah, absolutely, so, yeah, just get going a little bit, adding what Christmas saying like, everyone knows that elbamate, that tests are important on your code and your application. However, as we are dealing with with the blockchaining applications. It's ten times more important to think about all the edge cases and try to cover everything before I release, because every release there's this cost and effort involved to get people to to use this upgraded version. So if you catch something after it release, it's it's a way better to catch it before right and and going by the modular analogy of thing. That's absolutely right. And it's not only the way that we that we build a more contrast, but it is also the way that we are building the infrastructure that will deal make the connection between the client and and and the chain. So we believe that a lot of things that we that we...

...can solve we can solve by adding a layer between the client and the blockchain and not having this direct connection, because that's the whole premise. That's how we're going to solve scalability with the channels and and stuff like that. So fortunately I cannot go like a very deep into the technical explinations on this, but yeah, like more like Mosulre that you go, then then the better, because you can tackle each problem individually and the separate pieces. Sorry, Christ, you can go out. What to say. Can Add on, like will that are microservice. Part of our architecture for the option system is microservices models. The Sif Creator, you know, definitely helps with the keeping things very modular, keeping the logic purposeful with its boundaries and what it'should be doing, and so that that way it's a lot, a lot easier to maintain. Yeah, makes a lot of sense. In your I assume you're going to be building integration tools. I think that's what I gather from this, but I just want to clarify that you you feel so it's important that once I take your library, I implement it, that I can run the same tests, or similar tests or selected tests whatever, that you're running on my application and sure that my implementation of your library is to stuff. Yeah, definitely. So one of the things that I haven't finished doing with our with our Library Pos right now we've got the etherium libraries repo, which has all the libraries in it, and then, I don't know if you noticed, like we have like different individual repose with each like for the different libraries individually, and so we kind of secuted into goes out into their own package and with the idea that they're very self contained packages. So they have their own test suite on it and then you don't have to like download the entire their libraries to use one of them. And then it's also in preparation with EAS PMISPM has been working hard to come out with version two. I don't know if you guys have try to use it last year, but V one was very sketchy and so we got away from it. But E'spm, Piper Mariam and his team, truffle, they've been working really hard on get inversion two out. So that should be coming out shortly. So when I get those libraries have to go on that. Yeah, so like for our audience, what what libraries have you produced and what is what is in your pipeline? So Up to this point we have a mask library which protects overflow and underfloil. It's it's just like Zeppelin safe mass or implementation. A little bit different in that it doesn't throw immediately if you overflow on our flow. It's almost like and go where you have the return and are variable, so that we don't make the assumption that you immediately want to throws you overflow on flow, like maybe you want to continue and the logic. So we give you the air return and then you do with it with you. Well, if it's true and you want to throw to do that, if you want continue on your something else, you can do that. We've got in a ray handler which will basically handle a rays that you might may have in storage countring. It will sort it, it will get the index of value to thing like that. We've got the token library which as of right now it is for you arc twenty. I think we had a PR for pulling in the seven hundred and twenty one standard in the pulling that out. We've got three...

...different crowd cell libraries for three different types of crowd cells. Just one for the basic crowd sound, where's either in token out. We've got the cap crowd sew where you can camp addresses for a certain amount of tokens, and then the interactive crowd cell that we put out earlier this year, and I think I'm missing another one, and then, if someone will know, I think that's it. I think it cover all of them, but most of them, and like who if people go to get interested on the interactive crowd sale. Contrary, there's also a paper that was published or just or do this year, with a more details about the the purpose and implementation and that's going to read it all. It's great. All I can make sure I'll make it this on the show notes for our listeners. How do you make money? How do you how do you feel the company? Because it's like a lot of what you're saying and doing is open source work that is notoriously not fruitful, which is why a lot of people build tokens so that they can incentivized open source development. How are you guys, making money if you're not doing that? So we start off boots crapping, just providing services and stuff like that. It we've got a couple of backers now and so we're really just that's one of the reasons why I mentioned earlier, you know, our focus is kind of come off the the Rebo for a little bit because we're really trying to get this product done so that we can get some solid partners with some of these financial institutions and and either get them locked in proof of concepts or maybe even putting this putting some of our stuff into production. So yeah, right now we're not making money. I don't think a lot of us are really. I mean he's a funded off tokens or your you've got a solid group of backers that that are helping you move along, but yeah, no revenue yet. Yeah, I think it's important to make that distinction. Not because I think the reason I think it's important to make that distinction is because it's really, really crucial work that people do these types of things. But there it's no touristsly difficult to get paid for doing open source work. The the experience that comes from doing it will end up being fruitful in terms of consulting when all these people need these things to work and then people that know how to make them work. But that has to be bootstrap somehow and like I hope maybe even listeners can reach out and help in any way that they can, if it's not through code, code pools. You know, I mean, Yep, if sure, there's another initiative that Robbie Pitt did with the foundation is called Eighth Prize. I think they have a site eth prize dot io or EA Prize Dot Org. They've got two initiatives for the package manager and, I want to say a debugger, and they actually have some really serious money back in those initiatives, bounties basically, and I know if status has their bounty program too. So yeah, yeah, there's there are some ways to contribute and make some money. How do you was going to say, I've just completely lost my train thought. I got one. Guys using these libraries. That increases gas cost. How do you? What do you feel like the cost per transaction impact of using your libraries versus having an eight code is, and how can users mitigate that if they feel as it's going to be kind of an overall the ship? So delegated...

...core is ten thous I believe. And so that's your increase and then you know it, it's very fractro home fair, very small as far as what that cost is in the big scheme. And it's definitely constants analysis thing. You can pull code in your contract libraries if the library functions are internal function calls, and then that just folds the bike code right into your bike code. So you don't actually have to make a delegate call. It just makes your contract formager. So the plant costs are higher. So and that's and that's the difference. You know, if you're using the logic and libraries a you know that it's not logic that you had to write the it's well I mean it's basically out there on the chain, and so you reduce the amount of code that you have in your contracts, your plant costs is lower, but your transaction costs are higher. And then it's the other way around if you if you pulled by code into your contract. So, yeah, the best way to do it, if you don't want the extra delegate calls to pull the by code in your contract by making the functions internal right to the yeah, and we try to keep like a fair trade off between the centiality and because, like, if like you, functionally helps a little bit, but it costs a lot of gas and Y may not worth it to have a new code. Basically, you you are better off doing doing yourself, but we try to keep a tradeoff that is like a reasonable amount of guests for the for the benefits of using delabrries. I remember what I had to say when I have add had to ask. First off, I think that's very key thing to keep in mind when doing any type of blockchain development is the tradeoffs with money and functionality. There is inherent costs everything that you do and it's not necessarily worth it to add a lot of things to low cost functions or even implement them at all. So like making design decisions based on the actual need to have things on chain or what needs to go on chain is incredibly important. If it's going on chain, it should probably be highly secure, which requires things like safe math. So you should be paying those costs. Otherwise maybe to think about putting it on chain in the first place. Right, and makes you remember from the computer science classes that everything has a cost, right, everything has makes it you think about development on a different way because when you when you when develop like conventional oblcation, like even like wab applications, for example. Today, a lot of things I could take for granted. You think it's free, I can make this little of you here because it's free, like it doesn't cost a lot to me. When when you move through the blockchain thing, a long that you you have to remember those low let of things of how we're going to implement something and keep like a good trade off, because everything, everything, the line of color were writing, it's it's money. Basically. That's your standing. It's like on execution. So it makes your think about like computer science and a lot of different way than conficional opplications. Yeah, it actually like insidiviuses good coding practice, whereas it does, I mean actually it literally does like. It doesn't hope it does, it literally does like. Is a poor example because you wouldn't want to do this on chain calculation. But you know, if you want to sort in array, you know you've got a myriad of sorting algorithms to pick from and you know a quick sort is going to be literally cheaper than a bubble sort. So you would actually save actual money,...

...not just for yourself, before your users, if you are, if you are, you know, being a better coder. I mean right. There's an aspect of it. May Be the difference between usable and unusable in terms of cost benefit analysis. If you if you have four implementations which are if it is incredibly important, like you could build something that does awesome things, but if it costs too much, if the cost to do that thing is too expensive for the thing itself, then no one's ever going to use it, which means it can't ever gain traction and you can't earn money from it or whatever, or like be a successful company. So you need to understand the efficiency of the things that you do and smart contracts just to make sure that it can be used in the first place. Right, yea and and Nique like community to think out. So like there's the cost of the code execution, but as also the cost, what of scalability as well? Right, like, in a way that I don't know if you guys remember, I believe was early last you early two thousand and seventeen, that it was like a contrary. There was a raffle on here and a lot of people started to participate on I and then when they called the withdrawal function to everything get remember the yeah, it's too expensive to fit a single block. So you could actually exactly so slowly, like all those people, like like the people that the road the country, didn't think that there was sup possibility to have like thousands of people participate and then you had to run this, this, this for loop and then run this logic for each one of them on the same call. It was basically impossible. So it can cut. It can be very, very costly to don't write a good code and actually think about all this. This problems. It's a great example. I remember what I wanted to say earlier, and that was a you have your Github a lot of a theium functionality or durium libraries and you plan to do other libraries. But and in what? Like? What? What other platforms or even considering contributing to? What's worth it in your opinion? So it is a good question. We've had discussions about moving horizonally across chains. You know, for us there's really there's two networks that have been around for more than a year now and that's Bitcoin and etherium. So you have other things like hashcraft that are proposed, you have other chains that might yeah, I mean they're all proposed. Are All proposed for Beta releases and I think, I think once, once these things are more established, we were out, but we much more focused on on getting what's what's viable now into people's hands then moving out and trying to move across platforms right now. So right now the plan, the pipeline is is we don't have anything slated for for other platforms just yet. That's good to know. There's this mentality that I think it's one of those one of those schools, monetary schools that kids go to these days, in the ideology behind the schooling is makes the kid an expert at something, so we has something to relate to everything else too, and you kind of take that idea to what you're doing now. It's kind of make really, really, really good libraries for the best smart contracting system that currently exists, and when the opportunity arises to make things for for newer ones, you'll have really good repository to pull from to do that quickly, as opposed to kind of wetting your your feet or cutting your teeth on everything all at once.

Yeah, and I'm not sure, I'm not sure we have to worry about, you know, other engines. You know, I think, especially when you look at projects like Cosmos and Polka Dot, my theory is that you know, you know, we end up with an Internet of blockchains and and then your different platforms are just different engines and so it's not whether or not, like another newer platform overtakes the theorium. I think, you know, just like we have different operating systems, we're going to have different blockchain engines. I don't think the etherium engines going to go anywhere. And then when other chains come out and they have their own you know, by code and their own engine, then and usually be a developer on that platform. Then then you can do that. I think I think it's going to. I think the market is going to go much more in that direction, where you don't we're we're used to having like one monster chain, because we had bitcoin for years and then atherium came out and that's all we had, right, and so that we have this framework, we're okay, there's only one really by Bible chain that everybody microws to which one's going to be and which one's going to overtake the farm. I think when these bridges come out, it's a game changer because it's not going to just be one chain anymore. When you don't have to worry about consensus in your network because polkadots offloaded it for you, and you can build vertical, specific chains, then then it's just a matter of choice. Like you wanted to be run by the theorium engine. You want it to be run by you know, whatever else comes out. Right. I hundred percent agree with that, that we have to move away from this like kind of tree bullies and that like, okay, this is the chain, that is the correct one, that has that solves on the issues and like that's that's not true at all. Like, if you to hear someone talking this way, it's probably someone that has invested in night and it's not a really talking about the technology itself. It's like it doesn't care about it. Right, people shill in the space. I don't go. I don't actually adhere to that ideology. Really. I actually believe that there will will be one world blockchain that will operate central source of truth for literally everything, even when we're networking to change. Yeah, well, since is. The thing is, I'm not convinced that those are actually biable to be I have not seen any evidence to show that that's actually going to operate the way that they think it is. You know, I I'm still waiting for that and now, if it does well, I'll cross separation when I get there and I'm always open to change my mind, but at the moment I see things like plasma architecture as being way more compelling, meaning that you have this very thin layer protocol which allows you to have one sort of centralized unitized measure of value, kind of like the the I know that in I think it's in London or something, they have they have a kill, a bar that represents the measurement of what a kilogram is, and I feel like having that one, you know, currency, which basically defines what the value is for all other things, would be a much more stable environment for the world to live in. And then anything that that wants to participate in a global economy would operate on something like a Plasma Chine, where it comes underneath this unitized measure of value, and that would be the methodology for creating additional chain networks. They would kind of link into this backbone and then the backbone would result would maintain a central ledger of truth of valued for that for everything else. And I get a little, I get a little, I get a little Um queasy when I think of this, missmash Hash, you know this, missmash you know Mesh Network of chains of different types of you...

...know, you know algorithms that have absolutely no sent trialized way of measuring value and you have absolutely no way of confirming those chains are operating to some sort of unified truth of how value is created and measured and transferred. I just get I see a little, little little when I hear about POLKA DOT and Cosmos. I think we talked to Zacameny and episode five and you know, the read I got from him is that he's kind of he's kind of leaning a little in that wet direction nowt to and that Cosmos is actually trying to build a system similar to that, or at least something that will plug into system like that. When I hear something like Polka Dot, where it's literally just any chain can connect to anything, I'm like, okay, show me when it works then we'll talk. Now I read, I read the White Paper and I go, okay, I don't I don't see how this quite works yet if while plasma mvps are already being produced. Yeah, I don't disagree with the idea that we that we get an anchor currency or an anchor, you know, way to bring people to consensus. But I think our comments, or my common at least, is more on the side of the state machines themselves, like what's running to by code and and you know whatever, whatever token ends up paying for that at some point. I feel like that's very viable. As far as having like a single, I guess, baseline currency or baseline consensus, that would that would that would spread across and provide an anchor value to everything else. But as far as like running code, as far as like running the state machines, I feel like that's where you know, as a as a developer, if I'm going to write in a specific language for specific platform. You know, there's just a lot of there's a lot of support for etherium. It was early, it's got a very open community, it's got the EP process. There's a lot of things that other projects have to catch up to if they want their development community to grow as large or bigger. And I feel this is this is outside of the context of like ether itself, like either being viable or it being the only currency or or if something else overtakes as the currency or the way to handle consensus. But just as far as development itself, the code, I think there's just going to be a lot of different varieties that you can choose from and they're all going to be viable to some extent. Yeah, totally. We have the group can condenna, who's got a very unique way of scaling proof of work on the show as well, and they have their own language packed. What's it called packed? Packed? And it's say it's a it's a their run, their own basically interpreted language, and when you want to publish your code, you G ZIP it up and put it on on the chain and then anybody can kind of execute that interpreted language, which has no recursion, which basically allows you to do what's it called formal formal verification on their language is baked in and those kind of things are going to be awesome going forward. But right now you're absolutely correct. We are. We are limited to the EVM in the way that it works, and that is a very robust you can do literally anything on it as long as it comes under gas cost. Ye. At the same time it's also extremely retrictive in that things like, you know, you have an addressed space of two hundred and fifty six bits and if you do things, if you try and make a u into size eight, it totally can, but it actually went some costing you more because it has to inject a bunch of code to handle that.

Right, I feel like having specialized chains with specialized purposes and specialized calculation. It's absolutely going to be essential, but you need sort of this backbone so you can do things like register your sequel database transaction log with a with with a chain and steak in that, or link cofcu streams to your your chain in some manners that you can actually have some formal verification. Are Sorry, some formal varication, but, you know, truth consensus on your stream data as it goes in and out and keep the top layer state and things like definity, which don't necessarily have their consensus protocol tied with their ledger. You can, you can decouple those things and actually run a machine that only maintains top level state. But to but to provide value to the world on a global scale. I still feel like you need a central chain which is just robust and does the bare minium that you need and has an address space and can provide could transfer KYC and identity across these various platforms. I don't feel like you're going to get that if you're mishmashing a ton of consensus protocols in together and say they're all just as equal as each other, we can transfer value and really you're going to have too much delay, latency, inability to run to to to challenge bad actors, in ability to, you know, just transfer data at the speed that we kind of want, and inability to verify that the individual chains are running in a uniquely, what's it called, decentralized and trustless manner. So I don't know I think these are all great and I think when you have projects like yours, which have these libraries that enable the very base protocol to sort of operate in a more reliablely because you have these audited libraries, he's audited smart contracts. They can actually say, Hey, this is the bare minimum functionality that we know is correct. It's just going to be an essential these primitives are just going to be essential for building applications going forward, no matter whether or not it's Pokadat, whether or not as cosmost, whether or not plasma and general state channels become the methodology that people link to that main chain. So I think this is a great project. Yeah, I think we could all everything that, regardless of what how we feel, things will move forward. To say you know what it, this space is going to look like in five years is overly arrogant. We have no idea. That play difficult. Yeah, if no idea, what what? What route the you know, everyone is going to take and what's going to become popular or only used the landscape of all the stuff and in the next five years? And but y'all are doing the right thing in terms of pushing it in the right direction or push it or pushing it forward at all, and that's that's building stuff and trying to educate others on how to do things properly within a space that's secure and efficient. So I appreciate that. Right, Yep. So how could people reach you and learn more about your project? So our website right now, what would check the IO is, is where you can reach us. We've got a couple contact links on there. It's not very descriptive about what we're work and all right now, just because it's better to put you know and you don't want to put in accurate information and there's there's been a lot of pivoting internally as far as like what exactly the end looks like. And then our GETHUB is modular network and that's where you'll find all of our smart contracts. And now that we've gotten on this podcast and we've talked about them, I'm gonna put some...

...priority on cleaning those libraries back up and getting them up to date with the latest solidity versions and finish getting the package clean up the way I want. So developmentscussion how can people find you, Chris and will right, this is the way it's on this core. Yeah, modulars. These core we are almost seven, so it can reach us out there. Are are directing messages that are open. So can a message US directly or message on the module str now and we will be gladed to talk with you. Doesn't matter if you were ready experience in the area. Feel you are like just starting. That's that's something that I want to make it cure. Here today we listad some problems that we were still facing, some things that we have to fix. It have decisions that we have to have to be made at some point in the other. But I don't want you that's listening to think that those are all barriers. Think about it a more like opportunity of things that need to be solid in, things that you can work on the future and that you can join the space and make a huge impact, like in any any area. That that's that is needed right now. That's a lot of stuff to be done. Yep, it's great, great, thanks guys, for coming on a show. As usual. You can reach us me on twitter at Core Petty. Nope, that's me. Reach you. Reach Cory at Corpetti, twitter here. Reach me at Colin CEO Ncu. See Colin Cuche on twitter you can see us also in our slack. Was it BETC PODCAST, slackers? It spelled out. The slack is the Bitcoin podcast. If you want to call, you want to join the slack, go to the Bitcoin podcastcom and there's a slack button in the nap bar which will give you a sign up link. And then we are always there and if you need to reach out to us, that's probably the best way because I usually have a hard time with emails for some reason. Yep, we are always taken a you know, good good leads on guests have on the program as well. So if you are interested, please feel free to reach out to us there. Will Chat with you and see if if there's a good show fit. And we're also looking for a sponsor. So if anybody wants to sponsors the program feel free to reach up out to the stair as well and we'll talk about it. So thanks, guys. Thanks for coming on. It's really great price for a great very much, guys.

In-Stream Audio Search

NEW

Search across all episodes within this podcast

Episodes (127)