feat: events api

[Daanvdplas]

Events should be added to the api ink! library as well as emitted in the pallet.

[chungquantin]

IMO, this should emit the event on the runtime level, we want the smart contract developer to control what kinds of events they want to emit on the contract level. But in the other hand, emitting the event from POP API does improve the contract testing experience with tool like Contract UI: https://ui.use.ink/

[Daanvdplas]

we want the smart contract developer to control what kinds of events they want to emit on the contract level

I think that is a great point.

As for having events for testing, this is why we have put so much effort in the error handling. Contracts using the pop api should not have to worry about the code not working. They should only have to worry about the logic they add on top of the api, this includes what to do with the return value from the api, as for errors - this is were top notch documentation and examples will become crucial (#108), to help the developer understanding how to convert the status code to a clear error and how to eventually structure their production level code with respect to the error handling of the api. StatusCode will be the best, otherwise the UseCaseError - FungiblesError. They can then, like you said, emit their own custom events for testing the success of their smart contract logic.

@peterwht & @evilrobot-01, I would like to hear your view here so that we can implement the final decision.

[Daanvdplas]

As for events in the runtime, the standard only has two:

• Transfer
• Approval

The events for creating and destroying assets and metadata is an open question here.

[peterwht]

Events emitted from a contract results in: "contracts.ContractEmitted" from pallet-contracts. So, emitting additional events from the runtime results in needing to monitor both contract events and runtime events. See here. We can create predefined events for contracts to use in the contract-side of the API.

Also, in this example, pallet-assets will emit events as well.

However, outputting events from the runtime could be useful for monitoring activity in the API.

My opinion is this:

1. We should have predefined events that smart contracts can use IF they want to. These will be in the contract-side of the API. As Tin said, emitting events on the contract-side results in better DX in tools like ui.use.ink.
2. We should output Pop API events in the runtime. These events should be catered for information on the Pop API pallet usage. However, contracts can use these if they desire, but ultimately they will have better results utilizing above.

[Daanvdplas]

We should output Pop API events in the runtime. These events should be catered for information on the Pop API pallet usage.

Just mentioning that emitting events doesn't come for free: https://substrate.stackexchange.com/questions/4126/why-are-events-stored

[Daanvdplas]

Additional relevant comments: #113 (comment)

[evilrobot-01]

Contracts can't consume the emitted events AFAIK, so I think the conversation should be based around standards in this context. If fungibles is supporting a standard, it should potentially emit events to satisfy the standard, so that external event subcribers get the information they require to take some action. Access to signals of state changes, in a known format, is the most important thing.

The consumer of the events can ultimately choose which events to subscribe to in order to fulfill their use case, potentially amalgamating information from multiple events if need be. Listening to multiple events to gather enough information to act isn't ideal, but better than not even sufficient information to act.

Zooming out, what does a wallet supporting a PSP do to support a token. If it only looks for contract specific events, with specific interfaces/identifiers, then emitting them from the fungibles may be unnecessary. Let's be standards compliant first, then potentially consider whether the fungibles pallet should emit events and what shape they may be.

By example, does assets emit enough, does fungibles emit enough, does the contract have enough to even emit. If assets emits something containing the new balance, but fungibles or the contract are unable to use that information to incorporate their own event, apart from querying, is there much than can be done by way of the contract events?

[evilrobot-01]

We probably need to place these events into two buckets. Those contracts which want to comply to a standard for interoperability and composability, which may want to emit standards-based events. I agree with Peter here in making these types easily available, provided the contract has sufficient information to actually construct the event data. This may be a non-starter or may require the contract to track additional state. Providing reusable types to meet a standard is easy tho.

Other contracts are consumers of Pop API and probably don't directly care about being standards compliant. I still feel that fungibles should emit standards compliant events where practical, so that ultimately wallets/dapps have the information they need readily available.

[Daanvdplas]

Alright so providing the event in the api, as part of the standard and use case. In addition, emitting the event in the pallet.

That seems both reasonable, especially in the contract where the developer can choose themselves whether to use it or not.

[Daanvdplas]

Closed by #153