P2P Semi-Autonomous Games on the ETF Network [Part 1]
semi-autonomous p2p blockchain-based games on the ETF network
This article is part of a series about using the ETF network (“encryption to the future”) and timelock encryption in the context of blockchain-based p2p gaming. Part is available here. In this article show how the ETF network can provide capabilities for immutable and unavoidable in-game events for async, p2p games. The ETF network is a blockchain using ETF consensus, enabling timelock encryption. You can read more here. This is a proof-of-concept only and not ready for production use. If this article intrigues you, check out the project on github or join us on discord. Now, let’s begin!
Introduction
Blockchains can be thought of as a mechanism against which many disparate participants asynchronously issue transactions in order to modify a commonly agreed upon state. This mechanism works really well when you only care about the immutability of actions taken, however, interactions between parties become inherently untrusted in the context of a blockchain. In blockchain-based p2p games, this becomes particularly detrimental and imposes limitations of the capabilities of game mechanics, leading to poor user experience or usage of centralized components. The absence of a central authority to coordinate interactions between players and to keep these actions private until played results in blockhain-based games losing many positive qualities of traditional games. Of particular note, front-running is very consequential and could determine the outcome of a game. In standard p2p games, this would definitely be considered cheating, but in blockchain based ones, it could be hard to avoid.
Without the presence of a centralized authority, participants no longer have a central ‘event clock’ against which they all agree. That is, there is no way for each player to ‘play’ at the same time due to the async nature of the network. Even if two players somehow issued their plays (transactions) at precisely the same time, there is still no guarantee that they will be included in the same block. This can be somewhat counteracted with an interactive commit-reveal approach, where participants issue commitments to their actions and reveal them at some time later on. However, this can become cumbersome if there are a large quantity of commitments and it is also interactive for every player, meaning any action taken in the game requires two interactions with the platform (and two transaction fees).
Centralized v.s. Decentralized Games
Games that are elementary to implement in centralized systems can be difficult or cumbersome with decentralized architectures. For example, let’s look at rock-paper-scissors with a centralized architecture. Since both players trust the central authority (the server), they both rely on it to store their plays and to truthfully determine the winner of the game. This is an elementary application to build with centralized systems and could be done as a good “first project” for someone learning p2p web technologies. In this game, if the server behaves honestly, then the outcome of each game is truthful. The players do not need to agree on the “time” because the server does that for them, meaning the order of message delivery is not so impactful.
Now, in decentralized systems, these types of games rely on smart contracts to act in the capacity of the server. A smart contract encodes immutable and transparent game logic which is executed to determine the winner of the game. In a naive approach, two participants could simply use a smart contract. One of them ‘starts’ the game, the other joins. Then, they each issue their plays as transactions to the contract which are encoded in the contract’s storage. The contract’s game logic waits until both players have values in storage before allowing a winner to be determined. It is quite easy to see that whichever player issues their play first is at a supreme disadvantage. As stated previously, this can be counteracted by each playing using a commit-reveal approach instead, where their initial play is a commitment to a value, then after each has committed a play, they can both reveal it to determine a winner.
This provides a framework for establishing trust between distinct parties in an asynchronous way, but it does not scale to a solution for general games with a large number of participants. Each participant is responsible for calling the contract twice, meaning any game mechanism with a commit-reveal approach undoubtedly requires two calls, and so two transaction fees. In games with large number of participants, interaction with the contract could become costly due to the contract execution cost coupled with the storage of commits/reveals within the contract. Network latency bewtween participants could be an additional bottleneck, especially in games with a large number of players.
ETF Network as a Logical Clock
The ETF network’s unique consensus mechanism provides a solution for the problems above. The network is able to act as an immutable, resilient, and predictable clock for game events while also ensuring the confidentiality of actions planned for those events. By leveraging timelock encryption, participants can create ciphertexts that can only be decrypted at specific “times” in the ETF network’s consensus mechanism. It should also be noted that the ETF network can provide this capability “for free”, in the sense that encryption, decryption, and extracting secrets from headers comes at no cost to any party.
To start, we will refer to the game as G. The game G is a peer-to-peer game within a smart contract and uses the ETF network as a logical clock to advance the game. We model G similar to a blockchain, as a finite state machine. We will say that G has an initial state S0. To keep things simple, let’s say that the game’s clock should advance every 10 blocks. Within that 10-block window, players have the chance to issue their next move, timelocked for the target block, and broadcast it to peers (other players, likely done as a smart contract). At the end of the round, each players move is decrypted by a semi-trusted executed and the next state of the game is calculated by the game logic, producing S1.
So, let’s break this down a little…
The Game
The game is a smart contract deployed on the ETF network. The actual logic of the game isn’t very important here. The game can be implemented in a myriad of ways based on the logic executed when advancing the clock. The game contract’s storage represents the state of the game which can be updated only after each ‘clock event’ happens. These clock events can be made static or dynamic and are represented by slot identities in the ETF network’s consensus mechanism (similar to block numbers). For example, a game could have a static logical clock, where events occur every 10 slots, or a dynamic one, where events do not need to follow a fixed amount of blocks between events and instead can be defined however the game creator wants.
The game state is only updatable through a function in the contract, the advance_clock function. This call accepts decrypted player moves and then verifies the moves against committments issued by the players. When all moves have been “played”, the game clock advances. Note that this does imply the game clock could be paused or stopped indefinitely if no player advances the clock (or if by design of the game developer).
We can also refer to this style of game as a semi-autonomous world. We say semi-autonomous because the clock must still be manually advanced. In this sense, the game has its own defined rules and logic and the game players are responsible for constructing the next state of the world. Our upcoming delayed transactions mechanism will be able to enable fully autonomous worlds (no manual clock advancement required).
The Players
Players can potentially be any address in the blockchain (ETF network). The game deployer sets conditions for player eligibility (e.g. max 10 players, prove DAO membership). Each player prepares a ‘move’ by first creating a commitment to their ‘move’ (for example, the sha256 hash of the move). Then, they use timelock encryption to encrypt it for the game clock’s next event. After playing, players do not explicitly need to interact with the game until planning their next play.
The semi-trusted Executor
This role could really be performed anybody or it can be specifically configured by the game deployer. For example, executor assignment can be made part of the game itself. The executor advances the game clock by supplying correctly decrypted plaintexts (player moves) to the contract via the advance_clock function.
P2P Semi-Autonomous Game Framework
To formalize and generalize these concepts, we provide a sketch of a generic framework for semi-autonomous p2p games. There are three basic phases, setup, play, and clock advancement.
Setup Phase
During the setup phase, the game deployer determines the event schedule for game events as well as the initial state of the game and the rules of the game, which are shared with all players.
Define an event schedule function which deterministically outputs the slot when events are triggered. For example, a function f(n) = initial_slot + 10*n generated events at slots initial_slot + 10, initial_slot + 20, and so on.
Define an initial state for the game. In practice, assuming the game is implemented as a smart contract, this would look like defining the initial values for the contract storage.
Publish the game rules within the logic of the advance_clock function.
Play Phase
In the play phase, each player chooses a “play” for an future event e_k. Each play is an action that would be valid under the logic of the advance_clock function. For now, let A be the space containing all valid actions. Then:
Each player chooses some action a in A.
The player creates a commitment to their action a by calculating the hash H = Sha256(a). In the case where the space A is small, it could be easy to determine which element of A is the preimage of the hash. In such a case, we can choose a random number r and use it when preparing the hash, producing H = Sha256(a (xor) r). In this case, the player would produce both the hash H as well as the value r. We will proceed without the value r for now.
The player uses timelock encryption to encrypt their play, producing a ciphertext CT.
Finally, they publish the tuple (CT, H, e_k).
Clock Advance Phase
This is the final phase of a ‘round’ of play. In this phase, the semi-trusted executor is responsible for decrypting ciphertexts produced during the play phase and providing them to the advance_clock function.
Fetch all ciphertexts produced for the round ek, stored as a mapping {PK → (CT, H)} where PK is the public key of the origin that produced the ciphertext.
Decrypt each ciphertext in the mapping above call advance_clock({PK → PLAINTEXT: PK published the play CT for round ek}).
The advance_clock function’s logic:
verifies that each players move is valid by calculating Sha256(plaintext) and comparing agains the one published by the player
run the game logic once all player’s valid plays are produced
and we are done! The clock has advanced.
With that said, the sketch above leaves a lot of room for improvement. It mentions little in terms of handling adversarial behavior. For example, if a user issues an invalid ciphertext or if a semi-trusted executor. This can be accounted for within the logic of the contract but could get quite complex. To this end, we are working on developing a delayed transactions framework which takes this idea one step further. Instead of using timelock encryption on values that can be used later on in an interactive game, delayed transactions apply to entire transactions. This paves the way for non-interactive autonomous worlds powered by the ETF network.
Next Steps
We have developed an timelock auction based on this mechanism. In the timelock auction, an orchestrator contract deploys instances of auction contracts, where the main game logic (advancing the clock) can occur. You can check out the auction here!
In the next installment of this series, we show how to build a game of bit-roulette on the etf network! Check out part 2 here!
Stay tuned! Interested in building something? Say hi on discord!
Learn more about the etf network: https://etf.idealabs.network
Check out the project at: https://github.com/ideal-lab5