Hash events into ledger

core/cap-0067.md

@@ -35,8 +35,6 @@ This CAP specifies three changes -
 2. Remove the admin from the topics of the `mint` and `clawback` events emitted in the SAC.
 3. Update issuer semantics in the SAC so that a `transfer` involving the issuer will emit the semantically correct event (`mint` or `burn`).
 
-The added events will not be a protocol change because they won't be hashed into the ledger, but the Stellar Asset Contract changes will be.
-
 ## Specification
 
 ### XDR Changes
@@ -69,6 +67,49 @@ index 5113005..ee10e20 100644
  };
  
  %struct SCVal;
+diff --git a/Stellar-ledger.x b/Stellar-ledger.x
+index 6ab63fb..80a2635 100644
+--- a/Stellar-ledger.x
++++ b/Stellar-ledger.x
+@@ -447,6 +447,7 @@ struct TransactionMetaV3
+ };
+ 
+ // This is in Stellar-ledger.x to due to a circular dependency 
++// Only used before protocol 23
+ struct InvokeHostFunctionSuccessPreImage
+ {
+     SCVal returnValue;
+diff --git a/Stellar-transaction.x b/Stellar-transaction.x
+index 6b10e4d..163430e 100644
+--- a/Stellar-transaction.x
++++ b/Stellar-transaction.x
+@@ -1883,7 +1883,7 @@ enum InvokeHostFunctionResultCode
+ union InvokeHostFunctionResult switch (InvokeHostFunctionResultCode code)
+ {
+ case INVOKE_HOST_FUNCTION_SUCCESS:
+-    Hash success; // sha256(InvokeHostFunctionSuccessPreImage)
++    Hash success; // sha256(SCVal)
+ case INVOKE_HOST_FUNCTION_MALFORMED:
+ case INVOKE_HOST_FUNCTION_TRAPPED:
+ case INVOKE_HOST_FUNCTION_RESOURCE_LIMIT_EXCEEDED:
+@@ -2083,6 +2083,8 @@ struct InnerTransactionResult
+     {
+     case 0:
+         void;
++    case 1:
++        Hash eventsHash;
+     }
+     ext;
+ };
+@@ -2130,6 +2132,8 @@ struct TransactionResult
+     {
+     case 0:
+         void;
++    case 1:
++        Hash eventsHash;
+     }
+     ext;
+ };
 ```
 
 ## Semantics
@@ -90,8 +131,9 @@ 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 `TransactionMeta`, and will not be hashed into the ledger. 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.
+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 `SorobanTransactionMeta`, and the SHA-256 hash of the events will be saved in the new `eventsHash` 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.
+
+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.
 
 #### Fees paid by source account
 
@@ -278,9 +320,7 @@ The admin isn't relevant information when a mint or `clawback` occurs, and it hi
 
 ### No change to TransactionMeta XDR
 
-By using the existing `events<>` vector in `SorobanTransactionMeta`. We can avoid making any xdr changes. This does have some tradeoffs, mainly that 
-1. All events for a given transaction will be emitted in a single vector, making it impossible to distinguish which operation emitted a specific event. The alternative would be to move Soroban meta from the transaction layer into the operation layer of transaction meta, but that would be a breaking change. 
-2. Soroban events are hashed into the return value of `InvokeHostFunctionResult` which allows you to cryptographically verify the `events<>` vector. Using the same `events<>` vector may cause some confusion because the Classic events won't be hashed into anything.
+By using the existing `events<>` vector in `SorobanTransactionMeta`. We can avoid making any xdr changes. This does have some tradeoffs, mainly that all events for a given transaction will be emitted in a single vector, making it impossible to distinguish which operation emitted a specific event. The alternative would be to move Soroban meta from the transaction layer into the operation layer of transaction meta, but that would be a breaking change.
 
 ### Emit the semantically correct event instead of no longer allowing the issuer to transfer due to missing a trustline