Network Protocol

Kaze adopts a P2P network structure, in which nodes can communicate with each other through TCP/IP protocol. In this structure, there are two different types of nodes: peer nodes and validating nodes (referred to as Bookkeepers in the Kaze Whitepaper). Peer nodes can broadcast, receive and transfer transactions or blocks, while validating node can create blocks.

The network protocol of Kaze is roughly similar to bitcoin’s, however, data structures such as blocks or transactions are quite different.

Convention

  1. Byte OrderAll integer types of Kaze are Little Endian except for IP address and port number, these 2 are Big Endian.
  2. HashTwo different hash functions are used in Kaze: SHA256 and RIPEMD160. SHA256 is used to generate a long hash value, and RIPEMD160 is used to generate a short hash value. In general, we get an object's hash value by using hash function twice. For example, we use SHA256 twice when we want to generate block's or transaction's hash value. When generating a contract address, we will use SHA256 function first and then use RIPEMD160. In addition, the block will also use a hash structure called a Merkle Tree. It computes the hash of each transaction and combines one another then hash again, repeats this process until there is only one root hash (Merkle Root).
  3. Variable Length TypeVariant: Variable length integer, can be encoded to save space according to the value typed.

Varstr: Variable length string, consisting of variable length integer followed by strings. String encoded by UTF8.

Array: The array consists of a variable length integer followed by a sequence of elements.

4. Fixed-point NumberData in Kaze such as amount or price are 64 bit fixed-point number and the precision of decimal part is 10-8,range:[-263/108, +263/108)

Data Type

  1. BlockchainThe blockchain is a kind of logical structure, which is connected in series with a one-way linked list. It is used to store the data of the whole network, such as transactions or assets.
  2. Block

When calculating the hash value of the block, instead of calculating the entire block, only first seven fields in the block head will be calculated, which are version, PrevBlock, MerkleRoot, timestamp, and height, the nonce, NextMiner. Since MerkleRoot already contains the hash value of all transactions, the modification of transaction will influence the hash value of the block.Data structure of block head:

The time-stamp of each block must be later than previous block's time stamp. Generally the difference of two block's time stamp is about 15 seconds and imprecision is allowed. The height of the block must be exactly equal to the height of the previous block plus 1.

3. Transaction

All processes in Kaze system are recorded as transactions. There are several types of transactions:

Each type of transaction, in addition to the public field, also has its own exclusive field. The following will describe these exclusive fields in detail.

MinerTransaction

The first transaction in each block must be MinerTransaction. It is used to reward all transaction fees of the current block to the validator.

Random number in the transaction is used to avoid hash collision.

IssueTransaction

There are no special fields for an issue transaction.

Asset managers can create the assets that have been registered in Kaze blockchain through IssueTransaction, and sent them to any address.

In particular, if the assets which being issued are Kaze, then the transaction will be sent free.

Random number in the transaction is used to avoid hash collision.

ClaimTransaction

EnrollmentTransaction

The transaction represents an enrollment form, which indicates that the sponsor of the transaction would like to sign up as a validator.

The way to sign up is: To construct an EnrollmentTransaction type of transaction, and send a deposit to the address of the PublicKey.

The way to cancel the registration is: Spend the deposit on the address of the PublicKey.

  • RegisterTransaction

WARNING
Has been deactived and replaced by Kaze .Asset.Create for the smart contract.View Alternative .NET Smart Contract FrameworkView Alternative Smart Contract API

  • ContractTransaction

There are no special attributes for a contract transaction. This is a very common kind of transaction as it allows one wallet to send Kaze to another. The inputs and outputs transaction fields will usually be important for this transaction (for example, to govern how much Kaze will be sent, and to what address).

  • PublishTransaction

WARNING
Has been deactivated and replaced by Kaze.Contract.Create for the smart contract.

View Alternative .NET Smart Contract Framework
View Alternative Smart Contract API

  • Invoking a Transaction

4. Transaction Attributes

Sometimes the transaction will contain some data for external use, these data will be placed in the transaction attributes field.

Each transaction attribute has different usages:

For ContractHash, ECDH series, Hash series, data length is fixed to 32 bytes and length field is omitted;

For CertUrl, DescriptionUrl, Description, Remark series, the data length must be clearly defined, and the length should not exceed 255;

5. Input Transaction

6. Output of Transaction

Each transaction can have outputs up to 65536.

7. Validation Script

Stack script can only be used for the PUSH operations, which is used to push data like signatures into the stack. The script interpreter will execute the stack script code first, and then execute the contract script code. 

In a transaction, the hash value of the contract script code must be consistent with the transaction output, which is part of the validation. The later section will describe the execution process of the script in detail.

Network Message

All network messages are sent in this structure:

Defined Magic value:

Command is utf8 code, of which the length is 12 bytes, the extra part is filled with 0.

Checksum is the first 4 bytes of the value that two times SHA256 hash of the Payload.

According to different orders Payload has different detailed format, see below:

  1. version

When a node receives a connection request, it declares its version immediately. There will be no other communication until both sides are getting versions of each other.

  1. verackWhen a node receives the version message, it replies with a verack immediately.This message has no payload.
  2. getaddrMake requests to a node for a batch of new active nodes in order to increase the number of connections.This message has no payload.
  3. addr

After receiving the getaddr message, the node returns an addr message as response and provides information about the known nodes on the network.

4. getheaders

Make requests to a node for at most 2000 blocks’ header packages that contain HashStart to HashStop. To get the block hash after that, you need to resend the getheaders message. This message is used to quickly download the blockchain which does not contain the transactions.

5. headers

After receiving the getheaders message, the node returns a header message as response and provides information about the known nodes on the network.

6. getblocks

Make requests to a node for inv message which starts from HashStart to HashStop. The number of blocks which starts from HashStart to HashStop is up to 500. If you want to get block hash more than that, you need to resend getblocks message.

7. inv

The node can broadcast the object information it owns by this message. The message can be sent automatically or can be used to answer getblocks messages.

Object information is included in the list:

Object types:

8. getdata

To request a specified object from a node: It is usually sent after the inv packet is received and the known element removed.

9. block

Sending a block to a node, to respond to the getdata message.

10. tx

Sending a transaction to a node, to respond to the getdata message.

Did this answer your question?