Launching Your Own Game on Saga
Part 5: Storing data on your own chain
This blog post is the final of a series designed to walk you through the steps of launching your own chain that can host its own game, whether the game is fully on-chain, meant to store gamestate in real time or only has in-game assets. In crypto today, most games choose to launch on monolithic chains that they do not control, where developers are limited by the design choices that are specific to that chain. But on Saga, where developers can launch their own chain, there is a far greater degree of flexibility, customizability and throughput that a developer can have access to. In this series, we’ll show you some of the basics of deploying your own chain on Saga while also demonstrating the unique things that one can do with Saga that isn’t possible in other ecosystems. Specifically, we’ll show you how you can:
- Blog Post #1: Launch your own EVM chain in minutes and connect it to its own block explorer, web-sockets and RPC endpoints.
- Blog Post #2: Connect and deploy pre-audited smart contracts directly onto your own chain such as an ERC-20 token contract.
- Blog Post #3: Deploy pre-compiled NFT minting contracts onto your own chain.
- Blog Post #4: Deploy an NFT exchange for NFTs on your chain.
- Blog Post #5: Demonstrate the power of your own dedicated EVM chain, such as storing data directly to your own chain.
In this post, we’ll discuss how to easily store data on your own chain via smart contracts. These smart contracts can be used to store any kind of data, such as game-state, game events or any other kind of data that may be relevant for your game. By having this data on-chain it can be accessible to end-users of your applications and be utilized in novel manners.
Let’s dive in.
Step 1: Why/How for different types of storage on the EVM.
In the EVM, there are four distinct types of data storage: storage, memory, call data, and stack.
Storage is a persistent storage area where all the contract state variables reside. Any changes to storage are very costly in terms of gas, but the data is stored between function calls and transactions, effectively becoming part of the blockchain record. This type of storage will be the subject of this blog post and would be useful to a game developer who would like to store game assets, player attributes, ownership details, or other essential information that must persist across different game sessions and transactions. Because this data is on a blockchain, it ensures authenticity and can create a transparent history of in-game assets.
Memory is a temporary place where data is stored. It is erased between (external) function calls and is more gas-efficient than storage. Memory is a linear and expandable area where the contract can keep temporary variables during the execution of a function. A game developer might use memory to temporarily hold data related to the current game session, such as intermediate calculations, player moves, or other transient information that does not need to be stored permanently but is essential for the processing of a specific transaction or function call.
Call Data: This is an immutable, non-changeable area where the data from a transaction or call is stored. It includes the function signature and the parameters with which the function was called. This data is only accessible for the duration of the function execution and cannot be altered by the contract. A game developer might utilize call data to ensure the integrity of the incoming instructions for a game action, as this data cannot be altered during execution. It may also be useful for processing player commands in a secure manner.
Stack: The EVM uses a stack to hold small-sized data values, like operands and partial results of computations. The stack has a fixed depth of 1024 slots and only supports simple operations. It’s used for computations and temporary storage during the execution of the contract, with the data being popped off the stack as it is processed. A game developer could utilize the stack for rapid computations like scoring, processing logic, or other in-game calculations that require immediate processing and don’t need to be saved after the function execution. It helps in optimizing the game’s performance and gas costs by handling quick, transient operations efficiently.
For a more in-depth understanding of how the EVM works, please refer to this excellent article.
Step 2: Go to Remix IDE and connect your Chainlet to it.
Remix IDE is a popular open-source web and desktop application that helps in smart contract development for EVM chains. It provides a range of tools that facilitate writing, testing, debugging, and deploying smart contracts written in Solidity, the primary language for Ethereum contracts. The IDE includes features such as static analysis, a built-in compiler, a debugger, and a test environment, all designed to streamline the development process. By offering both in-browser and downloadable versions, Remix IDE has become an essential tool for both newcomers and experienced developers in the Ethereum community. We can access the Remix IDE by going to (https://remix.ethereum.org/)
Once you go to Remix, navigate to ‘Deploy & run transactions’ on the left panel bar and from the drop-down menu at the top click on ‘Injected Provider — MetaMask’. This will connect the Remix IDE to your Chainlet.
Step 3: Create a new workspace for a data-storage smart contract.
Navigate up to ‘File Explorer’ and click on the three bars next to Workspaces to create a new workspace. Under template, we will choose ‘Basic’ and then name your workspace accordingly.
On the left hand side of the page, you should be able to see a collection of files that have already been created. Click on 1_Storage.sol and you should be able to see a basic storage contract written in solidity.
The storage contract here provides a simple Solidity contract designed to store and retrieve an unsigned 256-bit integer within the Ethereum blockchain. The contract consists of a single state variable ‘number’, and two public functions. The store function takes an unsigned integer as an input and assigns it to the number variable, effectively storing the value. The retrieve function, on the other hand, is a view function that returns the current value of the number variable without modifying the state. This contract represents a basic example of how data can be stored and accessed on the Ethereum blockchain, without involving any complex functionality.
Step 4: Deploy storage contract to your Chainlet.
We are now ready to deploy this contract to our Chainlet. Click on ‘Solidity Compiler’ on the left hand side and compile the storage contract.
Once the storage contract is compiled we should be ready to deploy to our Chainlet. Go back to ‘Deploy & run transactions’ and click ‘Deploy’. Once you ‘Deploy’ you will be asked to sign a transaction on Metamask. Once the contract is deployed, we can confirm its creation from the Chainlet block explorer.
From the block explorer, we can track down the address of the contract. For this author, that address is 0x1c43635e3cb5A3917848D202b9DE65e98aD1e605 (font). We are now ready to interact with the storage contract.
Step 5: Interact with the storage contract on your Chainlet.
Now that the storage contract is deployed, we are ready to store data within it. Go back to the ‘Deploy and run transaction’ tab within Remix and click on the contract under ‘Deployed’. You should be able to see the two functions of the contract — ‘store’ and ‘retrieve’.
Input in a number and click on the ‘store’ button. You’ll be asked to sign a transaction on Metamask. To confirm the transaction you can confirm it on your block explorer. To see if the transaction went through properly, click on ‘retrieve’ and the number that you just inputted should pop up!
Conclusion and Next Steps
So let’s summarize what we’ve done over the course of the tutorial. We have connected our Saga Chainlet to Remix, one of the most popular IDEs for Solidity development. We deployed a customizable smart contract that implements basic storage on your chain. This storage contract can be changed to store any arbitrary kind of data that may be of interest for a developer.