diff --git a/block/stream/block_header.proto b/block/stream/block_header.proto index 03eda19b..d63c5d9b 100644 --- a/block/stream/block_header.proto +++ b/block/stream/block_header.proto @@ -44,22 +44,18 @@ import "basic_types.proto"; * and process that block, or stop processing if appropriate.
* The block header MUST describe, at minimum, the following items. * - The version of the block stream data - * - The Hedera API version - * - The Hedera Services version - * - The Hedera Platform version * - The block number * - The hash of the previous block * - The hash algorithm used to generate the block hash - * - The digital signature algorithm used to sign the block hash * - * All fields of this message are REQUIRED, with the exception that the _algorithms_ MAY + * All fields of this message are REQUIRED, with the exception that `hash_algorithm` MAY * be _transmitted_ as a default value to improve data efficiency. */ message BlockHeader { /** * Version of the HAPI specification that was used to serialize the block. */ - proto.SemanticVersion hapi_proto_version = 2; + proto.SemanticVersion hapi_proto_version = 1; /** * The block number of this block.
@@ -68,7 +64,7 @@ message BlockHeader { * in `number` sequence, and MAY assume the block stream has encountered data * loss, data corruption, or unauthorized modification. */ - uint64 number = 5; + uint64 number = 2; /** * The running hash of the previous block.
@@ -79,12 +75,12 @@ message BlockHeader { * does not match the block hash of the previous block and MAY assume the block stream * has encountered data loss, data corruption, or unauthorized modification. */ - bytes start_running_hash = 6; + bytes start_running_hash = 3; /** * The hash algorithm used in this block. */ - BlockHashAlgorithm hash_algorithm = 7; + BlockHashAlgorithm hash_algorithm = 4; } /** @@ -95,5 +91,10 @@ message BlockHeader { * `HASH_ALGORITHM_UNKNOWN` is the default for HashAlgorithm. */ enum BlockHashAlgorithm { + /** + * A SHA2 algorithm SHA-384 hash.
+ * This is the default value, if a field of this enumerated type is not set, then + * this is the value that will be decoded when the serialized message is read. + */ SHA_384 = 0; } diff --git a/block/stream/block_item.proto b/block/stream/block_item.proto index ec006a5b..7e6cb082 100644 --- a/block/stream/block_item.proto +++ b/block/stream/block_item.proto @@ -180,7 +180,7 @@ message BlockItem { */ message FilteredBlockItem { /** - * A SHA384 hash of an item filtered from the stream. + * A SHA-384 hash of an item filtered from the stream. */ bytes item_hash = 1; } diff --git a/block/stream/consensus_service.proto b/block/stream/consensus_service.proto index 4b6d77d0..943fe3b8 100644 --- a/block/stream/consensus_service.proto +++ b/block/stream/consensus_service.proto @@ -3,63 +3,8 @@ * Block stream messages that report the results of transactions handled by the `Consensus` service. * * ### Topic Running Hash Calculation - * Some messages include a topic running hash. This value has changed over time, with the - * known versions listed here. - * - *
- * - * This 48-byte field is the output of a SHA-384 digest with input data determined by the - * value of the `topic_running_hash_version` field.
- * All new transactions SHALL use `topic_running_hash_version` `3`.
- * The bytes of each uint64 or uint32 encoded for the hash input MUST be in Big-Endian format. - * --- - * If the `topic_running_hash_version` is '0' or '1', then the input data to the SHA-384 digest are, - * in order: - * 1. The previous running hash of the topic (48 bytes) - * 1. The topic's shard (8 bytes) - * 1. The topic's realm (8 bytes) - * 1. The topic's number (8 bytes) - * 1. The number of seconds since the epoch when the `ConsensusSubmitMessage` reached - * consensus (8 bytes) - * 1. The number of nanoseconds within the second when the `ConsensusSubmitMessage` reached - * consensus (4 bytes) - * 1. The `topic_sequence_number` field (8 bytes) - * 1. The message bytes from the `ConsensusSubmitMessage` (variable). - * --- - * If the `topic_running_hash_version` is '2', then the input data to the SHA-384 digest are, in - * order: - * 1. The previous running hash of the topic (48 bytes) - * 1. The `topic_running_hash_version` field (8 bytes) - * 1. The topic's shard (8 bytes) - * 1. The topic's realm (8 bytes) - * 1. The topic's number (8 bytes) - * 1. The number of seconds since the epoch when the `ConsensusSubmitMessage` reached - * consensus (8 bytes) - * 1. The number of nanoseconds within the second when the `ConsensusSubmitMessage` reached - * consensus (4 bytes) - * 1. The `topic_sequence_number` field (8 bytes) - * 1. The output of a SHA-384 digest of the message bytes from the `ConsensusSubmitMessage` - * (48 bytes) - * --- - * If the `topic_running_hash_version` is '3', then the input data to the SHA-384 digest - * are, in order: - * 1. The previous running hash of the topic (48 bytes) - * 1. The `topic_running_hash_version` field (8 bytes) - * 1. The payer account's shard (8 bytes) - * 1. The payer account's realm (8 bytes) - * 1. The payer account's number (8 bytes) - * 1. The topic's shard (8 bytes) - * 1. The topic's realm (8 bytes) - * 1. The topic's number (8 bytes) - * 1. The number of seconds since the epoch when the `ConsensusSubmitMessage` reached - * consensus (8 bytes) - * 1. The number of nanoseconds within the second when the `ConsensusSubmitMessage` reached - * consensus (4 bytes) - * 1. The `topic_sequence_number` field (8 bytes) - * 1. The output of a SHA-384 digest of the message bytes from the `ConsensusSubmitMessage` - * (48 bytes) - * - *
+ * Submitted messages include a topic running hash. This value has changed over time, with the + * known versions detailed in the `RunningHashVersion` enumeration. * * ### Keywords * The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", @@ -117,11 +62,92 @@ message DeleteTopicOutput {} * Block Stream data for a `submitMessage` transaction. * * This message SHALL NOT duplicate information already contained in the original transaction. + * The actual topic running hash SHALL be present in a `StateChanges` block item, and is not + * duplicated here.
*/ message SubmitMessageOutput { /** * The version of inputs to the SHA-384 running hash.
- * For all current transactions, this value SHALL be `3`. + * For all current transactions, this value SHALL be `WITH_MESSAGE_DIGEST_AND_PAYER`. + */ + RunningHashVersion topic_running_hash_version = 1; + + /** + * A version of the topic running hash. + * + * The inputs to the topic running hash have changed over time. This is tracked in earlier + * record streams as an integer. For the block stream we chose to use an enumeration for + * both efficiency and clarity. Placing the most recent, and most common/highest volume, + * version as `0` reduces the serialized size of this message by not serializing that + * default value. + * + *
+ * + * The topic running hash is a 48-byte value that is the output of a SHA-384 digest with + * input data determined by the value of the `topic_running_hash_version` field.
+ * All new transactions SHALL use `topic_running_hash_version` + * `WITH_MESSAGE_DIGEST_AND_PAYER`.
*/ - uint64 topic_running_hash_version = 3; + enum RunningHashVersion { + /** + * The most recent version.
+ * This version SHALL include, in order + *
    + *
  1. The previous running hash of the topic (48 bytes)
    2. + *
  2. The `topic_running_hash_version` field (8 bytes)
    3. + *
  3. The payer account's shard (8 bytes)
    4. + *
  4. The payer account's realm (8 bytes)
    5. + *
  5. The payer account's number (8 bytes)
    6. + *
  6. The topic's shard (8 bytes)
    7. + *
  7. The topic's realm (8 bytes)
    8. + *
  8. The topic's number (8 bytes)
    9. + *
  9. The number of seconds since the epoch when the `ConsensusSubmitMessage` reached + * consensus (8 bytes)
    10. + *
  10. The number of nanoseconds within the second when the `ConsensusSubmitMessage` + * reached consensus (4 bytes)
    11. + *
  11. The `topic_sequence_number` field (8 bytes)
    12. + *
  12. The output of a SHA-384 digest of the message bytes from the + * `ConsensusSubmitMessage` (48 bytes)
    13. + *
+ */ + WITH_MESSAGE_DIGEST_AND_PAYER = 0; + + /** + * An earlier version.
+ * This version SHALL include, in order + *
    + *
  1. The previous running hash of the topic (48 bytes)
    2. + *
  2. The `topic_running_hash_version` field (8 bytes)
    3. + *
  3. The topic's shard (8 bytes)
    4. + *
  4. The topic's realm (8 bytes)
    5. + *
  5. The topic's number (8 bytes)
    6. + *
  6. The number of seconds since the epoch when the `ConsensusSubmitMessage` reached + * consensus (8 bytes)
    7. + *
  7. The number of nanoseconds within the second when the `ConsensusSubmitMessage` + * reached consensus (4 bytes)
    8. + *
  8. The `topic_sequence_number` field (8 bytes)
    9. + *
  9. The output of a SHA-384 digest of the message bytes from the + * `ConsensusSubmitMessage` (48 bytes)
    10. + *
+ */ + WITH_MESSAGE_DIGEST = 1; + + /** + * The original version, used at genesis.
+ * This version SHALL include, in order + *
    + *
  1. The previous running hash of the topic (48 bytes)
    2. + *
  2. The topic's shard (8 bytes)
    3. + *
  3. The topic's realm (8 bytes)
    4. + *
  4. The topic's number (8 bytes)
    5. + *
  5. The number of seconds since the epoch when the `ConsensusSubmitMessage` reached + * consensus (8 bytes)
    6. + *
  6. The number of nanoseconds within the second when the `ConsensusSubmitMessage` + * reached consensus (4 bytes)
    7. + *
  7. The `topic_sequence_number` field (8 bytes)
    8. + *
  8. The message bytes from the `ConsensusSubmitMessage` (variable)
    9. + *
+ */ + WITH_FULL_MESSAGE = 2; + } } diff --git a/block/stream/transaction_output.proto b/block/stream/transaction_output.proto index b25faf6a..79fc571b 100644 --- a/block/stream/transaction_output.proto +++ b/block/stream/transaction_output.proto @@ -34,65 +34,121 @@ option java_package = "com.hedera.hapi.block.stream"; // <<>> This comment is special code for setting PBJ Compiler java package option java_multiple_files = true; +import "stream/schedule_service.proto"; +import "stream/util_service.proto"; import "stream/consensus_service.proto"; import "stream/crypto_service.proto"; -import "stream/file_service.proto"; -import "stream/network_service.proto"; -import "stream/schedule_service.proto"; import "stream/smart_contract_service.proto"; -import "stream/token_service.proto"; -import "stream/util_service.proto"; /** * Output from a transaction. * - * The values in transaction outputs SHALL be data that is not present in the - * original transaction and nor present in state changes. + * The values in transaction outputs SHALL be data that is neither present in the + * original transaction nor present in state changes. + * + * > Note + * >> Only a few transactions produce output that is not in the transaction and + * >> also not reflected in state changes. All other transaction types are _currently_ + * >> not included here. We have, however, allocated names and indexes for those + * >> transaction types to preserve consistency if we add them later. We have reserved + * >> field indexes 9 to 43 for this purpose. + * + * */ message TransactionOutput { - oneof transaction { - CallContractOutput contract_call = 1; - CreateContractOutput contract_create = 2; - UpdateContractOutput contract_update = 3; - DeleteContractOutput contract_delete = 4; - EthereumOutput ethereum_call = 5; - ApproveAllowanceOutput approve_allowance = 6; - DeleteAllowanceOutput delete_allowance = 7; - CreateAccountOutput create_account = 8; - DeleteAccountOutput delete_account = 9; - CryptoTransferOutput crypto_transfer = 10; - UpdateAccountOutput update_account = 11; - AppendFileOutput file_append = 12; - CreateFileOutput file_create = 13; - DeleteFileOutput file_delete = 14; - UpdateFileOutput fileUpdate = 15; - SystemDeleteOutput systemDelete = 16; - SystemUndeleteOutput systemUndelete = 17; - CreateTopicOutput create_topic = 18; - UpdateTopicOutput update_topic = 19; - DeleteTopicOutput delete_topic = 20; - SubmitMessageOutput submit_message = 21; - CreateTokenOutput create_token = 22; - FreezeTokenAccountOutput freeze_token_account = 23; - UnfreezeTokenAccountOutput unfreeze_token_account = 24; - GrantTokenKycOutput grant_token_account_kyc = 25; - RevokeTokenKycOutput revoke_token_account_kyc = 26; - DeleteTokenOutput delete_token = 27; - UpdateTokenOutput update_token = 28; - UpdateTokenNftsOutput update_token_nfts = 29; - MintTokenOutput mint_token = 30; - BurnTokenOutput burn_token = 31; - WipeTokenAccountOutput wipe_token_account = 32; - AssociateTokenOutput associate_token = 33; - DissociateTokenOutput dissociate_token = 34; - UpdateTokenFeeScheduleOutput update_token_fee_schedule = 35; - PauseTokenOutput pause_token = 36; - UnpauseTokenOutput unpause_token = 37; - CreateScheduleOutput create_schedule = 38; - DeleteScheduleOutput delete_schedule = 39; - SignScheduleOutput sign_schedule = 40; - UpdateNodeStakeOutput update_node_stake = 41; - UtilPrngOutput util_prng = 42; - FreezeOutput freeze_network = 43; - } + oneof transaction { + /** + * Output from a submit message transaction. + */ + SubmitMessageOutput submit_message = 1; + + /** + * Output from a crypto transfer transaction. + */ + CryptoTransferOutput crypto_transfer = 2; + + /** + * Output from a utilPrng transaction to request a deterministic pseudo-random number. + */ + UtilPrngOutput util_prng = 3; + + /** + * Output from a contract call transaction. + */ + CallContractOutput contract_call = 4; + + /** + * Output from an ethereum call transaction. + */ + EthereumOutput ethereum_call = 5; + + /** + * Output from a contract create transaction. + */ + CreateContractOutput contract_create = 6; + + /** + * Output from a schedule create transaction that executed immediately on creation. + */ + CreateScheduleOutput create_schedule = 7; + + /** + * Output from a schedule sign transaction that resulted in executing the scheduled + * transaction. + */ + SignScheduleOutput sign_schedule = 8; + } + reserved 9 to 43; } diff --git a/block/stream/transaction_result.proto b/block/stream/transaction_result.proto index ac40d13a..51d060db 100644 --- a/block/stream/transaction_result.proto +++ b/block/stream/transaction_result.proto @@ -39,6 +39,18 @@ import "exchange_rate.proto"; import "response_code.proto"; import "timestamp.proto"; +/** + * While we have the state changes as part of the block stream, + * we may not have the full data set needed. To surface information + * such as staking rewards, fees, etc. we need to include some of the + * data from the original TransactionRecord. + * + * > REVIEW NOTE + * >> Should we have custom fees here, and remove that from the CryptoTransfer output + * >> message? That would make more sense, as I believe TokenTransfer output would also + * >> need custom fees, and we may wish to add custom fees to other transactions in the + * >> future. + */ message TransactionResult { /** * A response code.
@@ -71,13 +83,6 @@ message TransactionResult { */ proto.ExchangeRateSet exchange_rate = 4; - /** - * While we now have the state changes as part of the block stream, - * we may not have the full "why" this change happened. To surface information - * such as staking rewards, fees, etc. we need to include some of the - * artifacts from the original TransactionRecord. - */ - /** * A schedule that executed this transaction, if this transaction was scheduled.
* This value SHALL NOT be set unless this transaction result represents the result diff --git a/documents/api/block/stream/block_header.md b/documents/api/block/stream/block_header.md index 7edef1ba..32acb164 100644 --- a/documents/api/block/stream/block_header.md +++ b/documents/api/block/stream/block_header.md @@ -32,15 +32,11 @@ The block header SHALL provide the base minimum information needed to correctly and process that block, or stop processing if appropriate.
The block header MUST describe, at minimum, the following items. - The version of the block stream data - - The Hedera API version - - The Hedera Services version - - The Hedera Platform version - The block number - The hash of the previous block - The hash algorithm used to generate the block hash - - The digital signature algorithm used to sign the block hash -All fields of this message are REQUIRED, with the exception that the _algorithms_ MAY +All fields of this message are REQUIRED, with the exception that `hash_algorithm` MAY be _transmitted_ as a default value to improve data efficiency. @@ -69,7 +65,7 @@ if that is the default value then we can save space by not serializing it, where | Name | Number | Description | | ---- | ------ | ----------- | -| SHA_384 | 0 | | +| SHA_384 | 0 | A SHA2 algorithm SHA-384 hash.
This is the default value, if a field of this enumerated type is not set, then this is the value that will be decoded when the serialized message is read. | diff --git a/documents/api/block/stream/block_item.md b/documents/api/block/stream/block_item.md index 94ddf1b1..bb428e28 100644 --- a/documents/api/block/stream/block_item.md +++ b/documents/api/block/stream/block_item.md @@ -108,7 +108,7 @@ MAY preclude verification or reconstruction of consensus state.
| Field | Type | Label | Description | | ----- | ---- | ----- | ----------- | -| item_hash | [bytes](#bytes) | | A SHA384 hash of an item filtered from the stream. | +| item_hash | [bytes](#bytes) | | A SHA-384 hash of an item filtered from the stream. | diff --git a/documents/api/block/stream/consensus_service.md b/documents/api/block/stream/consensus_service.md index 66240b5d..66ecbab9 100644 --- a/documents/api/block/stream/consensus_service.md +++ b/documents/api/block/stream/consensus_service.md @@ -6,6 +6,8 @@ - [SubmitMessageOutput](#com-hedera-hapi-block-stream-SubmitMessageOutput) - [UpdateTopicOutput](#com-hedera-hapi-block-stream-UpdateTopicOutput) + - [SubmitMessageOutput.RunningHashVersion](#com-hedera-hapi-block-stream-SubmitMessageOutput-RunningHashVersion) + @@ -17,63 +19,8 @@ Block stream messages that report the results of transactions handled by the `Consensus` service. ### Topic Running Hash Calculation -Some messages include a topic running hash. This value has changed over time, with the -known versions listed here. - -
- -This 48-byte field is the output of a SHA-384 digest with input data determined by the -value of the `topic_running_hash_version` field.
-All new transactions SHALL use `topic_running_hash_version` `3`.
-The bytes of each uint64 or uint32 encoded for the hash input MUST be in Big-Endian format. ---- -If the `topic_running_hash_version` is '0' or '1', then the input data to the SHA-384 digest are, -in order: - 1. The previous running hash of the topic (48 bytes) - 1. The topic's shard (8 bytes) - 1. The topic's realm (8 bytes) - 1. The topic's number (8 bytes) - 1. The number of seconds since the epoch when the `ConsensusSubmitMessage` reached - consensus (8 bytes) - 1. The number of nanoseconds within the second when the `ConsensusSubmitMessage` reached - consensus (4 bytes) - 1. The `topic_sequence_number` field (8 bytes) - 1. The message bytes from the `ConsensusSubmitMessage` (variable). ---- -If the `topic_running_hash_version` is '2', then the input data to the SHA-384 digest are, in -order: - 1. The previous running hash of the topic (48 bytes) - 1. The `topic_running_hash_version` field (8 bytes) - 1. The topic's shard (8 bytes) - 1. The topic's realm (8 bytes) - 1. The topic's number (8 bytes) - 1. The number of seconds since the epoch when the `ConsensusSubmitMessage` reached - consensus (8 bytes) - 1. The number of nanoseconds within the second when the `ConsensusSubmitMessage` reached - consensus (4 bytes) - 1. The `topic_sequence_number` field (8 bytes) - 1. The output of a SHA-384 digest of the message bytes from the `ConsensusSubmitMessage` - (48 bytes) ---- -If the `topic_running_hash_version` is '3', then the input data to the SHA-384 digest -are, in order: - 1. The previous running hash of the topic (48 bytes) - 1. The `topic_running_hash_version` field (8 bytes) - 1. The payer account's shard (8 bytes) - 1. The payer account's realm (8 bytes) - 1. The payer account's number (8 bytes) - 1. The topic's shard (8 bytes) - 1. The topic's realm (8 bytes) - 1. The topic's number (8 bytes) - 1. The number of seconds since the epoch when the `ConsensusSubmitMessage` reached - consensus (8 bytes) - 1. The number of nanoseconds within the second when the `ConsensusSubmitMessage` reached - consensus (4 bytes) - 1. The `topic_sequence_number` field (8 bytes) - 1. The output of a SHA-384 digest of the message bytes from the `ConsensusSubmitMessage` - (48 bytes) - -
+Submitted messages include a topic running hash. This value has changed over time, with the +known versions detailed in the `RunningHashVersion` enumeration. ### Keywords The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", @@ -111,11 +58,13 @@ This message SHALL NOT duplicate information already contained in the original t Block Stream data for a `submitMessage` transaction. This message SHALL NOT duplicate information already contained in the original transaction. +The actual topic running hash SHALL be present in a `StateChanges` block item, and is not +duplicated here.
| Field | Type | Label | Description | | ----- | ---- | ----- | ----------- | -| topic_running_hash_version | [uint64](#uint64) | | The version of inputs to the SHA-384 running hash.
For all current transactions, this value SHALL be `3`. | +| topic_running_hash_version | [SubmitMessageOutput.RunningHashVersion](#com-hedera-hapi-block-stream-SubmitMessageOutput-RunningHashVersion) | | The version of inputs to the SHA-384 running hash.
For all current transactions, this value SHALL be `WITH_MESSAGE_DIGEST_AND_PAYER`. | @@ -135,6 +84,32 @@ This message SHALL NOT duplicate information already contained in the original t + + + +### SubmitMessageOutput.RunningHashVersion +A version of the topic running hash. + +The inputs to the topic running hash have changed over time. This is tracked in earlier +record streams as an integer. For the block stream we chose to use an enumeration for +both efficiency and clarity. Placing the most recent, and most common/highest volume, +version as `0` reduces the serialized size of this message by not serializing that +default value. + +
+ +The topic running hash is a 48-byte value that is the output of a SHA-384 digest with +input data determined by the value of the `topic_running_hash_version` field.
+All new transactions SHALL use `topic_running_hash_version` +`WITH_MESSAGE_DIGEST_AND_PAYER`.
+ +| Name | Number | Description | +| ---- | ------ | ----------- | +| WITH_MESSAGE_DIGEST_AND_PAYER | 0 | The most recent version.
This version SHALL include, in order
  1. The previous running hash of the topic (48 bytes)
  2. The `topic_running_hash_version` field (8 bytes)
  3. The payer account's shard (8 bytes)
  4. The payer account's realm (8 bytes)
  5. The payer account's number (8 bytes)
  6. The topic's shard (8 bytes)
  7. The topic's realm (8 bytes)
  8. The topic's number (8 bytes)
  9. The number of seconds since the epoch when the `ConsensusSubmitMessage` reached consensus (8 bytes)
  10. The number of nanoseconds within the second when the `ConsensusSubmitMessage` reached consensus (4 bytes)
  11. The `topic_sequence_number` field (8 bytes)
  12. The output of a SHA-384 digest of the message bytes from the `ConsensusSubmitMessage` (48 bytes)
| +| WITH_MESSAGE_DIGEST | 1 | An earlier version.
This version SHALL include, in order
  1. The previous running hash of the topic (48 bytes)
  2. The `topic_running_hash_version` field (8 bytes)
  3. The topic's shard (8 bytes)
  4. The topic's realm (8 bytes)
  5. The topic's number (8 bytes)
  6. The number of seconds since the epoch when the `ConsensusSubmitMessage` reached consensus (8 bytes)
  7. The number of nanoseconds within the second when the `ConsensusSubmitMessage` reached consensus (4 bytes)
  8. The `topic_sequence_number` field (8 bytes)
  9. The output of a SHA-384 digest of the message bytes from the `ConsensusSubmitMessage` (48 bytes)
| +| WITH_FULL_MESSAGE | 2 | The original version, used at genesis.
This version SHALL include, in order
  1. The previous running hash of the topic (48 bytes)
  2. The topic's shard (8 bytes)
  3. The topic's realm (8 bytes)
  4. The topic's number (8 bytes)
  5. The number of seconds since the epoch when the `ConsensusSubmitMessage` reached consensus (8 bytes)
  6. The number of nanoseconds within the second when the `ConsensusSubmitMessage` reached consensus (4 bytes)
  7. The `topic_sequence_number` field (8 bytes)
  8. The message bytes from the `ConsensusSubmitMessage` (variable)
| + + diff --git a/documents/api/block/stream/transaction_output.md b/documents/api/block/stream/transaction_output.md index ad12fcfb..dfbeeec2 100644 --- a/documents/api/block/stream/transaction_output.md +++ b/documents/api/block/stream/transaction_output.md @@ -25,55 +25,81 @@ document are to be interpreted as described in [RFC2119](https://www.ietf.org/rf ### TransactionOutput Output from a transaction. -The values in transaction outputs SHALL be data that is not present in the -original transaction and nor present in state changes. +The values in transaction outputs SHALL be data that is neither present in the +original transaction nor present in state changes. + +> Note +>> Only a few transactions produce output that is not in the transaction and +>> also not reflected in state changes. All other transaction types are _currently_ +>> not included here. We have, however, allocated names and indexes for those +>> transaction types to preserve consistency if we add them later. We have reserved +>> field indexes 9 to 43 for this purpose. + + | Field | Type | Label | Description | | ----- | ---- | ----- | ----------- | -| contract_call | [CallContractOutput](#com-hedera-hapi-block-stream-CallContractOutput) | | | -| contract_create | [CreateContractOutput](#com-hedera-hapi-block-stream-CreateContractOutput) | | | -| contract_update | [UpdateContractOutput](#com-hedera-hapi-block-stream-UpdateContractOutput) | | | -| contract_delete | [DeleteContractOutput](#com-hedera-hapi-block-stream-DeleteContractOutput) | | | -| ethereum_call | [EthereumOutput](#com-hedera-hapi-block-stream-EthereumOutput) | | | -| approve_allowance | [ApproveAllowanceOutput](#com-hedera-hapi-block-stream-ApproveAllowanceOutput) | | | -| delete_allowance | [DeleteAllowanceOutput](#com-hedera-hapi-block-stream-DeleteAllowanceOutput) | | | -| create_account | [CreateAccountOutput](#com-hedera-hapi-block-stream-CreateAccountOutput) | | | -| delete_account | [DeleteAccountOutput](#com-hedera-hapi-block-stream-DeleteAccountOutput) | | | -| crypto_transfer | [CryptoTransferOutput](#com-hedera-hapi-block-stream-CryptoTransferOutput) | | | -| update_account | [UpdateAccountOutput](#com-hedera-hapi-block-stream-UpdateAccountOutput) | | | -| file_append | [AppendFileOutput](#com-hedera-hapi-block-stream-AppendFileOutput) | | | -| file_create | [CreateFileOutput](#com-hedera-hapi-block-stream-CreateFileOutput) | | | -| file_delete | [DeleteFileOutput](#com-hedera-hapi-block-stream-DeleteFileOutput) | | | -| fileUpdate | [UpdateFileOutput](#com-hedera-hapi-block-stream-UpdateFileOutput) | | | -| systemDelete | [SystemDeleteOutput](#com-hedera-hapi-block-stream-SystemDeleteOutput) | | | -| systemUndelete | [SystemUndeleteOutput](#com-hedera-hapi-block-stream-SystemUndeleteOutput) | | | -| create_topic | [CreateTopicOutput](#com-hedera-hapi-block-stream-CreateTopicOutput) | | | -| update_topic | [UpdateTopicOutput](#com-hedera-hapi-block-stream-UpdateTopicOutput) | | | -| delete_topic | [DeleteTopicOutput](#com-hedera-hapi-block-stream-DeleteTopicOutput) | | | -| submit_message | [SubmitMessageOutput](#com-hedera-hapi-block-stream-SubmitMessageOutput) | | | -| create_token | [CreateTokenOutput](#com-hedera-hapi-block-stream-CreateTokenOutput) | | | -| freeze_token_account | [FreezeTokenAccountOutput](#com-hedera-hapi-block-stream-FreezeTokenAccountOutput) | | | -| unfreeze_token_account | [UnfreezeTokenAccountOutput](#com-hedera-hapi-block-stream-UnfreezeTokenAccountOutput) | | | -| grant_token_account_kyc | [GrantTokenKycOutput](#com-hedera-hapi-block-stream-GrantTokenKycOutput) | | | -| revoke_token_account_kyc | [RevokeTokenKycOutput](#com-hedera-hapi-block-stream-RevokeTokenKycOutput) | | | -| delete_token | [DeleteTokenOutput](#com-hedera-hapi-block-stream-DeleteTokenOutput) | | | -| update_token | [UpdateTokenOutput](#com-hedera-hapi-block-stream-UpdateTokenOutput) | | | -| update_token_nfts | [UpdateTokenNftsOutput](#com-hedera-hapi-block-stream-UpdateTokenNftsOutput) | | | -| mint_token | [MintTokenOutput](#com-hedera-hapi-block-stream-MintTokenOutput) | | | -| burn_token | [BurnTokenOutput](#com-hedera-hapi-block-stream-BurnTokenOutput) | | | -| wipe_token_account | [WipeTokenAccountOutput](#com-hedera-hapi-block-stream-WipeTokenAccountOutput) | | | -| associate_token | [AssociateTokenOutput](#com-hedera-hapi-block-stream-AssociateTokenOutput) | | | -| dissociate_token | [DissociateTokenOutput](#com-hedera-hapi-block-stream-DissociateTokenOutput) | | | -| update_token_fee_schedule | [UpdateTokenFeeScheduleOutput](#com-hedera-hapi-block-stream-UpdateTokenFeeScheduleOutput) | | | -| pause_token | [PauseTokenOutput](#com-hedera-hapi-block-stream-PauseTokenOutput) | | | -| unpause_token | [UnpauseTokenOutput](#com-hedera-hapi-block-stream-UnpauseTokenOutput) | | | -| create_schedule | [CreateScheduleOutput](#com-hedera-hapi-block-stream-CreateScheduleOutput) | | | -| delete_schedule | [DeleteScheduleOutput](#com-hedera-hapi-block-stream-DeleteScheduleOutput) | | | -| sign_schedule | [SignScheduleOutput](#com-hedera-hapi-block-stream-SignScheduleOutput) | | | -| update_node_stake | [UpdateNodeStakeOutput](#com-hedera-hapi-block-stream-UpdateNodeStakeOutput) | | | -| util_prng | [UtilPrngOutput](#com-hedera-hapi-block-stream-UtilPrngOutput) | | | -| freeze_network | [FreezeOutput](#com-hedera-hapi-block-stream-FreezeOutput) | | | +| submit_message | [SubmitMessageOutput](#com-hedera-hapi-block-stream-SubmitMessageOutput) | | Output from a submit message transaction. | +| crypto_transfer | [CryptoTransferOutput](#com-hedera-hapi-block-stream-CryptoTransferOutput) | | Output from a crypto transfer transaction. | +| util_prng | [UtilPrngOutput](#com-hedera-hapi-block-stream-UtilPrngOutput) | | Output from a utilPrng transaction to request a deterministic pseudo-random number. | +| contract_call | [CallContractOutput](#com-hedera-hapi-block-stream-CallContractOutput) | | Output from a contract call transaction. | +| ethereum_call | [EthereumOutput](#com-hedera-hapi-block-stream-EthereumOutput) | | Output from an ethereum call transaction. | +| contract_create | [CreateContractOutput](#com-hedera-hapi-block-stream-CreateContractOutput) | | Output from a contract create transaction. | +| create_schedule | [CreateScheduleOutput](#com-hedera-hapi-block-stream-CreateScheduleOutput) | | Output from a schedule create transaction that executed immediately on creation. | +| sign_schedule | [SignScheduleOutput](#com-hedera-hapi-block-stream-SignScheduleOutput) | | Output from a schedule sign transaction that resulted in executing the scheduled transaction. | diff --git a/documents/api/block/stream/transaction_result.md b/documents/api/block/stream/transaction_result.md index 250bcf54..30b5a2c1 100644 --- a/documents/api/block/stream/transaction_result.md +++ b/documents/api/block/stream/transaction_result.md @@ -22,7 +22,16 @@ document are to be interpreted as described in [RFC2119](https://www.ietf.org/rf ### TransactionResult - +While we have the state changes as part of the block stream, +we may not have the full data set needed. To surface information +such as staking rewards, fees, etc. we need to include some of the +data from the original TransactionRecord. + +> REVIEW NOTE +>> Should we have custom fees here, and remove that from the CryptoTransfer output +>> message? That would make more sense, as I believe TokenTransfer output would also +>> need custom fees, and we may wish to add custom fees to other transactions in the +>> future. | Field | Type | Label | Description |