CAP-0067 Update - #1617
Conversation
| ### 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. |
There was a problem hiding this comment.
For consistency, the preimage of the hash stored in
InvokeHostFunctionResulton success will just be thereturnValueSCVal
This is undoing a previous change, right? It used to just be the SCVal. Should we revisit why we did that in the first place to make sure we're not missing something by reverting back?
There was a problem hiding this comment.
Just a reminder to post the comments on the discussion thread, especially for more contentious topics.
| 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. |
There was a problem hiding this comment.
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.
This seems... prohibitive to downstream ingesters. Unless the event itself makes it unnecessary to inspect the operation itself (which would require more details in data, imo. Could we make events<> a nested vector, instead, in a binary-compatible way, or will that not work because of a prepended length byte? I'm not 100% sure how XDR encodes things.
4 participants
We should rename
SorobanTransactionMeta, but that can be done in a follow up change to this CAP.