Compute MATIC to pay for Sequencers

[krlosMata]

Topic

When calculating the MATIC fee, how can the contract know hwo many transactions are RPL encoded without decoding them?, could we code at the start some bytes indicating how many transactions will be?

Idea

• We could use the length of the l2TxsData parameter in the smart contract
• There will be a minimal length for l2TxsData, which would be the bytes of the minimal viable transaction
  • This marks the floor of MATIC to spend
• More bytes means more MATIC to spend
  • l2TxsData is considered as a scarce resource, meaning that sequencer pays for byte added. Here, byte added means that the aggregator should put more effort to compute more bytes, so it is rewarded proportionally for bytes procecessed
• This approach has the advantage that penalizes behavior when submitting wrong txs and mitigates adding fake/bad txs

[invocamanman]

i agree in this point This approach has the advantage that penalizes behavior when submitting wrong txs and mitigates adding fake/bad txs but also i'm not agree tha tthe bytes added are dirrectly correlate with the computation effor.
Also we have to take in account that, maybe the effor of the aggregator do not depend that much on the transaction computation, (number of txs, or gas used) but the fact of create a proof itself, maybe it make sense to add a base cost.

[krlosMata]

Agree on the base cost.
I'm also thinking that incentive full-batches and penalize empty batches y by reversing the logic of MATIC payed.
Basically, pay X MATIC when the calldata is full and pay (X - byte*cost) MATIC when the batch is empty assuming there is a minimum to pay if the batch is full.
It kind of breaks the idea of bytes scarcity but I'm taking into an account the cost of calldata in Ethereum.
Just a idea ti put on the table :)