Well done. Progress everyday.
Great progress! I’d like to second the concerns around gas estimation services since any downtime could really harm the network.
why an average instead of dynamic for each message?
do you mean the number of state updates or the size of the state diff?
does this mean that the current tx ordering is still FIFO? so MEV is going to be a latency game more than anything. Have you looked into proposer-builder separation? do you think that would make any sense in here?
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!
Is whole payload of the l2->l1 message stored on l1 not only its hash?
Only the hash is stored.
bytes\_per\_msg is multiplied by gas\_per\_byte as it is sent as call data.
I also think it is very important to take the MEV component into account.
thanks for the post.
what is a step in this context?
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?
A Cairo trace step
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.
heh, I just asked the same this morning. +1 to the question.
Will events emitted by a function count as messages?
Events don’t count as messages to L1.
How will contract deployment fees be calculated? In other words, will the contract size be taken into account when deploying the contract?
At the moment we’re not taking fees for contract deployment since it’s a separate transaction, with no source account contract.
We are looking into how to address this, e.g. by making deployment a system call (and therefore a regular transaction), so a fee can be collected.
will it be possible to pay gas fee for a trans in another token on your wallet?
not right now.
but we’re thinking of having fee abstraction (as part of account abstraction), and this will then be possible.
that will be a great feature
i need some deep looking but well done
Thanks for these precisions!
i wonder the fee looks like now, like the average fee per transaction