CAP-0067 - Add tx level events

core/cap-0067.md

@@ -4,7 +4,7 @@
 CAP: 0067
 Title: Unified Asset Events
 Working Group:
-    Owner: sisuresh@stellar.org
+    Owner: Siddharth Suresh <@sisuresh>
     Authors: Siddharth Suresh <@sisuresh>, Leigh McCulloch <@leighmcculloch>
     Consulted: Dmytro Kozhevin <@dmkozh>, Jake Urban <jake@stellar.org>, Simon Chow <simon.chow@stellar.org>
 Status: Draft
@@ -68,7 +68,7 @@ index 5113005..ee10e20 100644
 
  %struct SCVal;
 diff --git a/Stellar-ledger.x b/Stellar-ledger.x
-index 6ab63fb..e99304e 100644
+index 6ab63fb..79e6bab 100644
 --- a/Stellar-ledger.x
 +++ b/Stellar-ledger.x
 @@ -446,7 +446,44 @@ struct TransactionMetaV3
@@ -94,7 +94,6 @@ index 6ab63fb..e99304e 100644
 +    SCVal returnValue;
 +}
 +
-+
 +struct TransactionMetaV4
 +{
 +    ExtensionPoint ext;
@@ -107,6 +106,7 @@ index 6ab63fb..e99304e 100644
 +    SorobanTransactionMetaV2* sorobanMeta; // Soroban-specific meta (only for 
 +                                           // Soroban transactions).
 +
++    ContractEvent events<>;
 +    DiagnosticEvent txDiagnosticEvents<>; // Used for diagnostic information not tied
 +                                          // to an operation.                                 
 +};
@@ -126,7 +126,7 @@ index 6ab63fb..e99304e 100644
 
  // This struct groups together changes on a per transaction basis
 diff --git a/Stellar-transaction.x b/Stellar-transaction.x
-index 6b10e4d..adc42ee 100644
+index 6b10e4d..0cff247 100644
 --- a/Stellar-transaction.x
 +++ b/Stellar-transaction.x
 @@ -1883,7 +1883,7 @@ enum InvokeHostFunctionResultCode
@@ -144,8 +144,8 @@ index 6b10e4d..adc42ee 100644
 
 +struct TransactionResultExtensionV1
 +{
-+    // Stores a hash per operation
-+    Hash eventsHash<>;
++    // Stores SHA256(Transaction level events + all operation level events)
++    Hash eventsHash;
 +
 +    union switch (int v)
 +    {
@@ -198,7 +198,7 @@ contract: asset, topics: ["clawback", from:Address, sep0011_asset:String], data:
 At the moment, if the issuer is the sender in a Stellar Asset Contract `transfer`, the asset will be minted. If the issuer is the recipient, the asset will be burned. The event emitted in both scenarios, however, is the `transfer` event. This CAP changes that behavior to instead emit the `mint`/`burn` event.
 
 ### New Events
-This section will go over the semantics of how the additional `transfer` events are emitted for each operation, as well as the `fee` event emitted for the fee paid by the source account. These events will be emitted through the `events<>` field in the new `OperationMetaV2`, and the SHA-256 hash of the events will be saved in `eventsHash<>` which is in the new `TransactionResultExtensionV1` extension of `TransactionResult`. For consistency, the preimage of the hash stored in `InvokeHostFunctionResult` on success will just be the `returnValue` `SCVal`, and the events hash will be stored in `eventsHash` like any other transaction. Soroban events will also be emitted through `OperationMetaV2`.
+This section will go over the semantics of how the additional `transfer` events are emitted for each operation, as well as the `fee` event emitted for the fee paid by the source account. These events will be emitted through the `events<>` field in the new `OperationMetaV2`, and the SHA-256 hash of the events will be saved in `eventsHash` which is in the new `TransactionResultExtensionV1` extension of `TransactionResult`. `eventsHash` will be `SHA256(Transaction level events + all operation level events in chronological order)`. For consistency, the preimage of the hash stored in `InvokeHostFunctionResult` on success will just be the `returnValue` `SCVal`, and the events hash will be stored in `eventsHash` like any other transaction. Soroban events will also be emitted through `OperationMetaV2`.
 
 Note that the `contract` field for these events corresponds to the Stellar Asset Contract address for the respective asset. Note that the Stellar Asset Contract instance is not required to be deployed for the asset. The events will be published using the reserved contract address regardless of deployment status.
 
@@ -387,7 +387,7 @@ The admin isn't relevant information when a mint or `clawback` occurs, and it hi
 
 ### TransactionMetaV4
 
-This CAP introduces a new `TransactionMeta` version, `TransactionMetaV4`. Now that we're emitting events for more than just Soroban, this allows us to clean up the structure of meta because `TransactionMetaV3` assumed events would only be emitted for Soroban. This change also allows us to emit events at the operation layer instead of the transaction layer using the new `OperationMetaV2` type.
+This CAP introduces a new `TransactionMeta` version, `TransactionMetaV4`. Now that we're emitting events for more than just Soroban, this allows us to clean up the structure of meta because `TransactionMetaV3` assumed events would only be emitted for Soroban. This change also allows us to emit events at the operation layer instead of the transaction layer using the new `OperationMetaV2` type. Transaction level events like `fee` will still be emitted at the transaction level under `TransactionMetaV4.events`.
 
 It's important to note that transaction meta is not part of the protocol, so the emission of `TransactionMetaV4` instead of `TransactionMetaV3` can be done using a config flag, allowing consumers of meta to switch on their own time.