Les Amis d’Ethereum France #9.2 — “Supporting a P2P rental system in a game" Vincent le Gallic

[Music] Good evening everyone, I'm going to talk to you about NFT rentals and I'll try to give you some feedback. We've used both protocols, so... I'll try not to get too technical and give you some key points if you ever build a game on the blockchain and want to add rentals. I'll try to give you some useful tips. A few words about Commit: we've made two games.

The first one, which you may have already played, was a completely chained game with a chained economy and chained movement. And right now we have a new game, a battle card game that's live. You can try it; it's really cool. We also have a B2B activity for companies; we help them build their Web 3.0 projects.

For that, we build tools, indexers, relays. We're working a lot on roles at the moment and we're writing protocols like rentals that will be used by other projects soon. So, since I'm a little lazy, when Jérôme Madison does n't want to do the talk on rentals, I'm just a minute away. Out of curiosity, I asked GPT chat if you could try to describe an NFC rental protocol. I thought I was being clever; I'd save time making a slide.

The answer was actually very, very good, and I thought, "Well, I'll have to adjust the text a bit. I'm going to write a general explanation about what NFC rental is because every GPT user does it better than me, and I'll have to focus on things that are perhaps a bit more technical." I thought, "Well, if it's just going to be copy-pasted from GPT chat, there's no point in doing anything, especially since, as developers, we can assume that AI isn't going to replace us in the development process." I'm going to ask if you can give me some pointers on how to implement a rental protocol. And here again, GPT chat is very relevant, so it's worth reading the answer if you want, but I won't do any better than that.

GPT chat on the theoretical part, so I'm going to focus on feedback because, unfortunately, I could talk for 20 minutes on the theoretical side about why it's good to have a rental protocol, but just ask GPT chat and you'll see, frankly, it's impossible to do better. So there are several ways to do it, there are different EPs that coexist today. There isn't really a standard like RC1 or 721 for making it for NFC rental. The different approaches that exist are a contract where the owner of an NFT and the renter simply register, saying, "OK, I rented this." A person owns this NFT.

That's the first version we made, by the way. A quick hello to Tanguy, who's in the room, who wrote the first version of the protocol, which was based on this idea. More and more, we're seeing the emergence of smart toilets with permissions, where you put NFC in a smartphone and then give usage rights to the NFC, so the person can... For example, you can play with an NFT, but you can't transfer it, you can't sell it. So we tried another approach: we make carbon copies or clones of NFCs, and I'll explain in a bit more detail how we do that and why we did it this way.

I also wanted to mention two companies we exchange a lot with, who are really specialized in writing a rental protocol. So we exchange a lot on different approaches. If you want to see another approach than the one I'm presenting tonight, these two companies have also created a protocol with a different and equally interesting approach. So why are we qualified to talk about this? Because we have more than 10,000 NFCs that have been rented thanks to the protocols we wrote.

So I'm quite proud of that because there are a lot of white papers, a lot of promises, a lot of NFT sales, but there isn't much practical use. We're one of the few projects where we have a lot of use cases. So what I'm going to talk to you about tonight is something that has been battle-tested in production. 10,000 NFTs rented thanks to its protocols is no small feat. From a good perspective, I'll start with a summary of my conclusion.

What I'm going to present to you is that these live streams are open source, they've been audited, and you can use them for your own games. So, when we started designing the protocol, we looked at the different elements. Okay, well, there's a game, there are NFCs, there are owners, and there are players. If you don't have these elements, you don't have NFCs with value, you don't have a game, you do n't have owners, and you don't have players, so to speak. Well, don't bother making rental protocol; it's useless in real life.

We're in this situation: you want to rent something, you put down a deposit. In the world of video games, it's not like that at all. Sorry, my slide, but actually, yeah, in fact, players want to play with items they don't own, and they can't put down collateral. The principle of a deposit is very simple: you take the Lamborghini, you don't return it, and your deposit is... Used to offset losses, so we need to find a solution to create a rental protocol where players can't deposit collateral or a security deposit.

We could use a kind of system where parties... but it has quite a few drawbacks: they could run off with the funds, they could use your money for other things, and so FTX is, yet again, proof that this exposes all parties to a huge risk. So we're doing it in the worst possible way because it's risky. It has other advantages, but again, I refer you to Wikipedia to detail all these advantages. But it's quite obvious: we inherit all the advantages of blockchain when we do it in chapters.

So one of the conditions for renting them is that they have to be desirable and have value. Nobody's going to want to rent an NFC, something useless. create an ecosystem where people want to rent it. It seems obvious, but I have to say it: why do our NFCs rent well? The thing is, we've created an economy around NFCs (Near Field Compounds) based on their rarity.

This means that if an owner doesn't have time to play, they can make their ship available, and another player will spend time on the game, generating income. There's a kind of revenue sharing between the owner and the renter. The rarer the ship, the more income it generates, and the longer you can play with it. It's a bit like the concept of engines that are more powerful on rare ships, allowing for more gameplay. Then you can imagine a drill that's more efficient and therefore generates more resources in case of victory.

So, if you want to do rentals, you really need to think about your economy so that your NFCs have value; otherwise, it won't work. When writing a protocol, the question we have to ask ourselves is: what are the advantages and incentives for using the protocol? I'll go back to my taxi example because it's actually quite good. You can have people who own cars and make them available to drivers. I find this example telling.

You can have... Car owners who do n't know how to drive and don't have the time, or who are actually doing it as an investment, what to put in it? We have quite a few people who bought ships and had absolutely no intention of playing with them; they bought them from the start as an investment. On the other hand, we have players who ski, who can play for 20 hours a day, who know the game very well, who are passionate about it. This will remove the mechanics, and so we need to find a protocol that meets all these motivations.

So for ship owners, we want it to be a bit like an apartment owner who receives their rent every month without doing anything. We want them to be able to—and I'll talk about this later, for example, the guild delegate—I'll go into a bit more detail later, and they want their position to be liquid. This means that I can easily buy a FFT, rent it out, make my investment profitable, and then want to resell my position without breaking the lease. It's a little complicated, but I'll explain how we do that. For the renter, as I said earlier, we don't want to be Collateral is not what we're doing here.

We're not taking out a loan with collateral like on other platforms. We're borrowing from Naft without depositing any collateral. We want it to function as a kind of marketplace where I can see all the available rental offers, compare them, filter them, search for them, subscribe immediately, and play with my new ship. Again, in the case of guilds, I'll be able to sublet it, and I also want a liquid position. That is, if I change my mind, I want to be able to transfer my rights to the contract.

From a game perspective, it's quite simple. What we want when we implement this kind of protocol in our game is more revenue, since we'll be taking money when the rental contract is opened. And above all, we don't want people to sell the Naft ships in the game, so we have to give them a purpose. Often, we have people who buy ships but don't have time to play with them. After a while, they look at their wallet and say, "That thing has n't moved in six months, I'm selling it."

And then, thanks to Randall, we tell them no, actually not that, put it up for rent. And in fact, this generates passive income for them, prevents people from selling them, and therefore maintains Flor Price, which is important for the project. The second aspect, which is extremely important, is that today our ships are quite expensive; I think it must be between $150 and $ 200 for the cheapest ship. Obviously, when we have new players joining, we ca n't ask them to pay that much, so we direct them to rental services, saying, "For a few euros, you can rent a ship and start playing and testing the guild mechanics. You can think of them as ' selected' players."

Their added value in the ecosystem today is identifying the highest-performing players. We could even be called guild managers because, while we imagine a guild to be a whole organization, it's generally a person who acts as an intermediary, rents to NFC, assigns a player, monitors their performance, and if they're not performing well, takes it back. ship and assign it to someone else, so its added value is really to say, okay, I'm not going to buy, I don't have the capital to buy a fleet of ships, I'm actually just going to make rental offers and manage a player base, so their added value to the ecosystem is recruiting and managing a team of ultra-competitive, high-level players. Similarly, creating a protocol today that doesn't address guilds, in my opinion, would be huge because ultimately, most of the volume we do is done through intermediaries who manage that part. So what does it look like concretely in terms of interface?

When, as a ship owner, I want to create a rental offer, I have several parameters to fill in. First, I can make a ship bundle, so I'm going to rent out my green ship as a purple ship. It can be public or private. I can reserve an offer and put an address so that only the recipient of this offer can access it. There's an entry cost, this entry cost, and especially to combat, as we can say, the flow of, yeah, there you go, so that when basically someone puts us All the ads spam the entire system with ads that don't have an entry fee.

For example, if the offer is free, I'm almost incentivized to subscribe to the offer and not play with the ship. Adding a small fee creates a barrier for someone who would want to subscribe to all the offers without playing with the ships. There's a time limit and a distribution of earnings. That is to say, I can take 50% of all the earnings generated by this ship in the Comet game, or rather, keep 50% for myself. The difference in strategy is that some people set very high entry fees and give all the income to the person, so it's a one-off deal.

Others set the lowest possible entry fee and take a large share of the income. It depends on the strategy of the renter and the player, the timing, and each person's philosophy. Knowing that once the period is over, as long as one of the two parties doesn't cancel or trigger the end of the contract, the contract continues, what happens from this point of view... It gets a bit more technical: when someone subscribes to the rental offer, original NFC is stored in a kind of vault, which is a smart contract. The protocol then generates a new NFT, a TFT, and a Border.

So the owner has the FT antenna, and the renter ends up with an NFC tag, which are clones of the original NFC. So, if you look at your toilet, you end up with the exact same Vexo, the ship you were going to have before. Sorry, but you have a Border telling you that this ship is rented, or [Music] represents your right as the owner. And the owner has the right, according to the contract, to reclaim their NFC. If you buy the other one, it's more problematic.

So, as I was saying, we did n't create a protocol where a wallet has rights over the protocol; it's really the NFT holder who can do things with that contract. That's what makes the position liquid: if you own the NT, you can do things with the protocol. If you own the NFC tag, you have other rights over the protocol. For example, the holder of the NFC tag can solder it. It's exactly like when you're in your apartment.

Imagine the landlord can't sublet the apartment while someone else is staying there. However, if you're staying there and want to increase the rent, you might be able to change Airbnb. We'll go quickly, it's legal, but this is just to give you the image. It means it's quite logical that the person at the end of the chain who can perform this kind of operation, precisely because we're talking about subletting. So, as a tenant, I can't modify the tag that was for the landlord, but I can, on my side of the pie, modify the NFC tag to be able to assign it.

In this case, at the protocol level, it's a bit of a numbers game, you have to stay connected, but what we do is, when someone subscribes to a sublet offer, they get the NFC tag, and we mine a new NFC tag for the intermediary. So that means that In the case of a city, the guild ends up with a Sublet NFT. The player, as in the case of the player at the end of the chain, always has the Boro NFT. I'll explain later why this is important. We end up with three NFCs that have been limited, and still the original NFC, which is located in the Smart contract.

There are a few volts on this protocol, which is a little difficult to understand. When there's a sublet, it means there's a transfer of NFCs, and ultimately, this technique allows us to do quite a lot. So, in this case, with a sublet, the rights change. This means that the person who has the brooch can't do anything on the protocol at all. But it's really the last resort; apart from playing, well, apart from having it in their wallet, they can't interact with the protocol.

The intermediary, the guild in this case, can always cut off, as I said earlier, a player who isn't performing well. As an intermediary, they can cut off their Broo NFT if the owner and manager agree to stop the profitable activity. They can do so. But in this case, we see that there aren't many possible operations. Creating these matrices is incredibly practical for developers; when all they have to do is implement these rules, it sorts things out.

Nothing technical, really. If you were a real estate agent, when you asked to draft a contract between two parties, you'd have to ask yourself these kinds of questions. So, I'm doing my part, I'm last in the chain, so I have my NFT office. This means that when I arrive in Comet, I have a ship like everyone else. I'm doing my part, let's say I win.

The game will give me rewards. So, as a game developer, we have to make a change to the game with this system. We have to support the anesthesiologist offices. So, when we say support the NFT edges today, without subletting, when you play Commit, we send the rewards. If the person has an NFT executioner in their Wallet, we show them the ship.

So, we have a condition to manage, and I check if that Wallet has NFTs from that contract, and if so, who wins? Instead of sending rewards directly to the player, we send them to the Wallets, then to the NFC office, and it's the NFC administrator who holds the distribution table and applies all the clauses of the contract agreed upon by the different parties. This approach prevents the game from being cluttered with rental rules. We wanted to create a protocol where the game, or at least where there are minimal modifications to the game, requires minimal intervention. We do have a rather unique system; there might be other games that don't work at all with RC1 transfers at the end, but in our case, it was exactly what we needed.

At the game level, we had to add two lines of code to support the NFC administrator and then to add a condition for sending rewards at the end. One last thing: I'm almost finished with the feedback on writing this protocol. Ultimately, there were about five of us working on it, although two people actually wrote it. Solidity code, and I wanted to make you aware that writing protocols such as renting, or protocols that allow for marketplaces or crafting (we also created a crafting protocol this year), ultimately results in very little Solidity code. We spent quite a bit of time reviewing the design; basically, we threw out a lot of things and rewrote a lot.

Regarding the documentation, I think we did it recently. For a year, the protocol was live, and there was no documentation, especially for unit tests. I took a quick look at the files earlier; there are over 600 lines. In fact, we have all the matrix cases I showed you previously. We had to test them, and it actually takes much longer to write the tests than to write the robust code, which is actually very simple once the matrices are well-designed and the design is okay.

The robust code is quite natural, a kind of secretion. However, you absolutely have to write code coverage because if you evolve your protocol and don't have a security issue, you're absolutely certain to introduce regressions. So, the interesting little lesson learned is that during the protocol development, we spent much more time writing tests than writing robust code. That's what it looks like. (A little aside: there's also a huge amount of work on the frontend.)

That is to say, managing these interfaces is at least as time-consuming as writing the protocol, even if the expertise isn't the same. To create these interfaces in a reactive way, you need Fontaine experts. Then you need a layer between the blockchain and Fontaine because, in fact, there's far too much data. So, you can use this graph, but we've reached the limits of what we can do with Exographe. We had to develop our own tools to be able to have this kind of interface that responds quickly and is never out of sync.

I've never had any desynchronization between tools like The Graph and the reality of the chain. Unfortunately, sometimes The Graph is behind, and for our users, having outdated data displayed to them can cause major problems. And that's pretty much all I wanted to tell you. I hope you've learned something about rental protocols. One last little word about what we're doing right now: there's the game that's live, and there's alambic.

tech where we're starting to release everything we've developed. For us, who were starting to use it, others, including renters, are involved. There's also Boiler for GG, which has a Discord bot that also uses infrastructure layers that we originally developed for Battle and which are now part of the tech scene. So these are things that are live, that you can test. A word about Boiler: it allows you to do what Premint does, that is, generate whitelists based on prerequisites like liking, or unchaining prerequisites.

Often you see operations where people have just bought something, for example, I'm going to waitlist people for Mintémont, a HT only if they've made a certain transaction on a certain network and only if they follow a certain Twitter account. We had fun abstracting all the interfaces to do this, all from Discord. It's free, so if you want to test it, don't hesitate. And all the infrastructure layers are developed by the Comète team, so don't hesitate to test Battle, which is live and is currently evolving rapidly. There are many...

New features have arrived, so feel free to test them and give us your feedback. Thank you very much. [Music]