Hashing It Out
Hashing It Out

Episode 1 · 4 years ago

Hashing It Out #1: Nick Johnson

ABOUT THIS EPISODE

Part of the Bitcoin Podcast Network, we have a new show where we interview Nick Johnson of the Ethereum Foundation. He talks about the Ethereum Name Service (ENS). ENS is bringing human-understandable naming to address resources both on-chain and off-chain. Nick is incorporating a new non-profit organization to support the efforts to build out a decentralized system for creating and managing these names. In addition, we pull from his expertise as go-ethereum engineer to get his take on dapp usability, solidity language quirks, blockchain scaling, and our blockchain-driven future.

Entering past work. Welcome to hashing it out, a podcast where we talked to the tech innovators behind blockchain infrastructure and decentralized networks. We dive into the weeds to get at why and how people build this technology and the problems they face along the way. Come listen and learn from the best in the business so you can join their ranks. Hey, guys, welcome to episode one of Hashing it out with your hosts color, Corey Petty and Colin cucher calling. You want to say hello? Hello, guys, hosts number zero and cost number one. Sure already start with zero. So has you get out some more along the lines of a podcast and wants to dive into technical aspects of blockchain technology, to sugar delator technology, whatever you want to call it. And for our first podcast, we what more appropriate did you bring on Nick Johnson from etherium, creator of the etherium name system, amongst the many other things. Nick, you want to give yourself a quick introduction? Hi, Yep, is alluded to. I'm Nick Johnson. My main project is the etherium name service, which I created about eighteen months ago, sorry, about a year ago. We launched and it serves to bring useful, human understandable names to the blockchain, specifically etherium. I've also worked on goetherium and other projects like community outreach and so forth. Very cool. Yeah, so actually we're kind of curious about that. I haven't followed the NS project much since about June, maybe early July, and what kind of happened with that? Maybe you could tell the story and now that you were on the episode one hundred and twenty nine of the Bitcoin podcast. It was a great episode, by the way. I really listen to it again today as I oh, yeah, there are so many things that actually just came through in that episode, but one thing that I haven't heard a whole lot about is the basically what continued on with the Innur System, and I saw that the last beastly state of the system was in June, mid June. I want to say. So what's the current state of the Ns and how are things going at what's n us now? What's going on with all that? Yeah, so we had a really successful launch, as you alluded to. We sold about or rented out about a hundred seventy thousand domains. Since then we've been sort of heads down working on more features. So with deployed a manager APP which is, you know, much like you might be familiar with to manage your DNS, names and and records and so forth, but for a UNIS. And we recently deployed a tool for very quickly allocating yourself a subdomain, so name your wallet and when clicks sort of thing, because you know, usability is one of the big issues where fake focusing on moment. We've also worked with a lot of clients and other other debts and so forth to get the N S support. Edit. Sort of got over a dozen different applications supporting uns now. But the really big news is that just very recently, and in fact ongoing now, we're splitting off from the etheroum foundation into our own not for profit organization. We're getting independent funding, starting with a very generous grant from the theorium foundation, and we're able to for the first time higher a team, so it won't just be me with volunteers, it will be a full time team working on improving Arnes, and so we've got some big goals there. Oh that's also what kind of improvements? So you looking for? So sort of top of our list is we launched working groups little while ago to sort of get the community involved in improving any specifically coming out with version two of the the NS registrar, so the permanent way that people will register names on the system and also, if it's like, integrating Arns with Dns so that you can claim your regular dns domain inside etherium, and other other efforts along those lines. And we're also, in terms of doing our own development, going to completely rewrite the NS manager and all the existing tools to integrate them into one sort of coherent package. We've got a UX and interaction expert in WHO's helping us put together a coherent and, and, you know, usable Lapp because currently things are a bit fragmented. And basically we're focusing really heavily on user experience. We want to make it as easy and straightforward as possible for people to get started and people to use it. Our medium term goal is that noetherium user should have to enter a blockchain address unless they're a developer. Ind users should just be able to deal with names the whole time and that should be all they have to know about. Yeah, so what were the lessons you learn from the one point of version specifically? So the biggest one is. We knew that the option process would be,...

...you know, complex and would be you know that some users would find it difficult, but we underappreciate it how much difficulty it would create. So, you know, although the the process ensures a fair price for names, it's also, you know, it's easy to trip up and make a mistake with it. So those are the sort of lessons we thought we'd learn and that's why we deployed an interim run rather than launching straight in and saying, yes, this is the permanent set up, but we're trying to, you know, take that and use that to build a better long term system, and that's probably going to involve making it possible for people to register names with just a single operation rather than having to go through the whole option process. I like that. Like a few steps back and try and figure out, explain to the listeners why is this system necessary and what makes it better than the DNS, like, why can't you just use a traditional services to do the same thing you're doing now? What makes ns better than other solutions and how far do you see that going? Are we still going to need traditional solutions there? Is this a complete replacement? So there's a couple of main advantages, and it sort of depends on your needs. But first of all, existing solutions like DNS can't be applied directly to to naming etherium resources. You can't do DNS resolution from inside a smart contract. There aren't appropriate record types and standards for doing that sort of thing. But, more importantly, doing it through smart contracts and on the etherium chain gives you the ability to to enforce restructions and so forth, so that you can make assertions, like I know that I am the only person with control over the record. You know I on this domain in the truest sense. But I would say that the the main advantages is building as a naming system that sort of native to Atherium, which means that any etherium client already has the resources it needs in order to be able to resolve these names, about having to reach out to external systems and with you know the complete security of the blockchain, so you know the records, you feat you're accurate because of the same guarantees that allow you to know that, you know your funds aren't being double spent. And although you can achieve some of that with DNS and DNS sick, very few people actually use dnssick and it's poorly deployed and poorly enforced across the Internet, although one of our other efforts is that if you do you just want, you know, an existing domain, that we're going to make it possible to import that into Aines. So we kind of look at it as offering the best of both worlds. If you want robust censorship resistance, then you can use your dot eth domain that you brought from the auction registrate. If you just want convenient naming with your existing domains, you'll be able to import them and use them there. And in fact we're seeing some interest from DNS registrars who want to use the NS technology to back up their DNAs domains so that they can import all the records the root zone and too etherium and then serve it from anywhere in the world without a worsity of Dias attacks taking it down and so forth. That's act interesting and that's that's more than just like a redirect service. Correct. Yes, yeah, so the idea is, you know, normally with a typical DNAs registry you have the root zone stored on some set of you know, globally distributed name servers, but if they're taken down then, you know, or made an accessible to you, you're out of luck. With the root zone on the etherium blockchain, anyone who is an etherium client and no thinks can access the complete root zone and and resolving record without needing access to those servers. Yep, that's very cool. So what is what is your timeline on a lot of us? Where you going? How do you see this kind of plan out in the near future to the whoar future? So we're going through the whole incorporation process to get set up and fundering everything right now and, you know, hopefully have that done in the next week or so and, you know, make some big announcements about it. And we've already got most of the staff we need have signed up and agreed to work on it and committed their time to it. So we're plant. We're hoping to get started on this, you know, this week, basically this coming week, in terms of producing results. I guess the our timeline for the main yeah, the new APP is probably on the order conservatively, of about six months, just because we want to get this right. We could rush straight into writing the APP that we want to make sure the user experiences right, make sure it's, you know, hitting on firing on all sortanders usability. Wise, in terms of some of the other effits, like the DNS integration and the permanent registrar, I think we can expect to see, you know, starts seeing results a lot quicker than Matt. The DNS Registrar, for instance, so you can register your you know, Yourcom or your Dot Expos toomain in the NS. is mostly they're already it needs some some polishing and some, you know, small improvements and then...

...some Ui for it. In terms of permanent registrate, our goal was always to deploy that circle two years after launch, so about a year from now. But, you know, we intend to have a working version for demo purposes and so that people can see what you know, know what to expect a lot sooner than there. So I made about not understood that correctly the first time we heard it. We you actually want people to take their dark calm down ends and use it in the the so how are they going to actually verify? How are you, how is the system going to know that that, you know, Carlin crouchercom is actually owned by this Wilid ID and that I you know, and how? What's is there any keyc associated with this, like, how are you actually going to manage that? In is there some centralization component that you're going to need to add to this in order to make that habit? So that's the magic of DNS sick. We can create a DNASEI oracle contract on the chain, and we've already written one that knows the root keys for DNS, the ones that are controlled by, you know, ianna and so forth. And given that you can, you've use a chain of trust to prove the existence of any DNS record that signed correctly using DNSSEC, as long as it uses one of the algorithms a theoreum could support, which is about eighty to ninety percent of all dnse signed domains at the moment. So it introduces a reliance on the root keys, you know, the at of fruit keys, and it also introduces a reliance on your registrar, but that in the extends as far as that section of Dns, if you like. So we're basically saying that if you trust the DNS registrar to accurately report your you know, to sorry, to sign on the things that are owned by you then you can trust that your demand is accurately represented in the Ns and if you don't Ben the The dottith registrar is still available for you ben a trustless fashion. So we're kind of you offering users by of tradeoffs and make them choose. Really cool, really cool. So this is an independent organization. You just started, you're just incorporated. It is just an open source project. Still is is something that you're looking for help with? Is is something that people could get involved on this particular project? Yep, absolutely. It is an open source project and the Organization will be a nonprofit one. Will fitted by grants and we'll use that money to both to hire people to work on this when we can, to hand out bounties and just to generally sort of help run the community. But it's still very much an open source project and we welcome volunteers and so forth. The best place to start with that with the discuss dot ein stop domains. That's our discussion board for the working groups and you know, we really welcome and put the air in terms of helping design the next components of the NS. Very cool and your look at you're really focusing on kind of the user interface out of things. But what kind of technical like aspects of this are you feeling like you were going to need to innovate on the most? What are there any upstanding questions that are currently in the system that you could use particular experts on that may be beneficial of the project? Absolutely, yeah, the main the main stuff is focusing around the permanent registrart for dot ees, or sort of the next you in registrate. So for the first version we have this option process and when you want an option, your funds were locked away until you release the domain. If you give the domain back, you get your money back, and that work well enough for, you know, fair way to allocate domains initially, but it's sort of become a parent but not everyone has the same cost of capital. So some people have a much, you know, smaller cost to them of locking away so ether for a year or two years or ten years than others, and that perversely encourages squatting when we would, you know, to some degree when we were trying to discourage it with that mechanism. So the big open questions are around what should we do instead of that, and the most likely solution is to charge a fixed rent per domain rather than, you know, a deposit. How should we option off new names when we first release them? So when we release names shorter than seven characters, you know, what system should we use? And if we're going to charge rent, how should we set what that rent is, because it's pretty an elegant to have a decentralized system and then have, you know, one person who can siser. Could you laterally set how much it costs per year to earn your domain? Much better if we can instead have the system self regulate so that if, you know, there are lots of useless domains being registered and not used, for instance, then the price goes up, and if there's, you know, fewer domains that are you know, or if the usage rate is very high, than the price goes down, for instance. So where we could really use inputs from people who have, you know, clever ideas and building self regulating systems. You know, good game, theory at it founded concept cool, cool, and so I guess that they kind of leads to another question that's kind of been on my mind a lot lately. Is, so you're deploying this on the main etherorium network. How does the current price of ether affect all this. What do...

...you feel like it even you even care? Now that's cover come. You bring up the kind of the game theory side of things. Is The incentivation station model on this, if it's tied to either specifically, and and yet the world is still in a fear world. How do you feel that the technical challenges kind of justify, you know, of the work that's being done here? How do you feel like you you kind of like like if yeah, how do you feel like like this whole scalability issue to like if you have a ton of data being dumped into this one contract, like if this hosting every single to nine in this would actually increase the size of the blockchain quite a bit. So what kind of, you know, solutions are you seeing that would not just about matter price, which is the scale, building, transaction fees, all this kind of stuff? How does it play into your system and what kind of concerns do you have regard to that? Yeah, so for the first question in terms of fluctuating price, that's another reason why we really want to self regulating system because, as you observe, even if the demand on the system for names doesn't change, the price of the ether can change. Dramatically and if we were having to manually set it, they're not only trusting some third party to sit in the price fairly, they're also going to have to keep reaching in an adjusting as as the price changes. So a self regulating system would step around that. It wouldn't care about, you know, the price of ether. Would care about, say what we sentage of users are deleting their domains and we would say, well, we want, you know, to per see demains to be deleted a year as useless or something like that. In terms of the scalability thing, long term is definitely something we need to work on because long term a theorium itself is going to you know, is going to deal with scalability and Nis needs to integrate with you know, if we have multiple shards, for instance, you need to be able to resolve across sholds and so forth. Short term, I'm I'm not overly concerned because the volume of update data for names is relatively low the the actual amount of DNA stater. You know, I wouldn't want to store perhaps the entirety of the DNS global route in in atherium right now, but certainly you can store a sizeable fraction of that in a surprisingly small amount of space. You know, named data is quite small for your typical etherium record. We're talking about maybe like a hundred and twenty eight bites per you know, per domain. So it takes an awful lot of domains to add up to a substantial amount of overhead. But in the long run, you know, as I say, we're going to be dealing with a shattered world, or at least a scalable one, and it would be useful to be able to work with that. And to some degree the NS structure facilitates that. So every domain has to be recorded in the central registry contract, but only the sort of fact of its existence and the address of the resolver. And you can write a resolver supports, for instance, state channels for frequent updates or, you know, other scalability mechanisms without having to change the the core components garages. So you're actually are you more excited at let's talk about scalability. First secuts that you brought it up and it's one of the top is a really like what what is what is your kind of thought on that? There's a lot of work being done in a very different ways. Is Sharuting, as you've mentioned, was also the interoperability. So you get your Polka out and your cosmos and the Internet, a block chains kind of thing going on. There is also your plasmen, your side chains, and then you get your staate channels. What of these technologies you really focus on the most and how do you see them kind of impacting what you're currently doing? So I guess from my point of view, shouting in side chains as sort of two different sides of the same coin. You know, the ones homogeneous, you know multiple homogeneous chains. That's shouting, and the other is multiple heterogeneous chains, that side chains. So I think the tick for those is probably going to mature to similar rate, although I kind of think that show side chains are an easier cell because if you have a bunch of different APPS, it's easier to say, okay, we're going to tune, you know, this chain just for this APP and this will be the Crypto kissy chain and then, you know, chip, point it back to the main etherium chain and provide some way. Just want resources and so on. That's a lot easier than the world and which, like the entire etherium chain, is look more or less randomly into different shards. That's what I think one of the big problems. Sorry seeing that with like what loom network did with the depth chain that they've recently trying to show it's allowing adapt to scale on its own and all quote on quote, Shard while moving alongside the theorem that work. Is that correct way of looking at it? Yeah, exactly, and I think that's easier to easier to do in some ways because you can sort of clearly define the boundary of your system and you expect that every interaction as cross chain. You know, every interaction in your APP is interchain, in every interaction between APPs as cross chain, and that makes architecting it easier. But in the world where you try and sort of just split the main etherium chain and two different chunks, then you end up with the sort of weird, you know, Combo world where sometimes you know other apps are...

...on the same chain, sometimes they're in different chains and you have to interact them in different ways and so on. So I guess I think that side chains and so on are going to, you know, become practical sooner and I think that, you know, proof of steak is going to be a big component of making that possible, because it's easier in theory to write a something that does cross chain proofs with proof of steak, because you know you've got finality, you know you're not going to have to deal with REORCS and so on, than it is to make, you know, one chain and like kind of another, when they're both proof of work. In terms of, you know, some of the other approaches, I mean I really think state channels are going to be the ones that get you know, there's are the first solution we have simply because, you know, for some well known US cases they're really really super simple and for other use cases, although they're more complete, exist, still track to the there aren't really sort of unknowns in there, and I think we're gonna see those, you know, become a lot more successful and a lot more used when we start seeing his k's and, you know, tool see it's that are built for. You know, basically, here's your shot, sorry, your State Channel Construction Kit. So if I had to put any money on it, I'd say that I think we'll see why deployment of state channels before anything else. So you're looking at like the general general state channels, like I think or doesn't counterfactual group is putting out and stuff like that, seemed like, and this bank chain group. Yeah, stuff like that and maybe a variants. So so the counterfactual ones are really cool that they're a little more involved. I would be surprised if before that we see like somebody put out a really simple tool kit for like, you know, the suddenly has limits of utility. You're going to use it in certain feel you know, certain applications, but if your application fits, then hy Prestole, you know, plug this library and then you're done. You know, isn't that I see? I see for his back up and to kind of do even like a little more of a of a diver do different types of state channels. You have something like micro radon, which has which was a kind of go for litle expose a at De cone three, where it's a one way state channel and which one person is sending multiple small payments to a single receiver. Then you have a fullblown state channel which is two way and that two people put down a deposit, they then move money back and forth very, very rapidly off chain and then they settle that deposit. And then you have something like funfair spank chain counter factual. All counter factual is another one to talk about this moment. You have the generalized State Channel, and which you don't aren't just sending simple payments, but are updating generalized state of particular smart contracts that are off chain. And then you have something maybe like counterfactual, which is so all of the ones beforehand require to on chain transactions, one to open up the channel, one to close the channel, and something like counterfactual, if I understand it correctly, only seems to require one. I think they in some cases even zero. I don't know how that works, but in that you just open up the idea of a channel with somebody, you then pat pass signed messages back and forth as much as you want off chain and then when your conclude your business, you basically post the settling transaction on chain. And these are the ideas of state channels, which allows people to do, you know, two people or potentially multiparty people to do as much business as they want while minimizing the actual on chain transactions. That all that? All correct? Yep, and I think you pretty much describe them in order of a seeming complexity and usefulness. How about that? So I thort you said that, as as one scaling mechanism, how does that interplay into the other ones? It's a good question. It's that for some that will be all you need, as you observe with with counterfectual state channels, you can you can have not just one but a series of interactions with only a single final transaction on chain. So you could, you know, play, say, a series of chess games or, you know, a series of different sorts of games or business transactions or whatever, and then settle them all with one final transaction. And for that sort of application where that suitable or the the single that might be all the scalability you need. That can support in an awful lot of users. But there are applications where that doesn't fit so well, for instance where you have many users who interact more or less randomly with each other, so setting up individual channels between each pair of people isn't really practical, and so then you're faced with either a sort of a hub routed network similar to lightning...

...and the eventual plans for Raidan, or you have to go with another scaling solution, like you know, as a side chain. The may be applications where you can combine, say, side chains and state channels. So say you have one really high volume map where even the closing transactions are, you know, more volume than you really want to put on the main network. But I think that in the short term we're likely to see people adult one or the other simply because they don't need the additional complexity yet. You know, it's more likely that we'll see those combinations in the long run where even side channels start to get expensive, for instance. Well, one other aspect of side channels that you kind of left out is it you lose data, you lose an audit trail and for a lot of the people I've talked to, a lot of the drawer that's coming with the you know, things like Ethereum, a one on watchings in general, is at you could kind of keep an audit field how you got from point a to point B and was so generals. You can take that completely off network and you lose that data. You may lose that sage. Yeah, well, yeah, cord us. If you're not then you may never be able to recover it. What's that? If you're watching at the time, then you can record it, but if you're a certain you may ever recover it. Once the side channels closed or garbage collected or whatever, but you need to put that history into the blockchain, and that's kind of the point we're trying to I think, trying to avoid with a lot of these things. So you don't want to go through that that rigger Maru and also pay that storage fee, which is why I kind of mean like, okay, stick these channels are great for now, but I'm still kind of like thinking plasmas the next kind of way of going. Personally, I have a kind of a I just I just think it's a good idea to experiment imply as we are right now. What are your thoughts on putting the arns system into something more of a plasma, like its own chain that connects to the meantnet? Have you given thought to that or I have a little, like I said, like I saying earlier, I kind of want to see how other applications evolved to use scaling first so that we can serve them best. From one point of view, having your own chain for ns would be pretty straightforward and and you know, a placema chain would be pretty much perfect. And that's assuming you're doing most of your resolution off chain. So you're doing it and wallows APPS and and deps with Webbin to faces and so forth, we're it trips up a bit is if you want to do resolution on chain, which is currently straightforward and pretty affordable gas wise, or if you want to update things from inside, you know, contracts that might live, you know, outside the NS world, then you have to start doing cross chain calls. It gets a synchronous and expensive and so on. So I guess it comes down to, in the end, the relative you know, the tradeoffs of how expensive it is it to keep it on a on the main chain as opposed to a side chain, and how much of you know how prevalent those use cases are. Look, another way of saying that is who cares? I mean who needs to access this information and what's the most efficient way of optimizing those people accessing it within speed and cast? And so whenever you're designing whatever application you're doing, you need to take mostly those two things into account. Who am I interacting with and what are my trusts associated with those people? And the more you trust those people, the more you can move it to an off chain transaction. If the entire community needs to access what you're doing, then it's going to be closer and closer and closer to the mean. That yes, and in fact, in terms of how complex this would be, the root eins contract, what we called the registry, is very simple. So in terms of practicality of building this, it would be relatively straightforward to have a plasma chain that the checkpoints to the main chain and you wouldn't even you know, you'd need the whole sort of appeal process, but you could execute any step of that on chain in order to verify it. So you've can come to an objective source of truth and so on, even though it may not be, you know, utxo based, like the initial plasma applications very cool. So are you kind of a one world blockchain guy or an Internet of blockchain goes? That's a good question. I I think that we're hitting in a direction where plasma and and things like it the the most obvious solutions. So we'll have sorry, are you asking about scalability future or you to asking about maximalism? maximalism, so I kind of want to know, like it's like like I brought it up really so there's the look it up, you know, poke it art and Cosmos. Not all these things that are trying to, you know, swap between blockchains are completely independent of each other logically and you know, work have them all work together in some way. You know...

...you're pretty focused on atherium and, to get more philosophical here, do you believe that a single source of truth is kind of more important than the ability to have your own truth value in your own chain that kind of interacts with that truth value? Do you see the world adopting one backbone of truth and that being one world blockchain, or do you see there being many ways of looking at value and connecting those ways will be the challenge. I guess what you said about Indoness of blockchains kind of reasonates and that I don't think we're going to have just one blockchain. I think we're going to have a lot for specific APP patients and they're going to be, you know, all over the show. But just like the Internet, I think they will all be tied together in some fashion, or at least the bulk of them will. So we will probably have a chain of some sort whose main job is just to to you know, chippoint state roots for all the other chains and allow them to interact with each other more easily and you know less than us. You know, rather than a starfing it. Maybe that's the backbone, but you know, you also sort of peering links between chains where it's relevant and so on, and that pretty matches the internet actually, because it is a whole series of smaller networks that are joined together with the backline and you have these, you know, offline networks that just don't interesting connecting to the Internet and we look at it as one b against you, but really it's pretty rougenous bunch of staff. And on top of that, I think what's important to note is that the only reason that works for the Internet is because they all follow a single kind of rough outlined protocol and how they and how they operate and move forward. And so what I think we'll see, at least in the being first implemented in terms of Internet of blockchains, will be all blockchains that follow something along the lines of the EVM. And however, the evm moves forward, and so a lot of that's why you see a lot of the third generation or next, quote unquote next generation blockchains being evm compatible, because it becomes much more complicated when you try and cross talk between two very different blockchains and how they operate. Like thinking about how to the etherium would connect to iota or bitcoin or something something that, like a utx base model is much more complicated of an issue than something like what definity is trying to create and that they're following the same basic protocol, just doing it on the back end differently. Yeah, just I actually said, did some did my homework on your neck. So you have some recent post on read it. We spoke a lot about it, the improvements you'd like to do on on the etherium, theorium protocol itself and the evm. Maybe you could go over some of the those things. You actually have a full list. Yeah, I guess from my point of view etheriums are pretty remarkable construction. It's got some really cool stuff, you know tike in it, but it's also it seems to me from looking at some of the aspects of it that it was designed by smart people who knew their computer science but hadn't spent a lot of time doing practical engineering on large scale systems. So there's things that make perfect sense from a cus point of view and a crypto point of view, but you would have done differently if you had been familiar with the you know, the real world constraints, and that sort of covers most of the things that I would, you know, in my imaginary super etherium change. So examples for that are, for instance, have the Meracle Patricia Tree, that sorry try, which is, you know, how everything's stored on disk. You know contract state and account balances and so on, and it is, I guess you call it, kind of spindlely that, you know, each node has relatively few subnodes and the result is that when you want to fetch a piece of data, you have to go, you know, many levels down the try and you have to fetch, you know, many and of aduaams from disk. Each of us ship, which are very small. But real world discs don't operate like you know imaginary you know random as his memories. You know hard discs have seek times and you know their bandwood is high, but their latency is also very high and you have to seek from place to place. This is these don't have seeks, but they still have a tradeoff point between what the optimum size of block two features. And so in ideal data structure would take that into mine hind and it would have or into a can count much larger nodes, you know, or it would combine multiple as nodes together into a single disk ensity, and that sort of thing could have led to, you know, significant performance improvement on reading and writing state updates. It's it would be difficult, but not impossible, to sort of retrofit back now. You know, it would be definitely more significant change than any of the ones that have had forked and so far. And there are other things like that, like choices around the structure of the EVM and so on. That again, you know, I see us sound but didn't take...

...into account real hardware. And most of those speak to performance applications, some of them speak to sort of future upgradeability and so forth. Yeah, and one of the things you brought up that I thought was something that's always kind of vexed me is when you're doing when I was doing contract development, just the the the size of a single unit of memory is always two hundred and fifty six bits. Yeah, and I was like yeah, that's that's that's just not efficient storage at all, especially in a storage heavy system like a block chain. It's like you're distributing your storage across the network and yet you choose them you know, everything is two hundred and fifty six bits and size. You can make it smaller, but it actually is no benefit at all to do that. It maybe would be a cost because you have to add something to check to like the really have opps to manipulate a smaller piece of data, and so that's like to me. That seems the opposite of how you should do but I'm sure there's choices, reasons they made those choices, but it's a good example because it's a very attractive theoretically pure solution. You know, we're in the going to have one Vata type. It's going to be an integer. How big should it be? Well, all of our addresses and now keys, sorry, all of that, you know, internal addressing and so on, and our keys now signatures are two forty six butts. They're going to need to be able to deal with two forty six but values, you know, for excessing stuff. So why don't we just use that everywhere? You know, now it's net entidy but, as you say, that comes as with a real world practical tradeoffs in terms of efficiency and not just storage space but computing. You know, if you want to add to you know, thirty two bits intages together. You you still going to have to use big math, like, you know, five routes, because it doesn't know they're not to six bits. Right, right, yeah, and I feel like I feel like a lot of the stuff that I've noticed in this early stage has been just lacking empathy, from both an enterprise standpoint user interface standpoint. But the thing that it's really important as week, it gets the message across, and I feel like that's where etherium has been successful so far as it's it actually makes progress. They just did it. They might have not done everything optimal, but it got the job done and now people are talking, now people are exploring these technologies and I can actually deploy smart contracts and you know, maybe it's maybe the rushed nature of that. I call it rushed, maybe they call it thoughtful, but the nature of it seems seems to work out in the long run anyway, because, you know, there's success. There's definitely marked success in what atherium is doing. Speaking of success, do you think the NS will be tokenized at any point? I don't think so. I mean not nft, I mean like the Arc Twenty L. is it good to see? Yeah, I mean disclaimer here. You know, I said that we're really looking for people who have some system design ideas. If somebody came along and said, look, with found a way to solve all of your problems, you know, to make rent fair and and you know have a system that you know allocates, name is feely, and make sure that the prices are right and so on. But to do that, if to a shoot tokens, I'd be like fine, will less you tokens, but we're only going to do it if it's like an asset to the system, if it's something that fundamentally makes it operate better, if it's just you know, it's that, there's no real reason to a shoot tokens. Got Ya. Also, it's not like engineering answer. Oh go ahead, court, such an such an engineering answer. I don't know. If the technology fits, then sure, if it doesn't, have a way would I use it? Exactly. Also good business answer to I mean, you don't want to tooken to seem to be adding a bit of a risk element. So whatever is going on right now, we don't know where they're going to go, we don't know how they're going to be represented, we don't know how they could be treated, whether or not it's utility token or are not. It's a little difficult to ascertain. What you know are are you printing money by doing that? Is that something that certain governments would straught upon? Which ones? There's a lot of the questions in gray area surrounding that. So I mean I think it's wise from all fronts, but yeah, it's pretty engineering. It's so. Speaking of which, like these are all all of these, these these names that you're sticking up at these domains, they're going to be represented by the seven hundred and twenty one or the I think the nft It's some twenty one or seven twenty five. I bring doesn't want to recall that. Thank yeah, seven ti or the other, which is the same. Yeah, I've given it a little thought. It probably makes sense to make the the new registrate, you know, E. SE seven twenty one compatible, just because people are developing like Genero size, you know, auction contracts and you know, other ways to interact with and manage those resources. Bearing in mind, of course, that's only going to be your second level dottyth names, so that doesn't mean the whole system, you know, every name would become a seven twenty one token. Because the base system is a much simpler API than that and of course was Wrissian before seven twenty one existed. So, you know, definitely something...

...will could implementing, but only for the the dotty th registrate. Do you think you've migrate to seven twenty one system? It seems like it's being adopted quickly as a standard. Thank you. Hello Kid. He's by the way. I'm no hell. COULD HE CRYPTIC? Whoops a. So there's one component to the inns for the registry which should be very difficult to upgrade, in that we would have to copy over every record and then tell people to use the new one. You know, be more or least manual, and that was, you know, intentional design. Will have this one component which is your like sort of indirection layer. We make it as simple as possible and then, you know, that points to all the upgradeable birds. So if we really wanted like everything to be a seven twenty one token, we would have to replace that. I don't think it's likely, simply because I don't think the value warrants it. The current contract is about a hundred lines long and if you delete the comments it's about fifty lines long. There's no loops, there's basically no left statements. It's about as simple and as trivially audited auditable as you could possibly hope and I'd be very reluctant to compromise that by byetting complexity. At least we could show like a really compelling use case for it. So okay, that makes sense. Yeah, I kind of feel like you would treat a domin and same way you'd kind of treat a token, and that you'd want to transfer it easily between one party and another without a lot of barriers. And since there's already standard interface for that with the nft standard, it seemed to me that logically, from a user interface stampoint, it would actually make sense that you could integrate tool sets which also adopt an Ft. so the good thing is contracts can own names and that means that you could write, you know, seven hundred twenty one, you know rapper, for instance, and that owns the name and then can deal with, you know, tokenizing it. That makes perfect sense. Yeah. So what about identity? Do you feel like the identity standard is getting any traction? Maybe some KYC elements of what you're doing with the INN US some yeah, I haven't heard a lot of people, you know, working on identity and talking about a anes but being most be if it's around identity that I've seen have been keeping feeling quiet in general. So so I don't know what they're using a different it's definitely something I'd like to see more of because I think that Tye and identity to a name is a fundamental component of the whole thing and I think Ns has as well placed to do it because certainly with the dot eith top level domain at least you can handlestead of guarantees you need about control over that name. So you looked into like it your see? Twenty five? Yeah, one, the Fabian Foco stellar, is proposed for a for identity at all or only at a very high level. I'm an eat editor and I try and keep up on stuff, but often I, like you, skin the original proposal and read the comments and the instead of for the time because I just don't have time to read them all. Yeah, yeah, I'm the same way. Yeah, totally, especially when to get three white papers every day. Yeah, what are the pushes to abstract addresses on is network? How does that plan into the NS system? And and first off, can you give an overview of like the what it needs to abstract addresses away and then how it would ploy into you knows. So I guess Eannis in general is an attempt to abstract addresses away, but I think maybe you're talking about the metropolis hard fork suggestion of account substruction. Yes, so in account abstruction you still have addresses but you no longer have the same distinction between external accounts and contract accounts. You would be able to provide source code for just aboid any any account, and that source code would, or bite code would determine how signatures were validated and how fees were paid and so forth. So the idea is you take a bunch of stuff that's currently hard coded into the base of the etherium system, like checking answers and paying mining fees, and you would turn that into, you know, flexible stuff that can be done through contracts. And that was originally planned for what became Bozantium, but it became apparent that there's it changes a few invariants and system that the people have been uncontraporously relying on the going to need to be a pretty big warning period and plenty of time for people to update their expectations. So one example of that is worth account abstruction. You could write an account and have a transaction that gets mind multiple times. So you could have, for instance, an alarm clock account that anyone can submerg and you know and run the alarm clock and it gets paid for by the people that you know wanted their contracts triggered. And that same transaction, it wouldn't have a nonce in the same way as the current one does, could be submitted every block or every tenth block or whatever, and that would have the same transaction...

...hash, but it would have executed hundred or a thousand times and lots and lots of code. In fact, pretty much all the code at the moment treats a transaction hash as a unique identifier for the actually execution, not just the contents of that transaction. So it would break a lot of stuff if suddenly it could be executed five or ten or a hundred times. Doesn't that doesn't that also have implications on who pays for what? It's that over right now it's whoever sense of transaction pays for it. Doesn't this change also make it so that the receiver pays the gas fees associated with the transaction. Yes, so that's the that's one of the big use cases for it actually is being able to build systems where somebody else pays for the gas, so, you know, make it easier for users to interact with APPs and so on and controlled fashions. The question, of course, is how a minor knows whether it's going to get paid at all when it excuts transaction, and there's basically a couple of suggestions around that. The simplest is that each minor would have a white list of by of contract bike codes that knows are trustworthy, basically that no you know knows will pay its fair share, and then, if you want, launch a new type of account which you would tear to, you know, standardize that code and then coludes the miners that you know that it's safe and they can turn it on. Basically, there are other, you know, more complex suggestions, but they ultimately, you know, the minor needs some way to cheaply determine whether whether it's going to get paid. It sounds like a credit score, sort of, but kind of a little. Yeah. The the issue, of course, is that since the contracts that you're incomplete, you can behave arbitrurily sneakily. You can, you know, write something that behaves well for a while and then stops paying the miners, you know. So it seems that the only options really are either to have some way for the contract to pay the minor at the beginning in a way that can't be, you know, undone with the reverse or whatever, or some way for the miners to like, you know, for humans to go in an assist them and choose which ones are safe. Well, couldn't couldn't it be part of the basically pre prepare the propreness? Or basically you prepay and you can actually order funds, whatever is in your bank account for the payment, kind of like, you know, prepaid cell phones. You would basically can treat it the same way. You do have to pay this much and, Moman, it's are up, we start doing work for you. altly. You could, you know, the minor could run, say, the first thousand gas with the transactions and see whether they're prepaid or with the instructions and pre see if they're prepaid by the time they get there and if they have, they keep on executing. But of course you need some way to make sure that prepay can never be, you know, reverted, so it might need some changes to Bebm to support it. I think it's very cool but, as I say, it's going to change the assumptions. So to actually get it rolled out we're going to have to, you know, solidify how it's going to work and then give the community lots of time to update. I'm pretty sure mandity, if the scan, is going to be pretty unhappy. So what is your what is your thoughts on upgrade paths for these protocols? I've been obviously a lot of what you've said throughout this this you know, interview has as evolved some some lacking things in both the EVM and just a protocol itself. What what? What do you see as being? So how are we going to upgrade? Is Hard fork sufficient? Is there some some other mechanism like it was? T has us that they had some sort of way of upgrading, but it was pretty much centralized. It is there was it has us. Oh well, is there some sort of like what do you see being the path upgradability on the network? I'm kind of with the town I can plant on this. I think that forking is actually an air seat in US regard and and having governance off chain as an air set in this regard, because it's what gives block chains their power effectively, is that they consent, consensus and consent based systems. You can't have a majority billium minority into accepting a chain change to the chain, because the minority can folk off and create their own chain with like Jack and hookers channel. I'm a yeah, basically that you know the stasis is the default and that you can build your own, you know, your own variant, but you have to convince people to come along effectively, and the problem with on chain government systems that are shooting that the majority should automatically be able to do the thing they want is that they take away that opportunity, or at least they make it a lot more difficult. So do you think I see just sufficient forcing upgrades? I think it is. Yeah, it's. I mean, one way or another, anyone who wants to keep going with without, you know, a given upgrade will at least have to fork to change the Ice Age. So I think it does a good job of ensuring that stasis is an option, but not indefinitely. So you know, you you you're going to have to make a choice and to to make a change,...

...even though you're the one you know, you get to choose what that change is. Cool. Well, I just have one more question before I'd hand it after the cord to wrap it up. What project you kind of most excited about the theium spect right now? That's a really good question. Tell me right like, I really want to know what's out there that I haven't seen. Maybe something that it's kind of on the fringe, that most you know, you've heard about but it's not really gotten a lot of traction yet. HMM, putting me on the spot here, but I don't say that most of the ones that come to mind are ones that people are pretty aware of. Like I really like whatever gone are doing. I like their whole radical transparency transparency stick, and I like that they're building like practical tools for real world companies to use to, you know, be more transparent about their governance and so on. I know, you know, bank or or a bit sort of ragged on and full disclosure. I ordered their contract and I've, you know, they've they've consulted with me occasionally, but I think that the attackers is pretty neat, you know, in that the idea of being able to do like an instant on chain synchronous transaction to get, you know, a change between eating two coins is pretty neat. I guess the stuff that excites me most of the moment is actually some of the scaling efforts, which aren't necessarily, you know, big ICOS or whatever. They're just research efforts. And some of the other stuff that that excites me is sort of further off, for more hypothetical, like I would love to see somebody build a random number dao based around blas random beacons. I, you know, love to see some of the zk snack stuff that is now possible getting better language support and being more widely deployed. It's yeah, I guess one of the other things I wanted an excuse to talk about, in fact, was stateless clients ladders. Is really not a fan, but I thinks a lot of potential we are to build a system that scales better simply because it doesn't require over and Di store the stuff. You know. Can You? Can you explain that a little more? So the the really short version is that instead of actually recording the transactions on the chain, you you submit the transaction, but you only keep track of the final state and you store all of the individual data for your APP locally, and so basically everyone who wants to use a particular APP has to, you know, fetch that data from you or they have to watch the chain to get that data. But individual nodes don't need that data in order to be able to verify as a transaction as valid, because each transaction actually includes that it's in its own input data and proof that that is part of the data set. So if you take, for instance, a token contract as a set of balances and so on, the users of that token contract to the only one that have to store a complete copy. And if I want to transfer ten tokens from me to you, all I have to do is send a transaction saying transfer Tin Tokens, and here is the proof of my current account balance, using like a mercle proofs, and if the nodes are able to verify that, there was a difference between that and a complex events system that we already have on a theium. So the events let you prove to a light client or a full client that something happened and what the details were. But this leads you actually enable effectively full clients that don't have to store the data in the first place. So with this, this sounds to me like you're also you sending additional data. That's well, I guess a technically would always be sent like this. Is increased network use, utility of the of the protocol at all ors. Just how hous usage of their protocol. It dollars like u like. How would that impact things global? He it would. It would increaseingly, would utilization because, as you say, you'd have to carry along the proof data. Yeah, OK, the transactions get bigger but the chain get smaller. I could be less finish. You do important future. Yeah, all right, I think that's a that's a great way to wrap it up and I always kind of enjoy hearing what people are excited about. It gives you a really good overview of where their focus is based on what they're looking forward to. And all of your answers were basically all infrastructure level, which tells you kind of where you think we are as a whole amongst the entire technology and what we need to move forward. And from what I clean from what you said, we need more infrastructure, and I want to stay mil this platform type things that enable people to build things. We're not too you don't care too much about what the end user is seeing in those types of applications relative to the things that are enabling people to build those things in the first...

...place. I I definitely agree we need more infrastructure. I wouldn't read too much into my focus on infrastructure because they what I'd see is at that, regardless of damage you of the PLATFORMANS. That's what I love working on. Yeah, I mean, I guess I am aligned with that, with that viewpoint. So that's what I saw from it. But thanks for coming on the show, Nick. I appreciate all the work that you've done for the entire space and keep doing it and then thanks. Appreciate it. CANS.

In-Stream Audio Search

NEW

Search across all episodes within this podcast

Episodes (127)