Ethereum Cat Herders PEEPanEIP, 18 Oct 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: PEEPanEIP #49: EIP-3607: Reject transactions from senders with deployed code (Marius W & Andrew A.)

Description

Topics covered
-----------------------------
01:08 - EIP introduction
02:00 - Introduction (Andrew)
02:57 - Introduction (Marius)
03:33 - EIP-3607
03:35 - Motivation
06:10 - Implementation in Geth
07:10 - Testing in Geth
09:49 - Gotcha’s in Geth
11:02 - Why implement in CodeHash not the CodesSize in Geth?
11:48 - When will Geth accept the transaction?
12:28 - Changes in the Yellow Paper
15:53 - Implementation in Erigon
17:30 - Interblock state in Erigon
18:28 - Ethereum test updated with the latest release
19:15 - Silkworm - A new Ethereum C++ client
19:24 - Why develop a new Ethereum client?
22:00 - EIP-3607 Implementation in Silkworm
23:18 - New tests for EIP-3607 in Silkworm
24:45 - Basically to prevent attack with a private key that is mapped to a contract
25:24 - Why isn't there an attack vector in the opposite direction?
27:16 - Is every consensus change is updated to the Yellow paper, if not how are changes decided to go to the Yellow Paper
29:46 -Why implement this proposal? Is there any estimate on the financial benefit that the attacker may get? Can multiple contracts be attacked at the same time?
32:22 - What are the chances in (percentage) of this attack to take place?
32:35 - What would have been the chances of collision after the Merge, if this EIP
33:47 - Gotchas - Are these exceptions for Geth client-only or for other clients as well?
35:21 - Do we have any list of corner cases for C++ implementation?
36:53 - Yellow paper & Soft fork. Why not consider it for a hard fork? Reasons for considering hard fork and soft fork?
40:01 - What are the plans for Erigon? Do we see Silkworm & Erigon co-existing?
41:58 - Client diversity - Are there any initiatives from the Geth & Erigon client to motivate users to move to the other clients?
45:45 - Is there any standardization of testing & Metrics?
50:02 - EIP status - move to “Review”

Resources:
- Slides: https://docs.google.com/presentation/d/186OHgkexlaU-OeEwOBOuxKapTM9UX8aM1Rns5zf5Quo/edit?usp=sharing
- EIP: https://eips.ethereum.org/EIPS/eip-3607
- Discussion: https://github.com/ethereum/EIPs/issues/3608
- Ethereum tests: https://github.com/ethereum/tests
- PR to Ethereum Yellow Paper - https://github.com/ethereum/yellowpaper/pull/801
- PR to Erigon implementation: https://github.com/ledgerwatch/erigon/pull/2820
- PR to Silkworm implementation: https://github.com/torquem-ch/silkworm/pull/423

Follow at Twitter
-----------------------------------------------
MariusVanDerWijden @vdWijden | Andew Ashikhmin @yperbasis | William Schwab @William94029369 | Pooja Ranjan @poojaranjan19

Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2

Follow PEEPanEIP earlier episodes at https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F

Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.io/ethereumcatherders
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
GitHub: https://github.com/ethereum-cat-herde...
Email: support@ethereumcatherders.com
Website: https://www.ethereumcatherders.com/

A

Developer, never stopped amazing us with their work. In the midst of all these popular network, upgrade client teams are also working on other improvement. Proposals which are required for strict security upgrades welcome to another episode of peep, an educational video series where we get an introduction to eip's upcoming updates and the basic of ethereum blockchain.

A

I'm your host puja ranjan and today we are going to have an overview of eib 3607, reject transaction from senders with deployed code, I'm joined by our guest maurice, who is one of the co-authors and the developer, implementing the proposal in geth client with him. We have andrew who has implemented this proposal in c, plus, plus and working on the aragon, client implementation, and we also have on the call william shop, the ethereum categories.

A

Thank you, everyone for joining, so the proposal eip3607, is a core proposal that was proposed in june this year by dan crede and is in draft status right now. However, this has already been merged in some of the clients and is ready to be moved to final status. Eventually, this proposal also requires to update the yellow paper and make it a part of formal ethereum specification, and in this episode we will have an overview of this one-of-a-kind proposal, its client implementation and more in a while happy to see you again, marius welcome andrew.

B

Thank you for having us. Thank you.

A

As for the guests, especially the new faces, we always request to have a kind of quick intro to hear about their journey to ethereum spaces. So if we can start with a quick introduction, can you start with andrew.

C

um Hello, so my name is andrew and I work on the ethereum team in general, but particularly on the aragon team and uh I joined the ethereum community in the beginning of 2019 and it was less who kind of who invited me to the community.

C

So before that um I I hadn't worked on blockchain projects, um and um so it's been an interesting journey. Now, of course, I know a little more now. I know a bit more about blockchain and ethereum than I did two years ago. So I'm happy to be part of the community.

A

Thank you, andrew marissa. I know you have already been here, but just a couple of words and then we can start with the presentation.

B

Yeah, I can, I can say something: hi, uh I'm marius. uh I joined the go ethereum team uh one and a half years ago and been been doing core development ever since and that's that's basically, it.

A

All right, thank you. Thank you so much. uh I always love this section. I don't know for some reason. It makes me feel very closer to uh know the ethereum developers community anyways, let's get into the proposal so without further ado, let's peep in.

B

Thank you. um I think I'm going to start yeah we're going to talk about uh 3607 today um a bit about the motivation. So basically we there were some discussions. uh Democrat had some discussions about the security of eoas, so in in ethereum we have two types of accounts. We have so called eoas externally, owned accounts, those are accounts or externally owned addresses.

B

Those are addresses that have a private key and we have contracts. Those are addresses that don't have a don't have a private key. So one problem is that if you, if you have a have a large enough computer, you can basically create a contract for which you know the private key. For that you have to find a collision between an eoa and a contract.

B

This is highly unlikely.

B

It requires 2 to the power of 80 operations, but it's not impossible, and given the recent rise in in computational power, uh we made some calculations and uh came to the conclusion that this is uh not that unlikely, um as we first uh thought it's uh by the way, it's two to the power of 80, uh not two to the power of 160 bits uh of security.

B

uh Due to the due to the uh birthday problem, uh because you don't require a you, don't want to find a certain key for a certain key and contract for one address.

B

You just want to have any key or contract and contract for one address, and this would allow this would allow the con the the attacker to train a contract.

B

Basically, he would deploy the contract that he has already has the secret key for um and then people would join the contract send their money to, for example, if it's like a a uniswap pool or something like this and the attacker can just take out all of the funds because he has the private key to the address, and this can be prevented by this, allowing transactions to be sent from addresses that also have a contract code deployed and yeah. So that's basically the proposal.

B

um This is the implementation in gas. It's uh pretty short, it's just two lines. Basically, we just look up in the database before we send the transaction. If the sender of the transaction so from address, has some code deployed?

B

It's not a big change, and so we, we kind of decided to make it as a soft fork into the protocol. So basically just have the have the clients implement the change whenever they want to, because we don't really see that. We don't think that someone is currently trying to exploit this currently spending the the the energy for that. But we just want to make ethereum future proof against this. This type of attack, um one big issue with that was testing.

B

One thing that can be done is that contracts can be deployed in the genesis state. So basically, if you create your genesis, you can have the contracts already deployed or already be part of the genesis file and those can, of course be deployed to to eoas, and we did that a lot in testing.

B

So we have the ethereum tests repository, which contains tests for basically all ethereum functionalities, especially for the evm, and these tests relied heavily on eoas, also containing code, and so we had to rewrite a lot of tests and one problem that we ran into is that 3607 couldn't be merged into death without fixing the testing first.

B

But we also couldn't so we wanted to add an inverse test, basically testing that 3607 is enabled, but that couldn't be merged in to the tests before the eip was merged in gas.

B

So we had like a cyclic dependency there, and so we decided to skip the inverse test for now and just fix the tests so that they don't rely on this eoa having contract code, merge the tests, merge 3607 in geth and then now there's a pr open to add tests to test that a client is really implementing 3607 and we also had to update the yellow paper to solidify this rule. um Basically, it's a it's a it's a new rule um that we have to like that.

B

We decided to apply retroactively uh because we know we met. We met like we. We ran a full sync with the um with the with the updated code to make sure that no one has ever exploited this, and so we're sure that this has never happened, and so we just made the decision to have this rule basically apply retroactively.

B

Yeah some some of the gotchas that we that we came across. um Basically uh one problem was that eth call is sometimes cons used to construct um construct transactions from multi-sticks.

B

So an old version of the gnosis save used the escort method to construct the transaction as f as if it was originated from an account and so.

B

That, of course, failed because now you couldn't have the transaction originate from the account anymore in each call, so we made a decision to basically not apply this rule to the rpc calls. If call estimate gas create access lists.

B

All all these rpc calls that that can execute basically fake transactions, and so another gotcha is that we that 3607 is implemented on the code hash, not the code size. First, we decided in the beginning. We we had it implemented as code size, but we thought that maybe with code regenesis and forgetting old contract code state expiry sorry so with the region.

B

As a synthetic query, it might be the case that the code size might become zero in the in the future, even for non-non-empty accounts, and so we said that we're going to implement it on the kotesh in another gotcha and guess we, the get code hash method can return either an empty cotash or a empty hash.

B

Those are different things. The empty code. Hash is basically the hash of zero and the empty hash is just all zeros and in both cases we accept the transaction because uh there's no code deployed.

B

That's that's already it for me about this proposal.

A

Thank you so now, andrew. If you would like to go next and post your talk, we will bring up some questions. Sure.

C

um So let me share my screen and I would like to go through the changes in the yellow paper. So if you look at the yellow paper, the pr was merged and, of course, the changes only to one file, because it's a big text file and um I have the yellow paper rendered.

C

The changes basically introduces a new condition uh on transaction validity, and it says that um it's this condition number four here, that uh the sender account has no contact code deployed um and which, here in the notation of the yellow paper, is that sigma, which is the state of the transaction sender,.

C

So the account um in the state, current co, uh corresponding to the transaction sender, has the code hash equal to the catch check of uh an empty string. So this funny notation means catch a cover, empty string.

C

uh Also, there is a formula here that uh lists uh the conditions when a transaction is valid, so we we simply add a new line here, but in reality the yellow paper is not accurate because uh it says that, for that we should. The first line here means that we should be able to recover the transaction sender and which is fine, but it also says that the center should exist in the state.

C

But historically there were some transactions with uh zero gas price for which the sender did not exist, and we did allow that- and uh maurice uh actually touched on this uh I'll I'll, explain I'll go into the implementation and uh um but basically yeah, it's a small inaccuracy in the yellow paper.

C

So we should address that so that it's like historically accurate, but it only affects um some weird transactions where you allow zero gas price because by default, if, uh if an account doesn't exist in the state, then we assume that its balance is zero and uh obviously you need to need to be able to cover the transaction cost from the balance. So you can only allow such transactions if the upfront cost is zero, which is only possible with the zero gas price.

C

So there is that, and I'd like to go into just a little bit more detail on the on how it was implemented in aragon and uh and silkworm and uh I'll talk about silicon is in a moment um in aragon.

C

The um implementation is very similar to that of gas, because that that part of aragon is pretty much similar to uh aragon was based uh originally forked uh from guess, though, we changed the architecture quite fundamentally in certain areas, but here it's still very similar to death. So this pr, it introduces a new error, condition error sender, not an externally owned account, and the check is that um in this uh state transition pre-check. So after we check the nonce, that's the nonsense, what we expect and that the transaction nonce matches that of on the sender.

C

That the code hash is not equal to empty code hash and it's also not equal to zero hash and zero hash actually means that the account doesn't exist. um That's what I was talking about that. Historically, there were some transactions and we should still allow them so that we are able to to think uh from from genesis um and this code the state get code.

C

It's called um in in aragon. We call it um intra block state because that corresponds to kind of the state state uh version that exists. While you are executing a block, so I can show you just how it's implemented in aragon.

C

um This intro block state get get code hash and does some capturing uh of the account read and there's, then it says, get state object and if the state object is new or is deleted, then it returns uh zero hash and it's the same as in guess so. Zero hash here means that the account does not exist, otherwise uh it just returns uh the code hash.

C

um So that was uh that's the gist of the change and also in this pr, the ethereum tests were updated um to the latest release because previously, in the tests, there were some instances when uh transactions were sent from a smart contract.

C

So we we had to update the tests uh and uh and kudos to the get team who actually, who pushed through all the tests updates, and we can now use um the like the official ethereum tests verbatim.

C

As you can see, the the changes is uh rather trivial uh and um also I'd like to show how it's implemented in silicon and silkworm is a new c plus plus ethereum client. It's based on the aragon architecture, and you may ask why do you need a new client? Well, a few reasons is that the original c plus plus ethereum client alice, is pretty much dead.

C

It's not maintained anymore, and um we feel that it's a kind of it's uh um in that siplus plus it shines in being when you need the the top performance like the when you need the last uh uh bits of performance, so that that's what we want to achieve with the c plus plus uh to be the fastest client um on the uh available and, um of course um like we want to build on using aragon's architecture, and also it's um because some aragon uses guth code.

C

um It uses the our gpl license uh and we want to have a client with uh with the apache license, because then some, maybe for certain people and particularly corporations, the apache license, is friendlier compared to the lgpl license.

C

That's another reason, and also like a third reason, is that um c, plus plus, is probably.

C

uh If you want to go length, codes and euros code talk to each other, then they will still probably talk via c and maybe and with the c plus plus providing s c. Apis is probably easier, and um another reason is that we have a very fast evm implementation, evm one uh thanks to pablo beliza. It's uh it's a really cool project, so we we kind of wanted to to build. On top of that. So that's that's uh silkworm and um it's it's still uh under very active uh development.

C

uh It passes the ethereum tests, but it's not a fully fledged client yet so it has the execution implemented, but we still have quite a lot of work to do to turn into into a fully fledged ethereum client.

C

um So I just wanted to show you this change in silicon, because in yeah in aragon, it's very similar to the gas here.

C

Also, I had to update the consensus tests and because of the update, the the the timeout is increased and here in this file the next file, a new um error code is introduced, uh which should be similar to that uh in to the error code in geth and and aragon.

C

uh That is the same that the new error code, that the sender is not an externally owned account um and basically, which change is pretty much the same- um that state get code. Hash doesn't equal the empty hash, but it I don't check here for zero hash, because in in silkworm um it's uh this method gets called cache.

C

It will return empty hash for missing accounts as well, and um also I had to change some tests so that that's a new test uh for for this uh eip for the skip so just create some sender and um uses this state to set um to set some code on the sender.

C

And then we we check that that transaction is not validated and similar to the consensus tests. I had to change our internal tests because it used to use a smart contract as a sender of a transaction. So that's here just to change the the this unit test. So it's no longer the case and uh yeah that's pretty much it and the the last change is to update the ethereum consensus tests in silicon.

C

Right, so that's all from me.

A

Thank you so much andrew thanks for the talk and presentation both of you it's interesting to learn that we may expect a new execution client soon. I'm calling it execution client at the moment, because this is the preferred terminology, but it's basically the ethereum one client.

A

So I believe william schwab may have some question.

D

Yeah um so, first of all great presentation, thank you um just going back to the underlying concept behind the eip, so the basic attack that it's looking to prevent is someone um being able to deploy a contract to an address at which they already control the key. The private key is that correct, or am I missing, details there a little bit exactly yes,.

B

You're trying to find a a a private key that maps to a contract address.

D

I I think you made a reference to this earlier marius um trying to like basically head off this question, but is there, why isn't there an attack vector in the opposite direction now for someone to try and deterministically create a contract address in order to brick somebody's ear away?

D

um For that or is there not.

B

um That, like that, could be, but then you have the the the higher security because you're trying to find a specific eoa and it's not the birthday problem anymore and you have the um the the security of of 2 to the 160 bits.

B

So that takes a really really really long time to find a hash collision between the the contract address and an existing eoa, because, like it, we can. We can reduce uh the security from from uh from 160 to 280 bits because you you're, like you, can choose both. You choose the the private key. You choose the eoa on one side and you choose the the contract code and the contract hash on the other side. So that's how you, uh how you, how you end up with like this, this less lesser security.

D

As in you can keep on generating both until you come up with a collision, but over here since you're targeting a specific uh eoa. So then you're stuck um just single-sided kind of working on the like on a contract. Until you find one that will deploy to the right address.

B

D

um Also, uh so, with regards to the yellow paper, what uh what consensus changes- or maybe I this might be- I don't know if this is too vague of a question, but is every consensus, change immediately updated in the yellow paper and, if not kind of how do we decide what and when.

B

um I think andrew can can better speak to it because uh he probably does more in the yellow paper than I do, but uh from.

A

B

Point of view we don't, we usually don't send our changes back to the yellow paper.

C

uh Right so this is this is not a hot fork change, so it's kind of a security change to address a security concern that hasn't happened yet and probably is very unlikely to happen, and it's not a breaking change, and um this this was discussed uh on acd um all coder for calls, and I think it's it's got approved um so in terms of the kind of uh approval. Of course, we we need an a a c d. Go for that, so that that's fine everybody.

C

I think everybody was in favor, yeah, uh typically, but very hard fork change. Then, of course, um the yellow paper. It's it's versioned! As now it's um it hasn't been updated to berlin and london. Yet it's um it's only in istanbul, I'm kind of working on uh upgrading it to berlin uh to berlin, but the the thing is uh this: uh this change was introduced in in geth code and probably in all other execution, clients unconditionally.

C

So it doesn't make sense to wait until um kind of a an upcoming hot fork to update the yellow paper.

D

So um so you're saying that like because it was more of a since it was a soft fork specifically to call attention to the fact that it was actually that the kind that the consensus rules were changing with us. Okay,.

C

Right, yeah cool. Thank you.

A

So I I have a couple of more questions on that and I would like to start for a new user kind of, like maybe an ignorant user for the proposal. My understanding is that eips need to prevent a planned attack right and we are talking about malicious party attacking it as an ignorant user. I might want to understand the importance of implementing this proposal in ethereum client, at least at this point of time.

A

So we have been provided an estimate of the effort and the money that needs to be put in like somewhere around 10 billion usd in hardware and electricity over a period of one year to kind of bring this coalition attack in existence. So what possibly would be the motivation for the malicious party I mean? Is there any estimate of any economical benefit?

A

I remember uh maurice mentioning about the uni swap account attack so uh like is that is that be like just one contract at a time or multiple contract, or is that uh something that can be estimated.

B

Yeah, so you could you could drain one contract um if you generate the collision, um so you would the the the problem is not really the user funds, because those are probably minimal in what compared to the cost that that this attack would would require.

B

The bigger problem is that it was not specified, and so it could could have been that, like some clients allowed for this transaction to go through and others did not- and this could could have resulted in a chain split, I'm pretty sure it would would not have because the because the tests are written in a way to prevent it.

B

um But if some clients are not really correctly uh testing, not not really having having the the tests updated to the newest version and or whatever so it that that would have been the biggest concern that different different clients or different versions of of the clients would uh would have acted differently, and so we had a chain split um and yeah. I think it's it's it's not! It's not like. It's not really fixing an imminent attack, it's more about future proofing, ethereum against nation-state attacks in the future.

A

So if we have to talk about it in percentage, it's going to be 0.001 or something like like really wrong.

B

Yeah point zero and then eighty zeros one percent.

A

Great a follow-up: maybe it's an about an imaginary situation where this eip is not implemented, and we are on the other side of the merge. Could we imagine any difference in the occurrence of a collision between contract and eu after the merge.

B

So the way the merge looks right now, um there's no change to to the execution uh to the transaction execution in the execution layer. So we have some changes to the way. It's basically you take the execution layer and you take out the the stuff that does the proof of work, verification and you put in an api for the consensus layer to to to call so there's no changes to the way transactions are executed, so yeah. It has no impact on post-merge land.

A

That's that's good, like it's really impressive, like how seriously ethereum takes security and considering that merge would not have brought any changes, it's good that we are implementing this proposal sooner rather than later. um I have another question related to one of the slides about gotcha right. So, if I understand that slide correctly, there are certain situations which are like exceptional cases and in which these kind of transaction would be allowed.

A

I'm trying to understand if this is the situation with get only or is it with almost every client? Do you have any opinion on this andrew and mice.

B

So yeah um for us it's! um It is an issue if you deploy uh like, if you specify contracts in your genesis- and we know that we did it with tests. We know that some people do it on private networks.

B

So if you have an, if you have your own ethereum fork, you could have done this just specified a a contract in the genesis file that you know uh the the the the transaction to so. If you then update all of your notes, um so for me I I see no way to do why anyone would do this, except for trying to steal user funds.

B

So if like, if your blockchain did this, if your private network did this, then I would be uh I would be concerned, and um but if you update your note to this version, then you wouldn't accept those transactions anymore.

A

All right, thank you uh and andrew, while uh the implementation of um the silkworm client, the c plus implementation of this proposal, where there any corner cases registers uh on do. We have a list available.

C

um No, there were no corner cases, it's only the well. The I guess two non-trivial points is that uh some tests used uh smart contracts uh as senders and that had to be rectified, but it's uh it's only for tests and also that actually transactions can be historically can can be sent from a non-existent non-existing sender and that's it. But I I concur with uh maurice that um it's actually it's a safety improvement and it's probably a bad thing when somebody tries to kind of to do this in in genesis.

C

So it's a potentially evil vulnerability and it's a good thing that we are preventing such potential security issues.

A

Right yeah, it's always good to have precaution better than landing up in the situation and then look for a solution so yeah. Thank you for the great work that you guys do. I have next question on the uh yellow paper side um as william were asking about uh the soft fork and the hard fork.

A

So my question is how often we come across with this kind of soft folk and what makes us like a part of a soft work, not the hard work, though this particular proposal is about security and every client is implementing, then why we are not going with the hard fork. Is it because we are having it implemented at different time uh in different clients? Or is there any specific reason that is considered while considering for a hard fork and a software.

C

uh Well, I think, with with this change, there is no need for coordination.

C

When you introduce a hard fork change, then all clients should agree on the on the block number from from which it applies here it it can apply retroactively, so there hasn't been any any transactions and it's very unlikely that uh it's it's well, it's it's feasible, but somebody has to spend like what 10 billion dollars to to even potentially trigger this attack. So it's very unlikely that it will be a concern in the upcoming months or years so whether a particular execution client implements it now or in a year. It doesn't realistically matter too much.

C

So there is that, that's I guess. That's the reason it's uh there is no need for coordination, um yeah, and you can also apply it from retroactively from block zero.

B

Yeah, I think it's it. It was more of a clarification than than a real change.

B

We wanted to clarify what the behavior is, if, uh if you do that, and that this should be disallowed and so yeah, and one thing is uh why I think we chose to do it in a soft fork- is that uh doing stuff in a hard fork um is uh uh pretty expensive, just in the in the amount of uh like uh hours that we have to put in into into into everything into coordinating into testing into uh like uh championing this proposal um uh through, like uh ten different, all chord of calls and everything.

B

So I'm I'm pretty happy that we could. We could just like slip it in to make uh ethereum secure and and uh not go through this whole. This whole uh hotfork process.

A

Basically, uh it's like the hardware process takes a lot more time on ethereum developers. I understand that path and because this is one of the changes that we would want to be registered, we are updating the yellow paper instead of making it a part of that. It's very much clear now. Thank you for this clarification right.

A

So my next question is about the silkworm uh client or the c plus plus implementation of ethereum protocol that we are expecting soon, uh so it as as you mentioned that this has the architecture of arigon and um it aims to be like the fastest ethereum client and also in the github. I found that it is using lib mdbx, which is like, like one of the fastest term database.

A

That also supports the lightweight solution, so in theory I'm assuming that it could be for new users who wants to join the ethereum blockchain with this lightweight solutions, but for the um for the aragon client. What could be the future of this silkworm is here like? Do we see silkworm as a replacement for aragon, or do we see them coexisting.

C

um I think they will coexist and um it's not it's kind of we. There are no plans to abandon aragon and switch it to silkworm. uh Silicon is still very experimental and also we have some well. We have expertise in in, um of course, in aragon, and we have uh expertise in c, plus, plus and building uh like c plus plus code base, and also we even try to like. There is a new, even more experimental client akula written in rust.

C

So uh it's, uh but there are no plans of decommissioning aragon, not yet at least so yeah there. The plan is for for them to coexist, but probably we want. I think three three implementations is enough:.

A

Right right, uh yeah, I mean it's good, it's interesting because uh these days we are talking about client diversity, and that also brings me to my next topic. So we have one more new client coming up with a different language. We can expect that some of the devs will be working there and it will at least lend a hand and the diversity that we are looking for. So client diversity has been an active discussion, considering uh the altair upgrade and uh the ethereum network upgrade for uh eth1 chain.

A

We have discussed this in like quite a month in summer 2020 and I believe um the lead developer of erigon. He had some questions and we looked into that, but we didn't see any significant change over the period of time. Get is still the dominant client and it has over 70 percent of client share. So that's too much for one client to handle. I can understand the pressure.

A

uh These developers have I'll be curious to learn about the initiatives that could be done from the ethereum client team side, especially get being the leader uh to kind of motivate users to move on to different uh client. I'm talking about it because of open ethereum as well, because open ethereum has 25 percent of share and we know that it's not going to be supported after december.

A

So is there any uh client specific plan that the users of ethereum should know about.

B

Oh I I can. I can speak to our plans. uh Of course. It's uh it's. It's uh we're not in a great spot. uh We would love to. um We would love to be less than uh less than 50. We don't. We would not like to lose our users.

B

uh We would hope instead, that new clients would like bring new users, bring new node runners into the ecosystem, so that the ecosystem uh itself will grow and we would just have a a smaller share of a bigger pie and yeah for us.

B

uh Open, ethereum going is, of course, a major problem because, like a lot of infrastructure still depends on some of their stuff, so we're trying to get some of our functionality like some of the functionality that only open ethereum provided in in in the past into gas, so that people can still retain this functionality in a maintained client, and we also hope that other smaller clients are um are looking into that to just uh yeah to take over the share that that open ethereum currently has.

C

Yeah, I'd like to add that, in in aragon, we also we try to support some of the apis. That open ethereum, has and also to support um aura, which is um a consensus mechanism. um Is that that's work is still I'm going to kind of to provide better compatibility with with open ethereum api and support its users.

A

Right, I think this is a a big opportunity for, like minor share clients, uh and if there are more documents on migration of clients might be helpful for new users or the existing user to be onboarded to a different client. I'm wondering about some of the uh testing thing. I understand the get team has to do a lot of testing for a lot of proposals say, for example, this proposal- and you mentioned that uh get team did it for the first like they were. The pilot in that.

A

Is there any standardization of these testing or the mattresses that you guys are using that can be used by different client? Do you think that would also help us help? uh You know other clients to work on the different side of this uh implementation.

B

Yeah we have. We have the ethereum test repository um it's on github ethereum, slash tests which contains um testing for for a lot of stuff.

B

The evm, mostly I've, implemented cross-client fuzzing, so that, like we're trying to we try we're always trying to um to help other clients test this stuff, because we we've seen in the past that some our clients just didn't, have the the manpower to do that, and um we hope that in the future, like uh dedicated teams can can work on this. So we that we can really focus on gas and not not uh like to do this. This testing for other clients, um but uh yeah right now.

B

We have, we basically have to do it, because uh not many other people are uh uh are willing or have the time or the resources to do it.

B

So we, I implemented a fuzzing for diff for different evms, so that you can create tests that are executed on the different different evms and then once the transaction is executed. Like you compare each uh each operation that was executed to see if there are any difference between uh between different implementations- and it already found- uh I think, around five to ten bucks in in uh nether, mind, uh bisu and also an old one in aragon. That was fixed.

B

uh I think uh uh in in the time that I wanted to report it, so it was already fixed and it also found uh one uh the one in gath that we had fixed sometime uh previously so in an old version of gas, so yeah that that that is definitely going on. If any client teams are listening to this and want to be part of it. um It's on my github fuzzy, vm or just contact me directly.

B

You need to implement eip3155, which standardizes the tracing format for for the evms, but um and then we're currently trying to standardize the json rpc api so that we can also create test cases um just to make it really easy for for people to implement and with the merge we have. I have implemented some test cases for the engine api, which is basically the the the api that is provided by the execution layer to the consensus layer, and we have test cases for that and we also have differential fuzzing for that.

B

So, if you want, if you're looking into implementing or implementing the merge implementing the consensus layer, the the engine api then also come talk to me or go to my github. Slash, merge fuss, which has the fuzzer for the for the engine. Api.

A

Awesome, I really did not hope to see a solution today, but uh I'm glad to hear about all these activities going on and I believe every step in this direction is helpful and we are almost close to an r. I have just one last topic to touch on and that's eip status.

A

I mean this is almost implemented in every client, certainly a candidate for last call, but before that we would want to see this in review. If you want to like every proposal, follow the process of it and as a member of a process improvement group, we would highly recommend moving it uh to the review. The pr coming from the authors, but in case of a bandwidth issue, the categories team also helped that and just as a piece of information.

A

This is like a supporter provided to every author who are either looking for the next step to do to make their proposal in standard and, of course, for this proposal as well. uh We can create a pull request to change the status and we would require your approval to you know, get it merged so feel free to reach out to us.

B

I'll, I can also create the pr but yeah we'll we will keep it moving.

A

Right because we want, like uh other than last call, there is no fixed duration. That is, that would be stopping this proposal getting into final, but before we get into last call, we have to pass through the review status so sooner the better all right, it's time to wrap up, and we appreciate you both taking out time talking about this proposal. I mean this is a special proposal in itself. We, we don't uh like, often see this kind of code proposals which are not considered for upgrade.

A

So I hope the information shared today not only on the proposal but also on the process and the new client that we may expect soon uh is going to help new users and understand the current user ethereum a little better, with the hope to see a decent client diversity and ethereum execution client as well. We wish this soon to be production, ready silicon client, all the best.

C

A

Yeah and on this note, thanks to all our youtube viewers for watching this episode, if you like, this episode, hit the like button and share it with community members, we want this information to be going out. So please do share you'll, find all the related resources and relevant github links in in the description, along with the uh twitter link for the guest to be followed and reach out for any questions.

A

If you have questions for this eip, you can leave as a comment uh on this video as well as, let us know on ech discord will try to uh relate to the guest. I read every comment and respond to every query. We love hearing feedback from you, so keep them coming and if you haven't already subscribed to ethereum categories youtube channel. Yet please do subscribe for meetings and educational resources coming on vdm blockchain, we'll get back with another interesting talk with the ethereum devs till then.

A

Keep watching keep sharing your love with the helium have a good one.