Closed yulesa closed 2 months ago
Basically you're adding log_index
to the list of supported fields of block
, is that it?
No.
Unlike the other entities, log is not selected by a log_id (block_id
+ log_index
). In fact, log_index
is not even a supported log selector.
In alloy, logs is requested by specifying a filter
in the get_logs
function..
The supported filters are:
The EQL syntax would require us to write it somehow. I haven't decided yet how to write it. The other issue is that any query wouldn't return only one log, but a vector of logs. To start, I can force the return of only one log until we figure out ranges.
Oh I see. The FROM block block_id ON eth
part got me thinking that you wanted to add those fields to BlockFields
struct.
for the syntax we can use something like:
GET block_hash FROM logs 0xblockhash | blocktag, 0xaddress, [topics] ON eth
but address and topics should be optional, since the only required input of get_logs
is block
since the only required input of get_logs is block
You can have any of them; none are required. I just want to start with block_hash and improve from that.
Gotcha. Yeah, it make sense starting from there
Summary
Allow EQL users to make EQL expressions to retrieve logs like:
GET block_hash, block_number, block_timestamp, transaction_hash, transaction_index, log_index, address, topics, data FROM block block_id ON eth
The feature request above represents only the minimum functionality to start supporting logs. More features, such as other ways to filter logs (by address and block), will be handled in future requests.