Mô hình dữ liệu

44 Kiến trúc hệ thống đề xuất trong phần 3.1 được thiết kế theo hướng phân chia thành các dịch vụ nhỏ (microservices) và xây dựng các thành phần kết nối riêng (drivers). Cách thiết kế này đòi hỏi phải có một mô hình dữ liệu chung để các thành phần kết nối (drivers) có thể chuyển đổi các dữ liệu khác nhau, từ nhiều nguồn, dưới nhiều định dạng về một mô hình dữ liệu thống nhất trong toàn hệ thống. Một mô hình dữ liệu tốt sẽ phục vụ cho việc quản lý, cấu hình các thành phần trong mạng chuỗi khối và đặc biệt việc triển khai các giao thức đồng thuận trở nên dễ dàng hơn. Mô hình được sử dụng phải đảm bảo tính tổng quát, dễ dàng mở rộng. Hình 3.8 mô tả thiết kế mô hình dữ liệu mà tôi đề xuất. Mô hình bao gồm các thành phần chính như sau:

 BlockchainNetwork: đại diện cho các thông tin cơ bản của mạng chuỗi khối gồm các thuộc tính liên quan đến: tên của mạng chuỗi khối (Name), kiểu mạng chuỗi khối (BlockchainType), giao thức đồng thuận (Consensus), mô tả về mạng chuỗi khối (Description), cầu hình của các nút trong mạng (BlockchainPeerConfig)…

 NodeInfrastructure: đại diện cho hạ tầng mà các dịch vụ, thành phần trong mạng chuỗi khối được triển khai. Các hạ tầng đó có thể là các dịch vụ điện toán đám mây (cloud services), hệ thống tính toán mà người dùng tự xây dựng hoặc tài nguyên sẵn có của các mạng chuỗi khối công khai…

 BlockchainPeerConfig: cấu hình cho các nút trong mạng. Tuỳ vào nền tảng chuỗi khối triển khai mà thành phần này có thể được kế thừa và mở rộng theo yêu cầu.

 Consensus: đại diện cho giao thức đồng thuận được triển khai trong mạng. Một số thông tin cơ bản của giao thức đồng thuận gồm: Tên giao thức (Name), số nút lượng nút trong mạng (NumberValidators). Các giao thức đồng thuận khác nhau sẽ kế thừa các thuộc tính của thành phần Consensus và thêm các thuộc tính sao cho phù hợp với cách vận hành của giao thức. Ví dụ: giao thức đồng thuận PoET cần thêm những thông số cấu hình hasSGX, Spid, IASURL để có thể hoạt động.

 Logs: đại diện cho các bản ghi log của các thành phần trong mạng chuỗi khối giúp người dùng có thể theo dõi quá trình hoạt động, lỗi xuất hiện trong hệ thống một cách dễ dàng hơn.

45 Mô hình đề xuất đã đạt được các yêu cầu sau:

 Tính tổng quát (Generalization): mô hình dữ liệu đề xuất bao gồm những thành phần chung và thiết yếu nhất của một mạng chuỗi khối phục vụ cho việc triển khai tự động giao thức đồng thuận. Thực tế chỉ ra rằng một mạng chuỗi khối có thể có nhiều thành phần phức tạp khác như: cơ chế khuyến khích các nút trên mạng (incentive mechanism), cơ chế truyền thông, cơ chế xác minh giao dịch. Tuy nhiên, chúng không xuất hiện trong mô hình dữ liệu đề xuất do không có vai trò trong việc triển khai giao thức đồng thuận trong phạm vi đề tài. Từ đó, tôi đã rút gọn, khái quát hoá các thành phần quan trọng gồm: BlockchainNetwork, NodeInfrastructure, Log, Consensus, BlockchainPeerConfig để đưa vào mô hình dữ liệu đã trình bày ở trên.

 Tính mở rộng (Extensibility): để có thể triển khai nhiều giao thức đồng thuận trong môi trường chuỗi khối đòi hỏi mô hình phải có được tính mở rộng, có khả năng áp dụng khi một hệ thống chuỗi khối nói chung và giao thức đồng thuận mới nói riêng ra đời.Với việc mô hình dữ liệu đề xuất đã định nghĩa trước các thành phần và các thuộc tính thiết yếu, người dùng có thể sử dụng phương pháp kế thừa để xây dựng các thành phần con mới phù hợp với nền tảng chuỗi khối và giao thức đồng thuận như mong muốn. Cụ thể trên mô hình dữ liệu ta có thể thấy ba thành phần con PoW, PoET, PBFT kế thừa từ thành phần Consensus.

Ví dụ 1: Dữ liệu giao thức đồng thuận PBFT trên mạng Hyperledger Fabric

{

"Name": "fabric-testnet",

"BlockchainType ": "Hyperledger Fabric", "Consensus": { "Name": "PBFT", "NumberValidators": 4 }, "NodeInfrastructure": { "InfrasType": "internal", "NumberVMNodes": "2", "VMPlan": { "Cpu": 1, "Ram": 2, "Disk": 25 } }, "BlockchainPeerConfig": { "NumberPeer": 8, "NumberOrgs": 2, "StateDatabase": "couchDB", "NumberOrderers": 4, "ChannelName": "channel-test", "OrgConfig": [ { "OrgName": "hust", "NumberPeer": 4, }, { "OrgName": "neu" "NumberPeer": 4 } ] } }

Ví dụ 2: Dữ liệu giao thức đồng thuận PoET trên mạng Hyperledger Sawtooth

{

"Name": "sawtooth-testnet",

"BlockchainType ": "Hyperledger Sawtooth", "Consensus": { "Name": "POET", "NumberValidators": 4 }, "NodeInfrastructure": { "InfrasType": "internal", "NumberVMNodes": "2", "VMPlan": { "Cpu": 1, "Ram": 2, "Disk": 25 } }, "BlockchainPeerConfig": { "NumberPeer": 8, "NumberProcessorPerPeer": 2, "SeedPeer": "validator-0", "Peers": ["validator-0", "validator-1", "validator-2", "validator-3"], "MaxPeerConnectivity": "3", "MinPeerConnectivity": "1" } }

CHƯƠNG 4.THỬ NGHIỆM VÀ ĐÁNH GIÁ 4.1 Thiết kế hệ thống thử nghiệm

Dựa vào các mô hình dữ liệu, mô hình kiến trúc hệ thống đề xuất tại chương 3, tôi đã xây dựng một hệ thống thử nghiệm để minh chứng tính đúng đắn của các kết quả nghiên cứu đã trình bày. Môi trường thử nghiệm như sau:

 Địa điểm: Trung tâm Thông tin Lưu trữ và Thư viện tài nguyên môi trường quốc gia, Cục Công nghệ thông tin và Dữ liệu tài nguyên môi trường, Bộ Tài nguyên và Môi trường

 Máy chủ: 3 máy chủ với cấu hình mỗi máy gồm: Intel(R) Xeon(R) CPU Intel Xeon X5660, 16 GB RAM, 521 GB HDD

 Giữa các máy chủ kết nối mạng nội bộ Hệ thống sẽ thử nghiệm với:

 2 nền tảng chuỗi khối: Hyperledger Fabric và Hyperledger Sawtooth  3 giao thức đồng thuận: Practical Byzantine Fault Tolerance (PBFT), Proof

of Elapsed Time (PoET) và Raft

Hình 4.1 minh hoạ cho hệ thống được triển khai gồm có:

 Các driver cho từng giao thức đồng thuận chính là các bản thử nghiệm thành phần Consensus Drivers.

 Digital Ocean Controller là một bản thử nghiệm của thành phần Infrastructure Controller.

 NFS server và Driver Database là các thành phần lưu trữ dữ liệu quản lý cũng như dữ liệu dưới dạng file của các Consensus Driver.

 Management Service giúp quản lý các thành phần trong hệ thống.  Message Queue vẫn là phương thức chính để các thành phần trong hệ

thống giao tiếp với nhau.

 API được cung cấp cho người dùng tương tác với hệ thống thông qua giao thức HTTP/HTTPS hoặc người dùng có thể tương tác với hệ thống thông qua một giao diện trực quan được cung cấp bởi thành phần Front-end.

 Load Balancer giúp cân bằng tải giữa các bản sao (replica) của hệ thống, gán nhãn, điều hướng về các dịch vụ

49 Hệ thống thử nghiệm được triển khai trên các cụm máy sử dụng công nghệ Kubernetes. Điều này sẽ giúp việc quản lý các dịch vụ dễ dàng hơn, tăng tính mở rộng và chịu lỗi của hệ thống.

Hình 4.1 Kiến trúc hệ thống thử nghiệm

4.2 Thử nghiệm các chức năng chính của hệ thống

Với kiến trúc hệ thống thử nghiệm tại Hình 4.1, luận văn sẽ trình bày một số kịch bản kiểm thử tại bảng Bảng 4.1 nhằm kiểm tra các chức năng chính của hệ thống liên quan đến việc tạo, xoá các mạng chuỗi khối và giao thức đồng thuận tương ứng có hoạt động chính xác hay không.

Bảng 4.1 Kịch bản và kết quả thử nghiệm các chức năng chính của hệ thống

STT Kịch bản Kết quả mong muốn Kết quả thực tế

Triển khai mạng Hyperledger Fabric với giao thức đồng thuận PBFT

Mạng chuỗi khối và giao thức đồng thuận tương ứng được triển khai

Đạt

Triển khai mạng Hyperledger Fabric với giao thức đồng thuận RAFT

Mạng chuỗi khối và giao thức đồng thuận tương ứng được triển khai

Đạt

Triển khai mạng Hyperledger Sawtooth với giao thức đồng thuận PBFT

Mạng chuỗi khối và giao thức đồng thuận tương ứng được triển khai

Đạt

Triển khai mạng Hyperledger Sawtooth với giao thức đồng thuận PoET

Mạng chuỗi khối và giao thức đồng thuận tương ứng được triển khai

Đạt

5 Xoá mạng chuỗi khối đã được triển khai

Mạng chuỗi khối và các tài

nguyên được giải phóng Đạt

Dưới đây là các bước người dùng sử dụng hệ thống thử nghiệm để tạo một mạng chuỗi khối và giao thức đồng thuận tương ứng.

Hình 4.3 Màn hình lựa chọn giao thức đồng thuận và mạng chuỗi khối

Hình 4.4 Màn hình cấu hình thông tin các nút trong chuỗi khối và hạ tầng triển khai

Hình 4.5 Màn hình kết thúc bước cài đặt

Hình 4.7 Màn hình kiểm tra trạng thái hạ tầng trên Digital Ocean

Hình 4.8 Màn hình kiểm tra các nút chuỗi khối trên Kubernetes

4.3 Thử nghiệm tốc độ xử lý giao dịch

Mục tiêu của thử nghiệm này để đánh giá tốc độ xử lý các giao dịch của mạng chuỗi khối và giao thức đồng thuận được triển khai có đáp ứng được nhu cầu về tốc độ xử lý giao dịch của các ứng dụng phi tập trung hay không. Hệ thống yêu cầu phải đáp ứng tối thiểu 15 giao dịch/giây với các ứng dụng phi tập trung liên quan đến lĩnh vực quản lý đất đai của Trung tâm Thông tin Lưu trữ và Thư viện

54 tài nguyên môi trường quốc gia, Cục Công nghệ thông tin và Dữ liệu tài nguyên môi trường, Bộ Tài nguyên và Môi trường.

Các bước tiến hành như sau:

 Xây dựng và triển khai một số ứng dụng phi tập trung (DAPP) trên mạng chuỗi khối được tự động triển khai bằng hệ thống đề xuất tại Hình 4.1. Ta có thể kể đến một số các ứng dụng như: dịch vụ công quản lý chứng chỉ định giá đất (dvcchungchidgd), dịch vụ công quản lý hồ sơ (dvchoso), dịch vụ công quản lý quá trình xử lý hồ sơ (dvcquatrinhxulyhs), dịch vụ quản lý tài liệu (dvctailieu), dịch vụ quản lý giấy chứng giấy (dvcttgiaychungnhan).

 Phát triển một module để đánh giá tốc độ xử lý giao dịch của mạng chuỗi khối (Benchmark Engine) dựa trên công cụ wrk [25]. Benchmark Engine sẽ tạo nhiều luồng xử lý, mô tả quá trình người dùng tương tác với các ứng dụng phi tập trung. Từ đó tính toán ra tốc độ xử lý của nền tảng vừa triển khai. Minh hoạ tại Hình 4.9.

Bảng 4.2 Testcase TC01-01

Testcase ID TC01-01

Tác vụ Thêm mới

Mô tả Thực hiện kiểm thử tác vụ Thêm mới và đo số giao dịch được xử lý trên một đơn vị thời gian

Dữ liệu kiểm thử { “MaHoSo”: “mahoso01”, “SoChungChi”: “2020”,

“NgayCoHieuLuc”: “01/01/2020”, “NgayHetHieuLuc”: “31/12/2020”, “CoQuanCap”: “UBND Ha Noi”, “ChuSoHuu”: “Nguyen Van A”, “QuocTich”: “VietNam”,

“SoCMND”: “012345678”,

“NgayCapCMND”: “01/01/1978”, “NguoiKy”: “Tran Van B”,

“NgaySinh”: “01/01/1960”, “ChungChi”: chungchidgd.doc “CreatedDate”: “09/09/2020”, “CreatedBy”: “UserTest”, “ModifitedDate”: “09/09/2020”, “ModifitedBy”: “UserTest” } Điều kiện tiền đề Xác thực người dùng thành công

Các bước thực hiện Bước 1: Tạo người dùng và xác thực người dùng Bước 2: Chạy mô-đun và kiểm thử với dữ liệu kiểm thử Bước 3: Lưu kết quả kiểm thử

Kết quả mong muốn 15 giao dịch được xử lý trên 1 giây

Kết quả thực tế ●

TPS: 15.28 giao dịch/giây

● Tổng số yêu cầu: 3669 yêu cầu

● Lỗi kết nối: 0

● Lỗi quá thời gian chờ: 0

Bảng 4.3 Testcase TC01-02

Testcase ID TC01-02

Tác vụ Cập nhật

Mô tả Thực hiện kiểm thử tác vụ Cập nhật và đo số giao dịch được xử lý trên một đơn vị thời gian

Dữ liệu kiểm thử { “NgayCoHieuLuc”: “01/01/2020”, “NgayHetHieuLuc”: “31/12/2020”, “ChungChi”: dvcchungchidgd.doc “ModifitedDate”: “09/09/2020”, “ModifitedBy”: “UserTest”, “ID”: “3f3492af-12d3-49d3-a649- ed585d47fb76” }

Điều kiện tiền đề Đã xác thực người dùng

Các bước thực hiện Bước 1: Tạo người dùng và xác thực người dùng

Bước 2: Chạy mô-đun và kiểm thử với dữ liệu kiểm thử Bước 3: Lưu kết quả kiểm thử

Kết quả mong muốn 15 giao dịch được xử lý trên 1 giây Kết quả thực tế ●

TPS: 26.02 giao dịch/giây

● Tổng số yêu cầu: 6248 yêu cầu

● Lỗi kết nối: 0

● Lỗi quá thời gian chờ: 0

Bảng 4.4 Testcase TC01-03

Testcase ID TC01-03

Tác vụ Cập nhật tất cả

Mô tả Thực hiện kiểm thử tác vụ Cập nhật tất cả và đo số giao dịch được xử lý trên một đơn vị thời gian

Dữ liệu kiểm thử { “MaHoSo”: “mahoso01”, “SoChungChi”: “2020”,

“NgayCoHieuLuc”: “01/01/2020”, “NgayHetHieuLuc”: “31/12/2020”, “CoQuanCap”: “UBND Ha Noi”, “ChuSoHuu”: “Nguyen Van A”, “QuocTich”: “VietNam”,

“SoCMND”: “012345678”,

“NgayCapCMND”: “01/01/1978”, “NguoiKy”: “Tran Van B”,

“NgaySinh”: “01/01/1960”, “ChungChi”: dvcchungchidgd.doc “CreatedDate”: “09/09/2020”, “CreatedBy”: “UserTest”, “ModifitedDate”: “09/09/2020”, “ModifitedBy”: “UserTest”, “SoChungChiCu”: “2019”, “ID”:“3f3492af-12d3-49d3-a649-ed585d47fb76”} Điều kiện tiền đề Đã xác thực người dùng

Các bước thực hiện Bước 1: Tạo người dùng và xác thực người dùng

Bước 2: Chạy mô-đun và kiểm thử với dữ liệu kiểm thử Bước 3: Lưu kết quả kiểm thử

Kết quả mong muốn 15 giao dịch được xử lý trên 1 giây Kết quả thực tế

● TPS: 25.52 giao dịch/giây

● Tổng số yêu cầu: 6128 yêu cầu

● Lỗi kết nối: 0

Bảng 4.5 Testcase TC01-04

Testcase ID TC01-04

Tác vụ Lấy theo mã hồ sơ

Mô tả Thực hiện kiểm thử tác vụ Lấy theo mã hồ sơ và đo số giao dịch được xử lý trên một đơn vị thời gian

Dữ liệu kiểm thử {“MaHoSo”: “mahoso01”} Điều kiện tiền đề Đã xác thực người dùng

Các bước thực hiện Bước 1: Tạo người dùng và xác thực người dùng

Bước 2: Chạy mô-đun và kiểm thử với dữ liệu kiểm thử Bước 3: Lưu kết quả kiểm thử

Kết quả mong muốn 15 giao dịch được xử lý trên 1 giây Kết quả thực tế

● TPS: 40.72 giao dịch/giây

● Tổng số yêu cầu: 9775 yêu cầu

● Lỗi kết nối: 0

● Lỗi quá thời gian chờ: 0

Bảng 4.6 Testcase TC01-05

Testcase ID TC01-05

Tác vụ Lấy theo số chứng chỉ

Mô tả Thực hiện kiểm thử tác vụ Lấy theo số chứng chỉ và đo số giao dịch được xử lý trên một đơn vị thời gian Dữ liệu kiểm thử {“SoChungChi”: “2020”}

Điều kiện tiền đề Đã xác thực người dùng

Kết quả mong muốn 15 giao dịch được xử lý trên 1 giây Kết quả thực tế

● TPS: 43.69 giao dịch/giây

● Tổng số yêu cầu: 10490 yêu cầu

● Lỗi kết nối: 0

● Lỗi quá thời gian chờ: 0

Bảng 4.7 Testcase TC01-06

Testcase ID TC01-06

Tác vụ Lấy theo số chứng chỉ cũ

Mô tả Kiểm thử tác vụ Lấy theo số chứng chỉ cũ và đo đạc Dữ liệu kiểm thử {“SoChungChiCu”: “2019”}

Điều kiện tiền đề Đã xác thực người dùng

Kết quả mong muốn 15 giao dịch được xử lý trên 1 giây Kết quả thực tế

● TPS: 37.25 giao dịch/giây

● Tổng số yêu cầu: 8944 yêu cầu

● Lỗi kết nối: 0

● Lỗi quá thời gian chờ: 0

Bảng 4.8 Testcase TC01-07

Testcase ID TC01-07

Tác vụ Lấy chứng chỉ

Mô tả Thực hiện kiểm thử tác vụ Lấy chứng chỉ và đo số giao dịch được xử lý trên một đơn vị thời gian

Dữ liệu kiểm thử { “SoChungChi”: “2020”,

“NgayCoHieuLuc”: “01/01/2020”,

“NgayHetHieuLuc”: “31/12/2020” } Điều kiện tiền đề Đã xác thực người dùng

Kết quả mong muốn 15 giao dịch được xử lý trên 1 giây Kết quả thực tế

● TPS: 45.31 giao dịch/giây

● Tổng số yêu cầu: 10879 yêu cầu

● Lỗi kết nối: 0

60 Ta có thể thấy rằng các thao tác với ứng dụng phi tập trung triển khai để thử nghiệm đều có thể được thực hiện với tốc độ phù hợp với yêu cầu nghiệp vụ khi có nhiều truy vấn đồng thời. Các giao dịch lấy dữ liệu từ chuỗi khối thường có tốc độ cao hơn. Ngược lại, các thao tác ghi dữ liệu mới, cập nhật dữ liệu thường tốn thời gian. Một phần nguyên nhân do dữ liệu truyền tải lớn, các nút phải tham gia

Thử nghiệm khả năng chịu tải, chịu lỗi