Understanding Ethereum Network Upgrades: Lecture 2

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

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