What is the meaning of `gasPrice` in `Submit`?

[pepyakin]

What is the meaning of gasPrice and what is the supposed behavior of the DA adapter wrt it?

https://github.com/rollkit/go-da/blob/011ba6919abc161b0703d1e3d87b45adf2f96464/da.go#L25-L29

[nashqueue]

GasPrice is how much Token you pay per Gas. If you don't need that field, you can ignore it. Does your DA-Layer not have a gas token ?

[pepyakin]

Ok, I am probably going to ignore it on our side.

Below, I would just mention what confuses me in case you are interested in generalizing of the interface.

While what you wrote

GasPrice is how much Token you pay per Gas.

is helpful, there are still some white spots left.

In Bitcoin, this description maps pretty cleanly, roughly gasPrice sets sats per byte to the DA transaction formed by submit. For post-EIP1559 Ethereum and similar networks (e.g. Substrate derived chains) it gets murkier. I am sure you are aware that in those transactions you don't specify gasPrice directly. You can change the tip component, but that has a different dynamic and is not per-gas/byte.

[nashqueue]

Interesting you are right. I am open to suggestions if you want to make the da-interface compatible with a specific Da-Layer that you have in mind

[pepyakin]

What follows is more of my thoughts on the general problem, rather than specifc suggestions. For now, I think the best way would be to do nothing.

Initially, I was confused why and how the caller could come up with a reasonable gas price. But this may be because I am biased with our DA's approach where it would pick value itself. However, as you hinted in #47 (comment) there may be different strategies of submitting blobs, with different constraints and optimization goals. As such, it may be a good idea to consider the idea of sequencer picking the transaction specifics.

Also, there is an issue I wrote thrumdev/blobs#79 (comment) which talks about complications of implementation of Submit-like functions, specifically, nonce management and submission of blobs when there are blobs in-flight, reaction to restarts, etc.

From the rollkit perspective, it's even more complicated, because it may not assume nonces if it aims to support UTXO. There may be also other features, such as replace-by-fee, which may be lacking in other DA layers.

So we have several pieces of logic that we have to split between the caller (rollkit/sequencer) and the implementer (node/shim):

1. durability,
2. resubmission,
3. nonce/utxo management,
4. strategy when and at which price submit blobs,
5. repacking transaction in batches due to changes of contraints like DA.MaxBlobSize,
6. so on.

And it is kind of intermingled between each other. Maybe resumbission is required, but now blockspace market conditions are not favorable. We can't resubmit the persisted blobs because MaxBlobSize has been changed. Add here some edge cases (Arbitrum-style out-of-money failure) and I start to think that the proper solution won't fit into the above interface at all.

One solution is to just be hands off: shift the responsibility onto the sequencer. The sequencer will manage the transaction submission itself (which will require some DA specific code). Since the above is quite some logic, and a lot of it can be shared, so some template could be useful to alleviate some pain. Powerful and annoying for the end-users (rollup authors).

Another is where the implementer is in charge of most the logic. After all, it is aware of the details of the chain, so can handle much of the complexity, and will delegate some of the responsibilities to the caller. The interface may get way too complicated, and annoying for DA layer authors. It may also be very tricky to design and then another DA comes along breaks the design.

UPD, found this document, and I learnt that celestia a) drops the transaction from mempool after 5 blocks b) gas is not refunded.