Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Andrew Miller: The Gas Model and Ethereum’s Economics

Episode Date: December 28, 2015

Andrew Miller is a computer science PhD student at the University of Maryland who focuses on cryptocurrency. Having gotten involved in Bitcoin in 2011 and focused on cryptocurrencies early in his research work, he is one of the most prolific researchers in the field. Our discussion mainly focused on security aspects of Ethereum including their gas model, Proof-of-Work algorithm and plans to switch to Proof-of-Stake. Topics covered in this episode: How he got involved in doing research on Bitcoin and cryptocurrencies The blossoming of academic interest in the topic His work on analyzing Ethereum’s gas model Potential vulnerabilities of the Gas model Ethereum’s PoW algorithm How Ethereum handles the block size limit Episode links: Andrew's University Website Ethereum Analysis: Gas Economics and Proof of Work Overview Ethereum Analysis: Gas Economics Ledger Journal Hawk: Privacy-Preserving Smart Contracts This episode is hosted by Brian Fabian Crain and Meher Roy. Show notes and listening options: epicenter.tv/111

This is Epicenter Bitcoin, episode 111 with guest Andrew Miller. This episode of Epicenter Bitcoin is brought you by Ledger, now accepting pre-orders for the all-new Ledger Blue Developer Edition, a Bluetooth and NFC touchscreen hardware signing device. Learn more about the Ledger Blue at LedgerWallet.com and use the discount code Epicenter to get 10% off your first order. Hello and welcome to Epicenter Bitcoin, the show which talks about technologies, projects, and startups driving decentralization and the global cryptocurrency revolution. My name is Brian Fabian Crane.

And I'm Meher Roy. Today we are joined by a very interesting guest. His name is Andrew Miller. And I've been following Andrew Miller's work for the past few years. Some of our listeners might know him as Socrates 1-024 in Bitcoin Talk. He has made such great postings on that forum that it's very interesting. He is currently a PhD student at, the University of Maryland and he focuses on mostly his work focuses mostly on cryptocurrencies.

Over the past few years he has done various interesting research projects such as replacements of proof of work to discourage mining pools, new ways of exchanging currencies, like decentralized exchanges, ways of making order books, ways of enhancing privacy, etc. So he's a very interesting guess we have today. But before we start, perhaps, we should take take out for some time for Andrew to introduce himself. Andrew, can you give your introduction? Sure, thank you for the introduction. Yeah, I'm Andrew.

Like you said, I'm a PhD student at the University of Maryland. I really like doing cryptocurrency research. I especially work on programming languages and cryptography, but I'm interested in kind of all facets of cryptocurrencies. So how long has it been that you've been interested in this area? I think it would be about three to four years. now. I remember when I was just getting started on this, I would post on Bitcoin talk as a way of kind of trying to see if there were viable research topics. And I started doing this full-time

and transferred to the University of Maryland just to work on cryptocurrency research in the beginning of 2013. How was that received at the time? Was that looked at as something bizarre and did you get resistance from your advisors? Yeah, yeah. It was a very weird process. I mean, I was in computer graphics at the time at the University of Central Florida. And my advisor then very patiently, you know, allowed me to go off on this tangent, you know, kind of dropping all the other stuff that I was doing in computer graphics and pursuing what would have seemed to be a completely ridiculous tangent to go off on on this cryptocurrency stuff. At the time, it wasn't nearly as big of a deal, you know, as it is now. So it didn't, you know, I fully imagined that when I got it started doing Bitcoin research, that Bitcoin was going to crash

and I'd be there trying to tell people know, hey, this is actually a really great idea there's like theoretically interesting things you know, it's still a good topic even though everyone's forgotten about it. But then that turned out not to be the case at all. Now it's a household name so it's a lot easier to talk about but at the time it seemed like a really big risk to take.

Yeah, but also a risk that probably paid off. Because now also on the academic side there's so much interest and I don't see that going away anytime soon. And of course, if you know, you're sort of among the first who have really seriously pursued that. That is a great position to be in. Yeah, absolutely.

I got in the ground floor of cryptocurrency research, and that's been a lot of fun. So we had some difficulties, like choosing what topic we were going to talk about. Because Meijer, as he mentioned, he's been following you for a long time. And so he put up these big list, like, super well research of, like, all these things you're going to have to talk about. And I looked at him, it was like, oh, this is going to be either it's going to be a three-hour episode. or we're going to have a very cursory superficial treatment of most of these topics instead of have to hurry through it. So what we've said is like, well, let's sort of push off a big chunk of it,

and perhaps we'll do another episode to talk on those projects. And let's focus purely on Ethereum. And you've done some work on Ethereum. You've done a security audit on Ethereum. And in particular, there's a lot of interesting intricacies because I think Ethereum has done a lot of attention, but it's hard to understand. No, it's, it's hard enough to understand Bitcoin and it's not exactly easier to understand Ethereum. And I think some of the work you've done should provide us a good window to kind of dive deep into that. So I look forward to that a lot.

Yeah, let's go for it. Let's go for it. Yeah. So tell us, what was the security audit the first the first time you kind of got involved in Ethereum or have there other things been before that? So I had looked into some issues with Ethereum and smart contracts. I made a forum post on the Bitcoin Forum pointing, not the Bitcoin Forum, one of the Ethereum forums, actually I'm not even sure exactly which Ethereum forum, and pointed out a couple of things that interested me that seemed to be hazards that no one was talking about, about things that can go wrong when you're trying to compose complicated smart contracts. I think the one that I wrote about was some weird condition that can happen when a contract sort of calls itself, like a recursive function that calls itself, and you can get these kind of interleaved states that are a little bit unexpected.

So I think it was really on the basis on that that they asked me to help with the security audit. So that came after these things that I had just done on my own. And so the audit then was performed. That was before the launch of the actual beta launch. at some point, you know, after the crowd sale as a sort of, you know, in the final stage before Frontier went live? Was that when it happened? Yeah, yeah.

It was several months before the launch of Frontier. And this was something that was done joint with least authority, you know, who make Tahoe laughs the distributed file storage project and who are now involved in the zero cash launch. So did your audit of Ethereum focus on certain aspects of the system, or was it, like, like a general code audit starting from design and ending at code. Absolutely.

It was very targeted. I wouldn't even call it a security audit. It was more of a spot check. And we had a very specific scope that we were going to look at. Ethereum also had a full-scale general security audit and hired a bunch more people to do the general view. We really focused on two specific things, which were issues related to the gas mechanism and incentives,

and also on their proof of work puzzle. And those were the only things that we were looking at. and we would call it an analysis rather than a security audit because we didn't try to go, you know, exhaustively and catch everything. And for that matter, also our main point of entry was the yellow paper itself, the on-paper reference rather than the particular code implementation. So we try to look at design issues. Okay.

So for our listeners who haven't actually gone through Ethereum, everyone knows White Alex white paper that laid out kind of the vision for Ethereum, but Gavin Wood came out with the Ethereum yellow paper that describes the Ethereum system in mathematical notation. It's quite a complicated paper, it's a long complicated paper, but it really is the heart of the Ethereum system because unlike Bitcoin, Ethereum has many different implementations like there's Ethereum in the Go language, there's Ethereum in C++, and all of these implementations are supposed to tail the Ethereum yellow paper. So you can think of it as the main specification document.

for Ethereum on which the clients are made, right? That would be right, Andrew? Yeah, yeah, absolutely. Bitcoin's reference is the Bitcoin Core C code, right? And Ethereum's references the yellow paper. So basically, you performed an audit of the yellow paper, like not an audit, but an analysis of the yellow paper about what it does well, what kind of attacks are possible in that system,

and how does the proof of function perform, etc. Yeah. Okay. in general how was your experience interacting with the Ethereum dev team do you think they were responsive to criticisms or suggestions you came up with? Yeah, I really enjoyed it. I thought that they were very responsive. They were very helpful in answering any questions that we asked really quickly. Even just as you're bringing this up, it's reminding me I really liked the getting to get some visibility into their development process. I thought it was really interesting and I think a pretty good idea. You know, if you can afford. it to develop several different competing implementations that are all expected to be in sync. So, you know, if there was ever a implementation bug where the C++ version and the Go version diverged,

then, you know, all of the developers would sit together and, you know, look at the yellow paper too, and they would figure out, is this an error that's also in the yellow paper, or do two of the specifications match the yellow paper? And, you know, doing it that way, because the code bases are so different and they're all done entirely from scratch, you know, implementation bugs tend to occur one, but not exactly the same way in the other. So that is a good way to catch them. And in that context, the yellow paper is just an other one of the reference implementations that's supposed to be in sync with all the others. Right. And then so you mentioned gas and I think that's an interesting, interesting way to sort of dive into that because in Ethereum, right, computations are paid with gas, right?

So the whole idea of Ethereum basically is that you know, you sent transactions and contracts, and all that to this chain and they get executed and you know paid by gas and so you pay for each computational step by gas at the same time the currency of ethereum right is ether so that's i think that on its own is sort of confusing because it's like how do those two relate so can you explain it a little bit why was it even necessary to have gas right can you just pay everything with ether i see so you're asking especially why does there have to be any sort of conversion between gas and ether. So the way that that works in a transaction is that when you make a transaction, you say this is how

many, this is how much gas that I want to pay, and this is the conversion rate that I'm willing to pay for ether to gas. So the rationale for that is the way that the gas mechanism is implemented is that each op code in the Ethereum virtual machine has a sort of fixed rate of how many gas tokens it costs. And so, I mean, the reason that there's this conversion rate is because you don't want to have to change the fee schedule in gas units per op code every time the price of ether changes. So the reason to have those two is just so you can decouple the market price of ether from the sort of relative costs of different op codes.

Okay, so you sort of have, you know, let's say sending a transaction costs 50 gas, like each step costs 10 gas, you know, you have all these different things and then, but the real cost is going to vary, right? because the real cost is going to depend on, well, how much ether you have to pay per gas. And then that is, again, a sort of a market mechanism. But from a programming perspective, I guess the advantage would be that you can hard code, you know, this is cost this many gas without having, you know, to change that as, as the cost of ether changes.

So the demand changes. Yes. Yeah, exactly. And in the program code, you know, it's come into, there are instructions that let you see how much gas is remaining when you call another contract. you can kind of carve off a portion of your gas remaining, and so the units that you use for that kind of programming is always in gas, and so it stays kind of static.

So what was your overall impression of the gas model? Does it make sense to you? Do you think that's, they went about it the right way? I think it makes sense. I'm impressed with it. I think it's quite novel. I haven't seen any other programming language that really features anything like that,

so I think it's a really clever and, good idea. I think it's pretty effective. So like Ethereum device gas because fundamentally in any program it is not possible to know whether it's going to terminate or not. So if you don't have something like gas, then you could have a smart contract that has an infinite loop and keeps going forever. And then you need some way by which you know how to exclude these infinite loops out of the picture. So do you think the Ethereum gas model will be effective? at this aim of preventing infinite loops? It's absolutely effective at preventing infinite loops.

That's a problem that this adequately solves. I mean, that's not the only way to go about preventing infinite loops. One thing I'll be happy to dig into is that I think that the Turing completeness goal is a bit overstated or misinterpreted. So while it's true that for an arbitrary program that you have, you can't check whether or not it has infinite loops or not. It is possible for most programs that you want to provide a program along with a proof that it does terminate. So for most programs of interest, the programmer can provide some kind of proof in a program analysis format that guarantees that it doesn't terminate, that it doesn't have infinite loops. And you can have languages that are very expressive and that aren't fully Turing complete and that don't support these infinite loops but are still expressive enough to carry out a bunch of tasks.

On the other hand, gas would still be useful because just because a program doesn't have an infinite loop doesn't mean that it won't run for a very long time. And so it's useful to have a mechanism to exclude contracts that run for too long. Even if they would terminate eventually, if they run for too long, you might want to charge them more than other contracts. And so in Bitcoin, basically, the only mechanism we have in this priority calculation is that transactions that are larger cost more to get the same priority. And so for contracts, it makes sense to have a way of charging contracts more or charging transactions more that cause more execution to occur. And so that's a good mechanism to do that. So it's a little bit separate from infinite loops. That's not the only reason to have that.

Right, because it's like a public good in a way, you know, that Ethereum chain and you want to have people pay for it. Just in the same way that basically with Bitcoin, they pay to be included in the blockchain, right? And then, you know, as you mentioned, right, of course, if the feeware, with the transaction size and that exactly sort of reflects how much space you take up there. So I think from that perspective, it's absolutely essential, you know, beyond the infinite loop to have a model like that. So one thing I find interesting about this, so when you say you hard code how much gas you pay for different operations, can you give examples of some of those things?

And if you have to hard code that, does that mean like in reality they did the cost of executing those corresponds to the ratios you pay in gas? So let's say something costs 10 gas and something else costs 100 gas. Does that mean for the miner or for the network, the real cost of the thing that costs 100 gas is actually 10 times higher than the thing that costs 10 gas? it should. I mean, that there's kind of some approximation involved there, but when they were setting the prices, as I understand it, they actually did a lot of kind of benchmarks on various machines to get an estimate of what is the real cost or the real execution time for these different top codes. So yeah, that's roughly the intent is that if you look at the gas price of executing a contract with some message, that should roughly correspond to the actual computation. resource involved in running it. So it's not perfect, of course, because different machines do different things faster. And so it doesn't necessarily capture all of the things that are involved, but that's roughly the intent. But so let's say now there are some errors here. And let's say maybe over time, you know, hardware changes, miners change, you know, the world evolves.

And let's say those errors or little inaccuracies get bigger. Could that cause serious problems? I don't know whether or not they would be serious, but an example of the kind of problem that it could cause is you could have people designing contracts that actually cost a lot more and are a much larger burden to the network because they're very expensive, but if they're underpriced, then that may be the cheapest way to get some task done. So, for example, you know, that you could have some hash function that's actually really, really expensive. It's like Shaw 4 or something. And just suppose it's really expensive, but that, I mean, it's actually really computationally expensive, but it's very underpriced. It costs only one gas unit. And you might see people trying to use that function more and more because it's cheaper in terms of what you have to pay, but it's actually worse for the network to have to process all of that. So, I mean, that that's the concern with having the prices be mismatched to the actual computational cost.

So in essence, this kind of thing creates like an attack vector where a programmer could create a smart contract that needs a lot of, say, if Sharfur operations are cheap, then he could create a contract that needs, that executes a lot of these operations. And he pays a very small fee amount for it. And the actual cost to the network, to the nodes of the network to execute this operation, store or the results of this operation are much higher. higher than what they are deriving as revenue from this operation itself, right? Yeah, yeah, exactly right.

And for anyone who's listening to this like five years from now, I have no idea at the time what Shaw for actually is. So no offense to your hash function. That was just a made-up example. So is there a way to change it over time if it turns out that maybe some errors were made and actually, you know, there are these mispricings and they get, they lead to all kinds of weird things happening? Can you go back and say, okay, we need to adjust that?

Yeah, I don't, I mean, there's no obstacle to effectively hard forking to change the fee schedule for the various op codes. And one of the things that seems to distinguish Ethereum from Bitcoin is that they are, you know, they've made it clear that they're willing to do hard forks as necessary for, you know, improving it. So, well, that's a huge issue for Bitcoin these days. That seems like a totally plausible upgrade mechanism for Ethereum. So I think it would just be a matter. of changing those. One of the things that can happen, yeah, so like you said,

any kind of mispricing results in some kind of denial of service attack vector where you don't pay very much, but you cause some kind of load on the network. And so one of the things that we tried to look at in this analysis was to try to see, are there any ways that we can cause more harm to the network or more cost to the network without having to pay for it?

And some of the things that we found are along those lines. In general, it would be cool to have some way to automatically update the costs of op codes. I know that was something that Vitalik talked about, but I don't think as implemented yet. So conceptually, you could have other upgrade mechanisms. And finally, one of the points that we made, and we could talk about this a little more, but that one thing that you can't rule out simply by having these op codes is the ability to pay minors out of band as a way of circumventing some things. So if you have some op code that you want to use that's actually priced the wrong way,

you might be able to make a deal with the miner out of band where you set the gas price to be wrong so that you kind of scale all of the op codes down and you pay less in fees. And you may make up the difference to the minor just by paying them out of band. So it's possible that even the policies that are there, if they're too far out of whack, then people may find other ways of making side deals to circumvent the intended price. Yeah, that makes a lot of sense because one of the, you mentioned the possibility of some sort of attack vectors, you know, people doing big transactions cheap or something like that. But the thing actually I was thinking about was let's say you need to use a specific operation, specific op code. And that one just happens to be on the price.

Now you don't want to take advantage of it. But, you know, if you just pay the normal fees, minors might say, well, we don't include that. You know, like we just always throw that way. but then yeah i guess that would be a way to circumvent out yeah yeah miners could say if you use this op code then you just need to you know add your increase your gas price like the the rate of ether that you pay for it so that it sort of averages out to what what they wanted you to pay yeah so then that's the mechanism for circumventing the prescribed price okay so i could say i i'm using this cheap operation but i'm willing to to pay more per gas and then different people

might pay different rates per gas within a block. Right. Let's take a quick break so I can take it to Paris. I stopped into the ledger offices and met with Eric Larcheweck, ledger CEO, and he filled me in on the upcoming Leisure Blue. In early 2016, we are going to release the Ledger Blue. This is a personal privacy device which runs on a SETU element, has a touchscreen, NFC, Bluetooth, and...

USB connectivity and it will be a full-fledged hardware wallet with a second factor validation of the transaction directly on the screen. It will be fully open source, you will be able to add your own apps and it will also be compatible with Fido second factor authentication. Password are going to disappear and it will be replaced by this kind of cryptographically secure authentication. The Ledger Blue will be certified by Fido and will give you the possibility to login on any website very easily just by signing a cryptographically secure challenge. Ledger is making hardware wallets easy and convenient

without compromising on security. If you want to get a secure setup for storing your Bitcoins, go to ledgerwalt.com and use the code Epicenter to get 10% off your order. We'd like to thank Ledger for their support of Epicenter Bitcoin. So in a sense, this kind of seems like a governance problem almost. Like in Bitcoin, we have this problem where you have the block size, which is 1MB, and people want to increase it, but they can't come to consensus on it. So this mechanism where different opcodes, like a Shar-3 operation or a jump operation or a

store operation, all of these have different prices and those prices are set by the Ethereum Dev team currently. but don't this seem like avenues for future conflicts like the block size, like the block size increase in Bitcoin? Yeah, absolutely. It's absolutely a question of governance. And whether it's easy to upgrade these or not depends on how easy it is for the Ethereum dev team or whatever political factions, you know,

are able to push things like that along. If it becomes contentious, then I could imagine the same, you know, challenges happening to Ethereum that face between. right now. So far it doesn't seem like the Ethereum dev team has a problem with that, but they're currently, you know, largely in control of this and don't have the dissent that different factions in Bitcoin have currently. Yeah, I mean, I just was, I wanted to say it's also, it's so early, right? So when you, now it's also, it's early, there's not that much at stake and you have this sort of homogeneous

development community. But. you know bitcoin is now how old is bitcoin now it's six years soon right and a lot of things change within that sort of time frame yeah yeah so it's hard to speculate and this is true for the the analyses that we say and even this just discussion that we had they're very much about and strategic interactions between fees payers and miners and there's no evidence that the you know miners are like that they have an API where you can request bribes or things like that so So these are things that are kind of strategically speculative, but aren't necessarily attack vectors that are going to be used right now.

So with regards to the gas mechanism, you mentioned that there are ideas for like automated ways of updating the gas prices. Could you shed light on what these could be? How would you solve the governance problem essentially in an automated fashion? A really coarse example that, I mean, it's easy to talk about because Ethereum also features this mechanism to tune other tunables in the system is simply to have miners vote on it. And this also pertains to something that was in our analysis. So right now there's a, you know, Bitcoin has a block size limit and people have talked about having,

you know, ways of automatically adjusting it or adjusting it by minor vote. In Ethereum, you don't have a block size limit, but you have a gas limit per block. So you can only spend this many op codes for all the transactions in a block. And you have to pay gas for size. So this implies that there's also a size bound. So it's a kind of, there is a bound for the combination of the computation and amount of storage used in a block. But this limit is adjustable. It's elastic and it can change over time. And it can change over time essentially by the median of the votes of a miner. So each time miner mines a block, the amount of gas that they use sort of factors into this, you know, function that's a sliding window. So over time, if miners choose to, they can expand this limit. So for a while,

even in Frontier, the gas limit was so low that you couldn't make, I think you couldn't make any transactions at all. And so we were actually waiting to see the first transactions and the first contract published on Frontier. You had to wait for the natural process to expand the block size limit up to the point that you could even fit in one transaction at a time. And so that mechanism is a, that is a mechanism you can use to tune things. I don't know whether it's incentive compatible or gamable or totally sound against any attack, But it is a general purpose mechanism so you could imagine using the same thing to also adjust the op codes. So in Bitcoin, one of the concerns a lot of people have with the block size is so if the block size is too big, it's an advantage for bigger miners. And they start being even more profitable and causes all kinds of other problems.

Do you see similar problems here? And will there be, for example, an incentive for if you're a large miner to try to drive up that gas limit? That seems plausible to me. I don't see any inherent reason why that wouldn't be the case, presumably if that's a problem in Bitcoin, it's a perfect analog, so it should still be a problem in Ethereum too. But do you think in general it makes sense to you that the way the gas limit is adjusted? I mean, when you look at Bitcoin, right now there's like no method of upgrading it. So it seems like any method is better than no method. And to have like updating.

Maybe unless it's a bad method. Well, not any method is better than no method. But a reasonable method is probably better than no method. And this sounds like reasonable enough. But I look deeply. If this method works for Ethereum, then I think it would also work for Bitcoin. So I mean, it is a similar, it is a method that's attacking a similar problem in a way that would be applicable. Right? So this is kind of a way of, this is Ethereum testing out a mechanism that if it turns out to be sound, then, you know, that could also be a solution for Bitcoin to use. Whether it's actually going to be sound, I don't know. I mean, so even while I like analyzing the incentives of things and trying to look at rationality models and so on, I know that the kinds of analysis that I do don't reflect all of the intricacies of reality. So when people say, oh, well, there's lots of good reasons why just because this, you know, this seems like it

makes sense when you look at it as a simplistic way, it's missing out on the realities of bandwidth than China or something. Yeah, all of that's possible. So I would certainly not claim to be able to tell which of these methods is going to work, if any. And have you looked at, because in Bitcoin, there's a whole range of attacks that miners could use. I mean, we've talked on this show. We've talked before about selfish mining and about miners' dilemma, some of the work that Emmingunser and Ita left on. And there's certainly quite a few others. Have you looked at if those translate to Ethereum as well,

or are there some protections against some of these known issues with proof of work in Bitcoin? Some of the things are a little bit different. I mean, so Ethereum's proof of work puzzle is designed to be GPU friendly rather than ASIC friendly. And so one of the things that we looked at in the analysis is to see if that is the case. And we concluded that, yeah, it does seem to be the case.

A lot of this wasn't even so much technical as a matter of looking at hardware catalogs and trying to get a feel for how different memory performance tradeoffs are and what their costs are. And so does it seem like it would be possible that someone could make a dedicated ASIC? That would be thousands of times more effective than the commodity memory that you could buy. And we concluded, know the most cost-effective way to solve this puzzle is to use a commodity-available memory. So even while we concluded that it's effective at being GPU friendly rather than ASIC friendly, I don't know whether being GPU friendly rather than ASIC friendly is the right choice for a cryptocurrency. There's these kind of two opposing points that if you have ASICs, then at least you have this

kind of hardware investment that you can't recoup by using it for anything else. Whereas if you use GPUs, then you could sell the GPUs after an attack and they'll still be useful for supercomputing or something like that. So that is to say, Ethereum has some distinct differences from Bitcoin in terms of what attacks and incentive landscapes there are. And even by pointing out the differences, I don't necessarily know which ones better. Similarly, Ethereum has this ghost protocol, and that directly addresses some of the mining concerns, especially in terms of increasing the rate of blocks. I don't exactly know what the interaction is with ghost and selfish mining.

So I don't know whether that actually exacerbate selfish mining attacks or gets away with that. I know that the people who work on those probably have some thoughts about that, and I just don't remember what their opinions are. So let's drive a bit into the proof of work function for Ethereum, like you've brought it up. And we could maybe go into ghost later. So like as I understand it, like you could design proof of work functions in to, In at least three ways, like you could have either have the target of being ASIC friendly, which is Bitcoin, short of 56. You could have the target of being CPU friendly, which means no matter if you use a GPU or an ASIC, their performances are going to be pretty similar to what the mining performance for a CPU would be.

So this was, I think, Wirtcoin and those guys tried this out for CPU friendliness. And the third is GPU-friendlyness in which graphics cards are probably the best hardware to do it. So kind of is there any science to choosing one of these objectives or is it all pure guesswork today? Yeah, I don't know. I'm inclined to say it's guesswork for choosing among those objectives. Once you've picked an objective, then there's a lot of science you can do in terms of meeting that objective. I mean, it's not exactly guesswork, but it maybe involves, some kind of sense of economics or macroeconomics or predictions about hardware trends,

which I find hard to do. So like what does what does GPU resistance practically mean? Like would would do you think this means that in the future a lot of people will be able to mine Ethereum unlike Bitcoin where miners are getting more and more specialized? Yeah. I mean that that that's that's that's the rationale for it. One of the things is by being GPU friendly, one of the meanings of GPU friendly is that the ideal puzzle, it should appear that there's very little gain to be had by going through the process of making a specialized ASIC. You could make a specialized ASIC. You could for sure make a specialized board that just has the relevant parts of the GPU, like the RAM and a simple processor. And that'll be more cost effective and more efficient and higher throughput and all.

But it won't be that much more. So if you look at like a GPU versus a Chautu Bitcoin mining, ASIC, it's just like thousands or tens of thousands of times or some vast amount more efficient. And so if you can narrow the gap to being only 10 times more efficient, that's still a big factor. But that may be enough of a reduction that it just doesn't seem to make financial sense for someone to spend the tremendous amount of engineering design effort to go through the fabrication process of getting. A6 made. So even just closing that gap may have the economic effect of discouraging people from going through that process of making highly specialized ASICs. And then, yeah, that should mean that anyone who can have access to commodity GPU equipment, that's roughly as good as what's used for other tasks in GPU computing and so on, we'll be able to do just about as well.

So why didn't they try to make a proof of work puzzle that is actually suited for CISC? CPUs. Is that not possible? I don't know how to do it. I think that the, you know, the approach to going about making something GPU friendly is specifically to target its RAM. So it's really about making it like memory friendly and GPU, you know, graphics RAM is just extremely efficient and cost effective right now and very powerful. If we knew how to make a CPU specialized puzzle where, you know, it would be like proof of X86 or something, like the only waited to do well at this puzzle would be strictly to use a particular CPU design, that'd be a really cool achievement. I don't know how to go about doing that. So there's kind of a foot hold

to designing, you know, memory-based puzzles. If we had one for CPU, that would be cool. One thing I've heard people mention was the idea that you have a variety of different proof-of-ware puzzles and you sort of rotate them or you put them on top of each other or something like that. Is that something you've ever looked at? Yeah, like the X-11 puzzle design. Yeah, I'm not sure about that. I mean, so it strikes me as plausible that attackers would still be able to benefit by specializing in whatever is the lowest hanging fruit there. Or you may be able to simply have several different specialized basics, each one of which is specialized at accomplishing one of those tasks.

And then altogether it could still be, you know, 10,000s of times better than a CPU. So it could be that there's something along those things. that there's something along those lines that works, but I'm not totally sure. One of the things that I've thought about is that, one of the things that makes CPUs designed is to use minimal power. So it's plausible to me that there may be some approach

that involves quickly cycling between different things like that, so that the only way that you would be able to do it more cost-effectively is effectively to power down one circuit when that's not the one that's active. So I don't really know. It's plausible to me that some approach like that could work. So, I mean, so one other way that Ethereum is trying to incentivize building of A6 for its POWs is by saying that,

hey, we guys are going to shift to proof of stake. So if you build an ASIC factory, then you might be left out in the cold. Yeah. And like some of our listeners may know that Andrew is, that you may have heard of the statement that the problem with proof of stake is that there's nothing at stake. And Andrew is the originator, the creator of that statement. So like Andrew, could you explain, you could talk about proof of stake? Why did you come up with that statement and what were the conditions then and what has changed up to now?

Yeah, so the problem with proof of stake is that there's nothing at stake was a criticism directed at, I think, pure coins puzzle at the time. And, I mean, the essence of it is that you can do stake grinding for free in the sense that you can be applying your stake to many different, you know, potential views of the blockchain, like many different forks all at the same time. And then you can just continue to work on whichever one seems to benefit you the most. And there's no cost to doing that. So even though the premise of proof of stake is that you should have your, you know, your, your, your, your, your, your, your, your, your, your, your, your, your, at risk when you make one of these decisions, that mechanism doesn't actually have any effect

when you can simultaneously do this on all of these different forks at the same time. Now, this criticisms, I've seen it kind of used as a catch-all criticism for all proof-of-stake puzzles, but what I want to point out is that nearly every proof-of-stake design since then has had some explicit mechanism to address that concern. So these are the punitive proof-of-stake algorithms where if you are caught double-hulls, signing or using the same stake in two different blockchain forks at once, then you forfeit your collateral deposit or your coins get, you know, eaten up or deleted or something like that. So that directly, you know, addresses that concern.

There are still other concerns like, you know, Greg Maxwell's view is the problem of costless simulation, which is another way of saying a sort of similar problem, which is that you can always, after the fact, go back in time and pretend to be extending some block a long time in the past and maybe you've already spent your coins maybe this is after the security collateral deposits already been claimed and so it's hard to retroactively punish someone for something that they do if it affects a fork that's so far back in history that they've already sold the money and moved on and so yeah so proof of stake is that the long range attack is that the same thing uh i believe long range attack uh maybe i could i would use the just a matter of semantics yeah those

most commonly are used to refer to the same kind of thing. I mean, conceptually, you could have a long range attack that I'd still want to call a long range attack even if it wasn't costless. But, yeah, effectively those mean the same thing. Okay. Because yeah, with long range attack, right, the idea is okay, you can go, because if the security deposit, you go back far enough so that there is no deposits, you get people's private keys, and then you start doing a chain from there.

And if there is some sort of mechanism that affects the rate of blocks, that, you know, maybe you can be more efficient at creating blocks because you control the whole chain and then you can sort of take over the chain and, you know, you can do all kinds of fake things. And then the way this is addressed, I think mostly is that you do sort of a checkpointing thing, right? That you say, okay, you know, it's final now. And if somebody comes from further back, then, you know, we ignore that. So I've never been totally confident about how many of the checkpoint mechanisms works. So certainly that would work, but then the burden is on the effectiveness of the checkpoint mechanism. That's also where my in-depth knowledge of this kind of reaches a limit.

So I don't know whether the checkpoint mechanisms that are proposed work well. I know a lot of people are working on this sort of thing, and so I would say I'm guardedly optimistic that there's some way to do this very well of proof of stake that could work. Actually, I would say I'm in the middle. It's 50-50. I have no idea whether there's going to be an effective. effective proof of stake. Another thing that I like to say on this is that there seems to be, it seems like there's

something inherent about burning actual, you know, expending actual power, consuming actual energy. There's something undeniable about that. That's kind of, you know, it involves time, you know, unless you have more hardware, you can't burn power any faster, whereas in any of the proof of stake things, it's only based on subjective view of time that there's any restriction in time. So I like to wonder whether there's some inherent kind of security that you can only. only get by burning real power. And if not, then they would suggest that there is a way to do it

with proof of stake. So I'm undecided, but that's like one of the most tantalizing open problems of this era, in my opinion. Today's magic word is gas, GAS. Head over to let's talk bitcoin.com to sign in, enter the magic word, and claim your part of the listener award. So, I mean, I guess the reason like this, this kind of becomes like a very interesting problem to think about is once you go into the smart contracts world and you have developers that are writing smart contracts and these applications become more and more complex, all the developers, after a point, all they care about is the gas price. They want it to be as low as it can go so that they can write even more complex stuff. So in a sense, we start to need designs where gas price can be driven very low. And perhaps the thinking behind Ethereum is that with proof of stake, you can make the gas price like 10 times lower than in a proof of work system, right? Oh, I see.

You're just saying because you don't need to – I mean, it doesn't have to do with the smart contract execution. It's just you don't have to subsidize this big expense. I mean, for sure, the proof of work mining is the biggest expense. in Bitcoin. It's like a million dollars per day that's going out to Bitcoin miners, right? That's a million dollars per day that's subsidized by the, you know, inflating the currency by all of the other people that have it. So someone's paying for it. They're paying for it and the decreased value of their coins just because of that. So all else equal, you would have far less transaction fees needed if you could do cryptocurrency without the mining. So I think it's really unrelated to

smart contracts specifically. But for sure, if you could get rid of that mining, it would be a big boon to the economics of the cryptocurrency as long as you could still have security in the same way. And so overall, your view is on proof of sake. It's interesting, but you're like undecided whether it will actually work and whether it will survive in a long run and provide the kind of security that's needed once you have real value in really big applications running on these systems. Yeah, I would say I'm perfectly razor's edge undecided 50-50. It could go either way, but it's something I pay close attention to. I'm really eager to know what the answer is.

So from your whole design audit of Ethereum, do you think there are some things that are missing from the Ethereum ecosystem that would be nice to add as features? There are a few things. Let's see here. So one of them is that the Ethereum data structure is designed to support all kinds of SPV-like queries. and to even support zero storage lightweight validation.

Like you can be a full validating node, you'll only effectively look at SPV proofs for each to validate each new block. But I don't think that any of those are implemented any of the client. So the data structures there are ready for it, but the implementation of these things isn't developed yet. Maybe there is an SPV Ethereum client now.

I may not know if one's come out recently. Another point that I want to make is that, even though Ethereum is Turing Complete, there are some things that you can't do in Ethereum script. And actually, what I'm going to describe was pointed out, although kind of as an aside, in an academic paper by some other people, Kiayas and Heng Shenzhu and others. But the point is that here's an example of something that you can't do with Ethereum, and it doesn't matter how Turing complete it is. Something that you can't do in an Ethereum contract is look at the other transactions that occur in the

block that you're currently executing in. And the reason why is that there's no op code that lets you load in the current block hash. You can't see the other transactions in the in the block. You can see other transactions in previous blocks, but only because of a hack. Because in Ethereum you can access the hash of the previous block. And so technically you could write an Ethereum contract that does SPV validation of the Ethereum blockchain itself. And so by doing that, you could go and kind of check these Merkel tree proofs to see what the state is of the contract at a prior point in time. You can see all of the transactions prior to the

current block, but you can't tell which transaction order you're in. You can't see the contents of the other transactions of the block. When would that cause a problem? I don't have any practical explanation why it could cause a problem. I could come up with little contrived examples where it might cause a problem. For example, you might want to have a contract that depends on the storage of some other contract. And in general, there's no op code in Ethereum that lets you, like you can look at your own storage, like a contract can look at its own storage and modify it, but you can't access another contract storage. Unless it provides a get, you know, method that you can't actually go and look at its storage. You can go look at its storage, though,

by traversing the storage tri, which is committed to in the previous block hash. So you can see the previous blocks. You can see the storage of any contract, but you can see the state of what it is in the previous block. So this kind of contrived example I'm coming up with is that you might want depend on the storage at the current moment, but it's possible that a transaction in the current block changed that storage, and you'd have no way to be able to confirm that. Okay, so what you're essentially saying is like if there's a contract in which the storage is continuously being updated, like, for example, there's a particular public key stored inside the contract, and it keeps being getting updated. Then right now, my contract cannot access

the public key that was in the other contract, 100 days. ago. I can only access what is the public key that's in there right now, but I can't access the public key. It's the other way around. You can access the one that's historical because you can always traverse backwards as though you were an SPV client from the previous block hash backwards, but you can't see what's changed currently because you can't see the current contract that you can't see the current transactions in the current block. Okay. So I mean, so that's very interesting. So this is just a counter example to the to the claim that because it's turning complete, you can do absolutely anything. No, it actually depends on what

kinds of information is passed in. It depends on this execution structure. That on its own is just a counter example, not a particularly, so I wouldn't say that this is like a feature that Ethereum needs, but I don't know, maybe it could turn out that there's something important. Okay. I thought like reading through your papers, I thought the most important thing that Ethereum lacks is really transactional privacy. Like the example you gave was that if you have like five people that want to bid on something then before the

like let's say there's a beautiful Chinese wars that the five of us want to bid on and we want to put our bids in and then whoever has the best bid wins but ideally we don't want to know each other's bids like we don't

I mean to design such an auction we would prefer not to not the participants to know each other's bids before they are revealed. But you can't do something like this with core Ethereum. You can, but not in the most direct way. So Ethereum is so tempting because it looks so easy to implement all of these things. And if you can implement an auction in a dozen lines of code in Ethereum, but it's only, but it would suffer from this pitfall. The most direct and obvious way to implement things in Ethereum usually involves leaking a ton of information

everywhere. And so an auction is a perfect example. That's the motivating example we use for Hawk. The easy way to implement an Ethereum auction involves everyone just telling you exactly what their bids are, and that's not a sealed bid auction. So that's usually not the economic mechanism you would want. Now, what you can do is use cryptography to build better protocols on top of the smart contract system. But now you need to actually use the cryptographic primitives that are provided like you have Shaw 3 at your disposal and there's a hard-coded contract extension that you can use to do elliptic curve signatures to verify elliptic curve signatures. But for anything else, you would either be forced to not have it or to basically try to

implement it in the Ethereum language. And that's really difficult because it's just not costly to implement cryptographic primitives directly into this virtual machine. would pay a lot of gas to do it that way. So, I mean, so, like, like, we decided, like, so Andrew has this proposal called, I don't know if it's a proposal, it's, Andrew has this paper on, on Hawk, which is a system by which you can write privacy preserving smart contracts on Ethereum, right? Is that the objective?

Yeah. Yep, that's the goal of Hawk. So, I mean, perhaps it's, yeah, perhaps, like, it's, it's, it's, it's like a deep, topic for us to go in this current show because we have a one hour slot but we'd like to discuss one of this proposal and another talk of yours because it's a very interesting idea that

you can have smart contracts that both preserve the privacy and where most of the computation is also off-chain so it preserves gas as well it preserves privacy as well and it's a smart contract like Ethereum and it's as powerful as the Ethereum contract language right yeah

I mean, a brief enough thing just to say about is that I'm optimistic that a lot of the things that you would want to do, including more complicated applications that need more complex cryptography, especially for the point of being privacy preserving. I can imagine doing them with fairly minimal additions to Ethereum that come in the form of op codes that do specific cryptography. So right now you have op codes built in for hashes and for signatures, but if you also had an op code built in for various forms of encryption or for zero knowledge proofs or for other kinds of cryptographic primitives, then maybe all of these things would be able to be more easily supported. Yeah.

So actually in the future, you could have not only currencies like zero cash, which are like truly anonymous, quote unquote, but you could also have smart contracts that are privacy preserving. like these these all things are possible in the future and they'll come our way right yeah i think so i'm pretty confident in that that these are possible okay that's that's very interesting like we'll we'll get into this in another episode but perhaps we should focus on just ethereum as it is today in this one so um have have you been looking around the ethereum ecosystem what are the kinds of projects that excite you oh wow um not as much as i should have recently i watched some of the videos from DevCon, which is amazing because they have, it must be like 40 hours of video footage of presentations all on these different projects. I really like the one on Ethereum World, which is a whole virtual world in the style of second life where you have to buy virtual property, but that's all mediated on the blockchain. Stuff like that's pretty cool to me. I would say that right now BTC Relay is probably my favorite contract. That's one that you wanted us to talk about, so I'm happy to talk about that a bit.

That's the first really sophisticated serpent contract that I saw. When I was asking Vitalik for hints on serpent program to sort of make progress with the, even the Ethereum audit, I wanted to make examples in Serpent. So I'd say, hey, Vitalik, how do I go do this thing? And he'd say, oh, go look at a Joseph Chowell's project. That has all the complicated serpent code in it. And yeah, so I used BTC Relay's early code as like a textbook for how to do complicated string manipulations and stuff in Serpent. And so it's a really sophisticated coding example.

So what does BTC relay exactly do? Why is it special? So BTC Relay is a Bitcoin SPV client implemented in Ethereum smart contract language. So you can, just like a Bitcoin SPV client receives proof of work headers from anyone who sends it to them, like other nodes in the Bitcoin network. This is a smart contract that keeps track of the Buconnetwork. proof of work blockchain of Bitcoin. And so you can advance its view of what it thinks is the longest blockchain fork by submitting proofs of work to it. And then the code of the Ethereum contract checks the proof of work, just like the Bitcoin J SPV client would do on your phone.

And then you can also prove to the SPV client in Ethereum. You can prove to BTC relay that a transaction has been included or not because you show it the path through the Merkel tree to the transaction that you care about in the blockchain that the contracts aware of. So it basically has a whole implementation of a Bitcoin mobile phone blockchain viewer in Ethereum. And I think that that's really cool

because, and I can tell you a couple of other examples of why I like this. The reason that I like this so much is because it's a protocol that spans more than one blockchain. There are only a couple of other examples like this, and I love all of them. And probably also know, as a promoter of the Tiernolan and I've been told that it's Tiernolins and also Ito Bentov's

cross-chain atomic swap. So this is an old protocol that you could do just with hash lock transactions that lets you trade a light coin for a Bitcoin with no risk of one party walking away with both coins. And so that's so clever because it's a thing you can do with scripting language, but it involves two blockchains, not just one. That's awesome. Yeah, I mean, I've, like, like, this is, this is probably the protocol that drew my attention to you the first time, because, because you wrote the script for it. Like, I think TN O'Land came up with the idea and then you wrote the script for it. And it's very interesting that, basically for our listeners that haven't heard of TN O'Lans protocol, it's essentially a decentralized cryptocurrency exchange, which allows you to trade Bitcoin with light coin. and there's no counterparty in the middle.

It's just you interacting with the two blockchains and conducting an exchange and you as a party to the exchange can't be cheated by the other guy. So this is really like truly decentralized exchange and this protocol exists and it can actually be implemented in Bitcoin. But for some reason, it never was.

I never understood why we don't have an exchange that works with that protocol. I've always wondered that myself. It's such an acute thing. I mean, like anything else, it's probably just a matter of no one's gone out and done it. I should go out and do it if I like it so much rather than just yamering about it. I mean, it requires non-standard transaction type, so that's the kind of catch-all reason. You'd have to go get it to mind at Luke Jr.'s pool.

Yeah, but it works, and it uses script that's available today. I mean, around the same time, Sergio Damien Lerner also made a proposal called P2P Trade X, which accomplished the same thing, but in a moment. more interesting way that could also accomplish other things. And this involved having a, you know, you could use it with Bitcoin and trade to another chain that had to be designed with special op codes. It's really like a proto version of side chains actually, because the idea is that the other chain that you'd be trading with would itself have an SPV client checker. So you would have op codes in this other language that work like SPV validators of Bitcoin. And that would be another way

to achieve this fair exchange. And so that's actually closer to what BTC relay does. And even sidechains as the other example of protocols that span multiple cryptocurrency blockchains. So just the last question before we wrap up. With the PTC Relay, which I agree is super cool, right? Because the potential, of course, is that you can use all the smart contracts on Ethereum, you know, with Bitcoin basically and, you know, without having, for example, side chains, although that might be interesting as well. But so because in Ethereum, like each computational step,

is going to be expensive. Is it is building an SPV client and then you know checking each time and updating and you know submitting proof that you know your transaction has gone to that place on the Bitcoin chain is that going to be very expensive? Yeah, I think it will be very expensive especially right now given the current gas prices. This is one of the reasons why BTC relay. I mean, I think it runs runs and it works on the Ethereum test nets. so not even on the Ethereum Frontier Network.

And the reason why is just that it would be prohibitively expensive right now. I realize that just sending data to transactions is quite expensive in Ethereum right now. I worked on this gadget called like a block hashes gadget, which is a pretty modest little thing that just is, it tries to overcome some limitation of one of the op codes in Ethereum that only lets you look at hashes of blocks in the most recent 256. And if you want to see more block hashes prior to that, a way to do it is to build a contract that stores all the block hashes.

So it's almost like an untrusted blockchain mirror for Ethereum blockchain itself. And I realized that I initially wanted to basically send this every block hash so that it has all of the block hashes in its storage. And I realized that would be too expensive. It would be like $14 a day or something. And I'm not going to pay that. So just because of the cost of sending storage to that, I think I ended up doing something like sending to it once every $250. blocks or so, which is still fun, and it's a lot cheaper, but it doesn't provide the same service. So already the cost of sending things to Ethereum rules out some kinds of applications that I would

want. And yeah, and that only gets worse when you try to do more complicated stuff. One nice thing is that BTC relay, you know, you don't have to, you know, if lots of different people use it, they get to sort of amortize the cost of sending proof of work headers to it. So you only need one instance of the BTC relay contract to provide service for a bunch of people who want to see transactions in it. But yeah, I think the best hope is to, you know, hope that the cost of storage goes down. Yeah, yeah. And, of course, there's still the cost of computation and, like, verifying proof of works and the headers

and even that might be expensive now. Yeah, I mean, fortunately, that's pretty cheap. So, like, the Shaw 2 op code is pretty cheap in Ethereum, which is good, and storage is expensive. And one of the reason storage is expensive is because every time you do a storage operation, that actually triggers, like, a whole chain of hash. computations. So, you know, that's one reason that a single hash isn't so bad. Okay, excellent. Well, Andrew, we're at the end of our time, but thanks so much for coming on and talking to us today. I mean,

I know there's lots of topics we could have talked about, but I thought it was hopefully also gave people an interesting perspective on gas, which I think it's going to, you know, it's obviously a core feature of here. I mean, a core component of how it works. And thanks so much for sharing your views on that. Yeah, this was a lot of fun. You'll have to have me on again and we can talk about more things next time. Yeah, absolutely. Certainly. Okay, yeah, well, thanks so much for our listeners. Hopefully you enjoyed this and hopefully you learned a little bit more about Ethereum, how that works and how gas works. And very excited to see where that's going to go. And, you know, once we have things like PTC relay really working and hopefully the cost coming down,

it will be very exciting. Of course, too, to use Bitcoin on Ethereum. And yeah, so thanks so much for listening. So we are part of the Let's Start Bitcoin Network. So if you want to check out this show or also lots of other shows, you can do so. Let's TalkBitcoin.com. Of course, you can also download the mobile, the audio versions of this on mobile on SoundCloud or whatever podcast app you use. And you can watch video.

We do video as well. And that's on YouTube.com slash eBcenter Bitcoin. And, you know, speaking all of Ethereum and speaking of YouTube, Meher's video is from DevCon. I'm not sure if all of them are up, but lots of them are up at this stage. So if you want to dive into more there, there's a lot of content, a lot of great content that he has produced there. So thanks so much and we look forward to being back next week.