Hashing It Out
Hashing It Out

Episode 2 · 4 years ago

Hashing It Out #2: Orie Steele

ABOUT THIS EPISODE

Orie Steele, CTO of Transmute Industries. Orie is the creator of the Transmute Platform, a rapid application development framework for centralized, decentralized, and hybrid Ethereum applications and services. We discuss language features of Solidity, scalability paradigms such as Truebit, building blockchain architectures, and off-chain scalability. We pull from his cyber security training to talk about security and best practices in smart contract development.

Now entering past 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. All right, episode two of Hashing it out with me, Dr Corey Patty and Colin Cuche as always, and today we have RII steel from transmute, Rans Mute Industries. We're going to be talking to him about what they do, why they do it and or he's general perception on the entire space, and we're hopefully to get a little technical and fun with us. Or how you doing? Doing? All right, all right on. So it started out. Why don't you give us a quick introduction on who you are, what you do and how that pertains to transmute industries and what they do? Awesome. Yeah, so I'm more a steel CTO at transmute. My backgrounds insider security. I've been playing in the cryptography space since two thousand and seven, two thousand and eight, when I initially went to college. We founded transmute about a year and a half ago as we were building decentralized applications for some customers and we found that it was like pretty hard to build these like blockchain applications that were integrating with centralized applications, and so we founded the company to solve that problem for customers. And so so right now is sort of two parts to our company. Like one part is the sort of consulting services piece, which is, you know, where we help customers build out through concepts that are focused on a specific application use case. The other part is our open source framework and platform, which is basically just to provide developers with the tools they need to build blockchain applications. Cool, and so orry. I've talked to you quite a bit about your platform in the past, but I got to say it's a little hard for me to kind of focus on one particular thing at this time. Can you kind of go over a little more about your framework and what its goals are? Yeah, and I think there is one tagline in particular that I think just stands out about what you're trying to do for solidity. So yeah, just tell us a little more about what you're trying to accomplish with this this framework currently leveraging it. Yeah, so, you know, with solidity, like the biggest problem with solidity is there's not a lot of developers who under stand it. So there's plenty of developers that understand jobascript, and so what we focus on is sort of making the development experience for first time blockchain developers is familiar to jobascript as possible. So Joba script developers that are familiar with reducts will find our framework really intuitive because we're basically just using one solidity smart contract to create a reduct like interface for a blockchain application. So just just sort of get into the weeds right away. The way this is, you know, what we do is we take normal job of script objects, we save them to IPFs, we get a hashback for them and we save those Hashes to the etherium smart contract and what that lets us do is save larger amounts of data with integrity checking to if Theim blockchain via sort of a convenient interface. So if you're a first time solidity developer and you're building a decentralized application and all the application is really doing is managing state, leveraging the immutable Olog property of the Blockchain, then our framework might be a good choice. I will mention that, you know, saving any amount of data to the etherium blockchain is kind of expensive, and so I think our framework probably right now is better suited for proof of authority sort of set ups where there's little, no gas cost. But you know, to the main idea behind the framework is sort of say hey, jobascript developers, you're familiar with reducts. You can go ahead and use use this framework to do the same kind of thing you've always been doing and the framework will kind of blockchain of by your normal redoubts application. All right, that's there's a lot of different places I can take this. I'm going to start with there's this concept that I've I've had a problem with, maybe not a problem with, but it's certainly a road block that I've found in that solidity is a is a language that's based off of Javascript, yea, which means that people who have spent a good portion of their development time in Javascript doing something like web development, have gained some type of intuition based on the applications that they build, on...

...how to build those applications, and then we developed a language that's that emulates that, which isn't a good type of intuition for building smart contracts. Right. So that restate that how you use javascript gives you a certain type of skill set which isn't necessarily intuitive for building smart smart contracts. Right. What do you think about that? Well, so I completely agree with that. You know, it reminds me of when when I was in school and I was, you know, learning fundamentals of cryptography and we are starting to talk about building secure applications, one of the things that got drilled in my head over and over and over again was just you see, for everything and absolutely never ever trust any cryptography that's done in jobscript period. And then that like, I professors and classmates who went on to work, you know, in great places and they were all really, really negative about, you know, javascript and you know, the ability to do anything secure in it and also sort of, just like you said, like some of the general patterns that javascript developers tend to pick up because of the structure of the language. So I think, like I agree with you that it's it's a danger. It's a dangerous place to start. However, you know, one of the biggest problems that I see in the block chance space right now is sort of the lack of sort of adoption, and Javascript is a language that lots of people know and so if you're trying to gain if you're trying to address a wider audience, it makes sense to try and happen to sort of some of that knowledge. Now you really careful when you do that, but I think, I think that the idea behind solidity was great. I think there's a lot of language features that it has that are not really features, that are kind of like things that should have been left out of the language. So that's sort of my my sort of two sense on it. I think that it's good that solidity is familiar to jobascript developers in some sense, but I also think that it, you know, a lot of a lot of the inheritance structures and some of the other language features. It's not and it's not obvious to javascript developers how much trouble they can get in right away and the fact that they can't just, you know, probably a new distributable to a server and fix the problem. It has led to a lot of serious bugs. Yeah, I kind of I kind of feel like saying that it's a javascript like language. Is actually just false. Like at this point, you know, I mean like it looks like javascript has got some some basic foundations of what it is, but like there's no such as a modifier and javascript. Yeah, you know, there's there's no. There's no like typing in javascript. I mean you have to. They have. They've things like type scripts to make that happen. You know, the native core ecma script standard doesn't necessarily support that. I think there's I think the more the recent standards might. I don't know, I have to double check, but like, you know, there were things like action script back in the day for Flash, which had typing and that really cool and it made things fast and had in it classes. But then you know like like all this amazing namespacing stuff that you could do anyway, but that those are extensions over this concept of javascript. The javascript itself is does not do the things that solidity is doing and there's no concept of of you know, for instance, I kind of consider the memory, the memory space issue of the state versus you know memory, those kind of concepts on existing jobascript. You know, like you can't, you can't replicate it. Somebody goes in and goes okay, solidity is a javascript like language and then they pull up to the desk and they start saying, okay, I'll just go to code. No, no, you're not, you're not. You're starting from scratch. It's a totally different language. It's a totally different thing and it's really kind of a misnomer to say it art and Missus right term, but like a miss misrepresentation to say that it is. It is. It is a job script language are based off. I was COURP I just don't think it's the same thing because it is said. I think that. I think there's a lot of language things in it that that are not bad, and modifiers are one of them. I don't dislike things like that. I just don't. or He's got the face. What's going on? or I mean so I think modifiers are okay if you use them sparingly, but when you start combining them with inheritance, I think it very quickly becomes kind of a runaway train. So one of the things that you know I look for, that I when I'm writing solidity, that I try and do is I try and keep the number of external dependencies simple and I try and stick to one file as much as possible, and I know that you know, given some of the language, some of some of the libraries out there that people like to use, like open Zeppelin like, it very, very easily becomes tempting to start importing a whole bunch of really powerful tools and trying to apply them to whatever the problem is that you're solving with your solidity code. But every piece of complexity that you add to a piece of software is a tax surface and I I think you know, modifiers,...

...when it comes to inheritance, like you can very easily get into a situation where people aren't really aware of what's going on because the logic has been split out. So, like, if you look at the Viper language, like reading on Github, like the the first bit of it are like the features a Piper doesn't have that solidity has, and I think that when I think about modifiers and inheritance and solidity, I think about that list on the wiper reading, basically. But modifiers are essentially just a water down decorator. Yeah, there's the thing. I really like Piper. I think the SEP in here, the python go ahead of cory. Yeah, it's the overall design concepts. I think it's what or is trying to get at is that when you start including a much of modifiers like smart contract, code should be easily modef like a auditible, and that you understand exactly what you're typing and what it's supposed to do and it does what it's supposed to do and when someone read your code, they can they can glean what you're trying to do and what it's actually does. you start adding modifiers and things that some of the features of solidity, then the auditor or the person who's reading your code is jumping around a tremendous amount, or things get obfuscated to a point that you can't figure out what it's actually doing, even when the like. Say you're calling a modifier that says only owner, but the actual only owner code doesn't do that. That would be very hard to find. Less you go and find that code, and that's not something. That's not the type of design pattern you want. Would for code that cannot fail. And what I was shouting hired auditor that didn't check you're right, things like you got it there, made multiple I feel like that's the onus of responsibility. There's is on the otter. Let's face it. You can say that you're trying to protect the world from itself, but, like the onus of responsibilities always on the end user and the person who is actually going to implement this. The reason they have modifiers in the code is because it makes very lot more efficient bite code and it's also allows for kind of more of an upfront cost as opposed to like, if I put this if statement in every single function, and that to me makes perfect sense from an implementation standpoint when deploying on the network. Now, do I think that it makes the most readable code? It's really not necessarily true. Do I think it makes the most efficient code? Actually, I think in a lot of cases it does not. I think, though, as a concept modifiers are not bad. They just need to be used responsibly, just like everything else in programming. I mean, it gets to, I guess, this sort of it gets down to, like, you know, who are these new developers that are coming in in the ECOSYST and are picking up solely for the first time, and are they going to be able to actually read, you know, the Consensus Best Practices for solidity, you know all of the documentation on that. Are they going to start writing code that's in line with that, or are they going to start exploring the language features and just, you know, shoving code out into production? Yeah, that's that's something I've noticed to is some of the code that's out there is very it takes very h design principles which I think aren't really conducive to making efficient smart contracts. That's, it's, not to say, the bad point earlier. What's up? That was my point order, is that we've sold this language is a javascript like language, which makes people who know Javascript, which are people who do web development, jump in because they think they can quickly. And the way you design smart contracts and decentralized applications is very different than the way you design a web development or work web front ends or web applications. Let me totally to an exciting but when you make a smart contract, I have to repeat, it has to work the first time or you have to find a way to upgrade it so that you can do that in a secure way, especially if it's storing money. And I feel like I feel like some of this is also, if you were we kind of are treating it like like web development, like you said, but I think a better model for the development process for anything we do with a guard to smart contracts is to take take it from firmware developers. Yeah, yeah, you know, those people get it. Have to be like ninety nine percent correct in everything they do or else the entire product is boo barred. You know, there's typically not a strong upgrade path for anything that that's that's firmware. And I mean ninety nine point nine, nine, ninety nine, you know, five nines if you can. Nothing's a hundred percent. I won't give it that, but like you know it. You need to be solid and what you're doing in a lot of a lot of the cavalier nature of job job script developers. You're right in that mentality wise, especially. It doesn't. It doesn't, it doesn't apply. I've read have one function, it's really superrec super efficient and big. Then one function and just put the cost up front for storing storing the the the contract. Then have like a bunch of decomposed things that have possible leave room for possible errors that we couldn't descree before. So I guess we're all on the same page. You're just saying it in kind of a different way. Yeah, but that said, I think the responsibility still is on the implementer, as in it always will be, and so you can talk about the auditor not checking whether or not only owner is actually pointed only owner. That's a shitty auditor.

You know what I mean. You have to check this stuff. Yeah, and code goes through. You know, there's there's different sort of levels of confidence that you have and in development. So, you know, let me just sort of say real quickly like a lot of the work that we do at transmute we're developing code that's hasn't been audited yet. It's in Alpha or were exploring sort of the con the concepts in the interfaces that developers might might really enjoy and one that doesn't necessarily translate directly to production code. And what you're the process of like having, you know, one or two or three audits, like ideally on your smart contracts, before you before it gets all the way out. It's similar to the process you go when you're designing like an actual circuit board. Like I think smart contracts and printed circuit boards are almost equivalent. Like yeah, you at the point which you've actually got the board manufactured. That's it, like it either works or it doesn't. And if there's a defect that's built into it, it's there forever and you're going to have to go build another board to get order that. Wonder if we could build like a bite code, a copil bike, like a vhdal or vdhl or what it was called. The I'm sure the chip language. With enough, you know, work, you probably go. I'm not sure it's a better language and the solidity it has more riggor behind it in a longer history. The yeah, now. So, I mean, you guess you've looked into the Viper project at all? I kind of like what I see, but it's not going anywhere. It's not getting the traction I want. You know, that's that's my my absurd biggest frustration with it is it's the sort of power law distribution. You know, solidity was first and it's got all this gravity and all these developers keep coming in just reinforcing solidity. I like and Viper has a lot of features that I'm really excited about that I want to see developed, but I don't I mean, I've played around with it a little bit. I don't really have the confidence to stand on it or to start building on top of it, given the kind of traction that it has so far. Like you said, I'm excited about this axling project. I don't know if you guys are familiar with this, but it's like a like a language that's, you know, basically putting formal verification for first, for Saluty Develope, for for solidity development, for evm smart contracts, and it's, I guess, sort of similar to the bamboo project, which is another project that sort of focused on formal verification. Wondering look what you guys think about formal verification in the space, especially compared to traditional audits. I have very strong feelings about all of it. As you can imagine, I have strong feelings about everything. So it starts off with like backing up and explaining, if for those listeners that don't quite understand, that any of these languages, these high level languages that we're talking about, are used so that a programmer can create code that does what he thinks it should do in a very human readable fashion and then compiles down to, for anything, theorem based at the EVM bytecode, which is something that a machine is more likely to understand, and that translation is incredibly important so that what you think you're programming actually ends up being programmed into the blockchain, and so we have different languages that we model around that we think maybe good or bad in terms of that. That translation from human readable code to machine readable code and formal verification is a process in which you make human readable code that you can run through a machine that guaranteeds what you think it does is what it does in the machine level code. I think it's incredibly important that we have something like that. But at the end of the day, because open blockchains work the way that they do, no one's really going to use them until they make contracts that I have held money for a long period of time that have experience. That's the only reason that these design patterns are worth their salt is because we have of real deployed contracts being attacked by people who want the money inside of them, and so you have a certain level of guarantee, some quantifiable metric that says this works, because it has worked in people have tried to break it. Yeah, yeah, I totally agree, and I think that so highlights something that I've seen in the industry which I'd like to call out, which is the the bug bounties that you set for your Smart Contract Library. If you're a small you're a small company and you've just released a new multi SIG wallet and you've put, like, you know, two thousand dollars equivalent on your bug bounty. No one is going to burn their exploit on that like. So you to your point like this. The contracts that are holding, you know, real law, really large amounts of funds, like...

...for those, for those contracts, at the point in which you're holding really large amounts of funds in them, the incentitive for the attacker is now there. But if you're if you're doing a bug bounty and you're saying, you know, our contracts are secure because we have a bug bounty, the bug bounty was for like, you know, too grand like. It's nowhere near the right amount of value to attract someone to actually report and disclose, you know, that appropriately. So I just think it's one of those things. I every now and then I come across a project and someone's, you know, touting their bug bounty and when I think about what it would what it would be like if you actually had an exploit that worked on that, like, your chances of actually reporting it and claiming that bounty are below well, you know, some people are do wear white hats. So you know some people have ethics and morals, and I guess rewarding that that kind of behavior is not a bad idea. But I see exactly where you're coming from. HMM. So take the Twentyzero bug money. Or do I do? I sife in a hundred eighty million dollars out of this particular contract. Like, what do I do? HMM, I'm sure I can find a way to launder a hundred eighty million dollars bringing it back to bring it back to the the the formal verification. Part of that is that having having things like that that helped you feel more secure about your human readable code being transpiled or compiled into machine readable code so that you have left what's known as Zero Day exploits, helps you take that initial step of putting a significant amount of money into the contract that you deploy, and so then you can have the like the real guarantees or or more quantifiable guarantees of security and smart contracts. Well, you know, I'll just say this. I think that our approach to spat car tracks, is being single units and containers of validation, is not going to work. meaning that we need to kind of put like a firewall system in front of a lot of the stuff that we're already just thing. So contracts need to be calling contracts if they want to x, you know, pull out any significant amount of money. Now, minor transactions, I think they could flow up more freely, but at some point we got to go okay, this is the unit of value where I got to say, look, I'm going to this transaction needs to be validated by another, you know, transaction, another contract or authorized by another entity if it's going to be above the certain amountain. That's easy to do and smart contracts is not difficult, but it would cost more to deployed, it would be more engineering effort and of course you'd have to make a very thin way of doing it. So you can guarantee that the container cary. I don't know. Firewall contract is something you can audit easily and ensure that you couldn figure it easily and not mess up. And you know, I think that's the only real safety will or guarantee is we're going to get out of this is really small things that are easy to guarantee that your value is protected. Guarding standing in front of the very large containers of value that we have in these smart contracts right now. Yeah, I mean I think it's, you know, we're really what you're saying is that there's always this tradeoff between like efficiency and security, and sometimes, like the best security means that you have that you have to eat a lot of inefficiency to get to get the best security. So like time locks, like you know, restrictions on the amount of volume and it can be withdrawn from a smart contract within a period of time, like these are all things that actually are there. They create an efficiency in the system and then you're protected by the fact that that in efficiency exists. And the same thing applies to, you know, the proof of work mining, mining algorithms and, to some extent, you know, proof of staate algorithms as well. Like we we build security on top of an efficiency. And Yeah, what you're saying about, you know, proxy contracts makes me think that, you know, it's it. This is like a valid approach to that problem. You know, by add by adding extra time delays or extra sort of middleware, extra inconvenience. From the perspective of an attacker who's trying to drain your funds, you know, that's that's going to ultimately be good for the contract owner. Yeah, and and Zeppelin libraries, if you look at them, they have this concept of a pause. Yeah, and and you can, you can literally just say, okay, something bad is going on, I'm going to execute the pause. And the only person could do that as the owner. And if there was time delays. is a really great idea that you know, it's implemented another places, but that's your something. I wish brought it earlily. It's something that you can pause on. You can go, okay, I see this event is happening. I have enough time to react. I have something monitoring this, like you get alert, and then I can hit pause on whatever's going on. That's great, you know. Yeah, but again, this increases the decreases the efficiency, increases the cost of of operating your system. And really, when you say efficiency in this we're talking about two things. Your gas limits, and you don't want to cross that and you know you don't get to two ex to too...

...much your you can't yet your contract can't spend too much. And then the other one is just the fact that the currency itself is so incredibly overvalud right now. I have no problem with incentive models being in fact, I love it. They built it to the etherium network. It's the eye, it's way that's built for that. It's one of the things I love about it. But when people are trading at four hundred dollars a coin, God forbid one thousand, you know that is not worth it to run the network at the moment, especially with this the low limits of the high through the low through put needs, what's word of it the like. There's just too much. It's too to cost too much to do just the most basic thing. So the idea that I'm thinking is like a lot of this stuff that we're talking about won't matter if the currency relative to the Fiat goes down or if you has kind of disappear all together, because we could, we could, we'd be in a different world at that point. And these arguments that were making about efficiency and if scalability is improved and computational power is is is able to be done off chain for a lot of this stuff. I know you're working a troop bit, for instance. If a lot of this is able to be brought off chain, that lowers the cost of running your code in the network. So you could build better solutions which make more fucking sense. And right now a lot of the stuff we're doing is small and tight because we can't afford to do anything other than that, and that is actually causing more problems. It's actually losing US money. Yeah, from a philosophical standpoint, I think that in time this will all just kind of play out in futures looking great, but right now, you know, people are designing big you know. Well, yeah, whatever, yeah, I made my piece. I said my work. What you're saying about, you know, basically people using I think a lot of there's a lot of people who were, you know, sort of coming in now because of the all time high. You know, around a thousand like people who heard about that or are new to the system and they're they're coming in or there may be their jova script web developers. They're writing their first solidity contracts and they're doing everything in the blockchain. They're doing everything in solidity. And to your point, you know, I think etherium is for it's for this immutable audit log and for verification, like Really Smart Verification, which is why I really like what, you know, what true of it is doing, and I think that any all of the solutions for scaling off chain computation and on chain verifiable manner really interesting, because I think etherium is old like the ultimately the best the best thing for it to be focusing on is is just sort of the secure multi party computation verification game. Like that's the thing that I wanted to do and I want really scalable, easy to use off chain computation. So you know, solutions that I can plug into a theorium where I can get the performance that I want off chain using the tools that I'm already familiar with, but I can I can be held accountable and verify that computation on chain. So tell me a little more about what you're using. True it for them. Sounds like you're already getting into the weeds with that, and I you're the only person I know who is. So it's yeah, so we're there's no publicly available code right now in our framework that's actively using true bit, but what we've been doing is we've been sort of, you know, following the progress on true bit, and I'll just sort of explain at a very high level. Like true bits sort of genius. So true it solves this problem of like how do I prove that I performed a computation correctly and the out you know, the mechanism that true it uses for that is complicated and pretty awesome. But one of those sort of key components of it is that if you just trusted people to be performing computation like you know, honestly, then they could start to they could start to sort of deceive you based on the inputs. And so part of the true algorithm, it's really awesome, is that it injects these faults and it looks for them in the guys that are doing computation and verification, and so by doing that it can encourage you can encourage users to use to actually perform the computations correctly, because if they're caught like cheating or like using a stored input when one of those failures is injected, then that they will be punished. So it's like when cartographers are your map designers would put fake streets in the map so they could detect if somebody stole their copyright of material in the map. When they when that, yeah, they would actually put the fake street. Yeah, so back of the day it was a big problem. So they go through all the effort of mapping out all the streets to a city and then they publish their map. Okay, they'd have authorized people copy, but they had other all UN authoried people, resell their maps. So in order to I forget it had a specific name for the street, but it actually they put little streets in in the in there in their map that don't exist. Yeah, and so with when they wanted to prove that somebody stole their stuff, all they had to go...

...that's my seat, that's my street. I got to notorize document sating that that's my that's my fake street that I put in and this person has it. Therefore they copied my map. That's awesome. I've heard of something similar for Persian rugs. Is really intricate rug patterns that sometimes people will specifically introduce flaws in this particular part of them and then some of the machine generated topies won't have those flaws, and so it's a way of supproving authenticity in it. I think it's interesting that we see these parallels throughout throughout history and throughout time and throughout different mediums for sort of guaranteeing the authenticity. That's it's super cool. Yeah, I'd like to kind of shift the the conversation a little bit, because this is something that I don't think gets a lot of attention at all, in that what you're doing in chance root industries is mainly focused towards trying to enable enterprises, it's, to dissipate in this decentralized economy or build applications in a way that help them do what they do, but in a decentralized way. That's not necessarily what the majority of the people who are working on open blockchains care about, but yeah, there is a lot of demand from the enterprise perspective, and what I think is important to note I work for one of those massive enterprises myself and I am a blockchain developer for them. So I understand that there's a pretty big difference in that the types of problems enterprises are trying to solve have very different constraints and ideas than what open blockchain developers are trying to solve or develop, and that like the incentive structure or the trust model that we usually go into or assume from the very beginning or very different for enterprises than an open network. How do you see that being played out when trying to create platforms or infrastructure for enterprises to solve these types of problems, because you can't do what everyone else is doing in the open network if you want to try and solve products to them. Yeah, that's it. It's a this is a really good question and that's struggling with. This is is basically, you know, a huge part of what gets me up in the morning to work a chance me. This is what I'm most excited about. So the first thing I'll say is that, you know, obviously we're at the beginning of the sort of block an era and we're not really sure how long it's going to go and you know what the future holds, but certainly these are the early days. So it's hard to talk about the value to enterprises right now, because it's like talking about the value of the Internet when like three percent of you know, the United States has it and it's K and you know it's it's hard to sort of imagine how it's really going to train transform business. But the one thing I will say about it is it's built on top of this property, the security property, which is that decentralized systems are inherently more secure than centralized one. So you think about really what blockchains are, they're distributing the liability and or the risk of breach by basically making each participant manage their own encrypting keys. So in a world where an enterprise, you know, has a sequel database with a bunch of personal information in it and that enterprise is compromised, although that whole secreted sequel database is dumped and you know, everyone's mad that their identity has been stolen, and you can think about this is an analogy. But you know, imagine that that sequel database we each row for a customer is encrypted and the customer encrypted that data and then the customers sends the encrypted data to the enterprise. Now when that enterprise is breached, the enterprise has to say, yet we're breached. All of our encrypted records were we're stolen. And but the good news is that it all the encryption keys used for those records were managed by the users and so, like you know, as long as you have secured your keys as a user, you should feel confident that the information still encrypted. And I think that there's there's a lot of value for enterprises just off of that sort of distributed key. You know, distributed encryption model, especially in a world where, you know, people enterprises are losing customer data more and more, and the aquifacts and facebook and these are situations that are causing users to trust, to question whether we can trust centralized information providers. And you know, my personal perspective, with the background in Cybersecurity, is you should never trust anyone with your encryption keys ever. And if you're encrypted, if you're not encrypting your data and you're not in control of the keys, and the software is controlling you and it's not the other way around. And so I think it's really important that users understand that they have to use encryption themselves and they have to ask for enterprises to support interfaces...

...where they can hand the enterprise encrypted data. And so I think a lot of the innovation in this space and the interest from enterprises like how to how to build experiences for their customers that do that so the enterprise can be safer in the event of a breach, so it's not a catastrophic failure where all these records are stolen, but also so that the customer can have a better experience working with that enterprise. They can they can trust that those they can trust the software without trusting the company. You know, I this is, I think, why enterprises are interested in the space. And to get back to, you know, your original question. To build user experiences that are pleasant right now, I think you need to leverage a lot of existing enterprise centralized software and technology. So, you know, our framework and a lot of the open source software that we're pulling together is blending centralized security concepts with decentralized ones and centralized application hosting experiences with decentralized ones, and we want to make it easy for enterprise software engineers to build with tools that they're familiar with, in patterns of development that they're familiar with, where their leveraging, you know, centralized technologies to provide user experiences that are good, that where the performance is acceptable to users right now, and then all the while sort of thinking and sort of with with an eye towards how are we going to decentralize these company these pieces in the future when decentralized technology performance sort of catches up? So it's like a specific example of that. You know, I loove, I really love IPFs. I think it's great. There's some cases where you're better off just using Cassandra, you know and like and I think depending on what the enterprise, you know, is trying to build kind of solution there, they're making sometimes it's okay to make that trade off, especially as you're developing the initial proved concepts. Yeah, well, my take on it is the the intent of a blockchain, intent of all these decentralized systems is that they hook into some trustless entity, some single source of truth. You can have a cassandra cluster and if it's if it's operating or checking in with a plasma chain, you know you've got some value volidity to that Cassandra cust click cluster. But but, you know, to bring back to your other point about controlling your identity and controlling your private keys, I think it's really interesting and one of the more compelling use cases of Blockchain, as it is not just the equifacts and everything contained, but how do you establish an identity? You had a particular project that I thought was interesting and I might actually have to replicate it here in the future with biometric data. Yeah, and I'm kind of I'm kind of curious, you know, if you could tall talk about your experiences with that and how you actually decentralize some biometric data for, if you, for one of your customers. Yeah, so that that's a it's an interesting use case. So, like, I can talk about it generally the you did with me as well. So, yeah, so, like you know, basically, you know, one of the key sort of challenges, like you like you know, I mentioned, is, you know, this this key management problem, like it's a big it's a big step for a lot of users to understand that they have to defend and protect private keys. So you might you might ask yourself, well, you know, in the in the in the middle term, you know, how do I make a if I'm an enterprise and I want users to have the sort of experience of blockchain sort of security but I don't want to actually make them responsible for private keys, I'm going to use some people call them like cloud wallets. You know, they're private keys in this case, or manage buying and enterprise. And then the access to those private keys and the Kate, the ways that those private keys can be used to interact with blockchains is controlled by centralized software in the enterprise web application. And so in the case of cloud wallets you have the same authentication problem that you've always had when you're building web application. So, you know, a user comes to a website, they lock in with they're using them and password, they get you know, adjacent webpoke and like a bearer token, and then that token, you know, is the thing that they can use to present two services, to claim to be a specific identity. And so you can imagine logging into a website, getting a bearer token and then saying, you know, I want to check my balance, I want to transfer some funds, and in those cases the cloud wallet will take those actions if the bearer token is correct. And and you know if that's really scary, because I'll just steal your bearer token and now I control like whether or not I can see your balance or can send funds to someone one. So the people say, well, look, let's add on multiple factors to the authentication process. So let's let's ask for you to prove that you're in control of a phone number, prove that you...

...remember, you know your your password, and prove that you're in control of some biometric you know, maybe prove that your control of two or three biometrics, different, different ones. And so when you're building these like these cloud wallets, are a great opportunity to sort of blend, you know, the state of the art in centralized biometric security technologies with decentralized technology, because you can, you can layer on all these concepts and then you can say, you know this, this enterprise is going to only allow certain kinds of actions if all that guarantees are met. So and and you can bootstrap, you know, those identities from from blockchain identities as well. You know, you can. You can have a client prove that they're in control of a private key and then use that to then log in with using in a password, and then you keep adding these layers on and then at some point you have confidence that when an action is happening in a centralized system, that there's there's reason to believe that the human on the other end of that action is still the person they claim to be. So like this is something that I've I think a lot of enterprises will probably do as they start art to build out blockchain applications for their customers. They will initially use this cloud wallet pattern because it's familiar to them. Like they like the idea of being in control of what a user can and can't do in a system but ultimately that's there's a problem there, because if the user isn't the one who's actually in control of the private key, then all of this extra biometric stuff that you're doing isn't doesn't really matter. So I think, you know, the experience that we've had has been sort of blending centralized security concepts with biometrics and with blockchain authentication. But I think the really interesting thing that like we haven't spent a whole lot of time on, which I think there's there's some really interesting papers out there which you can sort of dig around and look at, is like the idea of secure, decentralized biometrics on the blockchain, where you're storing true biometric templates and decentralized storage technologies and the verification and authentication can be done in a completely distributed manner. Yeah, one of the things I was looking into is how how we could use biometrics is sort of an entry point. So you must first pass the biometric test. Problem is a lot of this computation stuff that we have to do, for that requires things like bk trees and and really complex fuzzy fuzzy logic. You know, did you know you want to do himming codes a million times him over on a table of mapping just to detective. You got that existing in there. Is it's really difficult to do in a decentralized manner with the current technology, but with something like true but it might actually make it viable. So I'm kind of interested in how that kind of works out the long run. Yeah, so I'm kind of curious. What what do you guys doing with the Framework Right now? Where's the progress on that and how's that going? What's Your Road Map? Well, man, so well, there's a couple things. I'm one thing I think you know I should say is that for a while the framework was was sort of really, really forward looking, trying to take advantage of all the coolest little developer sugars that I could find out there, and it got kind of bloated and so I had to had to go ahead and rewrite a big jump of it get rid of all these dependencies that had snuffed their way in there. That we're making it hard for users. So we have a long ways to go. I think you know high level the framework right now. It work. It works well for building decentralized applications with a theorem and IPFs in secure sandbox environment. So that's kind of the short term goal that it I think it meets, you know, roughly, but it's still, you know, actively under development. You know, I like what you said about, you know, it being kind of hard to handle some of these decentralized authentication concepts and I when I think about what the framework is really attempting to be, I'm I want it to be the abstraction that you reach for when you when you encounter some of these problems. I want it, I want it to solve, I want it to I want it to be easy to apply to solve some of these higher order problems. So we're adding layers on top of this sort of event source model to support those use cases. So encryption support is the sort of coming soon and I'm hoping that by providing like a really simple interface on top of libsodium and I give as and if you're in smart contracts, we can provide some sort of general standards for how to handle encrypted off chain data with integriting managed on chain and, you know, moving...

...beyond that. I think that that having having that as a building block is really important for being able to scale some of the off chain computation pieces and finish some of the true integration work that we're hoping to do in the future where we can sort of provide provide proofs that users in the network are doing computation and that these events streams that are built from user activity are are to be trusted, because encryption was was there from the start. So the framework has, like you know, are are. We have a long road map with a lot of really complicate features in it. Yeah, the no governance was a huge part of what you're doing. Maybe you could talk a little bit about how you're actually integrating governess models into what you're set up. You had a pretty decent urbaut contract that I saw. What's going on with that? I mean, is that kind of where the demand is going for what you're doing? So the a while ago we wrote this role based access control interface that was built on top of event streams and I actually kind of have put that in the attic for the time being. I looked over at some of what opens Zeppelin has been doing and I think that, you know, I I wrote a bunch of tests for this. This are our BAC solidity contract that was event sourced and I had some confidence that it was working, you know, approximately correctly, but I was really the only person using it. Hadn't been audited at all, and I looked at it compared to these other features and there's one thing that you know you should never do, it's roll your own Crypto, and that basically applies to like everything in solidity. So something out there that is more battle tested, and you find yourself making your own version of it, like that's great if you're learning, but at a certain point it's time to decide whether it's fat. This is, you know, is this thing really the thing that you want to be spending your time securing and working with, or is it time to sort of rely on something that's been more battle tested? And so I think for a lot of a lot of the I thinks that opens up one's really great and I think that they're our libraries are. I think people should should use things that have been used, you know, more often and like and specifically you find cool stuff in our framework, that's great, like, play with it, explore but, you know, don't go including our stuff in your production code right now. Isn't that what they say? That about a hemium too. I mentioned that earlier. With these design decisions based on like how much money's been putting the contracts that use them. That's that's you just you just pretty much gave us a scenario as to doing exactly that. I built something. Turns out somebody build something that was very similar, that's been used a lot more than what I did. I should probably use that because there's probably a lot more money in the contracts that use that decision or that that mechanism, which means it's inherently more secure, or at least I know that it's more secure because it's been tested. Yeah, yeah, I mean, I think I will say, you know, I think it's important to experiment and play and there's a lot of cool cryptography that you can reimplement yourself and gain some knowledge of and have a really pleasant experience. I think you just want to be careful not getting lost in that and forgetting what you're saying, you know, which is that like you should be trusting things that have have proven to be trustworthy and an adversarial environment for a long time now, like even, you know, the NSA, you know, sweet beast have like like the crypto sweets, that they have their time limited and you know, I don't know if you don't also you guys want to get into the whole quantum discussion, but things don't last forever and a lot of the cryptography that we're using right now it may not be be around, you know, forever and and or it may not be safe forever, and so I think it's worth sort of relying on things that have survived and a reasonably unbroken format for long periods of time. All that's why a lot of the off chain stuff is actually going to be act is like literally important anybody. So they could do everything on chain. I don't think they've ever worked for anybody that had really important data, because you need to physical access. Is the first rule in security, okay, and if you if you put it out on the chain, everybody has physical access. You know you're not controlling your you know your physical acts at Allso I feel like the block changes gets rid of the number one rule in security, which is physical access. You need to protect it. I feel like, oh, that's I could be this. I could have cut the mustard for for a lot of this fort mustard or mustard, whatever it's for, for a lot of these enterprise applications that even just enterprise, government,...

...even private, private application. I think to some extent you're going to need to hold it tight to your chest. The data and encryption, like you said, does not last forever and you know MD five took ten years, but we found a collision and wind up causing problems. Now that doesn't mean that empty fies bad. We still use it all the time, but you know, well, you gotta probably know. We probably shouldn't. You know like well, because what you're using it for. It's a really lightweight, easy, quick cryptographic Hash that if you're just trying to take a piece of data and create like a simple checksum for it or, you know, just have something, you can use it as a look up table index four. It's fine. Yeah, it's not like five. Our Sea for like we when we when we know there's problems and we've seen attacks and we, you know, can read about like the attacks that have worked on these things. Like if it's in a piece of software that you are responsible for, you should remove it. Like if you're using a piece of software that's using one of these things, you might have to accept that you're not going to go rewrite that library to get rid of that broken cryptography, but you shouldn't be under any illusion that you're not using a library broken cryptography and like, I just think that. Let me give an example. I was at I had a system where I was going out in skinny web pages and I would intercept these web pages and I had a special system for taking the data, regardless of the content, and creating a fingerprint. I use the MD five function to actually ultimately create the fingerprint. I don't care, right if you for me. From my perspective, unique to find it enough, and that's all I was trying to do. So it really does apply to the application. That said, I mean, could I have used a better other than well, at the time it wasn't broken, you know, so it was fine. Do I think I'm super scared for this application now that it's broken? No, fact, I don't think they're using it anymore. But the point is is that, you know, if there were, it wouldn't hurt the application at all because the context in which I use the actual function didn't didn't let me have that sort of cure to something. But anyway, sorry, go ahead, Corey. Yeah, it's like what something you mentioned earlier, physical access as number one, and the purpose of using cryptography is to move the physical access away from where it's stored. What you're doing with cryptography, and that's why it's been incorporated into the base layer of blockchain systems, is you're allowing people to hold the value themselves and storing it in a place that's had that gives access to everybody, regardless of word. So we have the central source of truth the Blockchain, but the physical access is within the users and their private keys. Who have, who give, who change the ownership right? And so what you're talking about right now and whether or not you use a certain type of Hash function, is the link between where it's stored and who has physical access and how secure that is. And so when you're talking about something like who has the question to you want to ask yourself, when thinking about how secure is my hash function or whether or not to use something, is how many people have access to where things are stored? And so, calm the type of use case that you're talking about, you have access to where that stored. So only you care about the function, but in public systems you really care about that function because it's in an adversarial setting. You have to make sure that the links between where something is stored and who has physical access to it is incredibly secure. Otherwise it's entirely broken. Correct. I'm okay, sure, not going to secate that. Is that summarize basically both both your standpoints there. I'm saying context is king that if just because you have it doesn't mean needed to replace it necessarily. Might you know it's probably easier not to in certain cases, but for a yeah, for a public setting, if you're going to enable it, and most contexts with regard to that, yeah, you definitely want to change it. So yeah, and then running back to the the quantum scenario. That's why people are so worried about it, is that quantum cryptography or quantum computers breaks that link between where something is stored and who has access to move it, the link between the public and private key. That's why people care about it so much, because it has the potential, in my opinion, far off potential, but heavy potential, of breaking that link. It is inevitability. And what does it mean when you break that? That leak? But we already have the solutions to quantum, quantum block chains. I mean they're there. There's just quantum scure algorithms already existing them connection the probably quantum scires, your algorithms that we can use the problems. Are Not using them now because they're just a little more costly and I think I want right. There's definitely implications of this, and I put this is coming from someone with a WHO's thought a lot about this and I come from a quantum mechanics background. It. We may be able to have quantum secure solutions, but we're not using them now and we have a lot of value in things that do not use them now and we've tied up a lot of secondhand implications on the on disc...

...value. So our economic so will take, for instance, bitcoin. This is the example that I like to give for for implications of quantum mechanics or quantum computing. We have bitcoin with it with a given total supply and circulating supply of of Tokens that can be passed around the network. These are stored up in public and private keys that are not quantum secure and over time a lot of those bitcoins are basically gone dead. They don't exist anymore. They may be in the total supply that have been mine time, but they're not in circulating supply. They are dead Bitcoin, and our economic model on how we pin a price to the bitcoin takes this into account. Think about Sotocio's coins and the percentage of coins that we considered dead that don't move and how that reflects the current price, and what we think about how scarce this resource is. Blockchain or open blockchains and the tokens on them is digital scarcity, and that's why they have value. Now, when you introduce quantum cryptography, you may be able to change the way addresses are created that are quantum secure, and then you have to somehow force people to then create these new addresses and move funds to them so that, no, they can no longer be broken. But you cannot do that for all of the coins that we considered dead. I consider this to be a solvable problem, sure, and the reason it is to be a very just double shra difficult. Sorry, it's going to be a socially difficult problem to solve because you can't force dead coins to move to new addresses or and so you have to make one of two decisions. Well, I'm not going to make a false economy, but here are a few decisions you have you can make. You either say all of those coins are really dead now we've removed them from the total supply. Or you say, if you don't move them, then they are they are available to be stolen. So really, you know, right now there doesn't matter if they're not in supply, the supply that matters, circulation that matters. Tell that to somebody who wants to move their coins that has them locked up in cold storage through some odd secure mechanisms like store. That's that's that doesnlve them again. That's again. That's a solvable problem. That's in other words, I see that as being like a hey, you have six months to change your password. If you don't, you lose your billions of Bitcoin or whatever the heck you want, like me, and people aren't going to want to do in that. I would love to see what happened to this DOCI Wallet, but, like you know, it's just one of those things where I feel like it's actually solvable through process and procedure and you know, typical OPSEC in just protocol level upset and just like these kind of things can be done make, we can build, we can build solutions to these that are social and just because the cryptography is is is annoying and we, you know, we were going to force them to do it. Doesn't mean that that it won't. I feel like everybody's like worried that we're going to suddenly get this like, Oh my God, the whole world has access to quantum computers like today. No, we're going to know who has it. We're going to I'd be more afraid of like a state actor withholding than anything else. But worry about it. What's that? I wouldn't worry about it. Yes, I feel like it's could be a slow enough progression. We can actually say hey, look, we're going to need you to upgrade your your keys in six months. If you don't, then we're just going to take all your coin out of out of circulation, I think. And even in that process we can inject things like identity and KYC elements to prevent this from happening again. If you so opt in, you're that's it's a can of worms. Go ahead and orry. There's there's a lot in there. I mean I would say, you know, in terms of the like, you know, the application of a quantum computer to a specific problem like in the in in the future. You know, certainly, like may state actors are the ones that have the kinds of resources that will be able operationalize this kind of stuff first, and I think it'll be a kin to, you know, when we cracked enigma or, you know, purple and read, whatever the Japanese code systems were, you know, in World War Two. In those cases, like, once you've crap cracked, you know, a major cipher like that and you're the only one who has that capability, you really really don't want everyone to realize that their encryption is broken. So there's going to be a bunch of like really there will be some amount of pawn if a quantum computer gets to the point where, you know, it can solve all these problems like as easily as they want to for specific chosen target like there will be a bunch of times where we're probably going to let, you know, let some ships sing or let some attacks go through, even though we've decrypted the attack traffic, you know, ahead of time, because you don't want to reveal the fact that that this is a capability that you have. So just because we don't see, you know, wide scale movement of like, you know, dead bitcoins or wide scale like breaking of SSL. You...

...know, on the great firewall of China or that kind of thing. You know, that doesn't mean that the capability isn't there and that someone isn't withholding it and using it for very specific, very very specific, targeted use cases where there's a the ability to deny that the ability was even there. You know. Well, yeah, and that's my fear. I mentioned that earlier, but you know, it's not even a fear, it's just like, I think this how it's going to play out. That's okay, you know, that's okay. That's how things in a hundred years it won't matter. What matters right now is that we look at as the average person, is, the average Joe, as the average protocol designer, as the average in a software engineer. How do I build something that doesn't lock me in permanently to something that I can't possibly ask my users to upgrade in the future? That's where we are with bitcoin. But, let's face it, bitcoin's antiquated, an old and a trial technology, and it was successful as a trial and etherium successful as a trial. But they're not done. They're not done, and our next our next, the next phase, is going to include something that has a mechanism for for for everybody coming to a consensus on upgrading the protocol and requiring it, because you cannot survive a computational bomb like quantum computing or even the next paradigm going forward unless there's that mechanism built into the protocol itself to say hey, this particular ice age, let's just say, will force. Will Force you. Maybe it increases transaction fees on individual accounts so that if you don't upgrade your password or upgrade your security syste your authentication in any way, shape or form, you know, then we can prove that you have, then you you have it. Even then, like upgrading a wallet, you'd have to literally transfer to another. Well, yeah, if you have a transferred your like if you have transferred one of the new wallets, you will need, you know, using some it doesn't matter. I guess at that point it's not the onus is on them. But if you haven't, you don't upgrade your your system, like you your transaction futures go up like slowly, but eventually it's just gotta draining your account next time you try and do anything. Yeah, it's sort of a similar point which I've heard of. Is like this idea of like tainted pick bitcoin. So I don't know if you guys talked about this on the podcast previously, but Nope, your second episode number two on this fuck guest. All right, so, so do you you all know what tainted bit bitcoins are? Hmm, these these coins that are so, you know, like the Department of Justice Shuts Down Alpha Bay or Silk Road or something. They came Oh yeah, okay, and the bitcoins in circulation in that dark market are, you know, confiscated. You know, hopefully, like DOJ has control over the private keys for all of them. They go to auction them all off. They auction them off at a lower than market price for like a number of reasons. I'm one of the one of the reasons that it makes sense that the price is lower is that these coins are connected to this, you know, these nefarious they have a nefarious history. Right. So, like every time you move a coin that's connected to these past market place activity that's known to be bad, you move that into a hedge fund and there and the Hedge Fund is running scanning software on all the coins that are coming in. When transactions they're going to see like hey, like there's there's transaction history here that's concerning. Like these coin, these tainted bitcoins, are actually worth should be worth less than than untanged bitcoins. Like what are they? Tumblers are for a man? Well, let's let's let's take this into a technical stack type of analogy, in that your base layer should be agnostic to all of these things, because you you can always, I said this before, you can build centralized services on top of decentralized services, but you can't go the other way around, and so the types of assumptions that you make on your basic layer need to give meat, need to be the most general as possible, because what you end up using is going to be layers above that in the real world, and so you need to allow people to make whatever decisions they want in the applications that they're building, and what's going to end up working and being the at the end, at the end user level, is going to be something that everyone agrees to. But if you don't build that generality at the base level, then you're constraining how things can be built, which is which is the negative impact in my opinion, and that's why I like blockchain systems, because it's more general than a centralized system, which means you can build anything on top of it, but more than what we've already like, learned how to build. And when you start making these types of things like KYC aml, forcing people to do something, you're constraining the type of things you can do. You can always build on top of it, and that's what centivizes, right. Yeah, sentivising is a difference between constraints and incentives. Sure, but you can't impose certain rules. You can only...

...do incentives and DISTANC in has because you have to assume that people are going to act with in their own there they're like what's best for them, regardless of the scenario would our regardless whatever moral or social justice you think should be in place. You can't build something with those with those types of constraints in mind. It just has to be simple human behavior and allow whatever to play out and so that you're overwhelmingly more likely to play by their rules than not, and you can build on top of that in a way that who that aligns with whatever rules that you want, but you don't constrain yourself to it. Well, when I say ky see, I just want to be very clear here. I'm not saying stick your name in the blockchain. I'm saying that you want to build a marcle proof about yourself. Shot, I mean on. So there's a whole bunch of unique identify ifying features that human beings have and you don't have to own that data and it's entirely on a blockchain. But you need to be able to prove that that data produces the information that you want. And you can do that in construct that in a million different ways, and those ways can be personally upgradeable. And that is more of a KYC as I see it. In and yes, I have not I do not have all the solutions for this, but I'm inventing something kind of in my head, cooking it around. I feel like that the ultimate thing we're looking at is every humans going to be their own plasma chaine and that you basically can submit your own facts and claims about yourself and and and those people will be you will have your own truth, sense, truth enus about you that you can kind of maintain on your own and allow that to apply to the greater world by just proving that that truth is consistent. You don't have to actually put it in the chain. You'll have to have literal KYC, you just have to have abstract KYC, and it's so difficult to fraud that that you know from biometric data, just personal facts to an extreme degree. To you know, I don't know, there's I don't have the necessary solution that, but I feel like it is solvable. I feel like, especially as humans augment themselves, is solvable, but I don't want to get into that at this point either. The thing is I feel like as we go down the road and you'll look at what the way things are going or making rapid advancement to so many different ways, the unique identifying information about human being is growing exponentially and they can pick a subset of that which is large enough in easy enough for them to confirm. So I think, like you know what, I like the concept of selective disclosure, like this idea that you know, I can have these as as attestations got, I can and speak today. I can have these adas station attestations Jesus and I can. I can allow access to them as I see fit. But I think building solutions that where the user is still in control, but that where that's the solution is resilient to like key loss or key that where there's like a mechanism for recovery and a continuity of identity. Like building solutions like that. It's really hard. And so there's there's sort of like there's there's kind of two directions that my mind wants to take what you're saying. Like one is like the direction of like how important is privacy as a fundamental property of decentralized technology? Like, is privacy a feature? That's it's clearly like a missing feature and Bitcoin and etherium to some extent right now, and you know, is that? Is that? How important is that feature and how important is it that we get stronger privacy primitives before we go and truly build decentralized technology? And then, on the sort of polar opposite of that, how important is central at centralized authority and identity issuance in this whole space? So, like, and what I mean by that is, like there's a part of me that really wants the government to help with this problem. And the read the reason is that, yeah, when, when, when I studied social networks and social network malware and Bonnets in school, there's this cont there's this network attack, all the civil attack where I manifest as multiple identities and I use the fact that I have multiple idea identities to influence a system in some unfair way. So, as an example of this, like, let's say I created like hundreds of thousands of facebook accounts and use them to convince everyone that trump should win the election. You know, if it's that to happen, no way now. I mean, I got I mean in a lot of the this the even stronger version of that attack is like I buy a bunch of legitimate accounts that have real history and then I implement that attack again. And then, in that case, like you can't even count on the fact that the accounts are generated and linked previously, because they're not. They...

...were real accounts and you purchased them, all right, but in both of those cases it's the problem comes from the fact that there isn't an system that's strongly tying digital identity to human identity, and the government has historically been the part that the system that prevent that protects us against CIBIL attacks, like the government is responsible for managing social security numbers, even though they're an abomination. You know, from a from a security and like cryptography perspective, the unites this government manages some of this coupling between digital identity and physical identity, and without having that system in place, there's there's real risk of CIBIL attacks and of information manipulation. And, you know, a part of me really wants to be able to, you know, go to go to the DMB and set them as like, you know, one part of my social recovery scheme. So I can, you know, have my lawyer, have the US government, have my my parents all share part of my social recovery in case my private keys are compromise and I need to upgrade from one digital identity to the next. You know, I want I want to be able to trust some centralized authorities to help me with that. Well, on the other hand, you know, there's a bunch of risk and concern they're in terms of the privacy tradeoffs. What do you guys think about these things? I once again will argue on the side of generality. These types of things can be built on a layer above the base layer, and I don't I think we should go as agnostic as possible for the thing that's supposed to become the new Internet and not construging some in sides of it, because go ahead. Yeah, I agree with that. But so as the main container of value, you have the backbone. Okay, the backbone is acts as these ultimate oracles, ultimate center of truth. Facts exist in this place and facts are watered down to their most basic parts, the most most fundamental facts, the most truth, the truth, truth oriented things in the most small container of information is possible. But a government doesn't necessarily want that and we don't necessarily want that as participants in the government it government would have its own plasma chaine, to use the plasma chaine examples. The government would have its own systems in those plasma chains for each department of the government. Each state would have their own sections of the their own chains, which would basically create this organizational structures of facts and truths and value. And I think information is value is one of the big paradigm shifts that were got to be really looking at here. Sure, the center of truth is going to have these very, very, very fundamental, bare bones things you're you're suggesting. Absolutely, and as far as that goes, the theoreums the bare bare minimum viable product for that. Okay. But when we're talking about exchange of value, identity, recovery, you know we are. We require laws. These are not going to exist in the main root chain. They're just not. And as far as that goes, you want to integrate these KYC elements in and in the end of the day you might even have a situation where the only people that have wallets in the main root are governments. Are To say, I know you don't know. I mean, that's just one possible scenario to look at here, but it is it. In that situation, you simplified the root chain significantly and created a scalable scenario for everybody else to participate in this KYC in exchange of universal value in a trustless manner. But you have still the ability for taxation and all these other kind of things that we definitely rely on for society to function properly, as well as a system of court and rule which will allow us to contest people who do not have hold to the social contracts that we engage in, which we need. We abs a freaking lately need it. So we're not disagree. I'm not disagreeing with anything you're saying. I'm just saying that when we talk about these areas of identity in KYC, they might not apply on that route chain, but they're going to apply somewhere and with that or do you have anything else? No, I'm it's been really awesome talking with you, guys. Thank you so much for having me here. To all your listeners. If you're interested in etherium and development with IPPS or you want to play around with our framework, you can find us on a GITHUB TRANSMITTA industries. It's all Alpha level software, so please submit bug reports or issues open issues. I will personally help you if you have any trouble using it. And thank you, guys, you know so much for having me on here. The definitely join their slack. They're almost always available if you want to just hit chat over there. They're really great, great guys. So wonder if guys and Gal. Yeah, we also co host the Austin a theorium meet up with consensus, and so if you're in Austin...

...or you're ever in Austin, feel free to stop by the Austin the theory and meet up. It's it's pretty developer focus. We try and keep it about software engineering and not, you know, cryptocurrency trading and speculation. So definitely shout out to Austin. The theorym community is bunch of really awesome companies in Austin building on top of blockchain. Right now, I think you just said awesome. Let's gotta be a thing. I'm surprised that's a thing already. I'm from. I grew up in Dallas. I'd Surprise Austin isn't a word that's used Austin. All Right, thanks, come on our show. Awesome. Thank you.

In-Stream Audio Search

NEW

Search across all episodes within this podcast

Episodes (127)