Right, as Tom noted above, once we have full nodes operational, this could be done locally (in a node).
This is just a first approximation, so it’s just simplicity.
It will probably be more accurate when we indeed count per message.
Basically how many times the state has been updated in this transaction.
do you call this “state updates”?
In this case it won’t be FIFO. But note this is forward-looking, and we haven’t yet decided on this.
I didn’t look into this proposer-builder separation. Thanks for the pointer!
what do you expected L2 costs to compare vs L1 costs? Is this what you are talking about here?
the post explains how fees are calculated, how does the mechanism of fee collection work? is “sign transaction with fee” just an ETH transfer from client to sequencer’s address? where (L2 or L1) does it happen?
Basically, what we’re currently seeing as driving the price is the L1 cost; mainly the cost of data transfer and storage.
The price of L2 is low compared.
This statement, and the setting of the relevant parameters will probably reflect that at a first phase.
This is still being finalized. It will probably be an L2 transfer.
One small question. Will the starknet simulator (the library we use to run tests) report the state diff items and the number of steps? That way we can start estimating how effective some optimizations are.
Thank you for sharing the details on estimating and collecting transaction fees on the StarkNet Alpha network. It’s interesting to see the factors that contribute to the transaction cost and how the current mechanism works to estimate fees based on gas price and resource consumption. It’s good to know that there are plans to optimize and refine the fee calculation method in the future, especially as the network becomes decentralized. I look forward to seeing how fee auctions and fee abstraction will be implemented on the StarkNet network.