-
Reviewing the Ethereum improvement proposal process and standards
-
Exploring ERC standard tokens ERC20 and ERC721 for fungible and non-fungible assets
-
Designing and developing of ERC721-compliant real estate token
A smart contract can tokenize any asset, tangible (real, financial) or intangible (brand, performance). Tokenize means representing the asset with a digital unit that can be transferred, traded, exchanged, regulated, and managed like fiat currency or cryptocurrency. Examples of assets are computing artifacts, files, and photos on digital media, real estate, collectibles, stocks, and even intangible concepts such as security and performance. The asset can be virtual, physical, or imaginary! CryptoKitties is an example of the successful tokenization of an imaginary pet family launched on the Ethereum blockchain. You can buy, trade, and breed CryptoKitties as digital pets. You can view many other working tokens on Etherscan. Beyond the hype of digital pets, tokenization has the potential to be a disruptive, visible aspect of blockchain innovation.
Tokenization of assets further helps with the following:
- Standard management of asset behavior with smart contract features
-
Streamlined recording and sharing of information about assets via blockchain distributed ledger technology (DLT)
-
Traceability of goods and services, such as in supply chains
-
Faster confirmation of business transactions such as the sale of real estate (a few hours instead of a few months)
Overall, tokenization is expected to boost the broader applicability of blockchain technology.
In chapters 6-8, the focus was on end-to-end decentralized application development. In this chapter, you’ll explore the broader impact of blockchain technology with the introduction of the token concept. You’ll learn about standards built around tokens and about fungible and non-fungible tokens. A new smart contract, the RES4 token, demonstrates the token concept for transforming real estate assets into crypto-assets. You’ll design and develop a RES4 Dapp, which illustrates how to take advantage of the blockchain features of trust, immutable recording, and intermediation for efficient transactions of real estate assets.
Tokens need to comply with standards to facilitate seamless interaction among different token applications. This situation is similar to the way that different fiat currencies behave in financial markets and exchanges. Ethereum provides these standards through its protocol improvements initiated by the Ethereum Improvement Proposal (EIP) process. The RES4 is not just another smart contract; it will be designed as an Ethereum standard token to show you how to develop a token that is compliant with Ethereum standards.
9.1 Ethereum standards
Any time a technology grows exponentially in many directions, with deep and broad impact on all walks of life, from politics to pet shops, we need to pay attention to bringing some order to the situation. This expectation is not unusual. Take a look back at when operating systems became a big deal. Portable Operating System Interface (POSIX) standards were introduced for interoperability among operating systems. The Internet Engineering Task Force (IETF) was established for defining internet standards through requests for comments (RFCs). Commercial flights can land in any compliant airport in any country because of aviation standards--those of the International Organization for Standardization (ISO). Standards bring order, safety, regularization, and clarity to any field. They are especially imperative for a nascent and high-interest technology such as blockchain. Let’s explore a little bit of token history. During the years since the advent of Bitcoin and smart contracts, many standalone coins and tokens emerged. This expansion gave rise to many issues and questions about a token such as
- What does it represent?
-
What is the value of this token, and how do you assess the value?
-
Can you exchange it for another type of token or for any fiat currency?
These are concerns not only for you and me but also for the U.S. Securities and Exchange Commission (SEC) and regulatory agencies that are trying to regulate the cryptocurrency industry to protect investors from fraudulent products and investments. The Ethereum community continually addresses these issues through a process that includes development, discussion, and introduction of standards. It has developed a method to improve the protocol that underlies its blockchain and provides standards for advancing application development.
9.1.1 Ethereum improvement proposal
Let’s examine how standards evolve in Ethereum. A standard is developed under the EIP (https://eips.ethereum.org/EIPS/eip-1) to promote improvements in the Ethereum ecosystem. The EIP is a means to manage the protocol specification, improvements, updates, client APIs, and contract standards. EIP handles issues in different categories, including
- Core or core Ethereum protocol
-
Ethereum request for comments (ERC) or application-level conventions and standards
9.1.2 ERC20 token standard
As an immediate response to introduction of Ethereum, numerous cryptocurrency tokens emerged to represent various services and businesses. The ERC20 standard interface was introduced so that Ethereum-based cryptocurrency tokens follow a standard and are compatible. The ERC20 standard specifies a set of rules that allows the tokens to interact with one another, exchange with one another, and transact on the Ethereum network.
The OpenZeppelin organization (https://openzeppelin.com) is an active community that supports Ethereum protocol. Its improvements and token standards are discussed at https://docs.openzeppelin.com/contracts/3.x/api/token/erc20#IERC20. Here is a partial definition of the ERC20 interface:
contract ERC20 { function totalSupply() public view returns (uint256); function balanceOf(address tokenOwner) public view returns (uint256
balance); function allowance(address tokenOwner, address spender) public view
returns (uint256 remaining); function transfer(address to, uint256 tokens) public returns
(bool success); function approve(address spender, uint256 tokens) public returns
(bool success); function transferFrom(address from, address to, uint256 tokens)
public returns (bool success); //events event Transfer(address indexed from, address indexed to,
uint256 tokens); event Approval(address indexed tokenOwner, address indexed spender,
uint256 tokens); }
The ERC20 definition also includes the token name, token symbol, and an attribute (decimal) that specifies how to represent a fractional of a token--the scale factor. To create and deploy a token for an asset or utility compliant with the ERC20 standard, you'll implement a smart contract with the functions required by the ERC interface:
contract MyToken is ERC20 {
// implement the functions required by ERC20 interface standard
// other functions...
}
Hundreds of ERC20-compliant tokens have been deployed, and you can see them on Etherscan. These tokens piggyback on the Ethereum network and can operate with the same address as your Ethereum node. More important, theoretically, an ERC20 token can be exchanged for any other ERC20 token on crypto exchanges. This notion opens a whole new world for Dapps!
Here is a view of ERC20 token Txs on the regular Etherscan (https://etherscan .io/tokens), shown in figure 9.1. It shows two different ERC20 tokens transferred from one account to another. You can also locate many such transfers by exploring a token tracker for ERC20 tokens. The link here for the Tx is shown in figure 9.1. It shows the history of the Tx (http://mng.bz/nzYg). Click it and view the record of the Tx to understand the details of a token Tx.
Figure 9.1 Transaction with ERC20 token transfers
NOTE At the time of this writing, ERC20 is being replaced by ERC777, an improved version fungible token standard.
9.1.3 Fungible and non-fungible tokens
An ERC20 token is like currency, letting users buy certain utility or services by spending the tokens. There is an ERC20 token for paying for energy consumption in the Grid+ application, for example. One ERC20-compliant token of a kind (such as the REP token of Augur) is exchangeable with a token of the same kind, which means that it is a fungible token (FT).
A dollar bill can be exchanged with another dollar bill, so it is fungible. When a token represents an asset or a pet, like a real-world puppy, and it grows into a super dog that wins a world competition, this token value would appreciate enormously. Pokémon cards are another example. How about baseball cards and real estate? In these cases and many more practical examples, a given token value may appreciate or depreciate depending on many factors. This type of token is known as a non-fungible token (NFT). In this case, tokens are of the same kind, but they are not equal in value and so are not exchangeable for equal value.
DEFINITION A fungible token (FT) is identical to every other token in value for the same class of tokens. One FT is equally exchangeable with any other within the given class.
Definition A non-fungible token (NFT) is a unique token within given token class. An NFT is not equal to any other NFT within the given class.
Figure 9.2 further illustrates the concepts of fungible and non-fungible.
Figure 9.2 Fungible vs. non-fungible assets
As in figure 9.2, every ordinary dollar bill has the same value as every other dollar bill. This equation applies to 1 ETH and 1 Bitcoin, which are said to be fungible items. One item is replaceable by any other item of the same kind. But one pet dog is not the same as any other pet dog in the world. The pet dog Milli is not the same as the pet dog Riley!
In the highly popular Cryptokitties (https://www.cryptokitties.co) Dapp, a token (symbol CK) is used to represent a kitty, and the rules for its creation, life cycle, breeding, and so on are written into the immutable Ethereum blockchain and the smart contracts supported by it. At predetermined times, a certain number of new tokens are released and auctioned off to raise new funds. Assets--kitties, in this case--also appreciate or depreciate (value) based on demand and individual characteristics. Every asset is unique; one asset is not the same as the other. The kitties are not interchangeable. So these tokens are also non-fungible.
The Ethereum community designed a fungible and non-fungible token and a standard for each type. ERC20 is the fungible token, and thousands of exchangeable ERC20-compliant cryptocurrencies were deployed. ERC721 is the standard for a non-fungible token, and Cryptokitties, where it originated, made it famous.
Fun aside, you’ll have to consider the ERC721 token model seriously. ERC721 applies to a broad range of non-fungible assets. It can represent a lot of use cases, from stocks and real estate to collectible art. Consider a ERC721 token to be a model for timeshare and rental properties--maybe even a piece of land on Mars. The possibilities are endless.
In section 9.2, you’ll explore an ERC721-compliant token representing real estate assets.
9.2 RES4: Non-fungible real estate token
Property ownership--including land ownership, housing, and real estate--has been a tricky problem everywhere on earth since the dawn of history. Many wars and feuds are about land assets. Let’s consider real estate to be a non-fungible asset and then design and develop a token Dapp for it. It is worthwhile to note that even though real estate is the asset of focus in this exploration, the token we design stands for numerous other assets in many businesses, as well as in socioeconomic, cultural, and art applications.
We’ll begin with a problem statement and then apply the design principles (appendix B) to design and develop the application. This real estate token will be called RES4 (real estate for all).
Problem statement Design and develop a real estate token decentralized application representing new real estate developments in a town. The town supervisor can add a piece of real estate as an asset (RES4 token) and at the same time assign it to an owner. This task is accomplished by the process of the creation of the RES4 token. (Assume that the funds for asset ownership are transferred by other means that are not within the scope of this problem.) The owner of the token can add value to the token by building on it, as well as approve a sale to a buyer, and an approved buyer can buy the asset. The real estate asset may also appreciate or depreciate as determined by a town’s assessor. For simplicity, assume that the town supervisor and the assessor have the same identity, and that they represent the town and perform operations on behalf of the town.
RES4 is a simplified version of the real-world real estate business. You can improve this basic design after you complete development of the RES4 smart contract and Dapp.
9.2.1 Use case diagram
To get to the smart contract design, you begin with design principle 2: designing the use case diagram. Figure 9.3 shows the actors for the RES4 token as follows:
Now let’s depict these elements in a use case diagram to begin solving the RES4 token Dapp problem. You can observe the four roles: town supervisor, assessor, owner, and buyer. Essential operations are represented as use cases: add an asset, build, approve buyer, buy and transfer, and assess the property.
Figure 9.3 Use case diagram for RES4 asset token Dapp
9.2.2 Contract diagram
The contract diagram expands on the guideline provided by the use case diagram and adds more elements of design: data structures, modifiers, events, and functions (function headers). The contract diagram has only three elements: data, events, and functions. The access rules are specified inside the functions with require statements (require (condition);), not at the header of the functions. The RES4 follows the ERC721 standard that defines a set of function headers.
Figure 9.4 shows the contract diagram for RES4. Besides the data and the events, the RES4 functions in the contract diagram follow the use case diagram. These functions are addAsset(), build(), approve(), and transfer(). The functions appreciate() and depreciate() are for supporting the operations of the assessor role. These operations allow town officials to increase or decrease the current value of an asset. The events specified in the contract diagram are required by the ERC721 standard.
Figure 9.4 RES4 contract diagram
9.2.3 RES4 ERC721-compliant token
Do you wonder how ERC721 is defined? A smart contract implements the specifications of the ERC721, so it is ERC721.sol, written in Solidity. In this section, let’s look at the details of ERC721 token and at how to make RES4, an ERC721-compliant token.
ERC721 token standard
Every ERC721 token is unique. One of the requirements of the ERC721 standard is the limited supply of tokens. The limited number of tokens is not an issue with real estate assets; only a limited number of assets is possible if you consider all the real estate assets in an entire town or country, or the whole world. The standard is an interface that specifies functions (headers) that are required to be implemented. For a token to be ERC721-compliant, it has to implement the required functions of the ERC721 interface standard. The design of the ERC721 interface piggybacked on the ERC20 definition. The ERC721 standard is also evolving as I write this chapter. A new function called safeTransferFrom() has been added to the ERC721 interface, for example. Here are the functions of the ERC721 interface that are used in the development of RES4:
interface ERC721 {
function balanceOf(address _owner) external view returns (uint256 balance);
function ownerOf(uint256 _tokenId) external view returns (address owner);
function approve(address _to, uint256 _tokenId) external payable;
function transferFrom(address _from, address _to, uint256 _tokenId) external
➥ payable;
function safeTransferFrom(address _from, address _to, uint256 _tokenId)
➥ external payable;
...}
Besides these functions, we’ve also used a function from another standard ERC721-Enumerable interface: function totalSupply() public view returns (uint256 total). The totalSupply() function limits the number of tokens. The number of items are limited for many assets, including paintings, art, and habitable land on earth. The next two functions, balanceOf() and ownerOf(), gives details on tokens (assets) owned by an address. The function approve() is required for ERC721 to allow an address to spend the token. But it is very important to note that in the RES4, with real estate as an asset, the approval has a different meaning: approval of an asset (token) for sale to a specific address. The functions transferFrom() and safeTransferFrom() are variations of functions to transfer an asset from one address to another.
Given these functions, how do you incorporate the ERC721 standard into your smart contract and Dapp development? That’s what you’ll learn next.
Note ERC token standards are in flux, changing in numbering, support classes, and functions. This situation is understandable for an emerging subject such as tokenization. Some tokens are implemented as only partially compatible with the standards. Be aware of these aspects when you develop a token.
RES4 smart contract
Using the use case diagram (figure 9.3) and the contract diagram (figure 9.4) as guidelines, develop the smart contract for RES4. Figure 9.5 shows the block diagram of the Dapp. Observe a new element: the ERC721 token interface. The RES4 smart contract will use the inheritance of traditional object-oriented design for involving ERC721, as shown in figure 9.5. You’ll have to add ERC721 as another smart contract (ERC721.sol) in the contracts directory. It also needs other support contracts. These contracts are located in helper_contracts directory to separate them from the main RES4 contract. The ERC721 interface is incorporated into the code by the following additions to the smart contract. Follow these steps to inherit the features of one smart contract into another:
-
Import the ERC721 standard interface at the beginning of the smart contract code for RES4:
import "./helper_contracts/ERC721.sol";The ERC721 smart contract is imported from a
helper_contractsdirectory that also has other contracts used by ERC721.sol. Open the contracts directory, and browse the helper contracts. You’ll find many support contracts. -
This relationship between RES4 and ERC721 is also shown in figure 9.5. RES4 smart contract is an ERC721 token; this is how you specify inheritance in smart contracts:
contract RES4 is ERC721
Figure 9.5 RES4 Dapp with ERC721-compliant smart contract
9.2.4 RES4 Dapp
Figure 9.5 shows the overall structure of the Dapp with the contract and app parts. Listing 9.1 shows the RES4 contract. The ERC721 interface is imported from the Ethereum EIP site (http://mng.bz/v9oJ). For convenience, we’ve downloaded and added this ERC721 smart contract and other related standard smart contracts to the RES4-contract/contracts in a directory called helper_contracts.
Development of RES4 smart contract
The data defined is mostly for managing the various attributes of the tokens. The functions are developed in four major categories, as delineated by comments in listing 9.1:
- Mapping for various attributes
-
Internal functions to support these and other utility functions
-
You’ll have to implement all the functions for ERC721 compliance, but your Dapp may not need or use all of them. That’s why you see two sections in listing 9.1: one for the ERC721 functions required for the RES4 Dapp and one at the bottom that has ERC721 functions used by the RES4 token Dapp but implemented for compliance. You can find the complete smart contract in the codebase of this chapter.
Listing 9.1 RES4 smart contract (RES4.sol)
pragma soldity >=0.4.22 <=0.6.0;
import "./helper_contracts/ERC721.sol";
contract RES4 is ERC721 { ❶
struct Asset{
uint256 assetId;
uint256 price;
}
uint256 public assetsCount;
mapping(uint256 => Asset) public assetMap; ❷
address public supervisor; ❷
mapping (uint256 => address) private assetOwner; ❷
mapping (address => uint256) private ownedAssetsCount; ❷
mapping (uint256 => address) public assetApprovals; ❷
//Events
event Transfer(address from, address to, uint256 tokenId); ❸
event Approval(address owner, address approved, uint256 tokenId); ❸
constructor()public {
supervisor = msg.sender; }
// ERC721 functions ❹
function balanceOf() public view returns (uint256) {... }
function ownerOf(uint256 assetId) public view returns (address) {... }
function transferFrom(address payable from, uint256 assetId)...{ ...}
function approve(address to,uint256 assetId) public { ...}
function getApproved(uint256 assetId) ... returns (address) { ...}
// Additional functions added for RES4 token ❺
function addAsset(uint256 price,address to) public{ ... }
function clearApproval(uint256 assetId,address approved) public {...}
function build(uint256 assetId,uint256 value) public payable { ...}
function appreciate(uint256 assetId,uint256 value) public{ ...}
function depreciate(uint256 assetId,uint256 value) public{ ... }
function getAssetsSize() public view returns(uint){... }
// Functions used internally ❻
function mint(address to, uint256 assetId) internal { ...}
function exists(uint256 assetId) internal view returns (bool) { ... }
function isApprovedOrOwner(address spender, uint256 assetId) {...}
// Other ERC721 functions for compliance }
❷ Hash tables for managing tokens
❸ Events indexed and recorded on blocks
❹ ERC721 functions used by RES4
❺ RES4 Dapp-specific functions
Follow the model provided by this ERC721-compliant smart contract, and use it as a guideline for implementing any other NFT Dapp. You can reuse the ERC721-based code and add to your application-specific code to this base code.
TransferFrom function
The signature of the transferFrom() function implemented in RES4.sol is slightly different from the one defined in ERC721. It has two parameters--from address and asset id--instead of the three parameters of the same function of ERC721. In the RES4 case, the third parameter is implied and can be obtained from the msg.sender. Instead of a centralized authority or a designated person requesting the transfer, the approved person, or the account buying the asset, requests the transfer. In my opinion, this deviation is justifiable, as it (RES4 version of transferFrom()) implements a decentralized peer-to-peer transfer, with the blockchain acting as an intermediary.
9.2.5 Interaction with RES4 Dapp
The next step is developing the app part of the RES4 in the RES4-app module, which exposes its functions in a web UI. Download RES4-Dapp.zip, unzip it, and review the structure. You’ll deploy it on the local Ganache test chain, where ten accounts with balances are readily available. Following the structure in figure 9.5, locate the various parts of the Dapp. Then run the following steps to explore the workings of the RES4 token:
-
Start the Ganache test chain by clicking Quickstart. Copy the mnemonics at the top of the Ganache GUI. Link MetaMask to Ganache, using the mnemonics copied from the Ganache interface.
-
Assume that the town supervisor and assessor represent the identity of the town and represented by the address of Account1.
-
Deploy the RES4 token from the RES4-contract directory. Navigate to RES4-contract, and issue the Truffle command to deploy the smart contracts. By default, the first account on Ganache will be the deployer and town supervisor:
truffle migrate --reset
-
Deploy the web application from the RES4-app directory:
npm install npm start
You can view the RES4 web interface (figure 9.6) when you access it by using localhost:3000.
-
Move to the MetaMask wallet and link it to the Ganache test chain, using the mnemonics on the Ganache interface.
In MetaMask, reset the accounts for resetting nonce on Account1 through Account4. Click the Account1 icon, and select Settings > Advanced > Reset Account. Repeat this step for Account2, Account 3, and Account4.
-
The web UI in figure 9.6 shows five operations. Before initiating every operation, refresh the browser:
- Add an asset --by the town supervisor, the deployer of the RES4 token
- Assess -- by the town supervisor, the deployer of the RES4 token
- Build --by the owner of the property
- Approve --by the owner of the property
- Buy --by the approved buyer
-
Add a few assets (by town supervisor). Asset numbers are allocated automatically starting at 0. In a production application, the asset IDs will be 256 bits.
From Account1 (town supervisor’s) in MetaMask, add an asset of value 20, choose Account2 as owner, click Add, and confirm.
From Account1 in MetaMask, add an asset of value 30, choose Account3 as owner, click Add, and confirm.
You see the assets added at the bottom of the UI, as shown in figure 9.7.
Assets #0 and #1 are added to the UI, and the owners are Account2 and Account3 respectively. The values of these assets are 20 and 30 as specified when they were allocated (created) by the town supervisor (Account1).
Figure 9.7 RES4 interface after addition of two assets #0, #1, values 20 and 30 for two different owners
-
Build on the asset (by owner) increases the value of the asset. Reload (refresh) the browser, and move to Account2 in MetaMask. In the Build interface, enter the asset ID as
0and the build value as5, click Build, and confirmYou see that the value of asset #0 has increased to 25, as shown in figure 9.8.
Figure 9.8 RES4 interface with asset #0 after building and increasing its value by 5 ETH
-
Approve sale to a couple of people (two addresses), and clear one of them. Refresh the browser before you begin this operation.
In Account2 in MetaMask, enter asset ID as
0and address asAccount3,click Approve (sale to Account3), and confirm.Still in Account2, enter asset ID as
0and address asAccount3, click Clear (withdraw approval sale to Account3), and confirm.Still in Account2, enter asset ID as
0and address asAccount4, click Approve (sale to Account4), and confirm.You’ll see the screen shown in figure 9.9.
-
An approved address buys an asset (transfer occurs).
From Account4 (an approved account), enter the asset ID as
0and the Account2 address as From in theBuyinterface; then click Buy, and confirm.Asset #0’s ownership is changed to the address of Account4, as shown in figure 9.10.
Figure 9.10 Asset #0 transferred to Account4
You can also review the account balances, as shown in figure 9.11 and also in the Ganache UI. The Ganache UI shows the balances of all the accounts involved in the transactions, with the appropriate values added and deducted from the respective accounts. Figure 9.11 shows Account4, whose balance has gone down from 100 ETH to 73 ETH after buying the asset #0 and paying for the Txs. As shown in the middle of figure 9.11, Account2’s balance is about 118--an increase from the initial balance of 100 ETH because it incurred fees for selling asset #0 and the transaction fees. On the right side of figure 9.11 are logs of some of the transactions discussed earlier, displayed in MetaMask’s history of transactions. The balances you observe may be slightly different for you, depending on other transactions that you may have tried. Don’t hesitate to explore beyond the instructions given in these steps.
Figure 9.11 Account balances for Account4 and Account2, and a trace of operations
Note Some of the screenshots may be blurry. If you follow along with your deployment of RES4, you should be able to see a clear picture of these outcomes in your UI. I urge you to try the operations on your own, using the instructions given here as a guideline.
-
Here is a situation in which an unapproved account tries to buy an asset.
Enter Account3 in the Buy operation’s interface, select asset 1, and click Buy. MetaMask will throw a transaction error because the contract reverted at the smart contract level. This error message is displayed in the MetaMask pop-up window, shown in figure 9.12.
-
From Assess interface, assessor assesses the value of a property (that appreciated).
From Account1 in MetaMask (the town supervisor and assessor use the identity of the town), enter the asset ID as
1and the appreciated value as5, click the Appreciated button, and confirm. -
From Assess interface, assessor assesses the value of a property (that depreciated).
From Account1 on MetaMask (the town supervisor and assessor use the identity of the town), enter the asset ID as
0and the depreciated value as5, click the Depreciated button, and confirm.You should see the value of asset ID 0 decreased by 5 ETH.
The asset values after the assessment are shown in figure 9.13.
Figure 9.13 Asset #0 depreciated by 5 ETH, Asset #1 appreciated by 5 ETH
-
Add two more assets to Account4 of the same value from Account1 in MetaMask.
From Account1 (town supervisor’s) in MetaMask, add an asset of value 10, choose Account4 as owner, click Add, and confirm.
From Account1 in MetaMask, add an asset of value 10, choose Account4 as owner, click Add, and confirm.
Figure 9.14 Account4 has three different assets (#0,#2,#3): ERC721 tokens
You see the newly added assets in the UI, as shown in figure 9.14. Even though the assets are of equal value, they are not the same. One could be a little red house, and the other could be a piece of land yet to be developed. A RES4 token is not the same as another RES4 token. In this case, Account4 (0x21459...) has three assets, each of which is unique. That is the fundamental characteristic of ERC721, an NFT (non-fungible token).
This exploration with RES4, an ERC721-compliant token, should have revealed a whole new perspective on blockchain and decentralized applications. The NFT is indeed powerful, applying to a wide range of fields: art, collectibles, real estate, financial portfolios, video gaming artifacts, human resources, skills portfolios, and many more. Try to find ERC721-compliant token use in your field of expertise, and implement a token Dapp. The token Dapp is a significant advancement enabled by the cryptocurrency innovation. There are many more application models beyond fungible and non-fungible tokens. Some of them directly address the trust and integrity elements introduced in chapter 3.
9.3 Retrospective
The RES4 ERC721-compliant token implemented in this chapter is a proof of concept for NFT. The RES4 designed and developed here is a minimal implementation. By including a domain expert, you can further build RES4 into a full-fledged real estate token. This design could include rules for governance and local laws, and other such limitations.
The concept of NFT assets has a broad impact on numerous application domains. The models and standards developed based on this concept can enable a whole range of applications, from managing stored value assets to the human resources skills portfolio. It has the potential to bring art collectors, fund managers, and online gamers into the blockchain world, building a rich and diverse ecosystem for blockchain applications.
Consider this: FT can be transferred in any denomination. That is, you can transfer 0.5 ERC20 tokens or even 0.000005 tokens. This characteristic is true of any FT. For most NFT, a partial token transfer is practically impossible and infeasible. Can you transfer 0.5 kitties physically? On the other hand, for NFT, such as a house, you can have partial ownership. Still, one property (house) is not exchangeable with any other house one to one. All these aspects open many exciting opportunities for the ERC721 standard.
ERC20 and ERC721 tokens have opened a new world of opportunities and application models for blockchain technology. These tokens also represent the beginning of many more innovative standards and improvements to enrich the Ethereum ecosystem. As I write this chapter, ERC20 has been updated to ERC777, an improved version. ERC721 is augmented with ERC165, which checks whether the ERC721 token is indeed compliant with the standard.
Other application models are as exciting as the token Dapp. One of them is a decentralized autonomous organization, in which decisions for action items are made autonomously based on facts input and recorded on the blockchain. The decision made, as well as the explanation (reasons) for decisions, can be tracked by examining the distributed ledger that recorded the transactions and relevant state information.
ERC token standards are being proposed for identity, governance, and security. These tokens and EIPs of Ethereum are sure to enable new application models, transform the Dapp ecosystem into mainstream application framework, and propel Dapps as natural systems.
The token application model enhanced by standards has opened enormous opportunities to monetize services and utilities from the energy marketplace (Grid+) to decentralized prediction markets (Augur). Ultimately, broader adoption and monetization possibilities are important for the sustainability of a technology. Blockchain is no exception.
9.4 Best practices
-
Various application models have emerged from the initial cryptocurrency innovation in Bitcoin. Review the different existing application models and standards before designing and developing a Dapp. Existing application models and standards may guide and simplify your design.
-
Standards have been developed to streamline tokens and their features and to enable exchangeability and interoperability. Wherever possible, actively research the existing standards, and make sure that your smart contract design is compliant with the standards.
-
Determine whether public, permissioned, or private membership is appropriate for your Dapp. This important design consideration will determine which blockchain you’ll use. Ethereum and Bitcoin are relevant as public Dapps, for example, whereas the Hyperledger framework is by design permissioned and appropriate for private deployments. For the RES4 token, you need a public blockchain network to offer equal opportunity for anybody to buy and sell real estate.
9.5 Summary
-
Blockchain can not only enable cryptocurrency transfer between unknown decentralized participants, but also empower decentralized participants in applications for robust and transparent asset transfers.
-
The EIP manages continuous improvement to the protocol as well as the application models through its standards.
-
Two types of token models are fungible (FT) and non-fungible tokens (NFT).
-
The FT and NFT token are defined by Ethereum standards ERC20 and ERC721.
-
An NFT token model is suitable for assets such as real estate and collectibles.
-
RES4-Dapp for management of real estate assets is an example of an end-to-end development NFT model.
-
NFT token Dapp methodology includes implementing a standards-compliant smart contract using inheritance feature and an openly available ERC721 interface and other related artifacts for token management.
-
The non-fungible token is a disruptive application model covering diverse domains, from collectible assets to financial portfolios.
-
This chapter takes a significant step toward advancing blockchain applications from cryptocurrencies to cryptoassets.