Có thể xem channel như là một permissioned blockchain network ở trong Fabric và ta có thể dùng khái niệm “network” để chỉ một channel.

Mỗi channel sẽ có một ledger riêng. Trong ledger này sẽ luôn có một block chứa các chính sách và ACL. Ngoài ra, channel còn chứa các MSP instance dùng để mapping các crypto material từ các CA với các thành viên ở trong channel.

Ledger và chaincode deploy ở trong channel chỉ có thể được sử dụng bởi các node tham gia vào channel đó.

Sample Network

Dưới đây là sơ đồ hoàn chỉnh của một network bao gồm 3 tổ chức R1, R2, và R0.

Các tính chất của network trên:

  • Ba tổ chức này cùng tham gia vào channel C1 và đồng thuận với cấu hình CC1 của channel. Cấu hình này bao gồm những chính sách về quyền hạn và vai trò của ba tổ chức. Trong C1, R1 và R2 sẽ tham gia dưới vai trò là các peer (P1 và P2). Trong khi đó, P0 sẽ tham gia dưới vai trò orderer (O) và chạy ordering service.
  • Tất cả các node trong channel đều có một bản sao của channel ledger và bản sao của ordering service sẽ không chứa state database.
  • R1 và R2 sẽ tương tác với channel thông qua ứng dụng A1 và A2.
  • Mỗi tổ chức sẽ có một CA tương ứng để tạo ra các chứng chỉ cần thiết (CA0, CA1 và CA2).

Dưới đây là quá trình tạo ra network trên:

Creating the Network

Bước đầu tiên để thiết lập một channel giữa các tổ chức là yêu cầu sự đồng thuận của các tổ chức về cấu hình của channel đó (CC1). Cấu hình này sẽ quy định các tổ chức được phép tham gia và tương tác với channel. Ngoài ra, nó còn bao gồm các chính sách giúp gán các quyền cụ thể cho các actor trong channel.

Cấu hình CC1 sau khi được đồng thuận sẽ được lưu ở trong một block của channel ledger và được gọi là “configuration block”. Cụ thể hơn, block này được tạo bởi tool configtxgen dựa trên file cấu hình configtx.yaml1.

Định danh của các node trong tổ chức sẽ được tạo ra bởi các CA tương ứng với từng tổ chức. Cụ thể hơn, các CA có nhiệm vụ phân chia các chứng chỉ X.509 (là một định dạng chứng chỉ khóa công khai)2 để định danh các thành phần của tổ chức (một tổ chức có thể có nhiều peer, ta xem mỗi peer là một thành phần). Việc mapping giữa các chứng chỉ với các thành phần của tổ chức sẽ được thực hiện bởi MSP.

Các chứng chỉ của các node sẽ được dùng để ký transaction khi thực hiên chứng thực (endorse). Cụ thể hơn, nó được dùng trong việc ký các transaction proposal của client application và các transaction response của smart contract3. Các node trong mạng sẽ cần phải xác thực chữ ký này trước khi commit transaction xuống ledger.

Join Nodes to the Channel

Ta cho peer P1 của R1, peer P2 của R2 và orderer O của R0 cùng tham gia vào channel:

Channel chỉ có thể có duy nhất một ordering service và có thể có nhiều node cùng chạy service này. Trong môi trường production, ordering service phải có ít nhất 3 node.

Mỗi node trong channel sẽ lưu một bản sao của ledger (L1) và ordering service chỉ lưu transaction log chứ không lưu world state4.

Install, Approve, and Commit a Chaincode

Các logic nghiệp vụ quy định cách các peer tương tác với ledger sẽ được khai báo ở trong chaincode. Chaincode trước tiên sẽ được cài đặt trên các peer rồi sau đó được định nghĩa và commit ở trên ledger.

Ở trong hình trên, chaincode S5 được cài đặt ở trên P1 và P2 nhưng O lại không có. Lý do là vì ordering service thường không propose transaction.

Phần quan trọng nhất của chaincode definition5 là endorsement policy. Chính sách này quy định tổ chức nào cần phải chứng thực transaction trước khi nó được commit xuống ledger của các peer. Nếu endorsement policy không được thiết lập, nó sẽ được kế thừa từ cấu hình mặc định của channel.

Using an Application on the Channel

Sau khi chaincode được commit xuống ledger, các client application có thể invoke các phương thức của chaincode để tương tác với channel ledger.

Tương tự với các peer và orderer, các client application cũng cần phải có định danh và phải thuộc về một tổ chức nào đó. Trong hình trên, A1 thuộc về R1 và A2 thuộc về R2.

Bắt đầu từ phiên bản 2.4x, client application sẽ tạo kết nối gRPC đến gateway service6 để nhờ xử lý các transaction proposal và thực hiện quá trình chứng thực thay cho ứng dụng. Transaction proposal sau đó sẽ đóng vai trò như là input của chaincode và output của chaincode sẽ là transaction response.

list
from [[Hyperledger Fabric - Channel]]
sort file.ctime asc

Resources

Footnotes

  1. xem thêm Hyperledger Fabric - Using the Test Network

  2. tham khảo thêm https://www.ssl.com/faqs/what-is-an-x-509-certificate và xem thêm X.509 Certificate

  3. xem thêm Transaction Flow

  4. xem thêm Ledger

  5. xem thêm Hyperledger Fabric - Deploying a Chaincode to a Channel

  6. xem thêm Fabric Gateway Service