[tx data lake] Filter out specific transaction type

[rkdud007]

There are different eips introduced different transaction type that holds different fields to decode from. By default we get all the types within the range, but ideally user should have flexibility to filter the specific transaction types.

[petscheit]

From my perspective, this has high priority. Without this feature, we are not able to query any fields, that are not shared by every transaction type.

I have taken a look of how we could add it, and I think the TxInBlock datalake would be the place to do it.

One thing to keep in mind, that that solidity defaults to 0 for undefined values. For this reason we could add an included_types parameter, that contains a boolean, sequentially for each type. At least one idea, open for suggestions here.

[rkdud007]

One idea, this filter type should be also exist in datalake definition ( meaning also when we encode/commit this type specification should be effect as well ) ,would like to suggest have u64 for filtering value ( we can name it included_types as mentioned above @petscheit ). And, by follow this type index,

pub enum TxType {
    /// Legacy transaction type.
    Legacy = 1,
    /// EIP-2930 transaction type.
    Eip2930 = 2,
    /// EIP-1559 transaction type.
    Eip1559 = 4,
    /// EIP-4844 transaction type.
    Eip4844 = 8,
}

we sum up the value that we want to filter to the u64 value. the index is specified so that there is no duplicated value come up in any combination
e.g
case 1. want to get all types of Tx : 1 + 2 + 4 + 8 = 15
case 2. want to get only 2930 + 1559 : 2 + 4 = 6
total set : {1,2,4,8,3,5,9,6,10,12,7,11,13,14,15}

#[derive(Debug, Clone, PartialEq)]
pub struct TransactionsInBlockDatalake {
    // target block number
    pub target_block: u64,
    // ex. "tx.to" , "tx.gas_price" or "tx_receipt.success", "tx_receipt.cumulative_gas_used"
    pub sampled_property: TransactionsCollection,
    // increment of transactions
    pub increment: u64,
    // filtering index that we derive above
    pub included_types : u64
}

[rkdud007]

plus, if we fix on working on this, good to handle #72 together as this will also introduce encode/commit changes

[rkdud007]

updated suggestion:

included_types
[ decimal <> binary ]
0001 = Legacy = 1
0011 = Legacy + Eip2930 = 3
0111 = Legacy + Eip2930 + Eip1559 = 7
1111 = Legacy + Eip2930 + Eip1559 + Eip4844 = 15

pub struct TransactionsInBlockDatalake {
    // target block number
    pub target_block: u64,
    // ex. "tx.to" , "tx.gas_price" or "tx_receipt.success", "tx_receipt.cumulative_gas_used"
    pub sampled_property: TransactionsCollection,
    // start index of transactions range ( default 0 )
    pub start_index: u64,
    // start index of transactions range ( default last ) 
    pub end_index: u64,
    // increment of transactions
    pub increment: u64,
    // filter out the specific type of Txs
    pub included_types: u64
}

And in input.json file, we pass all the Tx/Tx receipts data in the specified range( regardless of the type )

And in Cairo can decode included_types, u64 type -> binary representation and loop through the bits

[rkdud007]

close as #66