Chương 1. TỔNG QUAN VỀ BLOCKCHAIN VÀ NỀN TẢNG
1.5. NỀN TẢNG BLOCKCHAIN HYPERLEDGER FABRIC
1.5.3. Xử lý lưu lượng mạng, khám phá và vận hành dịch vụ
Tắc nghẽn lưu lượng mạng là một trong những vấn đề tiềm tàng nhất trên kênh Fabric, do có nhiều tổ chức tham gia kênh. Mỗi tổ chức lại có thể sở hữu nhiều nút peer. Nếu số lượng tổ chức tham gia và các nút peer liên quan tăng lên theo thời gian, Orderer sẽ bị quá tải trong việc phân phối các block giao dịch cho mọi nút peer trên mỗi kênh. Vì vậy, Orderer dễ trở thành điểm lỗi đơn. Để cung cấp khả năng chịu lỗi CFT cho Orderer, Hyperledger Fabric hiện hỗ trợ hai loại dịch vụ sắp xếp CFT là Kafka và Raft. Ngoài ra, một số loại dịch vụ sắp xếp chịu lỗi Byzantine (BFT) cũng đang được phát triển [3]..
Để giảm bớt gánh nặng phân phối block cho nút Orderer , khái niệm “Leader Peer” được đưa ra cho tất cả các tổ chức tham gia [7].. Mỗi tổ chức có thể cho phép lựa chọn nút peer nào trở thành Leader Peer.
Hình 1.14 Cơ chế phân phối block dùng các leader peer
Như Hình 1 .14, Peer #2 của Org1 và Peer #2 của Org2 được chỉ định là các Leader Peer. Lưu đồ các bước của cơ chế phân phối block dùng Leader Peer:
Bước 1: Client gửi đề xuất giao dịch đến các nút bảo chứng đã chọn.
Bước 2: Mỗi nút bảo chứng tạo ra một phản hồi giao dịch và gửi phản hồi được chứng thực trở lại cho Client.
Bước 3: Client gửi giao dịch đính kèm các phản hồi được chứng thực cho Orderer.
Bước 4: Orderer tạo một block các giao dịch được sắp xếp và chỉ phân phối cho các Leader Peer của các tổ chức.
Bước 5: Mỗi Leader Peer phổ biến block nhận được cho các Peer khác trong cùng tổ chức thông qua giao thức Gossip.
Cơ chế phân phối block nói trên có thể giảm tải đáng kể cho Orderer. Mỗi tổ chức có thể định nghĩa tĩnh nút peer nào trở thành Leader Peer. Nếu không có peer nào được chỉ định tĩnh thì Hyperledger Fabric cũng có giải thuật lựa chọn động Leader Peer.
1.5.3.2. Khám phá dịch vụ (Service Discovery)
Để gọi một giao dịch thay đổi trạng thái của sổ cái, một ứng dụng client phải biết một tập các nút bảo chứng cần thiết để chứng thực đề xuất giao dịch. Từ phiên bản Fabric 1.2, dịch vụ khám phá được giới thiệu cho phép ứng dụng client khám phá cấu hình thành viên và bảo chứng, tất cả các nút peer đang hoạt động và các dịch vụ khả dụng khác. Dịch vụ khám phá cung cấp một API dưới dạng Fabric SDK để Client có thể gửi truy vấn các thông tin cần thiết (ví dụ, liệt kê tất cả các peer hoạt động trên một kênh) tới các nút peer thuộc cùng tổ chức. Các nút peer khi được truy vấn sẽ tính toán động các thông tin cần thiết và trả lời cho Client.
Để dịch vụ khám phá hoạt động hiệu quả, một loại nút peer đặc biệt gọi là Anchor Peer được cấu hình cho mỗi tổ chức [7].. Một trong những vai trò chính của Anchor Peer là phát hiện các nút peer. Cụ thể, tất cả các nút peer có thể truy vấn Anchor Peer trong cùng tổ chức để phát hiện động tất cả các Peer khác thuộc các tổ chức khác trên một kênh. Để ngăn chặn điểm lỗi đơn, một tổ chức có thể có nhiều Anchor Peer. Như được minh họa trong Hình 1 .15, Peer #2 của Org1 và Peer #2 của Org2 được cấu hình để làm Anchor Peer.
Hình 1.15 Khám phá các nút peer với hỗ trợ của Anchor Peer Lưu đồ từng bước khám phá peeer với sự hỗ trợ của Anchor Peer như sau:
Bước 1: Các Peer thông thường định kỳ đồng bộ hóa với các Anchor Peer cùng tổ chức thông qua giao thức gossip.
Bước 2: Anchor Peer của Org1 định kỳ cập nhật danh sách các peer đang hoạt động của mình gửi cho Anchor Peer của Org2 bằng giao thức gossip.
Bước 3: Anchor Peer của Org2 cũng định kỳ cập nhật danh sách các peer đang hoạt động của mình gửi cho Anchor Peer của Org1 bằng giao thức gossip.
Bước 4: Khi Client cần biết danh sách tất cả các peer đang hoạt động trên kênh, nó thực hiện yêu cầu truy vấn dùng Fabric SDK và gửi yêu cầu đến một trong số các nút Peer cùng tổ chức.
Bước 5: Nút Peer được truy vấn hồi đáp cho Client danh sách các peer đang hoạt động.
1.5.3.3. Dịch vụ vận hành (Operations Service)
Từ version 1.4, Hyperledger Fabric tập trung tăng cường độ ổn định và vận hành cho môi trường production. Dịch vụ vận hành là một trong những cập nhật chính. Dịch vụ này giúp cho người vận hành hệ thống xác định tình trạng hoạt động và “sức khỏe” của các nút Orderer, Peer và Fabric CA. Nó cũng giúp hiểu rõ hơn năng lực phục vụ của hệ thống Fabric theo thời gian.
Mỗi nút (bao gồm Orderer, Peer và Fabric CA) cung cấp dịch vụ vận hành qua HTTP RESTful API. Để hạn chế các thông tin nhạy cảm, API này được cách ly với các dịch vụ blockchain và chỉ được sử dụng để vận hành giám sát tình trạng của các thành phần hệ thống Fabric.