Quartz 🪬

Search

SearchSearch

Hyperledger Fabric - Peer

Nov 21, 20246 min read

Fundamental Building Blocks

Peer là một node thuộc về một tổ chức nào đó và tham gia vào network. Peer là thành phần cơ bản của network bởi vì nó host ledger và chaincode. Nó là đầu mối để các tổ chức có thể giao dịch trong channel.

Peer còn được gọi là non-ordering node vì nó không thực hiện sắp xếp giao dịch như các orderer node1.

Ledgers and Chaincode

Trong hình minh họa bên dưới có 3 peer là P1, P2 và P3. Cả 3 peer này đều host ledger L1 và sử dụng chaincode S1 để tương tác với ledger:

Thực tế, có thể có nhiều instance của ledger và chaincode được host ở trên từng peer. Mỗi instance là một phiên bản của ledger và chaincode bởi vì hai thực thể này luôn được cập nhật.

Multiple Ledgers

Một peer có thể ở trong nhiều channel. Nói cách khác, nó có thể host nhiều ledger của nhiều channel khác nhau:

Multiple Chaincodes

Tương tự với ledger, một peer có thể host nhiều chaincode để tương tác với các ledger ở các channel khác nhau:

Fabric Gateway Service

Các peer còn được dùng để quản lý các transaction proposal và các endorsement (kết quả trả về từ các endorsing peer). Cụ thể hơn, nó cung cấp dịch vụ Fabric Gateway để các client application tương tác với các chaincode2.

Quá trình tương tác giữa client application và Fabric Gateway nhằm ghi dữ liệu lên ledger trải qua ba phase:

Phase 1 - Transaction Proposal and Endorsement

Phase 1 gồm các bước sau:

  1. Client application submit một transaction proposal đã được ký đến một peer chạy Fabric gateway service.
  2. Gateway service chọn một peer (P1) trong tổ chức mà được chỉ định bởi endorsement policy (ta gọi peer này là endorsing peer) để:
    1. Giả lập việc thực thi smart contract.
    2. Trả về endorsement (kết quả thực thi smart contract) bao gồm read-write set kèm chữ ký số của P1 (có payload là endorsement) cho gateway.
  3. Gateway lặp lại bước 2 đến khi nào thu đủ số lượng endorsement được quy định bởi endorsement policy rồi trả về transaction cho client application.

Phase 2 - Transaction Submission and Ordering

Gồm hai bước sau:

  1. Client application gửi transaction đã được ký cho gateway service. Gateway service chuyển tiếp transaction cho ordering service và trả về success message cho client application.
  2. Ordering service xác thực chữ ký số và sắp xếp giao dịch vào bên trong một block cùng với các transaction khác. Ordering service sau đó phân phối block đến tất cả các peer ở trong channel để xác thực và commit xuống ledger.

Note

Lưu ý: tất cả các peer không nhất thiết phải kết nối đến orderer bởi vì chúng có thể trao đổi thông tin về các block với nhau thông qua gossip protocol (mặc dù việc nhận các block thông qua orderer được khuyến khích hơn).

Phase 3 - Transaction Validation and Commitment

Gồm ba bước sau:

  1. Mỗi peer sẽ phải kiểm tra xem các transaction có được chứng thực bởi các endorsing peer đã được chỉ định hay chưa.
  2. Trước khi commit block xuống ledger, peer sẽ kiểm tra tính hợp lệ của read-write set. Cụ thể, nó sẽ kiểm tra xem trạng thái hiện tại của ledger có khác với lúc transaction proposal được đề xuất hay không. Việc kiểm tra này nhằm ngăn chặn các concurrency update.
  3. Sau khi commit, peer sẽ gửi lại cho client application một loạt các sự kiện (block event, block transaction event, chaincode event và commit event) cùng với bằng chứng cho biết ledger đã được cập nhật. Các application có thể theo dõi các sự kiện này3.

Info

Tất cả các transaction (kể cả các transaction không được commit) sẽ được lưu lại (trên blockchain của orderer và peer) để phục vụ cho việc audit. Các block ở các peer sẽ giống với các block được phân phối bởi orderer, chỉ khác ở chỗ mỗi block sẽ có thêm thông tin cho biết transaction nào đã được commit và transaction nào không được commit.

Trong hình trên, orderer O1 phân phối block B2 đến peer P1 và peer P2 để thêm vào ledger L1 của từng peer.

Note

Chú ý rằng phase 3 không thực thi chaincode và do đó chaincode thường chỉ khả dụng đối với các endorsing peer.

Peers and Organizations

Mỗi tổ chức tham gia vào channel thông qua một peer nào đó:

Trong hình trên, có tổng cộng 8 peer và 5 trong số đó (P1, P3, P5, P7 và P8) tham gia vào channel C. Các peer còn lại có thể tham gia vào các channel khác. Ngoài ra, các ứng dụng phát triển bởi các tổ chức kết nối đến gateway service của tổ chức đó.

Có thể thấy, blockchain network ở trên không phụ thuộc vào bất kỳ một tổ chức đơn lẻ nào mà được cấu thành bởi nhiều tổ chức khác nhau.

Peers and Identity

Các peer có các định danh là các X.509 Certificate được phát hành bởi một CA cụ thể nào đó. Mỗi peer trong tổ chức đều cần phải có một định danh được gán bởi admin của tổ chức đó. Các thực thể tương tác với network mà sử dụng định danh được gọi là “principal”.

Khi một peer kết nối vào channel, chứng chỉ số của nó giúp xác định tổ chức mà peer đó thuộc về thông qua một channel MSP.

Trong hình trên, P1 và P2 có các định danh được phát hành bởi CA1. Channel C có chính sách cho biết các định danh phát hành bởi CA1 sẽ tương ứng với Org1 thông qua ORG1.MSP. Một cách tương tự, P3 và P4 sẽ được xác định là thuộc về Org2 thông qua ORG2.MSP.

Bất cứ khi nào một peer kết nối vào channel, chính sách của channel sẽ sử dụng định danh của peer để xác định xem peer đó vai trò và quyền hạn gì. Việc quyết định xem một peer được gán cho một vai trò nào trong một tổ chức và được quyền truy cập vào tài nguyên nào của network là trách nhiệm của MSP.

Note

Lưu ý rằng một peer có thể nằm ở máy chủ của một tổ chức nhưng thuộc về tổ chức khác. Quyền sở hữu peer của tổ chức phụ thuộc vào việc định danh của peer đó được cấp phát bởi CA thuộc về MSP của tổ chức nào.

Trong hình minh họa trên, P3 có thể nằm ở server vật lý của tổ chức Org1 nhưng nếu định danh của nó được phát hành bởi CA2 của ORG.MSP2 thì nó sẽ thuộc về Org2.

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

Resources

Footnotes

  1. xem thêm Ordering service ↩

  2. xem thêm Running a Fabric Application ↩

  3. có thể thấy, các sự kiện này tương tự với Event ở trong ngôn ngữ Solidity. ↩

Backlinks