EIPs are the unit around which governance happens in Ethereum. Anyone is free to propose one, and then various stakeholders in the community will debate to determine if it should be adopted as a standard or included in a network upgrade.
- Ethereum.org, Why EIPs Matter
Index
Lecture
Office Hours
Guest Speaker
Supplemental Resources
Lecture
â–¼Lecture Transcript
The following transcript was auto-generated, and may content syntactical errors.
00:00:00.000 --> 00:00:02.000
All right. Welcome to today's. Course today's class we kick off week 2 I'm gonna start the recording now so if you don't wanna be recorded, please feel free to drop off.
00:00:02.000 --> 00:00:12.000
All right, thank you all for joining us. Today, we are. Yeah, I'm gonna just.
00:00:12.000 --> 00:00:26.000
Put the captions on, so everyone can see them hopefully. We're in week 2 of our of our course understanding a theorem network upgrades.
00:00:26.000 --> 00:00:31.000
I'm Tom, I'm joined by Matt. You'll also find on here.
00:00:31.000 --> 00:00:56.000
Helping us.
00:01:10.000 --> 00:01:27.000
Of the Ethereum community and how that community comes together to do upgrades, but today we're actually going into the nuts and bolts of like what How do we figure out what gets included in upgrades in that?
00:01:27.000 --> 00:01:34.000
Is done via this EIP process. So. This is the high level slide.
00:01:34.000 --> 00:01:41.000
If you take one thing away and you slides are posted within the course and they'll be posted again.
00:01:41.000 --> 00:01:57.000
Once we have the recording up. You can find all the links. Follow along but I think the big thing is that this is literally the unit the the piece of,
00:01:57.000 --> 00:02:07.000
Of information around which we kind of build. All other processes around Ethereum, I think. If you listen to our guest speaker on Monday.
00:02:07.000 --> 00:02:08.000
These are
00:02:08.000 --> 00:02:13.000
Pooja, the, the herder in chief of Ethereum cat Herders
00:02:13.000 --> 00:02:27.000
I think she did a really good job of making the point. That EIPs are So critical and where it really starts and that's a big reason why Ethereum cat herders.
00:02:27.000 --> 00:02:39.000
Emerged because that is the layer at which. Ethereum upgrades. In a sort of controlled chaotic way, right?
00:02:39.000 --> 00:02:47.000
I think we've kind of all agreed that like there's a little bit of that. The little bit of chaos is good.
00:02:47.000 --> 00:02:57.000
But you also need to. Direct that chaos a little bit to have it be productive. So, Matt, do you just wanna talk about?
00:02:57.000 --> 00:03:02.000
The fact that You have, we have a note here that. There is no blocker on who can propose an EIP.
00:03:02.000 --> 00:03:08.000
What what's up with that?
00:03:08.000 --> 00:03:22.000
Yeah, so. We'll dive into a little bit of the process of maintaining kind of a life cycle of an EIP, but I think that's the beauty of it is that it's really up to the proposinger to drive champion and kind of shepherd their proposals.
00:03:22.000 --> 00:03:28.000
Through this process. The reason that there's no blockers is because, you know, we, run an open source kind of environment, a decentralized governance process.
00:03:28.000 --> 00:03:50.000
So since these are the units around which governance happens in Ethereum we need anybody to be able to make that kind of a proposal right but you have to gain the consensus of folks across a variety of different areas so it's really on the proposal to be able to do that.
00:03:50.000 --> 00:03:55.000
But there are no blocks in need to get to get involved. So. We'll keep it moving and talk some about some of those statuses stages of a proposal.
00:03:55.000 --> 00:04:12.000
Live cycle and why it's a little bit challenging to get EAPs included. But at the same time, there, you know, these are extremely important to Ethereum because this is the, this is the way we change almost anything on the network.
00:04:12.000 --> 00:04:19.000
So we've moved over here to the actual IP process. Tom, do you wanna give it 2 s?
00:04:19.000 --> 00:04:23.000
I need to grab some water. I'm have a frog in my throat it seems.
00:04:23.000 --> 00:04:31.000
For sure. I think if we're thinking, you know, one big. Link that we called out is EIP one.
00:04:31.000 --> 00:04:42.000
A very Meta EIP if one could say it. It's an EIP that almost defines, what it is a EIP that defines what, it is an EIP that defines what EIPs are.
00:04:42.000 --> 00:04:50.000
And there's a quote here that we just wanted to read to you in order to contextualize.
00:04:50.000 --> 00:04:53.000
Everything that's about to follow and EIP should primarily provide a concise technical specification with a small amount of motivation.
00:04:53.000 --> 00:05:08.000
Keep that first sentence in mind as you start to look at EIPs, whether you think that we've adhered to that.
00:05:08.000 --> 00:05:19.000
The EIP author is responsible for reaching consensus within the community and documenting alternative options. Simple statements seems pretty straightforward.
00:05:19.000 --> 00:05:33.000
I think we've already shown reaching consensus amongst many overlapping groups. Could be a A unique.
00:05:33.000 --> 00:05:41.000
Quest to go on and I and I will term it as that a quest. It's almost like the hero's journey in a way.
00:05:41.000 --> 00:05:53.000
And being able to document alternative options. Seems very straightforward, but. The complexity and possibilities.
00:05:53.000 --> 00:06:04.000
Can actually be quite overwhelming. So with that context, let's. And I'll let Matt talk generally about how we move through.
00:06:04.000 --> 00:06:13.000
This nice little chart here of we have some nodes and edges. We love nodes if you haven't figured it out yet.
00:06:13.000 --> 00:06:25.000
And so, will, will sort of talk through how we move from idea to, some sort of status where the EIP ends up.
00:06:25.000 --> 00:06:34.000
Yeah. So. We have of course, as Tom mentioned, a concise technical specification and a small amount of motivation.
00:06:34.000 --> 00:06:52.000
I think that's what we call the idea, right? You have something that you want to change within Ethereum, whether it's an application standard, a the way that client software is run, you want to add a new opcode, you want your smart contracts to be able to have more functionality at the base layer.
00:06:52.000 --> 00:06:55.000
Those are the kind of small units of technical specification. And then you have the motivation for why you're doing that, of course.
00:06:55.000 --> 00:07:04.000
You know, I want this new gas costing because I believe that the Existing gas schedule doesn't make sense in light of XYZ.
00:07:04.000 --> 00:07:14.000
That's a great EIP, right? And you have a, you know, you draft that idea.
00:07:14.000 --> 00:07:29.000
We have multiple repositories where those ideas live for the EIP repository. We'll talk soon about ERCs and others, but you you know, you draft this, you work it with the community, as mentioned by Puja and others the other day you need to engage with the fellowship of the theorem magicians.
00:07:29.000 --> 00:07:39.000
The reason being is that we, you know, the EIP standard of quality. Is somewhat high, right?
00:07:39.000 --> 00:07:54.000
So you want to be able to vet this idea that you have with the community before you submit it for kind of a formal review where you're taking resources from the other EIPs that might need attention from the community of editors that manage these EIPs.
00:07:54.000 --> 00:08:12.000
So when you take their attention, you want to make sure that you have a validated idea. So you reach out to these folks on Ethereum magicians, you vet the idea with the community, you see if it's already been done before a lot of the times, oh, maybe I have this great idea and you find a thread from 2 years back on a theory of magicians about the same idea and then you can read the logic
00:08:12.000 --> 00:08:32.000
for why the idea was never progressed, right? So there's a lot of kind of onus of, understanding on the author to go and do a lot of that initial leg work to draft their idea to be concise to build a rough consensus and then to submit the EIP for review and feedback.
00:08:32.000 --> 00:08:36.000
So you're moving it from the draft stage. Which might be opening a PR in the GitHub repository.
00:08:36.000 --> 00:09:00.000
Providing all the relevant details and then you put it up for review. So this is when we have, you know, depending on how far along the IP is, this is when we have the actual EIP editors come in and work with this this is might be the time where folks like Pooj's team, the Ethereum cat herders would come in and actually Move forward your proposal if
00:09:00.000 --> 00:09:13.000
it needs additional help. They have that kind of EIP in progress meeting that EIP-IP meeting that was discussed the other day which sort of acts as a core devs consensus call of the EIP editors.
00:09:13.000 --> 00:09:19.000
So there's really a lot of different stages of review that are happening. And different different people that are reviewing it.
00:09:19.000 --> 00:09:27.000
You'll likely have your specifications torn apart. Your motivations torn apart. And these are all good things, right?
00:09:27.000 --> 00:09:46.000
The kind of review phase is where a lot of the work gets done. And it's kind of moving through this process or it either becomes stagnant where it will be basically left for a later date or for not at all, or it moves into some of these other phases.
00:09:46.000 --> 00:09:51.000
So at any point in the IP, you can of course be withdrawn. If you no longer feel that the protocol needs the change that you're proposing or if you found an alternative solution that would nullify your previous proposal.
00:09:51.000 --> 00:10:12.000
Or if you just don't feel like managing it or dealing with it, whatever it may be, the author can move it to withdrawn stage however the information is always out there so others can revive your EIP in different forms if they like what's being proposed.
00:10:12.000 --> 00:10:21.000
So as EIPs move to the Last call phase this is when things get kind of a little bit interesting.
00:10:21.000 --> 00:10:33.000
So they typically hang out in this kind of living bubble for the longest time. If you have any IP that has been thoroughly reviewed thoroughly vetted, but not necessarily yet ready for inclusion and a hard fork.
00:10:33.000 --> 00:10:34.000
It's a living IP. It kind of hangs up for a little while because again, we only ship a handful of hard forks.
00:10:34.000 --> 00:10:49.000
The theorem network upgrades. Within a year, 2 year period. So a lot of these EIPs basically wait around until they're considered for inclusion for a forks.
00:10:49.000 --> 00:10:57.000
So as these upgrades come, the core devs and the Cordevs calls will happen. We will have EIP authors?
00:10:57.000 --> 00:11:03.000
Add agenda items to those Cordevs calls to make impassioned arguments about why their EIP should be included in the next upgrade and why.
00:11:03.000 --> 00:11:14.000
It should be considered for inclusion by those client dev teams. And just Cordevs in general.
00:11:14.000 --> 00:11:26.000
So they The next upgrade is coming around. We say, oh, we have 10 EIPs that are candidates and we move them toward across this thing into this last call phase.
00:11:26.000 --> 00:11:36.000
If a EIP is slated to be included in a network upgrade, it moves to last call because you cannot start tweaking things with any IP after client teams have to start implementing it.
00:11:36.000 --> 00:11:37.000
So if we say, okay, in the Cancun fork, we're including EIP, 4, 4, 4.
00:11:37.000 --> 00:12:02.000
It as it moves to the inclusion phase and we've decided for sure that we were including it it moves to last call where the EIP itself is not frozen but somewhat more locked down so that there's not a lot of changes happening quickly and iteration happening quickly because folks that are building this don't want to have to redo the work.
00:12:02.000 --> 00:12:10.000
However, there is a period of iteration with the EMP authors because You know, everything looks great on paper as a specification.
00:12:10.000 --> 00:12:21.000
But when you go to actually build something in real code, oftentimes you find that the spec will have holes or it will need updates and this is a kind of iterative process.
00:12:21.000 --> 00:12:26.000
So the EIPs are hanging out in last call. We ship a hard fork. So say we ship Shanghai.
00:12:26.000 --> 00:12:31.000
We have withdrawals, for example, the EIPs. Only then, will any, be VIP become final.
00:12:31.000 --> 00:12:41.000
And the reason being is that the final EIPs are a very exclusive list and they are meant to be indicative of what is live on the network at any given point in time.
00:12:41.000 --> 00:12:46.000
Unfortunately, the reason for this is because the Ethereum yellow paper is maintained in different kind of states at any given point.
00:12:46.000 --> 00:13:05.000
So if you were to go from scratch and try to build an Ethereum client today you'd have to look at the Ethereum yellow paper you'd have to look at the whole list of finalized EIPs and then you'd have to go build something that basically starts in one place and iterates slowly to another place.
00:13:05.000 --> 00:13:19.000
But in any point, the those final APs are meant to be kind of a living purpose of what has changed on Mannet and what all clients need to have implemented in order to be able to participate meaningfully in the network.
00:13:19.000 --> 00:13:20.000
This is going away a little bit because we now have Python specs for both the execution layer and the.
00:13:20.000 --> 00:13:31.000
Layer, which is great. Which just means that at any given point instead of having to read.
00:13:31.000 --> 00:13:44.000
Hundreds of VIPs and the, the, in order to. Meaningfully engaged with the spec, you can look at the point in time snapshot of the specification, which is those execution layer specs and consensus layer specs that live in the Ethereum GitHub.
00:13:44.000 --> 00:13:54.000
We'll talk about these a little bit more in future. Items, but those specs are, again, directly influenced by the finalized EIPs as well.
00:13:54.000 --> 00:14:04.000
So it's a little bit of a push and pull. The process has actually changed slightly. From what it used to be that those specs didn't know didn't used to exist and we had to follow this exact process.
00:14:04.000 --> 00:14:17.000
But now we have a little bit more flexibility since we have a, living up to date version of the specification, written Python, which makes it a lot easier to draft the IPs and a lot easier to interact.
00:14:17.000 --> 00:14:26.000
To understand how your EIP might interact with other specifications. And to get examples. Code snippets, templates.
00:14:26.000 --> 00:14:34.000
Whatever. Cool. That was extremely long winded.
00:14:34.000 --> 00:14:35.000
Yeah.
00:14:35.000 --> 00:14:45.000
Let's pause here for questions because we are definitely we we are definitely front loaded on this one. We do have a lot of other good information and if questions come up, we we we can push.
00:14:45.000 --> 00:14:51.000
Forward to that, but I think now's a good time to stop for questions people have because I can feel all the questions.
00:14:51.000 --> 00:15:00.000
I can feel them and if there's any that were submitted. If the core project management team just wants to read those out to us.
00:15:00.000 --> 00:15:06.000
That, is helpful as well.
00:15:06.000 --> 00:15:13.000
And I want to reiterate this is just the process. We'll dive a little bit more into what the EIPs look like feel like.
00:15:13.000 --> 00:15:18.000
Smell like. But right now this is kind of just the overall process from a kernel of an idea.
00:15:18.000 --> 00:15:25.000
It's a real governance and real specifications, which I think is frankly the most interesting part, but I know there's a ton of questions.
00:15:25.000 --> 00:15:27.000
Potentially so.
00:15:27.000 --> 00:15:36.000
I have a question. Is there an average length of time that it takes to get, an EIP through or is everyone really different to the end that there is really no.
00:15:36.000 --> 00:15:48.000
Estimated time from when it's first introduced to when it is shepherded through.
00:15:48.000 --> 00:15:49.000
Yeah. It really depends on the EIP, right? Some EIPs are very small units of work.
00:15:49.000 --> 00:16:01.000
They're you know, it could be like essentially a typo in the spec or like I said, a gas cost change.
00:16:01.000 --> 00:16:08.000
Something very simple like this used to be really expensive based on old computing hardware and now maybe it's really cheap based on new competing hardware.
00:16:08.000 --> 00:16:15.000
So we changed the gas cost. That takes literally minutes for clients to implement and in minutes for people to test.
00:16:15.000 --> 00:16:21.000
So oftentimes those EIPs move very, very quickly. You can look at something also like EIP, 1559, which we'll discuss at our case study later on where it took over 3 years.
00:16:21.000 --> 00:16:31.000
From the EIP being drafted and authored to go through the process and be implemented on main net.
00:16:31.000 --> 00:16:41.000
In like 2021 so it's really briefly depends on the substance of the EIP. It also primarily I think depends on how controversial the EIP is.
00:16:41.000 --> 00:16:47.000
If you have an EMP that is universally loved, it's universally beneficial. It's universally interoperable.
00:16:47.000 --> 00:17:00.000
It'll be much quicker for it to go through this process. But if you have contention in what you're doing or maybe one of the improvements that you have benefits one set of users and developers, but it might detriment one set one other set of users and developers that will cause argument which can cause stagnation in the progress.
00:17:00.000 --> 00:17:10.000
Or in the process and it can also cause. You know, like things to never be included, right?
00:17:10.000 --> 00:17:20.000
Like how can we include in the IP and a hard 4 car upgrade? When we don't necessarily have agreement on its benefit to the whole network.
00:17:20.000 --> 00:17:28.000
So hugely, a huge variety of, of, timelines there. Oh, can I, there's another question here.
00:17:28.000 --> 00:17:34.000
Could we please say more about the Python specifications, what qualifies as Python spec.
00:17:34.000 --> 00:17:45.000
Yeah, great question. The Hython specs are is pretty much just what they sound like. It's an implementation of the Ethereum, execution layer protocol.
00:17:45.000 --> 00:17:53.000
Written in Python, you can, I think, Attempts to sync the chain with Pi spec it will never catch up to the head of the chain.
00:17:53.000 --> 00:17:54.000
It's not fast enough, but you can, it's basically a node implementation written in Python.
00:17:54.000 --> 00:18:11.000
And it is exists to Again, help new developers and users of Ethereum understand in pretty readable pseudo code what is happening in both Ethereum clients and in the application space.
00:18:11.000 --> 00:18:25.000
The EVM kind of implementation is also very interesting to look at because there's like, it again, it's more readable pseudocode since it's written in Python, it's more readable pseudo code since it's written in Python.
00:18:25.000 --> 00:18:27.000
Whereas if you were going to go look at a client like Geth, since it's written in Python.
00:18:27.000 --> 00:18:31.000
Whereas if you were going to go look at a client like if you were going to go look at a client like Geth it would be pretty inscrutable to determine what is specification.
00:18:31.000 --> 00:18:41.000
That is dictated by the protocol of etherium versus what is just nice code that's been put in there by the GET team to accomplish something XYZ, right?
00:18:41.000 --> 00:18:48.000
All the different clients are different. But they all act against the spec. Tom linked a blog too, which talks about eels.
00:18:48.000 --> 00:19:01.000
They're new and exciting and people are really happy about the eels. And again, it's just a matter, a measure, a means for us to kind of upgrade the old process, which was to look at the Ethereum yellow paper.
00:19:01.000 --> 00:19:09.000
And reason about it in your head and then apply hundreds of VIPs on top of that initial specification written in like PDF format.
00:19:09.000 --> 00:19:26.000
So that was not sustainable for devs. It was not sustainable for the EIP editors. And now when you write an EIP, for example, you can open a PR against the execution layer spec or against the consensus layer Python spec and say, hey, you know, this is exactly where I'm going to be changing the protocol.
00:19:26.000 --> 00:19:50.000
Here's a code snippet. Here's my motivation. And you know, it just simplifies that process greatly, whereas before you would need to create so much more context when drafting an IP, that now you can essentially defer to the to the specification because you can say, hey, you know, this is the spec we all know and love and this is how and why I'm changing it.
00:19:50.000 --> 00:19:57.000
Great questions. Thanks everyone. So I think the next thing that kind of comes up is like, you know, as we think about our mental model.
00:19:57.000 --> 00:20:06.000
We do want to get a sense of like, well, what types, what's the sort of Taxonomy of EIPs.
00:20:06.000 --> 00:20:17.000
And so we're gonna just talk through some of the types of EIPs. Over the next 2 slides to sort of give you a sense of where they could fall.
00:20:17.000 --> 00:20:30.000
In terms of these. This classification system and. Give some general overview of round. If they fall in a different bucket.
00:20:30.000 --> 00:20:52.000
What is the complexity that goes along with that? So. There are so first off there's the standards track EIP and this is pretty much gonna be ones that are I think the way to think about it is like It's in order to implement a theory, this has to be implemented in some way.
00:20:52.000 --> 00:21:00.000
So that might be at the client level, at the, when we talk about block validation, what we're talking about is a combination of consensus.
00:21:00.000 --> 00:21:27.000
The consensus mechanism. And the sort of sinking mechanism and then also like network. In. So that could be anything from how different validators share information between each other it could be something on the line of like how a certain address or.
00:21:27.000 --> 00:21:32.000
A certain
00:21:32.000 --> 00:21:46.000
Representation of shows up but I'll turn it over to you Matt to sort of break down the the 4 components of the 4 different types of standards track EIPs.
00:21:46.000 --> 00:21:59.000
Yeah, absolutely. So. As Tom mentioned, core is what we primarily deal with when we're talking about these kinds of contexts, especially when you think of core devs.
00:21:59.000 --> 00:22:07.000
It's not quite a coincidence that that happens to look and sound like that. Or EIPs require consensus forks.
00:22:07.000 --> 00:22:13.000
And when I say a consensus work, that basically means an upgrade, right? We need to have all of the nodes on the network.
00:22:13.000 --> 00:22:19.000
Simultaneously agree upon a new set of rules that allow them to interoperate with each other. That can mean sinking the blockchain that can mean validating new blocks.
00:22:19.000 --> 00:22:36.000
That can mean hash function changes like Tom said. It can really mean anything. But anything that requires a change to the way that we essentially validate the chain requires a consensus.
00:22:36.000 --> 00:22:44.000
Or or else we will literally split the network in pieces when nodes do not agree on the version of the world that we have.
00:22:44.000 --> 00:22:51.000
So Cory IPs are, again, these are primarily what actually get shipped, at Ethereum network upgrades.
00:22:51.000 --> 00:23:05.000
They will require updates from all of the execution layer clients and all of the consensus layer clients usually. I say usually because some IPs usually target one layer or another.
00:23:05.000 --> 00:23:07.000
Some target both layers, but they will. Some target both layers, but they will require use or you know validating nodes like users participating in proof of stake to update their software.
00:23:07.000 --> 00:23:28.000
Infrastructure providers to update their software. Pretty much anyone running a node connected to a theorem will need to to update their software because they need again they need consensus and they need to implement those EIPs and they need to be able to talk to the other nodes.
00:23:28.000 --> 00:23:32.000
Some of these other EIP types, they don't require consensus, changes typically, but they're often lumped in with hard forks.
00:23:32.000 --> 00:23:59.000
Depending on where, where and how they look. Networking, for example. Changes to things like Deaf P, which is the peering system that we use in Ethereum do not require hard forks and upgrades and typically can Actually be kind of shipped whenever we often times will have the IPs to bump the versions of things like networking stack.
00:23:59.000 --> 00:24:04.000
So if you think of snapshot protocol, right? We have us, we have one version of the snapshot protocol.
00:24:04.000 --> 00:24:11.000
We could support another and we will when we have something called Verkal Tries next year, we'll have a new SNAP protocol.
00:24:11.000 --> 00:24:16.000
But we'll support both simultaneously. So it doesn't require you to change the way.
00:24:16.000 --> 00:24:19.000
That the network itself runs. It's simply how nodes talk to each other, how nodes give each other data.
00:24:19.000 --> 00:24:27.000
That's why I think networking is a great example for this. But these can be updated slowly or over time.
00:24:27.000 --> 00:24:32.000
And they're also usually backward compatible. So they don't really cause much of a fuss.
00:24:32.000 --> 00:24:45.000
And they don't really require a network upgrade to propose. Interface is similar. This is how we manage, basically APIs in Ethereum.
00:24:45.000 --> 00:24:53.000
Certain things also with the way that solidity works and some other stuff, application layer interfaces.
00:24:53.000 --> 00:25:02.000
These are maintained via EAPs as well. So we have, also specific APIs in Ethereum that the Ethereum Foundation maintains on their GitHub.
00:25:02.000 --> 00:25:12.000
This is like the JSON RPC API. You don't necessarily need EIPs to change that wholesale.
00:25:12.000 --> 00:25:22.000
We've actually moved a little bit away from this process in favor of the living specification on the on But you can.
00:25:22.000 --> 00:25:32.000
These can actually absolutely be APs. And I believe that if you want to create new sets of Api's, depending on what you're doing, you will need to use an interface.
00:25:32.000 --> 00:25:43.000
That's not always true. But again, decentralized governments is messy and we tend to do things that have the most experience and drafting EAPs is oftentimes time consuming.
00:25:43.000 --> 00:25:51.000
So if you're looking to work with application level standards, you're probably actually going to be in the world of ER, ERCs.
00:25:51.000 --> 00:25:57.000
This is where kind of I think the most of the attention in Ethereum, application development goes.
00:25:57.000 --> 00:26:09.000
That was a bad way to afraid that phrase that a lot of the effort around EIPs or changing the protocol in general ends up in the core EIPs bucket or the ERCs bucket.
00:26:09.000 --> 00:26:12.000
I don't want to dive too much into the ERC process now because we actually have slides specifically on that.
00:26:12.000 --> 00:26:25.000
But think about Think about interoperability standards on the application level, right? So I want to make a protocol that supports liquidity pools of various sizes and a decks for example.
00:26:25.000 --> 00:26:34.000
I want to make sure that all the tokens that come into my decks look and act similarly so that I can have interoperability and abstraction without worrying too much about.
00:26:34.000 --> 00:26:43.000
Hard coding things or building complex. Systems in order to be able to serve that, right?
00:26:43.000 --> 00:26:45.000
So, ERCs exist that the community community can standardize certain things that are valuable at the application layer like token standards.
00:26:45.000 --> 00:27:02.000
Specifically specific schemes for how wallets interact with front ends, for example, so that when I develop a new application front end, I don't have to start everything from scratch.
00:27:02.000 --> 00:27:09.000
I can know exactly how a wallet will connect to my page and how it will display information to the user.
00:27:09.000 --> 00:27:17.000
These kinds of things, right? User land, application land type. Standards will go here in the ERC.
00:27:17.000 --> 00:27:20.000
ERC section.
00:27:20.000 --> 00:27:31.000
And so we actually have. Some additional types of ER, EIPs. And we'll just.
00:27:31.000 --> 00:27:40.000
Quickly run through. These these are. So.
00:27:40.000 --> 00:27:52.000
The the meta EIP is gonna be one that. Is thinking about the decision making process itself.
00:27:52.000 --> 00:28:01.000
And with, you know, group like EIP.
00:28:01.000 --> 00:28:13.000
I. This becomes where that coordination layer can.
00:28:13.000 --> 00:28:21.000
Sort of intersect. A second time with the EIP process. So.
00:28:21.000 --> 00:28:32.000
It is. Less changing the literal protocol itself. But it is more changing the protocol around changing the protocol.
00:28:32.000 --> 00:28:36.000
And.
00:28:36.000 --> 00:28:44.000
I don't know if there's Matt, you have an illustrative example that you can think of of like a META EIP that comes top of mind.
00:28:44.000 --> 00:28:45.000
There you go.
00:28:45.000 --> 00:28:51.000
Yeah, EAP number one. How do you write? The, I'm at a, describes the process surrounding Ethereum.
00:28:51.000 --> 00:28:57.000
I would argue that creating a Ethereum governments is definitely surrounding the protocol, but is not a direct change to the protocol.
00:28:57.000 --> 00:29:11.000
There are very few met at EAPs. I would not say that they are widely used. But then again, people typically don't want to put their soapboxes in writing that is very detailed in a specific format they typically want to just shout stuff.
00:29:11.000 --> 00:29:21.000
So, META EAPs tend to happen in real live discussions and then get adopted via haphazard rough consensus, he means.
00:29:21.000 --> 00:29:31.000
However, I think EIP one is an awesome example and it's continuously updated actually to be a maintenance of kind of what it looks like to build the IPs.
00:29:31.000 --> 00:29:35.000
Yeah. There are there are very few of these. However, we're thinking about using metadata IPs to coordinate network upgrades going forward.
00:29:35.000 --> 00:29:54.000
So making an EIP that specifies what EIPs will be included. Yes, I know it's a little bit much, but then again, We are existing process is very much rough and kind of.
00:29:54.000 --> 00:29:59.000
Do it as you go. So I think this is this will be a nice. And, yeah, go ahead, Tom.
00:29:59.000 --> 00:30:07.000
And then to go back, yeah, like, can you just, you know, you'd made a statement about how ERCs.
00:30:07.000 --> 00:30:23.000
Like for example, something related to best practices. Might be an ERC that like reduces and will define what you're, we'll define what the URC acronym means in a minute.
00:30:23.000 --> 00:30:35.000
How does that differ from an informational EIP? Just to sort of drill down on like the difference between to really say like what is the difference between an ERC and an informational EIP?
00:30:35.000 --> 00:30:44.000
Yeah, and an informational MP in my mind is like, I have noticed this thing. About Ethereum.
00:30:44.000 --> 00:30:51.000
I'm going to do a little bit of research on it and I'm going to share my findings, but I'm going to do it in a formalized manner.
00:30:51.000 --> 00:30:59.000
The reason being is that you're basically free to ignore informational MPs. They don't actually do anything to the protocol.
00:30:59.000 --> 00:31:04.000
But a lot of time, like, like I said before, in the first slide, EIPs are the unit of governance in Ethereum.
00:31:04.000 --> 00:31:23.000
If you've noticed Something that requires careful eye or if you want to disseminate information about a topic that you're passionate about and informational AIP can do just that and it can allow us to coordinate around this because an informational MP can potentially spawn, a meta-IP or a Cory IP.
00:31:23.000 --> 00:31:40.000
Maybe you don't have the wherewithal to write a bunch of specification changes, but you do have the wherewithal to talk about an experience that you had that shapes the way you develop on the Ethereum protocol and then you provide a bunch of research that backs up your thought process and you make a recommendation, right?
00:31:40.000 --> 00:31:47.000
That's not really a Cory IP, but it can be done as an informationally IP and others can debate that topic.
00:31:47.000 --> 00:31:51.000
And use it as a means of coordinating further action later on.
00:31:51.000 --> 00:32:02.000
Gotcha. Okay, so how How do we how do we actually like Right this, what's the process for that?
00:32:02.000 --> 00:32:09.000
Yeah, so I wrote all these. Except for that quote on the left hand side, what I really like is that your role.
00:32:09.000 --> 00:32:16.000
Is to be the champion of your MP. You have to write it using the specific format that they outlined for you in the IP repo.
00:32:16.000 --> 00:32:24.000
You have to shepherd all of the discussions in the appropriate forums. So like I said, you have to go to a theory of magicians, maybe even research.
00:32:24.000 --> 00:32:29.000
You have to go to the court devs calls. You have to go to various discords. You have to talk to client teams.
00:32:29.000 --> 00:32:44.000
It's your job to do a lot of the leg work. However, if you build a really awesome community around this, you don't necessarily need to do it all of yourself if you're convincing enough you can make an army of followers to help you do all this stuff.
00:32:44.000 --> 00:32:51.000
But again, the author of the IP is dedicated to doing a lot of the legwork and building community consensus around the idea.
00:32:51.000 --> 00:32:58.000
So my suggestions and kind of how I view this authoring process. Is to start with an open mind, right?
00:32:58.000 --> 00:33:12.000
I think that a lot of people shy away from Ethereum improvement proposals because it seems like a lot of work and it seems like it would be impossible and if you're not a deep, deep, basically a client expert, you can't make these proposals.
00:33:12.000 --> 00:33:20.000
I think that's entirely wrong, especially when you consider ERCs. So don't accept necessarily the constraints of Ethereum as a protocol.
00:33:20.000 --> 00:33:28.000
Think of solutions and think of different things and make it informationally IP if you're not feeling so bold, right?
00:33:28.000 --> 00:33:35.000
But yeah, before you get started on that, if you have an idea, you had an open mind, you thought about a solution.
00:33:35.000 --> 00:33:48.000
Start vetting it, right? As you mentioned this before, you need to you need to make sure that no one's done this before that you did you're not necessarily it's not that you're stealing an idea but it's there's probably a reason why if something was debated before it was either implemented or ignored already.
00:33:48.000 --> 00:33:56.000
So make sure that you're reaching out to the community at large. The there is a huge amount of knowledge in the Ethereum Editions Forum and people are extremely active.
00:33:56.000 --> 00:33:57.000
So if you have an idea, bring it there. It doesn't even need to be any IP.
00:33:57.000 --> 00:34:11.000
You can just say, hey, I thought about this really interesting idea for a new opcode. You can just say, hey, I thought about this really interesting idea for a new opcode that'll allow us to store memory for a new opcode that'll allow us to store memory more cheaply between EVM execution calls.
00:34:11.000 --> 00:34:17.000
That's awesome. We love that idea. Just go post about it. You don't need to, you don't need to have specs written.
00:34:17.000 --> 00:34:24.000
You don't need to have anything. You just need to have an idea. You need to vet that idea with the community and then you need to start drafting your EMP in accordance with the format.
00:34:24.000 --> 00:34:36.000
Scribe AAP one. Presuming that there is no, show stoppers and what you've written or any, you know, the discussion that happens on Ethereum magicians is fruitful and you don't feel discouraged or if you don't feel like.
00:34:36.000 --> 00:34:42.000
Or you do feel like you have a good idea, etc. Keep going, build the EAP, draft it, share it with the repo.
00:34:42.000 --> 00:34:48.000
Get on those EIP IP meetings, talk to Pooja, get on the peep and Ep series.
00:34:48.000 --> 00:34:55.000
You want to be shopping your EIP around town like it's your job because in many cases it might be depending on what you're looking to do.
00:34:55.000 --> 00:35:02.000
Champion the AP, you have to understand the community sentiment and build consensus. Contentious items are unlikely to be adopted.
00:35:02.000 --> 00:35:09.000
If you have an EIP that will adversely impact 50% of atherium and positively impact 50% of Ethereum.
00:35:09.000 --> 00:35:17.000
You need to change those scales because your EIP is not going to get adopted. It's going to be debated to death literally and then it will sit in the stag and pile.
00:35:17.000 --> 00:35:24.000
Until something else comes along. So your, your job is to build, can you understand the community sentiment?
00:35:24.000 --> 00:35:30.000
Tweak your tweak your EIP to work within that community sentiment. You know hear the feedback of the people that are going to be impacted by this.
00:35:30.000 --> 00:35:47.000
And try to see if you can incorporate it and come up with a better solution. And then you really have to go, you know, once you have the community sentiment behind you, which is ideally perfect to do before you go to the Core Ds, but if you can't do that.
00:35:47.000 --> 00:35:52.000
Come to the Cordevs, convince the client teams of the value of your implementation for their clients.
00:35:52.000 --> 00:36:04.000
Right? If some, you are essentially asking. 10 teams to build some to set aside what they're doing to build something that you recommend in order to help the network.
00:36:04.000 --> 00:36:11.000
So you need to really convince them that spending literal time and money on something like this is valuable. And you want to provide reference implementations if you're feeling so bold and if you have the ability.
00:36:11.000 --> 00:36:21.000
Reference implementations if you're feeling so bold and if you have the ability. So a lot of people do this in GEH is fine, whatever.
00:36:21.000 --> 00:36:25.000
But we're seeing reference implementations for, you know, certain IPs being built in all of the.
00:36:25.000 --> 00:36:39.000
Clients simultaneously if you really want an EIP, I can tell you as someone who works on a client team, one of the most free ways to get me to promote your IP is building a implementation in Basu and telling me about it.
00:36:39.000 --> 00:36:50.000
So if you have a branch that has your code ready to go and tested, then I am gonna you know push for that because I think that's really awesome way to build community cool.
00:36:50.000 --> 00:37:05.000
This part isn't actually the last bullet point isn't actually as Key, but You in theory should be trying to shepherd it through delivery on the network upgrades into the final stages.
00:37:05.000 --> 00:37:14.000
That's not really on you after a certain point unless you are on a client team if you are not on a client team, you kind of once your EIP is included in a network upgrade.
00:37:14.000 --> 00:37:20.000
You can kind of wash your hands of it. Which is slam, but you know, you can come back and check on it and make sure.
00:37:20.000 --> 00:37:42.000
Be available to discuss it and the specifications and be available to do it. Or to update it in accordance with findings in testing but in reality you're you kind of just need to make your job is to get it included in a hard fork and then it's up to the client teams to find the right implementations and the right details and then working with them to get it into production basically.
00:37:42.000 --> 00:37:57.000
So we're gonna jump into a case study. And we are. I'm gonna quickly answer a question that came up like who decides the EIP number and you do as long as it's not an already chosen number.
00:37:57.000 --> 00:38:13.000
My understanding, at least this is how it has been for a while. This might have changed. I haven't seen any meta EIP on this is that the author gets to choose the number so long as it is not already chosen.
00:38:13.000 --> 00:38:32.000
And so it is kind of a first come first serve thing and I don't know the exact reason behind why 1559 was chosen for this one, but it is an exceedingly well.
00:38:32.000 --> 00:38:39.000
Let's just look at this quote here. This is humor, right? EIP, 1559 if ever implemented.
00:38:39.000 --> 00:38:45.000
Is arguably the most complex change since Genesis.
00:38:45.000 --> 00:38:55.000
Let's, what's the quick TLDR and what 1559 does, Matt.
00:38:55.000 --> 00:39:00.000
That I lose Matt?
00:39:00.000 --> 00:39:01.000
Okay. I might have lost that. Oh no, okay. Yeah.
00:39:01.000 --> 00:39:13.000
Sorry, I know I'm having another Not my connect. So a quick TLDR on 1559 is a change to the way that the fee market works in Ethereum.
00:39:13.000 --> 00:39:19.000
So, Ethereum has a fee market for block space. Currently I want a transaction included on chain, I have to pay for that privilege.
00:39:19.000 --> 00:39:37.000
And minors will include my transaction. In the next block. Or the block after that whatever it sits in the menpool yadda yadda there's kind of Excuse me.
00:39:37.000 --> 00:39:46.000
There is. This was a very different change to the way that Ethereum works, which is essentially a first come, highest offer auction.
00:39:46.000 --> 00:40:02.000
That did not scale well with capacity so what that is to say is that when In times of very high network congestion, gas prices would essentially just unboundedly increase, and not really have.
00:40:02.000 --> 00:40:09.000
Much rhyme or reason to what's happening. So, 1559 introduced new mechanisms, whereas whereas we.
00:40:09.000 --> 00:40:19.000
Dynamically raise and lower the gas fees on Ethereum in order to both encourage and discourage use of the network in times of congestion and in times of Nothing.
00:40:19.000 --> 00:40:26.000
So when the network is really, really. Open and there's tons of block space available.
00:40:26.000 --> 00:40:28.000
The fees will go way down. We've come very cheap and incentivized using Ethereum.
00:40:28.000 --> 00:40:47.000
When gas becomes very expensive because block space is very expensive because maybe there's some crazy NFT drop and someone is trying to reach out and find you know people are basically bidding up the gas options in order to get there make sure that our transactions are included in the next block.
00:40:47.000 --> 00:40:57.000
The base fee will increase in order to discourage that kind of behavior. Fine. There's also a tip mechanism, whereas you can.
00:40:57.000 --> 00:41:04.000
Basically tip on top of that base fee to really be sure that your transaction will be included. Cool.
00:41:04.000 --> 00:41:15.000
The EIP was contentious with a lot of different folks. Because 1559 changed the way that minors got paid.
00:41:15.000 --> 00:41:25.000
Instead of previously basically allowing for unbounded price increases, which would go to the miners in many instances as the as the gas options would increase.
00:41:25.000 --> 00:41:49.000
That means that minors kind of Can get more money in certain instances and 1559 would kind of change the way that they had their gas fees and it means that the block production would be differently like the rewards from block production would fluctuate in a way that would be less predictable and in some instances less profitable to these folks.
00:41:49.000 --> 00:42:10.000
So you have folks who, again, you had discussions starting as early as April, 2019 about this EAP and then you have people calling it humorous in 2021 you have websites cropping up called stop the IP 1559 with statements from mining pools on why they were not going to be supporting the IP, 1559, with statements from mining pools on why they were not going to be supporting the IP 15
00:42:10.000 --> 00:42:23.000
59 that website no longer exists but the funny part is that If you look in the Internet Archive link that I've provided in the slides, if you keep sliding the time over basically so like you start at the earliest point in time then you go farther over more of the mining pools moved from the opposition column to the supporting column.
00:42:23.000 --> 00:42:42.000
The reason being is because there was a huge push around the need for 1559 in etherium because network congestion was a problem but at the same time because of the supply The basically inflation problem of Ethereum.
00:42:42.000 --> 00:42:49.000
1559 also introduced something called the burn mechanism. So if you've heard of ultrasound money and you know all these other kind of memes around burning etherium this is why this happens and it's another kind of memes around burning etherium. This is why this happens.
00:42:49.000 --> 00:43:09.000
And it's another reason why over time that the kind of VIP was tweaked to be focusing less on the fee dynamics and more on the emission problem of Ethereum, which I think was a change in community sentiment that was.
00:43:09.000 --> 00:43:19.000
Notice by the authors and was basically taken advantage of to swing. Sentiment from the mining pools, which you know as regular users of Ethereum.
00:43:19.000 --> 00:43:20.000
We gotta be honest that we don't necessarily care what happens to the mining pools. Unless we participate in them.
00:43:20.000 --> 00:43:33.000
So, but users really do care about emissions and inflation. So if you're able to say, hey, you know, we're gonna remove some of the power of these miners.
00:43:33.000 --> 00:43:40.000
We're going to give users more flexibility and choice on how they're transactions are included and we're going to solve the theorems inflation problem.
00:43:40.000 --> 00:43:50.000
That is kind of a winning sales pitch that was able to move the needle on. This 4 year long EIP.
00:43:50.000 --> 00:43:55.000
To finally push it across the goal line in August of 2023. That date actually might be wrong.
00:43:55.000 --> 00:44:02.000
That's supposed to be August of 2022.
00:44:02.000 --> 00:44:03.000
And that's yeah, not a fact.
00:44:03.000 --> 00:44:16.000
Will change that in the, upload the slides. It was right before the merge, essentially.
00:44:16.000 --> 00:44:17.000
Let's go on.
00:44:17.000 --> 00:44:25.000
That, yeah. And then it went perfectly with the the merge so Let's so we're gonna get through the last few slides with our remaining time and then we'll just jump into questions.
00:44:25.000 --> 00:44:33.000
That kind of gives you a sense of just like how long the process could be, but there is this thing called Ethereum request for comment.
00:44:33.000 --> 00:44:48.000
Which is a type of standard track EIP and tends to actually be quite a bit. I don't wanna say necessarily faster, but it's they're generally a bit.
00:44:48.000 --> 00:44:54.000
Their complexity. 10 to be less. Is that a fair statement, Matt?
00:44:54.000 --> 00:44:55.000
Hmm
00:44:55.000 --> 00:45:02.000
They're complexity of implementation tends to be less. Their complexity might still be high, but in terms of implementing them.
00:45:02.000 --> 00:45:10.000
They tend to be implemented. At a faster clip, one might say.
00:45:10.000 --> 00:45:11.000
It always does.
00:45:11.000 --> 00:45:27.000
It depends, right? Because Yeah. I think that you're correct because they don't need they don't need a network upgrade to start adoption so I could put out an ERC today and I could have folks start implementing it immediately because I don't need to build on top of Ethereum protocol changes specifically.
00:45:27.000 --> 00:45:35.000
I think that's why ERCs can move a lot faster because you can put out a token standard that's like just awesome.
00:45:35.000 --> 00:45:40.000
And people can be like, yeah, this is a super awesome token standard. I'm gonna build on this right away.
00:45:40.000 --> 00:45:53.000
It will probably go through some phases of iteration. But at the same time, like their ERCs are a lot more of a collaborative community driven process because they're based around the application level community which is very different than the Kind of not very different, but is different than the core developer community.
00:45:53.000 --> 00:46:01.000
And that, you know, one shepherd's the protocol, the other builds on the protocol.
00:46:01.000 --> 00:46:12.000
Yeah, so it they're a little bit more flexible. If you look at the chart, there The line from idea to final is basically the same.
00:46:12.000 --> 00:46:19.000
And they're not really considered final as a network upgrade goes through, but for example, with ERC.
00:46:19.000 --> 00:46:24.000
20 tokens, it's considered final because folks are building and deploying them and their interrupt.
00:46:24.000 --> 00:46:39.000
It's an interoperability standard that's used in protocols. So the definition is a little dubious there, but I think that the ERC process is a lot more flexible because you don't need network upgrades to determine when and how things are shipped.
00:46:39.000 --> 00:46:50.000
So you can start iterating a lot more rapidly and you can build consensus a lot more rapidly with the community on these standards.
00:46:50.000 --> 00:46:56.000
And just to do a quick ERC case study that's super relevant. It would be account abstraction for 3 3 7.
00:46:56.000 --> 00:47:09.000
There actually are Quite a few other approaches out there if you click on the link. Here it will detail at least 3 other approaches including.
00:47:09.000 --> 00:47:10.000
A
00:47:10.000 --> 00:47:18.000
See 4 3 3 7 so can you just quickly walk us through. What, what's going on?
00:47:18.000 --> 00:47:22.000
Like what's going on with, with, with ERC 4 3 3 7.
00:47:22.000 --> 00:47:27.000
Yeah, absolutely. I'll be quick too. I'll try to do this in a few minutes so that we can leave plenty of time for questions.
00:47:27.000 --> 00:47:37.000
But yeah, the, as you might have heard, this is the account abstraction ERC that is collected the most steam it's based around kind of the notion of user operations versus traditional transactions.
00:47:37.000 --> 00:47:47.000
I'm not going to be breaking this down. It would take more than the 5 min that I want to give myself.
00:47:47.000 --> 00:47:55.000
But I encourage you to go read up on your receipt 4 through 7 and how it could bring Ethereum to the next 1 billion users.
00:47:55.000 --> 00:48:04.000
Cool. It's great. But in my opinion, this case study is very interesting is because we have,
00:48:04.000 --> 00:48:11.000
Like this was a huge kind of community action. And it shows how you can gain steam for an ERC.
00:48:11.000 --> 00:48:20.000
Because they have a little bit of personality, a lot of momentum, a lot of resources behind them and they solve the real problem.
00:48:20.000 --> 00:48:31.000
So the the reason I think 4 3 3 7 is interesting is because we have on the right hand side a screenshot from a 1,700 member telegram channel where folks are constantly sharing information.
00:48:31.000 --> 00:48:38.000
They're constantly sharing resources. They're sharing new products that they've built on top of 4 3 3 7.
00:48:38.000 --> 00:48:45.000
They're sharing open source code. They're fixing bugs, they're talking in person, and they're all building on the same application standard.
00:48:45.000 --> 00:48:52.000
So that took a while. It this this is it's you know, 1,700 members now, but it started off A lot, lot smaller.
00:48:52.000 --> 00:49:03.000
Even just last year, I remember there was only handful of folks in there. Great. This community consent coordination kind of community consensus layer.
00:49:03.000 --> 00:49:11.000
They also provide a GitHub with a ton of templated code that you can go steal, which is perfect for building on if you want somebody to build on your application, give them the tools to do so cheaply, easily and quickly.
00:49:11.000 --> 00:49:19.000
So that's exactly what they did. They got together. They built this really large telegram group.
00:49:19.000 --> 00:49:23.000
They started sharing code. They collected a bunch of. Resources and products and open source code that you can be used in your own products.
00:49:23.000 --> 00:49:35.000
They hosted, if you see, look at the picture on the bottom left hand side, they hosted meetups specifically in person for this kind of abstraction.
00:49:35.000 --> 00:49:58.000
Viewpoint so they're building you know in person networking around this they're trying to get a lot of different companies and groups on board so it's it's really more of a coordination on the kind of community consensus layer, often sometimes called layer 0 if you've heard that expression before around a cat abstraction and I think this is a good case study because it's it essentially has one the account
00:49:58.000 --> 00:50:09.000
abstraction. I don't wanna call it a war, but that, you know, there was a couple competing standards and this one is essentially come out on top and I think it's in part due to this kind of community coordination.
00:50:09.000 --> 00:50:20.000
And I think over time we will see it. Be tweets but it's it's mainly kind of one out here and yeah there's a link and also to a bunch to the graveyard of account abstraction.
00:50:20.000 --> 00:50:29.000
Eips and ERC is that attempted to solve the same problem. And I encourage you to go look and see why that is that they didn't make it through.
00:50:29.000 --> 00:50:33.000
But yeah, I think it's more in this in this perspective, it's if you build it, they will come kind of, ERC.
00:50:33.000 --> 00:50:50.000
And I think that the you know the folks that had come up with the initial implementation so you'll have and some other folks that are just like, ERC authors, they did a lot of the initial leg work they built.
00:50:50.000 --> 00:50:58.000
Code for other folks. They built client implementations, which is really cool. So some of the stuff required client changes.
00:50:58.000 --> 00:51:06.000
Anyway, they did all the hard work and it paid off beautifully for them and it will hopefully pay off very very soon for end users.
00:51:06.000 --> 00:51:13.000
Using anyone using an Ethereum wallet essentially will have their experience upgraded in the next year or so.
00:51:13.000 --> 00:51:24.000
Nice. There is one final IP at this time and that's roll up improvement proposals I think well it started maybe before that there was sort of a proposals.
00:51:24.000 --> 00:51:28.000
I think, well, it started maybe before that there was sort of a launch event at Devconnect, 2023.
00:51:28.000 --> 00:51:43.000
So in November, but we have no illustrative examples to share. So stay tuned. So, in November, but we have no illustrative examples to share.
00:51:43.000 --> 00:51:49.000
And just to cover office hours is on Friday. We'll talk about sort of the repos to follow and we'll talk a little bit about ERC.
00:51:49.000 --> 00:52:11.000
20 since that was like very foundational. One to sort of the token tokens that exist on a theorem today and in some ways establishing Ethereum as a
00:52:11.000 --> 00:52:16.000
Layer for settlement and cross chain settlement in particular. I think that's sort of something that we can talk about.
00:52:16.000 --> 00:52:24.000
And you can definitely submit your questions in advance to the link that, the core team has shared.
00:52:24.000 --> 00:52:37.000
But we'll just open it up with the remaining time. We have 5 min for any Q&A.
00:52:37.000 --> 00:52:42.000
Have you all been part of any EIPs?
00:52:42.000 --> 00:52:46.000
I've provided comment on a few. I am a recent addition to this world.
00:52:46.000 --> 00:52:57.000
Last year or 2, you're in change, but I've mostly provided feedback based on the perspective of my execution client team, base use team.
00:52:57.000 --> 00:53:04.000
So we you know, often times the client teams are asked to opine on existing APs and to provide feedback.
00:53:04.000 --> 00:53:11.000
So that's a lot of what I do. I'd love to start writing any IP, but I don't have any phenomenal ideas yet, so I'm waiting.
00:53:11.000 --> 00:53:15.000
If you have a great idea, come talk to me.
00:53:15.000 --> 00:53:27.000
This is lost to time, but I think a colleague of mine authored an EIP in the late 2,019, 2,020 era and
00:53:27.000 --> 00:53:39.000
I think at some point during COVID lockdown I put some comments through but honestly that part of my mind has evaporated and I would have to check it.
00:53:39.000 --> 00:53:46.000
But I do remember this EIP. And I remember who authored it and I can't remember the number.
00:53:46.000 --> 00:53:52.000
So, I think maybe but it has, it has been a little bit of time.
00:53:52.000 --> 00:54:09.000
I've been more on the receiving end. Working alongside those who to take the implementation of the EIP at the client level and understand how that's going to impact.
00:54:09.000 --> 00:54:23.000
Operations of of of a product and so probably the most involved. That I've been in understanding that and really breaking down the impact of EIPs.
00:54:23.000 --> 00:54:35.000
Was during the merge so there is almost a predecessor series to this that Matt was also a big part of where we did a webinar, an 8 part webinar series.
00:54:35.000 --> 00:54:43.000
Plus it was like 2 different webinar series that converged and went back out about the merge and how it's gonna impact different.
00:54:43.000 --> 00:54:58.000
Us like steakers. You know, DAP developers and we went into sort of the EIP changes and what that looked like.
00:54:58.000 --> 00:55:13.000
Any other questions folks we got 2 more minutes. I'm also happy to stay a little bit longer if we do have more questions.
00:55:13.000 --> 00:55:30.000
Any that are coming in through the form. We are. Charging for us to multitask.
00:55:30.000 --> 00:55:32.000
Awesome. I think we've.
00:55:32.000 --> 00:55:39.000
Yeah, I think we've dumped a lot of information on you, so maybe let that settle in.
00:55:39.000 --> 00:55:49.000
Make yourself a hot tea or coffee and let your subconscious sort through all of this. We'll be back together on Friday at the same time.
00:55:49.000 --> 00:56:06.000
To talk about. To do an office hours with like just a short little bit on ear c 20 and then really to answer more questions we're still arranging the guest speaker so as soon as we have that finalized, we will send that out and add it to the course schedule.
00:56:06.000 --> 00:56:10.000
But thanks everyone for attending today. We really appreciate it. And we'll see you on Friday.
00:56:10.000 --> 00:56:13.000
Or see you on a recording.
00:56:13.000 --> 00:56:20.000
Thanks
Office Hours
â–¼Office Hours Transcript
The following transcript was auto-generated, and may content syntactical errors.
00:00:02.000 --> 00:00:13.000
Hey everyone, welcome today is Friday December eighth. For some of you at NDP Saturday. I hope everyone's having a great end to their week.
00:00:13.000 --> 00:00:23.000
We're in week 2 office hours. So similar to week one office hours, what we'll do is we'll have about 15 to 20 min of.
00:00:23.000 --> 00:00:33.000
New material that we would kind of consider extension material material that you can review. And then just sort of bring up new.
00:00:33.000 --> 00:00:46.000
New topics and then, we have some discussion questions and we can just have a conversation. So, Yeah, that is gonna be the the schedule for today.
00:00:46.000 --> 00:00:57.000
Let's jump into it. So let's just take a step back and cover some of the things, the big topics that we covered in week.
00:00:57.000 --> 00:01:10.000
2. The first is that an EIP is They are the unit of governance. That we when we think about governance in Ethereum, the EIP.
00:01:10.000 --> 00:01:19.000
Is the unit of government governance. So we used a lot of terminology in this ecosystem about like blockchain.
00:01:19.000 --> 00:01:28.000
Primitives or web 3 primitives. And if you want to sort of take that analogy, you can almost say that the EIP is the governance primitive for Ethereum.
00:01:28.000 --> 00:01:33.000
You've seen a lot of other.
00:01:33.000 --> 00:01:51.000
Protocols actually adopt. A similar processes and to kind of take it back like you know there are improvement proposed there we're always improvement proposals for, The predecessor of a theory.
00:01:51.000 --> 00:02:00.000
And a chain that continues to have great value. The Bitcoin blockchain has, has BIPs.
00:02:00.000 --> 00:02:05.000
And so we have EIPs and as other protocols launch, you actually do see, them sort of modeling a similar.
00:02:05.000 --> 00:02:14.000
Improvement protocol. I was trying to chase down like what's the history of this like Sorry, improvement.
00:02:14.000 --> 00:02:23.000
Improvement proposal, not protocol. You know, just like What is the history of this in general?
00:02:23.000 --> 00:02:39.000
So far, my research, I'm hoping to peel back the onion a little bit more, is that this is something that has existed in some shape or form within open source communities for quite some time.
00:02:39.000 --> 00:02:49.000
But I'm gonna try and track down, you know, what is like sort of the the origin of the blank IP, where does it come from and how does that come about being?
00:02:49.000 --> 00:02:58.000
So if anyone does happen to know that, I think that would be a really interesting thing to talk about because it is related to the history of computing in general.
00:02:58.000 --> 00:03:09.000
Okay, so we talked about EIPs, the unit around which governance happens and Ethereum improvement proposals go through a process where it starts with an idea.
00:03:09.000 --> 00:03:20.000
And then it's gonna flow either to finalization. Stagation are being withdrawn and might hang out at different steps along the way.
00:03:20.000 --> 00:03:30.000
And we talked about how this process can be. Relatively fast, but it could also take quite a bit of time.
00:03:30.000 --> 00:03:38.000
And as Ethereum has become more complex and has had more dependencies, you can see where all of the
00:03:38.000 --> 00:03:58.000
Aspects of a change have to be considered become just like so much more complex in naturally lends itself to being quite a bit longer than the initial sort of Launch of Ethereum where it might have been quicker to make a change because there were less users of the network.
00:03:58.000 --> 00:04:10.000
There were less dependencies of L twos, L three's. I imagine that this will only get more complex as more value is.
00:04:10.000 --> 00:04:17.000
Stored on Ethereum or on L 2 chains. And I imagine that also the process will continue to evolve.
00:04:17.000 --> 00:04:35.000
To deal with this complexity. So it isn't easy to predict where. This will go, but I think what's interesting is that You can see how this process, even as it needs to undergo changes.
00:04:35.000 --> 00:04:44.000
Has the ability as it is today to shape itself to the growing complexity of. The Ethereum protocol.
00:04:44.000 --> 00:04:53.000
That's a pretty unique thing to be able to design. Such a process that given those changes.
00:04:53.000 --> 00:05:02.000
There is this sort of ability to. Naturally morph and become, sort of meet the moment, I would say.
00:05:02.000 --> 00:05:13.000
So I had promised that. We are going to do another ERC case study and I actually wanted to do one that is.
00:05:13.000 --> 00:05:17.000
In some ways, quite.
00:05:17.000 --> 00:05:29.000
Simple but also very profound. And when I say it's simple, what I mean is that the ERC, 20 token standard.
00:05:29.000 --> 00:05:40.000
Is very straightforward, right? It's implementing a standard application programming interface. For tokens within smart contracts.
00:05:40.000 --> 00:05:50.000
It's to provide basic functionalities to transfer tokens. As well as tokens to be approved so they can be spent by another on chain third party, right?
00:05:50.000 --> 00:05:56.000
So that was that's the actual description. If you go to EIP, 20, which is.
00:05:56.000 --> 00:06:03.000
We call ERC. 20 like that is the description. From the EIP.
00:06:03.000 --> 00:06:19.000
Dot com. And how this went into being was, you know, as we talked about, these ERCs being sort of a subset of core AIPs, not always requiring change to the protocols.
00:06:19.000 --> 00:06:30.000
They're probably the easiest way to think about this is the core implementation. So the open Zeppelin, like a core implementation that opens up on implementation.
00:06:30.000 --> 00:06:46.000
Consensus actually used to have an implementation as well that repository has been deprecated. So I've been linked it here, but if you are interested from just a historical perspective, seeing when we, I think we put that together in late 2015, early 2016.
00:06:46.000 --> 00:06:59.000
But as you know, this was proposed, I think. Do November nineteenth? 2015. The token transfer actually like Really?
00:06:59.000 --> 00:07:06.000
And so here we're opening up. Here is ERC. 20 dot soul. Solidity file.
00:07:06.000 --> 00:07:10.000
These are the opens up on contracts. I'm going to the GitHub repo.
00:07:10.000 --> 00:07:17.000
There's actually a much. More, I think, you know, because this course is kind of geared towards.
00:07:17.000 --> 00:07:25.000
There's a lot of folks who have maybe already taken the developer boot camp. You're actually probably quite familiar with this token center.
00:07:25.000 --> 00:07:33.000
You may even used it in your. In your project, but we're looking at it from a different way.
00:07:33.000 --> 00:07:38.000
I think at the time we're just looking about, oh, okay, cool. We could implement.
00:07:38.000 --> 00:07:52.000
That certain functions. That allow us to transfer tokens from one address to another address, right? And That.
00:07:52.000 --> 00:08:10.000
Was not something. That was. Originally, there while there was the transfer. Of that was immediately put in there as an opcode, there wasn't a token transfer operational code within Ethereum.
00:08:10.000 --> 00:08:18.000
So in order to enable that, within a smart contract that actually had to be written.
00:08:18.000 --> 00:08:28.000
Logic that transfers a token. From one address to another address. And then this also approved function that says.
00:08:28.000 --> 00:08:38.000
We can use the opcode that underpins message dot sender. To actually give another person.
00:08:38.000 --> 00:08:49.000
Another address, another person necessarily, the ability to transfer a token. And this has become. Literally foundational.
00:08:49.000 --> 00:09:02.000
To many of the applications. That we have built upon. Ethereum. So I just provide 2 examples is non-inclusive, but I think they're ones that.
00:09:02.000 --> 00:09:10.000
People probably know a lot about. Circles stable coin USDC. Makers die, these are stable coins.
00:09:10.000 --> 00:09:18.000
These tokens are minted. Based off of a supply of reserves that are held that like back these coins.
00:09:18.000 --> 00:09:28.000
I think D is now become like an algorithmic stable coin. Don't quote me on that.
00:09:28.000 --> 00:09:41.000
USDC is still like a reserved back stable coin and these are being created. And they are literally the ERC, 20 token standard.
00:09:41.000 --> 00:09:50.000
That they're using that to actually build these. To create and transfer. These, these tokens.
00:09:50.000 --> 00:09:59.000
This is very interesting code to read because there's a facility 0 point 4 back when we had to use the safe math.
00:09:59.000 --> 00:10:03.000
Library, which nowadays
00:10:03.000 --> 00:10:18.000
I think it was with Solidity, 0 point 8 that that. That the sort of issues that safe math solved were baked into solidity itself, but you can see that there's our ability to mint tokens.
00:10:18.000 --> 00:10:27.000
And this is all written in here and burn token. So this is like the first time. That this sort of functionality.
00:10:27.000 --> 00:10:38.000
Was built in order to allow for many of the things that we take for granted. For example, swap based applications like Uniswap, which is an AMM for ERC.
00:10:38.000 --> 00:10:44.000
Generally, but you can think about it more broadly, other tokens that. Up that adhere to.
00:10:44.000 --> 00:11:06.000
Some sort of variation of the ERC token standard. I picked this case study to talk about because it really gives you a sense of just how foundational the EIP and by extension the ERC processes into building the Ethereum that we have today, right?
00:11:06.000 --> 00:11:20.000
So. I know when we walk through our case studies. On Wednesday, it may have seemed. A little bit.
00:11:20.000 --> 00:11:25.000
Not pie in the sky, but it may have seen like, oh, this is, you know, I get it and 1559.
00:11:25.000 --> 00:11:30.000
I understand there's a lot of talk about that, but I think the ERC, 20 case study.
00:11:30.000 --> 00:11:37.000
Gives you a sense that like The Ethereum that you want to see exist is is governed by the EIP process.
00:11:37.000 --> 00:11:51.000
And so if there's certain functionality in Ethereum, that you want to create. You have to participate in this process in order to have these.
00:11:51.000 --> 00:12:05.000
Standards be baked into the protocol. So I think that sort of brings us to 3. Discussion questions, but we can open it up to more questions, comments, and thoughts.
00:12:05.000 --> 00:12:12.000
The 3 that I kinda had and I put these in our discord were given the high amount of shepherding required to get an EIP from draft to final.
00:12:12.000 --> 00:12:19.000
What are some organizations that we mentioned in week one that can help in EIP, author, craft their idea and build community around that idea.
00:12:19.000 --> 00:12:29.000
Second one is what are some issues you see that could cause an EIP to fall into stagnant status based on the EIPs that we shared with you, how do you think these EIPs avoided that fate?
00:12:29.000 --> 00:12:31.000
And 3, what would you do to make the IP process run faster? What tradeoffs would need to be made if you made these changes?
00:12:31.000 --> 00:12:38.000
So I'll leave this up and now what I'd love to do, you know, we've talked for nearing definitely for 15 min.
00:12:38.000 --> 00:12:44.000
So, would love to open up to any questions that people have on the materials. So would love to open up to any questions that people have on the materials from the first week and we can jump in there.
00:12:44.000 --> 00:13:03.000
I believe there was also a I think There some also some.
00:13:03.000 --> 00:13:08.000
There is not a shared.
00:13:08.000 --> 00:13:34.000
Form so just feel free to go ahead come off mute if you have a question that you want to ask.
00:13:34.000 --> 00:13:47.000
Okay, well those questions ruminate in focus is head. I'll kind of jump into I think we all have a sense of question one.
00:13:47.000 --> 00:13:55.000
You know, obviously we brought in Ethereum cat herders. So I kind of want to jump into question 2.
00:13:55.000 --> 00:14:03.000
How ways that I've seen, the IPs fall into a stagnant status. Is that?
00:14:03.000 --> 00:14:15.000
The EIP no longer addresses. Problem that the community thinks needs to be solved.
00:14:15.000 --> 00:14:25.000
It doesn't mean that it isn't a problem. But if it's a problem that the community does not see think needs to be solved.
00:14:25.000 --> 00:14:35.000
And. Even if they do think it needs to be solved. But there isn't a clear. Clearly articulated pathway.
00:14:35.000 --> 00:14:47.000
Towards solving that. Without. Reducing the risk of major trade offs. That's how EIPs fall into a stagnant status.
00:14:47.000 --> 00:14:53.000
That's not like a universal rule. There's some other reasons why. There's many reasons why.
00:14:53.000 --> 00:15:09.000
But an EIP. Is most likely to avoid that fate if they're one they're topical like they may not move to final But if it is a topical EIP that people are willing to.
00:15:09.000 --> 00:15:25.000
Debate and talk about. It will be a living EIP. Matt had mentioned EIP, 1559 and how long it had gone on in sort of living like review living status moving back and forth.
00:15:25.000 --> 00:15:40.000
The constant back and forth. That one. Was able to do that because it really was. A critical question that the theorem as a community was trying to answer.
00:15:40.000 --> 00:15:47.000
And therefore it stayed topical, it stayed relevant. I think what we're seeing with what we're going to talk about next week when we zoom in on.
00:15:47.000 --> 00:15:59.000
The one of the EIPs in the Denkun upgrade. Which is EIP 4.
00:15:59.000 --> 00:16:06.000
8 4 4 proto dank sharding That will. And it actually has like a longer name.
00:16:06.000 --> 00:16:18.000
It kind of is proto dang sharding, but. That solves a problem. That Ethereum is faced for a while with the increasing state.
00:16:18.000 --> 00:16:29.000
That is required to support Ethereum and challenges. And being able to get more transaction throughput. Specifically using .
00:16:29.000 --> 00:16:48.000
So, you know, being able to write like write and store data on the theorem blockchain and being able to deal with the increasing size of the state, perdog starting attempts to put a pathway towards solving that over time.
00:16:48.000 --> 00:16:51.000
And that is.
00:16:51.000 --> 00:17:04.000
Why it's so relevant why it's talked about when you run into a proposal that is trying to bring something that just doesn't resonate with the community as like a key issue to solve.
00:17:04.000 --> 00:17:11.000
Are and it's not easy to see how it could be solved. You're gonna lose.
00:17:11.000 --> 00:17:22.000
In the limited attention economy that exists. So the EIP process is not immune to. Folks losing attention, not feeling that's like that's a problem that need need to address.
00:17:22.000 --> 00:17:37.000
Those things could fall by the wayside. So when you think about If we're saying from like an optimistic standpoint, if we're trying to shepherd an EIP through, it's really thinking about, hey, am I solving a problem?
00:17:37.000 --> 00:17:46.000
Is this a relevant problem and how can I articulate a way that this can be done in manage the complexity.
00:17:46.000 --> 00:18:01.000
Being able to hold that attention and keep that message going and plot out those solutions is gonna be key to push to moving the EIP forward in getting groups of people to help.
00:18:01.000 --> 00:18:12.000
Any IP author determine how they would implement this EIP, what the reference implementation is. Becomes really key to.
00:18:12.000 --> 00:18:27.000
Build a group of people who are willing to help. Move the process along as Matt was saying. Last week So that's kind of my answer, but if anyone else has any thoughts, you're welcome to share them.
00:18:27.000 --> 00:18:37.000
Would love to hear what folks think about. Could be done to make the EIP process run faster because this is literally something that at any given time.
00:18:37.000 --> 00:18:46.000
The community is sort of thinking about. How do we do this more efficiently? And maybe faster isn't the best word to say, but how do we do this in a more efficient way?
00:18:46.000 --> 00:18:52.000
Is it, you know, one of the discussion questions we had we want is it possible for anyone to know everything about Ethereum?
00:18:52.000 --> 00:19:09.000
Would love to hear if folks have some thoughts or some Questions about why the process runs away it does so we'll open it up to questions.
00:19:09.000 --> 00:19:26.000
Yeah, not so much. Question is a comment. It seems like Ethereum is so complicated and hard to know that Just consequences of any change, you know, how long would it take to figure, you know, All the downstream, you know.
00:19:26.000 --> 00:19:30.000
Kind of issues that could come up.
00:19:30.000 --> 00:19:34.000
Great question. That is a question. How long would it take to know the downstream issues that would come up?
00:19:34.000 --> 00:19:39.000
Alright.
00:19:39.000 --> 00:19:49.000
They're actually is a way of testing this. And so I'll give you the quick TLDR.
00:19:49.000 --> 00:19:57.000
And then we'll actually go into the process of how this is tested. So for Den Coon, how we are testing this.
00:19:57.000 --> 00:20:10.000
Is through what are called Dev Nets. In the merge there were shadow forks essentially You take existing.
00:20:10.000 --> 00:20:18.000
Ethereum clients. And you apply the change and you create a network that isn't the main network.
00:20:18.000 --> 00:20:22.000
And you run.
00:20:22.000 --> 00:20:33.000
You fork the current network and you run code on it. That ends up giving you a sense of whether those changes, how those changes actually.
00:20:33.000 --> 00:20:54.000
Workout. So Well, we'll get into the deep. Fundamental. We will spend an hour about how that works and that actually is part of the final, like the developer track for the for the project-based learning in this course is like if you're on the developer track you will deploy a smart contract to a, you will deploy a smart contract to a Devnet.
00:20:54.000 --> 00:21:11.000
Or to a test net, that is how we know things operate as. As they should right you you're deploying something and you're saying okay given that we have this forked version of Ethereum where we've implemented these changes.
00:21:11.000 --> 00:21:17.000
If we're going to try and use For example, Uniswap, does it work as anticipated or not?
00:21:17.000 --> 00:21:23.000
And then basically you see that and if there is something that doesn't work as anticipated, that's where.
00:21:23.000 --> 00:21:28.000
There's an evaluation done of like, okay, why isn't it working? Why might that have happened?
00:21:28.000 --> 00:21:35.000
And you actually have to do this for every single Ethereum client. So, and ideally with the merge we had to do with every single Ethereum and CL client combo.
00:21:35.000 --> 00:21:57.000
So there were many, many basically like shadow forks that were done where the merge was done And then there was, what I would call like game days that were done where Literally the test net girly underwent the merch, right?
00:21:57.000 --> 00:22:18.000
It like it actually underwent the merged. So that is how we're able to test all this out It requires though a whole lot of work of actually implementing these changes in a version of every Ethereum client and then taking the chain in in creating that.
00:22:18.000 --> 00:22:25.000
Alternate version of it and seeing how it plays out. It's a lot of work the coordination around that.
00:22:25.000 --> 00:22:43.000
There's actually calls around like Devnet coordination, but That is how it's done. It's to actually simulate what it what it would be like at a certain scale in the participation of community is key because the more
00:22:43.000 --> 00:22:55.000
Signal that you get from that the more people participating doing something it is basically more inputs to test whether those assumptions were correct.
00:22:55.000 --> 00:23:05.000
I think we're on Devnet 9 now for the Dev Coon upgrade. So if that gives you a sense of like how many times they've gone through of like Thank you.
00:23:05.000 --> 00:23:16.000
Them clients have technically been ready in terms of applying the EIPs. But have they, but they need to prove out that they all like are able to work in.
00:23:16.000 --> 00:23:23.000
In this situation. So that's how we do it. And that's why you've we've seen you know, Den Coon move from like a launch date probably at the end of this year to moving into 2024 because there needs to be more data collected.
00:23:23.000 --> 00:23:44.000
So that's a great question. I just giving you sort of like the utopian high level view of how that works, but we actually, though all of week 6 will be about like, how that's coordinated, how that spun up, because it's critical.
00:23:44.000 --> 00:23:55.000
It's. Critical to actually making, sure that there won't be major issues when, a upgrade goes live.
00:23:55.000 --> 00:24:00.000
So what's the merge guarantee because of all the testing?
00:24:00.000 --> 00:24:04.000
The merge was.
00:24:04.000 --> 00:24:21.000
Never guaranteed. But the testing. Made the probability so high. That it was going to be.
00:24:21.000 --> 00:24:31.000
6. That there was a lot of confidence going into the merge now. You know, at that time, I was.
00:24:31.000 --> 00:24:39.000
Prog managing the Ethereum API for, so yes, during the merge was like constantly just sending.
00:24:39.000 --> 00:24:48.000
API requests to our endpoints. And being like, you know, like even though we knew everything we had done, everything everyone done.
00:24:48.000 --> 00:24:59.000
I was still Oh, almost overwhelmed by how Smoothly it went. So.
00:24:59.000 --> 00:25:01.000
I think. That wasn't guaranteed. I think that it went as smoothly as it was.
00:25:01.000 --> 00:25:19.000
And I think all of the testing got it to that point of They're just being so. It was so battle tested at that point.
00:25:19.000 --> 00:25:28.000
That the likelihood of it. Failing would if it was like really driven by like these huge outside externalities.
00:25:28.000 --> 00:25:37.000
That might not have been able to like reduce risk-wise. I think there were just so many people that had touched.
00:25:37.000 --> 00:25:46.000
The merge. While it definitely slowed things down, you know, it took years to get to the merge.
00:25:46.000 --> 00:25:57.000
It there were benefits in that like it you know it largely the things that have gone in with the merge have To my knowledge, they've they've all worked.
00:25:57.000 --> 00:26:10.000
They've all stood up, including like, you know, I think there was a loss of finality that happened on main net twice in May and that was actually designed as part of the protocol.
00:26:10.000 --> 00:26:26.000
To have that sort of like, hey, if we can't sync. You don't have finality, but blocks still get created and then eventually finality goes in and that was like a huge Almost proof point of like, hey, these These, I don't wanna call, but these like.
00:26:26.000 --> 00:26:39.000
Things baked into the protocol that deal with these edge case situations like they worked under pressure. We had a loss of finale for a few hours, but then those box are finalized, new blocks are being created.
00:26:39.000 --> 00:26:50.000
So I think the more you test. Good morning, the more you find out, it doesn't guarantee your success, but it gives you more ability to.
00:26:50.000 --> 00:27:01.000
Sort of react to what the problems will be. So testing is very important and very good. And it's also very hard to do well.
00:27:01.000 --> 00:27:07.000
How about something EIP, 1559, that's the burn. Eip.
00:27:07.000 --> 00:27:15.000
It is. . EIP is probably the easiest is the nice little like Tag line, but, yeah, there's
00:27:15.000 --> 00:27:21.000
Right, but that's the one that involves the burning of in all transactions. Is that correct or?
00:27:21.000 --> 00:27:29.000
And then there's like a tipping element as well. So let's just go to all.
00:27:29.000 --> 00:27:37.000
And we'll just control F. To 1559. Just so we can jump into it. So.
00:27:37.000 --> 00:27:50.000
It's described as a fee market change for 1.0 chain. This is kind of reflects our how we talked about stuff at the time.
00:27:50.000 --> 00:27:56.000
Great people on this EIP. You can see just every EIP has it requires like basically what ones that have to happen.
00:27:56.000 --> 00:28:06.000
It was a standard Track EIP. And basically, yeah, a transaction pricing mechanism that fixed per block network feed that is burned.
00:28:06.000 --> 00:28:20.000
And it dynamically expands and contracts block sizes to deal with. Transient congestion basically like it's able to.
00:28:20.000 --> 00:28:26.000
Do that sort of burn and deal with the variability in a network usage.
00:28:26.000 --> 00:28:30.000
Yeah, so, you know, kind of pulling back. You know, that I guess I, you know, makes it deflationary.
00:28:30.000 --> 00:28:49.000
You know, without testing, without anything, what does that look like in 20 years? I mean, do we know, you know, when we, when an EIP like this is proposed, like, What are the consequences of deflationary?
00:28:49.000 --> 00:28:52.000
Currency? Yeah.
00:28:52.000 --> 00:28:57.000
Yeah. So.
00:28:57.000 --> 00:29:03.000
What?
00:29:03.000 --> 00:29:16.000
Is good is that You're. Able to because of like the
00:29:16.000 --> 00:29:23.000
Because of the way the EIP is written, one can. Actually model that out, I think over time.
00:29:23.000 --> 00:29:29.000
So. If your question, I think this one can't.
00:29:29.000 --> 00:29:34.000
Maybe we can change the timeframe. But like you can see since the merge, how much was.
00:29:34.000 --> 00:29:48.000
I don't know if we can go. Going forward, but It is possible to. Actually plot out, I think, what what the expectation would be.
00:29:48.000 --> 00:30:03.000
In terms of the supply growth. And per year. So it looks like we're kind of. You know, this is this is where we're at.
00:30:03.000 --> 00:30:10.000
Now we'd be modeling this out. As you're saying like given the current
00:30:10.000 --> 00:30:18.000
Conditions that we have. And so. As other EIPs are being introduced, this could change, right?
00:30:18.000 --> 00:30:30.000
Depending if like certain elements, certain aspects about Ethereum change. The supply change could go up or down because it might impact the factors that go into this.
00:30:30.000 --> 00:30:44.000
And so I think that kind of opens up another question that I'm seeing in the chat. Goes into it nicely with many auxiliary teams helping analyze and test the proposals, is it possible to send a change to production that causes problems?
00:30:44.000 --> 00:31:01.000
Did any proposal have to be rolled back? That I know of. None like immediately comes to mind that doesn't mean that there hasn't been, but what I do know that happens is that changes to a theorem clients that are implementing the proposal.
00:31:01.000 --> 00:31:10.000
Have had to be rolled back because they've introduced a issue with the Ethereum client and it's not having the behavior as.
00:31:10.000 --> 00:31:22.000
Expected. So what I mean by that is because each Ethereum client team has to take the Yeah, EIPs and translate them into code.
00:31:22.000 --> 00:31:32.000
And that's why we ask for like as part of the IP if you can write a reference implementation it really helps because it helps the client teams actually put those in.
00:31:32.000 --> 00:31:46.000
It has been where some client teams have put in something and then because of certain other updates, you know, because sometimes there can be,
00:31:46.000 --> 00:31:56.000
There could be interactions that occur with like upgrading something else or swapping out a database that could result in some sort of issue.
00:31:56.000 --> 00:32:04.000
And so I have seen Ethereum clients have to like roll back to a prior version of the client until they're able to.
00:32:04.000 --> 00:32:10.000
Implement a change successfully. Now most of the time that's done in like sort of the Devnet.
00:32:10.000 --> 00:32:18.000
Side of things or in a shadow hard fork, but there are times when in the run up to.
00:32:18.000 --> 00:32:26.000
A an Ethereum upgrade. So in the run up to an Ethereum upgrade, Client teams may have said, okay, we're gonna put in these changes over time.
00:32:26.000 --> 00:32:35.000
Slowly and then like when, for example, the merge happens, then they'll go live.
00:32:35.000 --> 00:32:41.000
But they've already put them in and then that actually causes an issue or a regression to the software and causes it.
00:32:41.000 --> 00:33:04.000
So it's like, oh, sinking is now off. And I've seen client teams have to roll those back and address those and there was a couple, I mean, some, there was some sort of nervous moments and I would say August before the merge as a lot of those changes were rolling out and there were some client teams that ran into certain issues.
00:33:04.000 --> 00:33:12.000
And they had to like roll back and if you had already upgraded it might have caused a problem with like state.
00:33:12.000 --> 00:33:19.000
And so, It's always good to find out those in advance, but I know that like there was.
00:33:19.000 --> 00:33:29.000
Some tense moments for me in in August that of 2022 that was like really thinking about like, okay.
00:33:29.000 --> 00:33:39.000
What is our what is our plan if there's some sort of like. Issue in in one of the clients.
00:33:39.000 --> 00:33:49.000
So. I haven't seen an EIP have to be like roll back. However, there is and a very interesting EIP.
00:33:49.000 --> 00:34:12.000
That. You will see here that we. Don't really We don't really talk about in this class because We.
00:34:12.000 --> 00:34:20.000
Are kind of just focused on like going forward but I think I did find it. That was it.
00:34:20.000 --> 00:34:30.000
It is. The Dow hard fork and So when.
00:34:30.000 --> 00:34:34.000
The
00:34:34.000 --> 00:34:50.000
I believe this is the one.
00:34:50.000 --> 00:35:02.000
It basically is like a change that is like change this stuff. You know, you're kind of seeing like
00:35:02.000 --> 00:35:13.000
If this is even the The one that I want.
00:35:13.000 --> 00:35:22.000
I'll have to find this because I am, but basically we've had hard forks around the Dao.
00:35:22.000 --> 00:35:33.000
Are an upgrade that happened around like the Dow. The Dow Hack that There is like a pretty big change, obviously, to.
00:35:33.000 --> 00:35:42.000
Ethereum to revert to a different state. So I think that's like the closest thing.
00:35:42.000 --> 00:35:49.000
Well, it wasn't like a proposal that rolled back. It was like a a change that was literally a rollback.
00:35:49.000 --> 00:35:56.000
Of a theory, to a different state in time and caused a split between Ethereum and Ethereum classic.
00:35:56.000 --> 00:36:13.000
So that's probably the best one that that example that I can give. That that comes to mind for me.
00:36:13.000 --> 00:36:18.000
And.
00:36:18.000 --> 00:36:32.000
Yeah, so obviously this like the The EIP registries is super. Super interesting and if we go to our We can see all of our ones that our.
00:36:32.000 --> 00:36:38.000
You know, become tiers 721, the non-fungible token standard.
00:36:38.000 --> 00:36:53.000
You can see there's many other token standards. That now exist, but a lot of the things that we kind of take for granted or have been talked about.
00:36:53.000 --> 00:37:02.000
You can see I'm all all in here. It's really cool. It's almost like a hit like a like a history of.
00:37:02.000 --> 00:37:10.000
Of Ethereum and the idea is that that have gone into practice and others that are kind of now.
00:37:10.000 --> 00:37:19.000
In a in his status of not being worked on, but they're, you know, they, they added.
00:37:19.000 --> 00:37:22.000
To what we what we know about how we're going to run the protocol and they were debated.
00:37:22.000 --> 00:37:37.000
So it's really, really interesting. One of the last things that I'll say It's always good to go under review and draft and kind of see what are the things that are currently like being worked on.
00:37:37.000 --> 00:37:48.000
And that people are debating and in coming up with. Because this really gives you a view of like what's coming up next.
00:37:48.000 --> 00:38:01.000
Here's EIP 6 8 0 0 Ethereum state using a unified vertical tree This introduces a new vertical state tree along try along the existing MPT.
00:38:01.000 --> 00:38:10.000
Pretty interesting. So we're gonna introduce a vertical state tree alongside the, the Merkel Patricia tree.
00:38:10.000 --> 00:38:25.000
And this will be. How we will transition it. Exclusively to Verkal Tree. So this At some point in the future, this is gonna be a EIP that will be quite debated.
00:38:25.000 --> 00:38:30.000
And it's part of sort of a italics articulation of. The Ethereum roadmap.
00:38:30.000 --> 00:38:38.000
You can see there's a lot of really interesting things in here.
00:38:38.000 --> 00:38:46.000
Cool. Okay, before we as we kind of get towards the end of this session just a couple of things guest speakers still to be announced.
00:38:46.000 --> 00:38:56.000
We're coordinating. So it is possible we may sort of double up for week 3 with 2 guest speakers just given some scheduling.
00:38:56.000 --> 00:39:04.000
But we're trying to give you. Yeah, a guest speaker at least for each week and maybe a bonus one as well.
00:39:04.000 --> 00:39:09.000
And so, yeah, as soon as you have that, will add it and we'll send it out.
00:39:09.000 --> 00:39:20.000
And, this recording in the deck, I did not get a chance to post this deck beforehand, but I will post it alongside the recording.
00:39:20.000 --> 00:39:25.000
Okay, we've still got about 15 min left, so if there's any other Q&A that folks have, feel free to jump in.
00:39:25.000 --> 00:39:47.000
So pause there and then kinda. See what happens and if not we'll wrap it up.
00:39:47.000 --> 00:40:00.000
Take everyone's silence as a feeling of deep contemplation and thus will let you all Depart for your weekend, I hope.
00:40:00.000 --> 00:40:09.000
You have a great weekend and we're excited to see you back speak 3. We're going to be diving in to EIP 4 8 4 4.
00:40:09.000 --> 00:40:21.000
Proto I'll put up real quick just so you can.
00:40:21.000 --> 00:40:32.000
Proto. Yes, I should just type in. 4 8 4 Chart blob transactions. That's why it's not called per dexterity.
00:40:32.000 --> 00:40:37.000
That is the name I refer to. So we'll be going deep into this. This will, this is.
00:40:37.000 --> 00:40:42.000
Going to be part of the Denkun upgrade. So much to talk about. As you can see, there's a lot here.
00:40:42.000 --> 00:40:53.000
AlrightYup
Guest Speaker
Mikhail Kalinin - Principal Researcher, Consensys
Twitter: @mkalinin2
Supplemental Resources
Proceeds from collectibles editions of this post will be distributed as follows:
100% to Education DAO Optimism Treasury (0xbB2aC298f247e1FB5Fc3c4Fa40A92462a7FAAB85)
