Skip to content

L2ps simplified #495

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
tcsenpai wants to merge 65 commits into
base: testnet
Choose a base branch
from
Open

L2ps simplified #495

tcsenpai wants to merge 65 commits into from

Conversation

@tcsenpai
Copy link
Contributor

@tcsenpai tcsenpai commented Nov 8, 2025 •
edited by coderabbitai bot
Loading

User description

L2PS Reworking

PR Type

Enhancement

Description

Complete L2PS (Layer 2 Private Subnet) and DTR (Distributed Transaction Routing) Implementation

Core Features Implemented:

  • L2PS Network Management: Refactored to singleton pattern with lazy initialization, transaction encryption/decryption, and signature verification using UnifiedCrypto

  • L2PS Mempool Manager: New dedicated mempool for L2PS transactions with duplicate detection, hash generation, and comprehensive statistics

  • Validator Hash Service: Periodic L2PS hash generation and relay to validators every 5 seconds with reentrancy protection

  • DTR Transaction Routing: Non-validator nodes relay transactions to validators with parallel relay (5 validator concurrency limit) and retry mechanism

  • L2PS Concurrent Sync: Peer discovery and mempool synchronization across L2PS participants with incremental sync and batch duplicate detection

  • Instant Messaging Enhancement: Offline message storage with DoS protection, blockchain integration, and nonce-based replay prevention using mutex-based thread-safe operations

  • Validator Consensus: L2PS hash mapping manager for validators with atomic upsert operations and content-blind privacy model

  • Background Services: DTR relay retry service with validator caching optimization and L2PS hash generation service with graceful shutdown

Database & Entity Changes:

  • New L2PSMempool entity with composite indexing for efficient transaction querying

  • New L2PSHashes entity for validator consensus with UID-to-hash mappings

  • New OfflineMessages entity for instant messaging with status tracking

  • Updated GCRSubnetsTxs entity to use L2PSTransaction type

  • Datasource refactored to singleton pattern

Integration Points:

  • L2PS transaction handler with mempool integration and signature verification

  • NodeCall endpoints for L2PS participation queries, mempool info, and transaction retrieval

  • Concurrent L2PS sync during blockchain synchronization

  • DTR relay handler with validator status verification

  • Shared state extensions for DTR caching and L2PS participation tracking

Infrastructure:

  • Added async-mutex dependency for synchronization primitives

  • Updated @kynesyslabs/demosdk to ^2.2.71

  • Comprehensive documentation and implementation guides for L2PS phases and DTR architecture

  • Development guidelines and onboarding documentation for future sessions

Diagram Walkthrough

flowchart LR
  A["Non-Validator Nodes"] -- "DTR Relay" --> B["Validators"]
  C["L2PS Participants"] -- "Transaction Submit" --> D["L2PS Mempool"]
  D -- "Hash Generation" --> E["L2PS Hash Service"]
  E -- "Relay Hashes" --> B
  F["Peer Nodes"] -- "Concurrent Sync" --> C
  G["Instant Messaging"] -- "Offline Storage" --> H["OfflineMessages Entity"]
  H -- "Delivery on Reconnect" --> I["Message Recipients"]
  D -- "Duplicate Detection" --> J["Original Hash Tracking"]
  B -- "Consensus" --> K["L2PS Hashes Entity"]
Loading

File Walkthrough
Relevant files
Enhancement
21 files
parallelNetworks.ts
L2PS Network Management Refactored to Singleton Pattern   

src/libs/l2ps/parallelNetworks.ts

  • Complete rewrite from old Subnet class to new ParallelNetworks
    singleton managing multiple L2PS networks
  • Implements lazy initialization with promise locking to prevent race
    conditions during loadL2PS()
  • Adds comprehensive L2PS transaction encryption/decryption with
    signature verification using UnifiedCrypto
  • Introduces L2PSNodeConfig interface for configuration management with
    file-based key loading and validation
  • Adds transaction processing pipeline with processL2PSTransaction() for
    mempool integration
 +379/-216
signalingServer.ts
Instant Messaging with Offline Storage and Nonce Management

src/features/InstantMessagingProtocol/signalingServer/signalingServer.ts

  • Adds mutex-based thread-safe nonce management for transaction
    uniqueness and replay prevention
  • Implements offline message storage with DoS protection (rate limiting
    per sender with MAX_OFFLINE_MESSAGES_PER_SENDER)
  • Adds blockchain storage for both online and offline messages with
    mandatory audit trail consistency
  • Implements offline message delivery on peer reconnection with
    transactional semantics and WebSocket state checking
  • Adds per-sender nonce counter and offline message count tracking with
    atomic operations via Mutex
 +303/-13
l2ps_mempool.ts
L2PS Mempool Manager with Hash Generation                               

src/libs/blockchain/l2ps_mempool.ts

  • New L2PS-specific mempool manager with lazy initialization and promise
    locking for race condition prevention
  • Implements consolidated hash generation for L2PS networks with
    deterministic ordering for validator relay
  • Adds duplicate detection via both original and encrypted transaction
    hashes
  • Provides transaction status tracking, cleanup routines, and
    comprehensive statistics
  • Includes block number validation and error handling for edge cases
 +477/-0 
L2PSHashService.ts
L2PS Hash Generation and Validator Relay Service                 

src/libs/l2ps/L2PSHashService.ts

  • New service for periodic L2PS hash generation and relay to validators
    every 5 seconds
  • Implements reentrancy protection to prevent overlapping hash
    generation cycles
  • Reuses Demos SDK instance for efficiency instead of creating new
    instances per cycle
  • Relays hash updates to validators via DTR infrastructure with
    sequential fallback
  • Includes comprehensive statistics tracking and graceful shutdown
    support
 +410/-0 
endpointHandlers.ts
DTR Transaction Routing and L2PS Hash Update Handling       

src/libs/network/endpointHandlers.ts

  • Adds DTR (Distributed Transaction Routing) logic for non-validator
    nodes to relay transactions to validators
  • Implements parallel relay with concurrency limiting (5 validators)
    using Promise.allSettled()
  • Adds handleL2PSHashUpdate() handler for processing L2PS hash updates
    from other nodes
  • Validates L2PS hash payload structure and stores hashes for validator
    consensus
  • Adds ValidityData caching for retry service and fallback local storage
 +199/-34
relayRetryService.ts
DTR Relay Retry Service with Validator Optimization           

src/libs/network/dtr/relayRetryService.ts

  • New background service for retrying failed transaction relays from
    non-validator nodes to validators
  • Implements optimized validator caching (only recalculates when block
    number changes)
  • Adds timeout protection (5 seconds) for validator calls to prevent
    indefinite hanging
  • Implements Fisher-Yates shuffle for truly uniform random validator
    selection
  • Includes cleanup routines for stale retry entries and ValidityData
    cache eviction
 +343/-0 
L2PSConcurrentSync.ts
L2PS Concurrent Sync and Peer Discovery                                   

src/libs/l2ps/L2PSConcurrentSync.ts

  • New module for L2PS participant discovery and mempool synchronization
    across peers
  • Implements parallel peer queries for L2PS participation discovery with
    graceful failure handling
  • Adds incremental sync with timestamp-based filtering to avoid
    redundant transfers
  • Implements batch duplicate detection for efficiency and safe
    repository access checks
  • Includes participation exchange broadcast and randomized UUID
    generation for muid collision prevention
 +303/-0 
l2ps_hashes.ts
L2PS Hash Mapping Manager for Validator Consensus               

src/libs/blockchain/l2ps_hashes.ts

  • New manager for L2PS UID to hash mappings used by validators for
    consensus
  • Implements atomic upsert operations to prevent race conditions from
    concurrent updates
  • Provides hash retrieval, statistics, and pagination support for
    monitoring
  • Stores only hash mappings (content-blind) to preserve privacy for
    validators
  • Includes comprehensive error handling and initialization validation
 +237/-0 
GCRSubnetsTxs.ts
Update GCR Subnet Transactions Type Definition                     

src/model/entities/GCRv2/GCRSubnetsTxs.ts

  • Updates tx_data column type from EncryptedTransaction to
    L2PSTransaction
  • Aligns entity with new L2PS transaction type definitions from SDK
 +2/-2     
handleL2PS.ts
L2PS transaction handler refactoring with mempool integration

src/libs/network/routines/transactions/handleL2PS.ts

  • Refactored L2PS transaction handler with comprehensive validation and
    error handling for nested data structures
  • Integrated L2PS mempool storage with duplicate detection via
    original_hash field
  • Added transaction decryption with signature verification and encrypted
    payload validation
  • Implemented structured response with encrypted hash, original hash,
    and L2PS UID tracking
 +124/-37
manageNodeCall.ts
DTR relay and L2PS mempool synchronization endpoints         

src/libs/network/manageNodeCall.ts

  • Added DTR relay transaction handler (RELAY_TX case) with validator
    status verification and transaction validation
  • Implemented three L2PS NodeCall endpoints: getL2PSParticipationById,
    getL2PSMempoolInfo, getL2PSTransactions
  • Added comprehensive error handling and logging for DTR relay
    operations and L2PS mempool queries
  • Integrated transaction coherence and signature validation before
    mempool insertion
 +167/-5 
Sync.ts
Concurrent L2PS sync integration with blockchain synchronization

src/libs/blockchain/routines/Sync.ts

  • Added concurrent L2PS participant discovery during block sync via
    discoverL2PSParticipants()
  • Integrated L2PS mempool synchronization with peers during block
    download via syncL2PSWithPeer()
  • Added L2PS participation exchange with newly discovered peers via
    exchangeL2PSParticipation()
  • All L2PS operations run non-blocking in background to preserve
    blockchain sync performance
 +53/-0   
index.ts
Background service initialization for DTR and L2PS             

src/index.ts

  • Added DTR relay retry service initialization with production mode
    check
  • Added L2PS hash generation service startup for participating nodes
  • Implemented graceful shutdown handlers (SIGINT/SIGTERM) for both DTR
    and L2PS services
  • Services initialize after main loop to ensure proper sync status
    checking
 +57/-0   
transaction.ts
Transaction class constructor refactoring for flexibility

src/libs/blockchain/transaction.ts

  • Refactored Transaction class constructor to accept optional partial
    data for flexible initialization
  • Changed property declarations to use non-null assertion with definite
    assignment
  • Reordered transaction content fields with from_ed25519_address moved
    to beginning
  • Improved initialization with Object.assign() for cleaner property
    setup
 +36/-27 
L2PSMempool.ts
L2PS mempool entity with composite indexing                           

src/model/entities/L2PSMempool.ts

  • Created new TypeORM entity for L2PS mempool transaction storage with
    JSONB support
  • Defined composite indexes on l2ps_uid with timestamp and status for
    efficient querying
  • Added comprehensive JSDoc documentation explaining privacy
    preservation and entity purpose
  • Stores encrypted L2PS transactions separately from main mempool with
    original hash tracking
 +72/-0   
datasource.ts
Datasource refactoring to singleton pattern                           

src/model/datasource.ts

  • Refactored datasource initialization from module-level export to
    singleton pattern
  • Moved DataSource configuration into private constructor for lazy
    initialization
  • Added OfflineMessage entity to entities array
  • Removed duplicate entity entries and cleaned up entity list
 +26/-29 
L2PSHashes.ts
L2PS hash storage entity for validator consensus                 

src/model/entities/L2PSHashes.ts

  • Created new TypeORM entity for storing L2PS UID to consolidated hash
    mappings for validators
  • Defined primary key on l2ps_uid with supporting columns for hash,
    transaction count, and timestamps
  • Added comprehensive JSDoc explaining validator content-blind consensus
    model
  • Includes block number tracking for consensus ordering and staleness
    detection
 +55/-0   
OfflineMessages.ts
Offline messages entity for instant messaging                       

src/model/entities/OfflineMessages.ts

  • Created new TypeORM entity for offline message storage with indexed
    recipient and sender keys
  • Added support for encrypted content storage via JSONB column
  • Defined message status field with three states: pending, sent, failed
  • Includes timestamp tracking with bigint type to prevent JavaScript
    precision loss
 +34/-0   
sharedState.ts
Shared state extensions for DTR and L2PS                                 

src/utilities/sharedState.ts

  • Added validityDataCache Map for DTR retry mechanism storing
    ValidityData by transaction hash
  • Added l2psJoinedUids array to track L2PS networks the node
    participates in
  • Imported ValidityData type from demosdk for DTR caching support
 +9/-1     
mempool_v2.ts
Mempool transaction removal for DTR relay                               

src/libs/blockchain/mempool_v2.ts

  • Added removeTransaction() static method for DTR relay success cleanup
  • Method removes transactions from mempool by hash after successful
    validator relay
  • Includes logging for removal tracking and error handling
 +21/-0   
isValidator.ts
Validator status detection utility function                           

src/libs/consensus/v2/routines/isValidator.ts

  • Created new utility function to determine if current node is validator
    for next block
  • Reuses existing getCommonValidatorSeed() and getShard() logic for
    validator determination
  • Returns boolean with conservative fallback to false on errors
 +15/-0   
Miscellaneous
1 files
handleStep.ts
L2PS import path update to deprecated module                         

src/libs/network/routines/transactions/demosWork/handleStep.ts

  • Updated L2PS message import path from deprecated module to new
    location
  • Changed import from parallelNetworks to parallelNetworks_deprecated
 +1/-1     
Formatting
3 files
pay.ts
Code formatting consistency improvements                                 

src/features/multichain/routines/executors/pay.ts

  • Standardized semicolon usage in variable declarations and function
    calls
  • Minor formatting consistency improvements
 +2/-2     
server_rpc.ts
Minor formatting fix for response object                                 

src/libs/network/server_rpc.ts

  • Added trailing comma to MCP server status response object for
    consistency
 +1/-1     
validateUint8Array.ts
Code style consistency improvements                                           

src/utilities/validateUint8Array.ts

  • Changed string quotes from single to double quotes for consistency
  • Removed trailing semicolon from return statement for consistency
 +2/-2     
Documentation
19 files
L2PS_DTR_IMPLEMENTATION.md
L2PS and DTR implementation documentation                               

src/libs/l2ps/L2PS_DTR_IMPLEMENTATION.md

  • Comprehensive implementation documentation for L2PS and DTR
    integration
  • Detailed architecture overview with transaction flow diagrams
  • Phase-by-phase implementation status with completed and planned work
  • Privacy model validation and DTR integration points documentation
 +630/-0 
L2PS_PHASES.md
L2PS implementation phases and action items                           

L2PS_PHASES.md

  • Detailed actionable implementation steps for L2PS phases 1-3c
  • Complete phase descriptions with code templates and validation
    criteria
  • Implementation status tracking and success metrics
  • File modification summary and completion criteria
 +731/-0 
plan_of_action_for_offline_messages.md
Offline messaging and L2PS quantum-safe encryption plan   

src/features/InstantMessagingProtocol/signalingServer/plan_of_action_for_offline_messages.md

  • Comprehensive plan for offline messaging with blockchain integration
  • L2PS ML-KEM-AES quantum-safe encryption architecture documentation
  • Phase 2 planning for L2PS-integrated messaging system
  • Implementation status tracking and future enhancement roadmap
 +479/-0 
README.md
DTR implementation overview and architecture guide             

dtr_implementation/README.md

  • Comprehensive DTR (Distributed Transaction Routing) overview and
    architecture
  • Problem statement and two-tier transaction architecture explanation
  • Security advantages and technical benefits documentation
  • DTR flow architecture with validation pipeline and performance metrics
 +273/-0 
L2PS_TESTING.md
L2PS Testing and Validation Guide Creation                             

L2PS_TESTING.md

  • Created comprehensive 17-test scenario validation guide for L2PS
    implementation
  • Covers database schema verification, node startup validation, and
    phase-by-phase testing
  • Includes performance testing, error recovery, edge cases, and privacy
    validation procedures
  • Provides completion checklist and known issues to watch for during
    runtime validation
 +496/-0 
session_2025_01_31_l2ps_completion.md
Session Summary for L2PS Implementation Completion             

.serena/memories/session_2025_01_31_l2ps_completion.md

  • Documents complete L2PS implementation session with all phases
    finished (100%)
  • Records 4 commits implementing validator hash storage, NodeCall
    endpoints, concurrent sync, and blockchain integration
  • Summarizes technical discoveries including auto-initialization pattern
    and non-blocking operations
  • Provides file organization summary and next steps for runtime
    validation
 +385/-0 
DTR_MINIMAL_IMPLEMENTATION.md
DTR Minimal Implementation Plan and Strategy                         

dtr_implementation/DTR_MINIMAL_IMPLEMENTATION.md

  • Outlines minimal DTR (Distributed Transaction Routing) implementation
    strategy leveraging existing infrastructure
  • Describes single-point modification approach in endpointHandlers.ts
    with ~20 lines of DTR logic
  • Details multi-validator retry mechanism and background retry service
    with block-aware optimization
  • Includes enhanced fallback strategy and complete flow diagram for
    production implementation
 +354/-0 
l2ps_onboarding_guide.md
L2PS Onboarding Guide for Future Sessions                               

.serena/memories/l2ps_onboarding_guide.md

  • Comprehensive onboarding guide explaining L2PS system architecture and
    privacy model
  • Documents three-tier architecture (participants, validators, sync
    layer) and all implementation phases
  • Provides file organization, key data structures, and important
    concepts for future LLM sessions
  • Includes code flow examples, NodeCall endpoints reference, and testing
    checklist
 +395/-0 
l2ps_architecture.md
L2PS Architecture Documentation with Diagrams                       

.serena/memories/l2ps_architecture.md

  • Detailed L2PS system architecture with ASCII diagrams showing
    component interactions
  • Documents data flow for transaction submission, privacy separation,
    and validator hash updates
  • Includes network topology, security model, and performance
    characteristics
  • Provides threat protection analysis and trust boundary definitions
 +215/-0 
l2ps_implementation_status.md
L2PS Implementation Status - All Phases Complete                 

.serena/memories/l2ps_implementation_status.md

  • Status report showing all L2PS phases complete (100%) as of 2025-01-31
  • Details implementation of Phase 3b (validator hash storage), 3c-1
    (NodeCall endpoints), 3c-2 (concurrent sync), and 3c-3 (blockchain
    integration)
  • Lists 3 new files created and 4 files modified with ~650 lines of
    production code
  • Notes testing status as pending with comprehensive validation guide
    available
 +168/-0 
l2ps_remaining_work.md
L2PS Remaining Work Documentation                                               

.serena/memories/l2ps_remaining_work.md

  • Documents remaining work priorities for L2PS implementation (now
    completed)
  • Outlines 4 priority phases with specific file locations and
    implementation details
  • Provides code examples for validator hash storage, NodeCall endpoints,
    and sync service
  • Includes testing considerations and dependency relationships between
    priorities
 +178/-0 
l2ps_code_patterns.md
L2PS Code Patterns and Conventions Reference                         

.serena/memories/l2ps_code_patterns.md

  • Reference guide for L2PS code patterns and conventions used throughout
    implementation
  • Documents file locations, service patterns, NodeCall patterns, and
    database patterns
  • Provides key integration points including shared state,
    ParallelNetworks, and PeerManager
  • Lists important constraints and logging conventions for L2PS
    development
 +205/-0 
development_guidelines.md
Development Guidelines and Best Practices                               

.serena/memories/development_guidelines.md

  • Comprehensive development guidelines covering core principles,
    architecture, and best practices
  • Emphasizes maintainability, planning workflow, and code quality
    standards
  • Details critical requirement to never start node during development
    and use linting for validation
  • Includes repository-specific notes, testing guidelines, and
    development workflow summary
 +175/-0 
codebase_structure.md
Codebase Structure and Organization Reference                       

.serena/memories/codebase_structure.md

  • Documents complete codebase structure including root directory layout
    and feature modules
  • Details source code organization, configuration files, and
    documentation locations
  • Explains path aliases using @/ prefix and naming conventions for
    repository
  • Provides build output information and ignored directories reference
 +145/-0 
suggested_commands.md
Suggested Commands Reference Guide                                             

.serena/memories/suggested_commands.md

  • Reference guide for essential development commands including linting,
    testing, and node operations
  • Documents package management, database operations, and Docker commands
  • Provides standard development workflow and troubleshooting commands
  • Emphasizes critical requirement to never start node during development
 +142/-0 
code_style_conventions.md
Code Style and Conventions Reference                                         

.serena/memories/code_style_conventions.md

  • Documents ESLint-enforced naming conventions (camelCase for functions,
    PascalCase for classes)
  • Details code formatting rules including double quotes, no semicolons,
    and trailing commas
  • Specifies import organization with mandatory @/ path aliases instead
    of relative paths
  • Lists TypeScript configuration settings and documentation standards
 +117/-0 
task_completion_checklist.md
Task Completion Checklist and Validation Guide                     

.serena/memories/task_completion_checklist.md

  • Comprehensive pre-completion validation checklist for code quality and
    integration
  • Emphasizes mandatory bun run lint:fix execution before marking tasks
    complete
  • Details code quality, testing, integration, and security
    considerations
  • Includes critical warnings against starting node during development
 +108/-0 
validator_status_minimal.md
Validator Status Minimal Implementation Approach                 

dtr_implementation/validator_status_minimal.md

  • Minimal implementation approach for validator status checking using
    single function
  • Leverages existing consensus routines (getShard,
    getCommonValidatorSeed) with zero modifications
  • Provides simple isValidatorForNextBlock() function and optional
    getValidatorsForRelay() helper
  • Documents usage pattern and explains why minimal approach works
    effectively
 +88/-0   
tech_stack.md
Tech Stack and Dependencies Reference                                       

.serena/memories/tech_stack.md

  • Documents complete tech stack including core technologies and key
    dependencies
  • Details blockchain/crypto libraries, database/ORM, and server/API
    frameworks
  • Lists development tools and infrastructure requirements including
    Docker and PostgreSQL
  • Specifies build configuration with path aliases and TypeScript
    settings
 +52/-0   
Configuration changes
3 files
extensions.json
VSCode extension recommendation addition                                 

.vscode/extensions.json

  • Added nur-publisher.hypercomments-vscode extension to recommended
    extensions list
 +2/-1     
project.yml
Serena Project Configuration File                                               

.serena/project.yml

  • Project configuration file for Serena development environment
  • Specifies TypeScript as primary language with UTF-8 encoding
  • Enables gitignore-based file filtering and read-write mode
  • Lists all available development tools (excluded_tools is empty)
 +84/-0   
package.json
Package Configuration and Dependency Updates                         

package.json

  • Updated lint:fix command to exclude local_tests/** directory from
    linting
  • Upgraded @kynesyslabs/demosdk from ^2.2.70 to ^2.2.71
  • Added async-mutex ^0.5.0 as new dependency for synchronization
    primitives
 +3/-2     
Additional files
4 files
l2ps_overview.md +44/-0   
project_purpose.md +26/-0   
settings.json +2/-20   
manageExecution.ts +0/-10   

Summary by CodeRabbit

  • New Features

    • L2PS: encrypted subnet mempool, persistent network hash storage, periodic hash generation, non-blocking background sync, and mempool/info/transactions query endpoints.
    • DTR: validator relay flow with background retry service for non-validator nodes.
    • Offline messaging: persistent offline queue, per-sender limits, blockchain-backed storage option, and automatic delivery on reconnect.

  • Documentation

    • Detailed L2PS/DTR guides, testing plans, onboarding and development guidelines.

  • Chores

    • Expanded ignore rules, workspace settings and lint script updates.

✏️ Tip: You can customize this high-level summary in your review settings.

tcsenpai and others added 30 commits June 5, 2025 01:20
@tcsenpai
Plan of action
5366aad
added database structure for offline messages
b228b2e
just an addition to the ignore
8ff4f1d
Updated action plan for better l2ps imp
d1ca864
started new l2ps structure
fcfa880
dubious integration of ucrypto transaction type into this branch
e9ef066
l2ps implementation status tracking
30ffc92
version bumps
c83be55
refactoring of parallelNetworks l2ps wrapper using the new l2ps logic…
1cb1e95 
… from sdk
dependant files update following the upgrade to the new l2ps
4b8eaa8
ignoring sensitive files
029625a
documented the class
7c14d9e
Merge branch 'testnet' into imp_persistent
2209e06
better approach to transaction class
55851d2
claude.md ignored
b2c10df
using the generic transaction validation
3c66730
@tcsenpai
Merge branch 'testnet' into imp_persistent
8fd6941
ignored sensitive files
0f55d6b
dtr first test
8153c52
Merge branch 'testnet' into dtr
ec4d2bf
updated docs
6e76832
entrypoint for background tx relaying
30adaaf
added deletion method
486dd01
hardened DTR logic
c5dfa3d
relayRetryService implementation for background relay of txs
da25b2a
Merge branch 'testnet' into l2ps_simplified
665171e
fixed import with the new tx type
81c39af
Merge branch 'dtr' into l2ps_simplified
5f4bf76
Improved l2ps loading when handling a L2PSTransaction
12b05b5
simplified action plan for l2ps based on DTR
c2ffb2b
tcsenpai and others added 14 commits November 6, 2025 14:13
lints
0c8895d
added onboarding for l2ps
93a74e0
saved session for l2ps
00022c6
@claude
Fix L2PS return type and pre-existing issues
f11afe5 
L2PS Fix:
- parallelNetworks.ts:166: Fixed return type mismatch (return [] instead of return)

Pre-existing Issues Fixed:
- signalingServer.ts:62: Updated mempool import to mempool_v2
- signalingServer.ts:588: Added cryptographic signature for offline messages (integrity verification)
- signalingServer.ts:625-627: Moved DB operations outside loop (10x performance improvement)
- datasource.ts:39-53: Removed duplicate entities (Mempool, Transactions, GCRTracker)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
@claude
Fix DTR validator shuffle algorithm (fix dtr behavior)
d6e95fd 
Replaced biased sort(() => Math.random() - 0.5) with proper Fisher-Yates shuffle.

Problem:
- Previous shuffle could favor certain validators by 30-40%
- Violated transitivity assumptions of sort algorithms
- Caused uneven load distribution across validators

Solution:
- Implemented Fisher-Yates (Knuth) shuffle algorithm
- Guarantees truly uniform random distribution (1/n! for each permutation)
- O(n) time complexity (faster than sort's O(n log n))

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
ignores
b9c63cc
committed pr fixes
940b9f8
@claude
Fix 9 critical and high-priority issues from PR review
48d344f 
Critical fixes:
- Transactional offline message delivery with error handling
- Parallel validator relay with concurrency limit (prevents blocking)

High-priority fixes:
- Add | null to l2ps_hashes repo type annotation
- Fix TypeORM bigint type mismatch in OfflineMessages
- Validate nested data access in handleL2PS (2 locations)
- Define L2PSHashPayload interface with validation
- Reject transactions without block_number

Medium-priority fixes:
- Add private constructor to L2PSHashService singleton
- Remove redundant @Index from L2PSMempool primary key

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
@claude
Fix 16 critical and high-priority issues from CodeRabbit PR review
2362537 
Critical fixes (5/5):
- L2PSMempool: Add ensureInitialized() guards to prevent null repository crashes
- L2PSMempool: Fix timestamp type (bigint → string) to match TypeORM behavior
- RelayRetryService: Add 5-second timeout wrapper for validator calls
- RelayRetryService: Add cleanup for retryAttempts Map to prevent memory leak
- RelayRetryService: Convert sequential processing to parallel (concurrency: 5)

High priority fixes (11/13):
- RelayRetryService: Add null safety for validator.identity (3 locations)
- L2PSMempool: Add block number validation for edge cases
- L2PSMempool: Fix duplicate check consistency (use existsByHash method)
- L2PSConcurrentSync: Optimize duplicate detection with batched queries
- L2PSConcurrentSync: Use addTransaction() for validation instead of direct insert
- L2PSHashes: Fix race condition with atomic upsert operation
- RelayRetryService: Add validityDataCache eviction to prevent unbounded growth
- SignalingServer: Add consistent error handling for blockchain storage
- SignalingServer: Add null safety checks for private key access (2 locations)
- ParallelNetworks: Add JSON parsing error handling for config files
- ParallelNetworks: Add array validation before destructuring

All changes pass ESLint with zero errors or warnings.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
fixed some files due to reviews
750eb91
@claude
Fix 3 issues from CodeRabbit validation review
3793c6a 
- Fix nonce increment timing: Move senderNonces.set() to after successful mempool addition for better error handling
- Add defensive rate limiting: Enforce MAX_OFFLINE_MESSAGES_PER_SENDER in storeOfflineMessage method
- Update PR_REVIEW_FINAL.md: Document validation results and remaining issues

All changes pass ESLint validation.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
@claude
Fix 8 critical and high-priority issues from CodeRabbit PR review
e114000 
This commit implements all autofixable issues plus race condition mitigation:

CRITICAL FIXES:
- Issue #1: Made handleMessage async to support await operations (signalingServer.ts:156)
- Issue #3: Removed double increment of offline message count (signalingServer.ts:412)
- Issue #2: Added mutex locking to prevent race conditions on shared state Maps
  * Installed async-mutex package
  * Protected senderNonces with nonceMutex for transaction uniqueness
  * Protected offlineMessageCounts with countMutex for rate limiting
  * Atomic check-and-increment/decrement operations

HIGH PRIORITY FIXES:
- Issue #5: Reversed blockchain/DB storage order (DB first for easier rollback)
- Issue #6: Added L2PS decryption error handling with try-catch and null checks (handleL2PS.ts:56-72)

MEDIUM PRIORITY FIXES:
- Issue #7: Added L2PS mempool error handling (handleL2PS.ts:101-111)

LOW PRIORITY FIXES:
- Issue #8: Added pagination support to L2PSHashes.getAll() (l2ps_hashes.ts:152-169)
- Issue #9: Added non-null assertions for type safety (l2ps_hashes.ts:97, 125, 161)
- Issue #10: Changed "delivered" to "sent" for semantic accuracy
  * Updated status in signalingServer.ts
  * Updated OfflineMessage entity to include "sent" status
  * No migration needed (synchronize: true handles schema update)

All changes include REVIEW comments for code review tracking.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
@claude
Fix CodeRabbit Issue #1: Make blockchain storage mandatory for both p…
24c7a19 
…aths

Enforces consistent audit trail policy across online and offline message delivery.

BEFORE:
- Offline path: Blockchain failures were logged but non-fatal (operation continued)
- Online path: Blockchain failures aborted the operation (fatal)
- Result: Inconsistent audit trail with potential gaps

AFTER:
- Both paths: Blockchain failures abort the operation
- Ensures complete audit trail for all messages
- Consistent error handling and failure behavior

Changes:
- Updated offline path (lines 422-430) to match online path behavior
- Blockchain storage now mandatory for audit trail consistency
- Both paths return error and abort on blockchain failure

Impact:
- Guarantees all delivered messages have blockchain records
- Prevents audit trail gaps from blockchain service interruptions
- Message delivery requires both DB and blockchain success

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
ignores
62b5978
@tcsenpai tcsenpai requested a review from cwilvx November 8, 2025 14:11
@coderabbitai
Copy link
Contributor

coderabbitai bot commented Nov 8, 2025 •
edited
Loading

Warning

Rate limit exceeded

@tcsenpai has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 10 minutes and 46 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📥 Commits

Reviewing files that changed from the base of the PR and between f0ae38f and 330ae8a.

📒 Files selected for processing (1)
  • .gitignore (3 hunks)

Walkthrough

Adds a large L2PS (Layer 2 Privacy Subnets) and DTR feature set: new entities, mempools, managers, concurrent sync and hash-generation services, a relay-retry background service, NodeCall endpoints, datasource refactor, offline messaging support, and startup/shutdown wiring. All changes are feature additions and docs; no behavioral rollbacks.

Changes

Cohort / File(s) Change Summary
Git / Config & Packages
.gitignore, package.json		 Expanded ignore rules; bumped @kynesyslabs/demosdk, added async-mutex; lint script updated.
Editor Config
.vscode/extensions.json, .vscode/settings.json		 VS Code recommended extension added; workspace settings simplified.
Docs / Memories
.serena/memories/*, L2PS_PHASES.md, L2PS_TESTING.md, dtr_implementation/*, AGENTS.md		 Many new/updated docs: L2PS architecture, onboarding, phases, testing, DTR design, development guidelines, checklists and session notes.
Entities (DB)
src/model/entities/L2PSHashes.ts, src/model/entities/L2PSMempool.ts, src/model/entities/OfflineMessages.ts, src/model/entities/GCRv2/GCRSubnetsTxs.ts		 New TypeORM entities for L2PS hashes, L2PS mempool txs, offline messages; GCR entity adjusted to L2PSTransaction type.
Datasource & Shared State
src/model/datasource.ts, src/utilities/sharedState.ts		 Datasource refactored to class-based singleton; OfflineMessage added to entities; added validityDataCache and l2psJoinedUids to shared state.
L2PS Managers & Mempools
src/libs/blockchain/l2ps_hashes.ts, src/libs/blockchain/l2ps_mempool.ts		 New L2PSHashes manager (persistent UID→hash) and L2PSMempool manager (encrypted tx storage, dedupe, stats).
L2PS Services & Orchestration
src/libs/l2ps/L2PSHashService.ts, src/libs/l2ps/L2PSConcurrentSync.ts, src/libs/l2ps/parallelNetworks.ts, src/libs/l2ps/L2PS_DTR_IMPLEMENTATION.md		 New hash-generation service (periodic 5s, relay), concurrent sync utilities (discover/sync/exchange), ParallelNetworks singleton for load/encrypt/decrypt/process.
DTR Relay & Retry
src/libs/network/dtr/relayRetryService.ts, src/libs/blockchain/mempool_v2.ts		 New RelayRetryService background retry loop; removeTransaction added to mempool_v2 for post-relay removal.
Network / Transaction Flow
src/libs/network/endpointHandlers.ts, src/libs/network/manageExecution.ts, src/libs/network/manageNodeCall.ts, src/libs/network/routines/transactions/handleL2PS.ts, src/libs/network/routines/transactions/demosWork/handleStep.ts		 Added L2PS hash-update handler, production DTR relay path with fallback, new NodeCall handlers (RELAY_TX, getL2PSParticipationById, getL2PSMempoolInfo, getL2PSTransactions), removed special-case L2PS branch from manageExecution, robust handleL2PS decrypt/verify/dedup/store flow.
Consensus Helper
src/libs/consensus/v2/routines/isValidator.ts		 Added isValidatorForNextBlock() helper.
Transaction Model
src/libs/blockchain/transaction.ts		 Constructor now accepts Partial, uses non-null assertions; from_ed25519_address added to raw output.
Instant Messaging / Signaling
src/features/InstantMessagingProtocol/signalingServer/*		 Offline-messaging plan and server changes: per-sender nonce mutex, rate-limiting, offline storage/delivery, optional blockchain audit.
Startup & Lifecycle
src/index.ts		 Wire RelayRetryService (PROD, post-sync) and L2PSHashService (conditional), added graceful shutdown hooks and crypto import adjustments.
Misc / Build
.beads/*, .serena/memories/*		 Various small config and metadata additions for bead tooling and style docs.

Sequence Diagram(s)

sequenceDiagram
    participant Client
    participant L2PSNode as L2PS Participant
    participant DB as L2PSMempool
    participant HashSvc as L2PSHashService
    participant Validator
    Client->>L2PSNode: Submit encrypted transaction
    L2PSNode->>DB: L2PSMempool.addTransaction(encrypted)
    Note right of DB: stored encrypted-only
    loop every 5s
        HashSvc->>DB: getHashForL2PS(uid)
        HashSvc->>Validator: Relay L2PS hash update (DTR in PROD)
        Validator->>Validator: L2PSHashes.updateHash(uid,hash,meta)
    end
Loading 
sequenceDiagram
    participant NonValidator
    participant Mempool
    participant RelayRetry as RelayRetryService
    participant Validator
    NonValidator->>Mempool: Receive tx + store validityData
    loop every 10s (retry)
        RelayRetry->>Validator: Relay txs (shuffled list)
        alt validator accepts
            Validator->>Mempool: add tx to validator mempool
            RelayRetry->>Mempool: removeTransaction(txHash)
            RelayRetry->>RelayRetry: clear validityDataCache entry
        else all fail / exhausted
            RelayRetry->>Mempool: remove tx + abandon or log
        end
    end
Loading 
sequenceDiagram
    participant Peer
    participant Sync as Sync.ts
    participant L2PSCS as L2PSConcurrentSync
    Peer->>Sync: peer connected / mergePeerlist()
    Sync->>L2PSCS: exchangeL2PSParticipation(peers) (non-blocking)
    par blockchain sync
        Sync->>Sync: requestBlocks()
    and L2PS sync (background)
        L2PSCS->>Peer: discoverL2PSParticipants()/syncL2PSWithPeer()
    end
Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45–60 minutes

Areas to focus during review:

  • Concurrency and non-blocking use of Promise.allSettled in L2PSConcurrentSync and Sync.ts hooks.
  • L2PSHashService lifecycle (start/stop/reentrancy) and DTR relay selection logic.
  • RelayRetryService correctness (validator selection, retry limits, caching and cleanup of validityData).
  • EndpointHandlers/manageNodeCall changes that alter NodeCall interface and transaction routing.
  • Datasource singleton migration impact on entity registration and DB sync behavior.

Possibly related PRs

Suggested labels

Possible security concern

Suggested reviewers

  • cwilvx

Poem

🐰 I dug a burrow in the code tonight,

I stored some hashes out of sight,
Retries hum soft, syncs run in flight,
Offline notes queued till the morning light,
Hops and logs keep everything tight.

Pre-merge checks and finishing touches

❌ Failed checks (1 inconclusive)
Check name Status Explanation Resolution
Title check ❓ Inconclusive The title 'L2ps simplified' is vague and generic, using non-descriptive phrasing that does not clearly convey the scope or primary changes of this substantial PR. Use a more specific title that captures the main deliverables, such as 'Complete L2PS implementation with DTR routing, mempool sync, and validator integration' or 'L2PS and DTR implementation with concurrent sync and offline messaging'.
✅ Passed checks (2 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage ✅ Passed Docstring coverage is 92.31% which is sufficient. The required threshold is 80.00%.

Warning

Review ran into problems

🔥 Problems

Errors were encountered while retrieving linked issues.

Errors (1)
  • UTF-8: Entity not found: Issue - Could not find referenced Issue.

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@qodo-code-review
Copy link
Contributor

qodo-code-review bot commented Nov 8, 2025 •
edited
Loading

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
⚪
Insecure key path usage

Description: Private key and IV are read from filesystem paths controlled by config; although uid is
validated and path traversal is checked for config, private_key_path and iv_path are
resolved from process.cwd() without verifying they remain inside an expected directory,
which could allow loading sensitive keys from unintended locations if config is
compromised.
parallelNetworks.ts [152-164]

Referred Code 
const privateKeyPath = path.resolve(
    process.cwd(),
    nodeConfig.keys.private_key_path,
)
const ivPath = path.resolve(process.cwd(), nodeConfig.keys.iv_path)

if (!fs.existsSync(privateKeyPath) || !fs.existsSync(ivPath)) {
    throw new Error(`L2PS key files not found for ${uid}`)
}

const privateKey = fs.readFileSync(privateKeyPath, "utf8").trim()
const iv = fs.readFileSync(ivPath, "utf8").trim()
Missing sender auth

Description: Messages are signed with the node’s private key instead of the sender’s, providing
integrity but no sender authentication or non-repudiation; this enables spoofing of
senderId in on-chain records until client-side signing and verification are implemented.
signalingServer.ts [619-666]

Referred Code 
private async storeMessageOnBlockchain(senderId: string, targetId: string, message: SerializedEncryptedObject) {
    // REVIEW: PR Fix #2 - Use mutex to prevent nonce race conditions
    // Acquire lock before reading/modifying nonce to ensure atomic operation
    return await this.nonceMutex.runExclusive(async () => {
        // REVIEW: PR Fix #6 - Implement per-sender nonce counter for transaction uniqueness
        const currentNonce = this.senderNonces.get(senderId) || 0
        const nonce = currentNonce + 1
        // Don't increment yet - wait for mempool success for better error handling

        const transaction = new Transaction()
        transaction.content = {
            type: "instantMessaging",
            from: senderId,
            to: targetId,
            from_ed25519_address: senderId,
            amount: 0,
            data: ["instantMessaging", { message, timestamp: Date.now() }] as any,
            gcr_edits: [],
            nonce,
            timestamp: Date.now(),
            transaction_fee: { network_fee: 0, rpc_fee: 0, additional_fee: 0 },


 ... (clipped 27 lines)
Offline msg spoofing

Description: Offline message storage signs the node-generated messageHash with the node’s private key
and stores encrypted content without verifying sender identity, enabling potential sender
spoofing and accountability issues if a malicious client injects forged senderId.
signalingServer.ts [679-727]

Referred Code 
private async storeOfflineMessage(senderId: string, targetId: string, message: SerializedEncryptedObject) {
    // REVIEW: PR Fix #2 - Use mutex to prevent rate limit bypass via race conditions
    // Acquire lock before checking/modifying count to ensure atomic operation
    return await this.countMutex.runExclusive(async () => {
        // REVIEW: PR Fix #9 - Defensive rate limiting check (in case method is called from other locations)
        const currentCount = this.offlineMessageCounts.get(senderId) || 0
        if (currentCount >= this.MAX_OFFLINE_MESSAGES_PER_SENDER) {
            throw new Error(`Sender ${senderId} has exceeded offline message limit (${this.MAX_OFFLINE_MESSAGES_PER_SENDER})`)
        }

        const db = await Datasource.getInstance()
        const offlineMessageRepository = db.getDataSource().getRepository(OfflineMessage)

        // REVIEW: PR Fix - Use deterministic key ordering for consistent hashing
        const timestamp = Date.now()
        const messageContent = JSON.stringify({
            message,      // Keys in alphabetical order
            senderId,
            targetId,
            timestamp,
        })


 ... (clipped 28 lines)
Weak L2PS authz

Description: L2PS hash update acceptance only checks local participation and payload structure but does
not authenticate the transaction’s sender against L2PS membership (e.g., signature bound
to L2PS key set), allowing non-members to submit spoofed hash updates if they can craft a
valid transaction.
endpointHandlers.ts [760-844]

Referred Code 
static async handleL2PSHashUpdate(tx: Transaction): Promise<RPCResponse> {
    const response: RPCResponse = _.cloneDeep(emptyResponse)

    try {
        // REVIEW: PR Fix #12 - Validate payload structure and reject transactions without block_number
        if (!tx.content || !tx.content.data || !tx.content.data[1]) {
            response.result = 400
            response.response = "Invalid transaction structure"
            response.extra = "Missing L2PS hash payload in transaction data"
            return response
        }

        if (!tx.block_number) {
            response.result = 400
            response.response = "Missing block_number"
            response.extra = "L2PS hash updates require valid block_number (cannot default to 0)"
            return response
        }

        const payloadData = tx.content.data[1]



 ... (clipped 64 lines)
Ticket Compliance
⚪
🎫 No ticket provided
  • Create ticket/issue
Codebase Duplication Compliance
⚪
Codebase context is not defined

Follow the guide to enable codebase context checks.

Custom Compliance
🟢
Generic: Meaningful Naming and Self-Documenting Code

Objective: Ensure all identifiers clearly express their purpose and intent, making code
self-documenting

Status: Passed

🔴
Generic: Secure Logging Practices

Objective: To ensure logs are useful for debugging and auditing without exposing sensitive
information like PII, PHI, or cardholder data.

Status:
Sensitive logging: The server logs and returns messages containing peer IDs and possibly message metadata
(e.g., targetId, fromId, timestamps) via console.log and JSON responses, which may expose
user identifiers in logs and responses contrary to secure logging practices.

Referred Code 
        type: "message_queued",
        payload: {
            targetId: payload.targetId,
            status: "offline",
            message: "Message stored for offline delivery",
        },
    }))
    return
}

// REVIEW: PR Fix #5 - Make blockchain storage mandatory for online path consistency
// Create blockchain transaction for online message
try {
    await this.storeMessageOnBlockchain(senderId, payload.targetId, payload.message)
} catch (error) {
    console.error("Failed to store message on blockchain:", error)
    this.sendError(ws, ImErrorType.INTERNAL_ERROR, "Failed to store message")
    return  // Abort on blockchain failure for audit trail consistency
}
⚪
Generic: Comprehensive Audit Trails

Objective: To create a detailed and reliable record of critical system actions for security analysis
and compliance.

Status:
Partial auditing: The code introduces blockchain-backed logging for IM messages and L2PS hash updates, but
also performs console logging and DB writes without a clear, comprehensive, structured
audit policy ensuring all critical actions consistently capture user ID, timestamp,
action, and outcome across all paths.

Referred Code 
    return
}

// Check if target peer exists BEFORE blockchain write (prevent DoS)
const targetPeer = this.peers.get(payload.targetId)

if (!targetPeer) {
    // Store as offline message if target is not online
    // REVIEW: PR Fix #3 #5 - Store to database first (easier to rollback), then blockchain (best-effort)
    // REVIEW: PR Fix #2 - Removed redundant rate limit check; storeOfflineMessage has authoritative check with mutex
    try {
        await this.storeOfflineMessage(senderId, payload.targetId, payload.message)
    } catch (error: any) {
        console.error("Failed to store offline message in DB:", error)
        // REVIEW: PR Fix #2 - Provide specific error message for rate limit
        if (error.message?.includes("exceeded offline message limit")) {
            this.sendError(
                ws,
                ImErrorType.INTERNAL_ERROR,
                `Offline message limit reached (${this.MAX_OFFLINE_MESSAGES_PER_SENDER} messages). Please wait for recipient to come online.`,
            )


 ... (clipped 36 lines)
Generic: Robust Error Handling and Edge Case Management

Objective: Ensure comprehensive error handling that provides meaningful context and graceful
degradation

Status:
Edge cases: While many errors are handled, critical operations like repository saves and hash
generation return generic messages and sometimes swallow context, and some flows rely on
external services (Chain/SecretaryManager) without clear fallbacks for unavailable
dependencies.

Referred Code 
// Determine block number (following main mempool pattern)
// REVIEW: PR Fix #7 - Add validation for block number edge cases
let blockNumber: number
const manager = SecretaryManager.getInstance()

if (manager.shard?.blockRef && manager.shard.blockRef >= 0) {
    blockNumber = manager.shard.blockRef + 1
} else {
    const lastBlockNumber = await Chain.getLastBlockNumber()
    // Validate lastBlockNumber is a valid positive number
    if (typeof lastBlockNumber !== "number" || lastBlockNumber < 0) {
        return {
            success: false,
            error: `Invalid last block number: ${lastBlockNumber}`,
        }
    }
    blockNumber = lastBlockNumber + 1
}

// Additional safety check for final blockNumber
if (!Number.isFinite(blockNumber) || blockNumber <= 0) {


 ... (clipped 30 lines)
Generic: Secure Error Handling

Objective: To prevent the leakage of sensitive system information through error messages while
providing sufficient detail for internal debugging.

Status:
Verbose logs: Several error paths use this.sendError or console.error with internal details (e.g.,
database failures, blockchain storage errors) that may be exposed to clients, risking
leakage of implementation details unless upstream ensures they are not user-facing.

Referred Code 
    await this.storeOfflineMessage(senderId, payload.targetId, payload.message)
} catch (error: any) {
    console.error("Failed to store offline message in DB:", error)
    // REVIEW: PR Fix #2 - Provide specific error message for rate limit
    if (error.message?.includes("exceeded offline message limit")) {
        this.sendError(
            ws,
            ImErrorType.INTERNAL_ERROR,
            `Offline message limit reached (${this.MAX_OFFLINE_MESSAGES_PER_SENDER} messages). Please wait for recipient to come online.`,
        )
    } else {
        this.sendError(ws, ImErrorType.INTERNAL_ERROR, "Failed to store offline message")
    }
    return
}

// REVIEW: PR Fix - CodeRabbit Issue #1 - Make blockchain storage mandatory for audit trail consistency
// Then store to blockchain (mandatory for audit trail consistency with online path)
try {
    await this.storeMessageOnBlockchain(senderId, payload.targetId, payload.message)
} catch (error) {


 ... (clipped 5 lines)
Generic: Security-First Input Validation and Data Handling

Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent
vulnerabilities

Status:
Input validation: UID validation and path traversal checks are added, but other inputs like transaction
payloads and signatures rely on external assumptions; additional validation and
sanitization for data structures (e.g., tx.content fields) and consistent signature
verification across flows may be needed.

Referred Code 
async loadL2PS(uid: string): Promise<L2PS> {
    // REVIEW: PR Fix - Validate uid to prevent path traversal attacks
    if (!uid || !/^[A-Za-z0-9_-]+$/.test(uid)) {
        throw new Error(`Invalid L2PS uid: ${uid}`)
    }

    if (this.l2pses.has(uid)) {
        return this.l2pses.get(uid) as L2PS
    }

    // REVIEW: PR Fix - Check if already loading to prevent race conditions
    const existingPromise = this.loadingPromises.get(uid)
    if (existingPromise) {
        return existingPromise
    }

    const loadPromise = this.loadL2PSInternal(uid)
    this.loadingPromises.set(uid, loadPromise)

    try {
        const l2ps = await loadPromise


 ... (clipped 64 lines)
  • Update
Compliance status legend 🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

@qodo-code-review
Copy link
Contributor

qodo-code-review bot commented Nov 8, 2025 •
edited
Loading

PR Code Suggestions ✨

Explore these optional code suggestions:

CategorySuggestion                                                                                                                                    Impact
High-level
The server signs messages for users

The suggestion is to shift from server-side message signing to client-side
signing to fix a critical security flaw. This change would enable proper sender
authentication and non-repudiation, as the server would verify client signatures
instead of creating its own.

Examples:

src/features/InstantMessagingProtocol/signalingServer/signalingServer.ts [619-667] 
    private async storeMessageOnBlockchain(senderId: string, targetId: string, message: SerializedEncryptedObject) {
        // REVIEW: PR Fix #2 - Use mutex to prevent nonce race conditions
        // Acquire lock before reading/modifying nonce to ensure atomic operation
        return await this.nonceMutex.runExclusive(async () => {
            // REVIEW: PR Fix #6 - Implement per-sender nonce counter for transaction uniqueness
            const currentNonce = this.senderNonces.get(senderId) || 0
            const nonce = currentNonce + 1
            // Don't increment yet - wait for mempool success for better error handling

            const transaction = new Transaction()

 ... (clipped 39 lines)
src/features/InstantMessagingProtocol/signalingServer/signalingServer.ts [679-726] 
    private async storeOfflineMessage(senderId: string, targetId: string, message: SerializedEncryptedObject) {
        // REVIEW: PR Fix #2 - Use mutex to prevent rate limit bypass via race conditions
        // Acquire lock before checking/modifying count to ensure atomic operation
        return await this.countMutex.runExclusive(async () => {
            // REVIEW: PR Fix #9 - Defensive rate limiting check (in case method is called from other locations)
            const currentCount = this.offlineMessageCounts.get(senderId) || 0
            if (currentCount >= this.MAX_OFFLINE_MESSAGES_PER_SENDER) {
                throw new Error(`Sender ${senderId} has exceeded offline message limit (${this.MAX_OFFLINE_MESSAGES_PER_SENDER})`)
            }


 ... (clipped 38 lines)

Solution Walkthrough:

Before:

async function storeMessageOnBlockchain(senderId, targetId, message) {
  const transaction = new Transaction();
  transaction.content = {
    type: "instantMessaging",
    from: senderId,
    to: targetId,
    data: ["instantMessaging", { message, ... }],
    ...
  };

  // Server signs the transaction with its own private key
  const nodePrivateKey = getSharedState.identity.ed25519.privateKey;
  const signature = Cryptography.sign(
    JSON.stringify(transaction.content),
    nodePrivateKey
  );
  transaction.signature = signature;

  // Add server-signed transaction to mempool
  await Mempool.addTransaction(transaction);
}

After:

// Client-side payload now includes a signature
interface MessagePayload {
  targetId: string;
  message: SerializedEncryptedObject;
  clientSignature: SerializedSignature;
}

async function handlePeerMessage(ws, payload: MessagePayload) {
  const senderId = this.getPeerIdByWebSocket(ws);
  const senderPeer = this.peers.get(senderId);

  // Server VERIFIES the client's signature
  const isSignatureValid = Cryptography.verify(
    JSON.stringify(payload.message),
    payload.clientSignature,
    senderPeer.publicKey
  );

  if (!isSignatureValid) {
    throw new Error("Invalid client signature");
  }

  // If valid, proceed to store the message on the blockchain
  await this.storeMessageOnBlockchain(senderId, payload.targetId, payload.message);
}
Suggestion importance[1-10]: 10

__

Why: The suggestion correctly identifies a critical security and architectural flaw where the server signs messages, which prevents sender authentication and non-repudiation, and is a fundamental issue for a blockchain-based messaging system.

High
Possible issue
Fix incorrect public key usage

Fix the signature verification in decryptTransaction to use the node's public
key from the shared state instead of the sender's public key
(encryptedTx.content.from).

src/libs/l2ps/parallelNetworks.ts [276-290]

 // REVIEW: PR Fix - Verify signature before decrypting
 if (encryptedTx.signature) {
+    const sharedState = getSharedState()
+    if (!sharedState.identity?.ed25519?.publicKey) {
+        throw new Error("Node public key not available for signature verification")
+    }
     const isValid = await ucrypto.verify({
         algorithm: encryptedTx.signature.type as SigningAlgorithm,
         message: new TextEncoder().encode(JSON.stringify(encryptedTx.content)),
-        publicKey: hexToUint8Array(encryptedTx.content.from as string),
+        publicKey: hexToUint8Array(sharedState.identity.ed25519.publicKey),
         signature: hexToUint8Array(encryptedTx.signature.data),
     })
 
     if (!isValid) {
         throw new Error(`L2PS transaction signature verification failed for ${uid}`)
     }
 } else {
     console.warn(`[L2PS] Warning: No signature found on encrypted transaction for ${uid}`)
 }
  • Apply / Chat
Suggestion importance[1-10]: 9

__

Why: This is a critical bug fix. The signature verification logic uses the wrong public key, causing all signature checks to fail and breaking the newly added security feature.

High
Fix incorrect initial value in reduce

Fix a bug in the reduce function for finding the oldest timestamp by removing
the incorrect initial value. The current implementation always returns
BigInt(Number.MAX_SAFE_INTEGER).

src/libs/blockchain/l2ps_hashes.ts [218-221]

 const oldestUpdateTime = timestamps.reduce(
-    (min, ts) => ts < min ? ts : min,
-    BigInt(Number.MAX_SAFE_INTEGER),
+    (min, ts) => (ts < min ? ts : min)
 )
  • Apply / Chat
Suggestion importance[1-10]: 8

__

Why: The suggestion correctly identifies a bug where oldestUpdateTime would always be BigInt(Number.MAX_SAFE_INTEGER) because Date.now() timestamps are smaller, making the comparison ts < min always false. This fix is critical for the correctness of the getStats method.

Medium
Fix type mismatch between entity and manager

Fix the type mismatch for block_number and timestamp in the L2PSHash entity.
Change their types from string to bigint and add a TypeORM transformer to
correctly handle the conversion between the entity and the database.

src/model/entities/L2PSHashes.ts [45-54]

-@Column("bigint", { default: 0, nullable: false })
-block_number: string
+@Column("bigint", {
+    default: 0,
+    nullable: false,
+    transformer: {
+        to: (value: bigint) => value.toString(),
+        from: (value: string) => BigInt(value),
+    },
+})
+block_number: bigint
 
 /**
  * Timestamp when this hash mapping was stored
  * Used for tracking updates and staleness detection
  */
-// REVIEW: PR Fix - Changed bigint to string (TypeORM returns bigint columns as strings)
-@Column("bigint", { nullable: false })
-timestamp: string
+@Column("bigint", {
+    nullable: false,
+    transformer: {
+        to: (value: bigint) => value.toString(),
+        from: (value: string) => BigInt(value),
+    },
+})
+timestamp: bigint
  • Apply / Chat
Suggestion importance[1-10]: 7

__

Why: The suggestion correctly identifies a type inconsistency between the L2PSHashes manager (using bigint) and the L2PSHash entity (using string). Using a TypeORM transformer is the standard and safest way to handle bigint types, improving type safety and code correctness.

Medium
General
Avoid redundant validator list fetching

Refactor the code to fetch the validator list only once by calling
getCommonValidatorSeed() and getShard() outside the if block, then reuse the
list for both the validator check and the relay logic to avoid redundant calls.

dtr_implementation/DTR_MINIMAL_IMPLEMENTATION.md [43-60]

 // DTR: Check if we should relay instead of storing locally (Production only)
 if (getSharedState.PROD) {
-    const isValidator = await isValidatorForNextBlock()
+    const { commonValidatorSeed } = await getCommonValidatorSeed();
+    const validators = await getShard(commonValidatorSeed);
+    const ourIdentity = getSharedState.identity.ed25519.publicKey.toString("hex");
+    const isValidator = validators.some(peer => peer.identity === ourIdentity);
     
     if (!isValidator) {
         console.log("[DTR] Non-validator node: attempting relay to all validators")
         try {
-            const { commonValidatorSeed } = await getCommonValidatorSeed()
-            const validators = await getShard(commonValidatorSeed)
             const availableValidators = validators
                 .filter(v => v.status.online && v.sync.status)
                 .sort(() => Math.random() - 0.5) // Random order for load balancing
             
             // Try ALL validators in random order
             for (const validator of availableValidators) {
 ...

[To ensure code accuracy, apply this suggestion manually]

Suggestion importance[1-10]: 7

__

Why: The suggestion correctly points out a performance issue where validator data is fetched twice. The proposed refactoring to fetch the data once and reuse it is a valid optimization that improves efficiency.

Medium
Use a more robust shuffling algorithm

Replace the biased array shuffling method sort(() => Math.random() - 0.5) with
the more robust and unbiased Fisher-Yates shuffle algorithm to ensure fair load
distribution.

dtr_implementation/DTR_MINIMAL_IMPLEMENTATION.md [52-54]

 const availableValidators = validators
-    .filter(v => v.status.online && v.sync.status)
-    .sort(() => Math.random() - 0.5) // Random order for load balancing
+    .filter(v => v.status.online && v.sync.status);
 
+// Fisher-Yates shuffle for unbiased random order
+for (let i = availableValidators.length - 1; i > 0; i--) {
+    const j = Math.floor(Math.random() * (i + 1));
+    [availableValidators[i], availableValidators[j]] = [availableValidators[j], availableValidators[i]];
+}
+
  • Apply / Chat
Suggestion importance[1-10]: 6

__

Why: The suggestion correctly identifies that sort(() => Math.random() - 0.5) is a biased shuffling method and proposes the correct Fisher-Yates algorithm, which is crucial for fair load balancing among validators.

Low
Improve cache cleanup performance logic

Optimize the cleanupStaleEntries function by iterating over mempoolHashes and
rebuilding the validityDataCache to improve performance, rather than iterating
and deleting from the cache itself.

src/libs/network/dtr/relayRetryService.ts [81-90]

 // REVIEW: PR Fix - Add null check to prevent runtime error if cache is undefined
 // Remove ValidityData for transactions no longer in mempool
 let cacheEntriesEvicted = 0
 const sharedState = getSharedState()
 if (sharedState?.validityDataCache) {
-    for (const [txHash] of sharedState.validityDataCache) {
-        if (!mempoolHashes.has(txHash)) {
-            sharedState.validityDataCache.delete(txHash)
-            cacheEntriesEvicted++
+    const oldSize = sharedState.validityDataCache.size
+    const newCache = new Map()
+    for (const txHash of mempoolHashes) {
+        if (sharedState.validityDataCache.has(txHash)) {
+            newCache.set(txHash, sharedState.validityDataCache.get(txHash))
         }
     }
+    sharedState.validityDataCache = newCache
+    cacheEntriesEvicted = oldSize - newCache.size
 }

[To ensure code accuracy, apply this suggestion manually]

Suggestion importance[1-10]: 5

__

Why: The suggestion offers a valid performance optimization for cache cleanup, which is more efficient when the cache is larger than the mempool, a likely scenario.

Low
  • Update

@github-actions
Copy link

github-actions bot commented Nov 8, 2025

⚠️ MCP Memory Files Detected

This PR modifies .serena/ files. After merge, these changes will be automatically reverted to preserve branch-specific MCP memories.

Files that will be reverted:

  • .serena/memories/code_style_conventions.md
  • .serena/memories/codebase_structure.md
  • .serena/memories/development_guidelines.md
  • .serena/memories/l2ps_architecture.md
  • .serena/memories/l2ps_code_patterns.md
  • .serena/memories/l2ps_implementation_status.md
  • .serena/memories/l2ps_onboarding_guide.md
  • .serena/memories/l2ps_overview.md
  • .serena/memories/l2ps_remaining_work.md
  • .serena/memories/project_purpose.md
  • .serena/memories/session_2025_01_31_l2ps_completion.md
  • .serena/memories/suggested_commands.md
  • .serena/memories/task_completion_checklist.md
  • .serena/memories/tech_stack.md

coderabbitai[bot]
coderabbitai bot reviewed Nov 8, 2025
View reviewed changes
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 16

🧹 Nitpick comments (6)
src/features/multichain/routines/executors/pay.ts (1)

129-131: Maintain semicolon consistency with the rest of the file.

Lines 129 and 131 remove trailing semicolons, while the rest of the codebase (including this file) consistently uses them. This creates a stylistic inconsistency within the same function and module.

Apply this diff to restore consistency:

-        let signedTx = operation.task.signedPayloads[0]
+        let signedTx = operation.task.signedPayloads[0];
 
-        signedTx = validateIfUint8Array(signedTx)
+        signedTx = validateIfUint8Array(signedTx);
src/model/entities/GCRv2/GCRSubnetsTxs.ts (1)

2-2: Unused import: Transaction is not used in this file.

The Transaction type is imported but never referenced in the file. Consider removing it to keep imports clean.

Apply this diff to remove the unused import:

-import type { L2PSTransaction, Transaction } from "@kynesyslabs/demosdk/types"
+import type { L2PSTransaction } from "@kynesyslabs/demosdk/types"
src/index.ts (1)

396-416: Add consistent error handling for RelayRetryService startup.

The L2PS service startup is wrapped in try-catch (lines 407-413), but the DTR service startup (lines 398-402) lacks error handling. Both services should have consistent error handling for robustness.

Apply this diff:

 // Start DTR relay retry service after background loop initialization
 // The service will wait for syncStatus to be true before actually processing
 if (getSharedState.PROD) {
-    console.log("[DTR] Initializing relay retry service (will start after sync)")
-    // Service will check syncStatus internally before processing
-    RelayRetryService.getInstance().start()
+    try {
+        console.log("[DTR] Initializing relay retry service (will start after sync)")
+        // Service will check syncStatus internally before processing
+        RelayRetryService.getInstance().start()
+    } catch (error) {
+        console.error("[DTR] Failed to start relay retry service:", error)
+    }
 }
src/libs/blockchain/routines/Sync.ts (1)

116-130: LGTM! Non-blocking L2PS participant discovery correctly implemented.

The background discovery pattern is well-designed:

  • Fire-and-forget execution (no await) ensures blockchain sync isn't blocked
  • Error isolation prevents L2PS failures from breaking sync
  • Clear logging for debugging

Optional: Simplify optional chaining for consistency.

The onboarding guide (.serena/memories/l2ps_onboarding_guide.md:314) notes that l2psJoinedUids is always defined with a default of []. The optional chaining (?.) is safe but technically redundant. Consider using direct property access for consistency:

-    if (getSharedState.l2psJoinedUids?.length > 0) {
+    if (getSharedState.l2psJoinedUids.length > 0) {

This same pattern appears at lines 385 and 511 as well.

.serena/memories/l2ps_overview.md (1)

21-31: Optional: Add language specifier to code fence for better rendering.

The transaction flow diagram would benefit from a language specifier for syntax highlighting and proper rendering in documentation viewers.

-```
+```text
 Client → L2PS Node → Decrypt → L2PS Mempool (encrypted storage)
                                       ↓
src/model/entities/L2PSMempool.ts (1)

27-31: Define composite indexes at entity scope.

TypeORM only materializes composite indexes when the decorator sits at the entity/class level. Attaching @Index(["l2ps_uid", "timestamp"]) to the property silently collapses into another single-column index on l2ps_uid, so the intended covering indexes for timestamp, status, and block_number never land in the schema. Move those composite definitions to the class to get the access paths you’re expecting.

-@Entity("l2ps_mempool")
+@Index("idx_l2ps_uid_timestamp", ["l2ps_uid", "timestamp"])
+@Index("idx_l2ps_uid_status", ["l2ps_uid", "status"])
+@Index("idx_l2ps_uid_block_number", ["l2ps_uid", "block_number"])
+@Entity("l2ps_mempool")
 export class L2PSMempoolTx {
@@
-    @Index()
-    @Index(["l2ps_uid", "timestamp"])
-    @Index(["l2ps_uid", "status"])
-    @Index(["l2ps_uid", "block_number"])
+    @Index()
     @Column("text")
     l2ps_uid: string
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

  • Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between c7293c5 and 62b5978.

⛔ Files ignored due to path filters (1)
  • bun.lockb is excluded by !**/bun.lockb
📒 Files selected for processing (53)
  • .gitignore (1 hunks)
  • .serena/.gitignore (1 hunks)
  • .serena/memories/code_style_conventions.md (1 hunks)
  • .serena/memories/codebase_structure.md (1 hunks)
  • .serena/memories/development_guidelines.md (1 hunks)
  • .serena/memories/l2ps_architecture.md (1 hunks)
  • .serena/memories/l2ps_code_patterns.md (1 hunks)
  • .serena/memories/l2ps_implementation_status.md (1 hunks)
  • .serena/memories/l2ps_onboarding_guide.md (1 hunks)
  • .serena/memories/l2ps_overview.md (1 hunks)
  • .serena/memories/l2ps_remaining_work.md (1 hunks)
  • .serena/memories/project_purpose.md (1 hunks)
  • .serena/memories/session_2025_01_31_l2ps_completion.md (1 hunks)
  • .serena/memories/suggested_commands.md (1 hunks)
  • .serena/memories/task_completion_checklist.md (1 hunks)
  • .serena/memories/tech_stack.md (1 hunks)
  • .serena/project.yml (1 hunks)
  • .vscode/extensions.json (1 hunks)
  • .vscode/settings.json (1 hunks)
  • L2PS_PHASES.md (1 hunks)
  • L2PS_TESTING.md (1 hunks)
  • dtr_implementation/DTR_MINIMAL_IMPLEMENTATION.md (1 hunks)
  • dtr_implementation/README.md (1 hunks)
  • dtr_implementation/validator_status_minimal.md (1 hunks)
  • package.json (2 hunks)
  • src/features/InstantMessagingProtocol/signalingServer/plan_of_action_for_offline_messages.md (1 hunks)
  • src/features/InstantMessagingProtocol/signalingServer/signalingServer.ts (10 hunks)
  • src/features/multichain/routines/executors/pay.ts (1 hunks)
  • src/index.ts (2 hunks)
  • src/libs/blockchain/l2ps_hashes.ts (1 hunks)
  • src/libs/blockchain/l2ps_mempool.ts (1 hunks)
  • src/libs/blockchain/mempool_v2.ts (1 hunks)
  • src/libs/blockchain/routines/Sync.ts (4 hunks)
  • src/libs/blockchain/transaction.ts (2 hunks)
  • src/libs/consensus/v2/routines/isValidator.ts (1 hunks)
  • src/libs/l2ps/L2PSConcurrentSync.ts (1 hunks)
  • src/libs/l2ps/L2PSHashService.ts (1 hunks)
  • src/libs/l2ps/L2PS_DTR_IMPLEMENTATION.md (1 hunks)
  • src/libs/l2ps/parallelNetworks.ts (1 hunks)
  • src/libs/network/dtr/relayRetryService.ts (1 hunks)
  • src/libs/network/endpointHandlers.ts (8 hunks)
  • src/libs/network/manageExecution.ts (0 hunks)
  • src/libs/network/manageNodeCall.ts (3 hunks)
  • src/libs/network/routines/transactions/demosWork/handleStep.ts (1 hunks)
  • src/libs/network/routines/transactions/handleL2PS.ts (2 hunks)
  • src/libs/network/server_rpc.ts (1 hunks)
  • src/model/datasource.ts (1 hunks)
  • src/model/entities/GCRv2/GCRSubnetsTxs.ts (2 hunks)
  • src/model/entities/L2PSHashes.ts (1 hunks)
  • src/model/entities/L2PSMempool.ts (1 hunks)
  • src/model/entities/OfflineMessages.ts (1 hunks)
  • src/utilities/sharedState.ts (3 hunks)
  • src/utilities/validateUint8Array.ts (1 hunks)
💤 Files with no reviewable changes (1)
  • src/libs/network/manageExecution.ts
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-10-10T22:57:18.166Z 
Learnt from: tcsenpai
Repo: kynesyslabs/node PR: 477
File: .serena/memories/storage_programs_complete.md:64-82
Timestamp: 2025-10-10T22:57:18.166Z
Learning: Files in the `.serena/memories/` directory should be left alone - do not suggest linting fixes, formatting changes, or other modifications to files in this directory.

Applied to files:

  • .serena/memories/project_purpose.md
  • .serena/memories/task_completion_checklist.md
  • .serena/memories/development_guidelines.md
  • .serena/.gitignore
  • .serena/memories/suggested_commands.md
  • .serena/memories/code_style_conventions.md
  • .serena/project.yml
  • .serena/memories/codebase_structure.md
🧬 Code graph analysis (18)
src/libs/blockchain/mempool_v2.ts (1)
src/utilities/logger.ts (1)
  • error (125-132)
src/libs/consensus/v2/routines/isValidator.ts (2)
src/libs/consensus/v2/routines/getCommonValidatorSeed.ts (1)
  • getCommonValidatorSeed (58-132)
src/utilities/sharedState.ts (1)
  • getSharedState (238-240)
src/index.ts (4)
src/utilities/sharedState.ts (1)
  • getSharedState (238-240)
src/libs/network/dtr/relayRetryService.ts (1)
  • RelayRetryService (22-343)
src/libs/l2ps/L2PSHashService.ts (1)
  • L2PSHashService (24-410)
src/utilities/logger.ts (1)
  • error (125-132)
src/libs/blockchain/routines/Sync.ts (3)
src/utilities/sharedState.ts (1)
  • getSharedState (238-240)
src/libs/l2ps/L2PSConcurrentSync.ts (3)
  • discoverL2PSParticipants (30-88)
  • syncL2PSWithPeer (110-246)
  • exchangeL2PSParticipation (267-303)
src/libs/peer/Peer.ts (1)
  • Peer (15-346)
src/model/entities/OfflineMessages.ts (1)
src/model/entities/L2PSMempool.ts (1)
  • Entity (13-72)
src/model/entities/L2PSMempool.ts (1)
src/model/entities/OfflineMessages.ts (1)
  • Entity (4-34)
src/libs/l2ps/L2PSHashService.ts (3)
src/utilities/sharedState.ts (2)
  • SharedState (17-233)
  • getSharedState (238-240)
src/libs/blockchain/l2ps_mempool.ts (1)
  • L2PSMempool (25-474)
src/libs/consensus/v2/routines/getCommonValidatorSeed.ts (1)
  • getCommonValidatorSeed (58-132)
src/libs/network/server_rpc.ts (1)
src/utilities/sharedState.ts (1)
  • getSharedState (238-240)
src/libs/network/endpointHandlers.ts (8)
src/utilities/sharedState.ts (1)
  • getSharedState (238-240)
src/libs/consensus/v2/routines/isValidator.ts (1)
  • isValidatorForNextBlock (6-15)
src/libs/consensus/v2/routines/getCommonValidatorSeed.ts (1)
  • getCommonValidatorSeed (58-132)
src/libs/consensus/v2/routines/getShard.ts (1)
  • getShard (8-84)
src/utilities/logger.ts (1)
  • error (125-132)
src/libs/network/server_rpc.ts (1)
  • emptyResponse (35-40)
src/libs/l2ps/parallelNetworks.ts (1)
  • ParallelNetworks (61-425)
src/libs/blockchain/l2ps_hashes.ts (1)
  • L2PSHashes (22-234)
src/libs/blockchain/l2ps_hashes.ts (1)
src/utilities/logger.ts (1)
  • error (125-132)
src/features/multichain/routines/executors/pay.ts (1)
src/utilities/validateUint8Array.ts (1)
  • validateIfUint8Array (1-9)
src/libs/blockchain/l2ps_mempool.ts (2)
src/utilities/logger.ts (1)
  • error (125-132)
src/libs/consensus/v2/types/secretaryManager.ts (1)
  • SecretaryManager (15-907)
src/libs/network/dtr/relayRetryService.ts (5)
src/libs/blockchain/mempool_v2.ts (1)
  • Mempool (11-222)
src/utilities/sharedState.ts (1)
  • getSharedState (238-240)
src/utilities/logger.ts (1)
  • error (125-132)
src/libs/consensus/v2/routines/isValidator.ts (1)
  • isValidatorForNextBlock (6-15)
src/libs/consensus/v2/routines/getCommonValidatorSeed.ts (1)
  • getCommonValidatorSeed (58-132)
src/features/InstantMessagingProtocol/signalingServer/signalingServer.ts (3)
src/libs/blockchain/transaction.ts (1)
  • Transaction (50-540)
src/utilities/sharedState.ts (1)
  • getSharedState (238-240)
src/libs/blockchain/mempool_v2.ts (1)
  • Mempool (11-222)
src/libs/network/manageNodeCall.ts (5)
src/utilities/sharedState.ts (1)
  • getSharedState (238-240)
src/libs/consensus/v2/routines/isValidator.ts (1)
  • isValidatorForNextBlock (6-15)
src/libs/blockchain/transaction.ts (2)
  • Transaction (50-540)
  • isCoherent (277-287)
src/libs/blockchain/mempool_v2.ts (1)
  • Mempool (11-222)
src/libs/blockchain/l2ps_mempool.ts (1)
  • L2PSMempool (25-474)
src/libs/l2ps/parallelNetworks.ts (2)
src/utilities/sharedState.ts (1)
  • getSharedState (238-240)
src/libs/blockchain/transaction.ts (1)
  • Transaction (50-540)
src/libs/network/routines/transactions/handleL2PS.ts (4)
src/libs/network/server_rpc.ts (1)
  • emptyResponse (35-40)
src/libs/l2ps/parallelNetworks.ts (1)
  • ParallelNetworks (61-425)
src/libs/blockchain/transaction.ts (1)
  • Transaction (50-540)
src/libs/blockchain/l2ps_mempool.ts (1)
  • L2PSMempool (25-474)
src/libs/l2ps/L2PSConcurrentSync.ts (3)
src/libs/peer/Peer.ts (1)
  • Peer (15-346)
src/utilities/logger.ts (1)
  • error (125-132)
src/libs/blockchain/l2ps_mempool.ts (1)
  • L2PSMempool (25-474)
🪛 Biome (2.1.2)
src/libs/network/endpointHandlers.ts

[error] 401-402: Other switch clauses can erroneously access this declaration.
Wrap the declaration in a block to restrict its access to the switch clause.

The declaration is defined in this switch clause:

Safe fix: Wrap the declaration in a block.

(lint/correctness/noSwitchDeclarations)

🪛 LanguageTool
dtr_implementation/README.md

[grammar] ~252-~252: Use a hyphen to join words.
Context: ... relay optimization - Quality-of-service based routing ### **Phase 3: Incentive ...

(QB_NEW_EN_HYPHEN)

.serena/memories/l2ps_onboarding_guide.md

[style] ~363-~363: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... generation?** → L2PSHashService.ts Need to see sync logic? → `L2PSConcurrentSync...

(REP_NEED_TO_VB)

[style] ~364-~364: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...nc logic?** → L2PSConcurrentSync.ts Need to see endpoints? → manageNodeCall.ts ...

(REP_NEED_TO_VB)

[style] ~365-~365: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...→ manageNodeCall.ts (lines 318-421) Need to see blockchain integration? → `Sync.t...

(REP_NEED_TO_VB)

[style] ~366-~366: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...on?** → Sync.ts (search for "L2PS") Need to understand storage? → `l2ps_mempool.t...

(REP_NEED_TO_VB)

L2PS_PHASES.md

[style] ~595-~595: Consider an alternative to avoid wordiness and to strengthen your wording.
Context: ...ck**: Confirm blockchain sync continues working without issues ### Documentation Check - All new code...

(WORKS_WITHOUT_PROBLEMS)

🪛 markdownlint-cli2 (0.18.1)
dtr_implementation/README.md

51-51: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

.serena/memories/l2ps_architecture.md

5-5: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

50-50: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

67-67: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

90-90: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

115-115: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

138-138: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

156-156: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

179-179: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

L2PS_TESTING.md

45-45: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

86-86: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

190-190: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

222-222: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

250-250: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

280-280: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

297-297: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

314-314: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

.serena/memories/l2ps_onboarding_guide.md

22-22: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

177-177: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

188-188: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

199-199: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

.serena/memories/l2ps_overview.md

21-21: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

src/features/InstantMessagingProtocol/signalingServer/plan_of_action_for_offline_messages.md

14-14: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

130-130: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

279-279: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

295-295: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

303-303: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

310-310: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

343-343: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

dtr_implementation/DTR_MINIMAL_IMPLEMENTATION.md

45-45: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

86-86: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

190-190: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

222-222: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

250-250: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

280-280: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

297-297: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

314-314: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

.serena/memories/codebase_structure.md

6-6: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

23-23: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

41-41: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

55-55: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

65-65: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

75-75: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

🔇 Additional comments (11)
.vscode/extensions.json (1)

33-34: JSON syntax is valid and the extension addition is appropriate.

The trailing comma added to line 33 is correct for valid JSON, and the new VS Code extension recommendation is properly formatted as the final array element.

.vscode/settings.json (1)

1-4: Verify that the configuration reduction is intentional and doesn't impact team workflows.

This change significantly reduces the workspace configuration from a larger set of settings (including formatters, visualization options, and dimmer features per the summary) down to just two UI preferences. While simplification can be beneficial, this substantial reduction warrants verification.

Please confirm:

  1. Was this intentional as part of the L2PS simplification effort, or should some settings be preserved?
  2. Are critical development settings (formatters, linters, extensions configuration) managed elsewhere in the project?
  3. Should the team be notified of this change in case they have local overrides they depend on?
src/model/entities/GCRv2/GCRSubnetsTxs.ts (1)

26-27: No breaking changes from type conversion.

The type change from EncryptedTransaction to L2PSTransaction is safe. EncryptedTransaction does not exist in the codebase, and tx_data is never accessed for property reads—the field is treated as an opaque JSON column by TypeORM. The only mutation is setting it to null, which is compatible with both types.

Likely an incorrect or invalid review comment.

.serena/project.yml (1)

1-84: Serena project configuration looks appropriate.

Standard configuration for TypeScript project with proper tooling defaults, gitignore respect enabled, and no overly restrictive tool exclusions. The project setup aligns with the codebase structure and development guidelines documented elsewhere.

src/utilities/sharedState.ts (1)

57-59: LGTM - Well-designed additions for DTR and L2PS features.

The new validityDataCache Map and l2psJoinedUids array are appropriately scoped and documented. The cache supports the DTR relay retry mechanism, and cleanup logic exists in RelayRetryService to prevent memory leaks.

Also applies to: 85-86

src/libs/network/routines/transactions/demosWork/handleStep.ts (1)

11-11: Missing .js extension in ES module import.

The import path should include the .js extension for proper ESM resolution.

Apply this diff:

-import { L2PSMessage } from "@/libs/l2ps/parallelNetworks_deprecated"
+import { L2PSMessage } from "@/libs/l2ps/parallelNetworks_deprecated.js"

Note: The _deprecated suffix suggests this module may need future refactoring or removal.

Likely an incorrect or invalid review comment.

src/libs/consensus/v2/routines/isValidator.ts (1)

1-3: Missing .js extensions in ES module imports.

All three imports should include .js extensions for proper ESM module resolution.

Apply this diff:

-import getShard from "./getShard"
-import getCommonValidatorSeed from "./getCommonValidatorSeed"
-import { getSharedState } from "@/utilities/sharedState"
+import getShard from "./getShard.js"
+import getCommonValidatorSeed from "./getCommonValidatorSeed.js"
+import { getSharedState } from "@/utilities/sharedState.js"

Likely an incorrect or invalid review comment.

src/libs/blockchain/routines/Sync.ts (2)

30-34: LGTM! Clean L2PS integration imports.

The imports are well-organized and align with the non-blocking L2PS integration hooks added below.

383-396: LGTM! L2PS mempool sync correctly integrated without blocking blockchain operations.

The implementation demonstrates excellent separation of concerns:

  • Runs after successful block download as a background task
  • Per-UID synchronization ensures granular error handling
  • Explicit comment reinforces the critical design principle: "Don't break blockchain sync on L2PS errors"
src/model/entities/L2PSHashes.ts (1)

1-55: LGTM! Well-designed entity for validator hash storage.

The entity implementation demonstrates strong attention to detail:

  • Data integrity: Non-null constraints on critical fields (hash, transaction_count)
  • Type safety: Proper handling of bigint columns as strings to match TypeORM runtime behavior
  • Documentation: Clear JSDoc explaining the privacy model and field purposes
  • Schema design: Primary key on l2ps_uid ensures one hash mapping per L2PS network

The design correctly supports the content-blind validator consensus model described in the documentation.

src/model/entities/OfflineMessages.ts (1)

1-34: LGTM! Well-structured entity for offline messaging.

The entity design is solid with appropriate considerations:

  • Indexing strategy: Efficient lookups by recipient and sender keys for message retrieval
  • Uniqueness: Message hash uniqueness prevents duplicate storage
  • Type safety: Proper bigint-as-string handling consistent with TypeORM behavior
  • Status semantics: The "sent" status accurately reflects websocket semantics (no delivery guarantee)

The schema aligns well with the offline messaging workflow described in the PR documentation.

package.json
"scripts": {
"lint": "prettier --plugin-search-dir . --check . && eslint .",
"lint:fix": "eslint . --fix --ext .ts",
"lint:fix": "eslint . --fix --ext .ts --ignore-pattern 'local_tests/**'",
Copy link
Contributor

@coderabbitai coderabbitai bot Nov 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Use Windows-safe quoting for --ignore-pattern.

npm run executes through cmd.exe on Windows, where single quotes are treated as literal characters. As written, the ignore pattern becomes 'local_tests/**' and never matches, so Windows contributors still lint local_tests/** despite this change. Switch to escaped double quotes so the pattern is honored cross-platform.(archive.eslint.org)

-        "lint:fix": "eslint . --fix --ext .ts --ignore-pattern 'local_tests/**'",
+        "lint:fix": "eslint . --fix --ext .ts --ignore-pattern \"local_tests/**\"",
🤖 Prompt for AI Agents 
In package.json at line 11, the lint:fix script uses single quotes around
--ignore-pattern ('local_tests/**') which are treated literally on Windows;
replace the single quotes with escaped double quotes (i.e. \"local_tests/**\")
so the ignore pattern is honored cross-platform (update the script value
accordingly in package.json).

src/index.ts
Comment on lines +420 to +451
// Graceful shutdown handling for DTR service
process.on("SIGINT", () => {
console.log("[Services] Received SIGINT, shutting down gracefully...")
if (getSharedState.PROD) {
RelayRetryService.getInstance().stop()
}

// Stop L2PS hash service if running
try {
L2PSHashService.getInstance().stop()
} catch (error) {
console.error("[L2PS] Error stopping hash service:", error)
}

process.exit(0)
})

process.on("SIGTERM", () => {
console.log("[Services] Received SIGTERM, shutting down gracefully...")
if (getSharedState.PROD) {
RelayRetryService.getInstance().stop()
}

// Stop L2PS hash service if running
try {
L2PSHashService.getInstance().stop()
} catch (error) {
console.error("[L2PS] Error stopping hash service:", error)
}

process.exit(0)
})
Copy link
Contributor

@coderabbitai coderabbitai bot Nov 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion | 🟠 Major

Eliminate duplicate shutdown logic.

The SIGINT and SIGTERM handlers contain identical shutdown code, violating the DRY principle and making maintenance harder.

Apply this diff to extract common shutdown logic:

+// Graceful shutdown function
+async function gracefulShutdown(signal: string): Promise<void> {
+    console.log(`[Services] Received ${signal}, shutting down gracefully...`)
+    
+    if (getSharedState.PROD) {
+        RelayRetryService.getInstance().stop()
+    }
+    
+    // Stop L2PS hash service if running
+    try {
+        await L2PSHashService.getInstance().stop()
+    } catch (error) {
+        console.error("[L2PS] Error stopping hash service:", error)
+    }
+    
+    process.exit(0)
+}
+
-// Graceful shutdown handling for DTR service
-process.on("SIGINT", () => {
-    console.log("[Services] Received SIGINT, shutting down gracefully...")
-    if (getSharedState.PROD) {
-        RelayRetryService.getInstance().stop()
-    }
-    
-    // Stop L2PS hash service if running
-    try {
-        L2PSHashService.getInstance().stop()
-    } catch (error) {
-        console.error("[L2PS] Error stopping hash service:", error)
-    }
-    
-    process.exit(0)
-})
-
-process.on("SIGTERM", () => {
-    console.log("[Services] Received SIGTERM, shutting down gracefully...")
-    if (getSharedState.PROD) {
-        RelayRetryService.getInstance().stop()
-    }
-    
-    // Stop L2PS hash service if running
-    try {
-        L2PSHashService.getInstance().stop()
-    } catch (error) {
-        console.error("[L2PS] Error stopping hash service:", error)
-    }
-    
-    process.exit(0)
-})
+process.on("SIGINT", () => gracefulShutdown("SIGINT"))
+process.on("SIGTERM", () => gracefulShutdown("SIGTERM"))
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
// Graceful shutdown handling for DTR service
process.on("SIGINT", () => {
console.log("[Services] Received SIGINT, shutting down gracefully...")
if (getSharedState.PROD) {
RelayRetryService.getInstance().stop()
}
// Stop L2PS hash service if running
try {
L2PSHashService.getInstance().stop()
} catch (error) {
console.error("[L2PS] Error stopping hash service:", error)
}
process.exit(0)
})
process.on("SIGTERM", () => {
console.log("[Services] Received SIGTERM, shutting down gracefully...")
if (getSharedState.PROD) {
RelayRetryService.getInstance().stop()
}
// Stop L2PS hash service if running
try {
L2PSHashService.getInstance().stop()
} catch (error) {
console.error("[L2PS] Error stopping hash service:", error)
}
process.exit(0)
})
// Graceful shutdown function
async function gracefulShutdown(signal: string): Promise<void> {
console.log(`[Services] Received ${signal}, shutting down gracefully...`)
if (getSharedState.PROD) {
RelayRetryService.getInstance().stop()
}
// Stop L2PS hash service if running
try {
await L2PSHashService.getInstance().stop()
} catch (error) {
console.error("[L2PS] Error stopping hash service:", error)
}
process.exit(0)
}
process.on("SIGINT", () => gracefulShutdown("SIGINT"))
process.on("SIGTERM", () => gracefulShutdown("SIGTERM"))
🤖 Prompt for AI Agents 
In src/index.ts around lines 420 to 451, the SIGINT and SIGTERM handlers
duplicate the same shutdown logic; extract that logic into a single shared
function (e.g., handleShutdown or gracefulShutdown) that performs logging,
conditionally stops RelayRetryService when getSharedState.PROD, stops
L2PSHashService inside a try/catch, and exits the process, then register that
function as the callback for both process.on("SIGINT", ...) and
process.on("SIGTERM", ...). Ensure the shared function preserves existing
console messages, error logging, and calls process.exit(0) at the end.

src/libs/blockchain/l2ps_hashes.ts
Comment on lines +39 to +41
log.error("[L2PS Hashes] Failed to initialize:", error)
throw error
}
Copy link
Contributor

@coderabbitai coderabbitai bot Nov 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Log the actual error details

log.error("[L2PS Hashes] Failed to initialize:", error) is passing the error object into the logToTerminal boolean slot (see src/utilities/logger.ts). As a result the stack/message never reaches the logs, which makes diagnosing init failures very hard. Please stringify/embed the error into the message (same applies to the other log.error calls in this class).

-            log.error("[L2PS Hashes] Failed to initialize:", error)
+            const details = error instanceof Error ? error.stack ?? error.message : JSON.stringify(error)
+            log.error(`[L2PS Hashes] Failed to initialize: ${details}`)
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
log.error("[L2PS Hashes] Failed to initialize:", error)
throw error
}
const details = error instanceof Error ? error.stack ?? error.message : JSON.stringify(error)
log.error(`[L2PS Hashes] Failed to initialize: ${details}`)
throw error
}
🤖 Prompt for AI Agents 
In src/libs/blockchain/l2ps_hashes.ts around lines 39-41, the call
log.error("[L2PS Hashes] Failed to initialize:", error) is passing the Error
object into the boolean slot of logToTerminal so the stack/message is not
logged; replace it by embedding/stringifying the error into the message (e.g.
build a string using error instanceof Error ? (error.stack || error.message) :
JSON.stringify(error)) and call log.error with that single string, and apply the
same stringifying/embed pattern to the other log.error calls in this class so
the actual error details are logged.

src/libs/blockchain/l2ps_mempool.ts
Comment on lines +163 to +167
log.error("[L2PS Mempool] Error adding transaction:", error)
return {
success: false,
error: error.message || "Unknown error",
}
Copy link
Contributor

@coderabbitai coderabbitai bot Nov 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Preserve stack traces in error logs

Here (and elsewhere in this class) we call log.error("[L2PS Mempool] Error adding transaction:", error). Because logger.error only accepts (message: string, logToTerminal?: boolean), the error object is swallowed—we just set the terminal flag and lose the stack/message. That makes production incidents opaque. Please embed the error details in the string (and update the other log.error invocations here accordingly).

-            log.error("[L2PS Mempool] Error adding transaction:", error)
+            const details = error instanceof Error ? error.stack ?? error.message : JSON.stringify(error)
+            log.error(`[L2PS Mempool] Error adding transaction: ${details}`)
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
log.error("[L2PS Mempool] Error adding transaction:", error)
return {
success: false,
error: error.message || "Unknown error",
}
const details = error instanceof Error ? error.stack ?? error.message : JSON.stringify(error)
log.error(`[L2PS Mempool] Error adding transaction: ${details}`)
return {
success: false,
error: error.message || "Unknown error",
}
🤖 Prompt for AI Agents 
In src/libs/blockchain/l2ps_mempool.ts around lines 163 to 167, the logger call
passes the Error object as a second argument and thus loses the stack/message
because logger.error only accepts (message: string, logToTerminal?: boolean);
change the call to interpolate the error details into the message string (for
example include error.stack || error.message || String(error)) and remove the
second argument; apply the same pattern to other log.error invocations in this
class so every error log includes the error stack/message in the formatted
string rather than passing the error object as a separate parameter.

src/libs/network/endpointHandlers.ts
Comment on lines +772 to +817
if (!tx.block_number) {
response.result = 400
response.response = "Missing block_number"
response.extra = "L2PS hash updates require valid block_number (cannot default to 0)"
return response
}

const payloadData = tx.content.data[1]

// Validate payload has required L2PSHashPayload structure
if (
typeof payloadData !== "object" ||
!("l2ps_uid" in payloadData) ||
!("consolidated_hash" in payloadData) ||
!("transaction_count" in payloadData)
) {
response.result = 400
response.response = "Invalid L2PS hash payload"
response.extra = "Missing required fields: l2ps_uid, consolidated_hash, or transaction_count"
return response
}

// Extract L2PS hash payload from transaction data with proper typing
const l2psHashPayload = payloadData as L2PSHashPayload
const l2psUid = l2psHashPayload.l2ps_uid

// Validate sender is part of the L2PS network
const parallelNetworks = ParallelNetworks.getInstance()
const l2psInstance = await parallelNetworks.getL2PS(l2psUid)

if (!l2psInstance) {
response.result = 403
response.response = "Not participant in L2PS network"
response.extra = `L2PS network ${l2psUid} not found or not joined`
return response
}

// REVIEW: Store hash update for validator consensus (Phase 3b)
// Validators store ONLY UID → hash mappings (content blind)
try {
await L2PSHashes.updateHash(
l2psHashPayload.l2ps_uid,
l2psHashPayload.consolidated_hash,
l2psHashPayload.transaction_count,
BigInt(tx.block_number), // Now guaranteed to exist due to validation above
)
Copy link
Contributor

@coderabbitai coderabbitai bot Nov 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

Fix blockNumber validation to avoid rejecting every hash update.

Transaction instances expose blockNumber (camelCase). Checking tx.block_number always yields undefined, so this branch fires for every legitimate hash update and you return 400, preventing validators from persisting any L2PS hash updates. The falsy check also blocks block height 0 if it ever appears. Guard against undefined/null on the camelCase property and use it when persisting.

-        if (!tx.block_number) {
-            response.result = 400
-            response.response = "Missing block_number"
-            response.extra = "L2PS hash updates require valid block_number (cannot default to 0)"
+        if (tx.blockNumber === undefined || tx.blockNumber === null) {
+            response.result = 400
+            response.response = "Missing blockNumber"
+            response.extra = "L2PS hash updates require a valid blockNumber"
             return response
         }
…
-                    BigInt(tx.block_number), // Now guaranteed to exist due to validation above
+                    BigInt(tx.blockNumber), // Now guaranteed to exist due to validation above
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
if (!tx.block_number) {
response.result = 400
response.response = "Missing block_number"
response.extra = "L2PS hash updates require valid block_number (cannot default to 0)"
return response
}
const payloadData = tx.content.data[1]
// Validate payload has required L2PSHashPayload structure
if (
typeof payloadData !== "object" ||
!("l2ps_uid" in payloadData) ||
!("consolidated_hash" in payloadData) ||
!("transaction_count" in payloadData)
) {
response.result = 400
response.response = "Invalid L2PS hash payload"
response.extra = "Missing required fields: l2ps_uid, consolidated_hash, or transaction_count"
return response
}
// Extract L2PS hash payload from transaction data with proper typing
const l2psHashPayload = payloadData as L2PSHashPayload
const l2psUid = l2psHashPayload.l2ps_uid
// Validate sender is part of the L2PS network
const parallelNetworks = ParallelNetworks.getInstance()
const l2psInstance = await parallelNetworks.getL2PS(l2psUid)
if (!l2psInstance) {
response.result = 403
response.response = "Not participant in L2PS network"
response.extra = `L2PS network ${l2psUid} not found or not joined`
return response
}
// REVIEW: Store hash update for validator consensus (Phase 3b)
// Validators store ONLY UID → hash mappings (content blind)
try {
await L2PSHashes.updateHash(
l2psHashPayload.l2ps_uid,
l2psHashPayload.consolidated_hash,
l2psHashPayload.transaction_count,
BigInt(tx.block_number), // Now guaranteed to exist due to validation above
)
if (tx.blockNumber === undefined || tx.blockNumber === null) {
response.result = 400
response.response = "Missing blockNumber"
response.extra = "L2PS hash updates require a valid blockNumber"
return response
}
const payloadData = tx.content.data[1]
// Validate payload has required L2PSHashPayload structure
if (
typeof payloadData !== "object" ||
!("l2ps_uid" in payloadData) ||
!("consolidated_hash" in payloadData) ||
!("transaction_count" in payloadData)
) {
response.result = 400
response.response = "Invalid L2PS hash payload"
response.extra = "Missing required fields: l2ps_uid, consolidated_hash, or transaction_count"
return response
}
// Extract L2PS hash payload from transaction data with proper typing
const l2psHashPayload = payloadData as L2PSHashPayload
const l2psUid = l2psHashPayload.l2ps_uid
// Validate sender is part of the L2PS network
const parallelNetworks = ParallelNetworks.getInstance()
const l2psInstance = await parallelNetworks.getL2PS(l2psUid)
if (!l2psInstance) {
response.result = 403
response.response = "Not participant in L2PS network"
response.extra = `L2PS network ${l2psUid} not found or not joined`
return response
}
// REVIEW: Store hash update for validator consensus (Phase 3b)
// Validators store ONLY UID → hash mappings (content blind)
try {
await L2PSHashes.updateHash(
l2psHashPayload.l2ps_uid,
l2psHashPayload.consolidated_hash,
l2psHashPayload.transaction_count,
BigInt(tx.blockNumber), // Now guaranteed to exist due to validation above
)
🤖 Prompt for AI Agents 
In src/libs/network/endpointHandlers.ts around lines 772 to 817, the code checks
tx.block_number which is always undefined (Transaction exposes camelCase
blockNumber) and uses a falsy check that would also reject a legitimate block
height of 0; change the validation to explicitly guard against undefined/null on
tx.blockNumber (e.g. if (tx.blockNumber === undefined || tx.blockNumber ===
null) { ... }) and then use tx.blockNumber when persisting
(BigInt(tx.blockNumber)), replacing all tx.block_number references accordingly.

src/libs/network/manageNodeCall.ts
Comment on lines +287 to +293
const signatureValid = TxUtils.validateSignature(transaction)
if (!signatureValid) {
log.error("[DTR] Transaction signature validation failed: " + transaction.hash)
response.result = 400
response.response = "Transaction signature validation failed"
break
}
Copy link
Contributor

@coderabbitai coderabbitai bot Nov 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

Fix signature validation for relayed transactions.

TxUtils.validateSignature returns a Promise<{ success: boolean; message: string }>; without awaiting it (and checking success) this branch always treats the relay as valid, so a forged payload walks straight into the validator’s mempool. Await the call and reject whenever success is false (logging the reason) to keep invalid transactions out.

-                const signatureValid = TxUtils.validateSignature(transaction)
-                if (!signatureValid) {
-                    log.error("[DTR] Transaction signature validation failed: " + transaction.hash)
-                    response.result = 400
-                    response.response = "Transaction signature validation failed"
+                const signatureValidation = await TxUtils.validateSignature(transaction)
+                if (!signatureValidation.success) {
+                    log.error(
+                        `[DTR] Transaction signature validation failed for ${transaction.hash}: ${signatureValidation.message}`,
+                    )
+                    response.result = 400
+                    response.response =
+                        signatureValidation.message ||
+                        "Transaction signature validation failed"
                     break
                 }
🤖 Prompt for AI Agents 
In src/libs/network/manageNodeCall.ts around lines 287 to 293, the code calls
TxUtils.validateSignature without awaiting it and treats the return as a
boolean; change this to await TxUtils.validateSignature(transaction), check the
returned object’s success property, and if success is false log the returned
message/reason, set response.result = 400 and response.response to the failure
message, then break to reject the transaction so forged/invalid relayed
transactions are not accepted.

src/libs/network/routines/transactions/handleL2PS.ts
Comment on lines +80 to +86
const verificationResult = await Transaction.confirmTx(decryptedTx, decryptedTx.content.from)
if (!verificationResult) {
response.result = 400
response.response = false
response.extra = "Transaction signature verification failed"
return response
}
Copy link
Contributor

@coderabbitai coderabbitai bot Nov 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

Respect the validation result from Transaction.confirmTx.

Transaction.confirmTx never throws on signature/coherence failure; it returns { success: false, message, confirmation: null }. Because the code only checks for a falsy value, failed validations still flow to the L2PS mempool. Use the returned success flag (and message) to short‑circuit invalid decrypted transactions.

-    const verificationResult = await Transaction.confirmTx(decryptedTx, decryptedTx.content.from)
-    if (!verificationResult) {
-        response.result = 400
-        response.response = false
-        response.extra = "Transaction signature verification failed"
-        return response
-    }
+    const verificationResult = await Transaction.confirmTx(
+        decryptedTx,
+        decryptedTx.content.from,
+    )
+    if (!verificationResult?.success) {
+        response.result = 400
+        response.response = false
+        response.extra =
+            verificationResult?.message ||
+            "Transaction signature verification failed"
+        return response
+    }
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
const verificationResult = await Transaction.confirmTx(decryptedTx, decryptedTx.content.from)
if (!verificationResult) {
response.result = 400
response.response = false
response.extra = "Transaction signature verification failed"
return response
}
const verificationResult = await Transaction.confirmTx(
decryptedTx,
decryptedTx.content.from,
)
if (!verificationResult?.success) {
response.result = 400
response.response = false
response.extra =
verificationResult?.message ||
"Transaction signature verification failed"
return response
}
🤖 Prompt for AI Agents 
In src/libs/network/routines/transactions/handleL2PS.ts around lines 80 to 86,
Transaction.confirmTx returns an object like { success: boolean, message:
string, confirmation: any } and the current code only checks for a falsy value,
letting failed validations proceed; update the logic to inspect
verificationResult.success and when false set response.result to 400,
response.response to false and response.extra to verificationResult.message (or
a fallback message), then return response to short‑circuit invalid decrypted
transactions.

@github-actions
Copy link

github-actions bot commented Nov 10, 2025

⚠️ MCP Memory Files Detected

This PR modifies .serena/ files. After merge, these changes will be automatically reverted to preserve branch-specific MCP memories.

Files that will be reverted:

  • .serena/memories/code_style_conventions.md
  • .serena/memories/codebase_structure.md
  • .serena/memories/development_guidelines.md
  • .serena/memories/l2ps_architecture.md
  • .serena/memories/l2ps_code_patterns.md
  • .serena/memories/l2ps_implementation_status.md
  • .serena/memories/l2ps_onboarding_guide.md
  • .serena/memories/l2ps_overview.md
  • .serena/memories/l2ps_remaining_work.md
  • .serena/memories/project_purpose.md
  • .serena/memories/session_2025_01_31_l2ps_completion.md
  • .serena/memories/suggested_commands.md
  • .serena/memories/task_completion_checklist.md
  • .serena/memories/tech_stack.md

@tcsenpai
Copy link
Contributor Author

tcsenpai commented Dec 6, 2025

Your trial has ended! 😢

To keep getting reviews, activate your plan here.

Got questions about plans or want to see if we can extend your trial? Talk to our founders here.😎

coderabbitai[bot]
coderabbitai bot reviewed Dec 6, 2025
View reviewed changes
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (2)
AGENTS.md (2)

103-108: Use heading syntax for better document structure.

Line 103 uses bold emphasis (**Recommended approach:**) where a proper markdown heading would be more appropriate for navigation and document hierarchy.

-**Recommended approach:**
-- Create a `history/` directory in the project root
+### Recommended Approach
+
+- Create a `history/` directory in the project root

112-115: Specify language for fenced code block.

The .gitignore example lacks a language identifier for syntax highlighting.

-**Example .gitignore entry (optional):**
-```
+**Example .gitignore entry (optional):**
+```gitignore
 # AI planning documents (ephemeral)
 history/
-```
+```
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

  • Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 53d71e6 and f0ae38f.

📒 Files selected for processing (6)
  • .beads/.gitignore (1 hunks)
  • .beads/.local_version (1 hunks)
  • .beads/config.yaml (1 hunks)
  • .beads/metadata.json (1 hunks)
  • .gitignore (3 hunks)
  • AGENTS.md (1 hunks)
✅ Files skipped from review due to trivial changes (4)
  • .beads/metadata.json
  • .beads/.gitignore
  • .beads/config.yaml
  • .beads/.local_version
🧰 Additional context used
🪛 LanguageTool
AGENTS.md

[uncategorized] ~73-~73: The official name of this software platform is spelled with a capital “H”.
Context: ...n If using GitHub Copilot, also create .github/copilot-instructions.md for automatic ...

(GITHUB)

🪛 markdownlint-cli2 (0.18.1)
AGENTS.md

103-103: Emphasis used instead of a heading

(MD036, no-emphasis-as-heading)

112-112: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

🔇 Additional comments (2)
AGENTS.md (1)

1-134: LGTM — Well-structured documentation for AI agent workflow.

The documentation provides clear, actionable guidance on using bd for centralized issue tracking, establishing consistent workflows, and managing ephemeral planning documents. The emphasis on using bd exclusively (avoiding markdown TODOs) and the history/ directory pattern for AI-generated planning docs aligns well with good project governance practices. The quick-start commands and rules are practical and easy to follow.

Before merging, please verify that:

  • The bd tool and all referenced commands (bd ready, bd create, bd update, bd close, bd onboard) are installed and available in this project's development environment
  • The .beads/issues.jsonl path and format match the actual bd configuration
  • The GitHub Copilot integration guidance aligns with team setup (if Copilot is in use)
.gitignore (1)

193-205: Clarify the purpose of PR review artifact patterns.

Lines 193–205 add numerous PR review markdown files to .gitignore (e.g., PR_REVIEW.md, BUGS_AND_SECURITY_REPORT.md, ZK_CEREMONY_GUIDE.md, CEREMONY_COORDINATION.md, etc.). These appear to be temporary or one-off analysis artifacts from the review process.

Adding specific PR-related ignore patterns to the long-term .gitignore is unusual unless these files are expected to persist in local development environments. If these are temporary artifacts that should not be committed, clean them up now rather than adding rules for them. If they are intentional, document their purpose.

.gitignore
Comment on lines +114 to 127
CLAUDE.md
data/l2ps/example/config.json
data/l2ps/example/iv.key
data/l2ps/example/config.json
data/l2ps/example/iv.key
data/l2ps/*

# Claude specific files
CLAUDE.md
GEMINI.md

architecture.gitbook-cache.json
architecture
architecture
Copy link
Contributor

@coderabbitai coderabbitai bot Dec 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Remove duplicate ignore entries.

Several entries are duplicated, creating redundancy and suggesting the file wasn't carefully reviewed before commit:

  • Line 114 (CLAUDE.md) duplicates line 122
  • Lines 115–116 (data/l2ps/example/*) duplicate lines 117–118
  • Line 126 (architecture) duplicates line 127
  • Line 119 (data/l2ps/*) already covers the example/ subdirectory entries, making lines 115–118 partially redundant

Clean up the duplicates and consolidate patterns where feasible to keep the file maintainable.

Suggested cleanup:

 # L2PS files
-CLAUDE.md
-data/l2ps/example/config.json
-data/l2ps/example/iv.key
 data/l2ps/example/config.json
 data/l2ps/example/iv.key
 data/l2ps/*
 
 # Claude specific files
 CLAUDE.md
-architecture
 architecture

Or, if the broader pattern data/l2ps/* is preferred, remove the more specific example/ entries entirely.

Committable suggestion skipped: line range outside the PR's diff.

🤖 Prompt for AI Agents 
In .gitignore around lines 114 to 127, there are duplicate and redundant entries
(CLAUDE.md repeated, data/l2ps/example/config.json and iv.key duplicated,
data/l2ps/* already covers the example/ entries, and architecture repeated);
remove the duplicated lines and consolidate by keeping a single CLAUDE.md,
remove the specific data/l2ps/example/* lines if you keep data/l2ps/* (or vice
versa), and keep only one architecture entry so each ignore pattern appears
once.

@tcsenpai
Copy link
Contributor Author

tcsenpai commented Dec 6, 2025

Your trial has ended! 😢

To keep getting reviews, activate your plan here.

Got questions about plans or want to see if we can extend your trial? Talk to our founders here.😎

@sonarqubecloud
Copy link

sonarqubecloud bot commented Dec 6, 2025

Quality Gate Failed Quality Gate failed

Failed conditions
4 Security Hotspots
C Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@coderabbitai coderabbitai[bot] coderabbitai[bot] left review comments

@cwilvx cwilvx Awaiting requested review from cwilvx

Assignees

No one assigned

Labels

Review effort 5/5

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@tcsenpai