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.
That makes sense. Given that full nodes are currently not widely available for anyone to utilize, a bridging solution is needed as a temporary measure. It is good that this limitation is explicitly acknowledged in the post to set the right expectations.
The upcoming release of the pathfinder Rust full node by the end of this month is promising. Once API services start integrating with pathfinder, it should enable improved gas estimation by executing transactions locally or through those API services using the full node.
With pathfinder and other full nodes becoming more widely deployed and integrated, we can then transition to a more robust solution for transaction execution and gas estimation that taps into those full nodes. The current bridging solution can then be phased out.
Overall, it seems like good progress is being made toward a more decentralized network with greater node diversity and participation. The release of pathfinder and its adoption should be an important step forward in that direction. Please continue the good work!
I also think it is very important to take the MEV component into account.