Post Transaction - zoobc/zoobc-core GitHub Wiki

Submitting action to zoobc core node can be done by posting transaction, depending on the transaction type user take various actions.Posting transaction to zoobc node is defined with the proto definition as follow:

common/model/transaction.proto

message PostTransactionRequest {
    // Signed transaction bytes
    bytes TransactionBytes = 1;
}

and

common/service/transaction.proto

rpc PostTransaction(model.PostTransactionRequest) returns (model.PostTransactionResponse) {}

The above define from client side we'll have to submit a request including TransactionBytes which is array of byte that represent the transaction we want to submit.

Submitted transaction bytes must be signed by the sender private key before submitting to the node, or it won't pass the validation step when we submit the transaction.

  • Structure

    The transaction is structured as:

    • Transaction Header

      The common structure that's the same across different transaction including escrow headers.

    • Transaction Body

      A specific sets of field that is attached depending on the different type of transaction.

    • Transaction Signature

      Transaction signature that resulted from signing the hash of transaction with the account private key. The signature algorithm we use is according to one of the siganture type that available on zoobc. In order to validate the transaction signature, the siganture type that used on each transaction should be identified by account type of the sender account address

      The general requirement when generate the transaction:

  • Transaction Structure:

No Field Type Field Type
1 version INTEGER Version uint32
2 id (pk) INTEGER ID int64
3 block_id INTEGER BlockID int64
4 block_height INTEGER Height uint32
5 sender_account_address BLOB SenderAccount []byte
6 recipient_account_address BLOB RecipientAccount []byte
7 transaction_type INTEGER TransactionType uint32
8 fee INTEGER Fee int64
9 timestamp INTEGER Timestamp int64
10 transaction_hash BLOB TransactionHash []byte
11 transaction_body_length INTEGER TransactionBodyLength uint32
12 transaction_body_bytes BLOB TransactionBodyBytes []byte
13 signature BLOB Signature []byte
14 (protobuf only) TransactionBody TransactionBody
15 transaction_index INTEGER TransactionIndex uint32
16 (protobuf only) Escrow Escrow

  • Transaction Bytes

No Field Size Type
1 TransactionType 4 unt32
2 Version 1 int8
3 Timestamp 8 int64
4 SenderAccountAddress variable, default(36) * bytes
5 RecipientAccountAddress variable, default(4) ** bytes
6 TransactionFee 8 int64
7 TransactionBodyLength 4 uint32
8 TransactionBodyBytes {TransactionBodyLength} bytes
9 SignatureType 4 bytes / uint32
10 ApproverAddress default(4) bytes
11 Commission default(0) int64
12 Timeout default(0) int64
13 InstructionLength 4 uint32
14 Instruction default(0) string
15 Signature variable *** bytes

*: 36 bytes is the full length of a ZooBC account type (4 bytes for account type = 0 and 36 bytes for account public key). for others, check the account type to get the right length of account public key. note: sender account can never be empty (see below) **: for empty account type. empty account type is a special account that only has first 4 bytes (account type) = 2 and a 0 length (empty) account public key ***: signature length depends on SenderAccountAddress type

On success posting the transaction, node will response with the transaction object extracted from the transaction bytes.

  • General Validation

    There are general rules that every transaction must abide:

    • Transaction bytes must be parseable by core-node.
    • Transaction height is not be zero.
    • Transaction fee is more than zero.
    • Transaction sender field cannot be empty.
    • Transaction sender must already be recorded in account_balance table.
    • Sender spendable balance must be more than the total of the transaction fee and its additional amount if exists.
    • Provided signature must be able to be validated against the sender public key.