sRFC 00013 - CPI Events

1 Like

for check 1: why is it important for the data to start with those specific 8 bytes? is it just to have a standard discriminator to know it is a “cpi event” that should be indexed

1 Like

Appreciate work on this problem. Events are an essential but very neglected part of the runtime. I feel conflicted about trying another “runtime hack” for this purpose. Curious what a design from scratch would look like.

1 Like

I looked more in detail into the proposed spec, one issue I see, is that the CPI can reference accounts via ALT, which would break the current parser. Given how basic events are for client programs and how difficult it is to have accurate ALT copies on client side, I am more convinced that we should make events a first class citizen so that it’s easy to subscribe to them using a websocket similar to ETH:

Inner instructions are currently part of TransactionMeta, which means you can either subscribe to all txs in a block (very unscalable) or just one Transaction.

Another argument against CPI would be that the current program is passed to the emit call as an account, this obviously creates a lot of overhead on the runtime, as loading the a fairly average program means loading 3MB of memory.

Triton has implemented a transactionSubscribe RPC call (can filter by accounts, success/failure) which helps a lot in mitigating the problem of streaming CPI events

1 Like