RollCall #5

Transcript

hello and welcome everyone to roll call number five that's issue 1025 in the ethereum PM repo uh link to the agenda is in the chat uh starting off we had some discussion points on rip 7212 uh the R1 pre-compile uh the first is that there was a spec clarification um this hasn't fundamentally changed anything for anyone and uh I believe ulash has checked with uh everyone who's implemented it uh to to verify that this

is correct um but basically it was a little ambiguous what to do when a signature uh did not verify and so uh that has been clarified in the rip so it hasn't sub like because this is final we obviously can't change anything there um but this was something that needed to be updated uh the second is there's been some discussion about the pricing of the R1 pre-compile that's so first of all as this is a final rip that means we cannot change anything about the pricing um if we were to do anything

like that it would need to be a separate rip and those who wish to adopt that could adopt that um the reason that some people are interested in changing it at least my understanding is that the R1 curve does not have the same glv endomorphism that you can use on K1 which makes verification uh quite a bit more expensive despite the codes being rather similar so um because of this it might be worth having a more accurate reflection of the work involved and this is particularly true for some of the ZK rollups who get closer to the asmic um costs of these um these operations anyway just a consideration

so we can have some discussions about that and if people really do feel that the pricing is uh not correct then that would be uh worth flagging potentially having a second or another rip in relation to that anyone have other thoughts or additions on pricing or the spec clarification that happened I can make a bit comments here arbitrum team has raised this concern about the pricing of the pre-compile with with this message coming from their benchmarks and the optimism team share

that it's not a big issue for them and if any of the other teams are not very comfortable of the current gas pricing of the contracts as you said we can talk about any proposal and talk about how can we change but in in current situation it looks like most of the teams are okay with the current implementation and for the clarifications that we have made on the proposal only Kakarot team's implementation was incorrect due to the

current spec and thanks thanks to their team we could fastly update their implementation and it's currently merged and all of the rollups are aligned with the current spec and and the implementation and Lesly since for the last roll call the implementation has merged for optimism code codebase already live on polygon main net and yesterday the casing team has launched on their test net and possibly we will have on Main net next week and

Congress to them it's the first ZK ROP Implement they will be first ZK rup implementing the pre compile on on Main Nets great and uh congrats who's deployed things as very cool and I can share one of other concern of the arbitrum team if it's okay and yeah one one one moment just quickly on the pricing again um so pricing is something we've seen change for main net op codes before um it is

something that there there's no right answer for uh particularly for crypto things where there are like many like very different implementations um that are very comparative and when the whole point of a um pre compiles to subsidize the cost of Performing some action on chain um there aren't any clear answers so it's just to to raise that there is a potential point of discussion and if you have thoughts on that it is it would be worth worth worth raising them yes on the the other point I believe you want to talk about yeah um my reference implementation on get use native crypto library of of

goink and they have recently deprecated a function function that checks if the point is on on the elliptic curve and the method is still using in their low level apis and still can be used at the same way in in all package but arbitrum team has concerns that one day v may not be use the this method as it's decate it's marked as duplicated now I just want to raise this Conor F and take attention to different Ro of

containers and you you can consider changing this method [Music] from native go library to another implementation or just I love to hear what what do you think about this replication I mean

the for any any given pre-compile um SL rip the implementation should remain largely orthogonal to um these kinds of concerns uh so it's definitely worth flagging and it is something that should potentially be changed if people are worried about um in their own implementations but it doesn't change the way that the r works yeah and it's just my reference implementation yes we may see lots of other implement even in gets yes exactly yes or not you going to say I

don't I don't know if this is a problem or not but the fact that R1 is slower than K1 can be seen just the pseo code level it's just that there is a mathematical optimization which is called glv uh glv optimization which ASM totically it cuts the cost by 50% in practice it's less and this is why if the same uh implementor implement the two curves uh using the same machine and uh and targets uh K1 will be faster than R1 so this is not really to I am targeting arm Intel or or this

or this is just that uh K1 is faster than Ed which is faster than p256 and the ratio between the computational uh time will be the same uh for each Target it's just that okay depending on the implementation uh one can be can be more efficient but it's it's a mathematical property that you're able to cut by two the the size of the lader on K1 um so it's not related to you can bench of course but um I can also say that when you will have to implement it

in a ZK circuit uh K1 will be faster so I don't have to to wait for the bench mark to know it just that K1 has mathematically called properties that uh enable to have some uh some faster um uh some faster execution yeah sorry if I wasn't clear about that earlier the my points about bench marking were just that there are no clear answers exactly for gas costs but yeah the endomorphism definitely like makes a difference here in terms of of cost any further points on

7212 NOP okay uh moving on the next topic is Rip 76 96 which is a alternative method of achieving um Foster crypto within uh the evm uh particularly by offering a pre-compile for generic um double scale multiplication so I believe um that someone is here on the call who wishes to present yeah uh I would like to share my screen but I cannot absolutely yeah I do need to enable that one stand by one

moment I believe you should be able to share the screen now yeah perfect can you see it not yet I see a wallpaper okay okay I think my PDF reader just crashed okay there we go you can you see it yes okay cool so so rip 7696 is about generic double scalar multiplication which is the core operation for signature verif a but many other cryptographic protocols so this is

what you require if we want to verify either Ed eddsa ecdsa perform steel signature and so so right now we have several different RPS for each time targeting a different elliptic curve so question is why do should we choose for each new use case and how hard would it be to address genericity and this is uh something that we would like to to propose and uh we want to push it progressively so this is why we we perform the solidity implementation uh to provide a proof proof of concept we will compare it with uh the current Uh current implementation and address what it would mean for n and

ziky Z evm so right now we are talking about RP 7212 so there are several uh startups which uh started to build up using AC abstraction in conjunction with P 100 to 56 main mainly for sweet ux so CID CID wallet uh clave which is here demo is a very fair over p256 and smooth which which I belong to uh another use case is using the sgx for the settlement of a layer two so this is something Z sync and scroll and to have been implementing so what happened uh is that sjx previously was

uh implemented over BN curve but uh recently uh it has switched to p00 to 56 which is good if 7212 is implemented but also we should uh notice that um we are really dependent on the gaam choice for um for the choice of implementation so right now uh what the part of fos that is implemented is a p00 256 but we have no clue that at some point they will not do the same that was done from sjx so as uh as for instance uh Ed 25519 is already part of t50 of of F2 um we don't know if I don't

know maybe next year uh we will not be able to sign using p 256 but have to use add uh Ed Ed instead so this is a limitation of Z right being non-generic there are also some criticism around this curve uh it's not transparent there is actually a buy uh to to find the the seed which have been lost uh it's also weak um considering uh a misuse so it's not deterministic why the Eds aspect is um it's not MPC friendly and it's slower than K1 so we just talk about it so what we are pushing

uh so we want genericity it would also uh enable to implement RP 7212 but Ed uh most other more General protocols so ring signature uh Steels uh Steels address as specified in RC 5564 paker Vesta baby juu which which is used in the S circum um framework and actually if you look at what we are doing uh there is many use of of circum but sometime we are using a ZK verifier while a simple uh classic uh verifier would be enough and we are using a

hammer to to crush a fly and also uh if you have double scalar uh multiplication you you can Implement pedon ashing so this mean you you can have a a friendly uh ZK hash function uh because hash function are expensive for ZK ZK layer twos and this is something that will be reflected by The Proposal of increasing the cost in EIP 76 67 uh other use Cas are bridges to other ecosystem stet as is on curve Cosmos Sal so mainly the concern are the code complexity so actually if you want to have a generic curve implementation all

you need is a Mong multiplier um and uh implement the ACCC formulas so this is something that you should already have uh in most library or ZK evm implementation so what 76 96 includes uh there are two Hub codes so if you look and compare it to 7 to2 the difference uh for the first s code mainly lie in the introduction of the curves parameter so p a BN which are um um specific Fields uh for for each curve and uh we propose also another uh precompile uh which taking only uh for

extra values uh enable a speed up which is comparable to glv uh we was talking about so mainly glv is performing for bases multi multi exponentiation and with this extra data uh we can restore performances comparable to what we reach with with the K1 so those optimization are independent of of the language it's uh if we if we look just at the um complexity the number of operation um it would be the same independently of is it implemented in a node in a circuit or in solidity I will talk about the result in solidity

next and um a question I've been asked about why pushing this instead of a full generic MSM uh actually I think uh a full generic MSM might be too too complex to have a chance to be implemented while if you look at the solidity code uh of the proposal it's uh close to 100 lines um so of course full generic MSM is would be superior but to too complex I think for for single RP so last year we we had several results about um solidity implementation so what we want to say now if if we look at the best 7 to12 implementation in um compare

considering the performances uh was reached by fcl last year and what we were able to do uh actually we uh we managed to to have a fastest uh faster implementation that uh what fcl was uh doing uh being specific but for a generic curve so if we can do it in solidity we can it can also be uh transposed uh to other to other languages so mainly what appears on the two last lines are the cost for the two pre precompile in Full full solidity um so for circuit just to give an Insight so there is also problem when

pushing a one EIP or rip introducing a new curve uh each time it's uh it's a pain because it means that a dedicated ZK circuit will have to be um to be implemented by by the layer two so this is something zync has done uh in U uh we have contact with uh with Linea actually they plan to uh to integrate or or solidity which mainly is quite the same as as using uh as using U and uh we we think that pushing something that is generic would avoid to redesign a new circuit each time a new use case or

modification by the is pushed by by the gaffan um yeah so as I said mongy multiplayer is what you need to to implement those it's already coded in gak actually the pushed yeah and and the casing it's it's so what they did to to to implement 7212 it could be uh it could be modified to to be to be generic so that's it because I had only five minutes I think I've done more thank you very much um I have a few questions uh one is on uh you mentioned

using uh providing the extra like four bases for uh speed were possible do you have any insight into the gas of that because obviously then you'd have to supply yeah the the extra points versus the the speed up there yeah so first you can do this off chain actually uh this is what what is done when you provide the public key for your 77 to12 verification actually uh actually you already have to to to make some kind of wrapper to uh uh to transmit from uh um from the result of the The Enclave to to to the blockchain so this can be done offchain so onchain is something

like I think it's 100 20K Gaz which would be a onetime computation but it would be clever to perform to to do this of chain instead okay um the next question I have is how does this compare to something like evm Max um in terms of the the functionality good gain and sort of the gas the gas comparisons you have any thoughts on that yeah it's it's kind of different because we would have to to have a full evm Max uh evm Max implementation is evm Max is more

generic but uh it's not it's not to be used by uh by a non- cryptographer guy it means that using evm Max you can you can design a lot of cryptographic Primitives it's a powerful RP but it's intended for cryptographer I think if I ask you what what would you do yourself uh or developer with evm Max it's it's not it's not obvious so evm max it's it's a very good RP uh clearly if if we had it I I would use it for many many use cases I think that using evm Max you could also for instance Implement um latis latis ltis Bas

Primitives it's a it's another toolbox evm Max it's a it's a kind of tradeoff between evm and uh easm which at some point was a um was a very uh very good project because evm language is uh far from the machine uh which um which is complicated and we why do we need all those pre compiles because we do do not have ewm so evm max is very good it's kind of a trade-off between easm and and evm but I would say that it's it's a lower level tool than a pre

compile so outside of the the implementation issues around evm Max because you obviously have to for example Implement um monom multiplication on chain or like in in solidity using evm Max um so it assuming the implementation side of things was was not an issue I.E someone wrote a really robust uh EC multiply library or something like that um do you have any insight into just sort of the gas cost like how how much worse is it to do to implement like montomery multiplication using evm Max versus to to to sort of emulate this

RP of yours uh I I would need some offchain time to uh to make an evaluation but um yeah I mean I think part of the issue is we also don't have those concrete numbers for evm Max too and if we do they're rather old numbers so it's isn't a fair answer there I was just wondering if you had any thoughts I I could I could I could answer it or not right now but give me one or two days and I will have you the answer that would be really helpful thank you um Doan in the chat asks oh can you repeat the gas costs for R1

using ecml ad yeah uh yeah it's actually it's the same for for any curves so what we had last year was 200k and using the S up code we were able to reach 160k so it's uh 20% less okay right now this line uh was the the fastest uh on chain uh verification first line of

fcl and we can keep the same performances being generic or cut it by 20% uh using the extra um the extra data but this this 20% will be closer and very close to 50% for uh ZK implementation and also at nde level in fact at nde level you should have the same performances as K1 actually ZK because um when you perform a single operation on ZK on a circuit um you have a a very high number of impation just to implement a modular modular

multiplication and um you are very very close to the asop limit so this is uh this is something that we we were able to to measure on stet last year before uh when we started to work on on the Air1 uh before 4337 uh came to ethereum Great anyone else have further questions on this topic all right thank you rard for uh

the presentation thanks idea um yeah I mean the idea of having very generic implementation or very generic ways of doing things is this extensibility of that is very appealing next topic on the agenda is a bit of a discussion of what has been happening on the L1 side of things um there's since the last roll call there's been lots of discussion uh around what gets included in the next L1 for Petra so I'm going hand over to Ana who has some points you'd like to uh bring to everyone's attention on the

alter side yeah thanks I thought it was maybe just a nice addition to roll call to use this perform to to basically give brief summaries of like the the parts of the aquadex procedures that of last month that that were somewhat relevant for for Layer Two so just prepar that for for today so there kind of three five five different uh individual topics I want to touch touch on quickly uh the first three are concerning the upcoming Petra hardw um towards the end of of this year and then two of them kind of are more on the the RO beyond that um so on Petra the the first one um and that's a very recent one is is is on counter

protection so basically um there there there's the E 374 that maybe most here are familiar with that was after a lot like long debate accepted into for the for the upcoming pect fog initially like a month or so ago um there has been quite quite a bit of debate since though because the there are some drawbacks of the AP that not Everyone likes and so specifically yesterday there was a breakout call um on the kind of future of account obstruction on layer one um and now there is an alternative EIP a very new one it's basically just like an iteration of of 3074 called 7702 um and so basically uh I I just want to to Signal here for for people

maybe are not following this super closely that layer one is very likely to ship one of those two um in the in the in the upcoming hard for and so that that we will have basically enhanced EA features um on layer one um and what that means of course is that given given kind of the the just like the the default setting power of layer one that it still has um and and given that EAS of course still make up most of the user base that this will basically create a pretty strong kind of forcing function towards users expecting this functionality so if you're L to you have not looked into this deeply yet I would recommend that you have a look um you basically um have some some sort of um eua to account obstruction strategy in

place um presumably the decision between 3074 and 7702 will be made over the coming weeks so I'll give another update in on the next roll call but also you can for example tomorrow's alod devs this will probably be a big topic so if you want to listen in on that or maybe even come and contribute that that also um is worth it and as a last point on on on that account absortion topic and of course given that the layer one version of of such a spec change usually is like a pretty strong default shelling point for also the variant that ends up lending on their twos and now would be the time to look into is there maybe any modification to the spec that you would want to make it more useful in your context and then come and try to

participate in the lay one governance process around that as well I could IM imagine specifically on the ZK side for example it be really helpful to know if there's like any maybe small modification that will make it much easier to to have that also implemented on the ZK side um so that's on on on on the kind of section front um and and um I'm not sure what how to do this maybe maybe after each topic I'll briefly ask if there's any kind of questions so like if there's any questions specifically on the contstruction now would be the time um okay otherwise I'll move ahead so the second second point I on to briefy mention we already talked on this call earlier about the um what 7 to 12 the1 pre compile but just wanted to

mention that it's now also officially considered for inclusion um for Petra on the L1 side um and that's especially exciting because that would be the first time that some a feature that was first shipped as an IP and it's already finalized of course as an IP and would then later on come to main it so there's a lot of open questions that we would then basically have to figure out and both include both just with the basics like will it use the same EIP number as the IP but also like more interesting things like will L1 use the spec as is will there be some small changes for example you know we talked about the gas pricing these kind of things like if if there are changes basically how how does that impact the relationship between layer one and Layer Two um these kind of

questions they'll all be figured out um in the coming week depending on of course if it actually ends up being accepted for P or not um but again if this we we of course always going I'm usually participating in these all qu calls if I'm trying to represent the kind of the layer to perspective as best as possible car as well um of course if there's any ever anything specific it would be great you know like to to also have have people directly from L to side and participate but again just want to like that um third one the last one that one just a quick update EF um just because that's a bigger change so um if if if you at some point would want to support that that would probably require some lead time that one is still considered for inclusion for pect but is

more contentious so for now I would not necessarily expect it to be included in the hardw but that might change in the coming weeks and if we end up including it then that's also something where at least you should have a strategy around would you want to ship that then as well um of course at some point solidity for example then would start using that as a default um so if you want to still be compatible with new solity versions you would probably have to also support that so Bally at least having some sort of strategy for that in place tracking that I would recommend so those are kind of the the three three main points on on the upcoming pectra for that I wanted to Briefly summarize and then beyond pectra there are two more things one would just be Vries we've talked about this in the

past here on roll call already a little bit but now with pectra mostly logged in also ver verco which will likely be the upgrade um after after pectra basically is starting to be more and more top of mind for people um there there defit is active work um which means that a US l should really probably start to to to have some sort of B strategy like are you going to to to to move over to B as well once mayet does that are you not going to do that like what are the implications so for example for ever being on a different commitment scheme then um St commitment scheme then um then L one these these kind of questions are there maybe again same same topic as with account obstruction are there maybe

small modifications to work that would be really desirable from your point of view so that then it would be more attractive for you to move to and those would probably have to be raised on layer one relatively soon because I think we reasonably soon get to the point of having basically like a more more less spec walk in for ver um so now would be the time to to to dive in and and then pay attention to this um and then the last topic uh to bring up would just be um 4844 and post 4844 block throughput scaling so just as an update we are now what two months or something after the fog roughly we are we still haven't reached the the basically the target throughput um for 44 which means the blobs are still effectively free on

mainnet um which is nice but of course that won't last forever um there are so basically the way layer two layer one thinks about blob scaling is that there will it will basically be a gradual scaling so so we are already working on U data availability sampling which is the technology that will unlock um more substantial scaling this might or might not arrive in time for propecta um if it doesn't arrive in time prop pectra we would just have like a small bump up of the existing kind of numbers to give us a small kind of constant throughput increase over what we have today and and then once we have um and datel sampling in in the form of pias that's a specific technology that we using there

then we can kind of like have probably also gradual as we kind of get experience with that but but more more ambitious kind of throughput increases the reason why I'm bringing it up here I mean for one of course is is that that's maybe relevant for you to plan out your data availability strategy um but also I do think that there's a little bit of uncertainty on the L1 side around the demand levels for for blobs so as I was saying right we still haven't even hit the the target for 4 for before yet um and of course they this has multiple Dimensions one is is the the the the the amount of throughput that existing they are ones that already use on chain da ethereum L1 on chain da can basically can can make use of and but then also

there might be um chains that that that today do not use ethereum on chda but are considering switching over to it but they of course would need some sort of reliable um credible uh path where they can trust that that won't blow back up in in in cost and so having a good feeling for how much demand is there beyond the current levels um would be very helpful I think right now for example I'm I I I keep pushing for this as a priority but like I don't think all qu defs agree that um basically it is a big priority given that we don't see the demand yet so I think basically just voicing clearly voicing that there would be demand Beyond current levels and that that should be really be a priority and that that BS scaling should really push

at the fastest possible speed I think if if you think that's the case right or of course also the other way around if you think that hand levels are basically that that we can take it easy and focus on other things first both of those perspectives I think would be very valid and so basically like making those more visible for layer one I think would be would be very helpful yeah so those was those were the points I had um I yeah I hope I'll keep doing these summaries on the next dra calls if if they're useful um yeah are there any specific kind of questions for any of these these specific points let me see check

um yeah Roberto I I definitely agree um that my assumption is also that that we will basically reach the target probably even before Petra um there will I would say that it's almost inevitable that there will be some small bump up um in in in throughput in pector but it could be very moderate it could be very conservative if if there's no clear signal that that basically more is necessary because it might be preer do so um it would just use the existing technology just basically pushing it a bit more to its limits so if there's no clear signal that there is strong demand that I would expect that the Petra bamp will be relatively small yeah all that makes sense Anar thanks um just just wanted to note um we plan on increasing bases throughput a

bit more because we're we're currently at Target so we're going to consume a bit more of that space and I also see a lot of l2s that are coming online so seems very likely we'll be hitting that Target quite soon yeah makes sense and I think basically the sooner L1 basically actually starts reaching that Target level and the Block Base fee goes below goes goes beyond zero I think the the more likely it is that we get a bit more of the throughput increase both already in pectra but also that we I think that one is not even the one that I'm mostly focused on I think the more important believer here is to what extent the the work on pieras gets prioritized by by clients already today I think to the extent that they feel

that there's um and some some priority that should be put on this we we'll just get there sooner and that's the one that's going to unlock substantial increase okay yeah then that's all for my side thanks Oscar uh um that's all we had on the agenda for today's call uh does anyone have any other topics they would like to discuss before we uh bring this call to

close going once going twice okay thank you everyone for attending uh next roll call will be in roughly A month's time and see you all there um one quick last thing to flag is that uh Onan I will be looking into uh spinning up breard calls again uh after next roll call so if you have any topics that you'd like to see discuss there please reach out to either one of us and yeah thanks everyone for attending thank you