Bridge Atlas - Episode 5: Verifiability | Shreya Shankar & Justin Drake

Transcript

[music] [music] Hey everyone, welcome back to the final episode of the Bridge Bridge Atlas series. I'm your host, Christine D. Kim. I'm very excited because not only is this the final episode, but we also have our final two guests for the show. Um we're we are going to be discussing Ethereum and AI systems through the lens of verifiability. Um so pretty big topic and for the episode I am joined by Shrea, a PhD student and researcher at Berkeley University. Um some of our listeners may already know Shrea from

her summer of protocols talk on uh agentic query optimization for unstructured data processing. um which was a pretty uh pretty like a talk that she did earlier this year. Um and we're going to get into some of what she shared in that in that talk, but it'll also be linked for any listeners that are interested in the show notes of today's episode. Um hi Shrea, very nice to meet you and have you on the on Bridge Atlas. >> Yeah, I'm excited to be here Christine. And for our second guest, uh, we are joined by Justin Drake, an Ethereum Foundation researcher who is focusing on the lean Ethereum project. Hi Justin.

>> Hi Christine. Thanks for having me. >> I think it might be good just before we get started with the the full discussion to give our listeners a bit more background on what both of you guys do. Um Justin, can you start off with sharing a bit more work on the lean Ethereum project and what that what exactly that entails? >> Absolutely. So my understanding of this episode is verifiability and in the context of of lean Ethereum um we're trying to do two things differently with verifiability. So with blockchains there's two components. There's one which I'd say is deterministic meaning that there's this there's computation that's that's happening and it's a very

well definfined output for every single input and traditionally the way that we verify this computation uh for L1 blockchains is to do it naively through brute force re-execution. So you have potentially thousands of nodes all around the world and they're all redoing the exact same computation. And one thing that we're looking to do differently here is to use cryptography uh specifically a primitive called snarks uh which you can think of as being a short mathematical proof uh that the computation was done correctly.

And one of the the beauties of snarks is that only a single person needs to produce the snark and then the rest of the world can just verify it. And verification is almost free in the sense that it's a very short proof on the order of a few uh hundreds of kilobytes and it takes only a few milliseconds uh to to verify. And then the other aspect of consensus in in blockchains uh has to do with the verification of a majority vote. So um there's some things that are simply not deterministic. there's like multiple potential futures. For example, you know, the ordering of of of

transactions, you know, they could go one way or it could go the other way. And the way that uh we um settle on the the canonical truth is by using a majority vote. So you might have heard of a 51% uh you know attack. Um it's basically where you can overwhelm the majority. In any case, what we have today is a a mechanism where it takes 32 slots. So each slot on every is 12 seconds. 32 slots is what we call one epoch. Uh and it takes a couple of these epochs uh to for everyone to to to get to to vote uh and and and to reach consensus.

And one of the big things that we're hoping to do uh with lean Ethereum is to make this voting process much much faster uh so that you get so-called finality uh on the order of seconds as opposed to to minutes. Uh and that's the the nondeterministic part of blockchains. >> Gotcha. Shrea, I saw you smiling when Justin was saying snarks. Is that something you as well are very interested in as it in terms of how it relates to verifiability? I'm intellectually interested in snarks. I took a class in I learned about ZK snarks in the first year of my PhD.

Please don't ask me anything about them. Don't ask me. I don't work in in cryptography. But I did find them very cool. That's why I smiled. >> I see. We're going to change and we're going to do a last minute pivot. This entire episode's going to be about snarks. Um, no, I'm just kidding. Um but Sharia I'd love also for you to share more about what um you're interested in what verifiability looks like in your domain and like uh the work that you've been doing with with DOCTL um as well as your yeah current area of of focus when it comes to your PhD.

>> Yeah. So in my PhD I built the DOCTL system. This is a declarative system for unstructured data processing. So I'll give you an example of one of our users workloads. This is a public defender in the state of California and they are interested in mining very very long court transcripts to find statements that are racially biased or like coded with some sort of racial bias because it turns out there's a law in the state of California. If you can prove that um you know then you can defend a client who might be unjustly sentenced so forth.

And this is a problem that you know traditional data systems cannot solve because it requires some sort of reasoning to figure out what does it mean to have racial bias. How do you kind of extract this? We couldn't really do this in a database. But now hopefully with large language model or AI components, the goal of the DOCTL system is make it very easy for users to program data flow pipelines that leverage AI components. So say if you're familiar with the map produced paradigm, we basically allow people to write kind of map reduced filter pipelines but a large language model executes the operator which is defined in natural language rather than user writing some sort of code function to mine their data. Um so what does verifiability

broadly look like to us? Well, you might write some pipeline that a large language model executes, but you have no idea whether this is correct or this kind of aligns with what the public defender or what the judge or what the jury might think is a racially biased statement. Um, and what makes this even more complicative of a problem is the way that you might write such a pipeline to say send to a crowdworker pipeline. uh maybe for every document for every page let's extract racially coded statements and then we'll operate on that unit of page. Uh that's might that might be something that you send to a

human worker or crowd worker but that unit of computation might not be reliably executed by the AI. So our query optimizer under the hood figures out how to rewrite pipelines to have good accuracy and be costefficient. So try to you know author code functions whenever possible instead of LLM powered functions just to you know make things cheaper at scale. Um and then the questions around verifiability come okay how do we do rewrites that preserve the accuracy? How do we make sure that the end result is also accurate? Um humans cannot verify everything. This is a big thing for us. So how do we kind of expose statistical uh primitives that

allow people to verify on samples and then kind of give an estimate of what the accuracy might be in the worst case or um and so forth. So I'm happy to chat about that as well. And um also other aspects of verifiability for us include for example provenence like where in the source data are these statements? What is the quote unquote reasoning of these AI models? It's something that people have become interested in recently. Why did it say that this was racially biased? We don't really know. We could ask a large language model, but is that the reasoning? I don't know. Um, so there's a lot of fun questions around that.

>> Justin, any of those in particular as it relates to provenence or some of the other ways verifiability is measured with AI that you think is particularly you're particularly interested in learning more about as it applies to uh, Ethereum's verifiability? Yeah. So um what Treya said actually reminded me of this this mental model uh which I call the the spectrum of trust. Uh and on the one hand you have things that you can you know trust a lot like mathematics and and and physics and cryptography and then you know it it kind of becomes progressively weaker and weaker. Um so you might have for example uh you know consensus which to a large

extent is is based on economics and then you would have more mushy thing things like uh the the legal systems and uh you know things like reputation and uh I think what what what Treya is talking about here is interesting where you can take very mushy things that you know rely on on reputation and trust and bring them slightly closer to the middle of the spectrum and have a little bit more of a of a of a formal understanding of of what's going on. And really what we're trying to do in in blockchains is this idea of of trust minimization. So we're trying to bring everything as far as possible to the left side of the of of the extreme in the in the trustless uh realm. And if you take uh you know

complex applications for example a marketplace which is one of the first things that I worked on most of these things can actually be made extremely trustless. Uh so for example identity um payments um you know stable coins and whatnot but there's there's this one part um on marketplaces which is very difficult to do trustlessly which is dispute resolution. So you have for example a buyer and a seller and in between you have an escore agent and ultimately the escro agent needs to make a decision in case of dispute and here you have these two parties that are sending evidence and it's just extremely extremely mushy

and maybe uh the work that you're doing could allow us to build peer-to-peer trustless marketplaces where even the escrow agent is kind of removed from from the picture. That's very interesting. How is this problem like currently solved in the marketplace? Do you have to kind of reveal something about the identity or have some like hierarchy of who is trusted more than the others or >> Yeah. So in the designs of the so the marketplace that I used to work on was called Open Bazaar and the way that it was solved was um by the buyer and the seller mutually agreeing to a a a trusted escro agent. So it was very much

reputation based but also there was this coincidence of wants if you will where both needed wanted this the same thing. >> As soon as you make things trustless you open it up um to to to a broader design space where there isn't necessarily this this matching process going on. So it would be much more efficient. And these escro agents are they did you find instances where they actually cannot be trusted or are they like fully controlled by the marketplace? So >> yeah. So um ultimately the one way to think about them is that they they have some reputation and that has some economic value associated with it. for example,

the expectation of future income and >> if you know they're making a very big transaction, maybe they they have an incentive to collude with one of the parties because what they stand to to make from it. >> Got it. >> Yeah, >> I see. That's cool. >> Um >> Shrea, can you talk a little bit more about um AI evals in the context of the verifiability um studies that you have? I wonder if some of the concepts or the ways that you might be um creating or like progressing AI evals in this domain if if they might have some relevance to the conversation around verifiability for

Ethereum. >> Yeah, I can talk about the highle process that people do with docet and evals. Um so all of these outputs are very open-ended. So think like text document in and then like a list of text snippets out or something. That's like the most basic problem you can chain to together like kind of any data processing operation and any complex pipeline but I will focus on this like small scoped operation. Um what we do is we try to get a highlevel picture of what factors or what features might correlate to like a binary disagreement with between the human and the AI. So for example, so the human specifically will look at the output and say this was

not good and then it will anni then the human will annotate like basically features explaining why it's not good. So you know maybe it's missing out on some definitions of racial bias or um it's defined it in a weird way. Um maybe it's not like prioritizing the order correctly. I don't know like you can imagine all sorts of different features and we will try to basically have humans annotate as many samples as possible until kind of the distribution of what we're calling like these qualitative codes stabilizes. Um and then in a sense you can use that to train LLM power judges that each kind of evaluate these codes like on the outputs of the large language models themselves. Um, and then at scale kind of estimate, okay, how

misaligned are the AI outputs in the human expectations and why, like what factors contribute most. Um, and then we kind of go through a process of improving the specification to try to decrease that misalignment. Um, or I don't know, we give up if it's too hard, which happens sometimes. But that's broadly how we're trying to think about it is you know how do you take that qualitative uh unstructured data and then figure out features that you can then quantify the misalignment on.

>> I think of that a lot in the context of trying to measure something like decentralization in Ethereum. It's like a quality that can be measured in so many different ways. But Justin, correct me if I'm wrong, but I don't think we really have an eval like document or process to really be able to measure, you know, is Ethereum even decentralized or not or like where is it on the spectrum?

>> Yeah, decentralization is definitely something that's difficult to measure. But there have been attempts um looking for example at the distribution of stake and like how many staking operators are are required to have uh maybe 33% or 50% of of the stake and uh there's this term called the the Nakamoto coefficient. uh but even that is very mushy because uh you could have two staking operators that are both controlled uh by the same entity and vice versa you could have a single staking operator that actually is internally decentralized. Um so um I think the the the best that that that we

can do here uh when we design these systems is just to have the the lowest barrier to entry as possible and then just just just hope for the best in terms of of of decentralization. Um, and the snarks that I've been talking about really do bring the barrier to entry essentially to the minimum because um, from a computational standpoint, you you don't need a powerful computer at all. And you know, even just a a smartwatch or a phone or Raspberry Pi uh would would be sufficient.

Now, um, one of the the things that we we like leaning on, uh, for the non-deterministic part of of of blockchains that I was talking about is this this idea of, um, economic penalties. So, when things go wrong, the way that we uh gain asurances on our systems is that we we know that when these things go wrong, large amounts of money will be will be destroyed. Uh, and today on on Ethereum, we're talking about tens of of billions of dollars that would get destroyed if this uh if there was something wrong with the the nondeterministic aspect of of of these blockchains.

Um but I have a a question for for Shrea in terms of um the the the the model that that we have here especially when it comes to to adversariality because in blockchains um you know anyone can come in and try and poke at the system and and find holes. um like what kind of techniques do you have uh to try and uh and make sure that these these systems don't don't get don't get abused? >> Yeah. Um I there's a few threat models that I've I mean I'm going to use a term threat models, but there's not really a notion of security and AI and data processing yet. So don't like Google it

and see if there's something there because there isn't. Um but there's a few that I've kind of been observing in applications of DHTL. one is the user of docl who's creating the data analysis they themselves are a little bit malicious um so they are looking to use the AI to kind of find instances of comments or something in the data that will prove their point even though it might not hold at scale or I I don't know they're like they're trying to just be a data science and scientist in a malicious way um and docet can facilitate that the other threat model that I've seen actually this is crazy came out of user studies, but the user is not malicious. And I don't know if the AI is malicious or not, but the user

kind of blindly trusts what the AI says as for example racially biased or a benign query like what are interesting uh features of these customer reviews? I don't know something. The AI then has a lot of agency for lack of a better term to say to interpret what interesting means and return that back to the user. And the user doesn't really know the counterfactual of if I had done this analysis myself, what would I have considered interesting and whether that's, you know, aligned with what the AI says or not. Um, I think in the former use case, the where the user is malicious and I I hope that like in society we can put things in place to like prevent them from exercising that

malice. So for example, you know, when a lawyer goes to trial, right, they have to convince a jury. So it's not just like like hopefully the the jurors or hopefully the system is there in order to make it such that the evidence needs to be like somewhat robust to a bunch of different people's competing opinions. Um, but in the AI being somewhat malicious or having too much agency, that part really scares me because I think that we have a lot of data scientists in the world and no none of them have really used AI as a tool for data analysis before and most of them are going to blindly trust AI as is to tell them features in their unstructured data. Um, and I don't know if we have

good models of that or ways to solve this problem particularly. >> Got it. Um, I mean in in in the world of of SNOX uh we actually have two techniques uh to try and uh identify malicious activity. So one of them is called interactivity where you basically have a prover and a verifier and the verifier wants to make sure that the prover is not acting maliciously and um the the the techniques works by having multiple rounds of interaction. So maybe the prover can fool like one round, but you know based on on what they said in

the first round, they'll there's going to be a challenge where they they they they they start probing things and um so that that's that's one very powerful technique. Another powerful technique is what's called hinting or not or actually called also non-determinism confusingly because the same term that I used before. U but basically it's this idea that um as a as as a as a as a as a prover that's trying to make a claim, I can try and provide additional supporting information to make my case. Um and and that can kind of make the verification much easier. Uh and the classic example here is actually

just just the mathematical proof like if I tell you you know fair is correct you know that's very difficult for you to verify even though it's a true statement but if I give you the proof then you can just check check the proof. >> That's interesting. I wonder if there's actually I can think of ideas to combine both of them for this docet setting. Um, but yeah, the the problem of like if an LLM tells you here are the interesting things and you don't know what you would find interesting, like I one of the things we've been thinking about is are there ways to kind of use samples to convince the user of something. So, for example, the AI also returns here

are some things I did not find interesting. Um, or here are some things that might be interesting and can you label what is interesting? um and then somehow we can kind of formalize that as some like function that could apply to the whole data set and then I don't know characterize this interesting function a little bit better. Um I know that's very very high level but I that's just something that we've kind of been thinking about and then probably there are ways to make it somewhat more interactive. Um yeah, I don't know what are the challenges that you've seen with I guess snarks [snorts] um and the kind of like extra information.

So you said like the proof of um Ferma's last theorem for example like that that is something that like you as a system designer need to like figure out what is the extra information that you need to give to the verifier. Um is that a hard process? Is that something like system designer supposed to manually do? Um or am I thinking about this in the wrong way? So usually this this hinting is a technique to try and simplify the workload uh of of the prover because these snocks actually have very high overhead over the raw computation. So the raw computation might take let's say

you know a second to to run on a normal computer but it might take 10,000 seconds or at least uh core core seconds um to to to prove and so you want to be um doing as much pre-processing as you can uh outside of the m the heavy machinery of of snarks to try and find shortcuts and these this these and then you basically only feed in the shortcuts uh in in in the prover.

Um I mean just zooming out we have this this this big problem with um with with performance uh actually and um I guess there's there's maybe uh a couple things that that you can do like one uh one interesting technique here uh is to potentially only do the computation when something goes wrong. Uh so this is what we call an optimistic game where you know you you make a claim of something and you only go through the expensive uh proving and dispute resolution when when when something goes wrong. Maybe um maybe that can be applied in in in your

domain as well because you know AI you know consume a lot of of resources and and and electricity and um would would you agree that like you only really need to run the AI when when when something goes wrong. Uh this actually reminds me of the way that I've been thinking about this problem is like how I learned about databases because I'm a database PhD student like concurrency control techniques like optimistic concurrency control works for certain workloads and not just depends on the queries. It also depends on um like the hardware and whether like the the um the database is like a distributed database or not, right? If you if fault tolerance is something you really have to worry about, then you probably don't really

want to be running optimistic concurrency control because then you'll be just running your I don't know roll backs all the time because there's always some probability of like some node failing or straggling or something. Um but sometimes it does make sense for in the case where you know you don't have that many failures come up. So, I don't know. That's that's like the mindset that I've been applying to kind of how we think about um not dispute. I don't know what the term is, but like if there's like misalignment between like human um and the AI. I will say that pretty much every single time somebody authors a pipeline in DOCTL, there is a misalignment. And we actually did we wrote a HCI paper on why we like observed this problem over like

thousands of different pipelines that users initially authored. And we realize it's because um people don't really know how to articulate the task that they want the LLM to do in a prompt. And the way they discover how to do that is to look at examples of outputs from the large language model in a task that's like kind of adjacent to the one they want to write and then they will use that to write the specification, write their pipelines. So in this case, right, there's always 100% misalignment everywhere in the authoring process. Um now I think what we could do is like kind of separate into two phases of like initial authoring and then like handle some more like I don't know dispute

resolution or like misalignment resolution there um in a different protocol than you know in if somebody was running a docket pipeline in production regularly on their data that they already kind of knew about and felt good about then we would think that the misalignment between a human and an AI there is low. So maybe a different uh protocol would work there for dispute resolution. I don't know if kind of what I'm saying is making sense going deep into the AI, but yeah, I guess you you made this point.

There's there's these two cases. There's there's one where you know someone's actively trying to be uh malicious and and here you know one of the techniques that we have in blockchains is just to put a very high penalty to being malicious. So you put forward some collateral and then there's a process to eventually discovering that someone is malicious and then just through incentives malicious behavior doesn't happen anymore. Uh but then there's this other much harder case that you you put forward where in some sense it's incompetence. Um, and >> it's true. It's true.

>> It's hard that one. Much harder. >> And you know, I'm trying to um like one thing that just came to mind here is is this idea that, you know, AIs are going to be much much more intelligent than than us. So, we're going to be the incompetent ones. And so, what is the good way that the AI should be treating the humans? And two two mental models that you know that could make sense is you know the the the parent child relationship right that that that that's an or maybe the the the the teacher and and and and and student and um I guess this this maybe goes back to

this idea of hinting. Let's imagine that you have a teacher who poses a a question to to their students, you know, some sort of of of math question and and you know that they're stuck. They're just incompetent. They can't solve the the question, but you know, the teacher will provide a hint and that that hint kind of helps them uh solve the solve the problem. Um, and you know, maybe in a in a a parent child relationship is it's not a hint, but it's more I know sign of affection or something that that that that uh that that helps. >> I I think maybe hint is a more universally agreed on terminology or I I can find less problematic

issues with that than maybe parent child analogy. Um, but I think it's a good point. I also think about, you know, in traditional data science, like is it is it really new to large language models that we have this problem of malicious uh or like negligent users of data and science tools like going and analyzing data and then writing opeds or articles about it and then you know policy gets impacted and then you just you know you've created this I don't know what what if you've done something bad but the data doesn't actually tell you. Um I think that the problem was there in the past and what I think is new now is just now because of AI the problem is much

more preient like there was not that much structured data in the world compared to unstructured data in the world. So you could imagine like someone out there in the government is building a bot right now to like mine all of the tweets of the president and then like recommend to their leader what policy to implement. And it's like to me that's a scary thing, right? Because now there's like so much uh so much agency given to the AI to figure out what that's going to be because I know that the consumer of that is just going to take it for granted. Um >> so one thing that just came to mind is uh this technique called uh recursive

proof composition. It's a it's a fancy way of saying that you you you have multiple snarks or multiple proof systems and they're good at different things. So you could imagine proof system A which is extremely fast at producing the proofs but the proofs are pretty big and then you have proof system B that's much slower at producing proofs but the proofs are small and um if you combine the two so if you have a statement and you first do a pre-processing pass with proof system A and then you feed the proof to another proof system so you have a so-called recursive proof um then you get the best of both worlds where your final proof is is is short and and fast to verify. And maybe in your um setup, you could have

recursive AI. So basically, you have AI number one who's very good at taking the text and isolating snippets of text. And then you have AI, you know, B that's very good at identifying whether snippets of text are relevant. And when you combine them, you have what you want. >> Yeah. Actually that's a technique that we don't call it this u but the idea of like decomposing the problem into different units that different AIs can do well and that we could measure the accuracy of what we do in our query optimizer how we rewrite the pipelines.

What did you call this? I want to look this up um later. >> Recursive proof composition. >> Recursive proof composition. Okay. I always find in computer science every sub community has like invented the same things. >> This is why this series also exists. We've had many new moments in these discussions between Ethereum and other uh protocol experts of different domains find that they are studying very similar concepts but calling it something completely different.

Yeah, I yeah, I feel like when I do talk to people that know I'm just so outside of the domain for them like it always comes down to like the common denominators for me are like trust, you know, all of us know that trust matters. Um, all of us know that efficiency matters. So, how do you like minimize the amount of work that needs to be done? How do you like minimize data movement? That's like the core principle of kind of all of the systems that we try to build. Um so it's just interesting to see you know like how that how people have like chipped away at coming to those principles in their different domains. Would you guys also agree that the core tension in either of these domains or protocols that you're

studying uh between verifi is verifiability and uh performance efficiency as in like the the core what's at odds with each other is verifi if you have a lot of like say ei AI evals or something is just too much work like it slows down say the performance or process um or are those or Are there different tensions or trade-offs that you think are more important or are more relevant in the the way you guys are are um trying to get verifiability at these systems?

>> I mean in our domain uh we have this thing called rollups and in some sense it's all about verifiability of computation and there's at least four different flavors of rollups and they each have their own trade-offs. So uh one type of rollup is called optimistic rollups where you have this um you know claim and challenge um game and the the trade-off there is that the time to settlement is very long because you need the game to play out in the worst case and we have this 7day uh de facto uh challenge period. Then there's the the snark rollups or also known as ZK rollups where the main trade-off is that you have to put a lot of effort in

building your your your proof up front. And then there's another flavor uh which you could call uh TE rollups where you're trusting a an an enclave uh like like Intel SGX. And here obviously the trade-off is that you know you're trusting the hardware which has you know time and time again been uh found to have flaws uh eventually. Um and then there's yet another flavor where you know you have a committee for example and you're trusting that at least half of the committee members uh are honest and and here you know the downside is that it's it's liable to bribing and uh and uh and it leans very

much on reputation which is the thing that we're trying to to to to to move out of. Um so there's there's no silver bullet unfortunately. I know that in the context of AI there's this new trend of for example Nvidia GPUs having uh trusted enclaves that are baked in >> um and that could be that could be helpful but if you look at snarks unfortunately that we might have a power problem because my understanding is that AI is you know already consume let's say 10 gawatt uh and the process of of snarking introduces an overhead of let's say a thousand and there isn't 10,000 gigawatts in the world. There's only

5,000 gigawatts. So there's no way that we'll be able to snarkify all of the AIS and so we need to be clever and you know only snarkifying when required or Yeah. >> Yeah. That's it. I I think for our for data systems very broadly um there's always trade-offs and the more computation you do the more resources you're going to spend. So for every single workload and there's also trade-offs between like storage um like keeping data in the cloud that's very cheap and then keeping it in memory which is very expensive but then close to the compute right so then your process runs faster. I think there are

analoges in AI data systems as well. Um when you think about you know different LLMs have being varying levels of accurate. So there's big ones frontier models there's smaller ones smaller ones can't do some of the tasks that big ones can do so they're cheaper etc. Um, so there's always going to be trade-offs made and I think a core challenge for DOCTL and query optimization is okay, how do we take the task the user gives us and like partition it into all the computational units to like minimize the cost and maximize accuracy. So if the operator that the user wants is uh find me the number of words in this document, this is not a task we want to give to a

large language model that's like orders of magnitude more expensive than say some C++ function that can just count the number of words in the document. So we want to be able to author that kind of function on the fly. um kind of basically think about as redistributing the work so that we can push as much to the CPU as possible. All of the data that we need to repeatedly run pipelines on it's living in memory. Um and then we only reserve large language models to do the hard tasks that require some sort of reasoning or something that you know a human would traditionally have to do.

One of the the mental models that that has is the the co-processor and glue um where there's there's some tasks which are extremely repetitive um where you want a lot of specialization and then there's the glue which is much more unstructured and unpredictable. Um and you know the the hope I guess is that most of the heavy lifting actually happens in the co-processor so that the the expensive glue where you maybe using AI or something very flexible um only accounts for a relatively small portion of the time or resources spent to to solve a

specific problem. >> Totally. Yeah. like some the kind of optimal ways to process things like filters over large document corpuses. Turns out it's almost always have some agent in the optimizer write some sort of function to deterministically throw out words that are not relevant to the query. So like transcripts that might not have any mention of race whatsoever. Like you could probably do this with non AI throw out like 95% of text in the document and then now the task is much simpler for a large language model can run on a very small large language model. Um, right.

>> So, I think like it's it's kind of interesting like this glue analogy that you have of like, oh, it kind of is very fuzzy and you know, you don't really know how you're going to what what the query plan is going to end up like. But now, you know, we can reason over the task, the semantics in the task and what the data looks like and try to construct it optimally to navigate the kind of trade-offs that Christine is mentioning. >> Yeah. And there's this team in in Snox uh called powder and they have this technique called auto pre-ompile. So you can think of a pre-ompile as being this this specialized co-processor and the word old auto basically suggests that on the fly they come up with the best uh specialized co-processors.

um and I haven't looked at it in detail but my understanding is that they do a combination of of static analysis as well as um you know trying to identify what are the hot spots and like just optimizing those by by looking at multiple runs of of of similar problems. Uh and one of the things that we've been doing historically in in SNOX is to hand write our pre-ompiles because we think you know that we we're just very good at at trying to solve a very small problem by hand. But one of the surprising outcomes is that the auto pre-ompiles which are uh machine built uh will often time outperform the the handwritten

pre-ompiles. >> Interesting. Is that do you know like for what kinds of tasks that's true? Is it because maybe it needs to be a little bit more generalized and there's no way that like a human can kind of enumerate whatever I don't other or is it like truly it's so laborious or tedious and that there's like not that many human experts that can do the problem and some are just bad. >> So the example that powder gave was that of a a hash function. So a hash function is this basic primitive where you know you take in an input and then you fingerprint it cryptographically and and the way that these hash functions work internally is that there's there's a lot of scrambling uh going on and um I think

what happened basically is that the humans tried to build the best scrambler if you will but they were missing out on on optimizations which were not obvious and somehow the machine managed to find these the these nonobvious optimiz organizations. >> That's cool. Um I I so usually when when people ask me about the the intersection of uh AI and blockchains, the the very first thing that comes to mind is that um blockchains provide an ideal money for AI because AIs don't really have access to to to bank accounts, but they can have access to to cryptocurrency.

And then when you combine that with the observation that AIs are going to be so much smarter that than we are, it's only natural to to assume that AIs are going to be the richest entities in the world and they're going to be storing almost all of their wealth in in cryptocurrencies. I guess me saying that, what kind of emotions that I does that invoke in you? I I like the idea of having giving assigning currency to I don't know whatever entity that you want to call AI because it's like an incentive now you can design incentives for AI to align with you and currently we just don't have any. I think there's I I don't really know how that is going to play

out in the abstract if like AIs hoard a lot of wealth and the other thing is like what can you spend that capital on if if you can't like spend that capital on the things that you know humans value does that make the AI more or less I don't know likely to be useful for us I don't know um I think, okay, if I had to concretely think about how this would play out in like the data analysis setting of like I have an AI agent that's going to just analyze data for me whenever I wanted to and I'm going to treat it like an intern or like like a chief of staff I've hired to just

like always like be good at analyzing data. I don't know. Um I could totally imagine like if the AI is really good, it's very valuable. I would want to pay more than if an AI was less good. [laughter] And maybe that's a little bit scary to me. Um the fact that, you know, if if my AI cho of staff was so good at data analysis, I would just go bankrupt. [laughter] >> If it's an >> Go ahead. Oh, I was going to say if it's an AI, does it need the same kind of like can you just hardcode it to um believe and know that its ultimate end

and goal should be increasing in this particular asset um without anything to spend it on. So like for humans it's very hard to control us with that kind of incentives because we [clears throat] do need something meaningful to spend our money on or to believe in it. But I I wonder if just for the sake of like introducing penalties and introducing some kind of like desired behavior if uh if there is such a cryptocurrency uh that AIs can just be like I don't know forced to believe it is its ultimate end. I I wonder if that would solve some problems.

>> I mean, I would imagine that um because one one of the nice things about money is that uh once there's convergence on on the money, there starts to be network effects. And so an AI if it if it needs other AIs or other humans to produce tasks then you know if these other AIs are receiving that money that that kind of makes the money valuable to them because it helps them accomplish that that that that task. So an easy way to make them understand that this money is valuable is just by showing them that it helps them perh perform their tasks. And actually one of the things that uh you know I'm envisioning would happen is that the the the current paradigm where

it's humans directing AIs and paying them will will flip. Eventually it will be AI paying us and directing us to to per to perform tasks >> to perform things because they can't do so many things. I also think like there's the AIS need resources to do all the computation, right? Like they have to pay there's only finite comput memory like they have to pay for the compute in memory. So like in a way that there's there's many things that the AI is going to spend and the AI is incentivized to like be efficient of course but it's not going to like say it's not going to give up because it just thinks the compute is too expensive then like it would lose out on me paying the AI for like a good result, right? So, I don't I feel like, you know, hopefully I have a very

rudimentary understanding of markets. I hope the market is efficient. I hope we can figure out how to make it efficient. But I do think I I agree with Justin. I think like, you know, there's going to be all sorts of different kinds of transactions. AI is going to need resources to do the work that it gets paid for. AI is going to need us to do some sort of work. Like in the public defender example, uh currently humans have to go be lawyers. Like AI is not a lawyer. like that that's just like some task that has to be fulfilled by human being. Um and I imagine that there's many such tasks in the world that only humans are going to be able to do.

One thought experiment that I was having with w with with with my son the other day is um what if some jurisdictions were to embrace the notion of AIS being legal entities and having access to to to to bank accounts? Um does that lead to better or worse outcomes versus just outright uh abandoning them? And uh what I expect might happen is that we're going to have you know different there's about 200 jurisdictions in the world and we might have some of them lean in one way or the other and I think over the next few years we we we might see these experiments play out um and uh yeah

should be very interested >> and to this future that we're barreling towards even though we're talking about it in ways that I mean we're not sure but in any in either of the situ situations that we talked about. AI is such a it's such a core kind of like um force in our society. I do really think that this this topic of verifiability when it comes to AI is just so important um especially to quell some of the fears around AI dictating like our reality or our truth. Um, one other very quick kind of um, area I wanted to or question I want to ask you guys as it relates to

verifiability and protocols is are there any other characteristics that are really core or integral to verifiability? Um we talked a little bit um Ben sorry Justin you were talking about how in the domain of blockchains verifiability and reproducibility are just like one and the same like nodes are reproducing the same results and that means that this is verifiable are there others that really go hand in hand and and for Shrea like in AI is it all about like interpretability is that like the way in which verifiability it is attained or is is it something else?

>> So I think a lot of people do care about reproducibility myself uh included and I think most of the reason that researchers care about reabil reproducibility is to reproduce experiments like people draw conclusions from experiments and then if you cannot reproduce those experiments then you don't know about the validity of those conclusions and then you can't like apply them in other scenarios for example. But the inherent um I think people confuse you know non-determinism in AI for like lack of reproducibility or equate that to be the same thing as like oh I couldn't draw a scientific conclusion a valid statistical conclusion. I think those are very different things. I think it's okay that

AI is nondeterministic um in our everyday use of it. Humans are nondeterministic. It's very fuzzy. It's very hard to reason about, but we still have ways to study it, you know, how humans interact. And one of the strengths of AI is that it is nondeterministic and it's a little bit different and there's like a long tale of what it could do and sometimes that something in that tale is quite useful. Um, and then I I don't know. I don't think that that's bad. I think that's like a feature and not a bug. And um we're going to have to figure out ways to rethink what it means uh for what what is the analog of reproducibility. I guess it's it's more like it's not that we need exact reproducibility, but maybe

it's like a reproducibility of a statistical claim. Um >> I mean one one thing that that that came to mind um around reproducibility especially for stocks is the idea of bugs right like we have complex software and they they they all have bugs and and how how do you mitigate bugs and there's only really two solutions that we know of at least for stocks. The first one is to lean on client diversity where you basically have independent teams writing independent snarks in independent languages and then you have some sort of a rule that says you know for example three out of five snarks all need to

agree for that to be the the ground truth. And I guess you could do something similar with AIS where you have uh you know Gemini and you know Chad GPT and and like three others and if three of those agree then it's probably the the ground truth and then there's this much more um you know expensive but potentially more fruitful uh direction which we call formal verification where you can prove that your software has zero bugs. Um, and I guess that makes sense in the context of a snark where you have a very um precise specification, but you know, in the context of AIS, um, formal verification sounds almost like like

like a non-starter, but interestingly um, AIS are helping with the formification of SNOK. So for modification is a very laborious task and um what we're seeing is because for verification can be broken down into small sub problems um and each sub problem can have an independently verifiable proof you can massively you know outsource the problem to to parallel AIS and if they start hallucinating the proofs it doesn't really matter because anything that's hallucinated can be immediately discarded.

because the proof won't verify. >> Interesting. Yeah, a couple of my cohort mates are working on formal verification, having different PhDs than I'm having, but yeah, it seems very difficult. >> Nice. So, they should definitely contact uh Alex Hicks. So, Alex Hicks has a $20 million uh formal verification grant budget to spend over >> Oh, I should tell them. >> Spend over three years. and we're basically trying to formally verify the whole um snack snark stack. Um >> nice >> and we're just at the very beginning of using AIS for for verification. Um and one of the tools that Alex uh is is is

quite fond of. It's called lean for which has nothing to do with lean Ethereum. It's just a naming clash. >> Um so if they specialize in that then yeah definitely do do talk to Alex. >> Yeah definitely. No, all of them are excited about lean. So >> nice. >> I think there have been a lot of different bridges and connections that we've made in this conversation so far. As we wrap things up, um Justin and Treya, can you share uh what has been your main takeaway from the discussion?

say for Justin um anything about AI verifiability or systems that you didn't know coming into this conversation that now you're taking away and uh Shrea for you conversely um about Ethereum or um Ethereum protocol design that uh you hadn't known before and there are so many things I didn't know before but the thing I'm most excited about is this idea of hints like using hints to make verification easier I think we can definitely have analoges data process the thing, but that's probably really specific.

>> Yeah. Um, from my perspective, I guess, um, [snorts] I'm I'm quite pleased by the fact that, you know, people are trying to to take this this very mushy reality and and and and come up with with a more black and white uh outcome. Uh actually my my son uh plays fencing and um I'm a little bit frustrated by fencing because there's this rightofway rule um which you know should be uh completely objective but in practice you know defensing happens so fast and there's like a lot of of subtlety and

detail that uh that sometimes it leads to disputes with with the referee. And so, um, what I'm what I'm hoping could potentially happen is that, you know, Shrea's research could could be used to replace referees in in [laughter] the context of of fencing or replace, you know, escro agents in the context of of marketplaces. Um and I think once we we have that um then in some sense we we're able to solve the the remaining 20% uh where we still need humans in in in the context of business and and we can have a then a much more powerful uh network effect at play.

>> Thank you so much Justin Shrea u for joining me on this final episode of Bridge Atlas. It has been a true pleasure. Thanks Christine. Thanks. Thanks for >> and thank you to everybody who is listening to this final episode. Um for people that have been joining for this entire series, um I really hope that you learned a lot from these discussions. For anyone that's just joining in for this episode, please be sure to go back and listen to all of the episodes um in the series. This is indeed the last episode before the real in-person event which is going to happen at Dev Connect.

You can uh find information about the Dev Connect in-person event happening um next week I think or the week after. So, it's happening very soon um for for Dev Connect linked in the show notes of today's episode. Um so, yeah, thank you again to Justin and Shrea. Thank you to all of the guests who took part in Bridge Atlas. Um it has been yeah a real pleasure to to host this series. Um thank you to summer of of protocols team for organizing and and bringing all the guests together. Um couple of last things on the back end of this of this episode for anybody who's interested in learning more about what we talked about today be it with verifiability more

about protocols and again Shia's talk too um and Justin's work with lean Ethereum. Please check out the show notes of today's episode. It has all the links um and all of the uh places where people can find more information. Um and finally to stay engaged with the summer of protocols community and with discussions related to what we talked about uh please do join the summer of protocols discord where um you'll meet like-minded people that are very interested in protocol design and research not strictly Ethereum related. Um, so yeah, thank you all so much again and um this has been the end [music] of the bridge atlas series. Bye everyone.

[music] >> [music]