chore(p/grc20): Distinct Event Types for GRC20 Functions

[notJoon]

Description

Currently, the event type for grc20 is uniformly set to TrasferEvent (execpt for Approval function), which necessitated making RPC calls to check every block.

Therefore, I have modified it by adding event types for each function to distinguish them from one another.

In this case, we can reduce the number of RPC calls by retrieving data only when the target event type occurs.

Contributors' checklist...

• Added new tests, or not needed, or not feasible
• Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory
• Updated the official documentation or not needed
• No breaking changes were made, or a BREAKING CHANGE: xxx message was included in the description
• Added references to related issues and PRs
• Provided any useful hints for running manual tests
• Added new benchmarks to generated graphs, if any. More info here.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 60.22%. Comparing base (701ac17) to head (a17dccf).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #2749   +/-   ##
=======================================
  Coverage   60.21%   60.22%           
=======================================
  Files         562      562           
  Lines       75038    75038           
=======================================
+ Hits        45185    45188    +3     
+ Misses      26476    26475    -1     
+ Partials     3377     3375    -2     

Flag	Coverage Δ
contribs/gnodev	61.40% <ø> (ø)
contribs/gnofaucet	15.31% <ø> (+0.85%)	⬆️
gnovm	64.33% <ø> (ø)
misc/genstd	80.54% <ø> (ø)
misc/logos	20.23% <ø> (ø)
tm2	62.05% <ø> (+0.03%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[leohhhn]

@notJoon, can you elaborate more on why you want to do this?

[leohhhn]

The ERC20 spec mentions that a mint function should emit a transfer from a zero address to the address receiving new tokens (see Events - Transfer). Ideally, mint would use transfer under the hood, which would emit its own event satisfying the spec.

Since we're actively working on the GRC20 package, let me know how crucial this is to you; we (or you) can try to implement what I mentioned above in the next iteration.

It mentions nothing about the burn case, so I guess we can do whatever we want there.

cc @moul