Get desktop application:
View/edit binary Protocol Buffers messages
This is finalized block structure to be shared among the orderer and peer Note that the BlockHeader chains to the previous BlockHeader, and the BlockData hash is embedded in the BlockHeader. This makes it natural and obvious that the Data is included in the hash, but the Metadata is not.
Used in:
BlockHeader is the element of the block which forms the block chain The block header is hashed using the configured chain hashing algorithm over the ASN.1 encoding of the BlockHeader
Used in:
The position in the blockchain
The hash of the previous block header
The hash of the BlockData, by MerkleTree
Used in:
This enum enlists indexes of the block metadata array
Block metadata array position for block signatures
Block metadata array position to store last configuration block sequence number
Block metadata array position to store serialized bit array filter of invalid transactions
Block metadata array position to store operational metadata for orderers e.g. For Kafka, this is where we store the last offset written to the local ledger
Block metadata array position to store the hash of TRANSACTIONS_FILTER, State Updates, and the COMMIT_HASH of the previous block
Header is a generic replay prevention and identity message to include in a signed payload
Header types 0-10000 are reserved and defined by HeaderType
Version indicates message protocol version
Timestamp is the local time when the message was created by the sender
Identifier of the channel this message is bound for
An unique identifier that is used end-to-end. - set by higher layers such as end user or SDK - passed to the endorser (which will check for uniqueness) - as the header is passed along unchanged, it will be be retrieved by the committer (uniqueness check here as well) - to be stored in the ledger
The epoch in which this header was generated, where epoch is defined based on block height Epoch in which the response has been generated. This field identifies a logical window of time. A proposal response is accepted by a peer only if two conditions hold: 1. the epoch specified in the message is the current epoch 2. this message has been only seen once during this epoch (i.e. it hasn't been replayed)
Extension that may be attached based on the header type
If mutual TLS is employed, this represents the hash of the client's TLS certificate
Envelope wraps a Payload with a signature so that the message may be authenticated
A marshaled Payload
A signature by the creator specified in the Payload header
Used in:
Used for messages which are signed but opaque
Used for messages which express the channel config
Used for transactions which update the channel config
Used by the SDK to submit endorser based transactions
Used internally by the orderer for management
Used as the type for Envelope messages submitted to instruct the Deliver API to seek
Used for packaging chaincode artifacts for install
LastConfig is the encoded value for the Metadata message which is encoded in the LAST_CONFIGURATION block metadata index
Used in:
Metadata is a common structure to be used to encode block metadata
Used in:
An encoded SignatureHeader
The signature over the concatenation of the Metadata value bytes, signatureHeader, and block header
OrdererBlockMetadata defines metadata that is set by the ordering service.
Payload is the message contents (and header to allow for signing)
Header is included to provide identity and prevent replay
Data, the encoding of which is defined by the type in the header
Creator of the message, a marshaled msp.SerializedIdentity
Arbitrary number that may only be used once. Can be used to detect replay attacks.
These status codes are intended to resemble selected HTTP status codes