CAP-0067 - Add section for mint/burn bug and don't hash new events

core/cap-0067.md

@@ -125,58 +125,6 @@ index 6ab63fb..79e6bab 100644
  };
 
  // This struct groups together changes on a per transaction basis
-diff --git a/Stellar-transaction.x b/Stellar-transaction.x
-index 6b10e4d..0cff247 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:
-@@ -2045,6 +2045,20 @@ enum TransactionResultCode
-     txSOROBAN_INVALID = -17         // soroban-specific preconditions were not met
- };
-
-+struct TransactionResultExtensionV1
-+{
-+    // Stores SHA256(Transaction level events + all operation level events)
-+    Hash eventsHash;
-+
-+    union switch (int v)
-+    {
-+    case 0:
-+        void;
-+    }
-+    ext;
-+};
-+
-+
- // InnerTransactionResult must be binary compatible with TransactionResult
- // because it is be used to represent the result of a Transaction.
- struct InnerTransactionResult
-@@ -2083,6 +2097,8 @@ struct InnerTransactionResult
-     {
-     case 0:
-         void;
-+    case 1:
-+        TransactionResultExtensionV1 v1;
-     }
-     ext;
- };
-@@ -2130,6 +2146,8 @@ struct TransactionResult
-     {
-     case 0:
-         void;
-+    case 1:
-+        TransactionResultExtensionV1 v1;
-     }
-     ext;
- };
 ```
 
 ## Semantics
@@ -198,7 +146,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`. `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`.
+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`. Soroban events will be moved to `OperationMetaV2`. The hash of the current soroban events will still exist under `INVOKE_HOST_FUNCTION_SUCCESS` as it does today.
 
 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.
 
@@ -379,6 +327,11 @@ contract: asset, topics: ["transfer", from:Address, to:Address, sep0011_asset:St
 * `to` is the claimable balance being created. The type of this address will be `SC_ADDRESS_TYPE_CLAIMABLE_BALANCE`.
 * `amount` is the amount moved into the claimable balance.
 
+### Retroactively emitting correct events
+Prior to protocol 8, there was a bug that could result in the minting/burning of XLM. To allow for the ability to build balances with only events, we not only need to emit the events specified in this CAP from genesis, but also handle that bug properly.
+
+For both the mint and burn scenario, the affected account will be the source account, and that should be the only account in an operation with a balance difference not entirely reflected by the events specified in this CAP. If we take the total diff of XLM in an `Operations` `OperationMeta` (similar to what the ConservationOfLumens invariant does) and emit that diff as a mint/burn event for the source account, then consumers should be able to track balances correctly.
+
 ## Design Rationale
 
 ### Remove the admin from the SAC `mint` and `clawback` events
@@ -396,6 +349,10 @@ It's important to note that transaction meta is not part of the protocol, so the
 The Stellar Asset Contract special cases the issuer logic because issuers can't hold a trustline for their own assets. This matches the logic in Classic. The special case was unnecessary however because the Stellar Asset Contract provides the `mint` and `burn` functions. This CAP could instead just remove the special case and allow `transfers` involving the issuer to fail due to a missing trustline,
 but this would break any contracts that rely on this behavior (it's not known at this time if contracts like this exist, but we could check if there are any `transfers` on pubnet that involve the issuer). That's why this CAP chooses to instead emit the correct event in this scenario.
 
+### New events will not be hashed into the ledger
+
+For now, the new events will not be hashed into the ledger to give us more flexibility while we figure out if we want to transform more of the meta ledger entry changes into events. We can start hashing the events at a later point.
+
 ### New SCAddressType types
 
 This CAP adds two new `SCAddressType` types - `SC_ADDRESS_TYPE_CLAIMABLE_BALANCE` and `SC_ADDRESS_TYPE_LIQUIDITY_POOL`. These types are used in the topic of an event where the address is not a contract or a stellar account.