GBC Mechanism

GOLDEN BLOCK
3 min readMar 28, 2022

--

The GBC token was created according to the design shown in Figure above. The GBC token implies a variety of Contract Algorithm, which operates various functions through the role and interaction of the item of each element.

8.1 Solidity
The GBC smart contract was written in Solidity. The ERC20 standard of GBC complies with the standard protocol EIP Protocol to be implemented by all ERC20 tokens to allow integration with other contracts and defines the source code accordingly. You can refer to the example code below.

function totalSupply() public view returns (uint256);
function balanceOf(address tokenOwner) public view returns (uint);
function allowance(address tokenOwner, address spender)
public view returns (uint);
function transfer(address to, uint tokens) public returns (bool);
function approve(address spender, uint tokens) public returns (bool);
function transferFrom(address from, address to, uint tokens) public returns (bool);

The above ERC features of the GBC allow external users (e.g., Encryption Wallet App) to check their balances and transfer funds between users with appropriate privileges. The code below defines two events.

These events are given authorization to withdraw GBC tokens from the account, and are called or originated after the GBC token is actually sent. In addition to the standard ERC20 feature, many ERC20 tokens also have additional fields as follows.

Therefore, the basic structure of the GBC token is as follows.

8.2 ERC20
This explains the logic design of the GBC token. First, we need to define two mapping objects. This is the concept of Solidity for association or key/value arrays. mapping(address => uint256) balances;

mapping(address => mapping (address => uint256)) allowed;
This expression mapping (address = > uint256) defines associative array (this is a 256-bit integer typically used to store token balances) in which the key is the numeric type used to represent the address accounting address and the value is the type.

- The first mapping object, which is balances, holds the token balance of each owner account.
- The second mapping object, which is allowed, includes all accounts authorized to withdraw from the specified account and the total withdrawal allowed for each.

The value field of the allowed mapping is mapping plotting account address for the accepted withdrawal total by itself. Together with all other contract fields, these mappings are stored and mined in blockchain, propagating changes to all network user nodes. Blockchain storage is expensive and the contractor has to pay in some way. Therefore, storage size should always
be minimized and written to blockchain. Here, the additional SafeMath function exists to prevent hacking and to deal with the overflow attack problem of malicious smart contracts.

--

--