It’s been a while since we last posted a blog. The team has been hard at work improving the Xaya SDK along with Xaya based Soccerverse https://soccerverse.com .
If you’ve never heard about Xaya before, here is a quick TLDR:
Xaya is a SDK and platform that uses blockchain technology to host fully decentralised games and autonomous worlds. It is completely open source and free to use.
Although Xaya has its own blockchain, i.e. Xaya Core, the Xaya SDK is blockchain agnostic so it’s compatible with EVM chains and (with small modifications) almost every other blockchain as well. We’ll explain more about the SDK later, and how Soccerverse runs on Polygon.
As for why decentralised games (otherwise known as autonomous worlds, on-chain games, FOCG and probably a new one after we’ve finished this series of blogs), you can refer to one of our earlier blog posts titled “Why Decentralised Gaming?”.
This is Part 1 of 4 blogs we’ll be releasing over the next couple of months.
Let’s first go over some history and how we got to where we are today.
Xaya’s History
Let’s first start with Xaya Core.
Xaya Core is a PoW (proof of work) blockchain which is a fork of Namecoin, the first blockchain after Bitcoin, aka the first “altcoin”. Namecoin enables the creation of unique identities or names.
FUN FACT: Namecoin names are the first NFTs, with “d/bitcoin” being the world’s first NFT created on April 21st, 2011 (at least as we know of them).
https://namebrow.se/name/d/bitcoin/ (tx here).
Xaya Core has its own coin called CHI, which is used to pay for transaction fees and is also available on EVM chains in its wrapped version (wCHI).
You can read the Xaya Core specs in its GitHub repository here:
https://github.com/xaya/xaya/tree/master/doc/xaya
Xaya was conceived in mid 2016 and launched in July 2018 at a time when blockchain gaming was mostly unheard of. It wasn’t until “Cryptokitties” in November of 2017 that people started to take blockchain gaming seriously.
However, Xaya’s history goes back further than that. The initial idea of decentralised gaming using blockchain technology dates back to 2013 when Xaya co-founder “snailbrain” posted the concept in the Bitcointalk forums here:
https://bitcointalk.org/index.php?topic=262599.0
Along with members of the Namecoin community, such as “domob” (Chief Namecoin Scientist and Lead Xaya Developer) and “thecoder” (RIP) they developed a blockchain gaming proof of concept called “Huntercoin”.
Huntercoin: The 1st blockchain game (2013)
Huntercoin is the first blockchain game, and the first fully decentralised blockchain game.
Huntercoin was conceptualised to embrace the core principles that Bitcoin brought to the world:
- Decentralised
- Permissionless
- Censorship Resistant
- Transparent
- Secure
- Trustless
- Serverless
- Irreversible and immutable
- Anonymous/pseudo-anonymous
- Limited and scarce
You can see an old basic video of Huntercoin in action here:
https://www.youtube.com/watch?v=Q41RW6bxpM4
Huntercoin brought many new features and world firsts to Bitcoin type blockchains:
On-chain Gaming (and blockchain gaming in general).
Complex blockchain logic (similar to smart contracts)
Dual merge-mineable algorithms.
- The first dual PoW algo chain (used in countless other chains afterwards).
- Dual algorithm merged mining (could be merge mined with Bitcoin and Litecoin)
- You can see the initial discussion on merge mining and Bitdns (which became Namecoin) in the Bitcoin Talk forums. It was conceived by Satoshi and it’s one of his last posts before he vanished. https://bitcointalk.org/index.php?topic=1790.msg28696#msg28696
In Huntercoin, all nodes compute the state of the game world, which includes miners, people running the Huntercoin wallet and Huntercoin players. This achieves consensus and verifies Huntercoin transactions (game actions and normal coin transfers).
In Huntercoin you create characters, which in Namecoin (and Xaya) terminology are called “names”, by spending 1 HUC, the in-game cryptocurrency. This 1 HUC is then locked into what is now called an “NFT”. This allows players to use human readable names rather than wallet addresses for their accounts. They can also be traded securely, directly.
As only the character (aka name) owner has the private key, only they can make moves in the game, which are then stored in the blockchain ledger forever. This feature is one of many benefits that Huntercoin inherits from being built upon the Namecoin project.
All on-chain type games follow this in some sort of way. In Namecoin which was initially created for storing decentralised censorship resistant Domain Name Systems (DNS) names, when you create a “name”, you can also assign values to it, such as the “hosting IP address”.
In Huntercoin these values are in-game actions, such as “move to x:y”.
All moves/actions from the very first genesis block up to the current block are fed into the game’s logic to compute the current game state.
You can see some historical information about Huntercoin here:
https://xaya.io/huntercoin-legacy
Although Huntercoin was (“is” if you start mining now) primarily an experimental fully decentralised game, it was also a demonstration of another way to distribute cryptocurrencies through human actions and gameplay as opposed to requiring expensive mining hardware. This was termed “human mining”.
Huntercoin was a proof of concept, as such it was officially only planned to be supported for 1 year. However, the community and the Xaya team supported it for much longer despite having no significant premine (0.01% of the supply?) and no other financial incentives, or funding. A snapshot of the Huntercoin balances was taken and they were used to receive a portion of the initial Xaya coin allocation (in the next part). As the years passed, the team eventually stopped development, the exchanges delisted HUC and miners slowly diminished and eventually stopped mining.
With its relatively simple game mechanics, it was expected that Huntercoin would be botted. However what wasn’t expected was that the game (the Huntercoin blockchain) would take off as fast as it did.
Shortly after launch there were thousands of players playing (human mining) the game earning in excess of $10k a day at a time when Bitcoin was trading between $500 and $600 USD.
This accelerated the incentives for people to employ bots.
Initially there was 1 bot, known as “The Dominator” (BGB on Bitcointalk). This player began dominating the game with pure numbers and simple scripts to move thousands of Hunters around the map, collecting coins, and then returning home to “bank” them. In order to truly claim and own HUC, players had to return to their home base to secure their coins by “banking” them, which cashed out their coins from inside the game to inside their wallets. Prior to banking coins, other players could kill you and steal your coins.
As time progressed, more bots appeared, turning Huntercoin into an arena for lucrative “bot wars”.
After some quick-fix changes to increase the PvP aspect of the game, and the cost to play (which also increased the rewards for killing other hunters), the bot to human ratio was massively reduced. However, human ingenuity and greed are near boundless, and so the bots were improved and evolved to also dominate in combat. But it didn’t stop there. Over time they were constantly improved with advanced features such as watching the memory pool (mempool) to spy on their opponents next moves, and increasing their transaction fees to prioritise their moves over human players and other bot opponents.
This didn’t come as a surprise, but it was still cool to see it.
Some important points we learned (or were obvious anyway) with Huntercoin :
Scaling
One complex game is the limit.
- The more complex the game the longer it takes nodes to compute the state (pretty obvious). Running multiple complex games on one blockchain will be too expensive.
Slow input to the game
- Slow blocks
TX fees
- Needed to prevent spam
Human Behaviour
- If there is a way to make money, humans will find a way, and any flaws will be exploited. For example with bots.
- F2P (or very cheap to play) + the ability to make $$ doesn’t really work for almost all games.
- Simple and transparent gameplay makes it easy for bots.
- PvP + Social Dynamics work best.
From 2015+ we started discussing solutions for the scaling issues, one of which was game channels.
Game Channels
Written by lead developer Dr. Daniel Kraft (domob) and originally released on bitcointalk (2015) and later published in a peer reviewed scientific journal titled “Game channels —trustless real-time decentralised gaming”. Game Channels work similar to the later “state channels” on Ethereum.
Although at this point we didn’t have a working implementation, the theory was sound and Game Channels was peer reviewed and accepted:
In a nutshell Game Channels works as follows:
A player submits an on-chain transaction which is in words — that the player would like to open a channel.
The opponent then submits a transaction and which in words is — they’d like to join that channel.
At this point the users can then directly to each other (or through a relay) play head to head.
This is done by signing moves back and forth, and in some cases (depending on the game) send the state back and forth.
Whatever the rules of the game are, each of the players computes the state of the game themselves and thus also validates the opponents move.
By doing this, the players can play a real-time session, prove if the opponent tried to cheat (as all moves are signed) and ultimately prove who won.
When a user wins they can post on-chain the winning move or the state of the game.
Initially this was designed for a game/chain like Huntercoin in which all the nodes know the logic of the game and can validate the winning move.
Over time Game Channels have evolved, and many ideas and solutions to improve them and their limitations have been discussed and written about.
More information about this in some previous blogs — Game Channels and Ephemeral Time Stamps
Game Channels provide an initial vertical scalability solution for trustless real-time decentralised gaming.
Game State Processors (GSPs)
Huntercoin is one game on one chain. All nodes on the network compute the state of the game world. This works great if there is one game on the blockchain, but what if there are multiple?
Huntercoin was not a complex game on modern standards, however, computing the state still requires some computation. With over 50,000 Hunters moving around the map it would take a second or 5 to compute the state of the game (along with processing / validating transactions). As the blocktimes of Huntercoin were targeted at 1 minute this wasn’t a big issue.
But what if there were more than one game on the chain.
In 2016 we started designing a system which would allow for horizontal scalability and this would be later known as Game State Processors (GSPs).
How GSPs work:
In the example of Huntercoin, where every move is stored on-chain and all nodes calculate the state of the game, we realised that, in reality, there is no real need for all nodes to compute the state of the game.
As long as all moves are signed and stored on-chain by the user’s account, the computation and game logic can be completely detached from the blockchain itself.
As long as users or those wanting to compute the state of the game are using the same “logic” which produces deterministic results based on the moves on the blockchain, then we still have a decentralised game that follows all the principles and features which Bitcoin brought to the world.
Any moves which are invalid can still be submitted on chain, but the GSP will ignore those that are invalid.
By doing this, blockchain nodes don’t need to compute the state of any of the games and only need to deal with the normal coin transactions. This allows for many games on 1 chain.
The GSP can store the state in whatever the developer wishes, such as sqlite/mysql. The state could potentially be GBs in size or more depending on the game. It may also store historical data as well.
GSPs are similar to roll-ups and we have written a blog on how this works in more detail here:
https://xaya.medium.com/xaya-and-rollups-1b5eeba44921
With GSPs and Game Channels combined — you can imagine the types of games that could be built. For example, A Total War game where the world map is slow and strategic and then the real-time combat uses game channels, and the outcome of the combat affects the world map.
And that is the core of how Xaya (and it’s tools) work.
The length of this blog is exceeding what was intended so we’ll cut it here instead of making it too long to read (already is).
The Next Parts:
Part 2 Xaya ICO, Taurion, Soccer Manager Crypto, Xaya Ships, XID, WCHI and Democrit.
Part 3 Present, an in depth look at Soccerverse and the tech behind it (will be a big one), Taurion, CHI/WCHI
Part 4 Roadmap.
Expect the next part in a couple of weeks (or less).
Follow us on Twitter : https://x.com/XAYA_tech or join our discord to get real time updates.
