Digital Objects: What, Why, and How

Transcript

Awesome. Uh, great to be here at DevCon. I'm Gupche. >> And I'm Rob. >> And today we're super excited to be telling you about digital objects, a new technology that Zerox Park has been building on top of Ethereum. But before we do that, uh I believe that Rod has something that he wanted to show me.

>> Yeah. So, one of the things we've been building on top of Digital Objects over the last few weeks is a game experience which demonstrates the core concept of digital objects. And so, I'd like to take you through uh a playthrough of that game. >> Awesome. All right. So, can folks see this? Okay. So, this is Bitcraft. Um, Rob, can you tell me a little bit about what I'm looking at here right now? >> So, what you're seeing on screen right now is a file explorer. And on the left hand side of the file explorer, we can see two files. There is a BitCraft uh welcome markdown file and there is a BitCraft pocket knife. DOBJ file.

>> Cool. So, I'm going to go ahead and get started playing the game. So, let me read the instructions under Bitcraft welcome.md. Uh, it says, "Welcome to Bitcraft. Bitcraft is a crafting game. Your goal is to scale production of wood, stone, and iron. Every item in Bitcraft is a digital object, a cryptographically certified DOBJ file that lives on your computer. How do I get started? Left click on a D OBJ file to view details about it. Right click on a file to see a list of available actions. All right, so let's do that. I'm going to leftclick on Bitcraft pocket knife.dobj.

And it looks like we've got a description here. It's a basic tool for gathering wood, stone, and iron. That's exactly what I want to do in the game. And then there's some various uh cryptographic identifiers. So, we can also click this uh view raw button here or double click this and we get something that looks like a file. You know, it's some text. We can pretty print it. And we can see that uh okay so whatever this file is it is of class pocketk knife. It has some kind of cryptography uh under a field creation proof and it's got some various cryptographic identifiers. Okay. So with this pocket knife the instructions told me to

rightclick and select an action. So I'm going to go ahead and gather some wood. All right. So now we've got this gather wood job running uh in the background. And presumably what that's going to do is that's going to create a wood digital object for me. And in the meantime, I'm just going to take a closer look at this pocket knife to try to see if I can understand what's going on. So, um, okay, if I click on the class name, Bitcraft pocket knife, I see that there's some info about what I can do with the pocketk knife. And, uh, I can also see the source code of the pocketk knife class. So this is basically some specification that defines what does it

mean for this particular that this particular digital object is a pocket knife. Okay, looks like my job is done and I now have some Bitcraft wood. So I've got my pocket knife over here and I've got some wood. So this wood is clearly like a different kind of thing than the pocket knife. Um but it still has that same kind of file structure and rather than being a pocket knife, it is of class wood. So, we can take a look at the wood uh class, and we can see that there's all sorts of things that I can do with wood. Um, and that wood also has its own source code defining what it is.

Wood's a little bit more complicated than a pocketk knife. And if I wanted to read through all this low-level cryptographic code explaining what wood is, I could do that. Okay, great. So, um, when I look at wood, it has a different set of actions that I can perform. It looks like I can craft sticks from the wood. So, I'm going to go ahead and do that. And what this is going to do is just like executing the pocket knife action allowed me to create some wood, this craft sticks action is going to allow me to create some sticks digital objects. So, it looks like that's finishing up just about now. And while we're waiting for that, let's just take a look at what's actually happening

because there's a little log here that shows me what's going on when I'm actually doing one of these digital object actions. So, we can see that um it might be a little small for folks in the audience, but uh there's some proving going on. There's some sort of Ethereum transaction going on. Um I don't have any cryptocurrency. I'm not running a blockchain client or anything on this machine, but some sort of cryptography is going on in the background. And the result is now my wood has disappeared and now I have two sticks files. Okay, cool. So, I actually just got a notification from Rob uh that he's sent me something and uh it looks like Rob is interested in initiating a trade. So, Rob on his

machine has uh crafted a wooden axe. And uh maybe what we can do is we can we can do a little trade here. So maybe Rob will give me this wooden axe and I might give him some sticks. So let me take his wooden axe object and I'm going to go over here and I'm going to import. So I could either upload it as a file or I could just paste the raw serialized text. I import it and okay, cool. Now I've got a wooden axe in my inventory. Right. So, this wooden axe has a little uh caution icon, though, and it's telling me this file was recently imported. Someone else on the network might have an identical copy of this file. Well, that makes sense to me because Rob just sent me that text, so he's probably still got it

on his computer. Um, you can fully claim this item by rekeying it. This invalidates all other copies of this file on the network. Okay, great. I'd like to make this wooden axe, you know, my own. I'd like to invalidate Rob's copy. So, I'm going to go ahead and I'm going to do the rekey action. And uh something's going to happen there. There's going to be some kind of like cryptographic operations, some kind of proving um shrinking proof, transaction recorded, submitted proof. Um and now you can see that that old wooden axe is no longer valid. And I've got a new wooden axe here. I can check the contents of it. This is my wooden axe. I can check the source code of it. Um this is the source code of a wooden axe.

Okay. Um, so a wooden axe has some more state. A wooden axe has durability. Uh, the description says it chops two wood per use and breaks after 100 uses. Can be upgraded to a stone axe. So the wood axe that Rob just sent me has 100 durability. And let's try chopping some wood with it. All right. So what I did was I rightclicked on the wooden axe file and then I hit use wood axe. And we're generating a proof. Same process as before.

Looks like this process, this proof is taking a little longer. Okay. And we now have uh two woods, two uh digital woods, and we have a new version of the wood axe that has 99 durability. Great. Okay. So, um, what I can do now if I want to finish out this trade, you know, I might give Rob some wood and some sticks as well, uh, as a thank you for his axe. So, that's as simple as me just copying the wood, going over to signal, sending it to him, and now he can import that wood uh, just as I have imported his wood and axe and rekey it to make it his own. And that trade is complete.

Okay, so that's Bitcraft in a nutshell. Um, basically this is a game that we built. It's the first application on top of digital objects. Um, the game uh can get pretty complex and pretty deep. You can also play it with claude or codecs or any agent of your choice. As you can imagine, all of these kinds of operations proving crafting building up factories and refineries. They're all automatable and there's a pretty deep crafting tree and a set of things that you can do. Um, so it's kind of like imagine uh Bitcoin combined with Factorio, but you can play with agents.

Um, yeah, one thing that's been really interesting about this actually is that agents are very very good at playing this game. So later on we'll send you a link to Bitcraft, uh, if you want to try it out yourself. But with that, uh, we can get into what are digital objects. We're going to spend the rest of this talk telling you about what exactly is going on here and how this works. So I'm just going to quickly switch over to speaker mode. Oh, actually I think I can't. Okay, no problem. Okay, so what are digital objects? Well, first of all, let's review what we just saw. Let's take a look at the life cycle of a digital object. Kind of generalizing what we saw

with the digital wood and digital axes. So, first off, uh, every digital object has some kind of type. you know there's some class that defines uh what kind of digital object is this and what is its behavior. So classes have a constructor just as we saw with the wood it takes a pocketk knife and some kind of cryptographic operations to create digital wood. So uh basically when that constructor is called that's what allows me to create that digital object of that class for the first time. Um there's also mutation functions. So, as we saw with the axe chop wood, when I call that function on the axe. DOBJ, that's going to call some code and update the state of the axe and possibly have other side

effects like creating some more wood. Um, some mutations actually destroy the object. For example, we saw when converting wood into sticks, the wood was spent or consumed uh and then something else happened which was sticks were made. We also saw that we can send digital objects because they're just files. And on the other end, we can receive digital objects and verify that they are uh actually what they say they are. They are they're validly formed. They're cryptographically certified. Um they haven't been double spent. All of that information lives in a file and a tiny tiny check to a peer-to-peer decentralized network.

So this is very generalizable. This kind of pattern of digital objects that you can, you know, uh, create, mutate, program, send, and receive can apply to just about anything you could imagine. So, if you wrapped like a stable coin as a digital object, then sending some of that stable coin would be as simple as texting someone a file. Okay, so with that, we can get to the kind of full definition of what digital objects are. Digital objects are programmable state machines that retain their integrity and consistency across trust boundaries. to break down what that means. The first part, they're programmable state machines. State machines mean that digital objects carry within them some kind of state and they also carry some code that specifies a

state transition function. The stuff you're allowed to do to modify that digital object. They're programmable, which means that just like you saw classes that we defined for wood, pocket knife, wood, axe, refinery, etc. you can write in a more or less touring complete language uh any kind of digital object any kind of state transition function you'd like. The other part is that they keep their integrity and consistency no matter where they go. So the first part, integrity, means that when I receive a digital object, even if I don't trust the person who sent it to me or anyone on the chain of who's held it or mutated it or handled it in the past, I know because of a cryptographic certificate that that digital object has only been

modified according to the rules that were programmed into it. Consistency means something similar to blockchain solving the double spend problem. So there might be multiple ways to mutate a digital object and uh more cryptography and consensus ensures that the digital object that I'm receiving is guaranteed to be unambiguously the latest state of the digital object. So I can't mutate a digital object like my wood axe one way and show it to Alice and then mutate it a second way and show it to Bob and try to confuse them that way. Right? there's exactly one state of the digital object and everybody who uh is on the network can be sure of that.

And finally, as we saw, digital objects don't live on any server. They're not onchain in any sense. They live on someone's computer. So my computer, if I actually go to um Oh oops. Oh, one second. Okay. Well, anyways, if I the the point there is if I open my file system to that exact path that you saw on the BitCraft inventory listing and I uh just ran cat on one of the files, I would see that that digital object literally lives on my computer. It's not on chain. It's not on a server. Um it's entirely local and all the computation and mutation on it is local. Okay. So, why is this useful? Um we imagine that digital

objects are useful in any case where multiple mutually untrusting parties want to operate a stateful system. Okay. So as an example we have Bitcraft which is a crafting and trading game. Another example of a stateful system is let's say a network of banks, individuals or institutions transacting assets keeping track of credits or debits. Another example is maintaining residency records across jurisdictions. Maybe you've got multiple governance governments. there's people who are moving between these governments and what you'd really like to have is some kind of system of record for who lives where.

So the usual solution when we want a multiplayer stateful system, whether that's a multiplayer game, a financial network, or an enterprise system of record, is that we promote someone to basically keep track of all the data and be the person who's responsible for serving requests on the data and updating the state of the system. Right? So, uh, there's a lot of places though where that doesn't work. For example, if I want to track residency records across a bunch of different governments, it's unlikely that any of those governments is going to be willing to give up its uh system of recordkeeping power to some kind of higher authority. That's kind of what sovereignty is. So, in other words, there's no world where we could have some single computer or operator or company or something that is holding a

database that looks like this, even if we'd really like to, right? I don't know if any of you guys have had the experience of trying to move residencies and move all your documents between different states or countries, but this is very difficult and it's largely difficult because different governments have different systems of record. Okay. So, um digital objects provide a solution. If you can model your overall system in such a way that these cross system of record updates can be modeled as passing around bits of state um then you can use digital objects to pass around those bits of state. So now let's say that Alice wants to move from India to Texas. Rather than India and Texas having to agree on some company to hold the residency records of both

jurisdictions, India can simply send a digital object to Texas and that transaction, that residency moving would basically happen atomically. Okay, so that's a bit on the what and the why of digital objects. Now Rob is going to tell us how they work. >> Okay, I'm going to try and explain the whole thing in basically three minutes. Um so um the fundamental building block of this system is recursive zero knowledge proofs. Uh that's the thing that allows you to hold a state locally uh but still prove that you're following the rules. Um and that allows us to do things like taking the previous state of an object, applying a state transition function to it and proving then that the new state of that object is valid. So we

take a proof about the old state. We use that as an input into the proof about the new state. And that allows objects to evolve over time while proving that we're following the rules in how we do that. And it also allows things like for example proof from Bob and proof from Alice being combined together. So they can make a joint transaction which uh allows for the creation of an object, but it might also allow for a swap or some other kind of joint operation. Um, and they can do that because they they produce individual proofs that then get recursively combined into the transaction proof uh, which then gets posted to the consensus layer.

And we do this using a system called pod, which is something that we've been developing at zero x park over the last couple of years. And you can think of pod as being kind of like a zkm, but instead of being for risk 5 op codes, it's for logical operations. So we have these logical operations like contains or equal or greater than and each operation takes some arguments including uh values but also including Merkel trees or previous statements um and it will then produce new statements. So you can build up this kind of like logical proof tree uh of the thing that you want to say and then each statement is extensible. It can be reused and recombined into new uh logical statements that appear in later proofs.

So we looked at some actions earlier uh in the BitCraft app and those actions are defined using podlang. Um this is the action for crafting an axe. So we we do various checks. Uh we check that the um axe for instance has uh durability. Um we're going to delete uh the old axe and we're going to upgrade it to to being an iron axe. So you can see that there's code for doing those things. And each object each uh the axe the wood the refinery has a set of these actions and these are basically the state transition functions for the state machine.

And in fact transactions are pod lang as well. So we have a transactional system which verifies that all of the actions were performed correctly. You can think of this as playing the role that the EVM does uh in Ethereum. This is the thing that kind of makes sure that uh the code is actually validly executed except in this case this is about 150 lines of podlang. um which you then generate as a proof on your local machine and you post that transaction to the network. So as we talked about earlier, we want to know like which state of the object is valid. We can produce the proofs locally, but we need consensus about which is the latest state. So we do that by assembling a transaction locally. We post that to the network and that then goes into a global nullifier and commitment set.

This is done using some infrastructure. Um so we have the driver which is the thing that you run locally. Um there's a relayer which posts things to blobsp space. There's a synchronizer which reads things from blobsp space. And there's an archiver which persists the blobs uh for data availability. And this allows you to find out the current uh nullifier and commitment set uh for the network. And that is basically how it works. Uh I'd be happy to talk to people afterwards if you want to know more details. All right. So to close up we want to talk a little bit about the relationship between digital objects and lean Ethereum.

So, we mentioned at the beginning of this talk that digital objects are built on Ethereum, but what does that really mean? Because everything we've seen doesn't use smart contracts. We don't use the EVM. We don't store objects on chain and uh we don't use any kind of cryptocurrency. So, what are we actually using Ethereum for? Well, the key insight here is that digital objects sees Ethereum as a cryptography content delivery network. So for those who aren't familiar, a content delivery network is a system that ensures that data can be made accessible to users across the world.

And uh the way that we see lean Ethereum is that it ensures that cryptographic artifacts like hashes and proofs are available and accessible anywhere in the world in addition to providing some ordering guarantees and and uh other artifacts of consensus. So like a CDN, Ethereum is responsible for ensuring that any of these cryptographic artifacts that our system is using is publicly available to the entire world. Um the other phrase that's been used is uh Vitalik recently tweeted about Ethereum as a a vision for Ethereum as a public bulletin board and this is exactly the sort of thing that digital objects requires Ethereum for. We just need the strong data availability guarantees. We don't need the runtime.

We don't need anything like that. Okay. So we use Ethereum in this way, but how important is that really? How loadbearing is it? Well, it turns out that digital objects and constructions like it crucially need lean Ethereum. They simply do not work without something like this. Because if any single hasher proof on the digital objects network becomes unavailable, the entire digital object system can no longer guarantee that consistency uh property that we mentioned earlier. So we need cryptoeconomic level guarantees that all hashes and all proofs on the bit uh on the digital objects network have been made available at some point.

Additionally, as lean Ethereum scales, digital objects scale for free with it. So there's a throughput to the digital objects system. how many object updates can happen per second that solely depends on the throughput of lean Ethereum um as well as you know our computational infrastructure such as local proving um so that means that this straw map that Vitalic posted just recently is very very important for us so in particular today the digital object system can handle about 1.5k object updates per second and that's directly tied to the data availability throughput of Ethereum but if the entire long-term from lean Ethereum straw map is realized and Ethereum gets to a level where it

can process about a gigabyte of data availability per second then that puts the digital objects uh TPS in the millions so digital objects needs lean Ethereum we really hope to see that straw map uh be realized and we'll conclude by just telling you guys how to keep up with this if uh keep up with the network and the game if you're interested if you want to play Bitcraft Alpha you can go to bitcraft.sh SH and play exactly the thing that you saw on the screen, uh, Factorio for agents cross Bitcoin. It's currently in early development with a mainet release targeting early 2027. You can follow digital objects at digitalobjects.dev.

We have an experimental test net live, which is what that Bitcraft alpha uh, build is running on, also targeting a mainet release next year. And you can follow POD, the uh, customuilt ZKVM for composability recursion and programmability at pod.org. Uh this is ST as standalone infrastructure is usable today but is not yet audited. As always everything is open source and permissively licensed. >> Thank you so much. We'll take questions. >> Thank you. >> Awesome guys that was really really cool. >> One one question that I had just as I was listening to your talk. Would it be possible to have these digital objects like have private state? So like for example like I have some records in one country and I want to send them to

another. like is that possible to have private state for these digital objects? >> Yeah. So actually by default all digital objects are private to the holder. So if I have my wood or my wooden axe or or anything on my computer, no one on the network knows the contents of that wood or wooden axe or whatever, they don't even know that I have wood or a wooden axe. So actually by default digital objects already are private to the holders. >> Awesome. Um, one question that got a lot of up votes is how do you maintain consistency if objects are mutated offchain?

>> Yeah, so this is a great question. Um, the computation of the mutation is happening offchain that's happening locally. However, we essentially register using a zero knowledge proof that some valid mutation occurred onchain. So, we're going to broadcast a zero knowledge proof of some state transition. because it's a state uh because it's a zero knowledge proof, you don't actually no one on the network actually sees what object was mutated or how. But that still ensures the consistency. So anyone who does receive the state of the object can tell that that was indeed the correct state.

>> Another question that I was also like uh wondering uh is who pays for the gas for posting it to Ethereum? >> Yeah, so one of the really wonderful things about the recent upgrades to Ethereum is that they make blobsp space incredibly cheap. So rather than paying, you know, 21,000 gas minimum for a transaction that goes through the EVM, if you're just posting to blobs, then that is super cheap. So in fact, we calculated out right now that if you were to fill every single blob, every single bite, that would cost something on the order of maybe like 250k a month, which is not bad for utilization of the entire network. So at the moment, we're running uh relays that pay a tiny tiny amount uh per day. That's something that's fairly easy to subsidize, but

this is also something where anyone can permissionlessly and trustlessly run their own relayer too if they want, you know, better guarantees about their transactions getting into the memp pool or anything like that. But again, it's super cheap. So, we're at the level where now this can just be subsidized. >> Awesome. Well, guys, thank you so much. This is really interesting.