Chương 1. TỔNG QUAN VỀ BLOCKCHAIN VÀ NỀN TẢNG
1.5. NỀN TẢNG BLOCKCHAIN HYPERLEDGER FABRIC
1.5.1. Giới thiệu về Hyperledger Fabric
Hyperledger là một dự án mã nguồn mở, cung cấp một hệ sinh thái các giải pháp và người dùng trên nền tảng công nghệ blockchain thuộc tổ chức Linux Foundation. Mục đích của Linux Foundation là tạo ra một cộng đồng các nhà phát
triển làm việc trên các dự án nguồn mở, nhằm duy trì sự phát triển của các dự án, trong đó, mã nguồn dự án luôn được nâng cấp, sửa đổi và phân phối lại.
Hình 1.5 Thành phần và kiến trúc của Hyperledger Fabric
Hyperledger Fabric là kiểu blockchain cần được cấp quyền (permissioned).
Các thành viên tham gia mạng Hyperledger Fabric phải đăng ký qua một nhà cung cấp dịch vụ thành viên (MSP - Membership Service Provider). Hyperledger Fabric cũng cung cấp các tùy chọn plugable. Dữ liệu sổ cái có thể được lưu ở nhiều định dạng, các cơ chế đồng thuận có thể được hoán đổi, và các MSP khác nhau được hỗ trợ.
Hyperledger Fabric cung cấp khả năng tạo kênh, cho phép một nhóm người tham gia kênh tạo một sổ cái giao dịch riêng biệt và chỉ những người này mới có bản sao của sổ cái cho kênh đó [1].
Sổ cái chia sẻ: Hyperledger Fabric có phân hệ sổ cái bao gồm hai phần:
world-state và log giao dịch. Phần world-state mô tả trạng thái của sổ cái tại thời điểm hiện hành, nó chính là database của sổ cái và lưu trữ các bản ghi dưới dạng key-value (hiện tại cho phép tùy chọn dùng LevelDB hoặc CouchDB). Phần log giao dịch ghi lại tất cả các giao dịch đưa đến giá trị hiện tại của world-state. Log giao dịch chỉ đơn giản là ghi lại các giá trị trước và sau của database sổ cái, nó chính là chuỗi các block đang được sử dụng bởi kênh.
Hợp đồng thông minh (Smart contracts): được viết thành chaincode và được một ứng dụng bên ngoài blockchain gọi ra khi ứng dụng đó cần tương tác với sổ cái [1].. Trong hầu hết các trường hợp, chaincode chỉ tương tác với thành phần world-state database của sổ cái chứ không phải nhật ký giao dịch. Chaincode có thể được xây dựng bằng một số ngôn ngữ khác nhau như Go, Java, Node
Quyền riêng tư: Đối với các mạng public, quyền riêng tư sẽ không phải là mối quan tâm hàng đầu. Tuy nhiên tùy thuộc vào nhu cầu sử dụng mạng, những người tham gia mạng giữa các doanh nghiệp (B2B - Bussiness to Business) có thể cực kỳ nhạy cảm về lượng thông tin họ chia sẻ. Hyperledger Fabric đảm bảo quyền riêng tư bằng cách sử dụng các kênh là một yêu cầu bắt buộc. Bằng cách này, Hyperledger Fabric nhắm vào phân khúc đối tượng sử dụng là các tổ chức, doanh nghiệp.
Giao thức đồng thuận: Một trong những điểm khác biệt cực kỳ quan trọng của Fabric đó là hỗ trợ nhiều giao thức đồng thuận có thể lựa chọn [1].. Ví dụ, trong một số trường hợp cụ thể, giao thức đồng thuận chịu lỗi Byzantine (BTF - Byzantine Fault Tolerant) có thể là không cần thiết do nó tốn tài nguyên và băng thông, khi đó giao thức đồng thuận chịu lỗi sự cố (CFT - Crash Fault Tolerant) là quá đủ cho những trường hợp này. Giao thức đồng thuận CFT có thể giúp hệ thống vẫn đạt được sự đồng thuận một cách chính xác cho dù các thành phần khác có thể bị sự cố [8]..
1.5.2. Cơ chế hoạt động của Hyperledger Fabric 1.5.2.1. Cấu trúc mạng Hyperledger Fabric
Trong Hyperledger Fabric, các tổ chức tham gia và liên lạc với nhau thông qua channel (kênh). Kênh có thể được coi là một đường hầm để liên lạc bảo mật. Bất kỳ ai khác không tham gia vào kênh sẽ không có quyền truy cập vào các giao dịch hoặc thông tin liên quan của kênh đó [7].. Một tổ chức có thể tham gia vào nhiều kênh đồng thời.
Hình 1.6 Mạng Fabric đơn giản với 2 tổ chức
Hình 1 .6 mô tả một mạng Fabric đơn giản với hai tổ chức Org1 và Org2 tham gia vào kênh A (Channel A), các phần tử bao gồm Peer, Orderer, CA và Client có vai trò như sau:
Peer: là một nút blockchain lưu chứa tất cả các giao dịch trên một kênh nó tham gia. Mỗi nút peer có thể tham gia một hoặc nhiều kênh nếu cần, tuy nhiên việc lưu trữ thông tin của các kênh là độc lập nhau. Do đó, một tổ chức có thể yên tâm
rằng các thông tin được chia sẻ chỉ bao gồm nội bộ các bên tham gia trên kênh đó mà thôi.
Orderer: là một trong những thành phần quan trọng nhất được sử dụng trong cơ chế đồng thuận của Fabric. Orderer chịu trách nhiệm sắp xếp các giao dịch, tạo ra block mới chứa các giao dịch và phân phối block đến tất cả các nút Peer trên kênh.
CA: là nhà cung cấp chứng chỉ thực hiện quản lý các chứng chỉ số của người dùng như đăng ký người dùng, ghi danh người dùng, thu hồi người dùng v.v.
Hyperledger Fabric là một mạng blockchain có cấp phép (permissioned), có nghĩa là chỉ những người dùng được phép mới có thể query (truy vấn thông tin) hoặc invoke (tạo giao dịch mới) trên kênh được cấp quyền. Hyperledger Fabric sử dụng chứng chỉ theo chuẩn X.509 để thể hiện các quyền, vai trò và thuộc tính cho mỗi người dùng. Nói cách khác, người dùng có thể truy vấn hoặc gọi giao dịch nào trên kênh nào phải dựa trên quyền, vai trò và thuộc tính mà họ sở hữu.
Client: được xem như một ứng dụng tương tác với mạng blockchain Fabric.
Nghĩa là Client có thể tương tác với mạng Fabric theo các quyền, vai trò và thuộc tính của nó theo như được chỉ định trên chứng chỉ được lấy từ máy chủ CA của tổ chức.
Hình 1.7 Phân biệt nút bảo chứng (endorsing peer) và nút cam kết (commiting peer)
Trong Fabric, khái niệm smart-contract được gọi là chaincode. Để triển khai một chaincode, quản trị mạng phải cài đặt chaincode lên một nút peer đích và gọi lệnh để một Orderer khởi tạo chaincode đó trên kênh [1].. Khi khởi tạo chaincode, người quản trị phải định nghĩa một chính sách bảo chứng (endorsement policy) cho chaincode đó. Chính sách bảo chứng sẽ định nghĩa những nút peer nào cần phải tham gia chứng nhận kết quả của giao dịch. Các nút Peer được định nghĩa trong chính sách bảo chứng được gọi là nút bảo chứng (endorsing peer hoặc endorser), nó có cài đặt chaincode và chứa một sổ cái cục bộ. Còn các nút cam kết (commiting peer) chỉ chứa sổ cái cục bộ và không nhất thiết phải cài chaincode. Hình 1 .7 phân biệt giữa nút bảo chứng và nút cam kết.
Hình 1.8 Các thành phần bên trong sổ cái của một nút peer
Hình 1 .8 là các thành phần bên trong sổ cái của một nút Peer bao gồm blockchain và World State. Blockchain lưu giữ lịch sử của tất cả các giao dịch cho mọi chaincode trên một kênh cụ thể. World State duy trì trạng thái hiện tại của các biến đối với từng mã lệnh cụ thể. Hai loại cơ sở dữ liệu được hỗ trợ trong Fabric bao gồm LevelDB và CouchDB. LevelDB là cơ sở dữ liệu khóa-giá trị mặc định được xây dựng trên Fabric Peer, trong khi CouchDB là cơ sở dữ liệu dựa trên JSON hỗ trợ các hoạt động truy vấn phong phú dựa trên các đối tượng JSON. Nhà phát triển chaincode phải chọn sử dụng LevelDB hoặc CouchDB khi phát triển chaincode.
Hình 1 .9 là sơ đồ mạng Fabric thể hiện thêm chaincode và sổ cái. Các nút Peer của Org1 và Org2 cùng tham gia vào một kênh. Nhiều chaincode khác nhau có thể cùng được khởi tạo trên một kênh. Chaincode cũng có thể được cập nhật được nếu cần nâng cấp hoặc vá lỗi.
Chúng ta chú ý đến nút Orderer. Orderer được cài các system chaincode và sổ cái system đặc biệt. Các chaincode hệ thống thu thập cấu hình mạng, kênh và cấu hình hệ thống bên dưới để vận hành máy ảo Fabric; chúng khác biệt với các chaincode người dùng (user chaincode) chạy trong các docker container riêng biệt.
Trên thực tế, các system chaincode cũng được đăng ký và triển khai trên các nút
peer lúc khởi động, nhưng để đơn giản ta không vẽ trong hình. Một số system chaincode trong Hyperledger Fabric như sau:
• QSCC (Query System Chaincode): dành cho các truy vấn liên quan đến sổ cái và Fabric.
• CSCC (Configuration System Chaincode): giúp điều phối kiểm soát truy cập.
• LSCC (Lifecycle System Chaincode): định nghĩa các quy tắc đối với kênh
• ESCC (Endorsement System Chaincode): dùng để bảo chứng các giao dịch.
VSCC (Validation System Chaincode): để kiểm tra hợp lệ các giao dịch.
Hình 1.9 Mạng Fabric với các chaincode và sổ cái
Hình 1 .10 là một mạng Fabric phức tạp hơn với nhiều kênh. Kênh A gồm các Peer của các tổ chức Org1 và Org2 tham gia, trong khi kênh B gồm các Peer của Org2 và Org3. Với mỗi kênh riêng biệt, các tổ chức tham gia cùng kênh có thể chia sẻ các giao dịch hoặc thông tin với nhau một cách bí mật.
Hình 1.10 Một mạng Hyperledger Fabric phức tạp với nhiều kênh Một chaincode có thể gọi một chaincode khác trên cùng kênh. Ngoài ra, một chancode cũng có thể gọi hàm của một chaincode khác trên của kênh khác trong trường hợp chaincode gọi được thực thi trên cùng một nút bảo chứng (endorsing peer) tham gia vào cả 2 kênh liên quan (ví dụ nút peer của Org2 trên Hình 1 .10).
1.5.2.2. Sự đồng thuận trong mạng Hyperledger Fabric
Hyperledger Fabric sử dụng sự đồng thuận dựa trên biểu quyết cấp quyền với giả định rằng tất cả các bên tham gia trong mạng đều được tin tưởng một phần. Tiến trình đồng thuận có thể được chia thành ba pha [7]. như sau:
Pha 1: Bảo chứng (Endorsement): Bước 1-3 trong Hình 1 .11 Pha 2: Sắp xếp (Ordering): Bước 4-5.
Pha 3: Kiểm tra hợp lệ (Validation) và Cam kết (Commitment): Bước 6.
Hình 1.11 Lưu đồ thực hiện một giao dịch trong mạng Hyperledger Fabric Như trong Hình 1 .11 mô tả lưu đồ các bước của một lệnh gọi giao dịch Fabric:
Bước 1: Client tạo ra một đề xuất giao dịch (transaction proposal), ký số vào đề xuất bằng chứng chỉ của User và gửi đề xuất giao dịch đến các nút bảo chứng (endorsing peer) trên một kênh cụ thể.
Bước 2: Mỗi nút bảo chứng sẽ kiểm tra danh tính và quyền hạn của User trên payload của đề xuất giao dịch. Nếu hợp lệ, nút bảo chứng sẽ mô phỏng giao dịch (transaction simulation), tạo ra một phản hồi đề xuất (endorsed proposal response) gồm một tập read-write và ký chứng nhận phản hồi đó.
Bước 3: Client nhận về các phản hồi đề xuất được chứng thực từ các nút bảo chứng và kiểm tra.
Bước 4: Client gửi một giao dịch (transaction submission) được đính kèm đề xuất và các phản hồi đề xuất đã được bảo chứng cho Orderer.
Bước 5: Orderer xếp đặt các giao dịch nhận được, tạo ra một block mới chứa các giao dịch mới đã được sắp xếp và ký vào block bằng chứng chỉ của nó.
Bước 6: Orderer quảng bá block được tạo cho tất cả các nút Peer (cả nút bảo chứng và nút cam kết) trên kênh liên quan. Mỗi nút Peer phải đảm bảo rằng mỗi giao dịch trong block đã có đủ chữ ký của các nút bảo chứng cần thiết (cụ thể, được xác định từ chính sách bảo chứng của chaincode được gọi). Sau đó, nó kiểm tra phiên bản (multi-version concurrency control - MVCC) để xác định tính chính xác của từng giao dịch trong block nhận được. Tức là mỗi nút Peer sẽ so sánh read-set của mỗi giao dịch với trạng thái dữ liệu hiện hành trong sổ cái của nó (world- state). Nếu qua được việc kiểm tra, giao dịch sẽ được đánh dấu là hợp lệ và world- state của mỗi nút Peer sẽ được cập nhật. Ngược lại, giao dịch sẽ bị đánh dấu là không hợp lệ và không cập nhật trạng thái dữ liệu hiện hành. Cuối cùng, block này sẽ được thêm vào blockchain cục bộ của mỗi nút Peer, bất chấp giao dịch trong block có thể hợp lệ hoặc không.
Bước 7: Client sẽ nhận bất cứ các sự kiện đã đăng ký từ service EventHub.
1.5.2.3. Dịch vụ sắp xếp (ordering service) trong Hyperleger Fabric
Nút Orderer là một trong những thành phần quan trọng nhất trong Hyperledger Fabric. Nó hoạt động như một trung tâm phân phối các block giao dịch cho tất cả các nút peer trên một kênh liên quan. Vì vậy có thể xem như Orderer là điểm yếu nhất trong mạng Hyper Fabric. Có ba cách xây dựng dịch vụ sắp xếp là Solo, Kafka và Raft [8]..
Hình 1.12 Dịch vụ sắp xếp trong Hyperledger Fabric
Raft (từ phiên bản 1.4.1) - Raft là một dịch vụ sắp xếp chịu lỗi va chạm (CFT) dựa trên việc triển khai giao thức Raft, việc triển khai Raft rất phù hợp để được sử dụng như một nút duy nhất cho cả phát triển và được mở rộng cho nhiều nút trong môi trường production.
Kafka (hiện không dùng cho phiên bản 2.x) thường được sử dụng trong môi trường production. Với Kafka, chúng ta có thể thiết lập một cluster Kafka và một nhóm ZooKeeper để cung cấp dịch vụ sắp xếp có khả năng chịu lỗi sự cố CTF.
Mặc dù Kafka có thể cung cấp khả năng đồng thuận chịu lỗi sự cố CFT cho Orderer, tuy nhiên chỉ có một tổ chức kiểm soát toàn bộ dịch vụ sắp xếp (tổ chức sáng lập ra mạng). Việc này có thể là vấn đề vì tổ chức đó có thể không được tin cậy.
Solo (hiện không dùng cho phiên bản 2.x) được khuyến nghị chỉ sử dụng trong môi trường phát triển vì loại dịch vụ này chỉ là một tiến trình đơn phục vụ tất cả các client; đây sẽ là điểm lỗi đơn nếu dùng trong môi trường triển khai.
1.5.2.4. Hyperledger Fabric trong môi trường production
Trong môi trường production, có nhiều thành phần liên quan cộng tác với nhau. Hình 1 .13 tóm tắt mô hình triển khai mạng Fabric trong môi trường production [7].. Ứng dụng Client có thể tương tác với mạng blockchain Fabric bằng 2 cách: qua Fabric SDK (bộ công cụ phát triển phần mềm) hoặc Fabric CLI (giao diện dòng lệnh).
Fabric SDK cung cấp một tập chức năng phong phú thích hợp để dùng trong môi trường production. Thông thường, ứng dụng client (Client#1 trong hình) tương tác với mạng Fabric bằng cách kết nối đến một server RESTful API sử dụng Fabric SDK làm thư viện để giao tiếp với mạng blockchain. Fabric SDK hiện hỗ trợ các ngôn ngữ Go, Node.js và Java. Ngoài ra, các phiên bản Python và REST SDK cũng đang được phát triển. Fabric CLI thích hợp để sử dụng trong chế độ phát triển hoặc bảo trì (Client#2 trong Hình 1 .13).
Trong Fabric, CA thực hiện các tác vụ cấp chứng chỉ và quản lý người dùng. Có hai cách để triển khai Fabric CA. Cách thứ nhất là thiết lập Fabric CA mà không có mở rộng LDAP Server. Với cấu hình này, Fabric CA sẽ được sử dụng để đăng ký user, xác thực user và cấp chứng chỉ cho user (user enrollment). Cách thứ hai là thiết lập Fabric CA với mở rộng LDAP Server. Với cấu hình này, Fabric CA sẽ chỉ dùng để cấp chứng chỉ user và ủy quyền cho LDAP Server quản lý các tác vụ đăng ký, xác thực user, thu hồi user v.v. Cách thứ hai phù hợp để kết nối Fabric CA với máy chủ AD, LDAP hoặc Radius hiện có của tổ chức.
Hình 1.13 Mạng Hyperledger Fabric môi trường production
LevelDB và CouchDB đều có thể dùng để chạy database chứa world- state cho sổ cái của nút peer. Tuy nhiên CouchDB là tùy chọn tốt hơn cho môi trường production vì nó hỗ trợ nhiều tính năng như truy vấn JSON, lập chỉ mục (index), nhân bản dữ liệu, thuộc tính ACID v.v. Trong khi đó, LevelDB chỉ hỗ trợ một số tính năng hạn chế.
Để hỗ trợ đồng thuận CTF cho dịch vụ sắp xếp của Hyperledger Fabric, trong môi trường production thường mở rộng Orderer bằng một cluster Kafka- broker. Để cluster Kafka hoạt động đúng, cần thiết có một cluster ZooKeeper để phối hợp các tác vụ cục bộ giữa các Kafka-broker.