[Feature Request]: Add Blob Generation and Commitment Creation in the Celestia Node API

[a26nine]

Implementation ideas

Problem

The current Celestia Node API provides methods like blob.Submit and state.SubmitPayForBlob to handle the submission of blobs. However, it lacks the functionality to generate a blob and its associated commitment through the API. This requires users to generate the blob separately using external tools (e.g., Go/Rust clients), which may lead to a fragmented and less user-friendly experience.

Proposed Enhancement

Introduce a method to the Celestia Node API that allows users to generate a blob directly through the API, preparing it for submission without relying on external tools. This would be similar in function to the eth_signTransaction method in EVM clients, where users can sign and prepare a transaction for submission.

Benefits

Adding this feature would streamline workflows by removing the need for external blob generation tools, creating a more cohesive user experience. It would also improve accessibility for developers who may be unfamiliar with Go or Rust clients, enabling them to generate blobs directly via the API. Overall, this enhancement would allow developers to work entirely within the API environment, reducing dependency on external programming languages and tools.

[jcstein]

generate a blob directly through the API

If the blob is generated/provided by the user, don't you just need the corresponding commitment?

[a26nine]

generate a blob directly through the API

If the blob is generated/provided by the user, don't you just need the corresponding commitment?

Ideally, the response would be a blob struct like:

{
  "namespace": "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAMJ/xGlNMdE=",
  "data": "z8QyNztvogN7NYU27gI+nJgg1vMJtkK3vbduSDz7/8mhmos37I7duH51kkgouxrsdhdOBJ1431OmipNfVedbtwe6zQ06EbJBl/jk4QwwU3S29YBTUZcUfTzXpEJIuMrYzU6YPxN8Zce/KNdsEIy4zxdfxekXpvsgZMBhf83iYgfHvsFAoJmmCp/ORAUoAFf7tJ7cF8RZyA20ftqRa1uhAmktxIb58abpGTG+TNgq3mjyvswECVykJYqGjqNtInyIx2EQOnVp2q69YHkegdoBvoOKzEFigQTdrL2TZBex4MhkrYt7Zf0DQyNMRkCPL/zKYE3bhvXNWMThWCmhD5TOApzirORXKOTB0nxhjDF/aFYkrS+IKBw1KfJ5isldWvmasJBWwRgDuli6Cty67vMMk7fUUTUf0St6rvQeftSoEVlC1xEw46+h5kIXaWiM0g/EzGIAdZHycUFWCSdnt3p7BS5ttEpSf1d6ZbVYYL2y0XguH41k54JqufEMAw9ukmaF0IbN9Jk6fNefV1dsWTdCP6Mz6e+RTCd9DQGqb2VrsvMzx5uVidLD8ND79pvXgL1VzyhJaMTcjSfZK15jOxLwGh1arZc2gyTNiq2pu6wNz0tdJp+fFU+peG8rHN8=",
  "share_version": 0,
  "commitment": "aHlbp+J9yub6hw/uhK6dP8hBLR2mFy78XNRRdLf2794=",
  "index": -1
}

The user can provide namespace and data as arguments to the request.

[Wondertan]

This is good feedback for future Canonical API.

[DioBr4nd0]

Hii @Wondertan @jcstein @a26nine , I would like to contribute on this issue, Please assign this issue to me.
Thanks

[cmwaters]

My two cents is that I don't think you should need the commitment to submit a blob (it can be returned as part of the response, if the user wants to retrieve it again)

[Wondertan]

@a26nine, I am looking through the code, and apparently, if you send a Blob JSON with an empty commitment field, everything should work just fine. Even with JSON containing the field, we don't actually expect it to be populated on the server side and recomputed there anyway.

So, if you submit a Blob with an empty commitment and then request the Block back, presumably, you will get what you ask in this issue without introducing a new API method. Let me know if this resolves your issue.

[a26nine]

@a26nine, I am looking through the code, and apparently, if you send a Blob JSON with an empty commitment field, everything should work just fine. Even with JSON containing the field, we don't actually expect it to be populated on the server side and recomputed there anyway.

So, if you submit a Blob with an empty commitment and then request the Block back, presumably, you will get what you ask in this issue without introducing a new API method. Let me know if this resolves your issue.

Oh, nice! In that case, we don't require a separate API.