Web3 Data with AI

Transcript

Now, please welcome our next presenter, Mr. Hey guys, uh thank you for coming to my session. Uh my name is Makoto and uh actually I was born in Osanka. So I'm very honored to be able to present in this city and it's by the way last session was very enterprisey. So I wanted to make it a bit more casual. So that's me on yeah some rainy deal and

this is actually NFT pop NFT you some of you might have claimed in this stage as well but I have a hobby of just doodling me and every event I go. So this is all the uh pop budget I made. So if you have if you this talk interests you and if you want to talk to me more you can have a chat with me afterward and if you tap this card you can get this cute NFT badges and so let's start. So I already introduced myself as Makoto but everybody in the web three space your identity is the action on chain identity identity with your wallet address. How

many people have wallet Ethereum wallet? Okay, about 30%. Yeah. So, for those of you who have never had Ethereum wallet, the wallet address looks like this 0x58. It's actually my address. But most of the time, if someone wants to send me something on chain, you can't really remember just like you know, you don't remember your bank address either. ENS EM name service provide human readable name so that if you go to wallet such as MetaMask and if you type myth which is my onchain identity it look up ZX5A so you can send me E or any shitcoin and so today uh so and then

just a bit by so ENS is one of the oldest smart contract and DAS running on Ethereum blockchain is uh May the 4th 2017. So that's you know the Star Wars May the Force I think we intentionally launched on that May the 4th day. It's been 2017 since 2017 and we have over 1.9 names owned by 800 unique addresses. And what's interesting is because blockchain is a global ledger and all the data is you know verifiable from anywhere if you have an access to

the node. So there are lots of data platform where uh it kind of puts all the onchain data and you can query. So if you don't uh trust what I'm saying you can actually create a uh go to place something like a Dune does anyone know Dune dashboard? Yeah. Two people. So Dune is is amazing tool where all the onchain data is kind of in index and you can write a query called SQL. Does anyone know SQL? SQL. Yeah, it's called structured query language and it's one of the kind of it's programming language but many even non-coder can or business analyst can use to query basically data and so you

can check lots of onchain basically create a dashboard using dune dashboard and which I love it I'm one of the early cont kind of user of the dune but at the same time I've recently worked with Google cloud team to bring some of the aspect into their data platform called big Google big query uh that's where like you can write SQL and to query the large data set but they have a few new a few added features other data analytics platform doesn't have which is the fact that you can actually run JavaScript within SQL and the JavaScript is one of the most widely used programming

language So everything you do there's some sort of JavaScript library. So any logic you can't express with SQL you can argument with JavaScript and also because it's Google they basically embed their own uh AI model called Geminy Gemini and by using that you can do a bit more than just like you know doing vive coding using copy and pasting some query into your uh charge and do it. So today uh topic is uh by using my experience of porting the data platform into this uh Google cl Google cloud uh big query I wanted to show some

of the aspect of how you could do it by yourself and I think first and third part you might not even need a specific kind of programming experience so let's start. Yeah. So first uh SQL prompting with bitquery that like so this is kind of their platform where they have something called blockchain the long table name where it's almost like a Excel spreadsheet that it has a lots of column data and it has all the information of transaction and of the your own chain kind of interaction and if you wants to basically query first

thing you can do even if you don't know SQL you can say show me the first five rows of this table. Interestingly, uh because this property environment is embedded into the uh query platform, they already kind of do some uh digging of the data and they can even suggest some interesting query. So even if you don't know any SQL, you can kind of automatically generates it. But what's interesting is actually Google's big cloud environment uh gets charged per query and the larger query size is more expensive it becomes. So the first example is like a even though it says five first five row it says you need to read 2.61 terabyte uh which is a

bit a lot. So you can say okay I just want to know that last one now by minimizing data set you now it's shrunk to 900 meg or something like that. So you can kind of refine keep refining and you can run a query. So you run a query that's amazing but this makes no sense what the data what's the topics. Uh so if probably this usually needing knowledge but there's what people mostly use is use some sort of decoding uh library. This is a one of the most famous JavaScript library called ESAJS and

uh you decode this kind of z lots of numbers into this human readable. So in this case it it was some sort of the token transfer information. So you usually need to use this JavaScript function but most of the analytics environment where you run SQL which I showed you earlier this function is not available but uh because uh big query allows you to use JavaScript create your own JavaScript custom function. uh my uh our founder Nick Johnson wrote a blog post about actually how you use it within a big query that you can basically define query replace function function name uh with the location of

the JavaScript library and by embedding how to kind of call the function uh you can actually use it within the big query that so that like yeah I with this huge table I actually wants to extract this name registered information and by doing that the data looks like ZX ending 0 66B but it just shows that like this is a name registration information it's successfully decoding crypto world so that's makes it more usable and with this information I basically go back to basically I created the whole this table so now I want to show

something more interesting. So what I tried to do is okay so there's a guy well name called rough go east and who I just met uh in east Tokyo there's a rumor that this guy might be here as well and I might have seen it uh just like just now but what he's known for is he basically registered name for 6,000 years and he claimed he is the longest he has a name with the longest registration period And because ENS name cost like $5 a year, he he claimed that he paid like 45 years, which is crazy.

He just said it was a performance art. So I just wanted to actually dig in. So I initially said, you know, just did a B query or can you figure out how much is he paid? And I think it's too early on and sometimes like if yeah you need to specify uh I think there's a I need to dig in bit by myself but it's good like you know this SQL prompting give the base so the guy can easily build and it was actually 21 east because uh price was uh half what is right now but like you know this makes it a lot easier to uh query online so that's kind of second chapter the third chapter is so

far it's interesting but but you could I think with this uh baseline set up you can even do more interesting that in the first example I was I did a kind of vibe coding prompting to generate a SQL but what uh bigquery allows you is okay you can actually do some sort of machine learning AI within the SQL syntax what what it means is okay there's a one called ML understand text and by doing that uh you can say like oh I want to understand which language this uh certain text is so that like you can kind of find and or

something like I think this is was the names that owner of Rap Gold owns and I wanted to categorize what kind of names he had and you know vehicle is the most or something like that. So you can do categorization or you can find out all these names how many names are actually English based or Chinese-based or Japanese-based. So you can do like machine kind of machine learning categorization is understand test and also that's kind of interesting but you can also write a prompt as part of SQL to say so not like prompt is generating SQL but you write prompt directly on the

SQL to say uh for all these names can you suggest some different names is the prompt I did and This is a output. So I did the uh just formatting and then basically with the rough gold actually a can suggest what other names are possible and the power is that like okay to do that if you don't have this involvement you usually have to download all the data set and they have to set up your own data platform then have to run it but you can all do this within the Google cloud and you can kind of pro the chart and all the stuff. So that's quite powerful and beyond that there's a lots of you can do like a image recognition prediction and recommendation and I'm

not like a machine data scientist. So I also spend a couple time like couple hours using their online course Germany in bigquery. So I think uh this if you use big query with CRM data set it makes a lot more achievable to use kind of interesting AI and machine learning analytics uh for your web3 data and so this environment I'm still working on it and it's almost done it hasn't been announced yet but if you follow ENS domains X uh when we announce you you'll be the first one to find out how to access to these dates that I decoded using big query. And that's it. Thank you very much.

[Applause] Thank you very much. Diego Kingstones would like to invite our next speaker, Mr. Diego Kingstone.

Mr. Kingston, the floor is yours. [Music] Uh, excuse me. I am now going to give the presentation in in English, but I hope that sometime I will be able to do it uh in Japanese. So my talk is going to be about the future of CKVMs and especially about postquantum signatures in Ethereum which is one of the current threats uh we are facing and so I wanted to talk a little bit about

some design choices or tradeoffs and some of the recent uh developments that we have seen. So this is a bit the outline of my talk. I am going to first mention some of last year's advances then comment a little bit on the quantum threat why this is important for uh Ethereum then a little bit about the different like signature candidates uh also then talk a little bit about these multilinear versus univariat starks so uh these last few years there was a discussion between using like snarks or starks

It now seems that this discussion is uh settled. Um and then we have to choose maybe which is the right way to encode them with polomials. Maybe we can have both. And then some design choices. And finally, a little bit about why uh build a different VM especially for what is signature aggregation. What advantages this can give us and um I'll finish with some a short summary of what we've we have been talking.

So some of last year's advances. Uh first we saw that uh we we have like very powerful transparent validity proofs that is proof systems that don't rely on a trusted setup such as uh growth 16 or KCG plunk. Okay. And this has like several advantages and we don't have this um point of failure. Uh so this is something interesting. Um then we saw that uh we have general purpose CKVM that allow us to prove code written in Rust. Um and these have become like really powerful. Uh in fact uh it's been

shown that uh we can prove over 200,000 uh posidon two hashes per second or even more. That depends on your hardware. But this shows that we can prove uh enough hashes for what is uh practically meaningful for Ethereum. Then we saw uh the emergence of real time proving. Right now I think we have three or four uh CKVMs that can do this and we can expect that they will get better and better besides uh power consumption has been going consistently down and so perhaps it will be possible for us to

prove uh things directly from from home and not from a GPU farm. Um there has been a lot of developments related to hardware acceleration. Uh Nvidia has also uh added in its library uh the instructions for for example Poseidon 2 and other primitives that are useful for uh proof systems. We have seen uh a lot of better new lookup arguments especially logup and GKR. We also have like new ways of uh arithmetization and that gives us like more flexibility to uh describe our BPM and then we have

also more precise specifications. So what about the the quantum thread? The idea is that uh quantum computers uh have an efficient algorithm that allows us to break uh the cryptographic uh problem that elliptic curves rely on which is the discrete log. Okay. And basically this breaks all the cryptography EC cryptography that Ethereum uses particularly BLS signatures uh which are used in the consensus. Um and this is something that is very unfortunate because these signatures uh are really powerful because we have very

fast aggregation and um the verification is rather efficient and besides these signatures are very small uh so it's very easy to to communicate them between the peers. So um this also breaks all the elliptic curve based narks for example corox 16 which is again uh very the proofs are very small uh and so we will have to handle like uh larger um proofs. Um on the other hand the security of hash functions is reduced.

Okay, but this is not as catastrophic as the case of elliptic curves. And we can always restore this by working with larger digests. That is to say, if we double the digest, we get back to the security level we had. So why is this important for Ethereum? First, because if this appears, then this can break completely a great part of the cryptography we're working on. But even though this could never happen, I think it's always good to have uh Ethereum working with cryptography that is as robust as possible because that uh makes us resilient against any kind of of threats. Uh besides we know that uh

Ethereum has already uh accepted ZK as the best strategy for scaling Ethereum. uh zigg is really cheap and fast right now. Um so it doesn't make sense for to have optimistic rollups because the cost of adding ZK is negligible and besides um having CK uh greatly simplifies the whole protocol because we can essentially uh verify just these proofs and then just update the results because we know they are correct. Okay. So the execution is basically uh offloaded.

So the thing is they are going to break our signatures uh and so we have to replace them for something else. So there are a couple of things we we would like to have. Um first of course we want them to be postquantum secure. Uh then we want as minimal and as robust security assumptions. So for example, hash functions are among the best known cryptographic primitives. So they are a natural candidate. Uh there are other primitives that uh could also be candidates but maybe they have like uh weaker security assumptions or or

stronger in this case. Then we would like to have like fast proving because that way we can um use CK to bundle and and prove lots of things. We want small proof sizes because that way we can uh communicate them in in the consensus very easily. Uh we would also like the proving to be done in consumer grade uh devices because that increases the decentralization and especially we would like no trusted setups and uh no need to update the keys uh during uh lifetime.

So there are a couple of uh postquantum signature candidates. We have X MSS which is hashbased but this is uh a stateful uh signature scheme. Then we have Falcon for example that works over latises. Uh crystal deliththium also works over latises that is for example something that uh FHE uses. Uh and also Sphinx which is also hashbased but uh stateless. So uh the idea is that uh these uh signatures aren't aggregable but what we can do is use ZK to take a bunch of signatures and generate a proof

that we verify them and then just by verifying that proof it is as if we had verified all the signatures. Okay. And that way we can aggregate. The only problem is that okay this solves the problem partially but doesn't have this nice property that the BLS signature aggregation had which uh was insensitive to the order of the signatures. So basically an idea of how XMss works because this could be the the best candidate. This is because it's based on hash functions and we know that we can prove hashes with VMs really fast. So the idea is that uh the signer has a

long sequence of one-time public keys and uh he builds a miracle tree with that and in order to sign he's going to use one secret key and to show the public key uh is contained in the miracle tree. So we give like the public key and an authentication path. Each public key is related to a secret key by performing a number of hashes and the idea is we are going to encode the message using something called incomparable encodings. Then each chunk is going to be interpreted as a number and that is the number of times we will have to hash the uh secret key. Okay.

And then the idea is that the verifier can check that this is correct by hashing the remaining number of times until he gets to the public key. Uh, of course, when we are doing aggregation and everything, we have to be careful about using the hash function for signing and then for simulating uh the random oracle. Uh, if you want, you can check this this paper that uh explains like all the implementation and all the subtleties. It's really interesting. So now we have to see okay we are going to aggregate using these um starks and so we have like basically two flavors in one case we use ordinary polomials. The

idea is that in general this is what for example SP1 risk zero uh zisk were using or are using but basically the idea is we want to prove that the computation is correct and this is reduced to a claim about certain polomial equations that have to be enforced over some table. Um in this case we have uh certain freedom to choose uh the finite field where we are going to work on. Um but we need it to be something called FFT friendly and then the idea is basically we get each column of this trace table. We interpolate it uh using

the FFT. We commit to each of these columns. And then basically what we do is we plug in these polomials inside the constraints that we want to enforce. And then what we do is we divide by a polomial saying where the constraints should be enforced. Okay. And to show that the constraints are then enforced, we do uh a lowderee testing. Okay. And this is the case of of fry. and we generate a proof containing u several merkel trees and everything. So this is a very uh fast and efficient construction but um in general this tends to yield um larger proof sizes because we have to interpolate uh each

column separately and we would like perhaps something a bit more more efficient. On the other hand, multilinear starks uh in general offer more chances for efficient arithmetizations. For example, there are um ones using R1CS but also air which is one of the candidates uh for a special VM or M3. So you have like a lot more freedom. We also have a bit more freedom regarding uh the finite field. The idea is here we use multivariable polomials and what we do is we get all the trace and we interpolate it just as one

polomial not every column and then the idea is we are going to use this efficient sum check protocol to show that the constraints are enforced and essentially what the sum check does is transforms this claim to an evaluation of this polomial at a random point. Okay. And then what we can do is use a PCS to show that um the evaluation is correct. Okay. This is a standard technique uh corresponding to the what's called the BCS compiler.

So um it's interesting that we can use two techniques combined to yield very fast provers and at the same time uh small proof sizes. Spartan is particularly efficient. So in general what we want to prove is something like the product of uh a matrix times a vector is equal to something. And so the idea is you can split it as uh a claim over some random linear combination over the columns and then this random linear combination over the rows. And this uh is particularly efficient. Then wear is uh a bit more

efficient than fry because it works over a variant of read Solomon codes that are constrained. And so the idea is that we impose over the witness some some conditions and the idea is that we're again uses a partial sum check and then does some folding and reduces uh all the claims and this way we we get smaller proofs than in the case of univariat starks. uh something that they released a few days ago was also bin 64 that is using uh a different polomial commitment scheme but has been used to prove aggregation of XM SS signatures and it shows to be very efficient even in CPU.

So it's interesting that we have a lot of research and implementations relying on different primitives. So if I had to sum up some of the differences between um multilinear and univariat in general multilinear have gotten like way popular because of like some advantages for example uh in in the case of the sum check we don't have to calculate like inverses or anything in general with multilinears we can handle better sparsity patterns and so not have to pay for uh the zeros contain the matrix we don't need to interpolate using the FFT and in general

because we can use where we can have uh shorter proofs and we also have like more options regarding uh efficient arithmetization or even the use of binary fields as for the VMs the idea is that of course we have different choices regarding the instruction set architecture whether it's customized or risk Five whether we will have like one table or several tables. what finite field koala bear baby bear the hash function ketchup or the less battle tested Poseidon 2 whether we are going to use circuits or lookup based arguments uh for example in the case of jolt that's very easy to to audit the

arithmetization the memory argument the PCS the good thing is that if we do it like very modular then we can easily switch uh one component for the other where we are going to have a recursive prover or a streaming prover to keep a memory bounded. But in the end, I think we will need more than just one design, especially when it comes to execution to avoid any catastrophic bugs because these general purpose uh VMs tend to have like very large and complex code bases. So why why build a separate VM for signature aggregation?

Uh well, this is going to play an important role in the consensus and so we would like to have perhaps a simpler design that just handles the necessary logic for verifying and aggregating uh the signatures and ensures small proofs. Uh it's easier to audit. It's easier perhaps to have multiple implementations in different languages. uh we can also have a design that can be used together with general purpose VM. So I think that uh it's worthwhile because we have like very tight constraints on what we would like on the signatures and then it's easier to reason and audit and all that. So as a

summary, quantum computers are here and they could break easy cryptography. So we need new primitives. We can have this by using snarks to aggregate these new signatures. And I think that multiar snarks are a very good candidate because they handle very well sparsity patterns and we have efficient algorithms to prove uh memory accesses and all that. A simple VM can be really really helpful especially if we want to prove in weak devices and not compromise decentralization.

If you want uh to continue talking I am here. Thanks a lot for your attention.