Platform
Blocks: Distinctive Characteristics
Each block that is secured to Telcoin Network can be distinguished between and identified based on distinctive characteristics including the author, the block number, and a variety of other attributes.
| Distinctive characteristics | Description |
|---|---|
| Author The validator who proposed the block. | Each block includes the validator who produced the block. |
| Block Number The current number of blocks that have been committed to the blockchain. | Each block is assigned a number after it’s added to the blockchain. The genesis block starts at 0, and each block adds +1 to this number. |
| Transactions The list of transactions in the block. | Each block stores unique transaction information based on the interactions with the network at that time by accounts. |
| Parent Hash The hash of the preceeding block. | The parent hash of a block is required to ensure the block number is correct. Validators ensure they have the parent block before trying to verify the proposed block. |
| Block Hash The hash of this block. | The contents of a block are hashed using one-way encryption so other validators can independently verify the contents of a block haven’t changed. |
| Gas Limit The maximum amount of gas allowed in the block. | Blocks have a maximum amount of gas to prevent network failure. |
| Gas Used The maximum amount of total gas used by all transactions within the block. | The amount of gas used in a block affects the next block’s base fee. |
| Extra Data Arbitrary data included with this block. | The field is limited to 8-bytes max. |
| Base Fee Per Gas The base fee for transactions within this block. | The base fee is managed by the Telcoin Network’s protocol automatically based on how much of the previous block’s gas limit was used. Validators and end-users have no control over the value. Instead, the base fee is increased or decreased based on network demand. |
| Withdrawals A list of withdrawal objects | At some point in the future, validators may wish to withdraw some of the harvested TEL. This field would include that information and remove TEL from the staking contract and into a validator’s wallet. |
| Prev Randao The value used to randomly select the validator that proposed this block. | The hash of the block’s parent certificates. This value is subject to change as the protocol matures. |
| Receipts Root The hash of the transaction receipts trie. | All transactions executed in the block produce receipts, which are stored in a trie data structure. The final state of the trie is hashed so other validators can independently verify the receipts produced by the block’s transactions. |
| State Root The root hash for global state after executing all transactions within a block. | State is also stored in a trie data structure. The hash of this root is included in the block so other validators can independently verify the global state using a one-way hashing function, SHA-256. |
| Logs Bloom An optimization for applications to quickly find relevant blocks based on transaction events. | The logs from contracts are added to a bloom filter and included in the block’s header to reduce the amount of space taken on the blockchain. Users who are interested in a particular log can find it by searching these blooms and then replaying a particular block of interest to recreate the log itself. |
| Timestamp The moment in time when a block was produced. | The unix timestamp is a valued measured in seconds since January 1, 1970 at UTC. Validators can use this to ensure blocks were created at the correct time. |