System and method for facilitating blockchain applications

Abstract

A method for facilitating blockchain applications includes enabling at least one application implemented on a blockchain to access a scalability engine and facilitating execution of the application using the scalability engine. The scalability engine can employ on-chain smart contracts that act as a coordinator with an off-chain state machine that computes the state of the application. Various other methods, systems, and computer-readable media are also disclosed.

Description

[Technical Field]

[0001] This application relates to blockchain application technology. Applications, such as gaming applications, can connect to or operate in conjunction with blockchains. Nevertheless, the systems involved may contain various deficiencies or suboptimalities. [Background technology]

[0002] As one illustrative example, involved systems may favor centralized over decentralized approaches. These involved systems may rely on recent generation blockchain technology tied to a centralized Web2 gaming stack. Rather than innovating, these projects merely use the blockchain as a ledger for tokens (e.g., non-fungible tokens (NFTs)), with the entire gaming application itself running on centralized, dedicated servers. In these involved systems, the corresponding development teams inevitably become a centralized point that is perpetually imposed on users, simply because their technology stacks never allow for true decentralization. Examples of these challenges, as well as the associated issues and corresponding solutions, are described in more detail below. Summary of the Invention [Means for solving the problem]

[0003] In some examples, a method for facilitating blockchain applications includes providing access to a scalability engine for at least one application implemented on the blockchain, and facilitating execution of the application using the scalability engine. The scalability engine may employ an on-chain smart contract that acts as a coordinator with an off-chain state machine that computes the state of the application.

[0004] In some instances, the applications include blockchain gaming applications.

[0005] In some cases, an off-chain state machine calculates the state of a blockchain game application.

[0006] In some instances, the scalability engine allows users accessing the blockchain to read on-chain data that confirms the latest state of the blockchain gaming application in a zero-trust configuration.

[0007] In some cases, the blockchain stores almost all of the data required for the operation of a blockchain gaming application.

[0008] In some instances, the blockchain game application implements passive time, allowing the blockchain game application to progress while bypassing requirements for users to submit new transactions to the blockchain.

[0009] In some cases, the state machine acts as an L2 (Layer 2) chain.

[0010] In some instances, the scalability engine calculates the gas fee based on calculations regarding the user address, the game input, and the digital signature of the game input.

[0011] In some cases, the scalability engine makes gas and transaction fees strictly dependent on the number of bytes a user submits to the application for their input.

[0012] In some instances, the scalability engine will enable true blockchain player-versus-environment gaming.

[0013] In a further example, a corresponding computer-readable medium can include instructions that, when executed by a physical processor of the computing device, cause the computing device to perform a method including providing access to a scalability engine for at least one application implemented on a blockchain (enabling at least one application implemented on the blockchain to access the scalability engine) and facilitating execution of the application using the scalability engine. The scalability engine can employ an on-chain smart contract that acts as a coordinator for an off-chain state machine that computes the state of the application.

[0014] In a further example, a corresponding system can include an access-providing module stored in memory that provides access to a scalability engine for at least one application implemented on the blockchain (enabling at least one application implemented on the blockchain to access the scalability engine), a facilitation module stored in memory that facilitates execution of the application with the scalability engine, and at least one physical processor configured to execute the access-providing module and the facilitation module. The scalability engine can employ on-chain smart contracts that act as a coordinator for an off-chain state machine that computes the state of the application.

[0015] The accompanying drawings illustrate several embodiments and are a part of this specification, and together with the following description, these drawings demonstrate and explain various principles of the present invention. [Brief explanation of the drawings]

[0016] [Figure 1] FIG. 1 is a block diagram of an example of a system for facilitating blockchain applications. [Figure 2] 1 is a flow diagram of an example of a method for facilitating a blockchain application. [Figure 3] 10 is a flow diagram of another example method for facilitating a blockchain application. [Figure 4] 10 is a flow diagram of another example method for facilitating a blockchain application. [Figure 5] Block diagram of the scalability engine architecture. [Figure 6] FIG. 1 illustrates example code and corresponding data related to an example method for facilitating a blockchain application. [Figure 7] FIG. 1 illustrates example code and corresponding data related to an example method for facilitating a blockchain application. [Figure 8] FIG. 1 illustrates example code and corresponding data related to an example method for facilitating a blockchain application. [Figure 9] FIG. 1 illustrates example code and corresponding data related to an example method for facilitating a blockchain application. [Figure 10] FIG. 1 illustrates example code and corresponding data related to an example method for facilitating a blockchain application. [Figure 11] FIG. 1 is a block diagram comparing related non-fungible gaming tokens with stateful non-fungible tokens. [Figure 12] FIG. 1 is a block diagram of an example computer system capable of implementing one or more of the embodiments described and / or illustrated herein. [Figure 13] FIG. 1 is a block diagram of an example computer network capable of implementing one or more of the embodiments described and / or illustrated herein. DETAILED DESCRIPTION OF THE INVENTION

[0017] Throughout the drawings, the same reference characters and descriptions indicate similar, but not necessarily identical, elements. The embodiments described herein are susceptible to various modifications and alternative forms, and specific embodiments have been shown by way of example in the drawings and will be described in detail herein. However, it is not intended that the embodiments described herein be limited to the particular forms disclosed. Rather, the present invention covers all modifications, equivalents, and alternatives falling within the scope of the appended claims.

[0018] Detailed Description of the Embodiments The present invention is generally directed to systems and methods for facilitating blockchain applications. A detailed description of an example system for facilitating blockchain applications is provided below with reference to Figure 1. A detailed description of a computer-implemented method is also provided with reference to Figures 2-4. Additionally, a detailed description of an example computer system and network architecture capable of implementing one or more of the embodiments described herein is provided with reference to Figures 12 and 13, respectively.

[0019] FIG. 1 is a block diagram of an example system 100 for protecting users. As shown, the example system 100 may include one or more modules 102 for performing one or more tasks. For example, as described in more detail below, the example system 100 may include an access providing module 104 that provides access to a scalability engine for at least one application implemented on the blockchain (enabling at least one application implemented on the blockchain to access the scalability engine). The system 100 may also include a facilitation module 106 that facilitates execution of the application using the scalability engine. In some examples, the scalability engine may employ an on-chain smart contract that acts as a coordinator for an off-chain state machine that calculates the state of the application. While illustrated as separate elements, one or more of the modules 102 in FIG. 1 may represent one or more portions of a single module or application.

[0020] In particular embodiments, one or more of the modules 102 in Figure 1 may represent one or more software applications or programs that, when executed by a computing device, cause the computing device to perform one or more tasks. For example, as described in more detail below, one or more of the modules 102 may represent modules stored on and configured to execute on one or more computing devices. One or more of the modules 102 in Figure 1 may also represent all or one or more portions of one or more special-purpose computers configured to perform one or more tasks.

[0021] 1 , the example system 100 may also include one or more memory devices, such as memory 140. Memory 140 generally represents any type or form of volatile or non-volatile storage device or medium for storing data and / or computer-readable instructions. In one example, memory 140 may store, load, and / or maintain one or more of the modules 102. Examples of memory 140 include, without limitation, random access memory (RAM), read-only memory (ROM), flash memory, hard disk drive (HDD), solid-state device (SSD), optical disk drive, cache, any variation or combination of one or more of these, and / or any other suitable storage memory.

[0022] As shown in FIG. 1 , the example system 100 may also include one or more physical processors, such as physical processor 130. Physical processor 130 generally represents any type or form of hardware-implemented processing device capable of interpreting and / or executing computer-readable instructions. In one example, physical processor 130 may access and / or modify one or more of modules 102 stored in memory 140. Additionally or alternatively, physical processor 130 may execute one or more of modules 102 to facilitate a blockchain application. Examples of physical processor 130 include, without limitation, a microprocessor, a microcontroller, a central processing unit (CPU), a field-programmable gate array (FPGA), a soft-core processor, an application-specific integrated circuit (ASIC), one or more portions of one or more of these, one or more variations or combinations of these, and / or any other suitable physical processor.

[0023] The example system 100 in FIG. 1 can be implemented in a variety of ways. For example, all or a portion of the example system 100 can represent one or more portions of the example engine architecture 500 in FIG. 5, which is described further below. More generally, the system 100 can be implemented by an end-user computing device in conjunction with a server (e.g., a server facilitating blockchain transactions, such as middleware 510 or web server 522 in FIG. 5), the computing device and the server communicating over a network. A computing device can generally represent any type or form of computing device capable of reading computer-executable instructions. In some examples, a computing device can represent any computing device. Additional examples of computing devices include, without limitation, laptops, tablets, desktops, servers, cellular phones, personal digital assistants (PDAs), multimedia players, embedded systems, wearable devices (e.g., smart watches, smart glasses, etc.), smart vehicles, smart packaging (e.g., active or intelligent packaging), game consoles, so-called Internet of Things devices (e.g., smart appliances, etc.), variations or combinations of one or more of these, and / or any other suitable computing device.

[0024] A server may generally refer to any type or form of computing device capable of facilitating the execution of one or more example methods described herein. Additional examples of such servers may include, without limitation, security servers, application servers, web servers, storage servers, and / or database servers configured to run particular software applications and / or provide various security, web services, storage services, and / or database services.

[0025] These computing devices and servers communicate over a network, which generally refers to any medium or architecture capable of facilitating communication or data transfer. In one example, a network may facilitate communication or data transfer using wireless and / or wired connections. Examples of networks include, without limitation, an intranet, a wide area network (WAN), a local area network (LAN), a personal area network (PAN), the Internet, power line communication (PLC), a cellular network (e.g., a Global System for Mobile Communication (GSM) network), one or more portions of one or more of these, one or more variations or combinations of these, and / or other suitable networks.

[0026] 2-4 are flowcharts of an example computer-implemented method for facilitating blockchain applications. The steps illustrated in FIGS. 2-4 may be performed by any suitable computer-executable code and / or computer system, including system 100 in FIG. 1, engine architecture 500 in FIG. 5, and / or variations or combinations of one or more thereof. In one example, each of the steps illustrated in FIGS. 2-4 may represent an algorithm, the structure of which may include and / or be expressed by multiple substeps, examples of which are provided in more detail below. Additionally, although not explicitly shown in the drawings, the methods of FIGS. 3-4 may be implemented by module 102 in a manner parallel to the implementation of the method of FIG. 2 (i.e., by respective pairs of modules implementing respective steps of the corresponding method).

[0027] 2, in step 202 of method 200, one or more of the systems described herein can provide access to a scalability engine for at least one application implemented on the blockchain. Similarly, in step 204, one or more of the systems described herein can use the scalability engine to facilitate execution of the application. In these examples of method 200, the scalability engine can use an on-chain smart contract that acts as a coordinator for an off-chain state machine that computes the state of the application.

[0028] As used herein, a "scalability engine" or scalability solution refers to a software-implemented engine, solution, or framework that interfaces with or coordinates a blockchain to improve transaction or processing speed, bandwidth, number, frequency, or other scalability-related metrics. In other words, as one skilled in the art will understand, a scalability engine can address or ameliorate a scalability problem, which occurs when the amount of data processed by a blockchain reaches a limit or maximum due to a lack of capacity or resources associated with the blockchain. As these terms are understood by one skilled in the art, and as described in further detail below in connection with Figures 5-11, an example method of this application can be implemented as a Layer 2 scalability engine and can be implemented as a rollup-adjacent technology rather than a classic rollup.

[0029] In various instances, the application engines use rollups alongside research (state machines like the GA (Google Analytics) state machine), thereby bringing scalable, trustless blockchain games to the world. This means that any games built with these engine implementations will inherit the same scaling properties as rollups, with the addition of additional optimizations (parallelism, input compression, etc.) targeted at gaming use cases. In some instances, games built with one or more disclosed implementations of the application engines may not be rollups in the strict sense (although they may be new state machines that live or operate as L2), but these games may nevertheless be able to take advantage of features of rollup technology such as validium or data availability chains, and thus remain competitive over the long term.

[0030] In various implementations, this application engine provides orders of magnitude better on-chain scaling without adding new points of concentration to the system. Various implementations of this engine can achieve up to 98.500% reduction in on-chain gas fees compared to a typical newly released on-chain game. In contrast, if such games were built using one or more implementations of the engine, they would have near-constant gas fees, regardless of how much complexity they add to their game logic. Instead, such games representative of related technologies would feature an exponential curve in which users continue to pay more and more.

[0031] Because the engine's implementations are based on rolling and side-by-side research, the engine is able to leverage on-chain security with 100% off-chain game logic. Furthermore, the engine's implementations offer a higher level of flexibility than current generation rollup technologies, and by not requiring a batcher / sequence, centralization concerns are reduced. This technology has already been able to achieve, for example, a 10,900% efficiency gain compared to related technology games.

[0032] To understand how an engine implementation can be so effective, it's helpful to consider a pair of equations and break down the benefits step by step. In the first equation, g=i×12+24,349, the reader can see that the gas cost depends on i, where i is the number of bytes the user submits as their input to the game. This means that, unlike on-chain games, the gas cost to a user (and therefore the transaction fee) depends entirely on the amount of data the user submits as input, regardless of how many loops the code executes, how long it takes to execute, how much it mutates or generates the global game state, and all other performance-related factors.

[0033] While related systems may seek to optimize for input size, these engine implementations unlock every other scaling axis for free by making the gas cost depend precisely on i. In addition to these significant benefits, two other values ​​are part of the equation: 12 is, unfortunately, a static cost that scales with the input data and cannot necessarily be reduced, while 24,349 is the base amount users must pay when they issue their own transactions with game inputs.

[0034] Therefore, by introducing the concept of batching (putting game inputs submitted by multiple users into the same transaction), the above technique can average this fixed cost across all users. This is what the second equation, g = ((40 + i + s) × n × 12 + 24,349), achieves. Each user can provide their address (40), their game input (i), and a signature of their input (s), where this signature is created using the private key corresponding to the address. This means that while the number of bytes each user needs to provide is actually larger, this increase in base size is a large net positive, as it is offset by the discount of 24,349. Games built with one or more implementations of the engine that can take advantage of both users submitting their own game input and users with a choice of preferences deliver a solution that enjoys cost (and potentially UX) savings and improvements.

[0035] Finally, with in-place batching, it becomes very practical to look at bespoke (customer-built) compression protocols that further reduce the size of i across all users in the batch. Within a batch with hundreds or thousands of user inputs for the same game, a lot of data is likely to be repeated, so compression algorithms and input reduction mechanisms can be developed to further optimize this.

[0036] The fact that these engine implementations can build on research alongside rollups and manage to offer such large scaling benefits raises the topic of comparing classic rollups with innovations alongside rollups from scratch. As some blockchain games choose to implement their game logic on-chain, the question arises as to whether these games could be ported to rollups and reap the same benefits as these engine implementations. While this may sound theoretically possible, it raises a long list of issues.

[0037] When it comes to storage issues, rollup-based games are at a significant disadvantage. On the one hand, they are severely limited by the constraints of the Ethereum Virtual Machine (EVM), which means they cannot easily store large amounts of data. The EVM only allows data to be stored in 32-byte slots, and the EVM's default gas consumption highly inhibits storing large amounts of data. While it is possible to fork the EVM to tweak and optimize it to accommodate this, this is a breaking change that breaks the inherent compatibility of the EVM and thus requires a custom implementation (thus losing access to using all of the current EVM contracts on rollups).

[0038] On the other hand, using the EVM means that the games involved do not have access to world-class relational databases (such as MySQL, PostgreSQL, etc.). Instead, game developers are left with a very unattractive, low-level interface to access stored data with 1 / 100th the query power compared to these battle-hardened databases used daily by millions of projects. This leads to much more complex and bug-prone code, slower development times, and a much worse developer experience.

[0039] Second, the EVM also has very strong constraints regarding its execution time and available memory. The EVM is gas-aware, so the more RAM a game developer uses, the more gas the EVM uses. A rough estimate of the EVM with default parameters puts the maximum amount of memory available in a single block at roughly 2.5GB (gigabytes) (meaning it will use 100% of the gas for this block and cannot do anything else). This is a very limited amount and has a high price tag attached in the form of transaction fees.

[0040] However, memory complexity isn't actually the worst part from a game developer's perspective. The EVM is stack-based with a maximum depth of 1024, each unit being 32 bytes, and a maximum query stack depth of 16. This has numerous implications across the design of game smart contracts, including, for example, being able to access only 16 local variables at a time. Many times this means that the complexity of managing data is prohibitively high, especially for large consumption.

[0041] Game developers who rely solely on the EVM are hamstrung by using fundamentally outdated technology, on par with trying to fit a game onto a floppy disk, running on computers with very limited computing and memory capabilities, and forced to use very low-level languages ​​(e.g., Solidity) all the while. Even though developers have to deal with these low-level issues, the downside is that they cannot take advantage of any of the performance benefits that true systems languages ​​like Rust or C++ offer.

[0042] In various examples, the present engine, on the other hand, allows developers to use whatever language they most prefer for their core game logic, thus allowing developers to use their libraries / frameworks / stacks that they are already familiar with, with significant performance improvements.

[0043] Third, in terms of performance, games on Rollup are bound by all of the design decisions of the EVM, the most important of which is that the EVM is a purely sequential computational virtual machine, with no concept of parallelism. Therefore, all transactions submitted to Rollup must be executed in order, one after the other. This execution happens off-chain, and developers sometimes try to solve this problem by simply using more powerful CPUs, but increasingly this appears to be a ceiling on how advanced games can be.

[0044] In some cases, the engine's innovation from the end user's perspective is the addition of passive time, which generally has a huge effect, improving scalability and unlocking new game models that were previously simply not possible on the blockchain.

[0045] With smart contract-powered protocols, the on-chain state only ever changes when a transaction is added to a block. In the context of games, this means that the game never updates unless one of the users submits a transaction, triggering a smart contract. This means that these blockchain games passively have no concept of in-betweenness, which prevents many core features from being possible.

[0046] In various implementations, on the other hand, the present engine allows passive time to advance without a single transaction being issued, thereby providing the following example benefits to game developers and users: Unleash true blockchain PvE (Player vs Environment) games, where players must face off against non-human AI (Artificial Intelligence), which actively moves / attacks while time passes. Providing blockchain PvP (Player vs Player) games with the ability to implement AI elements that automatically create random map events and / or match conditions, thus providing dynamic and unpredictable gameplay. Enables games where the user sets extensive (macro) strategies, and in such games the device continues to execute its tasks in single blocks (e.g., fetch resources). Allow users to lock in game moves, which will be done automatically in the future (strategy-focused games). Supports passive classes in games, where users can only make one or two moves per day, but the map / battle / game state changes constantly every 2-3 seconds. · Give the game an opportunity to implement a day / night cycle.

[0047] Furthermore, in some implementations, the engine of the present application allows passive time to be provided during a game without charging the user a single cent extra, thus saving players potentially thousands of dollars in transaction fees over time, thereby significantly improving the gaming experience.

[0048] In addition to all of the previously described benefits that can be provided by various implementations of the engine, the following list summarizes additional examples of benefits realized in various embodiments compared to using EVM rollup: Lower transaction fees due to better compression of game inputs, no on-chain state root required, no intermediate EVM boilerplate required, no optimistic or zero-knowledge primitives required. There is no risk of rollback due to a bad actor submitting an invalid state transaction as in optimistic rollup (rollback would reset everyone's game state to its original state and require implementing rollback checks in every game, at the cost of higher complexity and worse UX). Unleash advanced, unpredictable randomness generation that leverages the security of the underlying blockchain leader selection. Enables stateful NFTs (explained in more detail below). For rollup EVMs, stateful NFTs require forking the EVM and redesigning how rollups interact with L1 (because rollups with EVMs do not reference L1 for who has the right to edit the rollup EVM smart contract state). Freedom to use any programming language to develop games, taking advantage of existing programming ecosystems, and circumventing EVM limitations. Relying strictly on batchers (as rollup does) results in higher average latency, which prevents certain game styles from being fun / playable. In various instances, it allows the engine to take advantage and direct user input submission without complex game theory. In various instances, the engine can run on top of the rollup and keep all of the benefits of each.

[0049] In various instances, engines allow games to rely on the underlying blockchain for decentralization and security, but with the freedom to scale and offer novel features. In contrast, related blockchain gaming systems do not realize these benefits. As further explained above, these related systems generally opted for centralized solutions due to the short-term convenience they offered. In other words, corresponding developers relied on recent generations of blockchain technology tied to centralized Web2 gaming stacks for these related solutions. Rather than innovating, the related systems merely use the blockchain as a ledger for tokens such as NFTs, but the entire game itself runs on centralized, dedicated servers. Developers of these related systems inevitably become a centralized point that is perpetually imposed on users, simply because their technology stacks never allow for true decentralization.

[0050] FIG. 3 illustrates another example method 300 for facilitating blockchain applications. The example method 300 may particularly relate to stateful non-fungible tokens. At step 302, one or more of the systems described herein may provide a blockchain gaming experience to an end user. The blockchain gaming experience may be provided, for example, by an engine implementation, as further described above. Similarly, at step 304, one or more of the systems described herein may assign non-fungible tokens to an end user in response to input from the end user. In particular, as described in more detail below, non-fungible tokens may have the property of being stateful, which may refer to these tokens as recording dynamic transitions of state (e.g., game state), as distinguished from traditional or classic NFTs.

[0051] Classic NFTs within the relevant blockchain gaming environments are simply bare-bones ERC-721 (or ERC-1155) tokens with no dynamic state attached. In other words, a user can buy an NFT that represents something like an in-game device, but this NFT always and forever represents this static device. The device attached to this NFT can never accumulate experience, level up, acquire items, add new armor, or do anything that actually changes the state of the device itself. At best, the relevant systems burn the old NFT and create a new NFT that represents an upgraded version of the initial device. This kind of solution is an ill-fitting Band-Aid for a larger problem: it limits the power of these NFTs in games.

[0052] The process of upgrading NFTs by burning is extremely cumbersome for end users, has high gas costs due to running smart contracts on-chain, and is a very fragile mechanism with limited usability. The game itself cannot be designed to have significant complexity within this domain, as the graph / path of smart contract calls and extensive NFT burning / minting would suddenly grow by multiple orders of magnitude, leading to unmanageable and expensive complexity.

[0053] In contrast to classic non-fungible tokens, the present technology leverages one or more of various novel innovations in different embodiments of the engine to build a new class of token: stateful NFTs. Based on research into state machines, such as the GA state machine underlying various examples of the engine, it becomes possible to create and offer non-fungible tokens that are stateful, with in-game state information encoded within them. This breakthrough effectively transforms NFTs from boring / dead tokens that forever represent the same asset into living assets that continually accumulate changing / dynamic attributes (e.g., level / stats / equipment, etc.) and accumulate more over time. Furthermore, when an NFT is sold on the open market, all of these dynamic attributes can potentially be transferred from one player to another, yet no additional information is maintained on-chain, further meaning that NFTs are 100% composable with all of the current NFT infrastructure in the EVM ecosystem.

[0054] An analogy is useful to explain the relevance of stateful non-fungible tokens. The present invention is similar to when Nintendo® added a backup battery to its handheld game cartridges for the Game Boy®. Before the backup battery, the games were still fun and exciting, but users had to keep replaying the same levels, and everything felt very static and tedious. Gamers didn't realize what they were missing at the time, but once gamers began playing games with backup batteries, like the original Pokémon®, it became abundantly clear to end users what they had been missing. The addition of a backup battery, and therefore the ability to maintain game state, opened up previously unimaginable vistas. By allowing users to save the Pokémon they caught and continue to level themselves up, this meant that users were accumulating permanent value to the player over time. Nintendo® understood this and capitalized on it with the ability to trade Pokémon® with others via the Game Link cable. This brings a new realm of innovation to gaming overall, moving it away from arcade-style, ephemeral games and now allowing users to have valuable, persistent game state that they can own and pass on to others; stateful NFTs, Figure 3, are indeed a similar innovation in this regard. Stateful NFTs maintain persistent game state while the underlying blockchain technology, by analogy, acts as a game link cable that allows users to trade their stateful NFTs.

[0055] One useful embodiment of a stateful NFT corresponds to one in which the stateful NFT functions as an end-user account, as described further below. In the future of truly decentralized gaming, it may be desirable for users to accumulate state over time. In classic online games, this is done with accounts, but this model generally relies on a centralized server. Related blockchain gaming solutions attempt to limit the amount of permanent game state as much as possible, and whenever limiting it, storage is always attached to a wallet address.

[0056] However, wallet addresses are disappointing for the job. Wallet addresses are not tradable, which defeats the purpose of having the game on a distributed ledger in the first place. Furthermore, if a user ever upgrades, switches wallets (i.e., hardware wallets), or ends up with a solution that compromises their private keys, they have no path to remediation.

[0057] In contrast, stateful NFTs function as account addresses, solving the problems outlined above. Account-stateful NFTs allow each user to maintain state for each game they play within the blockchain environment. Stated differently, each of these NFTs effectively functions as an "online account," allowing users to store their wins / losses, their in-game items, and their in-game state. Thus, in various implementations, users may request or be required to obtain an account NFT in order to fully participate in such gaming experiences.

[0058] Unlike related blockchain game projects that optimize for short-term profits with their own NFTs, account NFTs can be a core part of at least one embodiment of this technology. For this reason, account NFTs in these examples can be made accessible at a reasonable price to end users. As one illustrative example, account NFTs can be priced at a smaller price point (e.g., $10) in a stablecoin (a type of cryptocurrency) that is characterized by its lack of fluctuation due to demand. In this embodiment, as further explained above, such a pricing scheme encourages an increasing number of users to enter the game environment rather than allowing early users to outpace future users.

[0059] Just like how a user creates an account in an online game with visible statistics for level / items / publicity, in some instances all of this data can be attached to an account NFT. A user can optionally sell their account NFT to another person, and the buyer in this scenario will have access to everything the previous owner had. By analogy, this action is just like an account transfer from user A to user B, but performed with an account NFT rather than a traditional user account.

[0060] This kind of account trading was heavily discouraged in the world of MMOs (Massively Multiplayer Online Games), and the label "real-world trading" was a prohibitable offense. Nevertheless, these efforts did not prevent black markets from emerging, still capitalizing on the demand.

[0061] However, in some implementations of method 300, account NFT trading can be explicitly inserted into the system as a core mechanism. Users who invest time in building NFTs can then sell them to others on the open market. Because EVN-based blockchains are public, anyone in the world knows when an account NFT is transferred from user A to user B. Therefore, it is unlikely that someone would be willing to risk selling their private key to another (since there is no security once the private key is shared), making account NFTs advantageous in some instances as a first choice for executing trades. Consequently, account NFTs offer the benefit of new users wanting to quickly find equally willing sellers, with the benefit that all such trades are visibly recorded on-chain. Furthermore, account NFTs, in some instances, can enable the implementation of other protocols on top of them, which can filter out / reject certain portions of account NFTs that have been transferred between wallets in the last X days, thereby addressing all of the issues associated with the corresponding model in Web2.

[0062] Within the example blockchain gaming environment outlined above, it is inevitable that users will begin to desire to convert their favorite classic NFTs into account NFTs. In some instances, as further explained above, this may enable such players to take NFTs purchased on decentralized marketplaces, acquired from other games, or home-grown NFTs and convert them into stateful NFTs, specifically account NFTs. Thus, NFTs may thereby evolve from, in this example, being just plain old JPEGs to now possessing the capabilities associated with NFTs that maintain dynamic state.

[0063] Furthermore, the option to convert a classic NFT into a stateful NFT or account NFT in these examples can be monetized through premium pricing. In contrast, other users may still have the option to create a standard account NFT using the lower fixed price point described above. Furthermore, the tradable nature of stateful NFTs can create new mechanisms for increasing the value of existing classic NFTs. In other words, a user can acquire already valuable classic NFTs (e.g., CryptoPunk) and convert these classic NFTs into stateful or account NFTs, thereby accumulating additional game state information on top of the information corresponding to the pre-existing classic NFT. As an optional illustrative example, a user may no longer simply own "CryptoPunk 1859," as in the illustrative example user account, but instead own "CryptoPunk 1859" with the maximum level in Game A, own some rare cosmetics in Game B, and be at the top of the leaderboard in Game C. Each of these additional pieces of dynamic state attached to an NFT increases its value.

[0064] In some instances, stateful NFTs can also function as in-game item storage boxes, as per method 300. Going back to the account use case of stateful NFTs, corresponding technologies can now utilize blockchain for what works best, with the blockchain acting as a ledger of ownership.

[0065] The vast majority of games in the Web2 world all have some sort of trading system between users. This could be just the ability to send items to someone, potentially the ability to conduct active trades, or even a full-blown auction house. Generally, this requires implementing these ledger-like elements as functionality within the game logic itself. However, this is clearly extremely redundant when a game equivalent to method 300 is running on a ledger running on the EVM, which is orders of magnitude more viable and interoperable than anything an engineer could build inside the game.

[0066] Because of this, stateful NFTs allow an infinite amount of in-game state to be attached to an on-chain NFT, all without spending a single additional unit of gas or increasing transaction fees. In various instances, the stateful NFT itself acts as a bridge between the game and the ledger, thus avoiding the need for any complex bridging mechanisms such as optimistic fraud proofs, zk (zero knowledge) validity proofs, or those classically used by rollups.

[0067] With the above in mind, the stateful NFT technology of the present application may, in some examples, correspond to a storage box NFT. In these examples, a corresponding blockchain game environment may generate a set of storage box NFTs. Furthermore, storage box NFTs may, in some examples, generally be interoperable across multiple different (e.g., substantially all or all) games within the same blockchain game environment. As an illustrative example, a user may purchase a storage box NFT (or receive it for free, but take a percentage each time they trade / sell) and then use this storage box NFT in a game where they have items / gear / cosmetics they want to sell or send to someone else.

[0068] Simply by holding the Storage Box NFT in a corresponding wallet owned by a particular user, the user has the right to add in-game state information or attributes to this wallet. This allows this particular user to fill the Storage Box NFT with many different in-game items that are valuable to others and then go to a marketplace (e.g., OpenSea) to sell these in-game items to other players who are willing to pay a higher price. In these instances, the buyer in such a transaction receives the NFT via the on-chain smart contract that initiated the sale, and once completed, the buyer has full access to all of the in-game items that were in the Storage Box. As new items are released in games within this environment, these new items can be added to the Storage Box NFT without any on-chain smart contract updates.

[0069] FIG. 4 illustrates another example method 400 for facilitating blockchain applications. In particular, method 400 may correspond to a "play2farm" or "play-to-farm" embodiment, described in more detail below. For example, at step 402, one or more of the systems described herein may provide a blockchain gaming experience to a user. Thus, step 402 of method 400 may be equivalent to step 302 of method 300, described further above. Additionally, at step 404, one or more of the systems described herein may cap the amount of rewards available to an end user over a predetermined period of time, during which the end user may play in the blockchain gaming experience in exchange for rewards.

[0070] This technology can revolutionize the field of tokenomics by enabling a new model, Play-to-Farm (P2F), to replace the related Play-to-Earn (P2E) model used by some blockchain games. P2E has significant pitfalls that make it unsustainable in the long term.

[0071] The basic idea behind P2E is that users can continue to play games to earn fungible tokens, which can then be used to perform several basic actions. A clear example can be found in one popular related game, where generating new NFTs requires using the corresponding fungible P2E token. While this initially seems like a lucrative system, the sustainability of these dynamics clearly did not continue throughout the short period that this popular related game was active. This related game has only grown more popular over the last year, and empirically, the price of the P2E token has continued to decline. For example, over a period of approximately 11 months, the P2E token has experienced a token price decline of approximately 98.6%.

[0072] The above examples highlight several reasons why the P2E model is practically undesirable in the long term. Various of these reasons generally stem from Play-to-Earn's attempt to "duct tape" centralized online gaming technology onto newer, decentralized technologies. Because P2E seeks to reward actors for playing its games, it inevitably involves a system that will constantly be exploited by computers that can play 5,000 times faster and in 5,000 times as many browser windows as humans could ever play, thereby destroying the sustainability of tokenomics as a whole. These computers and their operators can be labeled "botters," as those skilled in the art would understand.

[0073] Any blockchain game that rewards players with tokens for successfully performing actions in their game will always have privileged botters who earn the majority of the token rewards. These botters will always dump their tokens into the market immediately, realizing and maximizing their profits at the expense of the long-term success and sustainability of the project. This leaves well-behaved players convinced that the project will eventually lose and become worthless.

[0074] The gaming industry, especially MMOs (Massive Multiplayer Online games), has spent billions of dollars over the past two decades trying to eradicate botting. Even with all of this funding, it has proven impossible to permanently solve botting, no matter how much money is poured into the problem. Even leading game developers around the world today are still playing a constant game of cat and mouse, trying to detect and ban botters.

[0075] This means that any tokenomics model, like P2E, that is susceptible to botting that destroys the project's economy will never be successful in the long term. Projects will inevitably always have to be centralized, as game developers must manage it in a way that bans as many botters as possible and prevents the token price from plummeting toward zero for the time being. Therefore, blockchain P2E games can never be truly decentralized, players can never truly own and control the game, and botters constantly threaten to drag the project's valuation ever lower, subverting the in-game economy relative to actual players. There is no solution to this reality; the only way forward is to start from scratch and build a tokenomics model that takes this problem seriously.

[0076] As further described below, play-to-firm loosely refers to a family of embodiments of the novel tokenomics model disclosed herein. Based on lessons from the failure of P2E, along with useful lessons from the DeFi (decentralized finance) space, P2F offers users a new generation of blockchain gaming tokenomics.

[0077] In P2E, the system seeks to optimize rewarding users so that they spend their tokens to perform game actions, which remove tokens from the global supply. The hope for long-term sustainability lies in users being more incentivized to spend the tokens they earn on the game itself, so that there is greater global demand to use the tokens than if they were sold on the open market. Due to the reality of botting, this is never feasible, as the overwhelming majority of rewarded tokens would go to actors who would immediately dump these tokens on the market, thereby driving down the price.

[0078] However, the play-to-farm described in the embodiments of this application may pursue one or more of the following goals: Botters have no advantage over regular users. Allows users to use the same tokens they purchased for different games within the blockchain environment. Optimize the restriction / removal of fungible tokens from the globally available supply to ensure long-term stability. Reward users with an APY (Annual Percentage Yield) for holding fungible tokens and playing games within the blockchain gaming environment. Limit token burning in favor of locking, encouraging users to buy more tokens and know they will never lose them.

[0079] In short, play-to-farm allows players to participate in token farming. Token farming, in various instances, requests or requires users to stake their tokens in a particular game of their choosing. By staking their tokens in farming, users have the ability to earn APY on their tokens (with additional tokens as rewards) while also generating those tokens to fund the particular game they have staked, as described in more detail below.

[0080] In some embodiments, to realize a particular reward, such as the APY outlined above, a user must play one or more games (e.g., play a particular game in which they have contributed) at least X times within a time period of Y. For example, in particular embodiments, a user may be required to play a particular game in which they have contributed once a week in order to earn an APY. Thus, in this particular example, if a user fails to do so, they miss out on participating in that week's farming and therefore do not receive any rewards. Thus, in P2F, users and botters generally have a completely level playing field, completely avoiding all of the problems of P2E.

[0081] The above examples (i) focus on a particular reward (APY), (ii) are based on the number of game plays over a period of time, and (iii) are examples for a particular game. However, in other or broader examples, the general inventive concept may amount to simply limiting the amount of a particular reward (APY, fungible token, NFC, etc.) that a particular user account can earn per a particular measure of engagement or involvement in a game. In other words, there is or is a constraint on the amount of a particular reward that any user account, botter, or person can earn per unit of time or unit of game engagement within a collection of user accounts, such as all user accounts. In various examples, this limit can be set to an amount that roughly corresponds to a normal or usual amount of game engagement for a natural person (e.g., playing a game once a week), as opposed to behavior associated with a botter. Accordingly, in other examples, different types of rewards can be capped in this manner. The amount of gaming engagement may also be measured in a variety of different ways, such as the number of times the game is executed / played, the number of minutes or hours the game is played, the number of times a particular gaming behavior is performed (e.g., a particular gaming behavior that results in a corresponding particular reward), a measure of gaming activity that accounts for inaction as distinguished from active or aggressive game play, etc. Similarly, measures of gaming engagement may generally be measured over a predetermined period of time, which may be defined in a variety of different ways, such as on a fixed increment schedule (e.g., the user must play the game at least once per week starting at midnight on Friday), or on a rolling basis (e.g., the user must have played the game at least once within the past month).

[0082] In other words, the general concept is to cap or limit the amount of a particular reward, or a particular set of available rewards, such that game involvement above a certain threshold associated with normal human play no longer results in the accumulation of additional such rewards, while game involvement below this threshold still allows the corresponding user account to accumulate additional such rewards, thereby placing both humans and botters on an equal playing field (i.e., it has proven impractical for anti-botting technology to distinguish between the two, and therefore the P2F system caps everyone equally). Furthermore, the definition of the statistical threshold above which game involvement is considered no longer human, and thus above which the corresponding user account can no longer accumulate additional rewards, can be measured in a variety of ways, including manual review, moderation by administrators, and supervised or unsupervised machine learning or labeling techniques, as will be understood by those skilled in the art.

[0083] Returning to the more specific example initially introduced above, at any moment, a user can initiate the process of withdrawing their staked tokens, thereby giving them the freedom to stake those tokens in other games within the same system, use their tokens in DeFi protocols, or whatever else they so desire.

[0084] By looking at existing Point-of-Stake or staking protocols in the blockchain space, the reader can see that it is possible to leverage P2F by staking a very large percentage of the total available token supply. This case is strengthened many times over thanks to the option to withdraw at any point without risk of losing tokens for end users.

[0085] With the above in mind, various embodiments of P2F farming disclosed herein address each of the deficiencies associated with P2E, while nevertheless leveraging lessons from L1 blockchains and DeFi.

[0086] An additional example is where token farming can be used to unlock premium content. In these examples, once a user contributes their tokens to a particular game for farming, the user immediately unlocks a new core element of functionality. In a more specific example, the user actually unlocks all of the corresponding game's core content (units, weapons, cards, maps, etc.).

[0087] Innovation at the smart contract level can help address issues related to Web2 online games. For example, some of these related Web2 online games utilize payment systems with excessively constant micropayments to unlock every small feature. This model repeatedly demonstrates extremely short-sighted play, leading to the player base becoming displeased with the developer, thereby inflicting a significant blow to their reputation. Therefore, the goal is to create a new, innovative model that empowers users with the ability to excite rather than aggressively sell features that should have been included in the first place. As noted above in the context of game engines, there is great flexibility in what can be achieved thanks to the smart contract EVM-powered ledger provided as part of the various game examples herein.

[0088] Referring now to the drawings, FIG. 5 further discloses an example engine architecture 500. As further shown in this figure, engine architecture 500 can include an engine runtime component 514, a game state machine 518, a game state database 520, and a web server 522, and the engine runtime component can further include a chain funnel 516. The engine runtime component 514 can be implemented off-chain, as further described above, which can benefit from game logic also being processed off-chain. The chain funnel 516 can funnel information related to the game state into the game state machine 518, which, for example, can further record the game state information and / or other information related to game logic or dynamics in the off-chain state machine. The corresponding state machine can effectively process changes to game state and / or game logic on-chain, rather than attempting to record such changes on-chain, which would result in all of the cumbersome inefficiencies associated with the relevant blockchain gaming technologies outlined above. In addition to the state machine itself, the engine runtime component 514 can further include a game state database 520, which can store additional and / or related, potentially more detailed, information about the game state and / or game logic off-chain. Because the game state database 520 can be implemented off-chain, developers can benefit from using more powerful and robust database technologies and platforms, as further described above.Finally, as further shown in FIG. 5 , the engine runtime component 514 can further include a web server 522, which can further provide an interface between end users (e.g., corresponding to the front-end game 508) on the one hand and other components, such as the middleware 510 and / or the web server 522, via the web. The middleware 510 can generally provide an interface between the front-end game 508 and one or more on-chain or on-chain-related components, including the NFT indexer 502, the user wallet 504, and the smart contract 506. Similarly, the match / round executor 512 can function as a coordinator or executor for different matches, rounds, and / or instances of gameplay. The match / round executor 512 may also start rounds or game instances and / or record the results of such rounds or game instances in terms of wins or losses, changes in token ownership, and / or any other items of game state information or other metadata as would be understood by one skilled in the art.

[0089] As initially introduced above, middleware 510 can interface with NFT indexer 502, user wallet 504, and / or smart contracts by referencing information or metadata in NFT indexer 502 (e.g., information identifying where on the actual blockchain NFT identification / ownership information is recorded), information or metadata in user wallet 504 (e.g., cryptographic information used to record transactions on the blockchain itself and / or used to identify corresponding blocks on the blockchain that pertain to a particular user account), and / or information or metadata in smart contracts (e.g., information that identifies, locates, and / or describes one or more smart contracts, where smart contracts act as coordinators and do not necessarily themselves implement changes to game state and / or game logic; such changes may instead be recorded using game state machine 518). Thus, the middleware 510 provides an interface between the blockchain itself on the one hand and the user experience realized by the front-end game 508 and one or more off-chain subcomponents in the engine runtime component 514. With respect to the smart contract 506, it acts as a coordinator, allowing information about the game state to flow into the engine runtime 514, which can then do the actual recording and tracking of game state changes based on information received from the corresponding smart contract through the chain funnel 516.

[0090] The above description of Figures 1 through 5 broadly describes various optional features and / or benefits of different disclosed embodiments of the technology of the present application. In addition, Figures 6 through 11 provide additional and optional mechanical or implementation details in some examples, which relate to how one or more of these features or benefits may be programmatically generated or obtained, as further described below. The mechanical implementation details of Figures 6 through 11 are for the purposes of enablement, explanation, and illustration and do not necessarily further limit the scope of the claims, as understood by those skilled in the art, as further outlined above (e.g., the exact letter and format of the computer code need not necessarily be followed exactly, but instead represent high-level concepts that provide an enabling description of exemplary embodiments of various technical improvements of the present application).

[0091] Starting with FIG. 6, this diagram illustrates a schematic 600 that includes an engine runtime component 602, equivalent to an engine runtime component, a game state database 608, and a web server 610. In various examples, the engine runtime component 602 may have one or more of the following main jobs or tasks: retrieve the height of the last processed block and the corresponding database (e.g., game state database 608), poll the chain funnel 604 at a fixed rate to obtain new "ChainData" to keep track of block heights, provide the "ChainData" to the processing functions of the game state machine 606, and / or launch the web server 610.

[0092] Diagram 600 also includes computer code portion 612. Portion 612 begins with a first command that initializes engine runtime component 602. As further shown in the diagram, portion 612 subsequently includes commands that trigger the start of execution of engine runtime component 602. "initialize(ChainFunnel, gameStateMachine)" in portion 612 represents an initialization function that takes the ChainFunnel and game state machine as arguments. Additionally, diagram 600 also includes computer code portion 614. Portion 614 can correspond to an extension interface that allows customizing functionality (e.g., customizing functionality before using the ".run()" endpoint).

[0093] With the above in mind, upon invoking a function (e.g., ".run()") on the Engine Runtime Component 602, the following tasks may be performed (e.g., before the Engine Runtime Component 602 begins actively running): verifying that the blockchain node provided in the ChainFunnel is active / accessible; verifying that the database connection information provided in the Game State Machine 606 is valid and that the database exists and / or can be connected to; and / or launching the web server 610 at one or more of the applicable GET or POST endpoints provided, as would be understood by one of ordinary skill in the art. If one or more of the above fails (e.g., if any of the above fails), the Engine Runtime Component 602 may safely exit. For example, the Engine Runtime Component 602 may close the web server 610 if it is started, as well as safely close anything else that is actively running on a different thread. In these cases, the Engine Runtime Component 602 may return an error message.

[0094] FIG. 7 illustrates a diagram 700 that includes computer code portion 702, computer code portion 704, and computer code portion 706, which may be related to and / or implement chain funnel 604. These computer code portions corresponding to chain funnel 604 form at least part of a core library that allows consumers to initialize a chain funnel object, which in turn stores state information about brickchain nodes (e.g., the node's uniform resource locator (URL)), deployed smart code addresses (e.g., storage addresses), and / or a collection of "ChainDataExtension" provided by a corresponding deployer in response. Computer code portion 702 indicates whether one or more of its internal fields should be part of the core library. In portion 702, "nodeUrl ; string" represents the node's URL:string, "storageAddress : string" represents the storage address:string, and "extensions : ChainDataExtension[ ]" represents extensions:chaindata extensions. Thus, computer code portion 704 further indicates that to initialize ChainFunnel 604, the deployer should invoke a function or command specified as an illustrative example in computer code portion 704. In portion 704, "const" represents a constant, "nodeUrl", "storageAddress", "extensions", and "chainFunnel = Funnel" represent the node's URL, storage address, extensions, and ChainFunnel = Funnel, respectively, and "initialize (nodeUrl, storageAddress, extensions)" represents a function that initializes the node's URL, storage address, and extensions.The "const latestChainData = chainFunnel.readData (latestProcessedBlockHeight + 1)" in portion 706 means that the constant "latestChainData" = "chainFunnel.readData (latestProcessedBlockHeight + 1)" (ChainFunnel read data (height of the most recently processed block + 1)). Similarly, ChainFunnel 604 may include a primary method that can be used to obtain "ChainData" (e.g., it may be similar to the readData function from the "storage.ts" component, but is simplified in Figure 7). With the above in mind, the "ChainData" received from ChainFunnel 604 can be fed to the game state machine, thereby allowing the game state to progress. In these examples, the "readData()" method is polled every X seconds or other time unit, thereby providing a simple interface that also interacts well with the Engine Runtime component 602.

[0095] FIG. 8 illustrates a diagram 800 that includes a computer code portion 802, a computer code portion 804, and a computer code portion 806, which may relate to or implement a game state machine 518. The state machines described herein (e.g., state machine 518) may be written in TypeScript (as shown in FIG. 8) and may enable the construction of state machines for games that can integrate naturally with the rest of the engine architecture 500. These game state machines may effectively provide a "game loop," which may hold some, all, or nearly all of the game logic. Unlike related video game loop techniques, which may occur at consistent times (e.g., 30+ times per second), the state machine corresponding to FIG. 8 may only execute state transitions as new blocks are generated on a blockchain on which a corresponding smart contract has been deployed. In some examples, the game state machine 518 may be naturally integrated with a postgres database (e.g., game state database 520) as the default storage backend for global game state.

[0096] With respect to data on the blockchain, a game implemented in the engine architecture 500 can only perform computations by progressing through state transitions. As mentioned above, state transitions can only occur when a new blockchain is created on a block. Therefore, these transitions can be funneled by the engine runtime component 514 through the chain funnel 516 to the game state machine 518. This new chain data can be preprocessed by the game state machine 518 and fed into the corresponding game state transition function. If a transaction blockchain block contains a transaction in which a user submits data to a smart contract, and this data may include game input, this particular data can be processed one by one by the state transition function.

[0097] The computer code portion 802 may indicate that, in some examples, the chain data may be formatted in a particular format. This particular format may optionally include, for example, a corresponding timestamp, a corresponding block hash value, a corresponding block number, and a data structure describing the submitted data, which may further include a user address corresponding to the submitted data, and the underlying actual data itself. In the portion 802, "timestamp," "blockHash," "blockNumber," "submittedData," "userAddress," and "data" represent the timestamp, block hash, block number, submitted data, user address, and data, respectively. "function gameStateTransition (InputData: InputData, blockNumber: number, randomSeed: number, db: Database)" in part 804 represents a game state transition function that takes input data, block number, random seed (number used to generate random numbers), and database as arguments, and "SQLUpdate" and "sqlUpdate" represent SQL (Structured Query Language) updates. "gameSM = SM" in part 804 means game state machine, and "initialize (databaseinfo, randomnessProtocolEnum, gameStateTransition)" represents a function that initializes database information, randomness protocol ENUM (association between internet phone numbers and addresses), and game state transition. "latestReadBlockHeight" and "latestBlockHeight" represent the height of the most recently read block and the height of the latest block, respectively."latestChainData = chainFunnel" means the latest chain data = chain funnel, and "readData (latestReadBlockHeight)" is a data reading function that takes "latestReadBlockHeight" as an argument. "gameSM.process (latestChainData)" represents a function processed by the game state machine that takes "latestChainData" as an argument.

[0098] Regarding the state transition function for implementing state transitions in the game state machine 518, this state transition function can be a function in which some, all, or nearly all of the game logic occurs. Developers using the game state machine 518 can implement their own specific state transition functions for the various mechanics and dynamics of their particular game. In some examples, the customized state transition function can receive one or more of the following as inputs (e.g., in some cases, it may be necessary to receive all of the following as inputs): input data, block number, random seed (e.g., a random seed generated by the game state machine 518 for use in random number generation, which may optionally be included in the game state database 520), and / or database object (e.g., an object that can be used to access the game state database 520 via a read-only interface). The output of this function can be a list of database update commands, which can further include all updates that will be applied to the global game state based on all of the results of the state transitions since the previous state. The computer code portion 804 (eg, here pseudocode) may further specify an illustrative instance of a state transition function including associated type information.

[0099] With regard to triggering state transitions, before triggering such transitions, the developer is required or required to first initialize a game state machine object corresponding to the game state machine 518. This object can connect to the game state database 520 and / or obtain the corresponding database schema. This object can also configure which random number generation protocol to use. The engine runtime component 514 can then obtain the next instant of chain data (e.g., from the on-chain contract 506 via the chain funnel 516) and then process all of the state transitions for the latest block of chain data, as shown in computer code portion 806.

[0100] The following description provides an overview of the internal dynamics of processing chain data. Accordingly, the following description refers to specific implementation details and computer code component names rather than the high-level block diagram of FIG. 5, but should nevertheless be read in a manner consistent with the high-level description of engine architecture 500.

[0101] When ".process(latestChainData)" (a function that processes the latest chain data) is called, the state machine can automatically initiate the execution of one or more state transitions via the "gameStateTransition()" function. First, the state machine checks the "scheduledData" table in its attached database. This table stores a list of entries with a block height (number) as its primary key and some "inputData" as its value. In other words, these are scheduled actions, generated by the previous state transition, that are executed at a given block height. By first executing these on-chain whenever a new block is generated (even if no data has been submitted to the smart contract), the engine architecture 500 provides passive time for the game, and these games are realized in this passive time.

[0102] In another example, whenever ".process(latestChainData)" is called on the game state machine, the state machine automatically queries for all scheduled data at the current level and begins triggering "gameStateTransition()" functions one by one. After each call, the STF (State Transition Function) returns SQL (Structured Query Language) update queries, which can be automatically applied to the database before the state machine calls the "gameStateTransition()" function again with the next input data. Thus, each successive state transition has access to the latest global game state, since all updates are applied to the database before proceeding (e.g., each time an element of scheduled data is processed, it is deleted from the "scheduledData" table).

[0103] Once all of the scheduled data has been processed, the state machine also feeds all of the "submittedData", starting with "latestChainData", one by one, to the "gameStateTransition()" function. Similarly, the state machine submits all SQL update queries to the database after each STF invocation. Note that any single given input data provided in "submittedData" may have been invalid. This means that "gameStateTransition()" may have failed for a given element of the submitted data, in which case no update is submitted to the database and the submitted data is simply discarded.

[0104] After using all of the "submittedData" piece by piece, this marks the end of the processing of "ChainData". All scheduled data and all user-supplied inputs have been processed at a given block height, and thus the system has reached an up-to-date state.

[0105] FIG. 9 illustrates a diagram 900 that includes portions 902, 904, 906, and 908, all of which may correspond to assertions and preprocessors used in engine architecture 500. Valid, succinctly encoded game inputs when using engine architecture 500 may rely on a simple standard, such as utf-8 (UCS (Unified Computer System) Transformation Format-8) encoded strings, with values ​​separated by a character such as "|". For example, in one representative game (named "catapult"), moves in a match may be submitted using the illustrative example schema shown in portion 902, with the information in portion 902 being encoded in utf-8 (as an illustrative example), resulting in the encoded information shown in portion 904. "Lobby ID", "roundNumber", "move1", "move2", and "move3" in part 902 represent the lobby ID, round number, move 1, move 2, and move 3, respectively.

[0106] With this in mind, the reader can think of the values ​​inside the two "|" as being values ​​that are relevant to the game state. In other words, they are values ​​that the game state machine can validate itself to determine whether they are valid and can be applied to the game state, or alternatively, whether they are invalid and should be discarded.

[0107] The above explanation inevitably raises the question, and that question is what happens if a user wants to submit state from the underlying blockchain to a game. The most obvious example is that a user might want to use an NFT they own inside a game. This claim of ownership is something that the game state machine, by itself, cannot verify, because it does not have access to the global blockchain state.

[0108] One approach is to use a "ChainDataExtension", but this approach may only be useful for a specific contract. In the case of NFTs, each NFT collection has its own contract, and forcing games to keep track of more and more contracts ad-hoc would further bloat each of these games' game state databases (and unnecessarily repeat the same state across game databases), and therefore is not a good path forward.

[0109] With the above in mind, this application discloses, in some examples, a new assertion model that caters to these specific use cases. These embodiments allow for the creation of a blockchain state assertion system that allows users to submit assertions along with their game inputs.

[0110] In these embodiments, assertions can be any valid game input string following the previous "|"-based standard, but with new assertion syntax added on top of it. Subsection 906 shows an illustrative example of what a lobby creator in a particular representative game (e.g., "catapult") might look like considering NFT ownership claims.

[0111] As can be seen, in these illustrative examples, the assertion is "X<input|input|input...> The syntax "(X<input|input|input...>)" can be used, where the prefix X is one or more lowercase letters and specifies an assertion (and therefore the number of expected inputs). An assertion makes a claim about the underlying blockchain state that must be true for the game input to be considered valid. Thus, if a single assertion in a game input string fails to prove valid at the current blockchain level, the game input can be discarded even before it is fed to the game state machine.

[0112] In addition to the above, the following observations and possible recommendations regarding assertions may be useful in connection with various examples. For example, assertions should be included immediately after the game input string. In another example, a game input can be invalid even if all assertions in the game input are valid. In an additional example, each game can be required to specify the maximum number of assertions it supports in a single game input. In another example, invalid assertions that have either too many inputs, invalid inputs, or unsupported prefixes are discarded.

[0113] Regarding preprocessors, in some instances, all submitted game inputs, if they have assertions within them, are passed through one or more preprocessors. The preprocessors (attached to the blockchain state indexer) then return either true or false, determining whether the assertions within the game input are valid. In these instances, if any of the preprocessors return false, the assertions are invalid, and therefore the entire game input is invalid and is discarded (and therefore is never fed to the game state machine).

[0114] In another example, when initializing chain funnel 516 for a particular game, the consumer may also be requested or required to specify the maximum number of assertions allowed to be part of the input data. This allows chain funnel 516 to filter out input data with too many assertions, preventing attacks where a bad actor may attempt to perform a denial of service attack with too many assertions.

[0115] As an illustrative example of such an assertion implemented in a preprocessor, the reader may consider the example of an NFT (ERC 721) ownership assertion. This assertion asserts that a user who submitted a game input has ownership of a given NFT at the block height at which the game input was submitted. In this representative example, the assertion has a prefix and two input values. The first input value is an ERC 721 contract address, and the second value is the ID (identification) of the NFT that the user claims to own. These details are shown in portion 908 of diagram 900. Of course, one skilled in the art will understand that this particular NFT protocol (ERC 721) and the particular configuration for this assertion are merely representative for illustrative purposes, and that different or other protocols and configurations may be used in other examples.

[0116] FIG. 10 illustrates a diagram 100, which includes a computer code portion 1002 and a computer code portion 1004, which may relate to chain data extensions. In some examples, it may be desirable to provide a game that does not rely on additional on-chain state, as described further below. In the relevant examples, the only on-chain state available for consumption by the game state machine is the set of data submitted by users to the deployed smart contract for this particular game. All other on-chain state is not necessarily passed to the state machine to keep the model efficient and prevent database bloat and added complexity. While this may be sufficient for these relevant examples, other examples refine this and extend the chain data provided to the game state machine with whatever on-chain state the game happens to require or involve. For example, a developer may want to pull a particular NFT contract (e.g., an ERC-721 contract) into the engine architecture 500, which allows a user to perform any element of functionality within the game if the state indicates that the user provably owns a particular NFT.In block 1002, "type ERC20Extension = { contractAddress: string}" means the type of ERC20 extension = { contract address represented as a string}, "type ERC721Extension = { contractAddress: string}" means the type of ERC721 extension = { contract address represented as a string}, "type ChainDataExtension = ERC20Extension | ERC721Extension" means the type of chain data extension = ERC20 extension | ERC721 extension, "type ERC20Update = { userAddress: string, amount: number}" means the type of ERC20 update = { user address represented as a string, amount represented as a number}, "type ERC721Update = { userAddress: string, amount: number}" means the type of ERC721 update = { user address represented as a string, amount represented as a number}, "type ERC20ExtensionDatum = { contractAddress: string, ERC20Update[]}” means type of ERC20 extension data = {contract address represented as a string, update being an ERC20 update}, “type ERC721ExtensionDatum = { contractAddress: string, upfates: ERC721Update[]}” means type of ERC721 extension data = {contract address represented as a string, update being an ERC721 update}, “type ChainDataExtensionDatum = ERC20ExtensionDatum | ERC721ExtensionDatum” means type of chaindata extension data = ERC20 extension data | ERC721 extension data.The part 1004 "export interface Chaindata { timestamp: number; blockhash: string; blocknumber: number; submittedData: SubmittedChainData[]; extensionDatums: ChainDataExtensionDatum[]" represents interface ChainData { timestamp: number; blockhash: string; blocknumber: number; submittedData: SubmittedChainData[]; extensionDatums: ChainDataExtensionDatum[]}.

[0117] The example improvements outlined above create a flow between the storage and state machines of engine architecture 500, which allows a game state machine developer to specify which chain data extensions to automatically access (e.g., in a hands-free manner) that particular data in the corresponding database. The following description further provides implementation details, at a high level of generality, of how these improvements are implemented.

[0118] More specifically, in some instances, these improvements can be realized in part through a "ChainDataExtension." In these instances, each "ChainDataExtension" has a corresponding "ChainDataExtension" type, which holds data about a given instantiation of the extension. In other words, the "ChainDataExtension" specifies what new data will be poured in from on-chain, and the "ChainDataExtensionDatum" is the actual new data from the chain in a given block. Portion 1002 shows illustrative examples of such on-chain data extensions, including a type representing an extension that would be read from an ERC20 (Ethereum Request for Comments (Token Standard #20)) contract, a type representing an extension that would be read from an ERC721 contract, a generic extension data type, a type representing an update to a user's balance in an ERC20 contract, and a type representing an update to who owns an NFT in an ERC721 contract, example data for "ERC20Extension," example data for "ERC721Extension," and a generic type for extension data. As further illustrated by portion 1002, the separation of extensions and extension data at a type level allows for easier integration of these features with engine architecture 500. With the above in mind, portion 1004 further illustrates that with these exceptions, "ChainData" now includes a new field, which holds all of the extension data.

[0119] For completeness, FIG. 11 also provides diagrams 1100 and 1101, which help illustrate the difference between classic static NFTs (corresponding to diagram 1100) and stateful NFTs (corresponding to diagram 1101 and FIG. 3). As further shown in this figure, a related blockchain game application and configuration can include a blockchain 1102, which includes a user wallet 1104, which includes an NFT (e.g., a static or classic NFT). In this case, a centralized game server 1108 simply interacts with the NFT 1106 in a one-way anchor relationship, whereby the NFT 1106 ownership state is provided to and confirmed by the centralized game server 1108.

[0120] In contrast, according to diagram 1101, blockchain 1102 can still include user wallet 1104 containing NFT 1106, yet engine 1110 (corresponding to engine architecture 500) can further include game state machine 1114 (corresponding to game state machine 518), which tracks and records dynamic changes in state information corresponding to the same NFT 1106. In contrast to the one-way anchors of diagram 1100, diagram 1101 features two-way data anchors, which enable the game state machine to indicate or record ownership in blockchain 1102 in one direction and record NFT game state from blockchain 1102 in the other direction into game state machine 1112, as further illustrated in this figure. Additionally, NFT 1114 can further track changes in state information, such as numbers, attributes, or other metadata instances related to in-game gold, items, statistics, etc., as would be understood by one of ordinary skill in the art.

[0121] 1-11, we now provide additional details regarding implementation details related to random number generation, which may be included in various examples of engine architecture 500, as described in more detail below. Random numbers are used in certain games, and having a good source of random numbers prevents users from exploiting statistical trends to their own advantage.

[0122] In some examples of engine architecture 500, the engine is configured to generate the game as a globally accessible state machine. In other words, these games are inherently deterministic (because everyone must respond to all submitted game inputs to arrive at the same global state). Furthermore, in these examples, there is no trusted central server that can be relied upon to generate random numbers (i.e., as a random number oracle). Taking these configuration details into consideration in these environments can increase the benefits of having a good random number source.

[0123] With the above in mind, various examples of engine architecture 500 can be configured such that whenever a new block is generated, there are two pieces of information provided to the engine architecture, and these two pieces of information have a degree of uncertainty or randomness that makes them more difficult to predict: the block hash, and a list of submitted data (user game inputs) posted by users to the on-chain smart contract. Thus, these pieces of data are pieces of data upon which further randomness can be built.

[0124] In the first example, the random number generation protocol can simply use the block hash. In this example, the block hash may be sufficient for simple games, yet may not be as advantageous for increasingly complex games. Thus, in the second example, all of the data submitted to the on-chain smart contract in the most recent block may be combined with the block hash. Because this data is user-generated or submitted, there may be a much larger number of actors submitting input, making this data much more random.

[0125] In an additional example, an automated piece of software can be configured to submit data to a smart contract, improving the randomness of the second example listed immediately above. Nevertheless, one sub-optimization of the second example, perhaps arising in certain scenarios, is that block producers still have the power to determine which transactions should be included in a block, and thus producers can collude to censor all transactions to the smart contract. In these scenarios, block producers can then work to find a block hash that is in their interest. (While this may seem unlikely for block producers in the context of a video game, it is nevertheless theoretically possible and can be addressed by technical improvements described further herein below.)

[0126] With this in mind, in the third example, the goal can be to improve random number generation so that it becomes much more difficult for block producers to collude. This can be achieved by utilizing a recurring random number source. In other words, rather than simply using the data from the most recent block, previously generated random numbers from the previous 10 blocks (as a threshold number) can be cached and then combined together.

[0127] In a fourth example, the last 25 blocks of random numbers (as another example threshold number) can be cached, and this resulting cache can then be used in conjunction with the protocol of the second example to generate a temporary random number, which is then further used to select which of the previous last 25 blocks of random numbers to choose and combine with the final temporary random number to generate the final random seed.

[0128] Returning to the first example, the submitted data from the previous 25 blocks can be cached, and by using the random number from the most recent block from the second example, starting with block X-25, it randomly selects which submitted data to use as part of generating a new random number source. Once a random set of "submittedData" is selected from block X-25, the protocol moves to block X-24 and uses the newly generated random number to select a subset of the submitted data from this block, and so on. In other words, the idea behind the above description is that the computations for generating random numbers can be very complex, making it nearly impossible for a block producer to manipulate the process for their own benefit within the timeframe in which they must generate a block (e.g., by trying to find or create a block with a particular set of data submitted by users and a particular block hash that is in their interest).

[0129] 12 is a block diagram of an example computer system 1210, which is capable of implementing one or more of the embodiments described and / or illustrated herein. For example, all or a portion of computer system 1210, alone or in combination with other elements, can perform and / or be a means for performing one or more of the steps described herein (such as one or more of the steps shown in FIG. 3). All or a portion of computer system 1210 can perform and / or be a means for performing any other step, method, or process described and / or illustrated herein.

[0130] Computer system 1210 broadly represents any single-processor or multi-processor computing device or system capable of executing computer-readable instructions. Examples of computer system 1210 include, without limitation, a workstation, a laptop, a client terminal, a server, a distributed computing system, a handheld device, or any other computing system or device. In its most basic configuration, computer system 1210 can include at least one processor 1214 and system memory 1216.

[0131] Processor 1214 generally represents any type or form of physical processing device (e.g., a central processing unit implemented in hardware) capable of processing data or interpreting and executing instructions. In particular embodiments, processor 1214 may receive instructions from a software application or module. These instructions may cause processor 1214 to perform one or more functions of the embodiments described and / or illustrated herein.

[0132] System memory 1216 generally represents any type or form of volatile or non-volatile storage device or medium capable of storing data and / or other computer-readable instructions. Examples of system memory 1216 include, without limitation, random access memory (RAM), read-only memory (ROM), flash memory, or any other suitable memory device. Although not required, in particular embodiments, computer system 1210 includes both a volatile memory unit (e.g., such as system memory 1216) and a non-volatile storage device (e.g., such as a primary storage device described in more detail below). In one example, one or more modules in FIG. 1 can be loaded into system memory 1216.

[0133] In some examples, system memory 1216 can store and / or load operating system 1240 for execution by processor 1214. In one example, operating system 1240 can include and / or represent software that manages computer hardware and software resources and / or provides common services to computer programs or applications on computer system 1210. Examples of operating systems 1240 include, without limitation, LINUX, JUNOS, MICROSOFT WINDOWS, WINDOWS MOBILE, MAC OS, Apple's IOS, UNIX, GOOGLE CHROME OS, GOOGLE ANDROID, SOLARIS, variations of one or more of these, and / or any other suitable operating system.

[0134] In particular embodiments, an example computer system 1210 includes one or more components or elements in addition to a processor 1214 and a system memory 1216. For example, as shown in FIG. 12, the computer system 1210 may include a memory controller 1218, an input / output (I / O) controller 1220, and a communication interface 1222, each of which may be interconnected via a communication infrastructure 1212. The communication interface 1212 generally represents any type or form of infrastructure capable of facilitating communication between one or more components of a computing device. Examples of the communication infrastructure 1212 include, without limitation, an Industry Standard Architecture (ISA), Peripheral Component Interconnect (PCI), PCI Express (PCIe), or similar buses and networks.

[0135] Memory controller 1218 generally represents any type or form of device capable of manipulating memory or data or controlling communications between one or more components of computer system 1210. For example, in particular embodiments, memory controller 1218 may control communications between processor 1214, system memory 1216, and I / O controller 1220 via communications infrastructure 1212.

[0136] I / O controller 1220 generally represents any type or form of module capable of coordinating and / or controlling the input and output functions of a computing device. For example, in particular embodiments, I / O controller 1220 may control or facilitate the transfer of data between one or more elements of computer system 1210, such as processor 1214, system memory 1216, communications interface 1222, display adapter 1226, input interface 1230, and storage interface 1234.

[0137] 12, computer system 1210 may also include at least one display device 1224 coupled to I / O controller 1220 via display adapter 1226. Display device 1224 generally represents any type or form of device capable of visually displaying information transferred by display adapter 1226. Similarly, display adapter 1226 generally represents any type or form of device configured to transfer graphics, text, and other data from communication interface 1212 (or from a frame buffer, as known in the art) for display on display device 1224.

[0138] 12, the example computer system 1210 may also include at least one input device 1228 coupled to the I / O controller 1220 via an input interface 1230. The input device 1228 generally represents any type or form of input device capable of providing either computer- or human-generated input to the example computer system 1210. The input device 1228 may include, without limitation, a keyboard, a pointing device, a voice recognition device, variations of one or more of these, and / or any other input device.

[0139] Additionally or alternatively, example computer system 1210 may include additional I / O devices. For example, example computer device 1210 may include I / O device(s) 1236. In this example, I / O device(s) 1236 may include and / or represent a user interface that facilitates human interaction with computer system 1210. Examples of I / O device(s) 1236 include, without limitation, a computer mouse, a keyboard, a monitor, a printer, a modem, a camera, a scanner, a microphone, a touchscreen device, variations or combinations of one or more of these, and / or any other I / O device.

[0140] Communication interface 1222 broadly represents any type or form of communication device or adapter capable of facilitating communications between the exemplary computer system 1210 and one or more additional devices. For example, in particular embodiments, communication interface 1222 may facilitate communications between computer system 1210 and a private or public network including additional computing devices. Examples of communication interface 1222 include, without limitation, a wired network interface (such as a network interface card), a wireless network interface (such as a wireless network interface card), a modem, and any other suitable interface. In at least one embodiment, communication interface 1222 may provide a direct connection to a remote server via a direct link to a network such as the Internet. Communication interface 1222 may also provide such a connection indirectly, for example, through a local area network (such as an Ethernet network), a personal area network, a telephone or cable network, a cellular telephone connection, a satellite data connection, or any other suitable connection.

[0141] In particular embodiments, communications interface 1222 may represent a host adapter configured to facilitate communication between computer system 1210 and one or more additional networks or storage devices over an external bus or communications channel. Examples of host adapters include, without limitation, Small Computer System Interface (SCSI) host adapters, Universal Serial Bus (USB) host adapters, Institute of Electrical and Electronics Engineers (IEEE) 1394 host adapters, Advanced Technology Attachment (ATA), Parallel ATA (PATA), Serial ATA (SATA), and External SATA (eSATA) host adapters, Fibre Channel interface adapters, Ethernet adapters, etc. For example, communications interface 1222 may receive instructions from a remote device for execution or send instructions to a remote device for execution.

[0142] In some examples, system memory 1216 can store and / or load a network communications program 1238 for execution by processor 1214. In one example, network communications program 1238 can include and / or represent software that enables computer system 1210 to establish network connections with other computer systems (not shown in FIG. 12 ) and / or communicate with other computer systems via communication interface 1222. In this example, network communications program 1238 can manage the flow of outgoing traffic sent to other computer systems over network connection 1242. Additionally or alternatively, network communications program 1238 can manage the processing of incoming traffic received from other computer systems over network connection 1242 connected to processor 1214.

[0143] 12, network communications program 1238 may instead be stored and / or loaded within communications interface 1222. For example, network communications program 1238 may include and / or represent at least a portion of software and / or firmware executed by a processor and / or application specific integrated circuit (ASIC) embedded within communications interface 1222.

[0144] 12 , exemplary computer system 1210 may also include primary storage 1232 and backup storage 1233 coupled to communications infrastructure 1212 via storage interface 1234. Storage devices 1232 and 1233 generally represent any type or form of storage device or medium capable of storing data and / or other computer-readable instructions. For example, storage devices 1232 and 1233 may be magnetic disk drives (e.g., so-called hard drives), solid-state drives, floppy disk drives, magnetic tape drives, optical disk drives, flash drives, etc. Storage interface 1234 generally represents any type or form of interface or device for transferring data between storage devices 1232 and 1233 and other components of computer system 1210.

[0145] In particular embodiments, storage devices 1232 and 1233 may be configured to read from and / or write to removable storage devices configured to store computer software, data, or other computer-readable information. Examples of suitable removable storage devices include, without limitation, floppy disks, magnetic tape, optical disks, flash memory devices, etc. Storage devices 1232 and 1233 may also include other similar structures or devices that allow computer software, data, or other computer-readable instructions to be loaded into computer system 1210. For example, storage devices 1232 and 1233 may be configured to read from and write to software, data, or other computer-readable information. Storage devices 1232 and 1233 may be part of computer system 1210 or may be separate devices accessed through other interface systems.

[0146] Numerous other devices or subsystems may be connected to computer system 1210. Conversely, not all of the components and devices shown in FIG. 12 need be present to practice the embodiments described and / or illustrated herein. The above-referenced devices and subsystems may also be interconnected in ways different from that shown in FIG. 12. Computer system 1210 may also employ any number of software, firmware, and / or hardware configurations. For example, one or more of the embodiments disclosed herein may be encoded on a computer-readable medium as a computer program (also referred to as computer software, computer-readable instructions, or control logic). As used herein, the term "computer-readable medium" generally refers to a device, carrier, or medium capable of storing or carrying computer-readable instructions. Examples of computer-readable media include, without limitation, transmission-type media such as carrier waves, and non-transitory media such as magnetic storage media (e.g., hard disk drives, tape drives, and floppy disks), optical storage media (e.g., compact disks (CDs), digital video disks (DVDs), and Blu-ray disks), electrical storage media (e.g., solid-state drives and flash memory), and other distributed systems.

[0147] A computer-readable medium containing a computer program can be loaded into computer system 1210. Accordingly, the computer program stored on the computer-readable medium can be stored, in whole or in part, in various portions of system memory 1216 and / or storage devices 1232 and 1233. When executed by processor 1214, the computer program loaded into computer system 1210 can cause processor 1214 to perform and / or be a means for performing one or more of the functions of the embodiments described and / or illustrated herein. Additionally or alternatively, one or more of the embodiments described and / or illustrated herein can be implemented in firmware and / or hardware. For example, computer system 1210 can be configured as an application-specific integrated circuit (ASIC) configured to implement one or more of the embodiments disclosed herein.

[0148] 13 is a block diagram of an example network architecture 1300 in which client systems 1310, 1320, and 1330 and servers 1340 and 1345 may be coupled to a network 1350. As noted above, all or a portion of network architecture 1300, alone or in combination with other elements, may perform and / or be a means for performing one or more of the steps disclosed herein (such as one or more of the steps shown in FIG. 3). All or a portion of network architecture 1300 may also be used to perform and / or be a means for performing other steps and features described in this disclosure.

[0149] Client systems 1310, 1320, and 1330 generally represent any type or form of computer device or system, such as example computer system 1210 of FIG. 12. Similarly, servers 1340 and 1345 generally represent computer devices or systems, such as application servers or database servers, configured to provide various database services and / or run specific software. Network 1350 generally represents any telecommunications or computer network, including, for example, an intranet, a WAN, a LAN, a PAN, or the Internet. In one example, client systems 1310, 1320, and / or 1330 and / or servers 1340 and 1345 may comprise all or a portion of system 100 of FIG. 1.

[0150] As shown in FIG. 13 , one or more storage devices 1360(1)-(N) can be directly attached to server 1340. Similarly, one or more storage devices 1370(1)-(N) can be directly attached to server 1345. Storage devices 1360(1)-(N) and storage devices 1370(1)-(N) generally represent any type or form of storage device or medium capable of storing data and / or other computer-readable instructions. In particular embodiments, storage devices 1360(1)-(N) and storage devices 1370(1)-(N) can represent network-attached storage (NAS) devices configured to communicate with servers 1340 and 1345 using various protocols, such as Network File System (NFS), Server Message Block (SMB), or Common Internet File System (CIFS).

[0151] Servers 1340 and 1345 may also be connected to a storage area network (SAN) structure 1380. SAN structure 1380 generally represents any type or form of computer network or architecture capable of facilitating communication between multiple storage devices. SAN structure 1380 may facilitate communication between servers 1340 and 1345 and multiple storage devices 1390(1)-(N) and / or intelligent storage array 1395. SAN structure 1380 may also facilitate communication between client systems 1310, 1320, and 1330 and storage devices 1390(1)-(N) and / or intelligent storage array 1395 via network 1350 and servers 1340 and 1345 in a manner such that storage devices 1390(1)-(N) and intelligent storage array 1395 appear as locally attached devices to client systems 1310, 1320, and 1330. Like storage devices 1360(1)-(N) and storage devices 1370(1)-(N), storage devices 1390(1)-(N) and intelligent storage array 1395 generally represent any type or form of storage device or medium capable of storing data and / or other computer-readable instructions.

[0152] In particular embodiments, and with reference to exemplary computer system 1210 of FIG. 12 , a communications interface, such as communications interface 1222 of FIG. 12 , may be used to provide connectivity between each of client systems 1310, 1320, and 1330 and network 1350. Client systems 1310, 1320, and 1330 may access information on server 1340 or 1345 using, for example, a web browser or other client software. Such software may enable client systems 1310, 1320, and 1330 to access data residing on server 1340, server 1345, storage devices 1360(1)-(N), storage devices 1370(1)-(N), or intelligent storage array 1395. While FIG. 13 illustrates the use of a network (such as the Internet) to exchange data, the embodiments described and / or illustrated herein are not limited to the Internet or any particular network-based environment.

[0153] In at least one example, one or more of the embodiments disclosed herein may be encoded, in whole or in part, as a computer program and loaded onto and executed by server 1340, server 1345, storage devices 1360(1)-(N), storage devices 1370(1)-(N), storage devices 1390(1)-(N), intelligent storage array 1395, or any combination thereof. One or more of the embodiments disclosed herein may also be encoded, in whole or in part, as a computer program that is stored on server 1340, executed by server 1345, and distributed over a network to client systems 1310, 1320, and 1330.

[0154] As detailed above, computer system 1210 and one or more components of network architecture 1300, alone or in combination with other elements, may perform and / or be a means for performing one or more steps of an example method for facilitating blockchain applications.

[0155] Although the foregoing disclosure describes various embodiments using specific block diagrams, flowcharts, and examples, each block diagram element, flowchart step, operation, and / or component described and / or illustrated herein can be implemented, individually and / or collectively, using a wide variety of hardware, software, or firmware (or any combination thereof) configurations. In addition, any disclosure of components within other components should be considered exemplary in nature, as numerous other architectures can be implemented to achieve the same functionality.

[0156] In some examples, all or portions of the exemplary system 100 of FIG. 1 may represent portions of a cloud computing environment or network-based environment. A cloud computing environment may provide various services and applications over the Internet. These cloud-based services (e.g., software as a service, platform as a service, infrastructure as a service, etc.) may be accessible through a web browser or other remote interface. Various functionality described herein may be provided through a remote desktop environment or any other cloud-based computing environment.

[0157] In various embodiments, all or a portion of the exemplary system 100 of FIG. 1 can facilitate multi-tenancy (multiple clients sharing the same computing resources) within a cloud-based computing environment. In other words, the software modules described herein can configure a computer system (e.g., a server) to facilitate multi-tenancy for one or more of the functions described herein. For example, one or more of the software modules described herein can program a server to allow two or more clients (e.g., customers) to share applications running on the server. A server so programmed can allow applications, operating systems, processing systems, and / or storage systems to be shared among multiple customers (i.e., tenants). One or more of the modules described herein can also partition data and / or configuration information for a multi-tenant application by customer, preventing one customer from accessing data and / or configuration information for another customer.

[0158] According to various embodiments, all or a portion of the exemplary system 100 of FIG. 1 may be implemented within a virtual environment. For example, the modules and / or data described herein may reside and / or execute within a virtual machine. As used herein, the term "virtual machine" generally refers to any operating system environment abstracted from computer hardware by a virtual machine manager (e.g., a hypervisor). Additionally or alternatively, the modules and / or data described herein may reside and / or execute within a visualization layer. As used herein, the term "visualization layer" generally refers to any data layer and / or application layer that overlays and / or is abstracted from an operating system environment. The visualization layer may be managed by a software visualization solution (e.g., a file system filter) that presents the visualization layer as if it were part of the underlying base operating system. For example, a software visualization solution may redirect calls that were originally directed to locations in the base file system and / or registry to locations in the visualization layer.

[0159] 1 may represent portions of a mobile computing environment. Mobile computing environments can be implemented by a wide range of mobile computing devices, including mobile phones, tablet computers, e-readers, personal digital assistants, wearable computing devices (e.g., computing devices with head-mounted displays, smart watches, etc.). In some examples, mobile computing environments can have one or more distinguishing characteristics, including, for example, a dependency on battery power, presenting only one foreground application at any given time, remote management features, touchscreen features, data placement and movement (e.g., data provided by the Global Positioning System, gyroscope, accelerometer, etc.), a restricted platform that limits changes to system-level settings and / or the ability of third-party software to affect the behavior of other applications, controls to restrict application installation (e.g., only from authorized application stores), etc. Various features described herein may be provided for and / or interact with a mobile computing environment.

[0160] Additionally, all or portions of the example system 100 of Figure 1 may represent portions of one or more systems for information management, interact with such systems, consume data generated by such systems, and / or generate data consumed by such systems. As used herein, "information management" may refer to the protection, organization, and / or storage of data. Examples of systems for information management may include, without limitation, storage systems, backup systems, archive systems, replication systems, high availability systems, data retrieval systems, visualization systems, etc.

[0161] 1 may represent portions of, generate data generated by, and / or communicate with one or more systems for information security. As used herein, "information security" may refer to controlling access to protected data. Examples of systems for information security may include, without limitation, systems providing managed security services, data loss prevention systems, identity and authentication systems, access control systems, encryption systems, policy compliance systems, intrusion detection and prevention systems, e-discovery systems, etc.

[0162] According to some examples, all or a portion of the example system 100 of FIG. 1 may represent parts of, communicate with, and / or receive protection from one or more systems for endpoint security. As used herein, "endpoint security" may refer to the protection of endpoint systems from unauthorized and / or unlawful use, access, and / or control. Examples of systems for endpoint protection may include, without limitation, anti-malware systems, user authentication systems, encryption systems, privacy systems, spam filtering systems, etc.

[0163] The process parameters and order of steps described and / or illustrated herein are provided by way of example only and can be varied as desired. For example, although the steps illustrated and / or described herein may be shown or described in a particular order, these steps do not necessarily have to be performed in the order illustrated or described. The various example methods described and / or illustrated herein can omit one or more of the steps described and / or illustrated herein or can include additional steps in addition to those disclosed.

[0164] Although various embodiments have been described and / or illustrated herein in the context of a fully functional computer system, one or more of these embodiments may be distributed in various forms as a program product, regardless of the particular type of computer-readable medium used to actually carry out the distribution. The embodiments disclosed herein may also be implemented using software modules that perform specific tasks. These software modules may include script files, batch files, or other executable files, which may be stored on a computer-readable storage medium or within a computer system. In some embodiments, a computer system may be configured such that these software modules execute one or more of the embodiments disclosed herein.

[0165] Additionally, one or more of the modules described herein may transform data, physical devices, and / or representations of physical devices from one form to another. Additionally or alternatively, one or more of the modules listed herein may transform a processor, volatile memory, non-volatile memory, and / or any other portion of a physical computer device by executing on the computer device, storing data on the computer device, and / or otherwise interacting with the computer device.

[0166] The preceding description has been provided to enable others skilled in the art to best utilize various aspects of the embodiments disclosed herein. The description of examples is not intended to be exhaustive or to be limited to any precise form disclosed. Numerous modifications and variations are possible without departing from the spirit and scope of the present invention. The embodiments disclosed herein are to be considered in all respects as illustrative and not restrictive. Reference should be made to the appended claims and their equivalents in determining the scope of the present invention.

[0167] Unless otherwise specified, the terms "connected to" and "coupled to" (and their derivatives) used in the specification and claims should be interpreted to allow for both direct and indirect (i.e., via other elements or components) connections. In addition, the term "element" used in the specification and claims should be interpreted to mean "at least one" element. Finally, for ease of use, the terms "include" and "have" (and their derivatives) used in the specification and claims are interchangeable with "comprise" and have the same meaning.

Claims

1. 1. A method for facilitating a blockchain application, at least a portion of which is performed by a computing device having at least one processor, comprising: enabling at least one application implemented on the blockchain to access the scalability engine; facilitating execution of the application using the scalability engine; A computer-implemented method in which the scalability engine uses smart contracts on-chain, where the smart contracts act as coordinators with an off-chain state machine that computes the state of the application.

2. 10. The computer-implemented method of claim 1, wherein the application comprises a blockchain gaming application.

3. 3. The computer-implemented method of claim 2, wherein the off-chain state machine calculates the state of the blockchain gaming application.

4. 3. The computer-implemented method of claim 2, wherein the scalability engine enables users accessing the blockchain to read on-chain data confirming the latest state of the blockchain gaming application in a zero-trust configuration.

5. 3. The computer-implemented method of claim 2, wherein the blockchain stores substantially all data for operation of the blockchain gaming application.

6. 3. The computer-implemented method of claim 2, wherein the blockchain gaming application implements passive time such that the blockchain gaming application progresses while bypassing requirements for users to submit new transactions to the blockchain.

7. The computer-implemented method of claim 1 , wherein the state machine operates as an L2 chain.

8. 10. The computer-implemented method of claim 1, wherein the scalability engine calculates the gas fee based on a calculation on the user address, the game input, and a digital signature of the game input.

9. 2. The computer-implemented method of claim 1, wherein the scalability engine makes gas and transaction fees strictly dependent on the number of bytes a user submits to the application for their input.

10. 10. The computer-implemented method of claim 1, wherein the scalability engine enables true blockchain player-versus-environment gaming.

11. A non-transitory computer-readable storage medium storing instructions that, when executed by a physical processor of a computing device, cause the computing device to perform a method, the method comprising: enabling at least one application implemented on the blockchain to access the scalability engine; facilitating execution of the application using the scalability engine; The scalability engine uses smart contracts on-chain, where the smart contracts act as coordinators with an off-chain state machine that computes the state of the application.

12. 12. The non-transitory computer-readable medium of claim 11, wherein the application comprises a blockchain gaming application.

13. 13. The non-transitory computer-readable medium of claim 12, wherein the off-chain state machine calculates the state of the blockchain gaming application.

14. 13. The non-transitory computer-readable medium of claim 12, wherein the scalability engine enables a user accessing the blockchain to read on-chain data confirming the latest state of the blockchain gaming application in a zero-trust configuration.

15. 13. The non-transitory computer-readable medium of claim 12, wherein the blockchain stores substantially all data for operation of the blockchain gaming application.

16. 13. The non-transitory computer-readable medium of claim 12, wherein the blockchain gaming application implements passive time such that the blockchain gaming application progresses while bypassing requirements for users to submit new transactions to the blockchain.

17. The non-transitory computer-readable medium of claim 11 , wherein the state machine operates as an L2 chain.

18. 12. The non-transitory computer-readable medium of claim 11, wherein the scalability engine calculates the gas fee based on a calculation on a user address, a game input, and a digital signature of the game input.

19. 12. The non-transitory computer-readable medium of claim 11, wherein the scalability engine makes gas and transaction fees strictly dependent on the number of bytes a user submits to the application for their input.

20. an access providing module that enables at least one application implemented on the blockchain to access the scalability engine; a facilitation module stored in memory that facilitates execution of the application using the scalability engine; at least one physical processor configured to execute the access providing module and the facilitating module, The system wherein the scalability engine uses smart contracts on-chain, which act as coordinators for an off-chain state machine that computes the state of the application.

Images