NFTs as Relational Databases | Rob Green - Runic Labs, Inc / Patchwork Protocol

[Music] my name is Rob um we'll do an intro in a second but first I want to get to the problem statement uh what we're trying to do is we want to have data records that relate to other data records all on chain and gas efficient that's that's the problem to solve right there there because if we can do that we can extend them all the way down so if a relates to B and B relates to C and C relates to D and so forth then we have a solution so uh my name is Rob Green uh I'm a currently a co-founder of runic Labs uh a vc-backed uh crypto Product Development Group um I came off of recently four years at coinbase uh I got there after uh developing with a team team uh product called paradex in 2017 um which was a defi exchange on ethereum mainnet um in the past I've worked for companies like IBM but I've spent a lot of time uh being an indie game developer over the years and uh I'm a lifetime uh computer and Technology hobbyist uh ultimately I don't think it matters that much I just felt like I had to say that but uh that the concepts matter far more than the person so let's get into it so um basic glossery here for what I'm going to talk about today uh I'm going to go over it with a little bit of detail even though some of this stuff you're going to roll your eyes and say guy I know what a 721 is that's fine but The Primitives are important so ERC 721 is the nft standard uh it's what many many nfts are today and if they're not that they're usually an ERC 1155 but an 1155 is actually uh only somewhat considered an nft standard it's a multi- token standard and more on that that in a minute um another really interesting one and uh I bring this up because I get asked about this one a lot is ERC 6551 and if you're not familiar with 6551 uh it's an nft bound account standard uh that I'll cover in a minute too um the uh the next term is metadata we all know about uh nft metadata um I'm going to go ahead and call that a record today as go further in but it's data associated with any one of these these three things and then a relation we're going to define a relation as a record with a two one or a to many relationship with another record so starting on ERC 721s these things are old we've had these since 2017 uh these were pretty much the foundation of the big nft boom that happened um but the the two really unique items or attributes about ERC 721s is that they are a unique address with metadata and by unique address I don't mean just the contract address I mean the uniquely address addressable piece of information so if you take the address plus the token ID that that describes a unique piece of data which is a metadata URL which leads you do metadata Json right and so in my example on the second line if you see the the well it's Taco Foods written out in HEX Okay taco Foods token ID 55 uh if we look that up it will it would take us hypothetically to um my.com 55. Json which would have something hopefully unique about token ID 55 at that address right so that's a unique piece of data um the other thing that's that's um a primary attribute about 721s is they have ownership uh that if you take this little bit of solidity here cast it to a 721 Taco Foods owner of 55 and abc23 that address owns it right now when I was first working with 721s I had people saying well when when are you going to do 1155 because 1155 are better 1155 is do more 11 55s are they're just 720 ones with batch transfer functions but um it turns out that's not exactly it uh I don't think they're going to replace 721s and I don't think they're truly a superet of 721s I think they're a little bit different the big thing about 1155 is that they are a balance of a token ID for an address they don't use the word address anymore they call it account and there's a good reason for this um I I assume is everyone here familiar with the r20s super basic right an 1155 is more like an erc20 for each token ID being that you can give a a balance of to a user so I can I don't I don't give you one I can give you five right and so if if the taco Foods contract is um is an 1155 and we check the balance of account abc123 for token ID 55 it'll say your balance is four right um the big thing about 1155 is there's no owner of they that that's not a standard function 1155 because instead there's just a balance that has implications when you want to get into Data relations um and all one of the biggest things is that 115s have a single metadata URL for the entirety of a token ID okay so there's not like if if if abc123 has five and DF 555 has 20 they have the same metadata they don't they don't that uh that first users five is can't be different than the other users 20 but 1155 is super awesome at what it is right one of my favorite use cases for it are commodity items so say you're building an app and you want to have something where you're issuing gold silver some kind of monies right uh bricks let's say in some kind of app um if you can see this would be an example sort of table that you would have in an 1155 and uh so we can see that there's one account uh 002 that has uh token ID 5,000 of token ID 5 12 of token ID 32 and then this other count is 33 of token ID 32 and then um these other two accounts say this is some let's say token ID is is um is like the in-game money or currency of some kind and this this account is 8 you know $821,000 and that account has 5.9 million it's really really awesome at this because with one call you can transfer millions of of the the quantity of that token ID to another user and that's something that 721 just doesn't do right so for this use case it's incredible but if you've heard about 65 51s and there was a lot of hype about them and the last year where where people were saying what about 65 51s these are going to these are going to enable everything they're going to enable all the all the composition all the relational data all these things um yes and no uh 65 51s are also amazing and they're very very cool at what they do um ultimately a 6551 is a proxy account owned by a 721 for every 6551 there is a 721 underpinning it and the way that works is that if Taco Foods let's say is now a 6551 contract I can call it and and if I own the 721 one of the the token ID at the 721 that creates that address I can execute code on chain on behalf of that address so the other contracts see the call coming from that 6551 account address and that's super powerful because that makes it so that if you own a 6551 account again underpin by 721 uh if you own that account you can own a slew of nfts you can have a balance uh let's say you want to collect a certain uh a certain bunch of nfts or something like that and then you want to sell them you want to sell them or transfer them to somebody you don't have to transfer them one by one you can sell this the the token ID at the 721 that owns all of it and that's that's something that you can do actually fairly trivially with a 6551 but there are some considerations you need to make if you want to use a 65 551 in this way um if you want to have a relational hierarchy with that you're going to have the the the 6551 721 problem meaning that the first 6551 that you own you have to you have to actually own the 721 and if you want that 6551 to own another 721 and you want and um and and that owns a 6550 that controls a 6551 uh you've got multiple hops to go through to assert the ownership um of that you have to have knowledge of of both so ultimately 721 is still the Primitive uh in in a 6551 and a lot of the things that you want to do with hierarchy you can actually do directly with with 721s um 65 51s also are a little more difficult because with a with a 721 you'll know if you go to that you know ether scan or whatever and you look at the address you can find what collection is this right how many were issued I I can find out things about it but if all you know is the address the account address of a 6551 and you don't know anything else about it because that's what you're going to have um your app own uh you don't really know what collection it belongs to you need more data than that the address alone doesn't tell you quite enough about it um also making contract calls and and front ends on top of 6551 is another layer of of um development that you have have to do to be able to handle all the proxying through and all that sort of stuff so let's imagine 721s have evolved a little bit for a second okay and instead of thinking them like you know I know a lot of people think of 721s as like pfps like all that is is some some art somewhere on a server but let's let's get rid of the idea for a second and let's think of each 721 as an address uh like a table with a schema okay and then for each token ID let's make that like the primary key and instead of metadata let's just call it the record but um as you can see offchain offchain data Json sorry offchain Json is a problem so if Taco Foods again is a 721 token ID 55 is at this URL I have to externally I have to go offchain and I have to go look that up and I can go read this Json that says that this relates to ff11 token ID 8 then I have to go back on chain I have to read about ff11 token id8 I have to go look that up I have to go offchain again to get the data this isn't that helpful right if I want to write it if I want to write a really robust onchain app there's too much that exists in servers that are that are outside of uh what my transaction can even do what my contract can do I also would then have to add a server to do that so if we can bring the data on chain we can solve that atomicity problem okay so let's imagine this is all on chain so we have a table here of data and the metadata imagine that there's some there's some onchain representation of this if I can read in a contract that taco Foods 55 relates to ff18 and ff18 has this data in it I can now write a contract that says um that says hey if you have ff11 uh any token ID on it I know what what the metadata scheme is and if your happiness is over 10 I'm going to award you with something or we're going to be able to perform some action right and so now these relationships actually become meaningful uh because all this is done on chain and we can also have data Integrity we don't have a situation where uh some server offline someone changed data someone pulled a plug these relationships can be created uh with with rejections if um let's say there's a violation or something like that so you're guaranteed to have data Integrity so real relationships start to look like this a 721 address and a token ID Rel to another 721 address and a token ID and once you bring the metadata online this all starts to become usable so how do we go from just talking about it and and or or having some like esoteric sort of um code that we wrote that doesn't matter to anybody else and and make this usable make this interoperable first we have to ask ourselves what does it mean to have onchain onchain metadata uh what about the ABI for interfacing between contracts that have onchain metadata and how do we discover other contracts and interoperate between applications and contracts and if you start with some definition just some definition of a metadata schema onchain uh given this one this is a very minimal form but with this this is complete enough to be usable right so if I Define my metadata as having a an array of these and each one of these is an entry and and so this represents a field each field has an ID a field type maybe the field type like un 256 or un 8 or um address right uh a field count so I could say I have 8 un 256s so now it's a static array um and then a key a human readable key so I can look these things up or so I can generate an ABI just from reading the metadata onchain and you add this function so at the bottom here if you can see the schema function you add this function to your to your 721 now other now you're allowing introspection okay so here's an example schema doing this those same four Fields IDs 1 through four field types un8 un32 string and here's a key one a relation field type it doesn't have to be a primitive in ethereum you can write a system that is aware of a relation with another 721 and you can have that be meaningful in a standard right and so we have we have keys on the side I don't know if I'm blocking it over here trying not to um keys on the side where these are the human readable parts and these could also be used to generate an AI and all this gives you discoverability so if I have a standard with this I can call a contract I can read the schema I can determine that these functions must exist I can know their return types and I can interoperate with it without having to know anything about the actual contract code itself in fact they don't have to publish the code it's fine the schema tells me everything I need to know so you might be asking yourself okay onchain sounds cool what about gas us I mean wouldn't this have happened happened before if if if uh it was cheap and easy to do well it turns out that if you just do this naively if you say all right I'm going to write an application and I'm going to put all of my stuff on chain uh that it it can get gas heavy ethereum mayet is a problem it is expensive um but there are actually a number of ways that you can optimize to reduce it uh we were doing some game design to do um a game that would run offchain and do rewards onchain but then we wanted to rewrite the entire game as web 3 and put it onchain and the first we ran into was we don't need to have 20 different fields we don't need to have a struct and and by the way if you think that um ethereum packs strs efficiently it does but if you has anyone uh used compiler Explorer before in the past there's a tool called compiler explore it supports solidity if you care about efficiency I recommend dropping your contract into it and see what it does um I believe it's at godbolt dorg um but uh it will tell you some very revealing things that happen that consume a whole lot of gas but you don't have to do that you can pack your data in and you can write your own routines that make it so that you you know consume like one field two field like two storage slots and you cut your gas down usage down dramatically to get your data online um also l2s have done an amazing job mitigating the costs it's a it's an order of magnitude cheaper to use an L2 and those didn't exist previously so can we make a full relational database management system on chain with queries and indexes and all that stuff uh not really not exactly the way you're thinking um it's it is it is so prohibitive to scan through large amounts of data on chain it's so gas prohibitive to do that that um that's not really the goal but the the main thing is that we can get a lot of utility just having the relations and the core data that we need on chain and we can bring Atomic transactions into play and and have data Integrity have ownership have inherit and stuff like that we don't need a full rdbms to do it so once you once you're in atomic transactions and what I mean by that is not reaching out to servers to read metadata keeping it on chain um you can create relations with data Integrity you can inherit meaning that if I have a if I have an nft A 721 that's a sword and I have another uh 721 that's a that's a that's called a red Gem and I want to assign the red gem to the sword to power it up and it's a one-time use rule in my game I can I can have that relation and now I can make it so the owner of that red gem 721 is the owner of the sword so that if that user ever transfers that sword the gem just goes with it it's still there the history is there the relation there um but that's something very powerful that I can do and I can guarantee it on chain with an atomic transaction okay and in fact you can get down to where um entire applications can deploy with only a client where you don't need server side components at all if you do this uh for some applications obviously it it varies um and you can take if if applications do this you end up uh being able to bootstrap off of one another where because someone's using the data you can start adding some data and gating off of theirs so existing 721s and 1155 aren't totally out you don't have to rewrite everything um you can you can extend them permissionless uh you can integrate onchain metadata with with what's existing offchain in my group we call it patching and all the stuff that I'm talking about uh I I wish I could have added more code but uh it it we've been working on this for about a year and there's thousands of lines of code to look at um but we do have an implementation but we've worked on all these features um and uh there's there's a whole lot there and I could talk for quite a while longer about this but that's pretty much the list um if you're interested in our implementation of this uh and what we do or you just want to use it as a reference uh got a number of links here and I'll give you a QR code at the very end if you want the deck and you want all the links as well and I believe the future of blockchain is more data onchain um richer data onchain I think that you're going to have app interoperability where an app shows up does something cool and another app gets an idea based on that one it does something cool up to piggyback it and I think that you're going to start to have apps with evm based backends that consumers are unaware of and what I mean by that is uh you can apply the the the parent test is by parent using something that's got a blockchain behind it and they don't even know right I think that's going to happen this is a QR code uh please for the deck please scan it if you want access to the resources or you want to be able to review or contact me or anything like that and I have 15 seconds left so I'm going to end there thank you