Account Nonce Value
Nonce is an abbreviation of Number Used Once or Number Once. A nonce, in information technology, is a number generated for a specific use, such as session authentication. Typically, a nonce is some value that varies with time, although a very large random number is sometimes used. In general usage, nonce means “for the immediate occasion” or “for now.” In the case of Blockchain Proof of Work scenarios,the hash value, found by a Miner, matching the network’s Difficulty thus proving the Block Validity is called Nonce as well. In BuChain, Account Nonce Value is used to identify the order in which the transaction is executed when the user submits the transaction.
In the BUMO project, the keypair is the interface that generates the
public key, private key, address, and signature. Only the
signature algorithm is supported during the signing process.
Raw Private Key
A Raw Private Key is a byte array obtained by a random algorithm. A Raw Private Key is a prerequisite for generating a private key.
Raw Public Key
A Raw Public Key is a byte array generated by processing the raw
private key with the
ED25519 algorithm. A Raw Public Key is a
prerequisite for generating a public key.
A private key is a piece of code generated in asymmetric-key encryption process by the algorithm. It is known only to the owner, and is paired with a public key to set off algorithms for text encryption and decryption. The private key is a prerequisite for generating the public key and the address, and is also the basic element for completing the signature. The private key cannot be changed after it is generated. Once it is lost, it cannot be retrieved, so it needs to be kept safely.
A string of characters derived from a private key that can be made public. The public key can be used to verify the authenticity of any signature created using the private key. It does not expose the private key when transmitted between networks. It is also a necessary condition for generating an address.
An address is a place where cryptocurrency can be sent to and from, in the form of a string of letters and numbers. A cryptocurrency address can be shared publicly in the form of text or QR code to those who want to send you cryptocurrency. Similar to real-life addresses, contacts cannot be found without an address, so without addresses transactions cannot be completed.
A Signature refers to the process of encrypting and confirming transaction data by algorithm and private key and obtaining signature data. The user can verify the integrity and correctness of the transaction data through the signature data.
A transaction is the act of exchanging cryptocurrencies on a blockchain. In BuChain, all operations that modify blockchain data are called transactions, such as issuing assets, transferring assets, sending BUs, creating accounts, setting metadata and setting permissions, etc.
A Transaction Blob is a hexadecimal string obtained by serializing a transaction object. Transaction serialization refers to the process of converting the state information of a transaction object into a string that can be stored and transmitted through the ProtoBuf data structure.
BuChain Operation refers to writing data to or modifying data on BuChain.
Transaction Submission refers to sending a request to write data to or modify data on BuChain.
BuChain Query refers to querying data in the BU blockchain.
Account Services provide account validity checking and query interfaces.
Asset Services provide asset-related query interfaces that follow the ATP 1.0 protocol.
Contract Services provide a contract-related validity checking and query interfaces.
Transaction Services provide a build transaction Blob interface, a signature interface, a query and a submit transaction interface.
Block Services provide an interface to query the block.
Serialization is used in many cases. For example, when we sign a transaction, we can only sign the byte string. In this case, we need to serialize the transaction into a byte string. In addition, we need to store the transaction and serialize it into a byte stream to store it. We chose Google's Protocol Buffer 3 for serialization. Therefore, all of our data structures are defined using Protocol Buffer 3. The advantages of Protocol Buffer 3 are fast at speed, small in size and supportive of multiple languages. We use SerializeAsString to represent the serialization operation of a protocol buffer object.
In the asymmetric signature system, there are private and public keys. It works by randomly generating a public-private key pair according to the algorithm. The private key (skey) is kept by the user, and the public key (pkey) is made public. When you sign a signature, signature = sign (skey, message). When you conduct a verification, validate whether Verify (pkey, signature, Message) is true or false. So why do not use pkey as the unique identifier for the user? Because the length of pkey is not fixed. For a certain elliptic curve family algorithm, pkey is generally 64 bytes in length, and the length of pkey in RSA system is several hundred bytes, which is inconvenient for users to view and save. In order to be compatible with a variety of signature algorithms and fixed length, we hash the public key and add some other flag bits to generate the account address. It is a 36-byte string derived from the public key and is the unique identifier of the account.
A block consists of 2 major parts, the block header (LedgerHeader) and the transactions (transaction_envs).
An asset is a digital certificate issued by an account.
The BU token is a native token built into BuChain and is used to pay for network transaction costs and operation and maintenance of the blockchain network. After BuChain was started, 1 billion BUs were generated when the genesis account was created. In addition to those native tokens, each time a new block is generated, a certain amount of BU tokens will be generated to reward the consensus nodes participating in the block packaging. Each time the BU tokens for each block generation and fees paid for the transactions in the block will be evenly distributed to all the consensus nodes packaging the block, and the modulo balance is randomly rewarded to a consensus node. The total amount of block rewards is 500 million. In the initial stage, 8 BUs are rewarded for each block generation. In the future, the number of BU tokens for generating a block will be attenuated by 1/4 every five years. After 360 years, 500 million BU coins will be fully rewarded.
The account is the main body of BuChain and is a mapping of legal or natural persons in the real world.
By a broad definition, a transaction is a combination of a series of operations to an account.
The operation is the specific action attached to the transaction, changing the atomic unit of the account. A transaction contains one or more operations.
The account is the main body of the transaction, and all transactions must be initiated through the account. Therefore, you must first create an account before performing other operations. The account creation operation is executed by other existing accounts. The first account is generated when BuChain is started, and it is also a genesis account.
Any account can create its own assets by performing an asset issuance operation.
By transferring assets, you can transfer the assets in the source account to the destination address.
Metadata is a database of key-value pairs with versions. Each of its key-value pairs has a version number. Whenever this data is modified, the version number is automatically incremented by 1.
Set the weight of the account owner and signer of the source account.
Set the threshold for each operation in the source account. If the weight of an operation in the transaction does not reach the threshold of the operation, the operation will be rejected.
Transaction Cache Queue
After a node in the blockchain network receiving a transaction request, it fist checks the legality of the transaction. If the transaction is legal, the transaction request is broadcast to other nodes and the request is added to the transaction cache queue.
The system relies on a timer to initiate a consensus every 10s to package transactions for generating a new block. When a node packaging transactions, no more than 4M bytes are fetched in order from the head of the transaction cache queue. If there is a situation where the sequence of source account is broken, all the transactions requested by the source account will be skipped from the broken point, and the broken point of the source account will be marked, and the subsequent blocks will not package the transactions in the source account until the broken point is completed. The transactions for the source account will be packaged until the break is completed, or the transactions are deleted from the cache queue as they time out.
A peer-to-peer networking (P2P) is a distributed application architecture that distributes tasks and workloads between peers. It is a peer-to-peer computing model formed at the application layer as an Ad Hoc network or networking. Participants in this network are both providers of resources, services, and content, as well as recipients of resources, services, and content.
Broadcast and Multicast
When we define the message type, we can divide the message into broadcast messages and unicast messages according to the way the messages are transmitted. Broadcasting is a multi-drop delivery method that delivers a copy of a packet to each destination. Unicasting refers to the delivery of datagrams with only one destination.
In BuChain P2P network, assuming there are four nodes, a unicast message means that node A receives a message from node B and does not propagate to C and D.
Consensus Node Selection
In order to ensure the stability and growth of the entire blockchain network, BuChain enables you to select verification nodes. In this way, the discovered evil verification nodes can be excluded from the consensus node group, and the node with higher performance can be elected to join the verification node group.
All operations in the same transaction, either all succeed or all fail, which is called the atomicity or transactional nature of the transaction.
The user must pay the transaction fees to send the transaction request to cover the cost of depreciation, power, operation and maintenance of the computer equipment in the blockchain network. In BuChain, transaction fees can be assessed before the transaction, and the assessment does not charge any fees, so that users can reasonably provide transaction costs according to their own circumstances. In addition, the cost standard can also be modified according to actual needs.
The basic fee check does not guarantee that the transaction fee paid is sufficient, because the basic fee check does not include the cost of the contract-triggered transaction. Therefore, in order to ensure that the transaction cost is sufficient, the user can first call the fee evaluation interface to evaluate the fee. BuChain provides an http interface named TestTransaction for users to evaluate transaction fees. The cost assessment will actually execute the transaction in a fully simulated environment and calculate the actual transaction cost based on the execution of the transaction.
In the real blockchain network, it may be necessary to adjust the transaction costs according to actual conditions. For example, in the case where the operation cost of the consensus node is fixed, the transaction volume of the entire network continues to increase, and the cost per transaction is diluted. At this time, a network-wide consensus mechanism is needed to adjust the transaction fee. Therefore, BuChain needs to provide a fee election mechanism. When the blockchain is initiated, a contract account to select a fee scheme is created.
The idea of smart contracts was put forward by Nick Sabo in the 1990s, but because of the lack of a credible execution environment at the time, smart contracts were not applied to the real industry. Since the birth of Bitcoin, people realized that the bottom layer of Bitcoin is inherently capable of providing a credible execution environment for smart contracts, but Bitcoin's support for smart contracts is only at the level of simple scripting, and is not Turing complete, so smart contracts cannot be used in Bitcoin for commercial application.
In BuChain system, the BuVM virtual machine provides platform-level support for the execution of smart contracts. The language of the smart contract is Turing complete, and developers can develop a business-level smart contract using the language provided by the platform. The smart contracts of BuVM are stored on the blockchain and distributed on each node machine. The user triggers the execution of the contract script through the transaction, and writes the result of the execution into the blockchain, and guarantees all the data is consistent through the underlying consensus.
The contract is determined when the account is created. In the account creation operation, the contract content of the created account is determined. It is not allowed to modify the contract code after the contract is created.
When a contract account receives assets transferred by other accounts, it will be triggered.
In the BUMO system, the contract is an attribute of the account, defined in the contract field of
In the design of the smart contract module, we provide a sandbox environment for debugging contracts, and the state of the blockchain and contract will not be changed during debugging. The smart contract can be debugged through the HTTP interface callContract. The smart contract can be an existed one on the public chain or contract code uploaded with parameters. The transaction is generated by using the callContract interface, so there is no need to pay the transaction fee.