14 September 2020
SN
07:28
Spencer Noon
T minus 90 minutes until our EIP 1559 AMA! 🍿
SN
08:49
Spencer Noon
10 minute warning!
09:01
Alright folks, welcome to this Monday version of Crypto AMA. Today we're doing a 1-hour session on EIP 1559 with @timbeiko @gakonst and @hasufly — thanks for coming on!
09:02
Guys, can you tell us a little bit about each of your respective backgrounds as well as your work/expertise on today's subject
09:02
We'll then dive right into questions
GK
09:02
Georgios Konstantopoulos
Hi everyone, Spencer, thank you for having us. In the past I operated as an independent consultant, working on L2 scaling, security auditing and zero knowledge proofs. Currently, I am a Research Partner at Paradigm, working closely with our portfolio companies, while also doing broader work on subjects that I believe to be impactful for Ethereum and Bitcoin, such as EIP1559.

Hasu & I published a couple of blogposts on this subject:
- EIP1559: https://insights.deribit.com/market-research/analysis-of-eip-1559/
- EIP2593: https://insights.deribit.com/market-research/analysis-of-eip-2593-escalator/).

We also talked about elastic blocks and touched on EIP1559 in the ZK Podcast: https://www.zeroknowledge.fm/142
TB
09:03
Tim Beiko
Hey all 👋

My full time role is as a PM for Hyperledger Besu, ConsenSys’s Eth1 client.
09:04
As part of that, our team decided to “revive” the work on EIP-1559 earlier this year (right after EthCC). Since then, we’ve implemented it in our client, and I’ve been acting as a sort of “unnoficial project manager” to help coordinate the implementation, R&D work, funding and public comms.
H
09:08
Hasu
Hi, I'm an independent researcher and writer in this space (as in, not affiliated with any particular project). Currently, I run the research desk for Deribit, the largest options exchange. Most of my previous research was focused on the economic security of public blockchains. I immediately took an interest in EIP-1559 because it represents the intersection of all my interests (security, economics, game theory, mining, fees...)
09:09
(sorry for the slow reply, will be faster now)
SN
09:09
Spencer Noon
Cool, thanks guys!
09:09
Questions good to go
09:10
@timbeiko let's start with you: for those of us who have been preoccupied with the latest emoji farm, what's the latest update on EIP-1559? Have there been any material changes over the last few months? When do you think it will ship?
TB
09:12
Tim Beiko
In reply to this message
For updates, we now have two client teams working on implementations of the EIP (Besu & Vulcanize, the latter which is working on Geth). Alongside that, research is being done to determine whether EIP-1559 is game theoretically sound (Tim Roughgarden, a Columbia CS/game theory professor has now been contracted to to so) and the EF is working on simulations of the EIP.

We typically have monthly contributors’ calls (posted here: https://github.com/ethereum/pm/issues/197) and I summarize them on Twitter (i.e. here: https://twitter.com/TimBeiko/status/1299397735171280896)
GK
09:12
Georgios Konstantopoulos
(this is an insane understatement about who Roughgarden is :D)
09:13
Apropos of nobody asking: IMO if you're an ETH investor you MUST be paying attention to EIP1559 because it is a fundamental change in Eth1's monetary policy
SN
09:13
Spencer Noon
In reply to this message
fill us in georgios 🙂
WN
09:13
Will Nuelle
What are the major outstanding economic questions associated with EIP-1559?
TB
09:15
Tim Beiko
With regards to material changes, there have been a _lot_ of proposals over the past few months. Some have been pretty minor technical minutiae while others have been broader potential changes based on UX/community feedback/etc. Before we commit any large changes, we’re trying to rech out to as many folks in the community to better understand the impact 1559 would have on their project. Shameless plug here 😄 https://forms.gle/3Jd4JpQgh3ZCfP3bA
TC
09:16
Tarun Chitra
What is the greatest level of precision (in terms of % of block reward emissions) that you think something like EIP-1559 can correct for? One simplistic way to view the burns is as corrections for over/under issuance based on demand, and I’m curious if you think the mechanism can be made very precise or has limits to how well it corrects (a la difficulty)
H
09:16
Hasu
In reply to this message
I think the big question is "is this mechanism incentive-compatible". as in, assuming people are rational, does it achieve its stated design goals?

Many people with a fundamental grasp of game theory and mechanism design have looked into it and not found any major issues, but we also find it extremely valuable to now have Prof. Roughgarden perform a formal analysis and give the final ok.

tldr: are there are no known outstanding issues, but there might be unknown ones.
GK
09:16
Georgios Konstantopoulos
In reply to this message
His work on game theory & auctions has _created_ a new field called "algorithmic game theory" which has applications from resource allocation in large networks, to online advertising. It is incredibly exciting to see such a figure be interested in our space. He's also done previous work in crypto on finding optimal/incentive compatible reward payout functions for mining pools, e.g. http://timroughgarden.org/papers/bitcoin.pdf
TB
09:17
Tim Beiko
In reply to this message
For timelines, this is always tricky! What I’m personally aiming for is “the fork after Berlin” (current fork being planned for Ethereum). Not sure I’m willing to commit to more than that 😅

One reason for getting the work started right after EthCC was to make sure that 1559 would ideally land _before_ other major changes proposed as part of Eth 1.x (i.e. statelessness). This would make 1559 easier to ship because both proposals won’t have to keep adapting to each other.
Spencer Noon invited Joe Andrews | Aztec
GK
09:19
Georgios Konstantopoulos
In reply to this message
Agreed with this. In addition, I think the simulations will improve our understanding of the soundness of the mechanism, but in the end we'll need to 1) get formal results around its incentive (in)compatibility and 2) see how it does in a live (incentivized) testnet
09:21
In reply to this message
I think this is somewhat accurate: By "correcting over/under issuance" via the burn, you're adjusting the security budget of the system depending on demand.
EW
09:21
Eric Wall
Are there any new/old attack vectors introduced/amplified by eip1559 that could cause a non-negligible systemtic threat that you're aware of? If so, what's the most important eip1559 security "FUD" to track?
W
09:21
William Phan
thoughts on the fee-war being replaced with a tip-war?
GK
09:22
Georgios Konstantopoulos
In reply to this message
One kind of "FUD" is that the BASEFEE goes to 0 (intentionally potentially) and gets stuck there, so all of this effort was done for no reason
SN
09:22
Spencer Noon
In reply to this message
ELI5 tip war?
E
09:22
Evan
How has the Filecoin testnet performed relative to expectations?
TB
09:23
Tim Beiko
In reply to this message
I’ll let others chime in as well, but from a client PoV, the biggest risk is that the network can’t process “1559-full” (i.e. 2x larger than normal) blocks for even a short period of time.
E
09:23
Evan
What is the best way we can get empirical evidence (to help narrow the cone of uncertainty about unknown unknowns) that 1559 works as intended?
H
09:23
Hasu
In reply to this message
Not sure that I understand the first part of your question, but agree that the burn can be seen as a correction for both over- and underissuance of block rewards to miners.

The reason it can be seen that way is that EIP-1559 combines well with a perpetual block subidy, which is the most stable incentive to miners (compared to txn fees, which can create incentives for fee sniping and chaintip instability)

With a perpetual block subsidy + fee burn you can ensure that miners earn *at least* x% issuance per year, but not much more (since most of the fees are burned).

The only way known to me how you would fine-tune the issuance further is by raising or lowering that subsidy, not really tinkering with the fee burn.
JW
09:23
Jesse Walden
ELI5: what does EIP1559 (in its current state) mean for the UX of your average Metamask user?
I
09:24
Ismail
How and when does the work on EIP-1559 intersect with the Ethereum 2.0 efforts?
GK
09:25
Georgios Konstantopoulos
In reply to this message
Due to the BASEFEE overshooting very quickly, it is not sustainable to have tip auctions for long durations. So there most definitely will be tip wars, but we expect them to not be happening consistently, UNLESS they're done in order to frontrun others' transactions e.g. in arbitrage opportunities
TB
09:25
Tim Beiko
In reply to this message
Open to suggestions here, but the way we are going about it is by having gradually more complex testnets. Right now, we’re just testing consensus across 2 implementations on a PoA network, next step would be testing on a PoW network and spamming it with a ton of txns to see how clients react, then I think we’ll need to test on a network with a large existing state (probably Ropsten) to see how “bad blocks” can affect the network.

In parallel to that, there is obviously the R&D work mentioned earlier going on.
W
09:26
William Phan
In reply to this message
EIP1559 introduces tips on top of a base fee, so now instead of users just cranking up the gas price to get their tx included in the next block, they can add a tip on top of the base fee, which on first glance appears to just defer the problem
H
09:26
Hasu
In reply to this message
If we are talking about priority gas auctions (PGAs), so multiple people bidding to get the same transaction included, or people trying to get mutually exclusive transactions included, the answer is 100%.

These auctions will continue to happen in any block, no matter how full, but shouldn't really affect other users further down in the block who are willing to pay the basefee.
GK
09:26
Georgios Konstantopoulos
In reply to this message
I do not know what the expectations were, unfortunately testnets on nacent networks with little to no users tend to be "empty" most of the time, which kind of defeats the purpose of EIP1559 (since it requires some actual demand). You can see how the BASEFEE behaved here, and it was mostly at 0.
09:27
In reply to this message
I think that it doesn't need to be "spammed" with transactions, on the contrary we must define a few demand distributions based on empirical data (e.g. seasonality due to timezones and demographic of ethereum users) and see how the BASEFEE behaves depending on them
TB
09:28
Tim Beiko
In reply to this message
Right now they are pretty separate. There is a desire to have 1559-style fees in Eth2 but I’m not aware of any formal spec or implementation yet. I think it’d be good to see how it performs on Eth1 to inform the Eth2 design!
H
09:29
Hasu
In reply to this message
to expand on this a little bit, the reason that paying the basefee + min tip is almost always enough to get into the block is that EIP-1559 introduces a flexible blocksize.
Instead of a single hardcap, there is now a target blocksize (same as today, 12.5m gas) and a max blocksize of twice that (so 25m). The basefee moves up and down in a way so that blocks are always on average 50% full. Therefore, there is always extra room for someone who is willing to pay that basefee.
TB
09:29
Tim Beiko
In reply to this message
I don’t think it’s either/or but both. Agreed! This is part of what Barnabe from the EF has been working on, see: https://github.com/barnabemonnot/abm1559
GK
09:30
Georgios Konstantopoulos
In reply to this message
The "pop-up -> click -> wait" flow of Metamask will not change. Due to how fee estimation is simplified (on the application level), we expect that fee volatility will be reduced and you'll be paying less fees as a result.
TB
09:32
Tim Beiko
@jessewldn here are some mocks the MetaMask team had put together a while back.
GK
09:32
Georgios Konstantopoulos
^ But these are for the "advanced" view, ideally you'll never have to use them
TB
09:32
Tim Beiko
That’s right ^
E
09:32
Evan
09:32
JW
09:33
Jesse Walden
Cool, thanks. Sounds like its mostly behind the scenes, but ideally with volatility reduced, there'll be fewer instances of failed txs, or txs you need to speed up
E
09:33
Evan
In reply to this message
Screenshots may be helpful
GK
09:33
Georgios Konstantopoulos
In reply to this message
Correct, speeding up txs is a thing you need to do because you underpaid
09:34
But if you estimated properly when you initially sent the tx, then it wouldn't be needed at all
H
09:34
Hasu
In reply to this message
Users now have to decide two parameters:
1) tip (which replaces the current fee)
2) feecap

feecap is the maximum basefee you are willing to pay, but you end up paying the same basefee rate as everyone else.

And because blocks almost always have extra capacity, you should be able to get your txn included in most blocks if you just pay the asked basefee + a minimum tip.

So IMO it more resembles buying something off amazon that's quoted to you at a fixed price rather than having to predict how other transcators are going to behave.
GK
09:34
Georgios Konstantopoulos
And EIP1559 + BASEFEE remove this need to estimate altogether, since you're always paying the same amount (+ the tip which is going to be minimum most of the time based on our current understanding)
H
09:36
Hasu
In reply to this message
the need to speed up txns should be significantly reduced, as you can very safely "overbid" for the transaction in the sense that you define a margin of safety, but you never pay more than everybody else. So choosing a high margin of safety is actually a low risk.
09:36
Just saw G already answered
SN
09:37
Spencer Noon
In reply to this message
Curious if anyone on the research side can chime in on Eth2 1559-style efforts
GK
09:37
Georgios Konstantopoulos
You get an EIP1559 market per shard is the last story I heard, but I don't think there's anythign super concrete
09:38
There's a Github iIssue with Justin Drake and Dankraad Feist discussing it IIRC (looking for it now), but there's no specification or concrete plan around it. It's a "we want it to happen" thing, but TBD
WN
09:39
Will Nuelle
Are miners’ revenunes adversely effected by 1559? What has been the reception from the mining community?
I
09:40
Ismail
Are there constraints that the EIP1559 team currently struggles with that could be solved with more funding?
DV
09:40
David Vorick
What is the impact on the overall throghput of Ethereum?
DV
09:41
David Vorick
In reply to this message
And also validation cost
GK
09:41
Georgios Konstantopoulos
In reply to this message
Long term the blocksize is the same, you're targeting 50% utilization of the 2x new total. So if blocks are 10m gas today, EIP1559 makes them 20m gas but targeting 50% utilization. You just have some slack which allows you to improve the fee situation. So it's not a blocksize increase per-se, if you zoom out enough
H
09:42
Hasu
In reply to this message
Fees are currently a signficant (I think >50% of the entire mining reward even?) part of overall miner revenue. Post-1559, the basefee part of the fee would be burned instead of going to miners.

Miners would still get the tips, which would be more than most people would believe. The reason that tips will still be significant is that PGAs still take place in every block as arbitrageurs bid for priority. So most revenue from arbitrage still goes to miners post-1559
Z
09:42
Zhen | Torus
In reply to this message
On this note, one of the points brought up when discussing EIP1559 is the possibility of introducing perpetual block rewards and therefore circumventing the insecurities that come with the opposite. How are we thinking about block rewards moving forward?
H
09:42
Hasu
In reply to this message
However, miners we've talked to are understandably not excited any reduction of their revenue.

personally, I think they should be as 1559 is long-term very positive for Ethereum and the fees that are diverted from miners go to token holders, which makes the reward more valuable.
TB
09:43
Tim Beiko
In reply to this message
Right now, I think we’re mostly good. We’ll need ongoing funding to keep our current pace but there are no big areas that aren’t funded 👍
GK
09:43
Georgios Konstantopoulos
In reply to this message
Yeah, MEV opportunities will still exist in a post-EIP1559 world, so there still be big fees that go to miners via tips
09:44
In reply to this message
(clarifying: fees go to token holders indirectly, via the burn)
TB
09:44
Tim Beiko
In reply to this message
For validation costs, there aren’t really any impacts on a fresh sync (because even if you have a bunch of full blocks that are 2x the size of our current ones, it’s only like if you added those blocks to the tip of the chain, in a way). If you are at head and syncing each block as it comes, then yes, some blocks could take 2x longer to validate/propagate and this could increase the risks of certain DoS attacks. One EIP that’s being put forward to reduce those risks (prior to 1559 going live) is EIP-2929: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2929.md
GK
09:45
Georgios Konstantopoulos
In reply to this message
The biggest issue would be if e.g. you got N blcoks with 2x the size sustainably
H
09:45
Hasu
In reply to this message
The current consensus in Ethereum is to introduce perpetual block rewards (or rather, keep them, since Ethereum currently has no halving schedule). I'm personally a big believer since a block subsidy generates very predictable and stable incentives for miners and hence consensus stability and confirmation times.
GK
09:45
Georgios Konstantopoulos
The testnet will tell, this is the kind of thing where you stress test. & see what happens
DV
09:45
David Vorick
Are the 2x burst rates being considered in the light of selfish mining?
09:46
Does it make selfish mining easier during periods of congestion?
GK
09:46
Georgios Konstantopoulos
You mean due to the fact that propagation becomes worse?
DV
09:46
David Vorick
Yes
GK
09:47
Georgios Konstantopoulos
I think this is correct, any deterioration in block propagation means that there's better opportunities for selfish mining. The counterpoint is that you won't get 100% utilization blocks for insanely long periods of time due to the basefee rapid overshoot
09:47
(I understand that my "basefee overshoots fast which means you can't be at 100% for too long" point might be a little handwavy)
09:48
e.g. if yield farming opportunities are providing you enough profit, you may end up using the chain even with BASEFEE=1 ETH
09:49
The basefee though ends up increasing by 12.5% each time, in my sims fees quickly went to thousands of dollars when there was lots of demand, which you'd expect would throttle demand heavily
H
09:49
Hasu
In reply to this message
I'm adding this as a sidenote, but >50% of the skepticism around 1559 is in some shape or form related to the question if the proposal doesn't try to achieve too many design goals at the same time. Usually followed by demands to unbundle it into several standalone mechanisms.

One of those would be a standalone elastic blocksize mechanism. But David's question actually shows why you can't have elastic blocksizes without a way of charging miners for making them. Otherwise, larger miners would have an incentive to make larger blocks all the time to de-facto selfish mine by increasing the propagation time of their blocks.

1559 nicely solves that with the basefee, a way for miners to pay for larger blocks, but only if they can directly recoup the cost from users.
09:50
In reply to this message
GK
09:51
Georgios Konstantopoulos
The code for all these (albeit super dirty) graphs is here: https://github.com/gakonst/eip1559
SN
09:52
Spencer Noon
~10 minutes. Get your questions in, folks!
TB
09:54
Tim Beiko
For people who may read this after the fact, the best place to ask follow ups to implementers & researchers is the Eth R&D discord: https://discord.gg/B4yx9SQ
SN
09:55
Spencer Noon
Great call. And what's the best place to follow along with updates?
TB
09:56
Tim Beiko
In reply to this message
Depending on how much granularity you want:

1. I give high level summaries on twitter (last one here: https://twitter.com/TimBeiko/status/1299397735171280896)
2. Our monthly implementers’ calls (uploaded to Youtube, last one here: https://youtu.be/fI2IhcvuJA0)
3. The discord channel, where most daily conversation takes place: https://discord.gg/B4yx9SQ
09:57
Also, if you’re a project building on Ethereum and have thoughts/concerns/comments about 1559, the best place to provide structured feedback is here: https://forms.gle/3Jd4JpQgh3ZCfP3bA
SN
09:59
Spencer Noon
Awesome, thanks Tim!
09:59
Any last questions folks?
TB
10:00
Tim Beiko
In reply to this message
Of course! Have to jump to another call but happy to answer any other questions that trickle in throughout the day. Thanks for organizing Spencer 😄!
SN
10:00
Spencer Noon
Alright, think that's going to do it — thanks for coming on @timbeiko @gakonst @hasufly! Feel free to drop any parting thoughts as well as how folks can stay in touch with your work
H
10:00
Hasu
Likewise - if you have any straggler questions, feel free to just drop em here and we'll answer them later today
10:01
cheers, and thx for participating
GK
10:01
Georgios Konstantopoulos
Telegram works, or https://twitter.com/gakonst, DMs open! Thanks for having us Spencer
I
10:01
Ismail
Thanks All, this was great