<aside> 👉 This change has been implemented in https://github.com/onflow/flow-go/pull/5845.

</aside>

Context

Service events are special Cadence events which are hoisted out of the execution state and propagated to the Protocol State via the sealing process. Service events (once sealed) are considered a trusted data source and can cause state changes in highly sensitive parts of the Protocol State, like identity table. In general they are very security-sensitive and need to be treated carefully. See Service Events for details.

Currently we have the following constraints for service events:

1. must be defined in a system contract
2. must be allow-listed in the Protocol node software
3. must be emitted during execution of the system chunk

<aside> 💡 In this document, we consider revising Rule 3

</aside>

We chose these rules in the context of the initial two service events, which were emitted based on observing a certain view from the context of the system chunk. Several new service events are emitted based on governance transactions, which requires:

• (within governance tx) writing a “pending service event” to storage
• (within system chunk) adding or extending a “heartbeat” function which checks for a pending service event and emits it

You can see an example here: https://github.com/onflow/flow-core-contracts/pull/411.

Shortcomings of Rule 3

The reasoning behind Rule 3 was:

• be as restrictive as possible, by default
• make it impossible for transaction execution initiated externally to directly cause service event emission

However: