Blockchain Features in The Sandbox
Our goals for The Sandbox are to not only develop a great game that allows players to become blockchain-empowered creators, but also foster the underlying technology to make the Sandbox ecosystem a reality.
Follow us on Telegram: https://t.me/sandboxgame and Discord: https://discord.gg/vAe4zvY to ask any questions to our team and community and receive our latest updates.
Introduction
To reach players who are not already familiar with blockchain and the web3 ecosystem, we have to adapt to the evolving nature of it, adopt the best standards to handle thousands of items while paying the minimum (or even non-existent) gas cost possible, and ideally allow players and creators to interact with the blockchain without having to own or understand Ether, the currency underlying the ethereum network.
As more and more artists and creators join our fund to create thousands of assets that will end up in the Marketplace as NFTs or Limited Editions Items (ERC1155), we want to share the technical decisions and implementations on the blockchain that make The Sandbox a unique project.
SAND, an ERC-20 Token with extra features
ERC-20, the leading token standard on Ethereum, allows ERC-compatible fungible tokens to be freely exchanged since they share a common group of rules that make their interactions predictable. Our ERC20 token, SAND is augmented with various features to make the life of our users easier.
EIP-712
One way to avoid the cost of blockchain is to minimize the interaction being made on the network. Signing message provide a mechanism by which user are able to make action without hitting the blockchain. While the first type of signed message available on web3 wallet and browsers were crude, the recent addition of EIP-712 has improved the situation to a great extent. Our SAND contract thus uses EIP-712 for approval, and meta transactions as you’ll see below. Another aspect of EIP-712 is the increased security it provide by separating message in domain to protect against replay attacks. Here is an example of such signing request being used on Metamask.
Native Meta transactions
Meta transaction is a term first coined by Christian Lundkvist to describe a mechanism allowing users to interact with the Ethereum blockchain without needing to own ether. The Uport team were one of the first to implement them for their identity contract.
While users do not need to own ether to broadcast such meta-transactions, someone else needs to spend ether to allow the content of the transaction to be performed on the network.
A relayer is the party responsible for it. There is currently some research on how to organize a set of relayers to provide the service in a decentralized manner. For our case, though we can act as a single relayer providing a useful service to our users. Now while we pay the transaction fee in ether with our own server-side hot-wallet, we require the user to pay us in Sand.
While meta transactions normally require support from the user ‘s wallet in the form of a smart contract acting as an identity for the user, our SAND token is actually implementing a variant of meta transaction called “native meta transaction”, a term first coined by Austin Thomas Griffith here. This allows users without such wallet to directly send meta transaction via our SAND ERC-20 implementation. They simply need to own SAND to interact with Ethereum. While such idea has been discussed in the past, we are pioneering the first live implementation and are currently working on formalizing the idea in the form of a new ERC so that web3 wallet and browsers can provide a meaningful UI to the user.
How it works
The user is asked to sign a message embedding all the details of the operation he or she wishes to perform, including the fee in Sand the user will pay the relayer to perform the transaction.
Once the message is signed, the frontend sends it to our backend. Our backend (the relayer) then creates a specific transaction that include the message signed by the user. The transaction is broadcasted and the backend returns the transaction hash to the user.
When the transaction is mined, if all the details are correct, the action the user signed for will be executed and the fee in Sand will be deducted from the user’s balance.
Note though that our backend needs to verify a few parameters before submitting the transaction to the network to ensure it is not wasting gas. For example, we need to ensure the user has enough Sand to pay the transaction, or else the transaction would fail and gas would be wasted (paid by our wallet) and we also need to ensure that the user is giving us enough Sand to cover the gas cost. Note that it is possible that between the time the check is made and the transaction is mined, the user could have drain all its Sand token and in that case, we would waste gas. This is a risk we need to take even though it is unlikely to happen as it will not benefit the user in any way.
Upgradeable Contract
All the features mentioned so far relies on standards yet to be finalized. As such, after a long reflexion weighting the cons and pros, we decided to make our SAND smart contract upgradable so that we can support standards that are almost finalized like EIP-712 (waiting for array support) or that are being worked on (native meta-transactions, subscription….) to offer a compelling user experience as it become possible, without delaying our launch.
This was a difficult decision to take since it brings both risks and responsibilities we could have avoided by simply making our smart contract immutable. In the end we decided that an upgradeable Sand token is the best option to give us the flexibility necessary to support the best user experience by following the evolution of the web3 ecosystem closely. Our end goal though is to make the smart contract immutable once nothing need to be changed. Hopefully this will happen sooner rather than later. In the mean time the ability to upgrade will be safely guarded by multi-signature contract like Gnosis Safe and hardware wallets.
Implementation wise we use the “Transparent Proxy” strategy, described by openzeppelin here.
ERC-777 Events compatibility
ERC-777 fixes some of the issues facing ERC-20 users as well as allow for token holder to define rules upon transfer, giving them more control. It also features a more elegant way to accept tokens from external contract. As such we wanted to make SAND ERC-777 compatible. Unfortunately, even though it is nearing completion, it has not been finalized.
While our SAND token is upgradeable, it is practically impossible to emit all past events of a smart contract. For that reason our ERC-20 smart contract also emits ERC-777 events, allowing us to upgrade it to support ERC-777 when ready (assuming the ERC777 standard do not change the events’ signature).
ASSET, a dual ERC-721 / ERC-1155 token smart contract
The second smart contract we are implementing is the one managing our creators’ voxel creation. While some creators will want to create unique items, it is likely that many of them will want to sell several copies in the form of limited editions items. Blockchain allow for both of these type as ERC-721 and ERC-20 tokens respectively.
Unfortunately these 2 standard require a separate contract to be deployed for each token type or collection. This limits certain functionality by the nature of separating each token contract into its own permissioned address. With the rise of blockchain games and platforms like Enjin Coin, game developers may be creating thousands of token types, and a new type of token standard is needed to support them. ERC-1155 was created for that reason.
The Sandbox require the same set of functionality as creators will be creating thousands of types of Voxel asset each of them with different scarcity. We thus participated in its conception of ERC-1155 and we are happy that such token contract standard is compatible with ERC-721, allowing us to manage both NFT and limited item in one contract.
Similarly to our SAND token, we pushed our ASSET contract further to allow for an optimized user experience, including built-in escrow-less auction and signature based approval. By implementing it at the token level, we remove the need for any extra interaction with the users. A feat not possible with generic marketplaces which require user to pre-approve extra smart contract.
ERC1155 and ERC721 Extraction
For ASSETS, as mentioned we are using a dual ERC721 / ERC1155 smart contract to support both NFT token (whose supply is always 1, which has a unique owner, and can have attributes associated to it individually) and limited edition tokens (ERC1155) that represent fungible items of different scarcity. By letting them live in the same contract we can manage them in group easily.
We also added support for ERC721 extraction, allowing a user to extract a NFT from a “limited edition” item so that it can get personalized for example. We are still deciding whether this will end up in the final version as one of the optimization we implemented in ERC-1155 is voided when extraction is enabled.
Escrow-less auction
As mentioned our ASSET contract has built-in support for escrow-less auctions, allowing the use of cryptographic signatures to sell and buy ASSETs, without the need to escrow those ASSETs (avoiding a costly transaction).
This process works as follows:
- The seller authorizes our smart contract to exchange any amount of specific ASSETs for a specific amount of ETH/SAND by signing a message with their private key.
- This signed message is stored on our servers, where everyone can see it.
- A buyer can claim this ASSET by presenting this signed message to the smart contract and paying the specified amount. The smart contract will verify its authenticity and then make the exchange.
Signing a Message
Signing a message with a private key does not require interacting with the Ethereum network. It can be done completely offline. In the browser it can be done using web3 and MetaMask.
Gas Cost
As we can see on table above, there is no cost to sell ASSETs, and cancelling a sale is much cheaper than in other systems. The only one paying is the buyer, which almost maintains the cost of a normal escrow-based auction.
There are other benefits. For instance, the user gets to use his/her ASSETs until they are sold. they can start an auction with a high price, and if it doesn’t sell as much as they want, they can lower its price without any cost — which would be impossible in the case of an escrow-based auction. (In our system, they just have to sign a new message, replacing the old signature and values. The other way around is not possible, because other people could still use the old signature, which will be valid until cancelled or the amount for sale gets to 0.)
LAND, avatars and the use of off-chain data
The third smart contract we are working on is that of LAND. Every Players will be able to own land and terraform as they see fit. They will also be able to place the ASSET they own there. Finally when our platform get ready, creators will be able to script these LAND and ASSET to bring to life amazing game experiences.
Obviously, every such modification (terraform, ASSET placement) can’t all happen on-chain. As we were building our technology stack, we quickly realised what needed to be on-chain and what could stay off-chain. The main realization was that every data that can be self described by users has no need to be on-chain since the user is always in control of its individual ASSET and LAND.
As such the LAND configuration (block position and ASSET placement) can be saved off-chain, while ASSET and LAND ownership stay on-chain. Our game client is aware of this distinction and will display the LAND accordingly.
We decided to implement avatars (which players will be able to customize with ASSETs) in a similar way. Instead of setting the avatar via on-chain transaction (a la ERC-998) which would make the experience disastrous for players, we opted for letting the user set the avatar configuration off-chain.
What’s next?
All the features presented here have one goal in common: a better user experience. There is still a lot to achieve in the web3 ecosystem on that matter and we will continue to strive for the best.
We are also working on enabling ASSET with special features and attributes so they can have different impact in the various game experience the players will create.
As a user generated content platform, we are facing other challenges too. For example, since the Asset are minted on Ethereum, a permission-less platform, it is to be expected that all sort of voxel asset will end up being minted on our ASSET smart contract. We will have thus to filter such content on our game and marketplace.
This is obviously a very difficult problem as the number of such asset minted grow. We are working on a solution that will let the whole community of players and creators participate in the moderation of our platform. We are excited to see this platform being used by players and creators alike form all over the world.
In the mean time do not hesitate to visit our website at https://www.sandbox.game. If you are an artist or someone curious enough do not hesitate to try our unique voxel editor too at https://www.voxedit.io/
You can also follow us on Telegram: https://t.me/sandboxgame and Discord: https://discord.gg/vAe4zvY to ask any questions to our team and community.
Thanks for reading
