Session 3 Under the Hood: Vana Protocol Architecture

Transcript

Um we have Katav with us today. He's um the head of engineering and applications lead at VA. And like this is like I think the first technical session from VA like where he'll kind of like give a deep dive of how WA under the hood works and how VA protocol architecture works actually and how can you and the next workshop on Friday we'll actually discuss like how to build your first data D. So yeah, over to you Gaddaf. Thanks Muskin. How's it going everyone? Thanks for joining us. Um I'm based in Toronto morning but uh I know everyone is kind of around the world. So whatever time it is, thank you for joining. Um my name is Kataf. I am the um head of

applications at Open Data Labs. And as Minan mentioned, we'll be talking today about um the protocol architecture as a whole. So let's dive in. Feel free to interrupt me with any questions at any time. Um but yeah, so uh let's let's dive into an architecture overview. So fond solves the fundamental problem of um turning private data into a tradable asset while preserving privacy, right? And it does that by um through five core components. So uh number one like wallet is your onchain identity uh data dows secure compute L1 and the dual token system. So starting from the right side um your

wallet is your onchain identity and data contributors exercise ownership over their data through their wallet and all the data is tied to their wallet. And um moving on to data dows. Uh these are decentralized data collectives that uh exercise that aggregate similar types of data. Um and uh and then they do this by using our secure compute layer. And these are trusted execution environments that run proof of contribution uh enforce onchain permissions and um compute over private data while maintaining privacy.

And then all of that is kind of recorded um onchain. So uh the Avana layer 1 is an EVM compatible blockchain that's specifically optimized for private data. So things like uh data ownership records, cryptographic verifications, permissions, economic flows, they all live on chain. And we've got the dual token system that's powering all of this. So Avana is the native token of the network and VRC's 20s are issued by data dows that represent the underlying data set.

So u we'll dive into some of these components into deep deeper uh detail. So uh let's start with the L1 itself. So uh the VA L1 is an event compatible blockchain um which should enable familiar smart contract development. If you've worked with Solidity on Ethereum or other chains, you should be pretty familiar with how to build Pvana. Um it's powered by proof ofstake consensus and uh basically what that means is uh any kind of all the validators that are powering the network they have to throw up some stake to um to uh ensure that their incentives are aligned and any kind of uh um uh ill behavior towards the network results in slashing of that

stake. So they're all incentivized to um you know be truthful in how they operate on the network. Uh as I mentioned earlier, VA is the native currency of the network. It's used for staking, governance, uh paying transaction fees as well as paying for data access fees. And data dows issue their own tokens called VRC20s. And VRC20s are very similar to ERC20s but for data. So uh VRC20s are the tokenized representation of the underlying data set. And you can think of it as if FAA is the dollar, VRC20s are the company stock.

So if we move up one more layer higher, uh let's talk about smart contracts. So the protocol is powered by several key smart contracts on the network. And as a data D builder, you're going to be interacting with a couple of key smart contracts. So we've got the data registry, the DLP registry, the DLP contract, and the D pool. So, uh, if you're not familiar with smart contracts, they're basically like a serverside script that runs automatically when certain conditions are met. But instead of running on a centralized server, it runs on a decentralized network. And this allows us to build applications that are, you know, in in a trustless manner, uh, with

transparency and reduced reliance on centralized authorities. So the bond protocol operates through um a couple of uh key smart contracts. So starting off with the data registry. This is the catalog of all the files added to the bond network. So it merely stores pointers to where the uh encrypted data lives on chain offchain. We don't actually store the data on chain. And uh each data point is linked linked to cryptographic proofs that were generated by Avana's tees and uh any permissions that the user granted to any third party and pointers to the structured version of the data called refinements.

Um so you can see that uh in the smart contract itself is just pointers that uh point to offchain uh proofs, refinements and the files itself. And the DLP registry is uh where data dials um or or DLPs they can permissionlessly register themselves and manage where their DLP contract lives. And the DLP contract keeps track of um file submissions to the DLP uh distributes rewards to users based on the results of the proof of contribution.

And lastly, the TE pool which is the orchestrator of all of the secure compute that happens on the VA network. So it kind of load balances proof of contribution jobs that data dows submit. And so uh yeah the L1 and smart contracts their um permissionless infrastructure for building and maintaining data dows. It provides the foundation but the real magic happens um in data dows. Um so uh I won't go too deep into what data dials are but just as a brief intro um data dials are collectively governed data sets. So uh decentralized data collectives they um they aggregate

specific types of data um and so you can think of it as like um a pools of fitness data or social media data, financial data, medical data. Yeah, go ahead. Yeah, just like one thing like a lot of like folks here like they don't come from like web three. So can you kind of like dumb down little things like what does a decentralized network means like what does TE means like like that might do like new things for folks here. So yeah. Oh perfect. Yeah. Um no no problem. I'll um I'll go into some of these more uh uh web three concepts in more detail then um maybe I'll I'll stop here for any kind of questions about some of the topics I've talked about already.

um to to answer that question um what is a decentralized network actually mean in layman terms. So, think of it um as um uh if you're if you're talking about um Bitcoin, Ethereum, there is no one central party that runs the Bitcoin network, the Ethereum network. If um there's no central bank, um it's actually run by thousands and thousands of machines and computers all over the world that collectively decide that this is the next state of of the blockchain.

So uh it's um next to impossible to you know take control over and there is no central governing body. So that's what the centralized network actually means and bond operates in the same way. There is no one central node that that uh runs the protocol. Um it's run by several what's called L1 validators all over the world. Uh could I talk more uh about tokens and how they actually work like a VRC token? Yeah, for sure. So, a VRC token, a VRC20 similar to an ERC20 is basically a smart contract that operates on the VA network. So, um what where VA is the base currency of the network. It's used

to pay like transaction fees, um data access fees and stuff. Um VRC20s live one layer up above that. And it's a smart contract that um that basically uh has a set of rules built into it. And uh it's it's a um it's treated as a token that you can trade you can perform you know any kind of financial transactions on but it's specifically tied to the data uh that's represented by the data. So uh a VRC20 represents the value of the underlying data set. So if you've got a a data dow that's um let's just say the Reddit data dow um when you

contribute to the reddit data dow they will issue um uh an something called ardat which is their vc20 and this is the token that the data contributor gets back and uh it represents ownership uh in the in the uh reddit data dow and you can the the data contributor can use it to vote on on uh data access policies and vote on what happens in the reddit data dow. and so on and so forth. So, uh it's represents collective ownership within the data pool. So, I'll I'll move on there. So, um yeah, just to summarize, yeah, VRC20s is the tokenization of the underlying data set and um the rewards uh it's distributed to um data

contributors based on the data quality. So um after running proof of contribution um the data dials will know like oh this data point is um you know really valuable or this data point is not that valuable and we'll reward the user accordingly with the appropriate VRC20 token. So uh we've covered the L1, we've covered smart contracts and data dows. So now let's move on to secure compute. So how do you actually run compute over your data without ever seeing it? And that is the problem that uh TEES or trusted execution environment solve. And TEES provide like a hardware level

memory encryption uh and isolation guarantees to help ensure that no one can see the data that's being operated on uh not even the TE operator themselves. So the code runs exactly as it's written with cryptographic proof that the data hasn't been tampered with and this is called attestations. So anyone can verify that this um machine this trusted execution environment is running this specific code and it hasn't been altered with it hasn't been tampered with and the memory space that it's running in is encrypted.

So even if I have physical access to the machine itself, I can't plug something in to see the data that's being operated on. And we use a network of these machines uh in the VA network. And TE's themselves, they have various architectures. They're built in different ways. Um here at VA, we specifically use the Intel TDX architecture. Um so let's move on to how data moves around the modern networks. So the data life cycle and there's really four key stages. Um contribution, validation, refinement and data access.

So moving from left to right here, the data contributors will um contribute their data to a data D. The data dell will then validate um that data point and write the cryptographic proof of that data point on chain and they'll grant the appropriate permissions for that data and then the data dow will refine it and what refinement means is basically taking an unstructured data point and turning it into a structured one and this allows uh us to query the data. So um imagine u I'll talk briefly about uh refinements in a bit but uh at a high level imagine having a Amazon

GDPR export it's just a zip file of CSVs JSON is very hard to query um once it's refined um you can issue SQL uh queries against it so that's what refinements are and then on the other side once this data is refined and available you have um uh you have data buyer like AI builders, u machine learning engineers, um companies that want access to c certain data, they will come and access that data. So contribution, validation, refinement and access.

So zooming in and focusing on the contribution state. So your your data source can come from anywhere. Um and we really specialize in private data. So, your data source can be a GDPR export of um of off of platforms like Reddit, Facebook, Instagram. They they all offer uh a way to export data in bulk off of their platform. Um it can be an API request. So maybe um you ask the user to sign into their Spotify account and then once they've signed in, you can make API requests on their behalf to gather their Spotify information. It can be documents that they own. And it can be very multimedia like uh pictures, images,

videos, um scraped content off of uh private websites. So by private it means like beyond a login screen. So uh it can be scraped content once you've logged into your Facebook account for example. So whatever your data source is um your as a data dow it's your responsibility to guide the user to um get that data appropriately and then once they have that data uh it's encrypted with their wallet and then upload it to an off-chain storage and we recommend that this uh offchain storage be user owned.

So what that means is um it would be more uh preferential to upload to the user's own Google Drive account or the user's own Dropbox account as opposed to a centrally managed a DLP managed S3 bucket or a DLP managed uh storage. So um I I mentioned encryption earlier and I'll talk briefly about how encryption works in the von protocol. So starting off um with uh you've got some plain uh plain text data. Uh we we use something

called symmetric encryption. And what that is is basically uh you have a one random uh string that will both encrypt and decrypt the data and uh this string is generated by signing a message. So um for what that means is that uh as a web3 user um if you've got your wallet uh a web 3 app can prompt you to sign a message. So um for example uh in your MetaMask you can get a request from a web 3 app to um sign a message and this message can be anything. So uh in this example it just says signature request please sign 1 2 3 4. Uh that string it can be anything and then once you've

signed it with your wallet you just click a button and it generates a signature and this signature is unique to both that string as well as the wallet itself. So if everyone here were to sign the same message, it would output something different. But if I sign the same message over and over again, it would output the same thing. So uh the result of that is the signature. And that is the sign that is the the key that we use to sign the file. Um I've got a question here. Do you need to know uh web3 protocols to create data dial? Um at a very basic level. So uh by web3 protocol like signatures are are something that's pretty uh like a a

basic to any kind of web 3 um web 3 application. Um and actually many if you ever used any web 3 application it'll ask you to sign in and a lot of web3 apps they authenticate through signatures. That's how they know who you are. Um because once you have the signature and the actual um string that was used to generate the signature, you can um determine the wallet address and that's how many web 3 applications um know who signed in just now by asking you to sign a signature and the getting the corresponding uh signature.

Another question here on is using private data fully legal? Um I I won't go too deep into the legal aspects of it. Uh I think we might have a session for that, separate session for that. Uh I don't have a legal background, but we've designed uh the protocol to be um to work with private data in a fully legal way. Uh next question. Um data anom data anonymization such as PII PHI a relevant concept with this type of security. So u I'll I'll touch on the data anonymization during the refinement step. U I'll save that question for a little bit.

Um do you use TLS notary or hardware testation on top of TLS um standard TLS? Um we don't use TLS notary uh on top of um hardware testation uh at the protocol level. Um so uh if you're speaking specifically about how RTE attest um we've partnered with Fala uh Fala is a is the provider of RTEEs and um they've been in this game a long time and they have they have something called um follow cloud where attestations are um generated for us automatically.

Um clarify um why it's better to have users keep their own data like Google Drive. So yeah, that's a that's a great question actually. So um VA is uh if you've heard um any pitch from anyone here at Vana, uh the words you'll probably hear are VA is a network for userowned data. And uh what it means to um what it means for data to be user owned is that the data is actually owned by the user. They they should have control over it. um we're not breaking down data barriers just to put that data in another barrier. Right? So um me personally I would feel comfortable more comfortable knowing that I've

uploaded my data to a data dow and the actual raw data is sitting in my Google drive that I can you know have control over it at any time. I can delete it uh if I wanted to versus if I uploaded it to um a data dows S3 bucket that I have no control over and I kind of have to rely on the data D themselves to um delete that data for me. So that's why um it's it might be better to offer user own storage. Um so um yeah that's uh that's the encryption flow um basically using uh the signature uh as uh this the this encryption key and this allows us to decrypt the file um using that same

signature. So once it when it comes time to decrypt, we can just prompt the user to sign the same message. They'll produce the same signature if they're signed in with the same wallet and we can then symmetrically decrypt that file. And if we need to share the files with um a trusted um first with a trusted party, what we can do is um we can encrypt that symmetric encryption key with the trusted parties public key and that way it's it's a secure way of sharing that super secret uh encryption key with trusted parties.

So going down the data life cycle um moving on to the validation stage I want to talk a bit more about proof of contribution. So proof of contribution is the framework for data integrity in VA. It has four key components authenticity ownership uniqueness and quality. And uh so basically the point to proof of contribution is okay so you got this encrypted data that's sitting in storage. How do you know if it's actually valuable? Right? So this is where proof of contribution comes in. Um so the these the four categories authenticity uh is the data real and unmodified. Uh did someone edit it? Did someone generate it through AI? Um

ownership. So does the contributor actually own this data? Um uniqueness. Uh has this data dow seen this data before? like is the same user uploading the same data point um 10 times to just g get more and more tokens and and quality like how valuable is this data for the data D's purpose if the data D's collecting data for training an AI model um does that next data point really have a significant impact on how that model is trained so um to give you some real life examples I I'll talk about the chatbt data D so how they might prove the authenticity and ownership of a file is um if the

contributor exports a zip file and that has all of their chats in it from chat GPT, they can submit this file but also the link from the uh uh email that you get from OpenAI when your export is ready and then during the proof of contribution step we can compare the check sums. We can download the file from the link that was shared and we can compare it um uh to the check sum of the uh file that was uploaded by the user themselves. And how they might um solve for uniqueness is using something called um uh fingerprinting. So we can generate something called feature vectors which is basically a way to represent

um files as a a string. And if a a a small data point in that file changed, let's just say you changed your name, for example, in a 1 megabyte text file, um the files are more or less similar, but the fingerprint itself will will change slightly. It it's different than a hash. When even one bite changes in the file, the hash changes completely. So a fingerprint is a way to represent like uh capture changes within files. And we can sort load this up in a vector store and see how similar each file is.

So that way if people are tweeting small bits of it, we can we have some guarantees that uh you know maybe we've seen this file before. And um quality so the chatbtp might assess quality by taking sample conversations from their chat and evaluating it with another LLM. So um for the purposes of training NLM, you know, how valuable is this chat? Uh maybe it returns a score from 0 to 10 in terms of quality. And uh those are some real life examples of um how proof of contribution might work. And of course, it's very different based on the kind of data that you're trying to uh validate.

So there is no one one general proof of contribution that will fit all kinds all types of data. So uh next I'll talk about um the refinement step and as I was mentioning earlier um this is how we take unstructured data and um turn it into structured and queryable data. So with the Amazon um uh example I was giving earlier, if you export all of your data off of Amazon right now, you'll end up with a zip file that is uh you know hundreds and hundreds and hundreds of files long um containing like images, CSV files, JSON files, TXT files and so on and so forth. That that data itself

is useful but kind of hard to work with. So uh as a data D it's your responsibility to refine it into something more uh useful and uh queryable. So the standard we've chosen for this is libs SQL. LibSQL is a modern fork of SQLite and uh we're basically going to be transforming all of that raw data into an SQLite data point so that we can issue queries against it. So imagine being able to issue a a SQL query like like select star from orders where price is greater than 10 um to to get back some of the more expensive orders. Um that would be really difficult to do if your data is kind of

in this unstructured format. Um there was a question earlier about PII and uh during the refinement step you as a data D can decide is there any PII in here that's that's really um that's that's really sensitive that you might not want to include in um in your final refined form. So let's just say you've got uh a zip file of social security numbers. Maybe you don't want to maybe you want to just include the last three digits or the first three digits of the social security number. You can do that during the refinement step and basically mask out uh any kind of um PII that your data will never reveal. Maybe it's some guarantees that you make to your user.

Um and this is your opportunity to do that. So let's talk about um um the refinement in a bit more detail. Um so DLPs are responsible for uh um building a docker image that gives us instructions on how to transform this un uh this raw data into structured data. Um similar to proof of contribution, it's basically instructions for how to validate your data. Refinements is instructions on how to structure your data. And the way this works in VA is um for both proof of contribution and refinement, we ask that data dows um build a uh a dockerized uh image that'll run on on our secure

compute environment. So um we've got templates for both for both the proof of contribution as well as refinement um where you can basically get started um using Python to uh give us instructions on how to transform your data and work with your data. Um we've got uh services uh called refinement service. You can self-host this or you can use our hosted version that will take this docker image and it will take the um the decrypted it will take the encrypted data decrypt it and run it through your docker image and output a refined data set and uh as a as a precursor to running the actual refinement you have to register your your schema on chain. So what this means

is that you as a data dow maybe you are building the Reddit data dow um you've got a schema that defines all of the tables uh in your data dow. So maybe for specifically for Reddit you've got tables for posts you've got tables for users for comments things like that. Um we ask that you publish the schema on chain so any kind of data buyers can um trustlessly see that this is um what your data dow collects and and this is the format that it's in. And then once you've got the um refiners set up um a new data point comes in. We run your uh refinement docker image. We uh generate the refined SQL data point um encrypt it and then it's added to the

data registry as a refinement. Um and then I I'll talk a bit more about data access um uh which is the last part of the data life cycle u in the data access workshop that's happening uh in in a few weeks where we'll we'll talk about how this data is aggregated we'll talk about how to run compute against this aggregated data how to uh how to u price your data sets um so on and so forth so I've got a question here can there be hierarchies within data dow like polymorphic root with spec more specific leaves. I don't quite understand that question. Um Gary, would you mind um explaining that a bit further?

Yeah. Hi. Um so basically what I want to find out is like you have these classes right data classes where you say like preferences right there might be a data D for my preferences but then I have specific preferences for travel and maybe se specific preference for phones and so would there be like do you envision different dows for for travel and food or is it just my preference because eventually I might be interested in uh looking holistically as a human being's preference rather than oh and there may be some correlation. So do you have that in mind? Oh that's a great question. So u the way I I understand

your question is should should it should we have different data dials for different kinds of data and my rule of thumb for that is can you can the underlying token can the underlying VRC20 token accurately represent the data that uh is being collected by this data dow. So if you've got a data dow that collects data from five different sources, let's just say uh Netflix, GitHub, um Reddit, so on and so forth in the category of social media, um sorry, not Netflix, but like Instagram, um uh Snapchat, so on and so forth. In the category of social media, it's the social media data. But however um Reddit, Snapchats, um Facebook, these are all very different data sets and it

might not be accurately represented by a single VRC20 token. Uh in that case, um it would be better to split those up into five different data dows, you know, the Snapchat data dow, the Reddit data D. Um I have a follow-up question then. Yeah. And that is so if let's say that there are all of these different data dows is there a concept of creating a collection of the data from those data dows for some higher order wisdom. Yeah. So um I think what you're asking is um will will you have the opportunity or the ability to um kind of um query all of this data that all the data DS

are collecting um in a way that you can draw insights from other data DS as well and that is yeah yeah definitely so um the reason that we you know refine this data and put it all in a common format is so that not only that we can issue SQL statements to uh a single data dow but across data dows as well. Um, in the future, uh, in the very near future, we're going to enable the ability to run queries across various data. And you can imagine being able to run a query like, give me all of the sleep patterns for everyone that listens to punk rock music because maybe you're trying to do some analysis on your music preferences on how it affects your sleeping habits. And

that's definitely poss going to be possible. And that would be on the consumer side. Consu the AI AI side of things. Exactly. Yeah. Exactly. Thank you. Perfect. I've got another question here. Will Vana help us learn this proof of contribution or is this something that as a future data do creator we'll have to learn to do? Um and the second question, refinements is a service we can work with on VA if understood correctly. So that first question um will want to help us uh learn proof of contribution. Definitely we've got u a lot of channels for for you as builders to reach out to us on out on. So our primary channel is the vano builder discord where you can drop any

questions. I'm also happy to take any questions right now about proof of contribution specifically. Um uh but uh yeah if there's anything um that was unclear about what proof of contribution is or how it might work for your specific data set. Yeah, do let me know. Um, but yeah, you can always reach out in the builder discord to learn more. And, uh, refinement is a service we can work with on VA. Um, yeah, so the refinement service is, uh, is something that we've open sourced. You you as a data job builder can choose to host it yourself, but you can also use our Nvana's hosted version as well. Uh and basically what the refinement service does is takes your refinement docker image and runs it against every single data point that uh your data dow uh

ingests. So going um putting it all together. So we've talked a lot about um you know secure compute u smart contracts um a proof of contribution refinements. Now if we were to sum it up into one large diagram on summarizing how data is ingressed into our network, this would be it. Um so basically um uh so basically we've got on the left here the data dial UI. So the parts in green are the are the parts that data dows are responsible for building. So that in

this case it's their their contribution UI the contract the DP contract itself and the two docker images or that represent the proof of contribution as well as refinement instructions. Um what what's not shown here is the corresponding like VRC20 token. So that's also uh the the data that are responsible for. So, putting the flow together, you've got your data contributor that that lands on your um data. Let's just say they've got their Reddit data ready to go. They will encrypt it and they'll add it to the data registry, which is a smart contract uh inside the VA L1. Once they've uh added that file, anyone can add a file

to the network, but now it's your responsibility to validate if this file is useful or not. So um what we're going to do is uh you as a data de you're going to request verification from the TE pool which is going to assign a TE or secure compute to your job your proof of contribution job. Once a TE is assigned what we will send the encryption key and the proof of contribution docker image right to the TE itself. No middleman just uh the data dow and the TE and it will run that secure compute. It will decrypt the data point. It will run through your set of instructions that validate um if this data is useful or not and then it will generate something called a proof and uh this proof has

some metadata about um it contains assertions about the data. So the data itself is encrypted onchain. How can anyone come in and look at the the public blockchain and see that hey this encrypted data is actually valuable or not? So, if we're talking about the Reddit data uh point for example, uh maybe you measure value by how many DMs a data point has, maybe you measure value by um um how long the user has been active for on Reddit. Maybe it's 10 years, maybe it's three days, right? One is more valuable than the other. So, this these kind of metadata you can publish in in the proof itself. Um and these proofs are public. So obviously we don't want to reveal any private

information but just some sort of public metadata that has some assertions about what this encrypted data point has. Um we then we generate the proof and then we write it to the data registry. So along with this uh encrypted data point we have some proof that uh that makes some certain assertions about the data. And then going on to the refinement stage um in in a similar way we send the encryption key and the refinement docker image to the TE and it basically transforms uh that raw data into a SQL SQLite format and encrypts it and then also adds that onchain adds a pointer to that onchain. So now the data

registry contains the encrypt the pointers to the encrypted file the proof and the refined data point and then once you have all that um the data dow you the data dow will reward the user with the appropriate VRC20 token for their contribution and that's the uh the workflow here. Um so that's all I have for for today's session. Um, I want to thank you for for taking the time uh out of your day to attend and uh yeah, I'm happy to take any uh questions that you might have.

Thanks. Uh any questions guys? I know this is a lot. It's it's not that uh simple to explain like VA's architecture. It's like like they're kind of intersection at both crypto and AI and that's a lot going on. So yeah just like I think ask all the questions you have about proof of contribution TE's how data storage works like whatever questions you have like we're here to answer if not here like just like bring your questions on discord as well like uh kataf and team will be there to actually like help you out there so yeah but yeah we still have 20 minutes if you have any questions uh of there's a question in the chat yes if you want to take You're on mute. Oh, sorry. A quick run

through of data validation considerations for the capture data dow. Can you give an example of data validation query test quality attestation in the context of another existing data dow like Reddit? Yeah, for sure. Um, great question. So, I'll go back to contribution. Um, the the four metrics being authenticity, ownership, uniqueness, and quality. And I I'll talk about how uh the reddit data might do it. So um uh authenticity and ownership um the way I recall the reddit data doing it is um we asked uh we asked them to like the the data contributor we asked them to make an edit to their profile. uh we generated a six-digit PIN

and we said, "Hey, go go go put this on your profile and then once they done that, we would um look at their profile and see if they have that PIN on their profile." So, this allowed us to verify that yes, they actually have uh ownership over the account that they say they do. Um in terms of uh uniqueness uh I I believe what was done there was um uh the fingerprinting technique that I mentioned which was to take the some of the meteor parts of the export and generate a fingerprint from it and keep it in a vector store um where we can see that um that fingerprint is generated through their posts through their comments uh and things like that. um we would be able to see that if this person

duplicated the file and changed the username for example that fingerprint would remain more or less the same and we would know that uh this is a duplicate file. Um and in terms of quality um I I don't remember the exact metrics but one of them was um age and you can actually um it it was age and I think it was like the number of posts and comments that they made. So um we we saw that uh some people were just creating an account and then without having any data in it they would just export their zip file and submit it to the Reddit data dial and um the quality score would be zero because you have really no content there's no meat

in that export. Um so that's how that was addressed. Um how does the network scale with the addition of storage? Um, have you tried integrations with IPFS, Filecoin, ARWeave for decentralized storage? Yeah, that's a great question. So, I didn't talk too deeply in about storage and how it works on the VA network, but the protocol itself is agnostic to the storage protocol that's used. So um we use IPFS primarily to store the cryptographic proofs and the refinements but the raw data the data that the DLPs are the data dials are collecting um we don't make any kind of um uh assertions or or or any kind of recommendations

about where that data lives other than we recommend that it's be userowned but as a data dial you know you can choose where that that data lives all we really need is a URL URL to the publicly available but encrypted data point. So if that's on IPFS, if that's on Filecoin, if that's on an S3 bucket, you know, that's the data D's uh prerogative. Yeah. Um can you explain the whole topic in brief? Uh Omar, can you uh explain Oh, sorry. Can you clarify the topic um that you're speaking about here?

I I'll wait for a followup from you before I I dive into that one. I'll move on to the next question. Um do we learn how to create a fingerprint to learn how to look for uh discrepancies? Yeah. Um I can point you to a repository that we have for generating um such fingerprints. Um yeah, I don't have a link off the top of my head, but I'm happy to share that with you after this call. Well, and that's just one one way to um to look for for uniqueness. You know, there could be another other ways as well. US as a data dial maybe um you take a hash of certain properties within the file. Maybe the username, the if we're talking about Reddit, for example, it doesn't necessarily have to be a

fingerprint. Maybe it could be a combination of the username, the check sum of the file, when the user joined, a combination of a couple of key properties and then maybe you take a hash of that and that can serve as the fingerprint non techies. hoping we can understand. Yeah, definitely. Um, so I I think we have a lot of uh, you know, non techies we in our builder community. So, um, we're definitely working to make sure that we have the appropriate templates and examples ready so that you don't really need to know some of these deeply technical concepts in great detail before you can start contributing.

Uh, next question here. So what are the key considerations for designing proof of contribution function for DLPs to balance data quality and contributor incentives? Are there any default uh are there any templates and tools provided by Bonnet to simplify this? Yeah, great question. So key considerations for um contribution. So you as a DLP, you it's your responsibility to make sure you know the highest quality data points get through and we're not incentivizing like lowquality data points. Um so I think if you do that, you're kind of setting yourself up for uh botting and uh just

spam in general. So uh you as a DLP it's your responsibility to to set up a really you know high quality proof of contribution even if that means some um data contributors will be rewarded less just because their data maybe is not that inherently valuable. Um so do we offer any default templates? We have templates for um for for everything that I've talked about here today, including the the the data UI, the DLP smart contract, the proof of contribution, the refinements. We have templates for all of that. And uh I believe there's session, I think it's the next session, um how to create a data dial. Um one of our one of our team members will walk um walk you guys through exactly all the

steps needed to create a data dow. And we've uh built this tool um very recently uh which kind of abstracts away a lot of these complexities. It's just issuing a few command line commands and you will have all of these set up. Uh I've got a I see uh Nissan's hand raised. So Nissan, go ahead. Hi. Um I just want to bring back something odd said yesterday about talking to AI builders and um I'm part of Build Club as well, one of the representatives in Brisbane. Um, a lot of the questions people are asking is like how do you get this data? Um, and how do you think about manipulating it?

There's this concept in data science called data wrangling. Um, you do not have to be technical to understand how to take some data and manipulate it to what you want. But you probably need to talk to the more technical folks about what you're getting from these data exports because this is private data um, and how to transform it into what you want. So, one step I would say is like if you're a little confused about the private data that you're trying to consume and how to get it to the state you need it to be, um, maybe talk to one of these AI builders in that club about what's a way to like change that up and maybe partner with them if they if they're not here in the academy to ask them to join you in the academy.

Yeah, definitely. Thanks, Tan. I'll move on to the next question here. How does the file URL management work as the data uh on the user side if it gets updated continuously? So yeah, that's a fantastic question. So uh every new every contribution is a new file in the network and um you you as a data dow can can decide what how you want to treat updates to the same file or uh contributions from the same user to your data d. So um you might have you might be building a data dow for uh streaming IoT data and uh these kind of data dows they will submit data from the same user

multiple times maybe even multiple times a day. Um uh you as a data dow should be responsible for figuring out if you want to um just capture the delta between every submission or if you want to write the entire file on on chain. um just whatever is more most valuable to your data D. Um if you're if you're talking about uh the Instagram data D where you just collect like GDPR exports from Instagram, um maybe like 90% of the data won't change between submissions, but but maybe 10% of the data will just because the user has had more comments, they've posted more to Instagram, but that GDPR export still has all of the data from day one. So u maybe in

subsequent submissions you don't include the old data that you've already seen before and and that's really up to you on how you want to handle updates between u uh yeah updates of the data. Next question. Um say the data contributor has their data on Google drive. Is that copy of the data kept within a data dow? U maybe kept within uh on AWS. So we recommend that uh no uh DLPs and data dials should not make a copy of the data and this is primarily due to of course privacy concerns but also that makes uh that makes data dials um uh a data processor under GDPR laws.

So we we're trying to do everything we can to make sure that data is um being handled in a way that's decentralized and secure and we offer all of that infrastructure so that data dials don't need to worry about it and um uh we recommend that yeah it's highly recommended actually that you shouldn't make a copy of the data and that if you need access to the data itself you go through the data access channels which uh we'll talk about in a in a subsequent um uh workshop. No problem.

I think we've got a few minutes left still. If there's any more questions, u happy to take them. Uh I guess that's all the questions that we had. Uh oh, there's another one. Oh, I just got another one. Um key considerations for proof contribution function. Um can you revisit this? Uh Sam, was there a particular um uh topic or or idea that you'd like me to revisit about contributions?

Uh dynamic pricing. Um sure. So I think what you're referring to there is how do we figure out um if two users submit different data points, how do we figure out um um what to uh incentivize them with? Like how do we reward them appropriately? So um in the proof of contribution function everything it boils down to the four scores of authenticity, ownership, uniqueness and quality. uh each score ranges from 0 to one and then we've got a final overall score uh of 0 to one that represent that data that data point that file and in your DLP contract um we take that score and we multiply by some multiplier that that you pick and that

is how much uh how many tokens to reward the user. So to give an example of that, if u in the Reddit data dow you've got a brand new user that submits lowquality data uh maybe their uh their score in the four categories is like very low you know 0.1.2 and then their their final score which is uh again a formula that you as a data builder decide is very low like 0.1 you take that score and then you take that multiplier that you decide as well to turn that into number of tokens. So maybe 0.1 times multiplier results in like one arith token. Whereas if you take a high quality file that received a score of one, you multiply by that same

multiplier and that results in 10 Arduct tokens. So that's the template that we have for dynamic pricing. But of course, if your use case is way more custom, you you're free to modify that that yourself. Uh, do data dows get incentives from BA for data collection like double XP? Um, I I think what you're asking is um uh the data dow reward system. So we we uh so um we reward data dials with liquidity of their VRC20 token. So um we'll talk more about that in um in the VRC20 session, but basically um liquidity is really important when

you're launching a new token and launching a new um VRC20 token. So um for data dows that are very active that have a lot of users contributing to their data dow that have um users accessing that data, we reward them appropriately with liquidity to their um VRC20 token pool. Is there a road map of um of how we build as you mentioned? Um so I I'll talk we'll talk a bit more about that in the created create a data dial session.

I think that's the next one that's happening on um basically the key ideas that you need to understand when we're building a a data dial. Um the proof of contribution is public. Correct. Have you seen real world instances where data buyers are skeptical of the attestation provided by proof of contribution functions? Um yes. So the proof of contribution function is public and um we similar to for both the uh proof of contribution function and the refinement function we we require that these are publicly available GitHub repositories. Um, the reason for that is if me as a data contributor, if I want to see what's happening with my data,

regardless of if it's on a secure server, if the code that's being executed, I need to be able to trust it. Um, if I care to look and um I I want to be able to go to a data and see, oh, hey, this is how they're evaluating my data point. Oh, this is how they're structuring my data point. Um, if they slide in some code in there to copy that my data point to an S3 bucket, I'll likely not, you know, contribute to that data point. uh to that data depth. So um have you seen real world instances where data buyers are skeptical? Uh if they are they're uh they they can basically go to the the public proof of contribution the public refinement images and see how their data is being handled. Um so the the protocol itself

doesn't make any assertions about um you know what the the the proof of contribution should do. We just assert that you know it should be public and testable and verifiable so that if any of your data contributors um question you or if any data accessorers question you you can point them to the repository. This is how we handle your data. No worries. No worries. Um VC 2015 Oh, go ahead. I have a quick question on the VA. You had mentioned something about VA. Vala. Yeah, the follow network. Go ahead. Is that something I can Google or uh Yeah, I I'll drop their um

uh their website in the chat here. Great. Thank you. Follow. And basically, these guys have been in the game for quite some time and they are one of the leading vendors of TE's in the web 3 space. And um they recently rolled out something called the follow dashboard where you can deploy a te uh within minutes and be able to deploy some code against it and have a full attestation report of what this code is doing that you can share with anyone. Perfect. Any other questions before we uh end the session here? I think that's it. Yeah.

Perfect. Well, I want to thank everyone for attending their session. Um, taking some time out of your day to learn a bit more about the protocol and the architecture. Um, as always, I'm available uh in the builder discord. Feel free to reach out to me there. Um, so thank you so much. Thanks everybody. Thanks for joining. All right. Bye. Thank you. All right.