Ethereum Cat Herders PEEPanEIP, 28 Aug 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Peep an EIP #3: EIP-2537 in five slides with Alex Vlasov

Description

Presentation slides: https://docs.google.com/presentation/d/1uN-ziUVXP1xtxEyKc5piHcVnOqcrTk26WIk-fzkbOMs/edit
EIP: https://eips.ethereum.org/EIPS/eip-2537
Discussion at EthMagician: https://ethereum-magicians.org/t/eip-2537-bls12-precompile-discussion-thread/4187/12

Follow Alex Vlasov at Github/Twitter (@shamatar)

Follow the schedule of Peep an EIP for another exciting EIP at
GitHub: https://github.com/ethereum-cat-herders/PM/projects/2

Contact Ethereum Cat Herders at
Discord: https://discord.gg/sgdnxZe
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders

A

Hello, everyone- I am puja and I welcome you all to another episode of p pen e. Today we are going to talk about eip2537 pre-compiled for bls 12-381.

A

This is a standard track called eip and is currently in draft status. It has been accepted as efi for those who are not familiar with the term efi. It is eligible for inclusion.

A

Following the eip centric model efi has been introduced to list core eips and track its progress which, in the future may undergo a network, upgrade to provide an overview and progress of eip-2537.

A

Today we have alexander vlasa, also known as shanta and with him. uh We are also joined by james hancock, the ethereum hardware coordinator, william schwab, and aleta moore from the ethereum cathedrals team. The 8th, magician and link for active discussion and eip is provided in the description below so without further ado. Let me invite alex welcome alex. Let us know a little bit about yourself and then we will dive into the protocols.

B

uh Yeah well a little bit about myself. uh Currently I'm one of uh two co-founders of metal apps and we, uh like our main goal, is scaling um for public blockchains with their knowledge proofs, um as many of or maybe some of you have heard. We have launched our main ad called ziki singh uh back in june and we use zero knowledge, proof, snarks, plonk as a proof system and another israeli pre-compile to actually do our work and provide scaling benefits.

B

um But this is not that relevant. I think for this discussion, but um I would be able to answer any questions later on. If there will be some.

B

So if it's fine, we can just jump directly to the eep description. It should be short. It will not be technical um and a little bit from historical perspective.

B

Initially, I have proposed another eep, which is 1962, which was a totally generic uh set of pre-compiles. Actually it was maybe just one precompile with huge functionality which uh would allow different arithmetic operations over led curves, and the goal for this pre-compile was like make a generic solution which would serve everyone's needs.

B

um But then people had an impression that complexity of such pre-compile is enormous, and that's why it was cut in few parts and the first one and the simplest one is 2537, which is only for bls 12 381 curve. First of all, you should not mix the bls signature, which is quite like commonly discussed construction right now. uh Well, bls curve and signatures um are two different deals uh and only shares the letter b for then banner as one of the resources fire.

B

As far as I remember, but let's put it aside, so the main reason is to um adds a breaking pile which allows efficient operations uh on led curve which uh first of all supports, pairings and has a good paying performance and also which provides 120 bits of security.

B

So this curve can be used uh in a long term.

B

Right now, there is already one led curve which supports spring operations in ethereum in the form of pre-compile, which is bn254 curve and depending on the estimate, it has from 80 to 100 bits of security, which is fine, but since bls 12 381 is kind of de facto standard and is like explicitly named in one of itf graphs for signature schemes for bls signature scheme um decided that this is a good first candidate, um so this pre-compile is quite simple, um but it brings a kind of three different different flavors of operations.

B

One of those like first set of those doesn't involve pairings, and this is just a standard set of operations over points, analytic curve, which involves additions and multiplications, and those operations are already enough for some of the protocols. For example, bullet proofs do not need bearings at all, but still provide interesting instructions.

B

So these observations are like for common use. uh There is also paying operation um which requires curve is a special properties. So this is a main operation which is utilized by signature scheme by zero knowledge.

B

Proof verifications by six improve systems and also there is an auxiliary operation which is called the meptic curve, which allows one to do uh to take a message or a hash of the message and map it from uh arbitrary 32 bytes to the point on lep curve in a secure way, because bla signature scheme requires uh that message should be mapped to the curve point. It is a requirement and this operation is expensive and not well and cannot be well expressed in terms of standard, uh even primitives.

B

So that's why um it was uh introduced as a separate operation and also was introduced as a pre-compile and made efficient.

B

um I already mentioned, like what constructions could potentially use an elliptic curve based pairing properties, uh but let's just go once again throw it. First of all: it's uh everything which uses ziki snarks uh in various pro systems. uh It can be for scaling, it can be for privacy solution. uh Maybe some of you heard about recent zero knowledge based game.

B

uh It's actually, I would say wonderful and you should definitely try to play it um well, as was mentioned many times, the bla signature scheme requires um to have a curve with spring operations. So this can be used to various things like dao governance, just roll ups or plasma constructions, where you have to get the signature from a large number of participants and and verify it very fast and efficiently.

B

It also will be required for cross-chain interactions um like you can verify the validity of the block of another blockchain if validity. Just uh such validity check, for example, just requires uh a simple signature from majority of the validators. This idea was also a part of um like having a light clan for east 2.0.

B

When east 2.0 is launched uh as a smart contract for east 1.0, so it would be possible to get the data from east 2.0 beacon chain and refer to it from ease 1.0 and that's also kind of freaking kind of very good feature for east 2.0 deposit contract, because it allows a user to opt in uh to the validation of his private public, key that it's well-formed.

B

So when he does the deposit from east 1.0 to 2.0, he will be able to access his funds in east 2.0 so that there is no problem that his public key is not well formed. So this there would be no possibility to make a signature for such public key, so the user was user would essentially lose his funds.

B

um It's also used in more recent constructions like randomness beacons.

B

An example is grant I'm not that an expert in this field, but it's usable- and I think on-chain randomness- is another important deal and also another part is constructions which for now can be considered r d and those, for example. A recent.

B

Paper for vector commitments and which can be used, for example, for witness compression in, for example, ease, 1.5 or whatever next upgrade of yeast would happen and require this feature.

B

So, let's get to the current state of affairs. um So at the moment this uh pre-compile is included in the code base of all major es, 1.0 clients um and, if like, if someone would want to make me a signature uh and do just anything using this pls 1231 curve. There is a huge set of libraries which allows to do it for various platforms, various languages and also various licenses in case it's also important. So this curve is indeed de facto standard and there are a lot of tools to work with this.

B

After integration, there was a fuzzing effort from guest team to fuss the implementations between different clients, because clients use different libraries to actually implement what is required by cpr compile um the interesting part. There is even while, initially uh people uh viewed this freaking file as like, very complex and intensive mass.

B

There were actually no errors in mathematical part um of all this code, uh but they were, but the only errors found during the washing process were integration. Errors like people didn't place uh proper constants in uh gas calculations functions. People didn't handle all the errors properly.

B

um So, as it happens, uh arithmetic parts and heavy mass wasn't a problem at all. So for now the status all the clients have an implementation, and the only thing which is left is just declares that this precompiled is included in berlin and, like uh put like, have a berlin at some point, um and so we just activate it everywhere, and that would be usable by everyone.

B

So it was indeed in five slides. uh So I can uh stop the screen demo.

C

um And uh I actually keep it up alex it's helpful.

B

Okay, yeah and.

C

It's also, I wanted to say it's it's great working with you on the awkward f call so I enjoy when you come on, and I help your your help and perspective is always it's really.

B

uh Yeah, thank you, james. uh Okay. I will also put a set of people because I don't recognize everyone by voice so.

C

Oh yeah um uh go back a couple slides to the one where you talk about who needs it? Yes, so can you so the cross chain interactions with eth2 file, coin and tesla's? How is it because you're you're you're using the same version or how does that? um How is it that it enables this kind of cross chains.

B

uh Well, it's more or less gets to the point how one can verify like validity of one chain in another chain, so as an example in east 2.0, it would boil down to verification of a signature of bls signature. Well too many bls here, but the verification of bls signatures of validator set uh over the block header, and it will allow to attest to ease 1.0 that this header is part of the canonical chain of ease 2.0.

B

Well. This applies in principle to any proof of stake or proof of authority uh chain which would use uh pls signature over this curve uh as um like as a kind of a seal of a main and valid chain. um I hope I try to explain it. uh Yeah.

C

B

C

You, if you can verify on your chain the validity of something, then you can consistently interact.

B

uh Well, yeah I mean if the chain construction is more or less following the standard pattern, that there is some state which is effectively miracle roots of a set of uh contracts, uh each of those having its own balances, and also there is a miracle root of set of transactions.

B

Then you would eventually be able to just walk along this merkle tree and, for example, say that well in this blog, there was transaction with these properties, and this would allow.

B

Some kind of the same as uh uh you would most likely just deposit in east 2.0 that there was some transaction with some properties. So there was some set of funds locked in is 1.0, so it can be released in east 2.0, but all particular nature of interactions is up to some developer. First of all, you need to attest that this block is a part of canonical chain.

C

Yeah so this, but this puts the building blocks in or the legos to allow this kind of stuff to happen.

C

Sorry, this this this puts in the legos or the building blocks for people to be able to do these sorts of things.

B

uh Yeah, it's like such precompiles are not solutions for a particular problem. uh It's more like a tool which allows a large set of applications like I am huge fan of snarks and also randomness speaking, but in randomness part. My knowledge is much more limited.

B

I was only more or less following the construction by rsa uh refinable delay functions and how it's incorporated in randomness generation but looks like there are other solutions which are kind of simpler and would also want to uh have a bls curve which is required for them to work.

C

Yeah, um let's talk a little bit more or I want to kind of get people who are users of the chain or developers of the chain, a sense of when you say it enables zk robes and privacy. How? What does that kind of benefit translate to users or to the people.

B

Well, this part is a little bit more technically involved, uh but, as I like, as I made an example, there is already bn254 curve uh which allows springs and which allows you snarks using this curve, and this is what we actually do. um So I try to put the word capacity here.

B

To make it simple, um when you make a certain knowledge proof, you have to express the statement. You are proving as a circuit, which involves at the high level addition and multiplication gates so and to be able to run the efficient prover for such circuit. You need to have a set of routes of unity uh in your field over which you work, you like, usually the circuit is expressed towards prime field in this case, and roots of unity is a property of the modulus.

B

In case of current curve, there are 228 roots of unity, the maximum size of the circuit. So if you, if, let's say you have, uh if you try to process transactions uh using zero knowledge circuit and each transactions takes, for example, one million gates- and you only have access to the maximum of 2 in 28 gates, um then the largest amount of transactions which you can process is around 256..

B

uh This is 4bn254 curve. The pls 1281 curve has two in a power of 32 rods of unity, so it's four times larger um and it allows you kind of batch more transactions in one zero, knowledge circuit and verification costs for bn and bls 1231 curves is roughly the same. So at the end of the day, when you do all the calculations, what is the final cost? uh You will get that you can guess like four times the compression for the same amount of gas required uh on chain to verify the proof.

C

So and so in this case, efficiency translates into cheaper gas for users.

B

Yeah, if you just divide the total gas spent to verify the proof by the number of interactions or like transactions, which you can verify by one proof, uh you get uh like four times in the efficiency in.

C

This example so- and this would be in like a layer, two sort of something so uh so that would also end up being cheaper.

B

uh Yeah I mean this was this: would translate to uh layer twos having larger capacity per block, uh so if effectively, it would decrease the costs um like, but I mean for later to use. There are other um uh costs consideration, so it's more complicated, but at the end of the day, if you run it full capacity uh and you just send a lot of proofs for verification um and you do it almost every block, then at the end of the day, your costs for end users will be four times smaller.

C

That's pretty good, that's it. Let's see um is this, is it is the privacy solutions kind of the same thing like it's more efficient or cheaper to do privacy solutions like a like? uh What's the tornado cache or something like that,.

B

It's I mean for now well, for if you want to put an example to another cache here, it's a little bit more uh technically involved. You would want to run the recursion, um but it's kind of the same like no matter. What is your construction if you use their knowledge proofs and you want to place like and if you want to prove the larger statement or to prove the statement over a larger set of like small, simple chunks and substatements, it will directly translate to savings on the cost.

B

uh There are else a few operations which are not uh available for bn254 curve, which is multi-exponentiation, uh which is simply uh doing a lot of individual point multiplications and then adding them up all together.

B

If you use special algorithm for this, you get huge discounts, and such operation is a part of many verification procedures for zero knowledge proofs. um So I would imagine that even for them, it would be an immediate like immediately benefit them for verification, um and then, if they decide to go into recursion, then the same capacity argument would else apply for them.

C

And recursive snarks is something that this bls or this bls version is.

B

In principle now you can choose a recursion over just one and one curve the same curve. um The problem is that it's more computationally expensive, so there are trade-offs. um So as a recursion argument, doesn't kind of this curve is not strictly for recursion. This is de facto standard curve for all interactions listed here, um but um if you want to name it, there is another eep which is 2569, which is bls 12, but 3 377 curve a little bit different. One like the only thing which is largely different is the modulus.

B

A prime number, which defines a field over the curve is defined. um This curve is also known as a sexy curve, and sexy construction is uh like from the sexy paper and we go in deeper and different technical details. Yeah this curve is like is uh like recursive composition friendly because it allows various tricks to make recursion cheaper, but uh I mean we can go deep. We can go in this direction if you want, uh but I don't think it will be useful, uh we'll just scare people away.

A

C

But but so just at least so I can be clear on it. There is your bls version, you're talking about. Would it enable something like 377 to happen later or how related would that be.

B

Well, uh from my perspective um and like from implementation of one curve or another uh bls 377 proposal is like copy paste of 381 proposal, everything will be the same. Api will be the same. Gas cost will be the same. All error k, you know, like all edge cases and errors will be the same. The only thing which will change is roughly four equations uh in the implementation uh which are um like, and these equations are usually not even hardcoded they're, just parameterized in the source code.

B

So if this one is accepted, the modification for bls377 will take, like maybe 50 lines of code, uh to like provide an implementation for a 377.

C

B

Will not even change external interfaces and clients will be would be immediately able to integrate it. So just from a perspective of how it is implemented in code, there's a small change of parameters, uh so nothing will change for external external server, but it's like it would be an asset building block for uh various constructions.

B

This is this like the various options. What you can do now in the in area of zero knowledge pros, there is smaller set of options. What you can do with their knowledge pros in ethereum, so what I try to do is gradually increase this set of options because for now, for example, if you look at the zit cache, uh they're not limited by free compiles and the users can use any crypto, they want and then, and they can use very interesting constructions like halo.

B

If you look at the coda, um they also recently introduced their approach for efficient composition and like set of smart contracts, which would be possible with just purely certain algebras. um So it's kind of extension.

B

I tried to extend ethereum to support more and more primitives, which would eventually allow me and other people to build something which I cannot maybe imagine right now. For example, zero knowledge games are great. um I was proposing it for some time ago. I think first on zero knowledge summit last year, but I'm happy to see that someone has built it.

B

So it's more or less a long road anyway,.

D

So I have a quick question. um You said that ethereum, the zero knowledge proves ethereum is like limited a bit and I'm wondering well first off, why and like how is it different in ethereum um like? How is this implementation different from say, you know, z, cash or something like that.

B

um It's uh limited in the sense that um well, first of all, such computations, uh like an amount of computations required to calculate the print, is quite large. It's few milliseconds.

B

If you run the native code on the recent cpu, which transforms to.

B

To tens of thousands of gas in ethereum and like if you want to try to implement it in an evm code, it will be prohibitedly, prohibitedly, expensive in some cases and insanely expensive. In other cases, like all evm premier, primitive types are 256 bits.

B

It allowed uh zak from adstaq to actually implement the same bn254 curve, which was available in ethereum as a precompile.

B

He implemented it as a evm contract and it had decent performance before bn254 pre-compile was repriced because implementations has improved, so the gas cost was uh reduced versus precompiled for uh bls, 12, 381 or 377 curves, it's even more difficult because they have to work over numbers which are uh 381 bit long, so they don't fit in a single ethereum uh unsigned integer. So you have to do more and more tricks.

B

uh That's why implementation sounds like this as the evm would be expensive and it would be first of all difficult and then it would be definitely more expensive than if you implement it in a native code as an example with bn implementation show and no one wants to pay a huge amount of gas for any interaction. So such implementation has to be efficient.

B

That's why it's usually implemented as a pre-compile, which is just a native code, which is just a function uh which is executed in native code and just reached back to the evm.

D

So have we ever considered um if I understand how how it works correctly, um we ever considered doing like sacrificing some of the benefits of uh touring complete, like architecture, for the benefit of like the the more complex, uh zero knowledge proofs. This doesn't mean to be considered.

B

B

Like I have to at least to improve the interpretation of this question like zero knowledge process as they are uh in terms of their knowledge circuits, they are not turing complete at the beginning.

B

So if you consider their knowledge proof over some statement, the form of the statements for zero knowledge proof to be efficient has to be certain bounds.

B

This is part which is purely for their knowledge pros, uh which can be over different proof systems and different curves.

B

But then you get to the point where you have to verify this proof and in most of the cases which we discuss here, verification happens in ethereum, so ethereum itself should be able to do the computations which are required to do the verification, uh and these computations uh right now are uh involve running bm254 pre-compile and later on. They would be able to use this pls-12381 curve, which else is lc pre-compile.

B

So this part has to be run in the serium and has to be as fast as possible so and right now there is only one curve uh there may be there. Maybe will be two uh in berlin, uh but those two curves are not the only curves and constructions possible for their knowledge probes.

B

There are other curves which we don't discuss here. There are other proof systems which have some different tradeoffs. They can trade off bandwidths for speed, for example, and not all those uh kind of interactions are reasonable to have an ethereum.

B

So if you're like in most of the proof systems which are considered to be efficient in ethereum proof, verification is a procedure which takes a constant time, no matter what is the size of their knowledge circuit?

B

There are other proof systems which has which have other asymptotical complexities, for example, in which proof verification is a procedure which takes a square root complexity over the circuit size or even linear complexity over the circuit size and those are not usable in serium, but has other benefits.

B

That's why there is a larger landscape, further knowledge proofs, which is used by other chains, but we discussed ethereum only here, so we try to bring the constructions which are reasonably efficient from both perspectives, uh running in a public blockchain, which is important and also not having a full kind of uh power to extend this public blockchain. In any way. You want that's why all those precompiled inclusion procedures are quite slow.

B

Even while there are other constructions in the wilderness, uh which are also very interesting, but they will not be usable in estonia um until uh more and more pre-compiles are introduced or until something like uh 1962 is introduced, which allows any curves any functions and also high performance. But it was considered to be too difficult to include.

B

Even so, there were three independent implementations which went through the fuzzy testing and didn't have any divergences, and also with a full spec to reproduce, but uh still wasn't sufficient as it happened.

A

So uh talking about berlin, I'm I'm curious to uh have a little conversation about the latest evm 384 that came up in our last all core dev call. So would you be able to elaborate on like how is it going to affect um yeah eip2537 before.

C

Before we jump into that picture, can I say one last thing about this: that it seems like there's a wonderful world of zk lots of things that ethereum and the community could use and we're limited, because the building blocks are either missing or too expensive.

B

uh Well, ideally, you should separate it here. A little okay like there is a huge set of possibilities.

B

uh Some of those are better suited for steering some of those are not well suited for ethereum, for example, um size of zero knowledge proof using pairing, friendly curves, as let's say, a few kilobytes, which is reasonable and verification uh takes constant time and, let's say, half a million gas which is also reasonable.

B

So it's kind of cheap.

B

There are proof systems which have a larger proof size, for example, starix, where a single proof verification would take a kind of like counting together as a proof, size uh and running the contract, which does verification which takes 5.5 uh as far as every member billion gas um for one block. So this is this feeds into the block but more expensive, as there are proof systems, whereas the proof sizes would be even larger, so those are not suitable for serum.

B

We don't consider them, but even in a subset of those which is suitable, uh there is variety of choices and those different choices would require different building blocks. Some of those are present in the serium. Some of those are not present. In this room, and even while some blocks are present, there are better options of this box, for example, kind of for bn254 curve and this bls 1281.

B

um So this is kind of the separation.

C

I think that's really helpful. I can see I I see more of the the expand like the vision that you're expanding the possibility for what ethereum can do like.

C

B

C

B

C

Have people like you pushing pushing things like this, that they do get involved and are sure.

C

uh And then and then uh pooja uh your question on the evm 384 eip2537, it came up on the last call and you have like a space to respond. Instead.

A

Yeah right, so I was curious like how is it going to affect eip2537, like with the discussion uh in the previous on code? F, call, I'm not sure if it is like uh how we are going to take. Are we considering both or how is it going to affect? Can you just let us know pros and cons of this versus that.

B

Yeah, I mean uh I definitely cannot answer how it's going to affect, because I'm not the person who does a decision, but from what I've seen. I didn't dig very deep. So there are maybe some other factors which you don't count right in short right now, the performance difference as a factor of three, so this would affect um like anyone who would we who would want to use uh and like a curve like the last two 381 implemented, either in native code or using this new op codes.

B

So it would force people to pay three times the gas. Also the compression which was present there um like it, was between kind of generic implementations uh of both, which is a reasonable comparison.

B

So if people would start to do optimizations on both sides and they go to the extreme limits, I think the ratio will stay largely the same, so it will be uh three times lower cuts, no matter if everyone goes to uh all the way down to assembly to implement basic operations.

B

So I believe that the ratio will be somewhere around factor of three. I also didn't look at some internal parts of this comparison, because there are operations which could have like uh recent benchmarks for evm opcodes. It's not exactly the paying operations being implemented.

B

It's kind of the simulation of this uh by operation counts, so it's like doing the same number of operations, uh primitive operations and to see how long it takes. So there is no implementation. There is no full implementation there. There is no control flow and I don't know how it's how difficult it would be to implement it. So it's still in research.

B

There are also other parts which, for example, subgroup checks, which I know how are implemented in 1962, which was a baseline for them, and I don't know how they were simulated in evm uh opcodes, and this reason is this. Difference can also be quite substantial uh because they take some like up to 40 percent of execution time.

B

uh So we will see how this progress goes, but my prediction is more or less it will be penalty for end users uh from performance perspective somewhere around the factor of three. If someone would want to kind of force uh that such operations would be implemented using uh new op codes instead of native code.

C

And a more penalty on performance translates to higher gas costs.

B

Oh yeah yeah, I mean uh I, I thought this was kind of obvious, but yeah I mean if we assume that any second is some amount of gas spent, then yeah it would directly transform into higher gas cost for any.

A

Operation, thank you um and like. I hope that this comparison would be uh coming up soon and we we will get to know like how is it going to go ahead like evm 384 or this one or both.

C

Well, I I can give my prescription uh perspective on that puja for at least from the hardcore coordinator side. Yeah, please go ahead. I think evm 384 is a good direction, but is it a reason to delay other good things? So I I don't think anyone's decided anything uh that I that's kind of where I I view this as another good thing that is pretty far along and can benefit and give value to both devs in the in the scope of what things they can do and users in that it's cheaper to do things.

B

uh Yeah well, it can be. uh I mean for this particular choice of um like I I don't know, what's happening with the hardware coordination in a sense. Is there a plan to have it at some point?

B

Is there a deadline to have it or you can delay it more and more until all these results, but which um effectively leads to like not having features which could have been there already, but, um like purely from a technical standpoint, maybe it's kind of useless for 384 bits, uh but it can be usable for other cases like uh for 384 bits. As it happens, um there is definitely in an overhead uh in crossing a boundary between the evm and the code, which actually does point, uh does uh field addition or montgomery multiplication.

B

uh But if you go to the larger field size, uh for example, let's say twice larger: this ratio would will definitely change and maybe for field sizes which are roughly 700 like 768 beats. Let's say uh this ratio will be such that an overhead will be not three times. Maybe it will be 30 percent and then it would definitely make sense uh to have a universal solution over particular ones. Maybe just not the best choice for 284 bits, uh but uh it's kind of another level of research.

B

uh I don't know if people uh working on this, especially axi, will have a time to try it uh in a short term, but uh maybe it would be uh kind of a niche for such uh implementation using the op codes.

B

That's I didn't like it's just my idea. She just had.

A

Cool yeah that time.

C

Oh, that seems good to me guys. This has been a really awesome conversation. Thank you alex.

A

Yeah both of you thank you, alex. Thank you james. uh This. This was really an interesting conversation and we get to know more about this particular eip. With this program, we are hoping that it. It would be useful for community to learn and ask questions directly from the author. So that's what we are trying to achieve here and I I think that we have achieved some of the questions that we received has been answered.

A

So I thank you all for joining us today and with that we have reached at the end of the episode. But, as I understand there is another proposal authored by alex, which is under discussion for berlin, uh that is eip2666.

A

So I hope to uh see you again on this show to learn about proposal uh and for those who are watching us on youtube. I hope to see you all in another episode of fifa eve with another puzzle.

A

So if you have any protocol that you would like to understand or ask questions with the author, please comment in the comment section below and we'll try to invite the eip author on our show. Thank you. Everyone for joining us.

C

um And alex, where would be a good place to for people to follow you or the research of matter labs if they're interested.

B

um Well, we're not that active on social media. There is a like on about on our website, which is easy to google. There are links. Well, there is a link to the github channel uh and usually when we have something we write a blog post um but like uh all the work is happening on the github and like we're not that active on social media but yeah. You can just try to find us on google, uh some of the metal apps.

B

You will find it easily and you can check the materials and a few hours blog posts with quite a like. Three of them were quite recent on medium um other than this, like, I don't think there are good sources or, if necessary, like uh you, can reach me in, like in private message on twitter or in the discord. uh I have the same handle everywhere, so you can just pm me if something.

A

Yeah, we will add that in the description below okay. Thank you. Everyone. Thank you for your time have a great day.

B

Okay, thank you. Everyone.