Syscall Log & Event Automation

[scab24]

Syscall Log & Event Automation

• Implementation of Log syscall for event emission in RISC-V contracts
• emit! macro with automatic Solidity type detection and signature generation
• Full type support (uint/int, address, bytes, arrays, tuples)
• Testing infrastructure for ERC20 event verification
• Automated system for topics and data generation

[gakonst]

Nice! How should we do indexed logs in this model?

[scab24]

Nice! How should we do indexed logs in this model?

In the code, the first three arguments are automatically indexed in topics, while the rest go to data.

This makes me think it would be interesting to do it like in Solidity and use the keyword indexed.

What do you think?

let mut topics = alloc::vec![topic0];
                
                $(
                    let encoded = $arg.abi_encode();
                    if topics.len() < 3 {
                        topics.push(B256::from_slice(&encoded));
                    } else {
                        eth_riscv_runtime::emit_log(&encoded, &topics);
                    }
                )*

[scab24]

Nice! How should we do indexed logs in this model?

I just updated the code. This would be more similar to what Solidity does

@gakonst

97a6da8

[deuszx]

Isn't it the case that in Solidity one defines which fields are indexed when declaring the event, not when using it? What will happen if another emit! call doesn't do idx from? Or change the (type) signature of the Transfer event entirely.

[scab24]

I completely understand what you're saying. We could do something more similar to what we have with Solidity and write it that way.

It's interesting to hear your opinions to define what would be most appropriate in this case. All of this is provisional. We could do something like this. What do you think?

#[event]
struct Transfer {
    #[indexed]
    from: Address,   
    #[indexed]
    to: Address,      
    value: U256    
}

pub fn transfer(&self, from: Address, to: Address, value: u64) -> bool {
    ...
    emit!(Transfer, from, to, value);
}

[deuszx]

Yes, struct makes more sense.

As for emitting there a couple of options:

1. What you did above.
2. Construct a Transfer instance and pass that to the emit!
3. Have event generate a transfer! macro (named after the struct).

Although one might argue that 2&3 are just sugar in top of 1.

[scab24]

I've just uploaded the update, would the structure be something like this?

Now I need to test everything byte by byte to ensure that everything matches 100% of the time

c48a335

[deuszx]

That's awesome @scab24 , thanks for doing this.

Please, don't treat everything I write as a command :) I really appreciate jumping on this immediately but I don't want to add you work unnecessarily. Let's see what @gakonst and @leonardoalt think as well.

[scab24]

@deuszx
Thank you for your comments, I'm glad to do it, it's a really interesting project 😀

Whenever I have some free time at work, I spend a bit on it

[deuszx]

It'd be nice to have some tests showing byte-for-byte equality of events of the same signature between r55 and Solidity. That way indexers don't need to adapt in order to index contracts written with r55.