build(p2p): internalize libp2p as local module

[barbatos2011]

What

Internalize io.github.tronprotocol:libp2p:2.2.7 source code as a new p2p/ gradle submodule, replacing the external Maven dependency. No functional changes to P2P behavior, protocol, or consensus.

Why

The external libp2p repository had a 2.5-year development gap (2023.3 ~ 2025.10). Cross-repo maintenance creates friction:

• Version coordination overhead: Modifying P2P behavior requires publishing libp2p first, then updating java-tron's dependency version
• Debugging difficulty: IDE cannot jump into external artifact source; requires downloading source JARs
• CI dependency: Build depends on external Maven/JitPack artifact availability
• Industry alignment: geth (go-ethereum) maintains its p2p/ package within the monorepo; this follows the same pattern

Changes

Commit 1: chore(p2p): add libp2p v2.2.7 source as p2p module

• Copy 90 main Java files (including embedded org.web3j crypto utils) + 2 proto files + 26 test files from tronprotocol/libp2p tag v2.2.7
• Create p2p/build.gradle with protobuf plugin configuration
• Add p2p/lombok.config to temporarily override root logger field name (log vs logger)
• Move example code (StartApp) to src/test/java (not packaged in JAR, but available for reference)
• Register module in settings.gradle, update gradle/verification-metadata.xml

Commit 2: style(p2p): replace log field with logger

• Replace all @Slf4j-generated log references with logger (35 files) to match root lombok.config (lombok.log.fieldName=logger)
• Remove temporary p2p/lombok.config override

Commit 3: build(common): switch from external libp2p to local p2p module

• common/build.gradle: replace 17 lines (Maven dependency + 11 exclude rules) with single api project(':p2p')
• Remove io.github.tronprotocol:libp2p:2.2.7 entry from gradle/verification-metadata.xml

Commit 4: style(p2p): fix checkstyle violations and enable checkstyle

• Apply google-java-format for bulk formatting (indentation, imports, whitespace)
• Manual fixes: lambda indentation, line length wrapping, empty catch blocks, star imports
• Enable checkstyle plugin with proto-generated code excluded (exclude '**/protos/**')
• ~1374 of 1454 violations were from proto-generated code; after exclusion only 80 remained in handwritten code

Commit 5: fix(p2p): address review findings

• Replace BasicThreadFactory.builder() (requires commons-lang3 3.12+) with new BasicThreadFactory.Builder() (available since 3.0) to prevent implicit global version upgrade from 3.4 to 3.18.0
• Remove unused grpc-core dependency; retain grpc-netty as Netty transport provider (p2p uses 30+ Netty imports for TCP/UDP but zero gRPC imports)
• Remove gRPC protoc plugin from protobuf config (p2p protos define only messages, no services)
• Add p2p/.gitignore to exclude proto-generated code for all developers

Commit 6: fix(p2p): replace Math with StrictMath and fix flaky network tests

• Replace Math.min/max with StrictMath.min/max in 5 files to satisfy CI check-math rule (integer operations, results identical)
• Rewrite NetUtilTest.testGetIP with mocked URLConnection — original test called 3 external IP services which failed in CI (libp2p's own CI never ran tests with -xtest)
• New mock tests cover: valid IP response, connection failure, invalid IP, empty response
• Remove testExternalIp (covered by mock tests), fix testGetLanIP to not depend on external connectivity

Key Design Decisions

Decision	Choice	Rationale
Module name	p2p	Matches package org.tron.p2p, geth p2p/ convention, project short-name style (common, crypto, etc.)
Proto files	Stay in p2p module	P2P protocol is separate from chain protocol in protocol/; avoids coupling
Example code	Move to src/test/java	Not packaged in jar, but accessible for external developers referencing the source
commons-lang3	3.4 (global consistent)	Rewrite builder() → new Builder() (3.0 API) instead of upgrading globally
grpc-netty retained	Yes	Provides Netty transitively; same as original libp2p; version auto-aligns with protocol module
grpc-core + grpc plugin removed	Yes	p2p protos have no service definitions, zero io.grpc imports in source
Checkstyle proto exclude	**/protos/**	Proto-generated code has ~1374 violations; consistent with protocol module approach
Math → StrictMath	All 5 call sites	CI check-math rule; integer min/max results are identical
testGetIP mock rewrite	URLConnection mock	Original depended on external services; libp2p CI never ran tests

Scope

• Does NOT change any P2P protocol behavior or message formats
• Does NOT change consensus rules or transaction validation logic
• Does NOT modify protobuf definitions
• Does NOT require hard fork
• All 38 files importing org.tron.p2p are unchanged (package name preserved)
• Existing nodes upgrading need only git pull and rebuild

Known Issues (pre-existing in libp2p)

The following issues exist in the original libp2p v2.2.7 codebase and are NOT introduced by this PR. They will be addressed in follow-up PRs:

Critical:

• Node ID generation uses weak PRNG (java.util.Random instead of SecureRandom) — eclipse attack vector
• Handshake lacks cryptographic authentication (self-reported node ID, no signature verification)
• Neighbor injection has no count limit per response

High:

• TOCTOU race in ChannelManager.handMessage (double onConnect)
• DNS sync uses predictable java.util.Random
• Algorithm.compressPubKey drops leading zeros from public key X-coordinate

Medium (from Cubic AI review):

• Node.equals compares byte[] via new String(id) instead of Arrays.equals
• Channel.hashCode() NPE when inetSocketAddress is null
• InterruptedException swallowed in DiscoverServer and PeerClient
• Several minor NPE risks and unclosed resources

Test

• p2p module: 63 tests (22 test classes), all pass
• Full build: BUILD SUCCESSFUL (12m, ~2319 tests, 0 failures)
• checkstyleMain + checkstyleTest: PASS for all modules including p2p
• check-math: PASS
• Node integration test: FullNode started with mainnet config, connected to peers, synced 14,000+ blocks successfully
• Flaky net tests (PbftMsgHandler, TronStatsManager): confirmed pre-existing, pass on retry

[xxo1shine]

@barbatos2011 What is the primary motivation for integrating libp2p into java-tron at this stage?
Also, considering that libp2p is undergoing protocol upgrades, would it be more appropriate to wait until the protocol stabilizes before proceeding with the integration?

[xxo1shine]

@barbatos2011 Should the unit tests related to the libp2p module be moved to the framework module?

[barbatos2011]

@xxo1shine Thanks for the questions. Let me address both:

On the motivation for integrating now

The main driver is reducing cross-repo maintenance friction, not adding features. Three concrete pain points with the current setup:

1. Version coordination overhead — any P2P change today requires: modify tronprotocol/libp2p → publish artifact → bump java-tron's dependency version → CI roundtrip. Post-internalization, it's a single PR, which actually accelerates future changes.

2. Debugging difficulty — IDE navigation into external artifact source requires downloading source JARs; stack traces point to decompiled code during incidents.

3. Build-time external dependency — CI depends on Maven/JitPack artifact availability for every build.

This follows the same pattern as go-ethereum, which keeps its p2p/ package in the monorepo for the same reasons.

On waiting for protocol stability

Fair concern, but the data doesn't support "active upgrade" framing:

• From 2023-04 to 2024-10 the upstream repo saw only sporadic maintenance (0-3 commits/month, many months with none). Development resumed properly in 2025-03 (v2.2.6) and 2025-08~11 (v2.2.7). So "waiting for stability" doesn't match the pattern — the repo isn't mid-upgrade, it's in a pattern of long quiet periods with release bursts.
• There is no published roadmap for incoming protocol changes.
• Internalization is explicitly scoped to zero functional change — no P2P behavior, protocol format, or consensus logic is modified. The PR is purely a build/source-layout change, so the risk surface of integration itself is minimal.

If libp2p protocol upgrades do come later, they can be applied as normal PRs to the internalized module — in fact that will be easier than the current cross-repo flow. Waiting would mean indefinite deferral without a clear signal for what "stable" means here.

Happy to discuss further if you see specific upgrade work that would be disrupted by this change.