Get desktop application:
View/edit binary Protocol Buffers messages
* Event Consensus Data.<br/> This message records the critical values produced by consensus for an event.
* A consensus timestamp.<br/> The network's consensus agreement on a timestamp for this event. <p> This timestamp MUST be strictly greater than the `consensus_timestamp` of the previous consensus event.<br/> This is a consensus value and MAY NOT match real-world "wall clock" time.
* A consensus order sequence number.<br/> A non-negative sequence number that identifies an event's consensus order since genesis. <p> This SHALL be the unique for each consensus event.<br/> This SHALL always increase, and SHALL NOT decrease.<br/> This SHALL increment by one for each consensus event.
* Contains information about an event and its parents.
Used in:
* The creator node identifier.<br/> This SHALL be the unique identifier for the node that created the event.<br/> This SHALL match the ID of the node as it appears in the address book.
* The birth round of the event.<br/> The birth round SHALL be the pending consensus round at the time the event is created.<br/> The pending consensus round SHALL be **one greater** than the latest round to reach consensus.
* The wall clock time at which the event was created, according to the node creating the event.<br/> If the event has a self parent, this timestamp MUST be strictly greater than the `time_created` of the self parent.
* A list of EventDescriptors representing the parents of this event.<br/> The list of parents SHALL include zero or one self parents, and zero or more other parents.<br/> The first element of the list SHALL be the self parent, if one exists.<br/> The list of parents SHALL NOT include more than one parent from the same creator.
* The event specification version.<br/> The specification described by this version SHALL encompass the format of the `GossipEvent` message, and also the format of all contained messages.<br/> This SHALL exactly match the specification version passed into the platform at construction.
This field is temporary until birth_round migration is complete. Field number 17 chosen to avoid polluting cheaper 1 byte field numbers 1-16
* Unique identifier for an event.
Used in:
* The hash of the event.<br/> The hash SHALL be a SHA-384 hash.<br/> The hash SHALL have the following inputs, in the specified order:<br/> 1. The bytes of the `EventCore` protobuf<br/> 2. The SHA-384 hash of each individual `EventTransaction`, in the order the transactions appear in the `event_transactions` field of the `GossipEvent` protobuf
* The creator node identifier.<br/> This SHALL be the unique identifier for the node that created the event.<br/> This SHALL match the ID of the node as it appears in the address book.
* The birth round of the event.<br/> The birth round SHALL be the pending consensus round at the time the event is created.<br/> The pending consensus round SHALL be **one greater** than the latest round to reach consensus.
* The generation of the event.<br/> This value SHALL be **one greater** than the _maximum_ generation of all parents.<br/>
This field is temporary until birth_round migration is complete. Field number 17 chosen to avoid polluting cheaper 1 byte field numbers 1-16
* An Event Transaction gossiped between nodes as part of events. Each node MUST extract this transaction and process according to the type of transaction encoded.<br/> Both the platform and the application built on that platform MAY define event transactions.<br/> The encoded data MUST be a serialized protobuf message.
Used in:
* An application transaction. <p> The contents of this transaction SHALL be defined by the application subsystem that created the event.<br/> The contents MUST be a serialized protobuf message.
* A state signature. <p> This transaction SHALL be a valid state signature for a state snapshot.
* An event that is sent and received via gossip
* The core event data
* A node signature on the event hash.<br/> The signature SHALL be created with the SHA384withRSA algorithm.<br/> The signature MUST verify using the public key belonging to the `event_creator`.<br/> The `event_creator` public key SHALL be read from the address book that corresponds to the event's birth round.<br/> The signed event hash SHALL be a SHA-384 hash.<br/> The signed event hash SHALL have the following inputs, in the specified order:<br/> 1. The bytes of the `event_core` field<br/> 2. The SHA-384 hash of each individual `EventTransaction`, in the order the transaction appear in the `event_transaction` field
* The event transaction. <p> This field MAY contain zero transactions.<br/> This field MUST NOT exceed `maxTransactionCountPerEvent` entries, initially `245760`.<br/> This total size of this field MUST NOT exceed `maxTransactionBytesPerEvent`, initially `245760` bytes.<br/> Deprecated in favor of the `transaction` field. The idea is to clean the design of event transactions.<br/> This is transitional state until 'transaction' field is fully adopted.
* A list of serialized transactions. <p> This field MAY contain zero transactions.<br/> Each transaction in this list SHALL be presented exactly as it was supplied to the consensus algorithm.<br/> This field MUST contain one entry for each transaction included in this gossip event.
* An signature of a state snapshot gossiped to other nodes. Each node SHALL hash the root of the merkle tree of a state snapshot every round. Once this hash is calculated, it SHOULD be signed with the nodes private signing key. This signature, together with the hash SHOULD be added to an event as a StateSignatureTransaction.
Used in:
,* The round number corresponding to the round number of the state snapshot being signed.<br/> This number MUST be greater than 0.
* The signature of state snapshot hash.<br/> This signature MUST be a RSA signature with a maximum length of 384 bytes.<br/> The signature algorithm used MUST be RSASSA-PKCS1-v1_5 with SHA-384.
* The hash of the state snapshot being signed.<br/> This hash MUST be a SHA-384 hash.