Game Monetization based on Cryptocurrencies and Blockchains

Transcription

1 Game Monetization based on Cryptocurrencies and Blockchains Luciano Silva Universidade Presbiteriana Mackenzie Laboratório de Computação Visual (LCV) Faculdade de Computação e Informática São Paulo Brasil Figure 1: A cryptocurrency environment for game monetization. ABSTRACT A blockchain is a continuously growing list of records called blocks which are linked and secured using cryptography. A cryptocurrency is a digital asset designed to work as a medium of exchange using cryptography to secure the transactions and to control the creation of additional units of the currency. Cryptocurrencies may use the blockchain technology as an implementation support. This work shows a roadmap of blockchain and cryptocurrencies focusing on Bitcoin and Ethereum aiming to applications on game monetization. It is also presented the DMarket platform a blockchain platform which can easily integrated with game engines such as Unity. Keywords: Game monetization Bitcoin Ethereum Blockchain. 1 INTRODUCTION In 2016 the gaming industry revenue has reached $100 billion and is expected to grow up to 128 billion by While there are millions playing currently only 4000 pro gamers make profits from their time in-game. Existing technologies cannot connect the different game universes and the many gaming platforms together. Players have been stuck with their precious items being undervalued despite the time and effort spent earning them. The evolution of the blockchain technology and smart contracts has enabled them to solve the issue of a cross-platform marketplace for cross-game trading. Users will be able to convert their time achievements and gaming experience into actual money such as depicted on the Figure 1. By design blockchains are inherently resistant to modification of the data. A blockchain can serve as an open distributed ledger that can record transactions between two parties efficiently and in a verifiable and permanent way. So this is a feasible environment for game monetization schemas. In this context this tutorial shows a a roadmap of blockchain and cryptocurrencies focusing on Bitcoin and Ethereum aiming to applications on game monetization. It is also presented the DMarket platform a blockchain platform which can easily integrated with game engines such as Unity. luciano.silva@mackenzie.br

2 2 BLOCKCHAINS 2.1 Fundamental Concepts A blockchain[3] is a continuously growing list of records called blocks which are linked and secured using cryptography. Each block typically contains a hash pointer as a link to a previous block a timestamp and transaction data. By design blockchains are inherently resistant to modification of the data. A blockchain can serve as an open distributed ledger that can record transactions between two parties efficiently and in a verifiable and permanent way. For use as a distributed ledger a blockchain is typically managed by a peer-topeer network collectively adhering to a protocol for validating new blocks. Once recorded the data in any given block cannot be altered retroactively without the alteration of all subsequent blocks which needs a collusion of the network majority. 2.2 Blockchain Data Structure The blockchain data structure[3] is an ordered backlinked list of blocks of transactions. The blockchain can be stored as a flat file or in a simple database. The Bitcoin Core client stores the blockchain metadata using Google s LevelDB database. Blocks are linked back each referring to the previous block in the chain as showed in Figure 2: Figure 2: Blockchain data structure. (src: The blockchain is often visualized as a vertical stack with blocks layered on top of each other and the first block serving as the foundation of the stack. The visualization of blocks stacked on top of each other results in the use of terms such as height to refer to the distance from the first block and top or tip to refer to the most recently added block. It is common the use of trees such as a Merkle tree. A hash tree or Merkle tree is a tree in which every leaf node is labelled with a data block and every nonleaf node is labelled with the cryptographic hash of the labels of its child nodes. Hash trees allow efficient and secure verification of the contents of large data structures. Hash trees are a generalization of hash lists and hash chains. Figure 3: A Merkle tree for blockchain. (src: #merkle_trees) Each block within the blockchain is identified by a hash generated using the SHA256 cryptographic hash algorithm on the header of the block. Each block also references a previous block known as the parent block through the "previous block hash" field in the block header. In other words each block contains the hash of its parent inside its own header. The sequence of hashes linking each block to its parent creates a chain going back all the way to the first block ever created known as the genesis block. Although a block has just one parent it can temporarily have multiple children. Each of the children refers to the same block as its parent and contains the same (parent) hash in the "previous block hash" field. Multiple children arise during a blockchain fork a temporary situation that occurs when different blocks are discovered almost simultaneously by different miners. Eventually only one child block becomes part of the blockchain and the fork is resolved. Even though a block may have more than one child each block can have only one parent. This is because a block has one single "previous block hash" field referencing its single parent. The previous block hash field is inside the block header and thereby affects the current block s hash. The child s own identity changes if the parent s identity changes. When the parent is modified in any way the parent s hash changes. The parent s changed hash necessitates a change in the previous block hash pointer of the child. This in turn causes the child s hash to change which requires a change in the pointer of the grandchild which in turn changes the grandchild and so on. This cascade effect ensures that once a block has

3 many generations following it it cannot be changed without forcing a recalculation of all subsequent blocks. Because such a recalculation would require enormous computation the existence of a long chain of blocks makes the blockchain s deep history immutable which is a key feature of bitcoin s security. 2.3 Distributed Ledgers A distributed ledger (also called shared ledger) is a consensus of replicated shared and synchronized digital data geographically spread across multiple sites countries or institutions. There is no central administrator or centralized data storage. A peer-to-peer network is required as well as consensus algorithms to ensure replication across nodes is undertaken. One distributed ledger design is through implementation of a public or private blockchain system. Figure 4 shows an example of distributed ledger: Bitcoin is a type of cryptocurrency: balances are kept using public and private keys which are long strings of numbers and letters linked through the mathematical encryption algorithm that was used to create them. The public key (comparable to a bank account number) serves as the address which is published to the world and to which others may send bitcoins. The private key (comparable to an ATM PIN) is meant to be a guarded secret and only used to authorize Bitcoin transmissions. Figure 5 shows an example of public key for Bitcoin: Figure 4: A distributed ledger architecture. (src: But not all distributed ledgers have to necessarily employ a chain of blocks to successfully provide secure and valid achievement of distributed consensus: a blockchain is only one type of data structure considered to be a distributed ledger. 3 BITCOINS 3.1 Fundamental Concepts Bitcoin [1] is a digital currency created in Satoshi Nakamoto is the name associated with the person or group of people who released the original Bitcoin white paper in 2008 and worked on the original Bitcoin software that was released in The Bitcoin protocol requires users to enter a birthday upon signup and we know that an individual named Satoshi Nakamoto registered and put down April 5 as a birth date. Figure 5: Public and private Keys examples for a Bitcoin. Bitcoin is one of the first digital currencies to use peer-to-peer technology to facilitate instant payments. The independent individuals and companies who own the governing computing power and participate in the Bitcoin network also known as "miners" are motivated by rewards (the release of new bitcoin) and transaction fees paid in bitcoin. These miners can be thought of as the decentralized authority enforcing the credibility of the Bitcoin network. New bitcoin is being released to the miners at a fixed but periodically declining rate such that the total supply of bitcoins approaches 21 million. One bitcoin is divisible to eight decimal places (100 millionth of one bitcoin) and this smallest unit is referred to as a Satoshi. If necessary and if the participating miners accept the

4 change Bitcoin could eventually be made divisible to even more decimal places. transactions from attempts to re-spend coins that have already been spent elsewhere. 3.3 Bitcoin Programming 3.2 Bitcoin Mining Bitcoin mining is the process through which bitcoins are released to come into circulation. Basically it involves solving a computationally difficult puzzle to discover a new block which is added to the blockchain and receiving a reward in the form of few bitcoins. The block reward was 50 new bitcoins in 2009; it decreases every four years. As more and more bitcoins are created the difficulty of the mining process that is the amount of computing power involved increases. The mining difficulty began at 1.0 with Bitcoin's debut back in 2009; at the end of the year it was only As of April 2017 the mining difficulty is over 4.24 billion. Once an ordinary desktop computer sufficed for the mining process; now to combat the difficulty level miners must use faster hardware like ApplicationSpecific Integrated Circuits (ASIC) more advanced processing units like Graphic Processing Units (GPUs). In the Figure 6 we have a GPU cluster for Bitcoin mining: Figure 6: A GPU cluster for Bitcoin Mining. Source: Bitcoin.com The core business of the Bitcoin blockchain technology is definitely building transactions[5]. In order to build a transaction an ECDSA keypair alone is not enough. We need the blockchain history of the keypair at our disposal the transactions sending value to the address associated with our keypair. Then we ll use the ECDSA private key to produce signatures for such transaction outputs so that they become inputs to our transaction. Given: an ECDSA keypair K a third-party P2PKH output address A the amount S to transfer in satoshis we want to send S satoshis to address A via our keypair K. Here s the overall procedure: 1. Scan the blockchain for the relevant UTXOs to K. 2. Build a transaction output from S and A. 3. Gather enough input value from the UTXOs to reach S. 4. For each input generate the subject of its signature. 5. Generate ECDSA signatures for each input subject. 6. Pack the transaction. At the very beginning of an ECDSA keypair history the derived P2PKH address has no transaction outputs associated with it and therefore has no bitcoin value for the blockchain. When someone later publishes a transaction that sends bitcoins to our address the keypair suddenly becomes a valuable asset. Consider our Testnet address: mqmi3xyqspvbwtrjtk8eupwdvmftz5jhuk Bitcoin mining is a peer-to-peer computer process used to secure and verify bitcoin transactions payments from one user to another on a decentralized network. Mining involves adding bitcoin transaction data to Bitcoin's global public ledger of past transactions. Each group of transactions is called a block. Blocks are secured by Bitcoin miners and build on top of each other forming a chain. This ledger of past transactions is called the blockchain. The blockchain serves to confirm transactions to the rest of the network as having taken place. Bitcoin nodes use the blockchain to distinguish legitimate Bitcoin and its blockchain history. Among all transactions three outputs are still unspent at the time of writing: 1. f34e1c37e736...a2f d...20c6 3. 6b580bada66e totalling a BTC output value (= satoshis).

5 Specifically these are the outputs sending money to our address: The first output of tx 1 (0.87 BTC). The first output of tx 2 (0.001 BTC). The second output of tx 3 (0.08 BTC). If you now translate the words into data structures: <f34e1c37e736...a2f3 0> < d...20c6 0> <6b580bada66e > you have the UTXO outpoints for our keypair/wallet. Besides making up the balance of the wallet the importance of the UTXO set lies in that it contains the outpoints we can reuse to build our own transactions. After spending an UTXO in a transaction input it s removed from the set because an UTXO is always spent in its entirety. For what it s worth scanning UTXOs would require a lot of networking code so building a wallet history from web explorers is a quick alternative. This will cost you some privacy though as you generally don t want to share your addresses with untrusted services. You should know by now how to build a P2PKH transaction output. Say we want to send BTC ( satoshis little-endian): e0 fe 7e to this address: mhmhrnn58ki9zbrj63mpngqxoyvdmxzsxt that decodes to the following hash160 digest: 18 ba 14 b cb e 31 fe cb Here s the first output of our transaction: /* value (0.251 BTC) */ e0 fe 7e /* script length */ 19 /* P2PKH script */ 76 a ba 14 b cb e 31 fe cb ac A convenient C macro in tx.h for building P2PKH outputs from a value and a hash160 is: void bbp_txout_create_p2pkh(bbp_txout_t *txout const uint64_t value const char *hash160); Basically the hash160 bytes are enclosed in the OP_DUP OP_HASH160 and OP_EQUALVERIFY OP_CHECKSIG opcodes. Hexes are interpreted from left to right and are therefore encoded little-endian. We use the macro to easily create our first output: bbp_txout_create_p2pkh(&outs[0] "18ba14b cb05230e31fecb "); Our UTXO set is worth < > BTC respectively so the first one: <f34e1c37e736...a2f3 0> is just enough for a BTC output. In fact our input value exceeds the output value by BTC which are silently returned to the transaction miner as a fee. We know an UTXO cannot be spent partially and since the fee is somewhat relevant to us we add a second output for change. Our final transaction will have one input and two outputs the second being a change output that returns the exceeding input value to our own address. Here s the second output of our transaction: /* value (0.619 BTC) */ e0 84 b /* script length */ 19 /* P2PKH script */ 76 a9 14 6b f1 9e 55 f9 4d 98 6b c1 54 d ac On the other hand it s quite obvious that output value cannot possibly exceed input value. Non-coinbase transactions never create bitcoin value. This is our second output in code: bbp_txout_create_p2pkh(&outs[1] "6bf19e55f94d986b4640c154d ");

6 This is tricky if not even controversial because the subject of transaction signatures is not the transaction itself. When studying ECDSA signatures the signing process takes three steps: 1. Generate an ECDSA keypair. 2. Create a message. 3. Sign the message with the private key to produce a signature. The problem here is that a Bitcoin transaction cannot be signed the usual way since signatures are actually part of the transaction namely the input scripts. The approach has to be different. In fact we ll produce a different signature for each transaction input which in turn will embed it in its P2PKH script. In practice for each input I the message to be signed is a slightly modified version of the transaction where: 1. The I script is set to the output script of the UTXO it refers to. 2. Input scripts other than I are truncated to zerolength. 3. A SIGHASH flag is appended. For a single input transaction we won t need to truncate any other input script: bbp_outpoint_fill(&outpoint "f34e1c37e fed85d1b129713ef7f c31c833985f487fa2f3" 0); bbp_txout_create_p2pkh(&prev_outs[0] "6bf19e55f94d986b4640c154d "); bbp_txin_create_signable(&ins_sign[0] &outpoint &prev_outs[0]); We have the outputs and the signable inputs so we go ahead and construct the message: tx.version = bbp_eint32(bbp_little 1); tx.outputs_len = 2; tx.outputs = outs; tx.inputs_len = 1; tx.inputs = ins_sign; tx.locktime = 0; msg_len = bbp_tx_size(&tx BBP_SIGHASH_ALL); msg = malloc(msg_len); bbp_tx_serialize(&tx msg BBP_SIGHASH_ALL); The external functions all come from tx.h: From the previous post you know that the bbp_tx_size and bbp_tx_serialize functions take care of sizing and serializing a transaction structure to raw bytes. The bbp_outpoint_fill function fills a bbp_outpoint_t structure from an UTXO. The UTXO reference consist of a previous transaction txid and the output index within the transaction. The bbp_txin_create_signable function creates a fake input for our message by copying the corresponding UTXO script. Since we ll sign all transaction inputs we set the flag parameter to SIGHASH_ALL (01). Beware that it s here padded to 32-bit for no apparent reason. The subject of our input signature: /* version (32-bit) */ /* number of inputs (varint) */ 01 /* input UTXO txid (hash256 little-endian) */ f3 a2 7f 48 5f c8 31 8c f ef b 5d d8 fe e7 37 1c 4e f3 /* input UTXO index (32-bit) */ /* input UTXO script (varint + data) */ a9 14 6b f1 9e 55 f9 4d 98 6b c1 54 d ac /* input sequence */ ff ff ff ff /* number of outputs (varint) */ 02 /* output value (64-bit) */ e0 fe 7e /* output script (varint + data) */ a ba 14 b3

7 cb e 31 fe cb ac /* change output value (64-bit) */ e0 84 b /* change output script (varint + data) */ a9 14 6b f1 9e 55 f9 4d 98 6b c1 54 d ac /* locktime (32-bit) */ /* SIGHASH (32-bit) */ Compare the above bytes to the msg output from ex-txbuild.c. This is also the message against which the OP_CHECKSIGopcode validates an input signature. 4 ETHEREUM 4.1 Fundamental Concepts Ethereum [2] is a decentralized platform that runs smart contracts: applications that run exactly as programmed without any possibility of downtime censorship fraud or third party interference. These apps run on a custom built blockchain an enormously powerful shared global infrastructure that can move value around and represent the ownership of property. This enables developers to create markets store registries of debts or promises move funds in accordance with instructions given long in the past (like a will or a futures contract) and many other things that have not been invented yet all without a middle man or counterparty risk. The project was bootstrapped via an ether pre-sale during August 2014 by fans all around the world. It is developed by the Ethereum Foundation a Swiss nonprofit with contributions from great minds across the globe. In Ethereum the state is made up of objects called accounts with each account having a 20-byte address and state transitions being direct transfers of value and information between accounts. An Ethereum account contains four fields: The nonce a counter used to make sure each transaction can only be processed once The account's current ether balance The account's contract code if present The account's storage (empty by default) "Ether" is the main internal crypto-fuel of Ethereum and is used to pay transaction fees. In general there are two types of accounts: externally owned accounts controlled by private keys and contract accounts controlled by their contract code. An externally owned account has no code and one can send messages from an externally owned account by creating and signing a transaction. In a contract account every time the contract account receives a message its code activates allowing it to read and write to internal storage and send other messages or create contracts in turn. Note that contracts in Ethereum should not be seen as something that should be fulfilled or complied with; rather they are more like autonomous agents that live inside of the Ethereum execution environment always executing a specific piece of code when poked by a message or transaction and having direct control over their own ether balance and their own key/value store to keep track of persistent variables. 4.2 Messages and Transactions The term transaction is used in Ethereum to refer to the signed data package that stores a message to be sent from an externally owned account. Transactions contain: the recipient of the message; a signature identifying the sender; the amount of ether to transfer from the sender to the recipient; an optional data field; a value representing the maximum number of computational steps the transaction execution is allowed to take; and a value representing the fee the sender pays per computational step. The first three are standard fields expected in any cryptocurrency. The data field has no function by default but the virtual machine has an opcode with which a contract can access the data. As an example use case if a contract is functioning as an blockchain domain registration service then it may wish to interpret the data being passed to it as containing two "fields" the first field being a domain to register and

8 the second field being the IP address to register it to. The contract would read these values from the message data and appropriately place them in storage. The values are crucial for Ethereum's anti-denialof-service model. In order to prevent accidental or hostile infinite loops or other computational wastage in code each transaction is required to set a limit to how many computational steps of code execution it can use. The fundamental unit of computation is necessary; usually a computational step costs 1 unity but some operations cost higher amounts of gas because they are more computationally expensive or increase the amount of data that must be stored as part of the state. There is also a fee of 5 units for every byte in the transaction data. The intent of the fee system is to require an attacker to pay proportionately for every resource that they consume including computation bandwidth and storage; hence any transaction that leads to the network consuming a greater amount of any of these resources must have a unity fee roughly proportional to the increment. 4.3 Ethereum Programming We are going to use the solidity programming language to write our contract for a voting system as described in [5]: If you are familiar with object oriented programming learning to write solidity contracts should be a breeze. We will write a contract (think of contract as a class in your favorite OOP language) called Voting with a constructor which initializes an array of candidates. We will write 2 methods one to return the total votes a candidate has received and another method to increment vote count for a candidate. The code is: pragma solidity ^0.4.11; // We have to specify what version of compiler this code will compile with contract Voting { /* mapping field below is equivalent to an associative array or hash. The key of the mapping is candidate name stored as type bytes32 and value is an unsigned integer to store the vote count */ mapping (bytes32 => uint8) public votesreceived; /* Solidity doesn't let you pass in an array of strings in the constructor (yet). We will use an array of bytes32 instead to store the list of candidates */ bytes32[] public candidatelist; /* This is the constructor which will be called once when you deploy the contract to the blockchain. When we deploy the contract we will pass an array of candidates who will be contesting in the election */ function Voting(bytes32[] candidatenames) { candidatelist = candidatenames; // This function returns the total votes a candidate has received so far function totalvotesfor(bytes32 candidate) returns (uint8) { if (validcandidate(candidate) == false) throw; return votesreceived[candidate]; Figure 7: A votting system for Ethereum. Source: medium.com

9 // This function increments the vote count for the specified candidate. This // is equivalent to casting a vote function voteforcandidate(bytes32 candidate) { if (validcandidate(candidate) == false) throw; votesreceived[candidate] += 1; function validcandidate(bytes32 candidate) returns (bool) { for(uint i = 0; i < candidatelist.length; i++) { if (candidatelist[i] == candidate) { return true; return false; To compile the solidity code we will first install npm module called solc: mahesh@projectblockchain:~/hello_world_votin g$ npm install solc We will use this library within a node console to compile our contract. Remember from the previous article web3js is a library which lets you interact with the blockchain through RPC. We will use that library to deploy our application and interact with it.first run the node command in your terminal to get in to the node console and initialize the solc and web3 objects. All the code snippets below need to be typed in the node console: mahesh@projectblockchain:~/hello_world_votin g$ node > Web3 = require('web3') > web3 = new Web3(new Web3.providers.HttpProvider(" t:8545")); To make sure web3 object is initialized and can communicate with the blockchain let s query all the accounts in the blockchain. You should see a result like below: > web3.eth.accounts ['0x9c02f5c68e02390a3ab81f63341edc1ba5dbb39e ' '0x7d920be073e92a590dc47e4ccea2f28db3f218cc' '0xf8a9c7c65c4d1c0c21b06c06ee5da80bd8f074a9' '0x9d8ee8c3d4f8b1e08803da274bdaff80c2204fc6' '0x26bb5d139aa7bdb1380af0e1e8f98147ef4c406a' '0x622e557aad13c36459fac83240f25ae c' '0xbf8b1630d5640e272f33653e83092ce33d302fd2' '0xe37a3157cb3081ea7a96ba9f9e942c72cf7ad87b' '0x175dae81345f36775db285d368f0b1d49f61b2f8' '0xc26bda5f3370bdd46e7c84bdb909aead4d8f35f3' ] To compile the contract load the code from Voting.sol in to a string variable and compile it. > code = fs.readfilesync('voting.sol').tostring() > solc = require('solc') > compiledcode = solc.compile(code) When you compile the code successfully and print the contract object (just type compiledcode in the node console to see the contents) there are two important fields you will notice which are important to understand: compiledcode.contracts[ :Voting ].bytecode: This is the bytecode you get when the source code in Voting.sol is compiled. This is the code which will be deployed to the blockchain. compiledcode.contracts[ :Voting ].interface: This is an interface or template of the contract (called abi) which tells the contract user what methods are available in the contract. Whenever you have to interact with the contract in the future you will need this abi definition. Let s now deploy the contract. You first create a contract object (VotingContract below) which is used to deploy and initiate contracts in the blockchain: > abidefinition = JSON.parse(compiledCode.contracts[':Voting'].interface) > VotingContract = web3.eth.contract(abidefinition) > bytecode = compiledcode.contracts[':voting'].bytecode > deployedcontract = VotingContract.new(['Rama''Nick''Jose']{d ata: bytecode from: web3.eth.accounts[0] gas: ) > deployedcontract.address > contractinstance = Voti

10 5 DMARKET DMarket[6] is a global marketplace based on blockchain and smart contracts. It enables one-click sale exchange or evaluation of every virtual item between all games on any platform. Smart contracts are the bridge on blockchain to connect all game worlds and universes without any third party needed. Figura 8 shows the architecture of DMarket platform: REFERENCES [1] Investopedia. Bitcoin. Available at: Retrieved 01 August [2] Ethereum. Ethereum Block Chain Platform. Available at: Retrivied 02 August [3] Andreas M. Antonopoulos. Mastering Bitcoin. New York: O Reilly [4] David de Rosa. Basic Blockchain Programming: The First Transaction. Avaialble at: /. Retrivied 10 August [5] Mahesh Murthy. Voting Ethereum. Available at: Retrivied 11 August [6] DMarket. DMarket Technology. Available at: Retrivied 15 August Figure 8: The DMarket architecture. Source: DMarket exposes a API for the blockchain technology. Using our API a game developer can easily connect the game to DMarket. All operations are fast secured and immediately synchronized. The code below shows an example of a simple contract written using the DMarket API: pragma solidity ^0.4.11; import 'zeppelinsolidity/contracts/token/mintabletoken.sol'; contract DMToken is MintableToken { string public name = "DMarket Token"; string public symbol = "DMT"; uint256 public decimals = 8; In order to test this contract you open the terminal and run the following commands: $ cd dmarket-smartcontract $ truffle migrate To deploy smart contracts to live network do the following steps: $ cd dmarket-smartcontract $ truffle console