Original Medium Article by Andrey Tsirulev
In this post we’re going to cover the choice of underlying blockchain technology for Parsec Frontiers. We’ll start from the goals to define requirements, discuss challenges and limitations, mention alternatives, and finally conclude with the choice of technology which we believe to be the best fit for our game.
The PRSC token will be an ERC20 token on Ethereum to allow for an easier crowd sale process and ease of trading on external cryptocurrency exchanges. A corresponding PRSC asset will also exist on the game chain for use in the game world.
One PRSC ERC20 token can be converted into one PRSC customized chain token. The exchange between ERC20 tokens and the customized chain token is facilitated by smart contracts that control the exchange back and forth.
Any asset that players own in game, lives on the blockchain and can be traded on the market. The blockchain ensures transparency and validity of transactions, prevents double spending, and provides the immutable and public history that can be used for financial analysis. We plan to make the market available outside of the rich (3D) game client — via a web interface for users, and a service API for developers.
Trustless is the key word when we talk about blockchain technology. In Parsec Frontiers we aim to create the virtual economy backed with the technical guarantees of working according to the predefined rules, which neither players nor developers can violate. The problem is that blockchain on its own cannot act as the backend for the player experience in a modern real-time MMO, and the traditional trusted game server is still needed. Unfortunately this trust is viral — once you allow a game server to issue digital assets on the market without control, blockchain guarantees nothing but the immutable transaction history (which is great, but obviously not enough). This means that the full production cycle of ingame assets should be exposed to blockchain and validated by smart contracts, up to resource extraction, and to ensure that the resource amount is limited. Even the world generation should be validated by blockchain.
The ingame player activity may also affect the value of an asset in a significant way. The obvious example is relocation — the resource may have a different value in different solar systems due to the non-uniformed resource distribution in the world. The ability to perform instant asset relocation would provide an unfair advantage, and this again requires players to trust that developers or hackers are not using this advantage. That leads us to the idea that the changes of asset properties that affect its value in a significant way, should be properly validated against the simplified but strict game rules on chain.
On the other hand, we can’t validate realtime players activity, especially if it requires traditional gaming skills. For instance, combat resolution is going to be performed by the game server only.
The borderline of trust should be carefully drawn between blockchain and the traditional server, and we will search for the right balance between trustless blockchain economy and rich ingame player experience.
The next step is to use blockchain for player cooperation. Imagine you’ve just bought some goods at Proxima Centauri, and see an opportunity of selling them at Orion for a really good price. The problem is that you don’t have a ship at Proxima Centauri, and you want someone to transfer goods for you. You find a guy to do the job for you, but you don’t really trust him. Fortunately, blockchain smart contracts come to the rescue. You discuss the deadline, the size of the reward for success and the forfeit for failure, then engage in signing the contract.
The example above is only one from many possible scenarios, and we want to encourage players to invent their own. We aim to provide a diagram-based language, which can be used by anyone (even non-technical players), to describe the contracts that are easy to understand. More complex scenarios may require real programming language, and we expect players who are familiar with programming to become lawyers in the world of Parsec Frontiers. The variety of services that decentralized applications can provide includes banking, insurance, clan regulations, betting, and many more.
We anticipate players to not just define the astronomical map of human expansion, but also to shape its social, financial and legal environment.
We have discussed that blockchain can be used to validate asset manufacturing and relocation against the rules of the game, but those rules are not carved in stone. As development proceeds, new features are added, and the existing aspects of the game are modified to improve the players experience. So although we need the flexibility to change the rules, we want to change them in consensus with the players, who are the real owners of the game. We want to develop the governance protocol that enforces this consensus as the required condition of rule contract changes, and if we find a good way for that, we want to do that on chain.
We define the following goals we want to achieve with integrating blockchain:
Issue of PRSC currency
Tradable assets on the market
Contracts and decentralized applications created by players: job contracts, banking, insurance, etc.
Validation of game rules (resource extraction, crafting, asset relocation)
Allow transfer of assets as tradable tokens to Ethereum, and probably other public blockchains
Governance — using blockchain to allow players to vote for game rule changes
Let’s add some non-functional requirements to that list.
We need thousands of transactions per second — for comparison, Ethereum currently supports only tens.
We need to store many thousands of tradable assets, which may have attached metadata (location, stats, etc.) that affects its value.
We want advanced smart contract programming capabilities.
We want a truly decentralized blockchain, maintained by the players. That also means that we need an efficient maintenance incentive model. We don’t want to use PRSC as a maintenance reward, that’s why we are considering a separate token that can also have ingame meaning (e.g. fuel). The exact details are yet to be designed.
We don’t want to depend on transaction fees of existing public blockchains. That’s why we’re searching for a customized chain. However, we still want transaction fees to prevent spamming.
We want players to be able to run the full node (and even encourage it). That means that we need native Windows support, and we don’t require specialized hardware. We also need to find a way to deal with disk usage which we expect to be quite huge.
Finally, we want fast or instant finality. Some blockchains like Bitcoin and Ethereum utilize probabilistic consensus (Proof-of-Work in particular), which does not guarantee finality as the current chain may be eventually be replaced with a more difficult one. You have to wait for several confirmations (mined blocks) to receive the probabilistic guarantee of transaction approvement. Probabilistic consensus complicates game server integration and degrades player experience. For instance, an asset bought on the market can only be used in game after a significant time. The alternative is definite Byzantine (BFT) consensus, where validator nodes agree on the block approval before the new block may be produced.
The famous assertion known as scalability trilemma claims that blockchain systems can only at most, have two of the following three properties: decentralization, scalability and security. Another definition known as the Zamfir triangle was suggested by Vlad Zamfir:
I think this is a fundamental tradeoff in fault tolerant consensus protocols.
As we want instant finality and high performance, that leaves us with a relatively small number of validating nodes. This can be easily explained — apparently a lesser amount of nodes can achieve Byzantine consensus much easier, complexity quickly grows when more nodes are added.
How can we limit the amount of validator nodes but still keep the blockchain truly decentralized?
One of the known solutions is using delegated consensus, where participants vote to elect the limited number of validator nodes which produce blocks in turns, and reach BFT consensus. The voting may be bonded with a participant’s stake, resulting in the hybrid of Proof-of-Stake and Byzantine consensus. In particular, this kind of approach is utilized by Tendermint (and Tendermint Cosmos), EOS.IO (known as DPoS consensus), and NEO (known as dBFT).
These solutions may expect that block producer is not an arbitrary PC node but a dedicated server with permanent uptime. The high cost of running the validator node requires an efficient incentive model. We may also expect that the node is run by group of players rather than by individuals, and that these groups may repeat ingame collaborations.
On the positive side, the dedicated nature of block producer node may be seen as a practical solution to disk usage problem.
Let’s briefly cover some of solutions that we seriously considered but had to withdraw.
Private and consortium distributed ledger (DLT) solutions like Hyperledger Fabric could be a good practical fit, but we decided that we really want our blockchain to be truly decentralized.
Hyperledger Sawtooth is great technology which combines the Byzantine finality with high performance and good decentralization, by introducing Proof-of-Elapsed-Time consensus. Sawtooth was one of our favourites, but Intel SGX hardware dependency, lack of proper Windows support and high disk usage made us drop it from the list.
Aeternity looked attractive due to its use of Erlang (the same platform that we use for our game server) and focus on light clients. We’re really fond of the tech, it has some great features. But its main approach to optimization are two-peer state channels which are not a good fit for our ingame economy model.
If we couldn’t find an ideal solution for all applications we have in mind, maybe we could use different solutions for different applications. This led us to the idea of using heterogeneous parallel chains, with Bitcoin-like UTXO PoW network for PRSC currency, and sharded markets for tradable assets — with market owners defining the maintenance incentive system of their choice, centralized DLT solution for logging and validating ingame events, feature-rich smart contract blockchain for players authored contracts and dapps, and interoperability protocol that would allow asset transfership and event causation. We looked into some interoperability solutions (like Tendermint Cosmos) which is very promising but didn’t provide exactly what we want. Finally we had to admit that while blockchain technology is quite mature these days, blockchain interoperability is still way too young to become the cornerstone of our game.
Finally, we settled on the delegated PoS with Byzantine consensus, choosing between EOS.IO and Neo customized networks. While Eos is a great platform with undoubtful potential, we chose Neo because it’s currently more mature and industry-ready.
Neo has very advanced smart contracts which support several mainstream languages including C# and Java, and we anticipate players will use them along with the diagram-based solution we’re considering implementing.
One of the curious features is the split of NEO and GAS tokens, the latter being used as a maintenance incentive and transaction fee. That suits us well, because we explicitly don’t want PRSC to be used for that purpose. We will still consider altering the incentive system, as well as integrating GAS into the gameplay.
Neo “bookkeepers” produce blocks once per 15 seconds, while in EOS it may happen every second or even less. We’ll have to test how reducing block time will affect blockchain performance.
And of course, we need to work with the players to ensure that we have enough bookkeepers to achieve true decentralization.
dBFT consensus, combining the instant finality with decentralized block ordering through voting for the limited number of bookkeepers
The high performance, promising thousands of transactions per second
Split of voting and incentive tokens, that gives us freedom in tweaking the incentive model
Powerful smart contract facility, that would allow both us and players to use mainstream languages and tools for smart contract development
Native Windows support
MIT license and C# language our team is experienced with allow us to customize the platform
Platform maturity, comparing to rivals
Platform focus on digital assets and digital identity, which is aligned with ours
Resources
