The Michelin Guide for CROPS

Transcript

[music] [music] Hey everyone, I'm Luca, uh, head of research at L2B and yeah, I will be talking about the Michelin guide for crops. Um, but before starting, I have a quick announcement, a quick but important and very exciting announcement. Um we're rebranding L2B to ETHB. Um thank you.

Um we started uh more than 5 years ago with twos. Uh when back then um the idea was to uh scale Ethereum with them. Uh scaling Ethereum meaning uh scaling the trustless and permissionless properties uh that Ethereum provides. Uh back then this idea was so exciting uh that Ethereum road map was kind of uh designed around it where Ethereum itself uh the L1 was supposed to like shrink to almost nothing to just uh consensus verifying L2 proofs and it availability and all the users were supposed to move to the L2s. Um this uh of course turned out to be very difficult uh because the

tech is difficult to build. Uh so the diesel 2's launch with training wheels. We track these training wheels. We um developed the stages framework uh to to track them. Um it took uh way more time uh for these projects to go to stage two uh which is what we wanted. And you know this still hasn't happened uh with exception of a very few projects. And in the meantime Ethereum has evolved and decided to scale itself uh not to rely on diesel tools uh but use the same technology u like ziki proofs and data availability blobs for example uh to scale itself. Um in the past year um you know we've built a lot of tools uh to review diesel tools over

the years and especially during this past year we have expanded uh the things that we track uh using this same tooling um that are open source and other people are also using. So for example, we've added interrop uh to our website because um for example, it doesn't uh it is not useful for users if uh an L2 is stage two but then all assets are bridged using third party bridges for example like layer zero or CCIP. So we wanted to explain uh to those users you know the different trust assumptions of the other bridges that you could use to bridge to 2. Now we're tracking almost every bridge uh or at least all the major bridges uh like CCTP layer zero uh all

the conical bridges of course the hyperlquid bridge uh and so on and providing the full risk assessment for all of them. You might have seen this very cool animation. Uh we have expanded to tracking ziki provers because you know it's not enough to say oh diesel 2 has a has ziki proofs but you know what are they actually verifying because it could be you know you cannot treat this as a black box. They might verifying you know sudoku puzzles. Um so if you look into it so we started tracking them looking into them if they're reproducible verifiable uh what the trusted setup that they use. uh what is the proof stock that I use? uh we have expanded to tokens uh now on L2 uh on Ebit I would say right now um you can search any token and you're able to see

what are the trust assumptions of any of those tokens that uh you can hold um on Ethereum on all these other chains uh mainly like uh who can mint these tokens um how they're bridged so you can know the trust assumptions we've expanded to privacy I will talk more about this uh later and we will soon expanding to uh liquid staking tokens. This is a big debate in Ethereum, you know, with the issuance debate and um and this is like there are a lot of tokens that are in in LSDs and uh we're starting to looking into them as well. Um, most importantly, we have also a mandate, uh, the ETH bit mandate. Um, and if you

go check it out, uh, it revolves around this intermediation. Like we see ourselves as um as um a company that tries to um focus on this intermediation as the main way to protect individual freedom. like um I don't think it makes sense for us to focus on on those technologies uh that are not focused themselves on this intermediation. uh I don't think those applications you know are very well suited for blockchains in general and we will try um to to check um all those applications that actually help people preserve their individual individual freedom to uh this intermediation and on this uh to the Michelin guide for

crops. So in the same way uh that the Michelin Guide tries to um promote um is yeah tries to promote like restaurants that uh distinguish themselves and you know it's a very effective guide I would say a very reputable guide uh we started to think you know can we do something similar for for crops to uh make people more aware and promote these applications uh that allow for this intermediation and that upfold for the values of crops. What is crops? I hope you heard about this many times already. Uh but it's important to stress it every time. CR for sensorship resistance, O for open source or openness, uh P for privacy and S for

security. And I will be explaining uh what is the work that we're doing as ETH bit uh for all these things. Um so censorship resistance is uh one of the like first topics that we um have ever researched uh at Alto bit in the context of centralized sequencers uh in L2s. Uh we always stated it's very important to to provide users with a with a force transaction mechanism for example uh to pass the centralized sequencers and we've studied them for years. Um we have like very deep research uh on all these projects on all these L2s. Um it's not enough to have a force transaction

mechanism because they differ in practice. Uh some of them you know might uh give you a delay of uh 12 hours for example in the case of OP mainet for arbitum one it is 24 hours. Um it is actually more complicated than this because they have a buffer. Um, none of them basically give you real-time censorship resistance. Um, and Starknet, for example, it's even weirder because there is no force transaction mechanism. Um, and you are supposed to go to the security council like if it's a sensor, you're supposed to like contact them somehow, maybe a tweet. Uh, which is kind of, you know, uh, weird. Um some of these project uh have been tolding us uh telling us that

you know for instruction mechanism might not be the best way uh to provide users with sensory resistance because they need uh most of the time these mechanisms need a delay. So some of them have suggested using decentralized sequencing. Instead we started tracking uh all those uh as well there are not many of them uh there are you know these are the few ones Aztec noses chain and polygon PS and we have very in-depth analysis about uh what it means to use um the decentralized sequencer whether they actually give you some significant strip resistant properties right in the future uh it will become like the discussion about censorship resistance will become even more complicated

uh because on Ethereum itself uh different applications and different users might get different level of censorship resistance. So for example, Fossil is an upgrade that is uh already scheduled not in the next upgrade but in uh the one after and this uh is supposed to give you like a force transaction mechanism to bypass the centralized builders. We knew that you know we know that in Ethereum um this has happened that builders have sensor for example uh of transactions. you might be able in the future to use this mechanism to bypass them. The problem is that uh not all transactions are eligible to go into these inclusion lists. H there are like stricter requirements and not all applications uh you know might be supported and in the

future you know we might want to uh explain and expose um what these applications are uh in Ethereum itself, right? uh there will be frame transactions uh that will extend you know the capabilities of accounts and these um it will get things even more complicated. there will be more applications that are possible in Ethereum. Uh but also um it could be you know that the percentage of applications that are eligible for this higher level of censorship resistance is lower. Then we have open source as I said we've been tracking um we you know we're trying to um cover all the smart contracts of these projects that we track. We expect

all of them uh to be uh verified on explorer right now. It's also easy to like reverse engineer the by code but that's another discussion. This reverse engineering doesn't work for example for zikk provers because if you have a zk verifier on chain you just see a verification key or a program hash and this is a hash like you cannot reverse engineer it right so it's very important that all these things are verifiable and we try to reproduce the verification key and the program hashes that we see on chain so that we make sure you know that what is on github actually corresponds to the thing that is on chain and what the ziki proofs are actually verifying.

We have found cases in which uh it was not possible to reproduce the verifiers. Uh we discovered a while ago for example in semaphore which is you know very popular uh zk application uh that uh there was a bug in the circum compiler uh that made verification keys nondeterministic. So every time you compile the same code, you get different verification keys and there was no way to to like uh prove that these verification keys was about semaphore and not something else. Uh we disclosed this problem. They had to do like another ceremony, another uh deployment uh which was very fun. We provide you with all the steps to reproduce it yourself so that you you don't have to trust us. So we have this like huge

database of you know uh reproducible steps of how to to do these things. This is for example tornado cache. Um and many times these steps are not available but only available on our website. We look at the trust setups. Uh sometimes these trust setups are small and not secure in practice. Sometimes it's just one party and if this one party is malicious they can forge proof in funds. So we also track the size of the trust setup and the ways to verify this trust setup. Privacy is a very big topic uh for us. uh we are tracking all the major Ethereum protocols that provide privacy.

Uh they have you know different flavors not all Ethereum protocols we're also tracking um protocols outside of Ethereum like Zcash and Monero but from the Ethereum perspective like I'm an Ethereum user I want to use Zcash to like I want to bridge my ETH and somehow go to Zcash and then back to ETH uh using for example near intense uh or some other services. We're tracking all these way that Ethereum users could get uh privacy and we're tracking uh many different aspects uh of this uh privacy protocol. So for example, not just the onchain part uh not just the contracts but also uh the network leaks. Uh and to do this uh we're also tracking for example their wallets. Uh one thing that

we um one example, one very fun example um to to show you like how deep we go into these topics is this Zama explorer that we built. Zama is a fullyomorphic encryption project that tries to build these tokens uh that you can send without disclosing the amount. But actually if you think about it, if I deposit into the Zama protocol that uses FHE um and they encrypt the amount, I already know something about it. like I know that the amount cannot be more than what I deposited at the very beginning.

So I I have an upper bound, right? And if you if you actually track all these upper bounds and sometimes lower bounds and you do like linear equations uh on all these encrypted value, turns out that a lot of times you can actually decrypt exactly what is the value that is being sent. And we built like a full explorer showing you uh and uh showing you these values or like very tight bounds that is possible to derive using linear equations and similar techniques. Um we've built another explorer when looking at pay pay ad uh pay is a project that was hacked recently but before being hacked um they had a card like a physical card and they were promising private transactions. We found that these transactions are not private

at all. you can link uh all of them and we built an explorer showing uh all the connections like between depositors and withdrawers. Uh then they got hacked unfortunately uh for unrelated reasons and as I said uh before um just looking at what happens on chain um it's not enough because the way that you access this protocol is as important if not more important. Um we're tracking this is for example our wallets or front ends for rail gun. Rail gun is one of the most popular privacy applications on Ethereum right now. Uh we believe that rail oxide is the best one. So what we do is we check all of them. We pick what we believe is the best one and we

explain why the others are worse and then uh when we do the rating of the application we do it uh through uh the best wallet and it happens that the best wallet also has problem in rail oxite. found problems regarding circuit isolations uh leaking TLS sessions in the in the TLS headers. Uh we found that for example if you have multiple accounts to check the balances they do a batched RPC call. Um and this is this is what we're working on. We're tracking anonymity sets because even if everything is perfect if the anonymity set is small uh you don't you don't get any privacy uh in practice. Uh and again you can find uh all these metrics on on ETH bit. We started very recently uh to

look at security and security is like super tough because like uh of course like no one knows about bugs, right? Like so the idea is can we get any metric or like anything that can give people some idea about the security of a system and the very first attempt that we tried um is theification. So right now there is this page that tracks how much oified a project is and we give this ocification score. Uh for example unis swap p2 is 99 tornado cach is 98 and rail gun is 60. What does it mean?

If you have a score of 99 it means that historical exploits um um have happened on younger code. So for example 99 means that 99% of exploits have happened of on younger code than this project. And to do this we have a huge database like we're collecting uh all the exploits that have happened uh how long they have happened uh since you know launch and this is how we we're defining this score. This score can change uh if we add more things if we get more points in this data set. uh you can find a GitHub repo uh where we contain and continuously update uh all these data uh all these um yeah all the

data set and the second thing that we're still working on this is not yet released is to look at audits and audits are a mess are a complete mess um it's the idea here is to try to see um what the audit is actually saying um sometimes Sometimes the audit for example doesn't specify what are the files uh that are covered within the audits. Sometimes it doesn't specify sometimes they don't specify the commit uh that they point at. uh even if they do an audit might not cover all of them and you need to track like okay this audit tracks like half of the code this

other audit tracks the other half but these are like in different point in times and when you audit the second part the first the first part might have changed and then sometimes there are findings and sometimes these projects do the fixes but they don't audit the fixes and like trying to um trying to understand whether a project is fully audited, it's like extremely difficult and right now our sentiment is that no project is audited on chain. Um we always find differences always. Uh this might be like issues within our methodology. Uh we're like trying to automate a lot of things because there are a lot of files. Uh all these PDFs are not machine readable. So it's difficult. Uh but we always find some

differences. Uh people assume for example open Zeppelin libraries are always okay. uh and you know like audits are missing sometimes in in some of them and these libraries are very complicated. This is like Merkel 3 library using uh used internal cache and this is an example of a diff we have a page like we will release a page eventually uh showing you all the diffs that we found uh against the audits. Um and you know after uh all of this after we check all of these things there are some projects uh that we found good in all these aspects and this is our Michelin guide uh our Michelin guide to crops. This is the uh this is live right

now. Um this is the very first list of projects that we believe deserve to be in this michelan guide. Um it's a very obvious uh list of projects. We have tornado cache. We have Uniswap V3 uh the safe multig and unus V2. Um you can see uh we assess all of them using these flowers. All of these are green except for privacy of the bottom three because they're transparent. So they get a transparent flower. Um, and we wanted to have this obvious list of projects at first because uh we want to uh kind of give the sentiment um that uh of the high bar uh to get in

this list and we want to we will add more projects but most importantly we want your project to be here. So if you're working on something on your applications and you believe uh that you're following these values uh the crops values please reach out to us. We will have we have a form on the website uh and we will check uh your protocol and add it here if it if it passes. That's all. Thank you very much. Thank you. Can we we got some uh pretty much a lot of questions. Can we get the mir cat on on the screen? Uh so first

two questions are related uh on the eat bit being a very important public good. How do you get your funding? >> Yeah. So this is the most difficult question for us. Um historically speaking uh we've been uh mainly funded by the Ethereum Foundation directly. Um in the past um we had what we have called the um an ecosystem partnership where uh the L2s were very excited about us like tracking their progress towards stage two and the centralization. So we got this ecosystem partnership where they um funded us. uh they were very happy to fund us. Uh the

problem is uh like over time while we you know stuck to the principles they didn't uh so you know we kept uh saying bad things about them uh in terms you know within the framework that we have so this has not continued and as of now um again this is this is the main challenge for us uh but mainly today uh is the foundation. >> Cool. Thanks. We're open by the way to [gasps] [snorts] to other source of funding.

>> So the next question would be I guess uh what's the latest update on supporting native rollups? >> Yeah. Um on native roll-ups the progress is very good. Uh I opened recently a new EIP uh that allows for native roll-ups. This is extremely simple uh because it's just a registry an append registries of verification keys. So the idea is um when Ethereum itself will have its own ZK program it will have its own verification keys and the idea is uh let's save this verification keys on chain and every time that there is an upgrade we will append the new verification keys so that projects can

just reuse whatever is in the is in the registry. Um this is like relatively simple uh the part that requires a fork. All the things that don't require a fork um are already resolved like for example how do you support L2 functionalities using the same state transition function as L1 stuff like deposits and withdrawals. This is solved already. The main blockers for native rollups are basically um they require the uh so we need lean VM work to be finished. uh we need um 8288 which is this uh lin stark transactions to to be made available on mainet. Uh this requires frame transactions. Uh but

there is a devet right now. You can visit native rollups.fyi. Uh this is something that I'm running myself. It's uh half mocked I would even say less than half mocked uh native rollup running and sending transactions. So this is going very well. uh it's just that there are some requirements and this you know until uh linvm work is not finished and not merged uh this cannot go live. Cool. And uh while we are talking about eat uh can you explain a little bit more why L2 beat?

>> Yeah. So as I said um the reason why we tracked L2s is because we were excited about scaling the trustless and permissionless properties of L1. Um if these L2s are not doing this it's not interesting for us. As we said in our mandate the main thing that we want to focus on is this intermediation. If these L2s are just you know an additional intermediary to this uh to the block space uh this is not something that is interesting for us. Uh so if there are L2s uh that want to get there and there are some like Castc for example they recently launched right um we will track them we will promote them uh we will continue tracking L2s this is

not something that we're removing it's just that if we see that a project for example doesn't even want to get there in the first place uh they feel uh that they're like an intermediary and they are okay with it. Uh we don't want to spend a lot of resources on this. It might make sense to for us to still expose that this is the case if they're a big project let's say Robin Hood but we don't want to spend much resources these resources are better allocated uh towards you know promoting stuff that actually goes in that direction >> I guess we have time just quickly to answer the next one which is when you will do analysis on D5 walls vaults and that would be great >> so we have exploited this direction uh the problem is that it's extreme

extremely complicated. Uh it's feasible maybe uh but it's extremely complicated and we've been told by a lot of these projects that people don't care about about this like uh there are permissions everywhere you know everyone uses chain chain link protocols these are completely centralized for example uh everyone trusts them uh and everyone uses you know layer zero to move these tokens around um I mean we want to we would like to uh we need to uh we need some people like you that come to us and say we care about this.

>> [music]