Add BDLS research findings and refactor notes

[Scapesfear]

This document presents a detailed technical analysis and refactor plan for integrating BDLS (Blockchain DLS) consensus into the Hyperledger Fabric framework using Fabric’s native gRPC-based Cluster Service instead of the current raw TCP transport.
It summarizes the architectural differences, missing integrations, and the steps required to align BDLS with Fabric’s production-ready communication infrastructure.

---

Key Findings

• Current Limitation: The BDLS Proof of Concept currently uses a custom agent-tcp transport that bypasses Fabric’s cluster.RPC and AuthCommMgr infrastructure.
• Architecture Analysis: Compared and contrasted BDLS, SmartBFT, and etcdraft communication models, confirming Fabric’s transport layer is fully gRPC-driven.
• Identified Bottleneck: The BDLS PeerInterface tightly couples the consensus logic with network-level code, blocking clean integration with Fabric’s cluster service.
• Security Gaps: BDLS currently reimplements authentication via ECDH/HMAC over TCP instead of leveraging Fabric’s TLS-based authenticated channels.

---

Proposed Refactor

1. Remove Custom TCP Agent:
   Eliminate agent.TCPAgent and related networking logic from chain.go.

2. Adopt Fabric gRPC Transport:
   Use Fabric’s cluster.Communicator and cluster.RPC for inter-node messaging (SendConsensus).

3. Implement Fabric-Compatible Egress/Ingress:

   • Redirect all BDLS message broadcasting through Egress.SendConsensus.
   • Use the existing Fabric ClusterService for inbound messages (Ingress.OnConsensus).

4. Modify BDLS Core:
   Replace PeerInterface with a transport-agnostic Transmitter interface for ID-based message delivery.

5. Integrate Secure Auth:
   Leverage Fabric’s AuthCommMgr for authenticated, TLS-bound gRPC channels.

[Copilot]

Copilot wasn't able to review any files in this pull request.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.