Apian: A Flexible Peer to Peer Framework for Blockchain Games with Keith Salzman

Uh good morning everybody or almost almost noon everybody. Uh so I'd like you I'd like to welcome you to uh my presentation today on APN. So my name is Keith Salsman and uh I am one of the uh engineering leads at Consensus Mesh R&D. Uh so a little about myself. I usually work within the topics of zero knowledge, uh kind of general blockchain development, uh quick prototyping of of solutions that have to do with newly made bleeding edge tech, uh and now more recently, uh the gaming space.

Uh so before I I really begin I have to kind of give a little uh kind of give a little claimer that I am not the brain behind Apen. Uh that the chief engineer who is also part of consensus R&D. Uh Jim Barry is behind Apen and he is a veteran in the game development space. He's been at Consensus for about uh eight years now. He is the co-founder of Virtue Poker and um like I said, he works in our research and development unit.

Uh so today I'm going to do a couple things. First, I'm going to start out and I'm going to retrace the path that our chief engineer Jim Barry took in kind of discovering and creating the AP framework. Uh then I'm going to on a high level uh give you an understanding of how APIN works under the hood. And then lastly, we're going to see a demo of a game uh that's made with the AP framework that I'm going to play here on the screen with some various uh anonymous people out in the crowd. Okay, there's there's one of the anonymous people.

No, stop raising your hands. You're anonymous. Okay. So, uh without further ado, uh this is Apen, a flexible peer-to-peer framework for blockchain games. Okay.

So, uh Apen kind of began with a a single idea and that idea you see here on the screen. So, it should be practical for a single developer or a small team to create and deploy this first class multiplayer game without a centralized server. So, uh, really quick, I'm going to dissect this this kind of oneliner here of Apen. I'm in front. Walk over there.

All right. So, the first part, there's really three important things here. It has to be practical for single developers and a small team to create and deploy this kind of first class game. So with APN framework, we are attempting to activate the community of single and small developers to give them the ability to deploy what we call this first class multiplayer game. So for the purpose of this presentation, you can think of first class multiplayer game as kind of those high tier really smooth high interaction uh FPS, MOBAs, whatever game you love, Fortnite, Apex, uh League of Legends, whatever the new thing is.

And then lastly, we want to be able to do this without a centralized server. And we'll get into the the real reasoning behind that. But it kind of suffices to say in a nutshell that in doing so, we're going to take some of the lower the barrier of entry from these small teams by moving to a decentralized framework. So the APN team in trying to you know take this prompt and create a framework started with uh solving the problem of the centralized server or wanting the lack of a centralized server and of course there's a very natural solution to this right use blockchain as a trustless decentralized server with usagebased costs. So the idea here, the initial idea is if the APN framework can give a set of tools to the single small team developers that will allow them to create a game onchain using decentralization.

This will kind of inherently lower that barrier of entry. And this is going to be a theme throughout the presentation of let's lower that barrier of entry for them, right? No longer do they have to spin up and deploy this production server with uh you know this game server logic and and and storage. Part of that can be moved to onchain and just in addition uh we we gain kind of an in-game consensus in a in an immutable fashion. Right?

So a little bonus extra there, right? uh but of course blockchain is not without its own barriers. So in an attempt to solve that first let's do it without centralization barrier. We somewhat intentionally create other barriers. So we're going to look at what those main barriers are as the APN team saw them that needed to be solved to bring us to a place where we fulfill that initial oneliner.

Okay. So really we've divided those into kind of three big ones that I'll discuss. We have the um all of them come from this you know idea of block time batching which results in performance and ordering issues. Right? The first one here all transactions are in limal to the next whole block is broadcast.

Well, if you think about it, this is a very obvious problem if we want to create that first class high interaction multiplayer game, right? In practice, these games in reality, we'd really need to wait until that next block to even use, you know, the effective outcome of the transactions. and in trying to attempt to achieve that that smooth highclass game well the throughput just doesn't work as it is right the next one transactions from multiple accounts are not ordered at all so although we may be able to guarantee that a a single user a single player game that their transactions will be ordered on chain but there is no guarantee that multiple users all playing the same game together that the way their transactions are placed on chain will be in order. And keep in mind, we're talking about this really smooth game. First person shooter, every action, every bullet, whatever it is, is a trans transaction on chain.

So without the guarantee that they are in order, well, obviously there may be some major type of drift in each person's client. And how things occur throughout the game may be seen differently through each player, right? And then once the drift is synced, well, uh, who knows? Maybe you thought you shot another player and in fact you were the one that was shot, right? Uh, the last one here, onchain cycles and storage are too expensive for casual use.

Well, we're all very aware of this, right? We are attempting to lower the barrier of entry. We took away that idea of you having to spin up your own production game server. You know, that lowers a barrier of entry. You don't need the money.

you don't need the people capable of doing that. But we've in some way kind of shifted that expense over to onchain. And who covers that expense? Well, we're not attempting to answer that question yet. We're just saying this is a barrier and it's still blocking those small teams, single devs.

And you may be thinking at this point, all right, well, you know, we we've seen some cool stuff uh recently. You know, what about doing things on L2 execution chains? what about you know scalability rollups optimistic zk everything and I think the the idea behind that and I personally do believe that you know in the future those paths may take us to a point where you may be able to deploy a firstass game on chain that's my personal opinion but until we get there in lie of that future no matter how far we at Apen are attempting to solve the problem today and now. So let's let's take a look at where the Apen team went from these barriers and how they were solved. So something's still missing here, right?

And that's the use of a peer-to-peer framework to allow eventual asynchronous onchain consensus. All right. So what you need to take from this sentence again we're going to do a little dissection is of course peerto-peer. So APN is a framework that allows and exposes the tools for its users to create peer-to-peer games but in addition to what you're used to normally with peerto-peer in letting everybody bring their own compute power to run the game. In addition, now each user will bring and participate in the consensus mechanism of the game itself in the group.

And what that accomplishes, it will allow us to take some of that load off of, you know, the throughput that we needed on chain in consensus and do that in our little peer group here and at some predefined interval asynchronously, you know, place that onchain consensus that we've gone through those rounds of consensus by oursel and put up onchain. Okay. All right. So, uh let's look at some of the benefits that this now this peer-to-peer framework has granted us. So, allows us to avoid these upfront server costs.

I touched on that, right? If you are if you use APN framework to create a game among peers, well, you no longer need those upfront servers as a single dev or a small dev team, right? All the peers in the group are bringing their own compute power. Forget consensus for now. They're bringing the compute power.

So that alleviates that pain point of cost. Now we shift over to the idea that each peer is also a participant or a a node in the consensus mechanism itself. And with that we have instant client finality. So if you imagine you know traditional games with a game server uh the game server is you know solely responsible the source of truth and you know it will send out information to the clients and the clients may experience some small drift right and of course if we try to do that onchain in a you know high interaction smooth game well then it's just going to kind of expand that drift. we can achieve this kind of instant client finality of the consensus in the peer group together comparable to that of the traditional game server because the source of truth are all the peers participating in the network himself.

We all agree on what is true and it's distributed among the group immediately. So uh those two are the most important. Uh right below that we have you know limit issues caused by client servers having two different code bases. Again, this is lowering the barrier barrier of entry, right? If you don't have to worry about if you're using APN framework and you don't have to worry about, you know, uh having devs that are competent in, you know, server and client, uh, you know, lowers the cost, right?

Barrier of entry down. Uh, this is just kind of an extra bonus. We eliminate the asymmetric trust that's inherently required by client server, right? So whether we're talking about onchain, whether we're talking about traditional gaming, there's that asymmetric inherent trust between having the two code bases. Uh that's just an extra bonus, but also that's that's eliminated, right?

We're only working with a single codebase now. And if we take all those things and put them together, we take the idea that that that original prompt where we're like, okay, let's let's make it possible for single devs. Let's make it possible for small teams to deploy the the first class multiplayer smooth high-end interaction game. Let's combine that with blockchain compatibility. On top of that, let's add the peer-to-peer framework that will allow the players to not only bring their own compute, but also participate as peers in the consensus network that will eventually achieve this asynchronous consensus onchain.

Let's wrap that all together. And that is Apen. Okay, a peer-to-peer framework for game devs. All right, this is our nice oneliner for it. Uh, I like it quite well, so I will read it.

uh a blockchain compatible code framework and protocol for the management of shared data in these highly interactive multi-user applications. So you notice you know son's this it's not really game particular right but games are just kind of epitomize this idea of sharing data in this highly interactive especially multi-user application and APN is a framework that will allow this it's it's more than that it's more than a protocol it's the mindset that we're going to do this without a game server we're going to do this with just the peers they will take on the responsibility collectively through communicating the responsibility of the game server. And in addition to that, they will be able to achieve consensus. And the really special thing about APN, the framework that allows in terms of consensus, is because the consensus code is kept separate um from the application programming, but answers are the same APIs. This means that any spun up peer-to-p peer network game, you can choose what type of consensus mechanism you will use among the peers, right?

This is you know just in time on the fly on runtime choice of consensus. So if you and your friends want to use a particular consensus mechanism for the whole game or even just for a particular levels in the game or stages in the game, you can tweak that consensus to optimize the balance between you know uh um efficiency and and and throughput and and and security based on what type of game you're playing and and what type of consensus it deserves. So that that is one really cool thing about AP I'll say. All right. Uh now I'm going to get to the go through the APN architecture on the high level.

Uh this is kind of the you know everything together and I'm going to go through and add one by one and describe what's going on here. Okay. Uh so we start out we start out with this kind of simplest data model. You can imagine what is the simplest data model. Uh if we're talking about a paper game, maybe that's like the board, the pieces, some kind of scoring pad here.

And this is what we refer to as the core state, right? Um you know everything can see the core state, everything can query the core state but nothing can change it except the core logic. Right? So now we have this extra piece here called the core logic. It is capable of altering uh the core state.

It is the only code that is allowed to do so. And when we pair these together, core logic and core state together, this makes up what we call the uh the app core. Now, we're going to see this in practice in a second. But what will happen is we're going to have some external flowing directives, these kind of predefined highle application domain directives that will flow into the core logic if chosen to do so. They will be interpreted by the core logic and the core logic will execute some very low-level changes in the core state to reflect what those high-level directives were that were sent to it.

Okay, let's let's take a look uh and but sorry before we take a look at the actual flow, let's just review the app core rules, right? State can be seen and queried by everyone. We talked about that. uh state can only be modified with these external command the directives I talked about state must be serializable has to be restorable has to be hashable uh and of course the the logic in the um if we looked at the core logic itself the logic in there must be deterministic right there cannot be anything random the code has to be stochastic or sorry cannot contain stochastic code all right so uh with all of those things in mind in here the core logic that will interpret those directives, the core state. If you think about it, that's kind of the foundational, you know, everything you would need to kind of run the the the server logic of the game there.

But that's not only what the game is. The game is also the client, right? We need some we need the rest of the game, the visual representation, maybe some some randomness, the how the users interact and that the rest we call the application code. Uh so you can think of the application code in this example of just handling the front-end task like like rendering the core state rendering the core state to the user as well as maybe collecting user input as we're all playing this multiplayer game together. It's collecting our user input.

It's sending it out to the app core and again we go through that flow through the core logic interpreted to low-level changes in the core state. All right. So, um the the one cool thing about that the thing I talked about of of no random behavior inside the core logic that means that uh we push any any randomness any stochastic code down into the application code. The same thing that is interpreting user input and transferring it as directives to the core logic. Well, that means if we want to introduce some other random list like for example uh an AI an AI player as you'll see later in the demos well this is going to be interpreted by the app core exactly the same way as user input would be right it lives in the application code collected by the application code and sent out just as a user input.

So to the app core, it sees no difference between, in this case, a real user player or an AI player. And this is all good and well. Sending commands directly to the app core works pretty well for like a single player application. Um, we could just keep sending commands straight through, but it's it's not really what we're trying to do. We don't want single player.

We want that first class multiplayer thing. And this is where the APN instance comes in, right? So we bring in a new component through the framework, the APN instance which is always going to be paired with an app core and together referred to as the core pair. What you need to know about the APN instance is that it is functionally for the core pair it is acting as a proxy for what's going to be this virtual APN group object out here. Um and this group object is made of you know all of the peers that are participating in the game bringing the compute powder power and the consensus.

Okay. Uh in a second we're going to go back to the diagram and kind of show the full flow through it from application to code uh through the APN ines through the core pair. But before we do that, uh, we're going to take a look at, you know, three different messages that are expected inside of the APN framework. So, APN defines these three messages that wrap these application directives, right? We talked about the the highlevel or the these predefined directives that are being sent in.

Now, these are the three types. We have commands. So, commands are they tell the app core to apply um some kind of application directive to the core state. A command is essentially saying we've received a directive. The group has decided that this directive should be a command and it should be reflected in through the core logic to the core state.

Now before something becomes a command, it could be a request or an observation. Uh the request itself I've hit on a couple times. It's from the application code and it's an ask. It's it's saying, hey, I have a directive from this client. Should it become a command?

Right? Should I I send this out to the consensus group and we need to decide should it become a command. Observations are the same thing as requests. The only difference is they originate from the app core itself. Right?

Uh so you can imagine uh I like to think of this in my mind as okay if I have a request the difference between a request and an observation request could come from me or an AI uh you know shooting something in a first person shooter and maybe I miss and it hits an object and the object is falling and there's some kind of like you know iterative pattern going going on where the object falls on somebody. So the object falling may end up being like an observation that is again run through and say hey this rock fell on what's his name head it should it be a command right should this be the truth do we agree this is on the truth this is the truth uh okay so let's take a look at the full flow here if we imagine a a request starting out in the application code whether that be from a user or from an AI player some randomness and and that request will be sent over to the APN instance which remember is a proxy for the virtual group. It will be fed into the proxy and distributed among the group. The group will engage in its kind of consensus mechanism and decide which requests or observation should be promoted to a command and upon deciding that that command will be sent back out to the instance and fed through the core logic which will interpret that command in a low-level way to the changes to the core state that we'll see in the game. We can also imagine this not only from our own point of view but coming in from the other peers maybe a full model inside your head.

You would imagine many different requests and observations kind of coming in from all sides from our APN instance from from uh you know the other uh peer network users APN instances and through consensus whatever consensus mechanism we have chosen for this group. uh it will decide not only which ones become commands but in what order those commands are distributed and they will be distributed back through each client system and then they will be fed through everybody's core logic and core state and since we're all running the same game we will all see the same source of truth that we have collectively decided on will exist in the core state okay so um I hope that I also have a video here uh of of the actual the flow going through you so you can see it in action. At the end of the presentation there'll not only be like QR codes and links so you can go and look at the explainer uh it's yourself and kind of see it in action the flow. It's it's easier to kind of understand when you can see things moving through it. It's a little too slow though.

So because I have I think I have about five minutes I'm going to go on to the demo itself. Okay, I have one last slide here before the demo to kind of summarize all of the things that the APN framework brings in terms of tools, libraries. So altogether these things will you know help the single devs the small devs avoid maybe twothirds of the time on infrastructure and support you know building all those systems necessary to deploy that that first class multiplayer smooth high-end interaction game. It also will present a place to store the game. Uh I won't get too ind depth on this but essentially APN also allows for nonplayer peers who are participating in the consensus mechanism to also be part of the peer group.

And since each peer whether they're player and consensus or pure consensus each has a copy of what's called the command log which is is essentially the game itself. So, one way to store the game would be if all of us leave and we leave that one peer consensus validator in there who's still maintaining the log, the command log that would actually still store the game and we could all then later join back or if everybody leaves, we could store it on somebody's local disc or even on just, you know, decentralized storage somewhere and rebuild the command log, restore it to where we want in the game and keep playing. uh remember bring your own compute right uh a peer-to-p peer framework for gaming all peers are going to bring their compute the reason why we don't have to spend all that time uh and money on building uh you know sole game server uh another cool thing is networking layer so essentially APN one of the tools it brings is an abstraction of you know existing kind of networking code without vendor lockin so that you're able to interact uh as just a normal application programmer would expect instead of having to hire maybe like a a networking programmer. Uh so that's it also uses network existing network code. Uh the app is shared across the peers and it's running the same.

So when those commands are distributed back through everybody sees the same thing reflected in their own personal client and that collective client finality, right? Collective client finality. Consensus is achieved through our agreeance. So when it's redistributed back out, you know, what we have decided is true, it's immediate as soon as we agree. Right.

All right. And now to the demo. Uh which this is the part I've been trying to get to uh pretty much all day. Uh the most fun is you guys will will be able to see me play the uh first game created with the Apen framework by uh Jim Barry himself, the chief architect of Apen, and it is called Beam. Uh so I think I'm going to get a couple people out in the crowd.

Are you guys ready? What are you're on? Pokey Hedgehog, right? Okay. All right.

Uh, let's see. Let's see if this works. Where where are you at? Mouse. Okay.

Here we go. All right. So, here we go. I'm going to go through the settings really quick. I only have a minute or two left.

So, just to show you some of the possibilities here. Uh, we have our P2P connection, the choices of our P2P connection, the choices of chain. I have my my in-game account versus my my permanent account. Uh, I have a APN network that's set up here. And then, of course, I have my screen name is Keith.

That's my name. Uh, I believe this matches your guys information, right? We're on the same place and I'm connecting. Let's see. Uh, okay.

I'm getting a Let's see. So, we are That's exactly what we're going to do. We're going to see. Okay. While you're restarting.

So, while he's restarting, I'll just say that this is P2P playing. Um it actually is a couple of uh machines we have running in here on the Wi-Fi over a couple of mobile networks. There's also a server um that is running participating the game with an AI out of New York on Digital Ocean um running Iuntu and then there's a Raspberry Pi on a Starlink network in the upper New England part of the US. So we have latencies that are varying between clients in the you know tens of milliseconds to 100 millisecond plus. All of that gets abstracted away.

Um the client actually runs uh you know Unity Build uh in uh any browser um on uh iOS, Android, Mac, Windows, Linux. Um so it gets all of those nice features. It really is meant for people to kind of divorce themselves from having to worry about um all of the details for it, but still be able to get a high quality game uh really individual um person or small team developing. Um and Jim Barry has a long career creating P2P flight simulators, other things. So this is sort of uh you know interpretation from a real uh game developer of like what is one very interesting possible future which obviously is different than you know creating a uh blockchain RPC.

Uh it can work with it as well. But so anyway that's the context on the network. I'll give it back to Keith. All right. And uh so I believe that is time.

Yeah. Okay. Sorry. So I believe that looks like Jim right there. But yeah, that is time.

And I'm just going to put up real quick if I can the uh the QR codes and stuff. Is that fine? Yeah, it's going to have to be fine. Yeah, I found him earlier, but I didn't have time to get to him and kill him. But uh so here you go.

Uh if you want to scan, we have a couple different QR codes here. Uh you know the apra.com uh us at mesh here and then we have another mesh R&D event later on the the 3 from 12 to 2 at Reno Rhino. Okay. All right.

Everything.