feat: p2p exchange wrapper

[tac0turtle]

Overview

This pr was an idea from @renaynay in which we create an exchange wrapper so that the exchange can check our store before making public requests for data. This would help the edge case i ran into today where the p2p store was missing 40 blocks randomly

[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	Jan 20, 2026, 6:24 PM

[claude]

Claude finished @tac0turtle's task in 2m 39s —— View job

---

Comprehensive Code Review

I've completed a thorough review of this PR. The exchange wrapper implementation is a solid architectural improvement that addresses the issue of missing blocks in the p2p store. However, there are several areas that need attention before merging.

---

1. Code Quality & Architecture

Critical Issues

pkg/sync/exchange_wrapper.go:33-43 - Silent Error Swallowing

ifew.getter!=nil {
ifh, err:=ew.getter(ctx, hash); err==nil&&!h.IsZero() {
returnh, nil
}
}

Problem: Errors from the DA store getter are silently ignored. If the DA store returns a genuine error (not "not found"), we should distinguish between "not found" and "actual error". This masks potential issues like:

• Database connectivity problems
• Corrupted data
• Permission issues

Recommendation: Add logging for non-"not found" errors to aid debugging:

ifew.getter!=nil {
h, err:=ew.getter(ctx, hash)
iferr==nil&&!h.IsZero() {
returnh, nil
}
iferr!=nil&&!errors.Is(err, datastore.ErrNotFound) {
// Log unexpected errors from DA storelog.Debug().Err(err).Msg("DA store getter failed, falling back to p2p")
}
}

Same issue in: GetByHeight (lines 45-55)

---

pkg/sync/exchange_wrapper.go:61-95 - Complex Fallback Logic Without Error Context

The GetRangeByHeight method has sophisticated fallback logic but several issues:

1. Line 71-74: When DA store fails, we completely discard the error and fall back to P2P. This makes debugging very difficult.
2. Line 82-85: The logic assumes that if len(daHeaders) == 0, we should retry the entire range from P2P. However, this could be inefficient if the DA store is having transient issues.
3. Line 88-92: If P2P fails to get the remainder, we return an error, but we lose information about what we already had from DA.

Recommendation:

• Add structured logging to track which code path is taken
• Consider metrics for DA hit rate vs P2P fallback rate
• Log when falling back from DA to P2P with reason

---

pkg/sync/sync_service.go:86-100 - Tight Coupling to DA Store Implementation

The getter functions are tightly coupled to the specific store.Store interface. This creates issues:

1. The getters call daStore.GetBlockByHash(ctx, hash) which returns (header, data, error), but we only use one part
2. For GetByHeight, we use daStore.GetBlockData but discard the data portion
3. @julienrbrt's comment is correct: GetHeader would be less expensive than GetBlockByHash since it doesn't need to retrieve the full block data

Current code:

getter=func(ctx context.Context, hash header.Hash) (*types.Data, error) {
_, d, err:=daStore.GetBlockByHash(ctx, hash) // Wasteful: retrieves header tooreturnd, err
}

Recommendation: Add a GetDataByHash method to the Store interface, or use more specific methods that don't over-fetch.

---

pkg/sync/sync_service.go:94-99 - Range Getter Inefficiency

rangeGetter=func(ctx context.Context, from, touint64) ([]*types.Data, uint64, error) {
returngetContiguousRange(ctx, from, to, func(ctx context.Context, huint64) (*types.Data, error) {
_, d, err:=daStore.GetBlockData(ctx, h)
returnd, err
})
}

This iterates through each height individually calling GetBlockData. For large ranges, this could be extremely inefficient (N database queries). Consider batch operations if the store supports them.

---

Design Concerns

Function Composition Pattern (@renaynay's feedback)

@renaynay suggested passing function implementations directly instead of storing the DA datastore on the wrapper. This is a valid point about reducing coupling:

Current approach: Store daStore + define methods on sync service
Suggested approach: Define standalone functions and pass them directly

Current:

// In sync_service.gogetter=func(ctx context.Context, hash header.Hash) (*types.Data, error) {
_, d, err:=daStore.GetBlockByHash(ctx, hash)
returnd, err
}
// Laterex:=&exchangeWrapper[H]{
getter: getter,
// ...
}

Better (per @renaynay):

// Define as standalone functions or methodsfuncgetDataByHash(daStore store.Store) GetterFunc[*types.Data] {
returnfunc(ctx context.Context, hash header.Hash) (*types.Data, error) {
_, d, err:=daStore.GetBlockByHash(ctx, hash)
returnd, err
}
}
// Then passex:=&exchangeWrapper[H]{
getter: getDataByHash(daStore),
// ...
}

However, the current approach is acceptable. The improvement would be marginal unless we need to swap implementations at runtime.

---

Confusing Naming (@renaynay's feedback on sync_service.go)

The naming of getter, getterByHeight, and rangeGetter in SyncService vs. the function types GetterFunc, GetterByHeightFunc is indeed confusing. Consider more descriptive names:

• daHashGetter instead of getter
• daHeightGetter instead of getterByHeight
• daRangeGetter instead of rangeGetter

This makes it immediately clear these are DA-backed getters.

---

2. Error Handling & Resilience

Missing Error Differentiation

The implementation treats all errors from DA store as "not found" and falls back to P2P. This is problematic for:

1. Transient errors (network timeouts, DB connection issues) - should maybe retry
2. Data corruption errors - should be logged/alerted
3. Permission errors - indicate configuration issues
4. "Not found" errors - expected, should fall back to P2P

Recommendation: Implement error classification:

funcisNotFoundError(errerror) bool {
returnerr!=nil&& (
errors.Is(err, datastore.ErrNotFound) ||errors.Is(err, header.ErrNotFound) ||strings.Contains(err.Error(), "not found")
)
}
// Then in Get:ifew.getter!=nil {
h, err:=ew.getter(ctx, hash)
iferr==nil&&!h.IsZero() {
returnh, nil
}
iferr!=nil&&!isNotFoundError(err) {
// Log unexpected errorslog.Warn().Err(err).Str("hash", hash.String()).Msg("DA store error, falling back to P2P")
}
}

---

No Timeout or Cancellation in DA Store Calls

The getter functions don't enforce timeouts. If the DA store is slow, we should have a timeout before falling back to P2P:

getter=func(ctx context.Context, hash header.Hash) (*types.Data, error) {
ctx, cancel:=context.WithTimeout(ctx, 5*time.Second)
defercancel()
_, d, err:=daStore.GetBlockByHash(ctx, hash)
returnd, err
}

This prevents DA store issues from blocking P2P fallback indefinitely.

---

GetRangeByHeight Partial Success Handling

In GetRangeByHeight (lines 88-92), if we successfully get some headers from DA but P2P fails for the remainder, we return an error and lose the DA data:

p2pHeaders, err:=ew.p2pExchange.GetRangeByHeight(ctx, lastDAHeader, to)
iferr!=nil {
returnnil, err// Lost daHeaders!
}

Consider: Return partial results with error, or document this behavior clearly. The caller might prefer partial data over nothing.

---

3. Security

No Input Validation

The implementation doesn't validate inputs:

1. GetRangeByHeight: No validation that from < to or that heights are reasonable
2. Hash validation: No validation of hash format/length
3. No bounds checking: Large ranges could cause memory issues

Recommendation:

func (ew*exchangeWrapper[H]) GetRangeByHeight(ctx context.Context, fromH, touint64) ([]H, error) {
fromHeight:=from.Height() +1// Validate rangeiffromHeight>=to {
returnnil, fmt.Errorf("invalid range: from=%d >= to=%d", fromHeight, to)
}
// Prevent excessive range requestsconstmaxRangeSize=10000ifto-fromHeight>maxRangeSize {
returnnil, fmt.Errorf("range too large: %d blocks (max %d)", to-fromHeight, maxRangeSize)
}
// ... rest of implementation
}

---

No Rate Limiting on P2P Fallback

If DA store consistently fails, every request will fall back to P2P, potentially overwhelming the P2P network. Consider:

• Circuit breaker pattern
• Rate limiting P2P requests
• Exponential backoff when DA store is unhealthy

---

4. Performance & Resource Efficiency

Memory Allocation in GetRangeByHeight

The getContiguousRange function pre-allocates a slice with capacity to-from:

result:=make([]H, 0, to-from) // pkg/sync/sync_service.go:183

For large ranges, this could allocate significant memory upfront. Consider:

• Streaming/chunked approach
• Dynamic growth with smaller initial capacity
• Maximum range limits (already mentioned in security)

---

Redundant IsZero Checks

The code checks both err == nil && !h.IsZero(). If err == nil, should the header ever be zero? This might indicate unclear error handling from the store interface. Document or fix the contract.

---

No Caching Layer

The implementation directly calls DA store on every request. Consider adding a small in-memory cache for recently accessed headers to reduce DA store load:

typecachedGetterstruct {
cache*lru.CachegetterGetterFunc
}

---

Append Operation in GetRangeByHeight

returnappend(daHeaders, p2pHeaders...), nil// Line 94

This creates a new slice and copies both. For large ranges, this could be expensive. Consider pre-allocating the final slice:

result:=make([]H, len(daHeaders) +len(p2pHeaders))
copy(result, daHeaders)
copy(result[len(daHeaders):], p2pHeaders)
returnresult, nil

---

5. Testing & Reliability

Good Coverage

The tests cover the main scenarios:

• Hit in store
• Miss in store
• Getter not configured
• All from DA
• Partial from DA then P2P
• No range getter fallback

Coverage: 69.09% for the patch is reasonable but could be improved.

---

Missing Test Cases

1. Error scenarios:

   • DA store returns error (not just "not found")
   • P2P fails when DA has partial data
   • Context cancellation during DA fetch
   • Context cancellation during P2P fallback

2. Edge cases:

   • Empty range (from == to)
   • Reverse range (from > to)
   • Very large ranges
   • Zero headers from IsZero() check

3. Concurrency:

   • Multiple goroutines calling Get simultaneously
   • Race conditions on getter function calls

Recommendation: Add these test cases to improve reliability confidence:

funcTestExchangeWrapper_GetDAError(t*testing.T) {
// Test that non-"not found" errors are handled gracefully
}
funcTestExchangeWrapper_ContextCancellation(t*testing.T) {
// Test cancellation during DA fetch and P2P fallback
}
funcTestExchangeWrapper_ConcurrentAccess(t*testing.T) {
// Test race conditions
}

---

Mock Quality

The generated mocks are appropriate. The mockery configuration correctly defines the P2PExchange interface.

---

6. Documentation & Developer Experience

Missing Package Documentation

The exchange_wrapper.go file lacks package-level documentation explaining:

• Why this wrapper exists
• When to use DA store vs P2P
• Fallback behavior
• Performance characteristics

Recommendation: Add package doc:

// Package sync provides P2P synchronization services with DA store optimization.//// The exchangeWrapper implements a two-tier caching strategy:// 1. First checks local DA store for blocks/headers// 2. Falls back to P2P network if not found locally//// This reduces P2P bandwidth and improves performance when data is available locally.package sync

---

Function Documentation Could Be Improved

Current documentation is minimal. For example:

// GetterFunc retrieves a header by hash from a backing store.typeGetterFunc[H header.Header[H]] func(context.Context, header.Hash) (H, error)

Better:

// GetterFunc retrieves a header by hash from a backing store (typically DA store).// Returns the header if found, or an error if not found or if retrieval failed.// Implementations should return datastore.ErrNotFound for missing headers to enable// proper fallback behavior.typeGetterFunc[H header.Header[H]] func(context.Context, header.Hash) (H, error)

---

No Examples or Usage Guidance

Consider adding examples in the doc comments or in a separate example file showing:

• How the wrapper is initialized
• What happens during DA hit vs miss
• How errors are handled

---

Confusing Interface Naming

The P2PExchange interface (lines 19-24) wraps header.Exchange[H] and adds Start/Stop. This naming is confusing because:

• The exchangeWrapper also deals with P2P
• It's not immediately clear this is specifically for the go-header Exchange

Consider: StartableExchange or ManagedExchange

---

7. Addressing Existing Review Comments

@julienrbrt's comment: "GetHeader is less expensive"

✅ Valid: Using GetBlockByHash when you only need the header is wasteful. The store should provide GetHeaderByHash or similar.

@julienrbrt's comment: "What is this used for now?"

Refers to line in sync_service.go. Without seeing the diff, I assume this refers to removed/changed code. The getters are now used by the exchange wrapper.

@renaynay's comment: "don't need to nest this call"

✅ Valid: If daStore is always provided to the constructor, the nil checks are unnecessary. However, the code currently allows daStore to be nil (light nodes), so the checks are appropriate. But the logic could be cleaner.

@renaynay's comment: "define as functions that don't take the store"

✅ Valid: As discussed above, this would reduce coupling slightly but is not critical.

@renaynay's comment on GetRangeByHeight:61

✅ Critical: "You need to actually implement this method w/ the p2p as a fallback system bc this is the method called by syncer."

This is already implemented (lines 61-95), so this comment might be outdated or misunderstood. The implementation does exactly what was requested:

• Checks DA store for contiguous range
• Requests remainder from P2P if needed
• Combines results

@renaynay's comment: "confusing naming"

✅ Valid: As discussed above.

---

Summary of Recommendations

Must Fix (Blocking)

1. ❌ Add logging for DA store errors (not just silent fallback)
2. ❌ Fix inefficient store method usage (GetBlockByHash when only header needed)
3. ❌ Add input validation for range requests
4. ❌ Improve error handling to distinguish error types

Should Fix (Important)

5. ⚠️ Add timeout/cancellation for DA store calls
6. ⚠️ Improve function naming for clarity (getter → daHashGetter, etc.)
7. ⚠️ Add missing test cases (error scenarios, edge cases, concurrency)
8. ⚠️ Add package and function documentation
9. ⚠️ Consider batch operations for range queries

Nice to Have (Optional)

10. 💡 Add metrics for DA hit rate vs P2P fallback
11. 💡 Consider caching layer for frequently accessed headers
12. 💡 Optimize slice allocation in GetRangeByHeight
13. 💡 Add circuit breaker for P2P fallback
14. 💡 Add usage examples in documentation

---

Positive Aspects

✅ Clean abstraction - The function type approach is flexible and testable
✅ Proper use of generics - Type safety for headers vs data
✅ Comprehensive tests - Good coverage of main scenarios
✅ Addresses real problem - Solves the missing blocks issue
✅ Backwards compatible - Graceful degradation when DA store is nil

---

Conclusion

This is a solid architectural improvement that addresses a real problem. The core design is sound, but the implementation needs refinement in error handling, efficiency, and documentation. The issues identified are not fundamental flaws but areas where production-grade polish is needed.

Recommendation: Request changes focusing on error handling, logging, and efficiency improvements before merging.

---

[codecov]

Codecov Report

❌ Patch coverage is 55.31915% with 42 lines in your changes missing coverage. Please review.
✅ Project coverage is 59.18%. Comparing base (140b24a) to head (f5db392).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
pkg/sync/sync_service.go	39.28%	30 Missing and 4 partials ⚠️
pkg/sync/exchange_wrapper.go	75.00%	5 Missing and 3 partials ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #2855 +/- ##
==========================================
- Coverage 59.26% 59.18% -0.09% 
==========================================
Files 108 109 +1 Lines 10103 10180 +77 ==========================================
+ Hits 5988 6025 +37 - Misses 3484 3518 +34 - Partials 631 637 +6 

Flag	Coverage Δ
combined	59.18% <55.31%> (-0.09%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.