Hành 3.1: Tổng quan mô hình dé xuất
7. Tiếp tục quay lại bước 2
3.2.5. Cấu trúc mây dựng mang Hyperledger Fabric
Trong phan này, đối với mạng lưới Hyperledger Fabric, chúng tôi giới thiệu
sơ đồ mạng được thiết kế dựa được thể hiện trong Hình 3.7.
Hình 3.7: Cau trúc tổng quan của mạng lưới Hyperledger Fabric.
Dầu tiên chúng tôi sẽ tìm hiểu về các cơ sở hạ tầng được thiết kế trong sơ
đồ. O ây ta có ba tổ chức R1, R2, và R4 cùng đứng ra để thành lập mạng lưới
Hyperledger Fabric. Các CAI, CA2, CA4 chính là các co quan cấp chứng chỉ (Certificate Authority) được sử dung để cấp chứng chỉ cho các quản trị viên, người dùng trong mạng lưới và các nút mạng. Đối với mạng Blockchain, chứng chỉ dùng để xác thực lẫn nhau từ một tổ chức cu thé. Do đó ta có nhiều hơn một CA phục vụ cho hệ thống mạng Blockchain của chúng ta, nom na mỗi tổ chức khác nhau sẽ sử dụng một CA khác nhau. CA để cấp chứng chỉ cho các quản trị viên của một tổ chức sẽ có dạng trong Hình 3.8.
Tiếp đến ta sẽ có quá trình khởi tạo kênh Cl, kênh là phương thức liên lạc chính, cách những thành viên của hiệp hội giao tiếp lan nhau. Một mạng sẽ có
nhiều kênh, đồng nghĩa với việc sẽ có nhiều kênh giao tiếp độc lập giữa các tổ
chức với nhau. Việc này được định nghĩa dựa trên Channel Configuration (CC),
ở day CC1 được sinh ra và quan trị bởi tổ chức R1 và R2, các kênh khác không liên quan sẽ không thể tham gia hoặc giao tiếp trực tiếp vào C1. Kênh C1 cung
Subject Name
Issuer Name
Issued Certificate
Version: 3
SerialNumber: 21.7 43
C3 98 C8 Not Valid Before: — 2022-06-19
caorg1.example.com-cert.pem
€(Countn): us
ST (State): North Carolina
L (Locality): Durham
‘O (Organization): orgt.example.com
CN (Common Name): ca.org1.example.com.
c (Country): us
ST (tate): North Carolina
L (Locality): Durham
‘O (Organization): orgt.example.com
CN (Common Name): ca.org1.example.com.
AB F2 11 92 80 92 34 FL
31 58 C8 41 40 93
Hình 3.8: Dinh dạng CA của một tổ chức.
cấp một phương thức liên lạc bí mat cho R1 và R2, dù cho ƠI là một phan của
hệ thống nhưng nó hoạt động độc lập. Kênh này chi để xử lí giao dịch giữa R1
và R2. CCI có những chính sách để kiểm soát quyền R1 và R2 có trên kênh Cl, tức là R3 và R4 chỉ có thể tương tác với RI nếu được R1 và R2 thêm vào chính
sách của cấu hình kênh CCl. Day chin! h là ưu điểm vượt trội của Hyperledger Fabric. Các tổ chức có thể đồng thời chia sẽ và giữ bí mật thông tin của nhau. Day chính là mau chốt khi chúng tôi thiết kế mạng lưới, do các R1, R2, R4 là các thành phần cùng đóng góp để huấn
hạn chế sự xuất hiện của các mô hình
uyện dữ liệu, tính chất này sẽ phần nào
ộc hại trong hệ thống.
Co một thành phan O4 được định nghĩa trong mạng lưới, đó chính là Ordering
Service. Hiểu nôm na thì Ordering Service là nơi mà các transaction đi qua và
được xử lý tuần tự trước khi được cập nhật và lưu vào số cái. Vì vậy nên Order- ing Service là dich vụ phải được triển khai đồng thời khi mạng lưới được sinh
ra. O đây cơ chế Orderer mà chúng tôi sử dụng là Raft.
Raft là một dich vụ sắp xếp (ordering service) có khả năng chồng lỗi (CFT).
Raft tuân theo mô hình một nút "leader" và các nút "followers", trong đó
"leader" được chọn (trên mỗi kênh) và các quyết định của nó sẽ được phát đến tất cả các "followers". Dich vụ sắp xếp Raft dé dàng thiết lập và quản lý hơn
44
peer0.org2
peert.orgt peer1.org2
Hình 3.9: Cáu trúc của Raft Orderer.
dịch vụ sắp xếp Kafka, và thiết kế của nó cho phép các tổ chức đóng góp các nút cho việc sắp xếp.
Giờ ta đã có kênh để kết nối các thành phần trong mạng lại với nhau, tiếp đến chính là giai đoạn triển khai Peers và Số cái (Ledger).
Ỏ đây L1 của mạng lưới sẽ là nơi lưu trữ trạng thái của các đối tượng, có thể là
trạng thái của một giao dịch tại một thời điểm cụ thể.
{key=Model1, value = {nodeld:'Org1', globalModel:'path/of/global/in/ipfs', benignModels:'path/of/benign/models/in/ipfs', timeStamp='1519211809934'}}
{key=Model2, value = {nodeld:'Org2', globalModel:'path/of/global/in/ipfs',
benignModels:'path/of/benign/models/in/ipfs', timeStamp =
1519211810362}
Hình 3.10: Trang thái của mot Ledger.
45
Peer là thành phần mạng lưu trữ bản sao số cái, có thể hiểu đơn giản chúng
là nơi lưu một bản sao của số cái L1 cho những người khác truy cập. Điểm quan trong của cấu hình PI là xác thực danh tính từ CA1, thứ sẽ kết nối P1 với tổ
chức R1. Ở đây các quyền thao tác của P1 sẽ được quy định trong chính sách
của CCI.
Chaincode S5 cung cấp một tập định nghĩa các cách truy vấn hay cập nhật số cái L1. S5 sẽ hỗ trợ các tập truy vấn, khi client thông qua Al gọi đến S5 để đọc
và ghi dữ liệu lên ledger, ta nói họ đã thực hiện một transaction. Ví dụ, ta có
một ledger lưu các trạng thái của các hãng xe, chaincode ở đây sẽ chứa tập các
ham truy vấn để thao tac trên ledger:
Chaincode Structure
Hình 3.11: Trang thái của một Chaincode.
Ỏ giai đoạn phát triển tiếp theo, các ứng dụng Al và A2 sử dụng kênh Cl
để thao tác với các tài nguyên trong mạng. Cũng như nút peer và node sắp xếp, một ứng dụng client sẽ có một danh tính kết nối tới tổ chức mình. Trong sở đồ trên, ứng dụng A1 được kết nối với tổ chức R1; và dù hoạt động ngoài hệ thống
mang, ứng dụng vẫn kết nối tới được hệ thống thông qua kênh Cl. Ở đây, Al
sẽ đóng vai trò là nơi đọc và truy xuất đến các hàm tại chaincode.
46
Điểm lưu ý ở đây là Al không trực tiếp thao tác và xem dữ liệu của L1, để thực hiện việc đó cần thông qua hợp đồng thông minh $5.
Đó chính là sơ bộ về cấu trúc mạng Hyperledger Fabric, chúng tôi dựa trên những kiến thức này để làm nền tảng phát triển mạng lưới về sau.
3.2.6. Luông hoạt động chi tiết của người dùng khi tham gia mang
Hyperledger Fabric
Dau tiên, người ding A muốn thực hiện một giao dịch đến người dùng B. Yêu cầu này được gửi đến peerA, peerB, là các peer của 2 tổ chức A, B đồng thời là nơi mà người dùng A và B lần lượt đăng ký. Tùy cấu hình mà mạng lưới triển khai, ở đây ta cần phải có chứng thực của cả 2 tổ chức A và B nên yêu cầu mới cần phải gửi đến cả 2 peer.
Client A SDK Proposal Peers
Hình 3.12: Người dùng A tạo một yêu cầu thông qua Client SDK.
Tiếp đến thông qua SDK (ở đây ta dùng bộ SDK này để phát triển thành ứng dụng ), Transaction Proposal sẽ được tạo dựa trên yêu cầu của client A. Proposal này có thể truy vấn đến một hoặc nhiều hàm được xây dựng ở Chaincode để tương tác với Ledger. Ngoài ra SDK cũng sẽ lấy thông tin của người dùng khi
tham gia vào mạng lưới được các CA cấp để tạo chữ ký cho giao dịch.
Các Endorsing Peers sau đó sẽ xác nhận rằng Transaction Proposal được tạo đúng chuẩn và chữ ký trên Transaction Proposal là hợp lệ. Tiếp đến, một
{("credenttals":{"certtficate”
XnRT1CgZCCAtagAwTBAg1UVHNCHUfw4983043Yse3NDKOr NxTwCgYTKoZEz6EAwTw\ncDELHAkGA1UE8hfCVVIXFZAVBgNVB,
'NQEAMTHQDAHBgNVHRMB\nAf8EAAAHB6GA1UdDgQMBBTCQ102v/4nxUnpZ / 'AVOEnyt]STDAFBGNVHSNEGDAW\ngBQAhxC3VKbt7w181MLDRoRXHo 1aZz84BggqAwQFBgcTAQReey2hdHRycyT6ey2o\nZt5 END CERTIFICATE---\n","privateKey":"---BEGIN PRIVATE KEY---
|\r\nlIIGHAGEAMBMGByqGSM49AgEGCCqGSM49AWEHBGOWaWIBAQQGC/~
CnkLkkj+HIOXO6V\r \nKYr sixb2MHOLv6tcxgz341207DGhRANCAASnXrRcL+RsqrEL3zr9EzsCOGTHFRP\r\n1011đ2ExDaH.
END PRIVATE KEV---\r\n"},"mspId":"OrgihsP", "type" :"x.509" ,"verston":1}
Hình 3.13: Certificate của một người dàng ma SDK sử dung để tao chit ky các
giao dich.
Transaction Value bao gồm chữ ký của peers, giá tri ma transaction thực thi trên ledger sao lưu tai peerA và peerB sẽ được gửi về client SDK dưới dang
response, đươc mô tả trong Hình 3.14.
_
= foo d
sage \— a’ @Mới
App Signed Proposal Signatures Peers
Response
Hình 3.14: Response từ Endorsement Peer sẽ được gửi vé client SDK để zác
thuc.
Sau khi nhận về Response, SDK sé đối chiếu lại và kiểm tra chữ ký của các Peers. Nếu response trả về cho thấy transaction yêu cầu cần cập nhật lại ledger, SDK sẽ một lần nữa kiểm tra chính sách của hệ thống xem cả peerA và peerB
có quyền thực hiện truy vấn đến hàm cập nhật Ledger tại Chaineode không.
———— —~ 6666
—— ooo — @®@®@®
= — 6666
SDK Channels Ordering Ordered
Service Transactions
Hình 3.15: SDK gửi Transaction đến Orderer Service.
48
Ordering Service không cần phải kiểm tra nội dung của giao dịch, nhiệm vụ của nó chỉ là nhận các giao dịch và sắp xếp chúng theo thứ tự thời gian. Các khối chứa các giao dịch sau đó sẽ được gửi tới tất cả các Peer trên Channel. Sau khi các giao dịch đã được xác minh là hợp lệ, mỗi Peer sẽ thêm khối vào chuỗi
và mỗi giao dịch hợp lệ sẽ được thêm vào Sổ cái (Ledger).
Ỏ đây với mạng lưới của chúng tôi, các transaction hợp lệ sẽ có cấu trúc như
Hình 3.16:
createModel Transaction:
Identifier: model
queryGlobalModel Transaction:
Identifier: model
Proposal + input: { ModelX) + Signature: input *
(ORG1 OR ORG2)
Proposal:
+ input: (modelNo, nodeld, globalModel,
trainModelPath, datasize, timeStamp}
+ Signature: input *
(ORG1 OR ORG2)
Response
queryBenignModels Transaction
Identifier: model Response:
+ Oupur[ Proposal
+ Output: {
New Model is added to block!
Return {(ModelX globalModel)}
}
+ input: ( ModelX)
+ Signature: input *
(ORG1 OR ORG2)
Sonsluứ + Signature
ine output signed by ORG
output signed by ORG output signed by ORG2 ky sen
output signed by ORG2 Output ¢
Return {(ModelX.trainModelPath)}
3
+ Signature:
output signed by ORG1 output signed by ORG2
8m ‘Transaction: A changeBenignModelPath Transaction:
Identifier: model Identifier: model
Proposal Proposal
+ input: {ModelX) + input: {[Arrayiofibenignlmodel/hashes], ModelX)
+ Signature: input *
(ORG1 OR ORG2)
Response:
+ Output: (
‘ModeIX.benignModels = [Array/offbenign/model/hashos])
}
+ Signature output signed by ORG1
‘output signed by ORG2
+ Signature: input *
(ORG1 OR ORG2)
Response.
+ Output: {
Return ((ModelX datasize))
}
+ Signature:
output signed by ORG1
output signed by ORG2
Hình 3.16: Hình thể hiện cấu trúc của các transaction trong hệ thống.
Hình 3.16 thể hiện cấu trúc các giao dịch được định nghĩa trong chaincode.
O mỗi transaction sẽ bao gồm identifier - tên của giao dịch, đầu vào là các tham
số yêu cầu của chaincode đã được định nghĩa sẵn để truy cập vào so cái. Dầu vào sẽ luôn được ký bởi tổ chức đề nghị thực hiện giao dịch. Dầu ra của giao dịch sẽ là kết quả cập nhật của các trường trong model được chỉ định với các giá trị đã được truyền vào trong giao dịch trước đó. Dầu ra sẽ được ký bởi các
49
tổ chức tham gia mạng để xác thực rằng các thành viên trong mạng đều đồng
thuận về chỉ tiết giao dịch.
Ỏ đây chúng tôi sẽ liệt kê 5 tác vụ chính trong chaineode khi tương tác với hệ
thống, bao gồm:
e createModel: Dùng để khởi tạo một khối mô hình toàn cục mới trong SỐ cái
để người dùng có thể sử dụng để huấn luyện ra mô hình toàn cục tiếp theo.
e queryGlobalModel: Truy van đến chuỗi giá trị băm của mô hình toàn cục được lưu trữ trên IPFS.
e queryBenignModels: Truy vấn đến mảng chứa các dãy giá trị băm của các
mô hình mà người dùng cập nhật lên hệ thống.
e queryDatasize: Truy vấn đến mảng các day giá trị băm chứa datasize của từng mô hình mà người dùng cập nhật lên hệ thống.
e changeBenignModelPath: Cập nhật lên hệ thống mảng các dãy giá trị băm
chứa các mô hình lành tính dùng để tổng hợp ra mô hình toàn cục cho vòng huấn luyện tiếp theo.
3.2.7. Luéng hoạt động của mô hành blockchain - Hyperledger Fab-
ric kết hợp vdi m6 hành học liên kết - Federated Learning
Luông hoạt động của người dùng tương tác với mô hình blockchain - Hyper- ledger Fabrie kết hợp với mô hình học máy - Federated Learning sẽ được chúng tôi mô tả chỉ tiết ở Hình 3.17.
Đăng ký thành viên trong hệ thống
Để tham gia vào hệ sinh thái, thong qua ứng dung (client SDK), người dùng cần phải đăng ký định danh không chỉ để thực hiện các chức năng trong mạng
lưới mà còn để hệ thống quản lý các hành vi của người dùng. Sau khi đăng ký,
50
a ©
Register Userằ
~~ ~—Retum Cert and Private Key
Request Global Model Query Init Model
Return Init Model
Application qeades pue j2p0/1 30 3D0I4 J2u00UE ppY
Hình 3.17: Luong hoạt động của mang lưới FabricX Federated.
người dùng sé được cung cấp một chứng chi chứa khóa private để tao chữ ký khi thực hiện yêu cau tao một transaction.
'Yêu cầu Init Model từ hệ thống để thực hiện huấn luyện
Sau khi xác thực người dùng, người dùng sẽ yêu cầu nhận Init Model thông qua ứng dụng từ hệ thống để bắt đầu huấn luyện, ứng dụng sẽ tạo một trans- action thông qua chaincode để truy xuất đến Ledger.
Gửi kết quả huấn luyện lên máy chủ
Sau khi hoàn tất quá trình huấn luyện, kết quả sẽ được gửi lên hệ thống. Đồng thời, mô hình sẽ được lưu trữ trong hệ thống lưu trữ phân tan IPFS, và hành vi đóng góp cũng sẽ được hệ thống ghi lại trên Blockchain.
Tổng hợp mô hình
Sau một round người dùng tổng hợp model và upload lên hệ thống, chaincode
sẽ thực hiện tổng hợp các benign model bằng thuật toán tính trung bình cộng
Federated Averaging (FedAvg), từ đó cho ra trạng thái mới của mô hình học
51
máy toàn cục ở round tiếp theo để tiếp tục quá trình huấn luyện phân tan như
trên.