Skip to main contentEvery state change in OpenGDP begins with a transaction. Its journey from creation to final inclusion in a block can be understood in three stages:
1. From User to Mempool
- Creation and Signing: A user creates a transaction specifying recipient, value, and gas parameters, then signs it with their private key. The signature proves ownership and intent. OpenGDP supports multiple signing methods, described in the Cryptography section.
- Broadcast: The signed transaction is submitted to an OpenGDP node through an RPC endpoint.
- Validation: The receiving node verifies the transaction before adding it to its mempool. Checks include basic transaction validation, signature validity, sufficient balance for gas, and a correct nonce. This prevents invalid or spam transactions from propagating.
- Gossip: Once accepted, the transaction is gossiped to peers and quickly propagates across the network, entering other nodes’ mempools.
2. From Mempool to Block
- Selection: At each block height, a proposer is chosen. It selects transactions from its mempool, typically by priority based on gas price.
- Proposal: The proposer creates a lean block proposal containing only ordered transaction hashes, as described in Accelerated Finality.
- Broadcast: The proposal is sent to all validators for review.
3. Reaching Finality
- Reconstruction and Execution: Validators get the block, then execute the transactions in the block to compute the state root.
- Voting: Validators cast a positive vote if the block is valid. After a block is accepted by more than ⅔ of total consensus power, the validator commits the block
- Finalization: After committing, the block gets finalized. Transactions become permanent, the state root is committed to disk, and the block is added to the canonical chain.
