feat!(state/core_accessor): add SubmitPayForBlobWithOptions endpoint

[vgonkivs]

Resolves #3346

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 48.93617% with 24 lines in your changes are missing coverage. Please review.

Project coverage is 44.70%. Comparing base (2469e7a) to head (49ea3a1).
Report is 65 commits behind head on main.

Files	Patch %	Lines
nodebuilder/state/mocks/api.go	0.00%	9 Missing ⚠️
state/core_access.go	41.66%	6 Missing and 1 partial ⚠️
nodebuilder/state/flags.go	71.42%	1 Missing and 1 partial ⚠️
nodebuilder/state/keyring.go	66.66%	1 Missing and 1 partial ⚠️
nodebuilder/state/state.go	0.00%	2 Missing ⚠️
nodebuilder/state/stub.go	0.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3349      +/-   ##
==========================================
- Coverage   44.83%   44.70%   -0.13%     
==========================================
  Files         265      272       +7     
  Lines       14620    15283     +663     
==========================================
+ Hits         6555     6833     +278     
- Misses       7313     7660     +347     
- Partials      752      790      +38     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[liamsi]

This PR looks good to me.
Just re-iterating that the most important feature/user-request is that users can submit blobs from different accounts. No other options should be added before that particular one. Having an options struct part of the JSON-RPC further more manifests that this current API is basically driven by implementation details (this is very go idiomatic). No blocker to merge this but sth I wanted to raise.

cc @renaynay

[renaynay]

LGTM - want to discuss the gasLim option there

Should we also update ADR 9 (API ADR)?

[renaynay]

Question for potential follow-up PR:
should we break SubmitPayForBlob on the state level to not take gasLim or fee and just use defaults? And then we can make blob module use SubmitPayForBlobWithOptions under the hood if opts are specified?

[renaynay]

are you not going to check any return val here/

[distractedm1nd]

Are we going to add the optional parameters to the struct in this PR as discussed above?

[distractedm1nd]

LGTM

[vgonkivs]

should we break SubmitPayForBlob on the state level to not take gasLim or fee and just use defaults? And then we can make blob module use SubmitPayForBlobWithOptions under the hood if opts are specified?

Yes, I also thought about it.

[liamsi]

It sounds like there is no consensus around if we should unify SubmitPayForBlob and SubmitPayForBlobWithOptions and fold them into one method. My opinion:

• if we were pre-launch and no-one was using the existing API, we should certainly not expose two very similar methods bu instead fold the functionality into one method.
• now that we are live, we should be very careful with introducing API breaking changes even though the API isn't v1 yet
• unless someone checks with external teams + solutions that they would welcome a cleaner but breaking change and are willing to upgrade their integrations for that asap, we should not break the API (@distractedm1nd and @Bidon15 to verify)

[liamsi]

So currently we already have two methods to submit blobs:

• Blob.Submit(blobs []*blob.Blob, gasPrice blob.GasPrice)uint64perms: write
• State.SubmitPayForBlob(fee state.Int, gasLim uint64, blobs []*blob.Blob)*state.TxResponseperms: write

Not speak of the infamous SubmitTx(tx state.Tx)*state.TxResponse method which is slated to be removed.

This PR introduces another method:

• Blob.SubmitPayForBlobWithOptions

After talking with @renaynay: If we have significant proof that users are currently using the State method instead of the Blob method, then I am also in favour of breaking the current Blob.Submit instead of introducing a third method here!

[distractedm1nd]

Alright, the optional params PR for go-jsonrpc isn’t really workable. It makes all parameters with pointers optional, and it doesn’t solve the problem that the generated client can’t actually mark the methods as optional. Basically, if you don’t send the optional params over the wire, the server will not complain, but the client methods won’t actually reflect that any params are optional.

And, variadics also wouldn’t work - as @vgonkivs pointed out internally, we cannot send our traditional options (which are just function pointers) over the wire.

Given that we want as many users as possible to use blob module, the cleanest way using go-jsonrpc will be to move TxOptions (-> SubmitOptions?) type to the blob module. This would replace the GasLimit parameter. We should define blob.DefaultSubmitOptions() *SubmitOptions and methods like opts.WithGasLimit(...).WithFee(...) for best devex.

As for the state module, we also need to eventually add some sort of TxOptions , which will probably have a lot of overlap with SubmitOptions, but likely with even more parameters. This is not very urgent though. This should be added to all state methods in place of the current parameters. If everyone else agrees with this, I will open an issue and get started on it ASAP