feat(client): run Fibre operations locally instead of via bridge#4961
Merged
walldiss merged 2 commits intocelestiaorg:feature/fibrefrom Apr 23, 2026
Merged
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## feature/fibre #4961 +/- ##
================================================
Coverage ? 34.22%
================================================
Files ? 317
Lines ? 26126
Branches ? 0
================================================
Hits ? 8941
Misses ? 16182
Partials ? 1003 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
api/client.Client constructs its own appfibre.Client and wraps the shared fibre.Service with the local nodebuilder/fibre.Module, so Fibre.Submit, Upload, Download and escrow ops hit consensus gRPC + FSPs directly. The bridge hop is only kept for ReadClient (read-only users) and Blob.Subscribe, matching the pattern used by Blob.Submit today. Implements the ADR-013 async submission contract on fibre.Service.Upload: MsgPayForFibre is broadcast in a background goroutine with a fresh context so callers return as soon as off-chain upload and sig aggregation complete. Per-goroutine timeout bounds the leak; a follow-up PR will add waitgroup tracking and Service.Stop() lifecycle. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
aff4f3c to
577a71b
Compare
vgonkivs
reviewed
Apr 22, 2026
- fibre/service.go: default nil TxConfig in Upload so the async MsgPayForFibre goroutine doesn't panic on SubmitMessage, and add a TODO marking the sync-in-goroutine approach as a stopgap until QueuedTxClient lands. - api/client/client.go: collect shutdown errors with errors.Join so one failing Stop doesn't leak the other resources (gRPC conn, blob svc, core accessor, tx client, appfibre client). - nodebuilder/fibre/module.go: drop "full nodes" from the NewModule doc — celestia-node has only Bridge and Light. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
vgonkivs
approved these changes
Apr 23, 2026
3 tasks
julienrbrt
pushed a commit
to evstack/ev-node
that referenced
this pull request
Apr 23, 2026
Adds tools/celestia-node-fiber, a new Go sub-module that implements the ev-node fiber.DA interface by delegating Upload, Download and Listen to a celestia-node api/client.Client. Upload and Download run locally against a Celestia consensus node (gRPC) and Fibre Storage Providers (Fibre gRPC) — no bridge-node hop — using celestia-node's self-sufficient client (celestiaorg/celestia-node#4961). Listen subscribes to blob.Subscribe on a bridge node and forwards only share-version-2 blobs, which is how Fibre blobs settle on-chain via MsgPayForFibre. The package lives in its own go.mod, parallel to tools/local-fiber, so ev-node core does not inherit celestia-app / cosmos-sdk replace-directive soup. A FromModules constructor accepts the Fibre and Blob Module interfaces directly so callers can inject mocks or share an existing *api/client.Client. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
api/client.Clientnow builds a local*appfibre.Client+*fibre.Serviceand replacesc.Fibrewithnodebuilder/fibre.NewModule(svc).Fibre.Submit,Upload,Downloadand all escrow ops run directly against consensus gRPC + FSPs — no bridge hop.nodebuilder/fibre.NewModulesoapi/clientand the bridge share the sameModulewrapping logic.modulestays unexported; only the constructor moves.fibre.Service.Uploadnow fires theMsgPayForFibrebroadcast in a background goroutine with a freshcontext.Background()+ 2-minute timeout. Errors log; the caller returns as soon as off-chain upload + validator sig aggregation completes.ReadClient.Fibre(JSON-RPC to the bridge) is unchanged — read-only users keep working.Client.Close()stops the localappfibre.Clientbefore tearing down the gRPC conn.Why
ADR-013 scoped the Fibre read path via
blob.Subscribeon the node, but the submit path was routed through the bridge by JSON-RPC even though every Fibre method can execute locally given a keyring and a consensus endpoint — the same setupBlob.Submitalready uses viablobSubmitClient. Routing through the bridge adds a hop, a base64-encoded 128 MiB payload on the write path, and a third-party dependency for callers that already hold consensus gRPC + a signer.Follow-up
sync.WaitGroup+Service.Stop()tofibre.ServicesoClient.Close()can wait for in-flight asyncMsgPayForFibrebroadcasts before tearing down the tx client. Keeping this out of this PR to keep the diff focused.Test plan
go build -tags fibre ./...go vet -tags fibre ./...go test -tags fibre -count=1 -run TestFibreEscrow ./api/client/...— new test covering Deposit → QueryEscrowAccount → Withdraw → PendingWithdrawals end-to-end over the locally-wired Fibre module.go test -tags fibre -count=1 -run TestSubmission ./api/client/...— existing Blob.Submit path unaffected.TestFibreEscrowdoes not coverUpload/Download/Submitbecause the default testnode validators don't run Fibre servers — Upload fails with "not enough voting power: collected 0". That path is validated at integration level against a fibre-enabled network.🤖 Generated with Claude Code