blockchain-data-engineering-toolkit/game-protocol-design/README.md

design of a protocol for management and bartering of game (NFT) assets

I. introduction

we leverage the principles of simplicity first, composability, and extensibility to design a plan to implement an end-to-end (first version of a) marketplace protocol for managing game NFT assets.

our protocol is designed to take advantage of non-fungible tokens (i.e., EVM’s compatible standards such as ERC-721, ERC-1155, and extensions) for game assets, which includes ownership (the address that holds the token or the), provable scarcity (through rarity traits and authenticity), interoperability, and emitting events when the state changes.

storage and computation costs are expensive and restricted on the ethereum blockchain. to overcome the challenges regarding searching, sorting, notification, and bartering, our hybrid design contains both on-chain and off-chain components.

in addition, the blockchain trilemma states that only two can be guaranteed among: decentralization, security, and scalability (similarly to the broader CAP theorem). since ethereum communities emphasize that decentralization and security are prerogatives, we design a solution that improves scalability through an off-chain microservice infrastructure (which can be deployed in a cloud service such as AWS, GCP, azure, vercel, etc.).

while these choices might initially compromise certain aspects of decentralization of the protocol, our modular design allows for gradual improvements and progressive decentralization in future versions that could take full advantage of blockchain technologies, for instance, by exploring layer-2 strategies.

In the subsequent sessions, we discuss the design and roadmap for our protocol, concluding with a survey on improvements, roads not taken, and their merits and demerits.

---

II. assumptions

we make the following assumptions in our design:

• the game's assets smart contracts are already available in another protocol and platform, which we have access to through the blockchain APIs.

• the player already has a digital wallet on which the assets are minted to. the assets are not soulbound, i.e., they can be transferable.

• the game's assets smart contracts contain (immutable) metadata that indicates an asset's rarity and utility (e.g., name, category, permanent URL for thumbnail, traits, required level).
  • our protocol will use this data to calculate a "rating" for the asset, which facilitates bartering (illustrated in the frontend sketch as a 1-5 stars rating).
  • the algorithm calculating this rating is out of the scope of this document, but we incorporated it into our modular microservice infrastructure.

• although this is a high-level design and we won't explicitly specify our protocol's smart contracts, they should contain two mutable boolean variables (or a logic variation):
  • EQUIPPED: specifying that the player's avatar is wearing the asset. this variable should be in sync with the game's main protocol.
  • FOR_TRADE: specifying that the player has marked the asset for bartering.

• as our protocol only focuses on bartering, the original asset's smart contracts have no logic for secondary market fees (or are irrelevant in our context).

• our protocol's smart contracts contain logic for a marketplace's fee in each barter transaction, and this is the only fee we consider in this design.

---

III. protocol layers

the frontend layer should provide the functions sketched in figure 1, consisting of a simple dashboard that can be built on a javascript/typescript framework:

• the only extra complexity is the integration with browser wallets.

• signning up or logging in should leverage the game's original protocol or simply be achieved through the user's wallet, as we are not creating a separate profile database or gathering personal data for the user.

the backend layer consists of:

• a database solution to track bartering operations (e.g., a noSQL such as mongoDB or an RDBMS supporting big data).

  • in the simplest form, every time a user places a bartering bid on an asset, the database could create an entry with the asset's and the user's address (or tokenId). this entry would be deleted when the bid is refused or accepted.
  • this approach could be later replaced by decentralized alternatives (e.g., kwil, orbitDB, bigchainDB, convenantSQL, ceramic).

• an orchestration infrastructure, through a kubernetes solution written on terraform.

• microservices for off-chain searching and sorting (e.g., ELK, biguery, cloudsearch, hive), notification system (e.g., a simple cloud messaging service such as AWS SNS or a more elaborated pub/sub solution such as AWS SQS, Kafka, ZeroMQ, AWS Kinesis, RabbitMQ), and an asset rating evaluation (through an in-house algorithm leveraging the assets' traits as input).

• a CI/CD pipeline (e.g., jenkins, circleci, gitHub actions).

• depending on the scale of the project, we might want to rely on something other than blockchain data availability, so we could consider adding a database to cache the smart contract events and keep track of ownership (e.g., Redis). This extra step is included in the roadmap below.

• likewise, any gateway and CDN solution should be incorporated in this layer.

finally, the blockchain layer contains our protocol smart contracts and their test suites. a multi-signature wallet (e.g., gnosis) could be leveraged to enhance the security of this deployment.

---

IV. implementation roadmap

---

V. roads not taken in our approach

a full on-chain narketplace for auctions with a native token

ideally, a marketplace should use smart contracts to fully control asset auctions and transactions. examples of this approach are sandbox or axie infinite marketplace's contract for auction.

however, since we are only focusing on bartering, this solution is overkill as creating a new token brings several challenges, such as extra engineering resources, adoption, tokenomics design, and security concerns.

a full on-chain decentralized autonomous bartering algorithm

in general, finding multiple "coincidence of wants" of various assets translates to finding hypercycles in directed hypergraphs (an NP-complete problem). Therefore, the bartering problem in a distributed setting is similar to dijkstra’s banker’s problem.

an on-chain implementation of this algorithm is tricky. In its most naive form, the design could be costly and probably prone to tampering, fraud, and MEV exploitation. in addition, it would need to assume a large amount of simultaneous trades.

a coincidence-of-wants bartering algorithm with off-chain batches

instead of leveraging an off-chain database solution, we could move our bartering logic on-chain by implementing a system for "coincidence of wants" with batch transfers.

in this approach, when multiple intents for the same asset are within a batch, there could be an opportunity for a peer-to-peer swap that doesn't rely on the main network.

a successful example in DeFi is the cowswap protocol, which collects and aggregates intents off-chain, setting them on batches. the batches are run by third-party solvers.

this design would need to assume a large number of trades at the same time and that there will be willed solvers (or an extra in-house structure) to run the batches.

an NFT-focused chain or L2

a few successful decentralized game platforms (such as enjin and immutable) have adopted an NFT-focused chain or L2 solution to customize the process of multiple NFT transfers, tracking metadata and provenance, facilitating intellectual property, and interoperability among chains.

however, there is a massive overhead to building, maintaining, governing, and creating the adoption of a new blockchain and a native token, making this solution unsuitable for our bartering protocol.