-
Notifications
You must be signed in to change notification settings - Fork 1
Block
Wouter den Bakker edited this page Oct 23, 2018
·
2 revisions
Block format and order when signing a block, transmitting it between nodes and how it is stored in the database:
| Name | Signing | Transmission | Database (type) | Description |
|---|---|---|---|---|
| prefix | ✓ | ✗ | ✗ | variable length. A unique prefix to ensure a block of another Validana instance is not valid in this instance. |
| total_length | ✗ | ✓ | ✗ | 4 bytes little endian unsigned int. Indicates the length of what is to follow. This because a block has variable length. |
| version | ✓ | ✓ | ✓ (smallint) | 1 byte unsigned int indicating the version, currently only version 1 exists. |
| block_id | ✓ | ✓ | ✓ (bitint) | 8 bytes little endian unsigned int. Indicates the id of this block. |
| previous_block_hash | ✓ | ✓ | ✓ (bytea) | 32 bytes. Indicated the previous block hash. |
| processed_ts | ✓ | ✓ | ✓ (bigint) | 8 bytes little endian unsigned int. At what time this block was processed. |
| transactions | ✓ | ✓ | ✓ (bytea) | variable length. A list of transaction in this block (in their transmission format.) |
| signature | ✗ | ✓ | ✓ (bytea) | 64 bytes, the ec signature of the block, 32 bytes r followed by 32 bytes s. |
The block hash is created using double sha256 of the prefix, version, block_id, previous_block_hash, processed_ts and transactions of the block (concatenated in that order). This is then signed using the ECDSA Algorithm using the secp256k1 curve.
When a block is transmitted the first 4 bytes indicate the total length of the remainder, which consists of the version, block_id, previous_block_hash, processed_ts, transactions and signature (concatenated in that order). No public key is transmitted as it will always be the same.