CryptoZombies Lesson 5

A walkthrough of lesson 5 cryptoZombies by the LOOM network.

Connor Wiseman
Bitfwd
7 min readJul 3, 2018

--

Introduction

Congratulations! You’re now at Lesson five and have the basic fundamental knowledge of a Ethereum blockchain developer that writes smart contracts. If you have just joined the series please check the previous articles here

Lesson 1 & 2: https://medium.com/bitfwd/solidity-fundamentals-cryptozombies-lesson-one-and-two-64ccd2631cef

Lesson 3 & 4: https://medium.com/bitfwd/advanced-solidity-concepts-cryptozombies-lesson-3-and-4-916237ed5bdf

In lesson Five, we are going to cover how to implement an ERC721 token interface and make each zombie one of a kind with a unique Ethereum 256bit hash that you will able to trade, transfer and battle against other zombies with. Now you may be wondering what is ERC and especially what is ERC721.

ERC stands for Ethereum Request for Comment and ERC721 is the seventh hundred and twenty first request for comment, which was detailed as a non fungible token implementation (NFT). For tokens to be able to represent real-world assets that can not be broken down into denominations. Most ERC721 tokens currently used are in games like cryptokitties or cryptopunks. To understand the difference between an ERC20 and ERC721 I recommend checking them out and comparing the difference to a token like ether, EOS, 0x or makerDAO.

Please see: https://github.com/OpenZeppelin/openzeppelin-solidity/tree/master/contracts/token/ERC721

Chapters 1 & 2

Now it’s time to get down & dirty with more Solidity :) The first chapter in lesson five will ask you to create a new contract called zombieOwnership which should import zombieattack.sol and be set with the latest pragma version. Chapter 2 is very similar and will provide you with an ERC721 interface which should be imported and inherited in the same way as zombieattack.sol

Chapters 3 & 4

In these chapters you wont be asked to do much, as the LOOM network has already given you the ERC721 interface in the ownership contract which is made up of 5 functions. All of these functions have to be implemented inside any contract that wishes to be ERC721 compliant. You will only have to code in one line in the first two functions of chapter 3 which will allow the contract to return the balance, of how many zombies a user has and which user owns what zombie.

After you have completed that step you will be taken to zombieFeeding for some re-factoring on the modifier functions. You will have to change the name of the modifier in zombieFeeding to onlyOwnerOf and then change the modifier declaration in the the feedAndMultiply function.

Chapters 5, 6, 7 & 8

These chapters are about making it possible to transfer your zombies from one Ethereum address to another, You will be asked to create a private function called _transfer which will take 3 parameters (_from, _to, _tokenId)

The body of the function will be built out by incrementing the balance of ownerZombieCount for the _to address, decreasing the balance of ownerZombieCount for the _from account, change the zombieToOwner of the tokenId and the last line should call the transfer event from the ERC721.sol file.

Now it will be time to build out the ERC721 compliance function that was given to you in chapter 3. All you have to do is add the onlyOwnerOf modifier to function declaration and call the _transfer inside of the function body. The only difference being that you should add in msg.sender instead of using _from in the argument of the function.

Chapter Seven will keep you going through the ERC721 functions and building out the ownership contract, the next function to make usable is the approve function. This will allow you to approve a Ethereum address (user) to transfer a zombie that is attached to your address and move it to thiers. You will need to log these approvals because the approve function gets called in the takeOwnership function as well. To accomplish this you will need to declare a mapping at the top of the contract called zombieApprovals which should map the tokenId(uint) to the approved address this way you can see who is approved to take which zombie. Once the mapping is defined you can start to code the body of the approve function but before you do that you must add the onlyOwnerOf modifier to the declaration. The body of the function will need to set zombieApproval for tokenId against the _to address, and then call the approve event from the ERC721.sol contract.

DONT FORGET TO USE msg.sender AS THE _owner

Now you should be at chapter 8 and be asked to edit the takeOwnership function by giving it a require statement zombieApprovals for the tokenId is the msg.sender. Next you will need to call the _transfer function but to do so you must have to address of owner which the tokenId is being transferred from, and then to do that you have to declare an address variable called owner and set it equal to ownerOf[_tokenId] on the next line of code after the variable. You can call the _transfer function the function must have msg.sender as to _to parameter.

Chapters 9, 10, 11 & 12

The next four chapters are all about using the safe math library from openZepplin and preventing overflow within function calls from our smart contracts. The first steps of implementing SafeMath is pretty straight forward all you need to do is import the contract into the zombieFactory contract and then add a declartion of using safeMath against uint256. Safe math libraries have four functions which can be used through any smart contract add, sub, mul and div.

Continuing on from chapter 9 the tutorial will take you to zombieownership where you will need to add safeMath methods, to line23 && 25 the way of implementing the methods are simple. You just have to remove the plus and minus symbols and replace them with = ownerZombieCount[_to].add(1); for line 23 and ownerZombieCount[msg.sender].sub(1); for line 25.

Time to go back to zombieFactory and add another 2 safemath declarations below using safeMath for uint256 the only difference being you will have to use safemath32 for uint32 && safemath16 for uint16. Those are the first two steps of chapter 11 the next is to simply use safemath add for ownerZombieCount[msg.sender]++ in the _createZombie function.

Last step now of the safe math re-factoring in zombieAttack first line of code you need to change is randNone++; then there is 3 to modifiy in the attack function wincount, level, losscount and finally another 2 in between the brackets of else in the same function. losscount, wincount.

Chapter 13

To finish of this lesson the LOOM network is showing you how to add the final details like comments your smart contracts. Comments will give you a chance to provide information on the smart contract such as what the contract is for, what are the parameters and if you have used other contracts inside your code, where did you get the contracts from.

CONGRATULATIONS — you have now completed lesson 5 of cryptoZombies by the LOOM network and are now well on your way to becoming a solidity wizard who can take the world of decentralisation and blockchain programming by storm. The lessons you have covered through-out this series are the basic concrete aspects of smart contract development.

Things to take from the 5 lessons:

1 : Data types and structures (uint’s, bytes, bool, int && array, mappings, structs)

2: Accessibility Restrictions (public, private, internal, external)

3: Function modifiers.

4: Smart contarct design structure (Factory, Feeding, Battle, Ownable)

5: Non-fungible token contract.

Once again I hope you all enjoyed the series, and that you have gained something you can put into real life pratice and who knows maybe you will end up on the moon with Princess Liea Peaches :)

please leave a review and clap!
Also stay tuned and follow for more Ethereum magic :)

--

--

Connor Wiseman
Bitfwd

Blockchain architect — interested in decentralised solutions that remove the currently centralised middlemen of many industries.