Emit additional keys on Events (e.g. Transfer events of ERC20 / ERC721)

[yoga-braavos]

Background

Cairo's default syntactic sugar for events (i.e. @event in Cairo 0 and #[event] in Cairo 1) assigns only a single key to the event which simply put is a starknet_keccak applied on the decorated variable name. For example, when emitting the following event:

#[event]
fn Transfer(from: ContractAddress, to: ContractAddress, value: u256) {}

The on-chain keys property of the event will only contain:

starknet_keccak(to_bytes("Transfer"))

For example, if we analyze the following ERC20 transfer transaction's events, 0x078e56b448ac25e70f96bcda25ef0bcaa5f84637b1a8d51d211274fca086540f we will see there is a single key in the events.keys property which is the encoded representation of "Transfer":

{
    "actual_fee": "0x94d1f34f6572",
    .....
    "events": [
        {
            "data": [
                "0xbf7ba278658bb8ddb076939d0d10b96323177a594792285516b2d7b72f9899",
                "0x2cb12823ceda26957cdd333a67afe1b8f760fb5558472ff3518635c91a7164",
                "0x71afd498d0000",
                "0x0"
            ],
            "from_address": "0x49d36570d4e46f48e99674bd3fcc84644ddd6b96f7c741b1562b82f9e004dc7",
            "keys": [
                "0x99cd8bde557814842a3121e8ddfd433a539b8c9f14bf31ebf108d12e6196e9"
            ]
        },
        ...

Problem

Emitting the events with only the variable name as a key does not allow us to take full advantage of the starknet_getEvents RPC API. Namely for "Transfer" we cannot filter on to or from directly. Current solutions scrape all events of a certain name (e.g. "Transfer") and filter on their local database, beating the purpose of having an event filter to begin with.
This is also not aligned with how events (/logs) are treated in L1, where you can properly query on indexed topics. e.g. https://etherscan.io/tx/0x7cf0a012f932e18b179785cc3e9ba1b5354d9f65696a81c0d20825dbf41480cd#eventlog

Solution

Until Cairo's syntactic sugar supports multi-key events, I suggest using the emit_event syscall to emit additional keys that are valuable for indexing.

Backward Csompatibility

Moving some of the events field from data to keys might break current solutions that looks for values in the events.data property. There are 2 options here:

1. Since starknet is still in alpha and pre re-genesis, we can still move fast and break things - this is also my preferred way forward.
2. For the sake of backwards compatibility we can emit the added keys as data as well, although redundant it will be backwards compatible.

[fracek]

I agree this is very needed. If we follow closely the Ethereum ERC20 and ERC721 standards when it comes to keys it will be finally possible to discriminate between ERC20 Transfer and ERC721 Transfer by looking at how many fields are indexed.

I also agree option 1 is the best technically, but I'm also concerned it will be very confusing for users. It will create a situation where old contracts (that don't use indexed parameters) will have all parameters in data, and new contracts where parameters are split between keys and data. On the other hand, after regenesis it makes sense to break backward compatibility. So my proposal is something along the following lines:

• Pre regenesis: put indexed params in keys to simplify working with getEvents. Software/libraries that are not updated won't break.
• After regenesis: split params between keys and data.