Transaction

Transaction format and order when signing a transaction, transmitting it between nodes or client-server and how it is stored in the database:

Name	Signing	Transmission	Database (type)	Description
prefix	✓	✗	✗	variable length. A unique prefix to ensure a transaction of another Validana instance is not valid in this instance. Never stored/transmitted as it is always the same.
total_length	✗	✓	✗	4 bytes little endian unsigned int. Indicates the length of what is to follow. This because a transaction has variable length.
version	✓	✓	✓ (smallint)	1 byte unsigned int indicating the version, currently only version 1 exists.
transaction_id	✓	✓	✓ (bytea)	16 bytes. Unique id, used to identify the transaction and protect against replay attacks.
contract_hash	✓	✓	✓ (bytea)	32 bytes indication what contract this transaction uses.
valid_till	✓	✓	✓ (bigint)	8 bytes little endian unsigned int, till when a transaction is valid, so you know when you can do a new one if the old one isn't added to the blockchain. 0=valid forever.
payload	✓	✓	✓ (json)	variable length UTF8 string. The payload to call the contract with.
signature	✗	✓	✓ (bytea)	64 bytes, the ec signature of the transaction, 32 bytes r followed by 32 bytes s.
public_key	✗	✓	✓	33 bytes. A compressed ec public key.

Signing:

Transactions are signed using ECDSA Algorithm, using the secp256k1 curve and double sha256 as hashing method. The data that is signed is the prefix, version, transaction_id, contract_hash, valid_till and payload (concatenated in that order).

Transmitting:

When a transaction is transmitted the first 4 bytes indicate the total length of the remainder, which consists of the version, transaction_id, contract_hash, valid_till, payload, signature and public_key (concatenated in that order).