All Core Devs - Execution #171

Transcript

foreign [Music] thank you

and

Tim Beiko: we are live uh welcome everyone to uh El call number 171 um so today uh obviously the discussing dencoon um we can talk about devnets to start and then we have the different audits that have come in for 4788 we have some of the Auditors on the call I'm not sure if all three firms are on the call but I think we have either a copy of the report or someone from every uh one of the auditing firms so we can go over the results there uh then uh I understand whole ski uh

relaunch today and so we can get a status update on that um and after that there were two other topics people want to discuss so one is a new eip7503 and then uh Guillo mendano had some uh discussion points around self-destruct Behavior after a vertical trials are implemented um yes I guess maybe to kick it off uh Barnabas you posted this spec for devnet9 uh do you want to maybe give us a high level overview of where things are at with regards to devnet

Barnabas Busa: yeah sure uh so I have prepared all the different uh images already for the nine

uh based on the feedback that the different client teams have given us and we should be pretty much good to go hopefully tomorrow but we are still hoping that uh we can get some more years to pass some more Hive tests so the general idea is to have about 1 300 valuators for this test with a split of 75 forget another man 18.8 for president ergon 3.7 percent for ethereum JS and 1.8 percent for RF

nice

Tim Beiko: yes you only have the specific client teams want to comment on where they're at

or um yeah

Marek Moraczyński: so I can start I think we are ready and a few failing tests on the iPhone page is mostly testing setup issue and we are uh talking with Mario just to fix it and that's it no we don't see serious issue

Tim Beiko: got it nice

Parithosh Jayanthi: just one other point um so definite band we're doing the updated address for 788 so that's the one that we'd be using on mainnet as well and we'd be doing the manual deployment which is also the approach we use for mainnet um the only open question is what do we

do about the trusted setup file do we continue using the one we've used in the past or um is there an updated trusted setup file

so the setup file is not updated yet

Parithosh Jayanthi: okay then we'll continue using the previous one and then we'll do that right now and possibly a future type it can use the new just set up there

Carl Beekhuizen: that's good

Barnabas Busa: one more quick note we probably will need to have a.net then also to test out each churn limit change where we can actually spin up you know 350 to like 400 000 milliliters

and then see if uh the trend limit uh change is actually working for all the different CS but that is expected to be a much uh shorter lived devnet

cut

Parithosh Jayanthi: and one one more Point um following that one the MAV workflow works with the mock Builder now we've tested uh four of the five CLS and it works fine um which means if we would like to start pushing for everyone to have map workflows and ideally in devnet9 slash devnet 10 also test um Builders and relays so if you have a builder a relay please reach out and

we'd like to get you set up

Barnabas Busa: and one more a quick note that we're going to be deprecating uh the Bellatrix uh Genesis so from now on devnet9 and any future devnet and testnet will probably use capella Genesis

Tim Beiko: got it one quick question uh before Mario uh so you mentioned the the validator churn limit um so that and the blob base fee are they implemented in clients for devnet9 I I recall that was what we we had agreed on

Danny Ryan: yeah it's just that the the noticeability of that churn limit cap is not going to be hit until a certain validator thresholds yeah there's logic there but you're not going to hit that code path

Tim Beiko: got it

yeah

Danny Ryan: you know this is a configuration variable so we could change it to be lower but I'm also fine with doing a big test that uses mainnet configuration

Barnabas Busa: yeah I would not do anything lower than four so that's why I said we would need at least 360 000 milliliters for big bigger tests because you also don't want to run a you know four hundred thousand dollar test

for multiple weeks that 119 is supposed to live

Tim Beiko: so cool got it so because the number of validators hired and just having a short short run once definite nine is stable to like make sure we hit those code paths and everything works is the plan

Barnabas Busa: yep my phone's about right

Parithosh Jayanthi: and we'll be testing it with holes key anyway So eventually we'll be testing it with a bigger set

Tim Beiko: right got it sweet uh Mario Vega you had your hand up a couple minutes ago I don't know

yeah

Mario Vega: just a couple comments um so on the side

of the tests running on the hype Cancun um some of the errors might be that we uh bumped up the parallelism on the test execution so we're lowering it down so probably we'll see more passing tests from the clients uh later today and another comment is that I think at least one of the clients has not updated their uh the the address for typical route so I'm passing it over the the chat so make sure that you have this address for all the tests and for w92.

Tim Beiko: College um did any of the other client teams want to share progress updates or blockers or anything with regards to the

devnet

Lightclient: say that we're passing a lot of the high tests now I think we've gotten it down to about 10 or 11 of the hard Cancun ones that we're not passing and most of them are pretty small Edge case things like you know what happens if you try and send some of the Cancun data objects in an old method like for Choice V2 or new payload V2 and just trying to find the best way to implement these changes I

think the only notable thing is that we still haven't added the code path to actually propagate blob transactions on the P2P so we have the a lot of pool to to um keep track of The Blob tx's if they're submitted directly to us via an RPC but right now we're not sharing them on the P2P with our peers

Tim Beiko: got it I'm curious do other clients have peer-to-peer uh that's working for Block transactions okay so neither mine in ref uh

have it

Andrew Ashikhmin: but sorry sorry I'm a bit confused I think in the epit says that gossip is not allowed like or there should be no gossip for Block transactions but only but if it should be in in the cash announcement but not in Gossip um but maybe I'm missing

we're not announcing them at all

Andrew Ashikhmin: uh yeah we have a different code path for a transaction fetching

and that just hasn't been connected with The Blob pool so it's not really aware when transactions are submitted to The Blob pool to share with its peers

Gajinder Singh: I think edh629 should uh have their gossip announcements right

Tim Beiko: yeah I'm not sure if this specific number but okay so get uh does it have that yeah uh Andrew does Aragon have the announcement

and then I think I think yeah

Andrew Ashikhmin: I think we will have them okay um you can double check

Tim Beiko: but yeah we should and I guess on the on the El side uh

besides um some

one moment but Matt you said that cat doesn't have it are you sure I don't really see a reason why we wouldn't announce

Lightclient: yeah there's a uh Channel That's not um hooked between the blob pool and the transaction fetcher so we don't really push anywhere that we've received a new transaction in the blob pool

at the transaction fetcher is not relevant when announcing transactions

or the East Handler sorry

yeah anyway I have to look into this

it's a bit weird

Lightclient: we're yeah I'm I'm if it is connected then it's failing The Hive test for propagating the transaction so we can look more into that but when I looked at it there's the transaction announcement Channel and it's just not hooked into the blob pool right now

Marius van der Wijden: are we not working the other way around that you're subscribing to the transaction announcements

Tim Beiko: okay I guess maybe uh you all can figure

this out uh offline but I just like to check broadly so uh blob gossiping and then you know there's a few failing hype tests uh for it seems like most of the El clients are there any other sort of big blockers or big chunk of work left on any of the El clients

Marcin Sobczak: yes so uh like uh one week ago I did an experiment with sending high amount of block transactions with like only six Block in transaction uh and uh like devnet 8 were not healthy on the under such high load and in

Netherland we had a bug in broadcaster we are sometimes we're sometimes requesting transactions which we already have in uh in blood pool so like after fixing it like the condition of our notes were way better but there is still some work to be done on building blocks well and there is a high amount of block transactions in the pool but it's definitely not a blocker it's optimization

Tim Beiko: got it thanks and neither team have

blockers or just optimizations or things that they're working on they want to share

Fabio Di Fabio: so for Basil regarding the blob transaction we still have to apply some optimization now it's possible to crash the node if you send too many blob transactions because the limits are not yet in place for that kind of transaction on the other way I was following some rescue notes uh so I'm not sure if before you were talking about transaction broadcast

is broadcasting also blob transaction

Tim Beiko: got it and okay thanks I think that's most this CL or El team sorry if anyone else has anything you want to share and folks on the CL side have updates I want to share as well feel free to

Gajinder Singh: pmgs also gossips develop transactions

Tim Beiko: okay so I guess then yeah if we have

definite nine going live uh hopefully tomorrow or you know maybe early next week um we can see how the different clients uh work on it and then um yeah it probably makes sense to to test the cloud transaction gossip code paths on it and yeah hopefully have things stable then run another uh another one on another devnet with a high validator account for the churn limit um and then start moving to test Nets once things are stabilized does that seem reasonable to people um and yeah we can follow up either next

week or uh the week after uh once we have a bit more uh data on how the dead net mine tests went um yeah to figure out next steps but yeah it seems like we're in the final stages of just polishing everything and getting it ready um anything else on the devnets

okay uh next up then so we uh we had uh three audits done for the smart contract that's part of 4788 um so I linked two of them in the chat uh sorry in the agenda here

um and then the third report we expect to have tomorrow um but I believe uh we have folks from most of uh these teams on the call um so is anyone from chain Security on hi yeah

Tim Beiko: do you want to give a quick uh just overview of your report the audit in general and sort of any thoughts you have on on the contract

yeah sure um so yeah I guess super quick recap but most are aware so VIP 4788 will introduce uh this smart contract that will store the beacon rules where only the system address is allowed to set Beacon routes and anyone can otherwise

query so the primary refining of our report was that the um uh you could query the zero timestamp and would get back a zero hash as long as the slot for the zero hash was still uninitialized which in a in the original version of the code would have taken a long time to initialize because of how it was set up but that directly brings me to the secondary finding in our report where we suggested that the size of the two ring buffers so we have ring buffers for the timestamps that of the corresponding Beacon routes and the beacon through Roots themselves so

um we suggested that the ring buffer sizes become prime numbers so that the storage ones are the storage size of the contract is more predictable even when the block interval might change in the future um yeah uh that being said um I think uh yeah uh we we I mean I'm happy to talk more about how what we did we we did a bunch of tests and and even some form of verification but like uh I guess to conclude the most interesting Insight that we had uh towards the end now based on the updated review where we reviewed what the prime buffer ring size um means is that the

um really the property because uh the original EIP said that Beacon Road should be held for 24 hours um so the real property that the contract has at the moment is that vehicle routes will be held for 8 191 seconds at least because um so as long as the block interval doesn't change then everything is fine and every um every uh Beacon route will only be overwritten after let's say 8 000 blocks but the moment the block interval changes um for this time period like where the change happens this property doesn't

hold anymore so we just want to point out that in this somehow very tight uh transition time you only have let's say two hours guaranteed history of uh block um of Beacon woods so yeah um I would say these are our primary findings but uh yeah sorry I hope this wasn't too um quick but yeah uh Team linked our report in the in the chat so um obviously feel free to read the whole thing or um uh ask questions now or um directly again

thanks

Tim Beiko: thanks um yeah we'll see if there's other Auditors on the call and sort of get everyone to go through their findings and then we can do questions to everyone

after that um I don't know if there's anyone from trail of bits on the call um I don't think there is uh so I link the reports of PDF it's not published on their website yet but I linked it in the agenda if people want to check it out um and then last uh we had ddub also do an audit and I believe they have someone on the call and we expect the report to be out tomorrow

Sifis Lagouvardos: um yes hello so essentially our find it similar to the previous one so the only let's say real finding was that the zero timestamp can be quite successfully and according to

our analysis with the block time it would never be overwritten but that was my reason it was sold and then the other thing we did is we how does an exercise what would happen if the block times were to change and we resulted into advisory items basically that the storage footprint would change for different parameters or even possible block time parameters and that some stale values would remain stored but again with the changes

this is uh resolved as well now we have reviewed the changes but we just haven't updated the report so it will be up in the same link again and we'll update it tomorrow now in terms of methodology uh what we mostly did we use the we inspected the code in different representations using uh like from the assemblers to our own the compiler and uh binary lifter to get to see how it works here so that's all if there are any questions

we have to answer also uh Michael the bonus on the call here with me he also worked on the audit

Tim Beiko: um so Maris has a question in the chat about push three uh do you wanna yeah give more context of that

mirrors

Marius van der Wijden: yeah in the updated code we use push three to um push a constant that is only four bytes long sorry two bytes from here but yeah it's it's not a big deal it's just like I was wondering if someone else got this as well

yeah we noted this in our updated report um yes uh but I'm not sure if it's relevant enough for a change but yeah as we noted this in our report

Marius van der Wijden: it's not relevant enough I think I would say for for changing it now

Sifis Lagouvardos: yeah we didn't see that

Tim Beiko: are there any other questions okay

um yeah so we'll we'll have obviously all three reports people can review them um and bring up questions uh if there's any in subsequent calls but I think at this point uh we're pretty confident in the changes uh in the final version of the bytecode it's anyone have anything to add or questions concerns

um yeah just maybe one quick Edition I know this is not necessarily the target audience here but uh indirectly it might be um so it might be useful to push to Smart project developers the info that um when you're querying for a timestamp x you're not getting the beacon route from time x you're getting the beacon

route that was inserted at time x but originates from an earlier timestamp I think that will otherwise lead to um likely implementation issues

Tim Beiko: right good good point yeah yeah okay anything else on the 4788 contract

Lightclient: just wanted to say thanks a lot for all the Auditors who took time to look through this and all the people who we didn't engage directly who took a chance to look through it and all the client teams who updated the address five four or five times

yeah

Tim Beiko: and also yeah special thank you to the Auditors who looked uh we were a bit late in sending the updated commits around so appreciate the quick turnaround um for the

for the additional review okay then uh next step we had a whole ski relaunched this morning I'm not sure Barnabas Perry uh who's the right person to to give a high level update

Barnabas Busa: yep um we had the lunch this morning we had the first um epochs uh a bit struggling but since then my simulators came online and now we are finalizing with about 78 to 80 participation

we are still uh trying to get as many validated groups online as possible and hopefully we are going to be closer to 90 by the end of today

Tim Beiko: and uh is there like 20 30 percent missing uh validators that are like struggling to keep up or is it just people who forgot about the launch and are not online at all

Barnabas Busa: um there was a bug with vouch and prison and uh because of that uh we saw a bigger group being offline and also some people just run a lot more validators than a smaller machine which caused some performance issues and

missed proposals so but it's slowly getting there

okay

Tim Beiko: nice anyone else have thoughts comments questions about the launch as of all congrats on getting it live oh and then uh yeah okay you have some nice graphs that we can all retweet

uh okay then um moving on so uh yeah we had two eips or at least one EIP and one sort of

modification to discuss so first up uh we have some folks on the call who want to introduce EAP 7503 which uh it's called zero knowledge wormholes and enables minting secretly burnt if uh directly on L1 yeah I forget who was the author but if you want to speak up when I was here

Tim Beiko: yeah we are here and hi hi hi team maker and my friend now trying to share him a slides and introduce the whole idea and the whole uip okay online

Keyvan Kambakhsh: uh yeah can you guys hear me

Tim Beiko: yes we can hear you both

Keyvan Kambakhsh: sounds good um so let me share my screen oh okay do you have my uh we see the slides yeah okay perfect so okay um thanks guys for having me here uh I am Kayvon a member of novitex labs and yeah I've been researching on privacy solutions that are based on zero knowledge proofs um in the past few months and uh recently we have found a new privacy solution that we found um interesting

and it's the topic of this presentation um you have name did zero knowledge form holes and we have made an EIP for it which is yeah eip7503 um it's currently in in the draft stage but you can check it out if you want so yeah let's um get deeper so if you if I want to describe it in a single sentence it's a proposal that is proposing ethereum uh L1 clients to uh enable remitting of eaters that are secretly burnt

and uh yeah so before going uh further we first have to Define what is uh a parent eater so uh and eaters are burnt if they are in addresses that are not Expendable as you know there are two kinds of addresses in ethereum blockchain uh there are externally owned that cons under smart contracts and both of them are like um are um dry they are derived from getting the ketchak hash of something so in case of externally owned accounts uh you get the

key check of of a public key and you you just cut the first 20 bytes of it and in case of a smart contrast you get the key check of the combination of the deployer address and its icons nonsense and then you just get the first 20 bytes and we Define unexpendable addresses so an address is understandable if um there exists uh no private Keys such that the cash check of its public key is equal with the icons address or there exists no address and non-spare which is ketchak is equal with with the icons

address and uh yeah so if we send the ethereum to an address that is definitely random and not a result of like getting a cash check of republic or something like that the the address the phones in that address are burnt because you can't suspend them anymore and the reason this happens uh comes back to the fact that the hash funds hash functions are a pre-image resistance and which means that it is invisible to find an X such that the ketcheck of X is equal with some arbitrary value

and yeah so if if you know that some phone has has been sent to an address that is definitely random you know that the phones are burnt and so the question is how can one convey confidently know that um someone else has burned his eaters we can have an interactive vertical be let um someone else to choose the random bites for us and he gives the random voice to us and we send our eaters to add that address and then we can be sure that like those phones are not Expendable anymore and yeah so this is kind of an

interactive protocol and uh yeah this was a meme I uh found a bit ago on Twitter which I found funny it says like cryptographers use this uh Fiat Channel heuristic trick in order to turn interactive protocols into non-interactive versions of them and yeah we can use some an idea like that here too we can use hash functions are as sources of Randomness so in case of a non-interactive protocol one can choose a pre-image r and send his eaters to Hash of r

like the 21st price of hash of r and yeah the hash function the use should be something other than kazak it could be like I don't know Shot 2 or or some ZK friendly hash function like mimc or Poseidon or something like that so yeah I I will generate this pre-image R and I give it to you as a proof that the address I have sent my eaters to is indeed random because it is very hard to find the private key that is public key is equal with hash of something and

yeah the next trick is that using the help of ZK snarks um we can hide the value of this pretty image R and imagine that in our ethereum clients we are recording all of the ethereum transfers that are happening in a giant Miracle tree sparse Miracle tree to be specific using the help of CK snarks I can prove that an ethereum transfer has happened which has burned some amount of ethereum um but I I won't show uh which transfer was it and uh yes so the whole uh idea behind

eip7503 is is that let's build a new kind of transaction in ethereum that allows us to Mint ethereum when someone actually provides such a proof that some amount of eaters have been burned and the beauty of this method and the reason it is better than other cryptocurrency mixers is that uh it gives you a bigger anonymity set we we can somehow say that all of the icons that have not um transferred anything yet are included in the anonymity set and as the sender you can always deny that

you have ever used this protocol which is uh very good for you as as a sender and uh yeah here I have uh like an implementation proposal of how something like this can be implemented on Twitter implants so we can have a like something like an event handler in our code that is called whenever and its transfer happens it it could be a transfer that is happening on as a result of a function called in a smart contract so we gather all of the each transfers in a single function and we put uh the hash of the destination

address and the value that is being transferred in a ZK Frank friendly Sports Miracle tree and then we should have a new transaction type which we call it the mint transaction which means some amount of eater in case on like someone proves that he knows that pre-image or their edge of H of R combined with amount exists in the miracle route of the miracle 3 we were maintaining and we can also have a nullifier to like prevent double spendings very similar to style mixers

uh yeah so that that was the basic idea and this could have like some extra features like we can allow people to merge and split their nullifiers to uh bring some unique private utxo model on ethereum whenever someone migrates his phones into this private anonymity pool and um yeah in in case we are able to split our coins we can we will be able to spend only a portion of our money like we can we can burn 10 eaters and only spend one eater something like that and uh we can

um like instead of instead of using hash functions we can like do um elliptical multiplications and this will allow us to like have uh Stills burning addresses like someone will give me a burn address and people can um like someone can publicly provide a burnt mattress and we can drive other parent addresses which are expendable by the master parent address holder and they can have like steals addresses and become we can also obfuscate

um the amounts in case people transfer their ethereum in the pool and as an extra feature of the cap we can also have proof of innocency and there is also implication if we Implement such a thing in ethereum and it's about scalability and uh yeah so the thing is the centralized exchange exchange usually like gather the user response into their hot or cold ballots from time to time by making a lot of transactions so they

will give um different users different addresses and after some time they will like move all of these phones into single a single letters which is uh like a huge source of um transaction traffic on ethereum blockchain and imagine we are able to pre-mint our multiple Burns in a single proof imagine uh like there is an exchange that gives burn addresses to its users and it's able to generate a proof like proving that um

like 1000 Burns have happened and the sum of those parents is like 100 eaters and remains them in a single transaction this will save a lot of space and using this solution we will only store a single nullifier value instead of a whole transaction with a giant signature on on our database and yeah that's it thank you uh if you have any questions we are happy to answer

Tim Beiko: thanks for sharing um yeah so there was one question in the chat uh asking you about how would you

track the East Supply under this scheme um would it still be possible to just track the total Supply

Keyvan Kambakhsh: uh yes absolutely uh there is Supply in this case uh like you can get the total Supply by subtracting the amount that has been minted from the total ethereums in all of the ethereum accounts

Tim Beiko: so you're able to track how much has been reminted and so if you look at the balance of every account which includes the burns account and you re remove however was minted in a new Min

transaction that gives you the circulating supplies all right

Keyvan Kambakhsh: yeah exactly

Tim Beiko: got it any other questions thoughts

Guillaume Ballet: uh yeah quick question so you're putting everything in a miracle tree why do you bother doing this because if you can make your a snark proof that Zeke is not proof that you burnt like that you sent um yeah funds to a to a burnt address why would you incur the extra

issue that is uh plaguing tornado cash for example to that you're pulled with potentially other criminal transactions and therefore you would become immediately suspicious of uh by using this system

Keyvan Kambakhsh: uh yeah the point is as the sender as the center you can always deny that you have been in this protocol you so you are safe but as the receiver your phones may be like fact or something like that and the reason we are using a miracle trees because we want uh we want to hide the addresses that are actually like burn addresses

Tim Beiko: um this is another question in the chats that's asking can't you deploy a contract to an unspendable address with create two

Hamid Bateni: not yet but we are working on it and this we can't find any solution for doing that but we're working on it

Ahmad Bitar: no sorry the question is the opposite is that this should not be possible because if you can deploy a contract on the unspendable address or the burn address would be a problem so if you use create two you you create two does not depend on the deployer's address and announce it depends on

other factors like the contracts codes

Hamid Bateni: I got it let's say in this way uh we can prevent this event with using the random number and providing the proof with that in the r circuit and we can we can prevent this event using and deploying a contract on the same address with using the Creator because the Creator using some sort of parameter and I can't put these parameters in my circuit to prevent this event but what if we can do some sort of thing if we can find a way to doing some this way we don't need the protocol change and we

can do the hour mixer in the contract level but I don't think so there is an easy easy way to find this approach if we find it we can do it on the contrast level not to protocol

uh how do you guarantee sorry

Guillaume Ballet: how do you guarantee that you're that you your circuit is going to have a random number

Keyvan Kambakhsh: uh yes I think the thing is uh it it is very uh almost impossible to find the appropriate parameters for generating your contract address that is equal via the uh like for example the mimc of some

random number I don't think this is possible it's I mean uh a hash function that is not care check um is a source of Randomness in our case and you you can just easily found the find the the part parameters that are used for generating contract addresses that will result in an address that is exactly equal with the output of our other hash function

foreign

Hamid Bateni: we're using the hash function as a

source of randomness

Danny Ryan: and the input to the hash function is given by the protocol like randow or the state route or something

Keyvan Kambakhsh: and no the user can actually pick anything

Guillaume Ballet: right so they could pick something that they like exactly therefore you cannot prove that this address has been burnt

Keyvan Kambakhsh: yeah you will need your pre-image value in order to prove that this address is a burn address because if you lose your pre-medger then no one can like be

convinced that this address is really a burn address and not the result of like hashing uh publicly for example

Guillaume Ballet: right if your pre-image is not shared uh because you said it's part of your private witness right so it's not chair yeah so how do you how do I prove to you that my number was indeed random

Keyvan Kambakhsh: uh yes so you do the hash function the you do the hashing in the circuit and you uh like your argument is that so there is a transaction that has happened in the previous works that have sent some eaters to an address that is that

is actually the output of uh like uh ZK friendly hash function and not a care check if you prove that the address is uh the output of like a ZK friendly hash function then people can be convinced that these addresses indeed random and by that they can be sure that it's uh there is a very very low probability people can spend the money in that but but the transaction itself and the the address itself is hidden no one can know that which address is the burn

address but they will definitely know that one of the addresses is a burn something like that

Hamid Bateni: exactly in the whole network view no one can see or understand what what his address is the parent address or a normal address but let's see we we just need to find a point on the elliptic curve that we don't know the private key and we should provide the proof we don't know the private key and for doing that we should we can do it simply get a random number on the curve and multiply it it's with the hash of our premium Hash Hash of our privacy and we

can prove provide a proof with our circuit for doing this and finding a null random point on the curve we don't know the

privacy

Ahmad Bitar: so like what you need is to prove that this address is can never be produced from acute check hash can you prove that

Keyvan Kambakhsh: yeah

Ahmad Bitar: from from any kitchen cache not only from like deployer plus nonce cash from any

kitchen cache

Keyvan Kambakhsh: uh yeah exactly uh actually let me write something in the chat so it is very fine

Hamid Bateni: you are talking about the Collision

Keyvan Kambakhsh: the argument is that you can find the pre-image X for a catcher cache that is equal with a pre-image uh y applied on another hash function this is impossible to do

Guillaume Ballet: right that's actually my other question so you want to build the transaction that would mint token that is based on premise that Poseidon is trustworthy my understanding is that currently uh it's not or at least it's not been

used enough in the field that we trusted so we should consider it as non-trustworthy for the time being and assuming we're right to consider it not not trustworthy that means it would be possible to find a pre-image and therefore to Min tokens

Danny Ryan: but I mean the the construction is sound if you just use if you use shot 256 or something like yes we can debate the hash function and which hash functions you know are safe versus optimal but the construction is safe if you have a safe

passion

Keyvan Kambakhsh: 256 folks too but it will make the circuit bigger and it will take more

time to generate such as your knowledge proof

so the ZK friendly hash functions basically there's like Mimsy Poseidon a few others and even these that are the most used are very relatively well unknown their properties they're kind of new and this technology is you know being experimented with with multiple l2s and other privacy pools but we've seen inflation bugs in Aztec privacy pools different versions of tornado cash we saw one in Z cash that we don't actually know if it was used or not and so the the issues with introducing like relatively untested um versions of privacy pools whether it's this construction or others are have inherently huge risk and I would argue that we don't gain much by putting

it in the base layer now we stand to potentially lose the credibility of all ethereum and the ability to say like how much ethereum actually there there actually is which would be detrimental um I I'm a huge advocate for privacy I think there's a lot of reasons for it to be honest we still have Solutions um whether it be an l2s or other mixing contracts where people can get these sort of functions when they need them that don't bring the same inherent risk to the base layer and I I guess what I would like to know is like all constructions and technical details aside what is the argument for bringing this into the base layer now versus leaving it in l2s and and other

things

Keyvan Kambakhsh: yes so the the whole advantage of such a thing compared to other privacy Solutions is that like it is uh that there are no smart contract interactions as the sender so that is some kind of a new thing people like considering yeah it's it's it's a very large anonymity set

I think that um we have sufficient anonymity sets for this purpose I mean we do make some so we we have to like kind of give up

some things like we have to have fixed size pools right now otherwise we have to trust newer technology like Nova um but for what it's worth like from from the security side and I've probably I'm not an expert but I spent the last eight months kind of collecting ZK bugs and looking at various bugs and we've seen inflation in double spin bugs in almost every some version of almost every single major mixing technology and so I would I would argue that like long term maybe this is something like this is where we do want to go for various reasons especially like a pre-compile making this cheap that would be really great but short term I I would I would advise against using these hash functions that

are not like relatively tested to the you know like other hash functions have you know 20 years of of testing and and we're starting to see collisions in them and we have a better understanding of like where we're at there but like circuits themselves I I would advocate in being cautious of adding these directly into the base layer um and I think the only other eips that we've even considered using ZK proofs for are are still relatively simple versions of things and we're we're you know we're hesitant to even go there that's just my two cents I I think it's about like a win maybe not so much an if and I think that um testing the technology significantly more and and finding the right construction and stuff

it sounds like there's still some dispute about the construction itself

Tim Beiko: yeah and I think just also to be super clear uh I didn't want to bring this up today in the context of like dude we do this in the next hard Forge but it's more like is this something we can start to get people thinking about and obviously you know the first path the the easiest way to get something like this use is you could imagine it being deployed unlike an evm equivalent L2 right then running that for a couple years and having you know significant funds use it and and you know like building confidence over time uh because yeah

obviously there's been many cases of of ZK bugs um and it's all still quite quite new

yeah I I definitely think that's a good path forward um one thing I will say is that if you look at ethereum and you trust the way it works right now and you say like okay ethereum works if you know ketchak works if BLS signatures work if like we're saying there's not like some serious bug in the base layer and if we did add this we would be adding circuits we would be adding dependencies on a ZK friendly hash function and other things that we don't have yet and that is a big leap and there's you know in Bogota there was like some discussion about like when

would you be okay zking the entire evm in the base layer and there's you know benefits for that and I think like the general answer at least that I was like the school of mine that I was in was I almost never there's some benefits to having transparency at the base layer because you can count the total Supply if if there's you know full privacy in an L2 and there is a serious bug or there is some issue with circuits you know ZK technology has been around in in theory since the 70s but in application for like five years at a larger scale and maybe eight beyond that and we would be basically opening ourselves up to that like right now if if there is an

inflation bug or if a privacy pool goes in solvent or something an entire L2 we wouldn't even know but if the base layer has transparency we always know at least the base layer can like sever that limb and and survive and I I don't think that this is like a Perfect Analogy because these these pools would be slightly smaller than like a huge L2 and you're you know you're using them to mix so it's not like one address has like you know 100 billion dollars in it but we do open ourselves up to like a question and fud about the actual of total amount of ethereum and I also do think uh Lucas kind of mentioned something about like the regulatory perspective here I'm

not saying ethereum should bow um to the ideologies of governments or anything like that but there is a happy medium before there where you can still get things like privacy and you can still get things like provable um like total inflation right anyways I've said my part um I I do think this is a very exciting construction let me just say that I'm not I I don't want to complain about that I I think it's exciting I think we should just use a lot of caution and it's not just for legal reasons it's not just for security reasons I think there's like a ideological aspect to this I think we should discuss all of

them and I'm happy to put my thoughts into the IP directly

Tim Beiko: yeah I agree you know both from a technical soundness uh you know analysis and also from do we eventually want to do this on l2s on L1 and and whatnot um there's a lot of discussions to be had then maybe this is a good place to like wrap up um what would be the best place for people to like discuss this VIP I assume is like an eighth magician's thread but if there's somewhere else um the authors think is better

or

Keyvan Kambakhsh: um we haven't built a like discussion group for that unfortunately yet

Tim Beiko: and got it so let's uh maybe just use discussion link on youth magicians for now and then if you have a new and better place we can move to that in the

Keyvan Kambakhsh: sounds good

Tim Beiko: yeah yeah but yeah thank you so much for presenting um and if you can share the slides either here on the Discord or uh on on eat magicians uh that would be great for people to be able to review them

Keyvan Kambakhsh: uh sure thing I will put it in the chat too

Tim Beiko: awesome thank you sweet then last up uh so Guillaume you wanted to discuss some self-destruct uh

Behavior changes uh with regards to uh vertical Choice

yeah

Guillaume Ballet: yeah uh something very simple in fact I don't know if I can share my screen which um yeah I'm always too lost to find my windows uh uh okay well it doesn't really matter so uh what's happening is that when you like if you look at the text of the of the eip6780 um it says when self-destruct is executed in the same transaction as the one the contract

was created in you uh you you retain the old Behavior but there's one thing where the old behavior is not retained and that's in the case of vertical trees in which case the it says the clear storage will be marked as having been written before but empty um that's uh that's something we would like okay I would like to change but it's it's a request that also came from uh from dragon from from Red um because if you look at the code when you when you do the deletion uh basically nothing hits the the tree layer so we would have to create a special case to write to

zero uh and it's it's a departure from the current behavior and that's something that indeed has no uh observable difference from the evm point of view but from the code base uh from the client code base point of view does have an impact so I would like to to remove this and just keep the keep the uh the current behavior which is no like the tree doesn't get updated in that case uh so yeah I would like to know if someone is against that I know Dano has countered but I don't think it's really a counter it's still compatible with this approach um Dano has suggested we we simply deactivate self-destruct uh with

vertical trees period that's uh going to to spark a lot of debate and we don't necessarily need to have this debate now um but uh but yeah I would like to just focusing on on the EIP proper um leaving open the possibility to deactivate self self-destruct all together at a later stage uh I would like to to know if there's some uh some disagreement with with this approach of keeping the old the old behavior in the vocal Tree World

Tim Beiko: any thoughts comments

Guillaume Ballet: I mean there's a comment by Ahmad uh eight yeah that's exactly that's exactly what uh uh like the effect would be except you don't even you don't even delete what's in the tree because that account has been created and self-destructed before the the cleanup code the the cleanup process at the end of the block writes it to the writes it to the tree so it would be an in-memory EIP 158 basically I mean this is how it works already um I would like to retain this behavior in

vertical

Andrew Ashikhmin: that sounds reasonable to me

Tim Beiko: and when you say this is how it works

already you mean width 67 AV

Guillaume Ballet: uh yeah even if you if you write if you create a contract and you self-destruct it in the same in the same transaction uh um okay all of a sudden I'm being unsure but I'm still pretty sure that it it never hits the the disk basically so it's as if nothing was created

Ahmad Bitar: my understanding is the same it's as if nothing is created so like my question to gallium again is what exactly is the proposed changed because like if nothing hits the disk

what's the problem

the

Guillaume Ballet: the problem is that this is not what the EIP says currently the EIP says in the vocal Tree World when a contract is created and self-destructed in the same transaction we should overwrite all the for example the balance should be set to zero and that should like the tree should be updated with a zero instead of the the account being non-existent

Tim Beiko: okay so this is the last bullet I'm looking at the EIP now this is like the last bullet of the second like uh exactly bullet two okay yeah so removing that yeah so with yeah

I assume this would not change anything about current implementations because it's all based on when vertical trees are implemented but

Ahmad Bitar: okay now it's clear um let's let's check who added this point and why because like there must be a reason for adding this

Guillaume Ballet: so it's uh it's dankhad and I asked him and he said he thought that would be uh I mean I don't know I saw him earlier maybe he can confirm directly um I don't see him right now oh yes he's here um but yeah basically he said he thought that was simpler but turns out it's not so uh yeah unless duncrod wants to add something

that that's my that's my answer

Dankrad Feist: yeah no I don't have a strong opinion on what the what the state of those search addresses should be yes it um it was simply seemed like that would be the straightforward to implement it but if it's the other way around then we can just re-specify it like in practice it shouldn't matter in practice like in from the evm point of view uh both of them look uh completely empty so it's only about the state commitment where we need one unique definition

Tim Beiko: so in in that case yeah Guillaume if you want to open the pr to just remove it maybe give people a couple days to comment if they weren't on this call or whatever um but then I would yeah I would push for us to make that change now because when the EIP is deployed on mainnet and it's set the final um it'll be harder to change um so yeah now feels like the right time to just remove that and it won't change anything in terms of client implementations but at least the spec will be a future proof

Guillaume Ballet: yep okay I'll do that thanks

Tim Beiko: cool any other thoughts questions

um why did why are we defining Behavior

about vertical in an aip46780 when Merkel did not hit minute yet like

Tim Beiko: so we should have standards yeah I agree it's kind of weird yeah

Ahmad Bitar: yeah my my understanding is that if if you want to add such specification it should go into how vertical is implemented not how uh the 6780 is implemented that's just how I think about it

Guillaume Ballet: yeah that makes sense at the same time uh the vertical EIP is already pretty long um so it would typically for I assume

you know people there's a risk that people might forget stuff but yeah if everybody wants it I don't mind removing the entire paragraph because yeah it makes no difference to me

Tim Beiko: anything else on the CIP okay and that was the last thing on the agenda anything else anyone wants to add before we Hop Off okay well thanks everyone and talk to you all on the calls next week

Lightclient: all right thanks

bye thank you thank you

bye thank you yes guys [Applause]

Jesus

Speaker names adapted from ethereum/pm, CC BY-SA 3.0.