feat: DA Client remove interface part 2, replace types with new code

[randygrok]

Overview

[github-actions]

The latest Buf updates on your PR. Results from workflow CI / buf-check (pull_request).

Build	Format	Lint	Breaking	Updated (UTC)
✅ passed	⏩ skipped	✅ passed	✅ passed	Dec 4, 2025, 4:33 PM

[claude]

Claude finished @randygrok's task —— View job

---

Code Review Complete

I've conducted a comprehensive review of the DA client refactoring changes across all 22 modified files. This is a significant architectural improvement that moves from generic interfaces to concrete, type-safe structures.

Summary

Overall Assessment: This refactoring is well-executed with solid architecture, comprehensive testing, and good error handling. However, I've identified one critical bug (already flagged by Gemini), several important improvements, and some minor issues that should be addressed before merging.

---

Critical Issues

1. Loss of Error Handling in block/internal/da/client.go:161-164 ⚠️ HIGH PRIORITY

File: block/internal/da/client.go:161-164

The blob.SplitID function signature changed from returning (uint64, Commitment, error) to (uint64, Commitment). The current code checks a stale err variable from line 94 (the SubmitWithOptions call), which is guaranteed to be nil at this point since we're in the success path.

Current code:

height, _ = blob.SplitID(ids[0])
if err != nil {
    c.logger.Error().Err(err).Msg("failed to split ID")
}

Problem: If ids[0] is malformed, blob.SplitID now returns (0, nil) with no way to detect the error. The dead error check gives false confidence.

Recommended fix:

if h, com := blob.SplitID(ids[0]); com != nil {
    height = h
} else {
    c.logger.Error().Msg("failed to split ID: malformed ID")
}

---

Important Issues

2. Duplicate Error Code Registration in da/jsonrpc/errors.go:14,17

File: da/jsonrpc/errors.go:14,17

errs.Register(jsonrpc.ErrorCode(datypes.StatusContextDeadline), &datypes.ErrTxTimedOut)     // line 14
// ... other registrations
errs.Register(jsonrpc.ErrorCode(datypes.StatusContextDeadline), &datypes.ErrContextDeadline) // line 17

Problem: StatusContextDeadline is registered twice with different error values. The second registration will overwrite the first. This creates ambiguity and potential runtime issues with error deserialization.

Recommended fix: Review the intended error mapping. If ErrTxTimedOut and ErrContextDeadline should map to different codes, use distinct StatusCode values. Otherwise, consolidate to a single error type.

3. Silent Error Swallowing in pkg/da/types/namespace.go:79

File: pkg/da/types/namespace.go:79

func NamespaceFromString(s string) *Namespace {
    hash := sha256.Sum256([]byte(s))
    ns, _ := NewNamespaceV0(hash[:NamespaceVersionZeroDataSize])
    return ns
}

Problem: The error from NewNamespaceV0 is silently discarded with _. While NewNamespaceV0 can only fail if data exceeds 10 bytes (which can't happen here since we're slicing to exactly 10 bytes), this pattern is fragile:

• Future maintainers might not understand why it's safe
• Code analysis tools will flag this as suspicious
• If NewNamespaceV0 validation logic changes, this could panic or return nil

Recommended fix: Either add a comment explaining why this can't fail, or use MustNewNamespaceV0 pattern:

func NamespaceFromString(s string) *Namespace {
    hash := sha256.Sum256([]byte(s))
    // Safe to ignore error: hash is exactly 32 bytes, we slice to 10
    ns, _ := NewNamespaceV0(hash[:NamespaceVersionZeroDataSize])
    return ns
}

4. Error Handling Uses String Matching Instead of errors.Is in Multiple Files

Files:

• block/internal/da/client.go:188,199
• block/internal/da/celestia_client.go:193,202
• da/jsonrpc/client.go:71,75,79

Problem: Code uses strings.Contains(err.Error(), ...) to detect specific errors instead of errors.Is(). This is fragile because:

• Error messages can change
• Wrapped errors might not preserve the exact string
• It's not the idiomatic Go approach

Example from client.go:188:

if strings.Contains(err.Error(), datypes.ErrBlobNotFound.Error()) {
    // handle...
}

Context: I understand this pattern is necessary for errors that cross RPC boundaries where errors.Is wrapping isn't preserved. However, this should be:

1. Documented with comments explaining why string matching is necessary
2. Potentially improved with explicit error codes in the RPC protocol

Recommended improvement: Add comments explaining the RPC serialization constraint:

// String matching required since RPC serialization doesn't preserve error wrapping
if strings.Contains(err.Error(), datypes.ErrBlobNotFound.Error()) {

---

Code Quality & Architecture

Strengths ✅

1. Excellent Type Safety: Moving from generic []byte types to concrete datypes.Namespace with validation is a significant improvement
2. Comprehensive Namespace Tests: pkg/da/types/namespace_test.go has excellent coverage with 338 lines testing edge cases, Celestia spec compliance, and real-world scenarios
3. Clear Separation of Concerns: The new package structure (pkg/da/types, pkg/blob) creates clean boundaries
4. Consistent Error Handling: New datypes.StatusCode enum provides type-safe error classification
5. Good Documentation: Functions like NewNamespaceV0 have clear docstrings

Suggestions for Improvement

5. Missing Godoc for Exported Types

File: pkg/da/types/errors.go

All exported error variables lack documentation. Add comments:

// ErrBlobNotFound indicates the requested blob was not found in the DA layer.
var ErrBlobNotFound = errors.New("blob: not found")

// ErrBlobSizeOverLimit indicates the blob size exceeds the maximum allowed.
var ErrBlobSizeOverLimit = errors.New("blob: over size limit")
// ... etc

6. Namespace Validation Could Be More Explicit

File: pkg/da/types/namespace.go:36-47

The IsValidForVersion0() method validates but doesn't explain why validation failed. Consider returning an error:

func (n Namespace) ValidateForVersion0() error {
    if n.Version != NamespaceVersionZero {
        return fmt.Errorf("invalid version: expected %d, got %d", NamespaceVersionZero, n.Version)
    }
    for i := range NamespaceVersionZeroPrefixSize {
        if n.ID[i] != 0 {
            return fmt.Errorf("invalid version 0 namespace: byte %d in prefix must be zero", i)
        }
    }
    return nil
}

This provides better debugging information when validation fails.

---

Error Handling & Resilience

Strengths ✅

1. Proper Context Cancellation: Both clients handle context.Canceled explicitly
2. Timeout Management: Per-operation timeouts with context.WithTimeout are well-implemented
3. Detailed Error Messages: Errors include sufficient context (height, namespace, batch info)
4. Batched Retrieval: client.go:243-264 implements retrieval batching with per-batch timeouts

Concerns

7. Partial Batch Failure Handling

File: block/internal/da/client.go:243-264

for i := 0; i < len(idsResult.IDs); i += batchSize {
    end := min(i+batchSize, len(idsResult.IDs))
    getBlobsCtx, cancel := context.WithTimeout(ctx, c.defaultTimeout)
    batchBlobs, err := c.da.Get(getBlobsCtx, idsResult.IDs[i:end], namespace)
    cancel()
    if err != nil {
        // Returns error for entire operation
        return datypes.ResultRetrieve{...}
    }
    blobs = append(blobs, batchBlobs...)
}

Issue: If batch 5 of 10 fails, the entire retrieval fails and previous batches are lost. This might be intentional, but consider:

• Whether partial results should be returned with a warning
• Adding retry logic for failed batches
• Documenting the all-or-nothing behavior

8. Missing Input Validation

File: block/internal/da/celestia_client.go:62

The Submit method doesn't validate that data and options aren't nil before use. While this might be caught downstream, defensive checks at API boundaries improve robustness:

func (c *CelestiaBlobClient) Submit(ctx context.Context, data [][]byte, namespace []byte, options []byte) datypes.ResultSubmit {
    if len(data) == 0 {
        return datypes.ResultSubmit{
            BaseResult: datypes.BaseResult{
                Code:    datypes.StatusSuccess,
                Message: "no data to submit",
            },
        }
    }
    // ... rest of function
}

---

Security

Strengths ✅

1. No Hardcoded Secrets: No credentials or sensitive data in code
2. Namespace Validation: ValidateForVersion0 prevents malformed namespaces
3. Size Limits: MaxBlobSize checks prevent resource exhaustion
4. Authorization Handling: JSONRPC client properly handles auth headers

Concerns

9. Namespace Logging Could Expose Sensitive Data

Files: Multiple (e.g., da/jsonrpc/client.go:49, da/jsonrpc/server.go:46)

api.Logger.Debug().Str("namespace", hex.EncodeToString(ns)).Msg("Making RPC call")

Consideration: If namespaces contain or correlate to sensitive information, logging them at Debug level could be a privacy concern. Review whether:

• Namespace values should be considered sensitive
• Logging should be at Trace level only
• Namespace should be hashed or truncated in logs

---

Performance & Resource Efficiency

Strengths ✅

1. Batch Processing: Retrieval batching (150 items default) prevents memory exhaustion
2. Efficient Namespace Storage: Pre-calculated namespace bytes in constructors avoid repeated conversions
3. Proper Goroutine Management: HTTP server uses atomic.Bool for start/stop safety

Suggestions

10. Potential Memory Allocation in Hot Path

File: pkg/da/types/namespace.go:28-33

func (n Namespace) Bytes() []byte {
    result := make([]byte, NamespaceSize)
    result[NamespaceVersionIndex] = n.Version
    copy(result[NamespaceVersionSize:], n.ID[:])
    return result
}

This allocates a new slice on every call. If called in hot paths, consider:

• Caching the byte representation in the struct
• Accepting a pre-allocated buffer: func (n Namespace) WriteBytes(buf []byte) error

Trade-off: Current approach is simple and correct. Only optimize if profiling shows it's a bottleneck.

11. Blob Size Validation Order

File: block/internal/da/celestia_client.go:80-88

for i, raw := range data {
    if uint64(len(raw)) > c.maxBlobSize {
        return datypes.ResultSubmit{...}
    }
    blobs[i], err = blob.NewBlobV0(ns, raw)
    // ...
}

Optimization: Check all blob sizes before creating any Blob objects. If any blob exceeds the limit, you avoid the overhead of creating blobs that will be discarded:

// First pass: validate all sizes
for i, raw := range data {
    if uint64(len(raw)) > c.maxBlobSize {
        return datypes.ResultSubmit{...}
    }
}

// Second pass: create blobs
blobs := make([]*blob.Blob, len(data))
for i, raw := range data {
    blobs[i], err = blob.NewBlobV0(ns, raw)
    // ...
}

---

Testing Coverage

Strengths ✅

1. Excellent Namespace Tests: 338 lines with edge cases, spec compliance, and real-world scenarios
2. Integration Tests: JSONRPC proxy tests with concurrent read/write scenarios
3. Mock Infrastructure: Well-structured mocks in client_test.go
4. Table-Driven Tests: Good use of table-driven patterns in namespace_test.go

Gaps

12. Missing Error Path Tests

File: pkg/da/types/namespace_test.go

While the happy paths are well-tested, I don't see tests for:

• NamespaceFromString with empty string or very long strings
• ParseHexNamespace with various malformed inputs (odd-length hex, invalid characters at different positions)
• Boundary conditions in NewNamespaceV0 (exactly 10 bytes vs 11 bytes)

13. No Tests for New Client Methods

File: block/internal/da/client_test.go

The test file only shows 100 lines (truncated), but I don't see tests for:

• RetrieveHeaders, RetrieveData, RetrieveForcedInclusion methods
• Namespace getter methods
• Error propagation from the underlying DA layer
• Timeout behavior

Recommendation: Add tests covering all public methods and error paths.

---

Documentation

Strengths ✅

1. Package Comments: Files have clear package-level documentation
2. Method Comments: Most exported functions have docstrings
3. Inline Comments: Complex logic (e.g., batch retrieval) has explanatory comments

Improvements

14. Missing README for New Packages

Packages: pkg/da/types/, pkg/namespace/

Add README.md files explaining:

• Package purpose and responsibilities
• Relationship to Celestia namespace spec
• Usage examples
• Migration guide from old core/da types

15. Undocumented Celestia Spec Compliance

File: pkg/da/types/namespace.go

While the tests reference Celestia spec compliance, the production code lacks comments linking to the spec. Add:

// Namespace mirrors Celestia's namespace layout (version + 28-byte ID).
// See: https://github.com/celestiaorg/celestia-specs/blob/main/src/specs/data_structures.md#namespace
type Namespace struct {
    Version uint8
    ID      [NamespaceIDSize]byte
}

---

Additional Observations

16. Inconsistent Nil Checks

Compare these two patterns:

celestia_client.go:146:

if len(blobs) == 0 {
    return datypes.ResultSubmit{...}
}

client.go:148:

if len(ids) == 0 && len(data) > 0 {
    return datypes.ResultSubmit{...}
}

The first checks for empty blobs after successful submission, the second checks for inconsistent state. Consider if both should check for consistency (len(data) > 0 guard).

17. Magic Numbers

File: block/internal/da/client.go:48

const (
    defaultRetrieveBatchSize = 150
)

Why 150? Add a comment explaining the reasoning (e.g., "balances memory usage vs RPC round trips" or "matches upstream Celestia client defaults").

---

Recommendations Summary

Must Fix Before Merge

1. ⚠️ Critical: Fix dead error check in client.go:161-164
2. Fix duplicate error code registration in errors.go:14,17

Should Fix Before Merge

3. Add safety comment or pattern to NamespaceFromString error handling
4. Document why string matching is used for RPC errors (or improve error protocol)
5. Add godoc for all exported error variables

Consider for Follow-up

6. Enhance namespace validation to return descriptive errors
7. Review partial batch failure behavior
8. Add input validation at API boundaries
9. Review namespace logging for privacy implications
10. Profile and optimize hot path allocations if needed
11. Optimize blob size validation order
12. Expand test coverage for error paths
13. Add tests for all new client methods
14. Add README files for new packages
15. Link to Celestia spec in documentation
16. Clarify empty slice handling patterns
17. Document magic numbers

---

Conclusion

This is a well-executed refactoring that significantly improves type safety and code organization. The new pkg/da/types package provides a solid foundation for future development. Once the critical bug and duplicate error registration are fixed, this will be ready to merge.

The codebase follows good Go idioms, has solid test coverage, and demonstrates careful attention to error handling and resource management. Great work on this substantial refactoring! 🎉

---

[gemini-code-assist]

Summary of Changes

Hello @randygrok, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request undertakes a significant refactoring of the Data Availability (DA) client architecture. The primary goal is to streamline interactions with the Celestia network by introducing a dedicated Celestia-specific client and replacing abstract DA interface types with concrete, purpose-built structures. This approach enhances type safety and reduces the project's dependency footprint on larger Celestia libraries, while ensuring full compatibility with the Celestia blob RPC. The changes are supported by comprehensive dependency updates and new integration tests to verify the robustness of the new implementation.

Highlights

• DA Client Refactoring: The core Data Availability (DA) client interface has been refactored to remove generic types and replace them with new, more specific types defined in the pkg/da/types package. This change impacts how DA submission and retrieval results are handled.
• New Celestia Client Implementation: A new CelestiaBlobClient has been introduced in block/internal/da, providing a concrete implementation for interacting with the Celestia blob RPC. This client handles namespace management, blob submission, and retrieval, including detailed error mapping.
• Celestia-Node Type Integration: Key data structures and RPC client definitions from celestia-node (e.g., Blob, Commitment, SubmitOptions, BlobAPI) have been selectively copied and trimmed into new da/celestia and pkg/blob packages. This strategy aims to maintain JSON compatibility with Celestia's blob RPC while minimizing external dependencies.
• Dependency Updates: Numerous go.mod and go.sum files across apps/evm, apps/grpc, apps/testapp, da, and the root module have been updated. This includes adding new Celestia-related dependencies like celestiaorg/go-square/merkle and celestiaorg/nmt, as well as other utility libraries.
• New Integration Tests: A new end-to-end integration test (test/e2e/integration/celestia_client_integration_test.go) has been added to validate the CelestiaBlobClient's functionality against a real Celestia network, ensuring proper blob submission and retrieval.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request continues the refactoring of the Data Availability (DA) client by moving types, errors, and namespace logic out of the core/da package and into new, more modular packages like pkg/da/types and pkg/namespace. The changes are mostly mechanical, replacing old type references with new ones across several files. The refactoring is well-executed, and new tests have been added for the extracted namespace logic. I found one issue where a change in a function's signature led to the loss of error handling for malformed IDs. I've provided a suggestion to fix this.

[gemini-code-assist]

The blob.SplitID function signature is different from the old coreda.SplitID; it no longer returns an error. Instead, it returns a nil commitment for a malformed ID. The current if err != nil check is using a stale err variable from a previous call, which is guaranteed to be nil at this point. This makes the block dead code and removes the error handling for a malformed ID.

I suggest restoring the check by verifying if the returned commitment is nil and logging an error if so.

		if h, com := blob.SplitID(ids[0]); com != nil {
			height = h
		} else {
			c.logger.Error().Msg("failed to split ID: malformed ID")
		}