celestiaorg/celestia-node v0.28.1-arabica on GitHub

This release introduces queued transaction submission via #4620.

Queued Transaction Submission ( Parallel Transaction Submission Lanes )

Node runners enable this feature by setting TxWorkerAccounts in the state config:

  [State]
    DefaultKeyName = "my_celes_key"
    DefaultBackendName = "test"
    EstimatorAddress = ""
    EnableEstimatorTLS = false
    TxWorkerAccounts = 8

TxWorkerAccounts defines how many parallel lanes the TxClient will initialize. These lanes are subaccounts funded by the default account to submit PayForBlob transactions in parallel, bypassing account sequence limits and enabling higher throughput (≥ TxWorkerAccounts PayForBlob txs per block).

Example: TxWorkerAccounts = 8 → 7 funded subaccounts + 1 default account, allowing at least 8 PayForBlob txs per block.

⚠️ Important Notes

Not suitable for implementations requiring sequential ordering.
Only valid for unordered transaction workflows.
Parallel submission works only with the default account. Specifying another account in TxConfig bypasses it.

Synchronous Submission

TxWorkerAccounts of 1 → synchronous/queued transaction submission.

Each tx queues until the previous is confirmed.
Preserves ordering and avoids sequence mismatches.
Throughput: ~1 PayForBlob tx per block.

⚠️ Important Notes

If an account other than the default account is specified in TxConfig, the queue is bypassed and txs enter the mempool directly without waiting on confirmations.

Default Behavior (immediate transaction submission)

TxWorkerAccounts defaults to 0 → queued submission disabled. All PayForBlob txs are submitted immediately. This is exactly the same behaviour as before with txs entering the mempool directly without waiting on confirmations.

What's Changed

fix(state): pass long lived core accessor ctx into txclient setup as ctx is now used to control lifecycle of tx workers by @renaynay in #4634

Full Changelog: v0.28.0-arabica...v0.28.1-arabica