Consider what contract event to implement (if any)

[autholykos]

Possible events are:

• Moonlight Transfer
• Addition to the note tree for Phoenix (emit the note or the nullifier) - this one we might seat out. To be discussed with @herr-seppia
• Stake

[autholykos]

After a brief discussion with @ureeves and @herr-seppia we recognized that, while Stake events are necessary, we need to carefully consider whether or not loading the contract execution with the overhead of emitting other type of events.

• Provisioners do not have any use for events because their focus on achieving consensus requires limiting their interaction with clients as much as possible.
• Archivals might serve different data to different clients. Therefore, it makes perfect sense to create events locally following a Moonlight or Phoenix transaction acceptance. These events might be tailor-made depending on the client requesting them. the convenience that an event would introduce for clients would still be possible with the Archival's intermediation.
• Stake events are necessary because it would be quite difficult for an Archival to capture state changes triggered by transactions that are not initiated by a user, but are contract function calls performed by the consensus (e.g. slashing events).

Crafting events in the Archival rather than during contract execution introduces inefficiency in proving the correctness, consistency, and completeness of events. In fact, a client wishing to prove that the events sent by the Archival are honest, might have to extract events from the transactions, rather than collecting them directly from a transfer execution. Although event emission in contract is not free and introduces a (perhaps moderate) hike in gas price and overhead, this seems to be justified in the case of Moonlight transactions.

Paraphrasing @herr-seppia:

In my view, events should be generated exclusively by the VM. Everything else is up to the discretion of the archival implementation(s).
There should be a clear distinction between a genuine contract event and manipulated, unverifiable data.

[autholykos]

Another reason that strengthens the case of having the contract emitting Moonlight events has to do with the fact that the Archival would already need to store the Stake events and those must necessarily be created during the contract execution. It would indeed be undesirable to have half of the events created by the VM and some others created by the Archival in an arbitrary fashion.

[ureeves]

@herr-seppia and I have considered the events to emit as a matter of course for the protocol. Here's our notes from the meeting, and we will be proceeding to implement them all today.

Transfer Events

• Mint
  • Add event with value and receiver of funds
• Withdraw
  • Add event with value and receiver of funds
• Convert
  • Add event with value and receiver of funds
  • Investigate whether the sender of the funds can be used (probably yes)
• Deposit
  • Add event with value and contract receiving the funds
  • Investigate whether the sender of the funds can be used (probably not)
• TransferToContract
  • Add event with the source and receiver contract, and value transferred
• TransferToAccount
  • Add event with the source contract and receiver account, and value transferred
• Spend and Execute
  • Add events on transfer of funds from account to account, and investigate during implementation if phoenix sender/receiver events also make sense.

Stake Events

• Stake
  • Emit event with the account that staked and the staked amount
• Unstake
  • Remove receiver of the withdraw, relying on the transfer contract to inform of the mint
• Withdraw
  • Remove receiver of the withdraw, relying on the transfer contract to inform of the mint
• Reward
  • Change the reward function to take a vector of keys and values, to emit a single event. Consolidate reward calls into one #2292
  • Add reason for reward - possibly a byte is enough. Consolidate reward calls into one #2292
• Slash
  • Merge the suspended and slash events into one
• Hard Slash
  • Merge the suspended and hard_slash events into one

[autholykos]

Solved by #2295 and #2294