EB111 – Andrew Miller: The Gas Model And Ethereum's Economics

Transcript

[Music] this episode of epicenter bitcoint is brought to you by Ledger now accepting pre-orders for The allnew Ledger blue Developer Edition a Bluetooth and NFC touchscreen Hardware signing device learn more about The Ledger blue at Ledger wallet.com and use the discount code epicenter to get 10% off your first order hello and welcome to enter Bitcoin the show which talks about Technologies projects and startups striv decentralization and the global cryptocurrency Revolution my name is

Brian Fabian Crane and I'm me 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 he some of you might some of our listeners might know him as Socrates one 1024 in Bitcoin talk he has made such great postings on that Forum that uh it's very interesting um uh he is currently a PhD student at the University of Maryland and he focuses on um mostly his work focuses mostly on cryptocurrencies over the past few years he has done various interesting research projects such as replacements for proof

of work to discourage mining pools um new ways of exchanging currency like decentralized exchanges ways of making order books ways of enhancing privacy Etc so he's a very interesting guest we have today but before we start perhaps we should take some take out for some time for Andrew to introduce himself Andrew can you give your introduction uh sure thank you for the introduction uh yeah I'm Andrew like you said I'm a PhD student at the University of Maryland um I really like doing cryptocurrency research um I 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 um I think it would be about U 3 to four years now um I remember when I was just uh getting started on this I would post on on bitcoin talk as a way of kind of trying to see if there were viable research topics uh and I 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 how was that received at the time was that looked at as something bizarre and did you get resistance from your advisers yeah yeah it was a very weird process um I mean I was in computer Graphics at the time at the University of Central Florida and my adviser then very uh 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 uh uh t tent to go off on on this cryptocurrency stuff right 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 I 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 no 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 uh but then that turned out not to be the case at all and now it's a a you know 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 risk that probably paid off now because now also on the academic side there's so much interest and then I I don't see that going away anytime soon and of course if you know if 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 of cryptocurrency research and that's been a lot of fun so we we had some difficulties like choosing what topic we're going to talk about cuz Mayer as he mentioned he's been following you for a long time and so he put it up this big list like super well researched of like all these things we going to have to talk about and I looked at he was like oh this is going

to be either it's going to be a a three-hour episode or we're going to have a very cursory superficial treatment of most of these topics and we have to hurry through it so we what we've said is like well let's let's sort of push off a big chunk of it and and perhaps we we'll do another episode to talk on on those projects and let's focus purely on on on ethereum and you've done some work on ethereum you've you've done a security audit on ethereum and in particular there there's some a lot of interesting intricacies because I think etherum has has gotten a lot of attention but it's 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 it should provide us a good window to kind of dive dive deep into that so I I I look forward to that a lot yeah let's go for it let's go for it yeah so so tell us was the security audit the first the first time you you kind of got involved in ethereum or or have there other things been before that uh so I had looked into some issues with ethereum and smart contracts I made a forum post on on the Bitcoin Forum pointing uh 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 uh smart contracts I think the one that I wrote about was was some you know weird condition that can happen when a contract um 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 um so I think it was really on the basis on that that they uh uh you know asked me to help with the the security audit um so you know that came after these things that I had just done on my own and and so the audit then was performed that was before the the launch of the the actual the beta launch and 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 it was several months before the launch of Frontier and and this was something that was done joint with least Authority uh who make Tahoe laughs the distributed file storage project and who are now involved in uh the the zero cash launch so did your audit of ethereum focus on certain aspects of the system or was it like a general code audit starting from design and ending absolutely I I it was very targeted I wouldn't even call it a security audit it 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 uh and and hired a bunch more people to do the

the general view um 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 those were the only things that we were looking at and 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 uh and for that matter also our our main point of entry was the yellow paper itself the on paper reference rather than the particular code implementation so we tried to look at design issues okay so for listeners uh who haven't actually gone through edium um 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 uh is the heart of the ethereum system because unlike Bitcoin ethereum has many different implementations like there's um ethereum in the go language there's ethereum in C++ and all of these implementation 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 uh ethereum's reference is the yellow paper so basically you you performed uh an audit of the yellow paper like not an

audit but an analysis of the yellow paper about what what it does well what kind of attacks are possible in that system and how does the proof of work function perform Etc yeah okay in in general how was your experience uh interacting with the ethereum dev team do you do you think they were responsive to criticisms or suggestions you came up with yeah I I really enjoyed it I thought that they were very responsive they were very helpful in uh uh answering answering any questions that we asked really quickly uh even just as as you're bringing this up it's reminding me I really liked the getting to get some visibility into their develop vment 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 the developers would sit together and you know and 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 uh you know doing 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 and the other so that is a good way to catch them and in that context the yellow paper is just another one of the reference implementations that's

supposed to be in sync with all the others right and and then so you mentioned gas and I think I think that's that's an interesting interesting way to sort of dive into that because in ethereum right computations are paid with gas right so they the whole idea of ethereum basically is that you know you send transactions and contracts and all that to this chain and they get executed and and you know they 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 a little bit why was it even necessary to have gas why 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 uh 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 uh 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 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 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 it would be that you can you can hardcode 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 yeah exactly and in the program code you know it's common to 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 I'm impressed with it I think it's quite novel I haven't seen any uh other programming language that really features uh anything like that so I think it's a really clever uh and and good idea I think it's pretty effective so um so like like ethereum

device gas because uh 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 at this aim of preventing infinite Loops uh it it's absolutely effective at preventing infinite Loops that's that's a problem that the you know this this adequately solves um I mean that's not the only way to go about preventing infinite Loops um uh one thing I'll have be happy to dig

into is that I think that the the Turing completeness uh goal is a bit overstated or or misinterpreted uh so while it's true that for an arbitrary you know you know program that you have you can't check whether or not it has infinite Loops or not uh 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 uh some kind of proof in a a a program analysis format that you know guarantees that it doesn't terminate or that that it doesn't have infinite Loops so uh 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 uh contracts that run for too long um even if they would terminate eventually if they run for too long you might want to charge them more than other contracts right and so in Bitcoin basically the only mechanism we have in this priority calculation is that transactions that are larger uh cost more you 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 you know that's a good uh 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 it's like a public good in a way you know that that ethereum chain and and you want to have people pay for it just just in the same way that basically with Bitcoin they pay to be included in the blockchain right and and and you know as you mentioned right if of course if the the fee varies with the transaction size and that that exactly sort of reflects how much space do you take up there so I think from that perspective it it's absolutely essential you know beyond the infinite Loop to to have a model like that but so one one thing I find interesting about this so when you say you hard code how much gas you pay for for different operations can you give

examples of of some of those things and if you have to hard code that does that mean like in reality they the cost of executing those corresponds to 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 minor or for the network that the real cost of the thing that costs 100 gas is is actually 10 times higher than the thing that costs 10 gas uh it should I that that is the mean that there's kind of some approximation involved there but when they were setting the prices uh as I understand it they actually did a lot of uh kind of benchmarks on various machines to get an estimate of what is

the real cost or the real execution time for these different op codes so yeah that's roughly the intent is that the if you look at the the gas price of executing a uh a contract with some message that should roughly correspond to the actual computational resource involved in running it so it's not perfect of course because different machines do different things faster and uh so it doesn't necessarily capture all of the things that are involved but that's roughly the the intent but so let let's say now there are some errors here or and 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 uh 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 say it's like Shaw 4 or something okay 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 then 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 that's the concern with having uh the prices be mismatched to the actual computational cost so in in essence this kind of thing creates like an attack Vector where a programmer could create a smart contract that needs a lot of if say if sha 4 operations are cheap then he could create a contract that needs that needs that executes a lot of uh 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 U the results of this operation are much 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 5 years from now I have no idea at the time what what shaur actually is so no offense to your hash function that was just up example so is there a way to change it over time if 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 can you go go back and say okay we need to adjust that yeah uh 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

uh you they've made it clear that they're willing to do hard Forks as necessary for uh you know improving it so well that's a huge issue for Bitcoin uh these days that seems like a a totally plausible upgrade mechanism for ethereum so I think it would just be a matter of changing those uh one of the things that can happen U yeah so like you said the you know any kind of Mis like 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 uh uh one of the things that we tried to look at in this analysis was you know 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 are along those lines um in general it would be cool to have some way to automatically update the costs of op codes I know that was something that vitalic talked about um but I don't think as as uh implemented yet so conceptually you could have other upgrade mechanisms uh and finally one of the points that we made and we could talk about this a little more but that uh one thing that you can't rule out Simply by having these op codes is the ability to pay miners out of band as a way of sort of uh circumventing some so if you have some op code that you want to use that's actually uh priced the wrong way you might be able to make a deal with the minor 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 it may you may make up the difference to the minor just by paying them out of band so it's possible that even the 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 you know intended price yeah that that makes a lot of sense because because one of the you mentioned the 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 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

miners might say well we don't include that you know like we just always thrw that away but then yeah I guess that would be a way to to circumvent that 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 uh what they wanted you to pay yeah so that's the mechanism for you know circumventing the prescribed price H okay so I could say I I'm using this cheap operation but I I'm willing to to pay more per gas and and then different people might pay different rates uh per gas within a block right let's take a quick break so I can

take you to Paris I stopped Into The Ledger offices and met with Eric lar Ledger CEO and he filled me in on the upcoming Leeder blue in early 2016 we are going to release the L blue this is a personal privacy device which runs on a sec element has a touch screen 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 fedo second Factor Authentication

password as going are going to disappear and it will be replaced by this kind of cryptographically secure authentification The Ledger blue will be certified by Pho and will give you the possibility to log 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 Bitcoins go to Ledger wal.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 in essence this kind of seems like a governance problem almost

like like in Bitcoin we have this problem where you have the block size which is 1 MB and people want to increase it but they can't come to consensus on it so this this this mechanism where different op codes like a sh 3 Operation or U or a or 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 they seem like avenues for future conflicts like the block size um like the block size increase in Bitcoin yeah absolutely uh it's absolutely a question of of uh governance and whether it's easy to upgrade these or not depends on how easy it is for the ethereum dev team or

whatever you know political factions that you know are able to to push things like that along if it becomes contentious then I could imagine the same you know challenges happening to ethereum that face Bitcoin right now um so far it doesn't seem like the ethereum dev team has a problem with that but they're currently you know a largely in control of this and don't have the uh The Descent that uh 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 is 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 uh 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 it's hard to speculate and this this is true for the uh the analyses that we say and even this just discussion that we had they're very much about kind of strategic interactions between fees payers and Miners And there's no that the you know miners are like that they have an API where you can request bribes or things like that so these are things that are kind of you know strategically speculative but aren't necessarily you know attack vectors that are going to be used right now so uh with regards to the gas mechanism um you mentioned that there might be there there are ideas for like automated ways of updating the gas prices could you shed light on what what

these could be how would you solve the governance problem essentially in an automated fashion um a really coarse example that I mean it's easy to talk about because ethereum also features this mechanism to tune other uh tunables in in the system is simply to have miners vote on it so uh and this also pertains to something that was in in our analysis so right now there's a you know Bitcoin has a block size limit and people have talked about having uh 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 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 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 uh the votes of a minor so each time minor mins a block the amount of gas that they use sort of factors into this uh you know function that's a sliding window so over time if minor 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 um 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 can even fit in one transaction at a

time and so that mechanism is a a that is a mechanism you can use to to tune things I don't know whether it's incentive compatible or gameable 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 right one of the concerns a lot of people have with the block size right is say so if the block size is too big it's a Advantage for bigger Miners and you start you know they start being even more profitable and and causes all kinds of other problems do you see similar problems here and then and will there be for example an incentive for if you're a large minor to to try to drive up that gas

limit that seems plausible to me I don't see any inherent reason why you know that wouldn't be the case presumably if that's a problem in Bitcoin the the it's a perfect analog so it should still be a problem in ethereum too but do you do you think in in general it makes sense to you that the way the gas limit is adjusted I mean when you when you look at Bitcoin [Music] I right right now there's like no method of upgrading it so it's EAS it seems like any any method is better than no method uh and of like updating maybe unless it's a bad method 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 if this method works for ethereum then I think it would also work for Bitcoin so I mean it is it is a similar it is a it is a method that's attacking a similar problem in in in a way that would be applicable right so so this is kind of a way of uh 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 I I don't know I mean so even while I like analyzing the incentives of things and trying to uh look at rationality models and so on uh 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 uh you know this seems like it makes sense when you look at it in a simplistic way it's missing out on the realities of bandwidth in China or something yeah all of that's possible so I I would certainly not claim to uh be able to tell which of these methods is is going to work if any and have have you looked at because in Bitcoin there's a whole range of of attacks that miners could use I mean we've we've talked on this show we've talked before about selfish Mining and about the miners dilemma some of the work that eming guner and it Al have done and they 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 you know known

issues with proof of work in Bitcoin some of the things are a little bit different um I mean so so ethereum's proof of work puzzle is designed to be GPU friendly rather than Asic friendly uh and so one of the things that we looked at in the analysis is to see if that is the the case and we concluded that yeah it does seem to be the case a lot of this wasn't uh even so much technical as a matter of looking at uh hardware cataloges and trying to get a feel for how uh different memory performance tradeoffs are and what their costs are and so does it seem like it would be possible that someone could uh make a dedicated Asic that would be thousands of times more effective than the commodity memory that you could buy and we concluded no the most cost-

effective way to solve this puzzle is to use a commodity available memory um so even while we concluded that it's effect Ive at being GPU friendly rather than Asic friendly I don't know whether being GPU friendly rather than Asic friendly is the the right choice uh for a cryptocurrency there's these kind of two you know opposing points that if you have as6 then at least you have this uh 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 superc computing or something like that so that is to say ethereum has some distinct differences from bit coin in terms of what attack and incentive Landscapes there are uh and even by pointing out

the differences I don't necessarily know which one's better uh similarly ethereum has uh this Ghost Protocol and that directly addresses some of the uh mining concerns uh especially in terms of you know 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 whether that actually exacerbates selfish mining attacks or gets away with that uh I know that the people who work on those probably have have some thoughts about that and I just uh don't remember what their opinions are so uh let's let's let's drive a bit into the uh into the proof of work function for ethereum like you have brought it up uh and we could maybe go into ghost later so like as as I

understand it like you could design proof of work functions in in to in at least three ways like you could have either have the target of being ASC friendly which is Bitcoin sh 56 you could have the target of being CPU friendly which means no matter if you use a GPU or an Asic um their performances are going to be pretty similar to what what the what the mining performance for a CPU would be so this was I think word coin and those guys tried tried this out for CPU friendliness and the third is GPU friendliness in which uh graphics cards are probably the best hardware to to do it so kind of is there any science to choosing one of these objectives or is

it All Pure guess work today yeah I'm inclined to say it's guesswork for for for choosing among 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 um I mean it's not exactly guesswork but it maybe involves uh some kind of sense of Economics or or macroeconomics or predictions about Hardware Trends which I find hard to do so like what does what does GPU resistance practically mean like um would would would do you think this means that in the future a lot of people will be able to mine ethereum unlike Bitcoin where uh miners are getting more and more

specialized yeah I mean that that that's uh that's the rationale for it um one of the things is by being GPU friendly one of the meanings of GPU friendly is that the 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 you know relevant parts of the GPU like the RAM and a simple processor um but and you and that'll be more cost effective and more efficient and higher throughput and all but it won't be that much more right so if you look at like a a GPU versus a Shot 2 Bitcoin mining ASC um it's just like thousands or tens of

thousands of times or some you know 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 uh Financial sense for someone to spend the tremendous amount of you know engineering design effort to go you know to go through the fabrication process of getting as6 made so even just closing that Gap may have the economic effect of discouraging people from going through that process of making highly spe specialized Asic and then yeah that 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 and GPU Computing and so on will be able to do

just about as well so why didn't they try to make a a proof of work puzzle that is actually suited for for CPUs is is that not possible I don't know how to do it I 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 uh you know Graphics Ram is just extremely efficient and and cost- effective right now and very powerful uh if 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 way to to 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 a foothold to designing a you know memory based puzzles if we had one for CPU that would be cool yeah one thing I've heard people mention was the idea that you have a variety of different proof of work puzzles and you sort of rotate them or or you put them on top of each other or something like that is that something you've ever looked at yeah like the X11 puzzle design um yeah I'm not I'm not sure about that I mean so it 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 Asics each one of which is specialized at accomplishing one of those tasks and then altogether it could still be you know 10 thousands of times better than a CPU so uh it could be 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 you know one of the things that makes uh uh CPUs designed is to be like uh to use minimal power so it it's plausible to me that there may be some approach that uh uh involves yeah 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

uh power down one circuit when that's not the one that's active um so I I I I don't really know it it's possible to me that some approach like that could work so uh I mean so the one other way that ethereum is trying to disin incentivize building of A6 for its p is by saying that hey we guys are going to shift to proof of stake so if you build an ASC Factory then you might be out left out in the cold yeah and and like our some of our listeners may know that Andrew is uh 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 that

statement so like Andrew could you explain um could you talk about proof of stake why did you come up with that statement and what were the conditions then and what has changed up till 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 uh puzzle at the time and I mean the essence of it is that you can you can do stake grinding for free in the sense that you can be applying stake to many different uh 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 uh your your your coins 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 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 uh design since then has had some explicit mechanism to address that concern so these are the punitive proof of stake uh algorithms where if you are caught double 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 uh you know Greg Maxwell's view is the 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 uh 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 they've already sold the money and moved on and so yeah so Pro 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 longrange attack that I'd still want to call a longrange attack even if it wasn't Costless uh but but yeah effectively those mean the same thing okay uh cuz yeah with long range attack right the IDE is okay you can go because if the security 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's some sort of mechanism that affects the the 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 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 I've never been totally confident about how many of the checkpoint mechanisms work so so certainly that would work but then the then the burden is on the effectiveness of the checkpoint mechanism that's also where my uh uh you know in-depth knowledge of this kind of uh uh reaches a limit so I I 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'm I would say I'm guardedly optimistic that there there's some way to do this very well of proof of stake that could work actually I would say I'm I'm in the middle it's 50/50 I have no idea whether there's going to be an effective proof of stake the 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 uh 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 uh restriction in time so I I like to wonder whether there's some inherent

kind of security that you can only get by burning real power and if not then I would suggest that there is a way to do it uh 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 g head over to let's talk bitcoin.com to sign in enter the magic word and claim your part of the listenting [Music] reward so um I mean I I guess the the the reason like this this kind of becomes like an 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 you're just saying because um you don't need to I mean it doesn't have to do with the smart contract execution it's just you you don't have to subsidize uh this big

expense I mean for sure the proof of work mining is the biggest expense in in Bitcoin it's like a million dollars per day um 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 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 of the cryptocurrency as long as you could still have Security in the same way and so overall your view is on on

proof for stake it's kind of it's interesting but you're like undecided whether whether it'll actually work and whether it will survive in the long run and and provide the kind of security that's needed once you have real value and really big applications running on these systems yeah I'm I would say I'm perfectly Razor's Edge undecided 50/50 it could go either way but I'm it's something I pay close attention to I'm really eager to know what the answer is so uh so from your from your whole design audit of e of ethereum um do you think there are some things that are missing from the ethereum ecosystem that would be nice to add as features um there are a few things uh 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 uh zero storage lightweight uh validation like you can be a full validating node you only effectively look at SPV proofs for each you know to validate each new block but I don't think that any of those are implemented any of the clients so the data structures there ready for it but the you know implementation of these things isn't developed yet maybe there is an SPV ethereum client now I I may not know if one's come out recently um another point that I want to make is that uh even though ethereum is tur incomplete there are some things that you can't do in ethereum script uh and actually what I'm going to describe

uh was pointed out although kind of as an aside in an academic paper by uh some other people Kias and Hong shenu and and and others but uh the point is that here's an example of something that you can't do with ethereum and it doesn't matter how tur and complete it is um something that you can't do in an ethereum contract is look at the other uh 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 uh 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 prior to the current block but you can't tell which transaction order you're in and you can't see the contents of the other transactions of the block when would that cause a problem um 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 call 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 has so you can see the previous you can see the 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 to 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 uh okay so so what you're essentially saying is like if if there's a contract in which uh 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 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 has 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 Turing complete you can do absolutely anything you know it actually depends on what kinds of information is passed in it depends on on this execution structure that on its own is just a counter example not a particularly uh 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 mhm okay I I thought like like reading through your paper I thought the most important thing that ethereum lacks is is really transactional privacy like the example you you gave was that if you have like five people that that want to bid on something then uh before the uh like let's say there's a beautiful Chinese was that the five of us want to bid on

and we want we want to put our bids in and um and then whoever has the best bid wins but ideally we don't want want to know each other's bids like we don't I mean the 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 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 uh but it would suffer from this pitfall the most direct and uh 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 um 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 uh but now you need to actually you know use The cryptographic Primitives that are provided like you have Shaw 3 at your disposal uh and there's a hardcoded uh contract extension that you can use to do U elliptic curve uh you know signatures to verify elliptic curve

signatures uh but for anything else you would either be forced to you know not have it or to basically try to implement it in the ethereum language and that's really difficult because uh it's just not uh uh it's costly to implement uh cryptographic Primitives directly into this virtual machine you would pay a lot of gas to do it that way so I mean so so like like we decided like so Andrew has this proposal called um I don't know if it's a proposal it's um 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 so I mean perhaps it's yeah per

perhaps like it's it's it's it's like a deep topic for us to go in in this current show cuz like we have a 1 hour slot but we'd like to discuss one of this proposal in another talk of yours CU it's a very interesting idea that you can have Smart contracts that both preserve the P privacy and where most of the computation is also offchain so it it it preserves gas as well it preserves privacy as well and it's a smart contract like like ethereum and it's as powerful as the ethereum contract language right mhm yeah I mean and just um I mean a brief 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 uh 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 uh op codes built in for hashes and for signatures but if you also had an OP code built in for uh various forms of uh of encryption or for zero knowledge proofs or for other kinds of cryptographic Primitives then you know maybe all of these things would be able to be more easily supported yeah so so actually in the future you could have you could have not only currencies like zeroc cach which are like truly anonymous quote unquote but you could also have Smart contracts

that are privacy preserving like these this 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 mhm okay that's that's very interesting like we we 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 you been looking around the ethereum ecosystem what are the kinds of projects that excite you oh wow um not as much as I I should have recently I watched some of the videos from Devcon which is amazing because they have um it's like it must be 40 hours of video footage of presentations all on these different projects I really like the one on

etheria world which is a whole uh 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 um I would say that right now BTC relay is probably my favorite contract you know that's one that uh uh you know you wanted us to talk about so happy to to talk about that a bit that's the first really sophisticated serpent contract that I saw um when I was asking vitalic for uh 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 vitalic how do I go do this thing and he'd say oh go look at a Joseph Charles project that has all the complicated serpent code in it and and yeah so I I

used uh BTC relays early code as like a textbook for how to do complicated string manipulations and stuff in Serpent and so it's a really uh 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 uh just like a Bitcoin SPV client receives uh proof of work headers from you know anyone who sends it to them like other nodes in the Bitcoin Network this is a smart contract that keeps track of the proof of work blockchain of Bitcoin and so you can advance its view of what it thinks is the longest

blockchain fork by uh 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 uh and then you can also prove to the SPV client in ethereum you can prove to BTC relay that a transaction's been included or not because you show it the path through the Merkel tree uh to the transaction that you care about in the blockchain that the the contract's aware of so it basically has a whole uh you know implementation of like a Bitcoin mobile phone uh blockchain viewer in ethereum and I think that that's really cool because uh and I can tell you a couple of other examples of you know why I like this the reason that I like this so much

is because this is It's a protocol that spans more than one blockchain there are only a couple of other examples uh like this and I love all of them so uh I'm probably also known as a promoter of the tier Nolan and I've been told that it's tier Nolan's and also Ido bov's uh cross chain Atomic swap so this is an old protocol that you could do just with hash loock transactions that lets you trade a Litecoin 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 you know scripting language but it involves two blockchains not just one and you know that's awesome yeah I mean I I've um like like this is this is probably the protocol that Drew my attention to you the first

time cuz cuz you wrote the script for it like I think TI noan came up with the with the idea and then you wrote the script for it and uh it's very interesting uh that U basically for our listeners that haven't heard of TN Lans protocol it's it's essentially a decentralized cryptocurrency exchange which allows you to trade Bitcoin with Litecoin and there's no counter party in the middle it's just you interacting with the two blockchains and conducting an exchange and you as as a a party to The Exchange can't can't be cheated by the other guy so this is really like truly decentralized change and this this protocol exists and it can actually be implemented in Bitcoin but for some reason it never was I I never understood

why we don't have we don't have an exchange that works with that protocol uh I've always wondered that myself it's such a a cute thing I mean like anything else it's probably just a matter of no one's gone out and done it you know I should go out and do it if I like it so much rather than uh just yammering about it um I mean it requires non-standard transaction type so that's the kind of catchall reason you'd have to go get it uh mind at Luke Junior's pool uh yeah but but it works and it uses script that's available today I mean around the same time uh Sergio Damian learner also made a proposal called P2P trade X which accomplished the same thing but in a more in a 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 cuz the idea is that this 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 side chains is the other example of uh you know protocols that span multiple cryptocurrency blockchains so just a last question before we wrap up with the BTC relay which I agree is like super cool right because you know the potential of course is that you can use all the smart contracts uh on ethereum you know with Bitcoin

basically uh and you know without having for example side chains uh although that might be interesting as well but so so because in ethereum like each computational step is 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 uh on the Bitcoin chain is is that going to be very expensive uh yeah I think it will be very expensive especially right now given the current gas prices uh this is one of the reasons why BTC relay I mean I think it runs it runs and it works on the ethereum test net so not even on the ethereum frontier Network and the reason

why is just that it would be prohibitively expensive right now um I realized that just sending data to transactions is quite expensive in ethereum right now I I worked on this a gadget called um like a block hases 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 look lets you look at uh 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 a a an untrusted blockchain mirror for ethereum blockchain itself uh and I realized that I initially wanted to basically send this uh 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 256 blocks or so which is still fun but 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 you don't have to you know if lots of different people people use it they get to sort of amortise 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 uh 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 then like verifying proof of works and the headers and and even that might be expensive no yeah I mean fortunately that's pretty cheap so like the shaw 2 op code is is pretty cheap in 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 uh of hash computations so uh you know that's one reason that 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 was lots of topics we could have talked about but thought it was hopefully also gave people an interesting uh perspective on on gas which I think is going to you know it's obviously a core feature of ethereum and a core component of how it works and thanks so much for sharing your views on that yeah this was a lot of fun uh 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 listening hopefully you enjoyed this and hopefully you learned a little bit more about etherum how that works and and how Gas Works and uh very excited to see where that's going to go and you

know once we have things like BTC 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 letort Bitcoin Network so if you want to check out this show or also lots of other shows you can do so let's talk bitcoin.com of course you can also download the mobile um the audio versions of this on mobile on Soundcloud or you know whatever podcast app you use and you can watch video we video as well and that's on youtube.com/ Center Bitcoin and you know speaking of ethereum and speaking of YouTube Mayers uh videos from Defcon 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 [Music] week [Music] no