PBFT là gì?

Mục lục

1. PBFT giải quyết bài toán gì?
2. PBFT hoạt động thế nào qua ba pha?
3. Vì sao cần đúng 3f+1 node?
4. View change: chuyện gì xảy ra khi primary hỏng?
5. PBFT khác gì với PoW, PoS và PoA?
6. PBFT có giới hạn gì?
7. PBFT được dùng ở đâu trong blockchain?
8. Doanh nghiệp Việt Nam có nên dùng PBFT?
9. Ưu và nhược điểm tóm tắt
10. Câu hỏi thường gặp

PBFT giải quyết bài toán gì?

Hãy hình dung năm chi nhánh ngân hàng cùng giữ một sổ cái. Một chi nhánh bị lỗi phần mềm, hoặc một quản trị viên bị mua chuộc, nên chi nhánh đó báo với nhóm A là “giao dịch X đã được duyệt”, còn báo với nhóm B là “giao dịch X bị từ chối”. Đây là lỗi Byzantine (Byzantine fault): node không chỉ ngừng hoạt động mà còn gửi thông tin mâu thuẫn cho các node khác.

Lỗi sập (crash fault) dễ xử lý hơn. Node sập thì im lặng, còn node Byzantine vẫn nói, nhưng nói sai. Với lỗi sập, thuật toán Paxos cần N = 2F+1 node. Với lỗi Byzantine, PBFT cần N = 3F+1, trong đó F là số node lỗi tối đa hệ thống chịu được.

Về nguồn gốc, PBFT được giới thiệu năm 1999 trong bài báo tại hội nghị OSDI của nhóm nghiên cứu MIT. Trước đó, các thuật toán thoả thuận Byzantine bị coi là quá chậm để dùng thật. Chữ “Practical” trong tên nhấn mạnh đây là bản đủ nhanh để chạy trong hệ thống thực. Bài báo gốc đã được trình bày tại OSDI 1999 và về sau trở thành nền cho nhiều giao thức BFT khác. Trong blockchain, PBFT được xem là một cơ chế đồng thuận cho mạng consortium và private. Bạn có thể xem bức tranh chung ở bài cơ chế đồng thuận trong blockchain.

PBFT hoạt động thế nào qua ba pha?

Hệ thống có một node chính (primary) và các node còn lại gọi là replica. Vai trò primary không cố định, mà luân chuyển theo từng “view” (xem phần view change bên dưới). Mỗi yêu cầu đi qua các bước sau.

1. Request: client gửi yêu cầu (ví dụ một giao dịch) tới primary.
2. Pre-prepare: primary gán số thứ tự cho yêu cầu rồi phát cho tất cả replica. Primary gán một sequence number, multicast thông điệp pre-prepare tới mọi backup và ghi vào log của mình.
3. Prepare: mỗi replica kiểm tra chữ ký, kiểm tra view hiện tại, rồi phát thông điệp prepare cho mọi replica khác. Replica không chấp nhận hai nội dung khác nhau cho cùng một số thứ tự trong cùng một view. Replica coi yêu cầu là “prepared” khi nhận pre-prepare cùng 2f thông điệp prepare khớp nhau.
4. Commit: khi đã prepared, replica phát thông điệp commit. Đủ 2f+1 commit khớp thì replica thực thi yêu cầu.
5. Reply: mỗi replica trả kết quả thẳng cho client. Client chờ F+1 phản hồi từ các replica khác nhau cho cùng một kết quả rồi mới tin.

Hai nhóm pha có hai nhiệm vụ khác nhau. Pre-prepare và prepare đảm bảo thứ tự các yêu cầu trong cùng một view, kể cả khi primary gian lận. Prepare và commit đảm bảo yêu cầu đã commit vẫn giữ nguyên thứ tự khi chuyển view. Pha commit tồn tại chính vì lý do thứ hai này, và nhiều bài giới thiệu hay bỏ qua điều đó.

Vì sao cần đúng 3f+1 node?

Đây là câu hỏi cốt lõi mà các bài tổng quan thường chỉ nêu công thức. Lập luận như sau, với trường hợp f = 1.

• Hệ thống không thể chờ đủ cả n phản hồi, vì f node lỗi có thể im lặng. Do đó phải tiến lên được khi chỉ có n − f phản hồi, tức 2f+1 khi n = 3f+1.
• Trong 2f+1 phản hồi đó, tối đa f có thể đến từ node gian lận. Còn lại ít nhất f+1 phản hồi trung thực, nhiều hơn số phiếu gian lận.
• Hai nhóm 2f+1 node bất kỳ luôn giao nhau ít nhất f+1 node, nên luôn có ít nhất một node trung thực nằm trong cả hai nhóm. Nhờ đó không thể có hai quyết định mâu thuẫn cùng được chốt.

Nếu chỉ dùng 2f+1 node như Paxos, một node trung thực chậm trễ cộng một node gian lận có thể khiến phần còn lại không phân biệt được đâu là giá trị đúng. Bài giảng về PBFT ở Đại học Utah cũng nêu tình huống này và kết luận cần nhân bản đủ để chịu f node chậm hoặc sập thì mới có 3f+1. Các tài liệu học thuật phát biểu rằng PBFT đạt an toàn và sống còn khi và chỉ khi n ≥ 3f+1.

View change: chuyện gì xảy ra khi primary hỏng?

Primary là điểm yếu tiềm tàng, vì nó quyết định thứ tự. Nếu primary gian lận hoặc im lặng, các replica cần cách thay nó mà không mất các yêu cầu đã chốt. Cơ chế đó gọi là view change.

• Mỗi replica đặt đồng hồ chờ khi nhận yêu cầu. Quá hạn mà chưa xong thì replica đòi đổi view.
• Primary mới thường được chọn theo công thức id = (view + 1) mod N, mô tả trong tài liệu sáng chế về giao thức kết thúc view change. Số view tăng dần mỗi lần đổi, nên các node luôn biết “lượt” nào đang chạy.
• Primary mới thu thập bằng chứng prepared từ các replica rồi phát thông điệp new-view, để những yêu cầu đã chuẩn bị trước đó không bị bỏ sót hay xếp lại thứ tự.

Ở phía client, client có đồng hồ chờ và khi hết hạn sẽ gửi yêu cầu tới tất cả replica. Nhờ vậy primary gian lận không thể “nuốt” yêu cầu của client mà không ai biết.

Về hai tính chất cần giữ, safety là mọi node trung thực cho cùng kết quả hợp lệ, còn liveness là mọi node trung thực cuối cùng đều ra kết quả mà không kẹt giữa chừng. Với PBFT, safety không phụ thuộc vào đồng hồ mạng, còn liveness cần mạng ổn định ở mức “partially synchronous”: mạng được giả định đồng bộ từng phần và có kênh xác thực đáng tin.

PBFT khác gì với PoW, PoS và PoA?

PBFT thuộc nhóm đồng thuận dựa trên bỏ phiếu giữa các node biết trước nhau. Các cơ chế còn lại có logic khác hẳn.

Tiêu chí	PBFT	Proof of Work	Proof of Stake	Proof of Authority
Ai được tham gia	Danh sách node biết trước	Ai cũng có thể đào	Ai đặt cọc đủ	Validator được cấp phép
Cách chốt khối	Bỏ phiếu 3 pha, 2f+1 phiếu	Giải bài toán băm	Validator được chọn và xác nhận	Validator ký khối
Chịu node gian lận	Tối đa 1/3 số node	Dựa vào đa số sức băm	Dựa vào phần stake trung thực	Dựa vào danh tiếng validator
Tính chung cuộc (finality)	Chốt ngay khi commit	Xác suất, tăng theo số khối	Tuỳ giao thức	Thường nhanh
Quy mô node phù hợp	Nhỏ đến vừa	Rất lớn	Lớn	Nhỏ
Tiêu tốn năng lượng	Thấp	Cao	Thấp	Thấp

Điểm khác lớn nhất nằm ở finality. Trong Proof of Work, giao dịch được coi là an toàn dần theo số khối xếp phía sau, và vẫn có xác suất nhỏ bị đảo. PBFT thì không có “khối mồ côi” ở chế độ bình thường: đã commit là xong. Đổi lại, nó đòi hỏi danh sách thành viên cố định. Proof of Authority có điểm giống ở chỗ validator được cấp phép, nhưng PoA tin vào danh tính và uy tín, còn PBFT tin vào toán học về ngưỡng 1/3.

PBFT có giới hạn gì?

Chi phí thông điệp tăng theo bình phương

Ở pha prepare và commit, mỗi replica gửi cho tất cả replica còn lại. Với n node, số thông điệp mỗi vòng cỡ n², tức độ phức tạp O(n²). Mạng 4 node không thấy gánh nặng, nhưng mạng vài trăm node sẽ nghẽn băng thông. Các giao thức BFT đời sau (như HotStuff và biến thể) ra đời một phần để giảm gánh nặng này.

Phải biết trước toàn bộ thành viên

Một nghiên cứu về chọn siêu node trong blockchain nhận xét rằng PBFT cần biết số node và giới hạn node gian lận, nên khó áp dụng cho hệ thống công khai. Ai cũng có thể tạo hàng nghìn danh tính giả (tấn công Sybil) nếu không có cơ chế cấp phép. Đó là lý do bạn gần như chỉ gặp PBFT trong blockchain consortium và private.

Ngưỡng 1/3 không mềm

Nếu hơn 1/3 node bị kẻ tấn công kiểm soát, hệ thống không còn đảm bảo gì. Ngưỡng này tính theo số node, không theo mức độ “quan trọng” của node. Vì vậy, nếu 3 trên 7 thành viên liên minh dùng chung một nhà cung cấp đám mây hoặc một đội vận hành, rủi ro lỗi chung (common-mode failure) có thể vượt ngưỡng dù trên giấy tờ họ là ba thành viên độc lập.

Cần mạng ổn định để duy trì tiến độ

Khi mạng chập chờn, view change xảy ra liên tục và hệ thống chậm đi dù không có kẻ gian. Một nghiên cứu về PBFT trong mạng không dây còn cho thấy cần một “viable area” tối thiểu để bảo đảm liveness, safety và khả năng chống chịu. Cách bố trí mạng giữa các node ảnh hưởng trực tiếp đến hiệu năng.

PBFT được dùng ở đâu trong blockchain?

PBFT gốc là giao thức nhân bản máy trạng thái (state machine replication), chưa phải thuật toán blockchain. Khi dùng cho blockchain, chỉ cần ba pha pre-prepare, prepare, commit, vì bước request và reply của hệ thống nhân bản dịch vụ không còn cần thiết. Primary lúc này đóng vai người đề xuất khối.

Các nền tảng doanh nghiệp thường chọn một biến thể BFT hoặc cơ chế khác tuỳ bài toán. Bạn nên đọc tài liệu từng nền tảng để biết bản nào hiện hỗ trợ bộ đồng thuận nào, vì điều này đổi theo phiên bản. Với nền tảng điển hình cho mạng liên minh, bạn có thể tham khảo Hyperledger Fabric.

Doanh nghiệp Việt Nam có nên dùng PBFT?

PBFT hợp lý khi bạn đồng thời có ba điều kiện: nhiều tổ chức không hoàn toàn tin nhau cùng ghi vào một sổ cái, danh sách thành viên cố định và biết rõ, và cần kết quả chốt dứt điểm ngay thay vì “gần như chắc chắn”. Ví dụ minh hoạ: một liên minh gồm nhà sản xuất, đơn vị logistics, kho lạnh, hải quan và ngân hàng tài trợ, mỗi bên chạy một node, cùng ghi trạng thái lô hàng. Bài toán thuộc nhóm truy xuất nguồn gốc bằng blockchain, và 5 bên cho phép chịu 1 node sai lệch (n = 4 là mức tối thiểu cho f = 1, nên 5 node vẫn chịu f = 1).

Ngược lại, PBFT không đáng dùng khi chỉ một công ty giữ toàn bộ node. Khi đó cơ sở dữ liệu thông thường rẻ hơn và dễ vận hành hơn, như phân tích ở bài blockchain khác database. PBFT cũng không phù hợp khi thành viên đổi liên tục, vì mỗi lần thêm hoặc bớt node phải cấu hình lại tập thành viên.

Với mạng liên minh, mỗi node thường là một máy chủ do một tổ chức vận hành. Bạn có thể tìm hiểu vai trò từng loại ở bài node trong blockchain. Mỗi thông điệp trong PBFT cần được ký hoặc xác thực. Bản gốc giảm chi phí bằng cách dùng mã xác thực thông điệp (MAC) thay cho mật mã bất đối xứng. Nền tảng về chữ ký số có ở bài private key và public key.

Ưu và nhược điểm tóm tắt

Ưu điểm	Nhược điểm
Chịu được node gian lận, không chỉ node sập	Chi phí thông điệp cỡ n², khó mở rộng số node
Chốt kết quả ngay sau một vòng bỏ phiếu	Cần danh sách thành viên biết trước
Không đào, không tiêu tốn điện như PoW	Mất đảm bảo nếu hơn 1/3 node bị chiếm quyền
Được nghiên cứu sâu từ 1999, có nhiều biến thể	Liveness phụ thuộc chất lượng mạng giữa các node

Câu hỏi thường gặp

PBFT viết tắt của từ gì?

PBFT là Practical Byzantine Fault Tolerance, nghĩa là “chịu lỗi Byzantine một cách thực dụng”. Chữ “Practical” chỉ việc thuật toán đủ nhanh để chạy trong hệ thống thật, khác với các giải pháp thoả thuận Byzantine trước đó vốn quá tốn kém.

PBFT có dùng cho Bitcoin hoặc Ethereum không?

Không. Bitcoin dùng Proof of Work, còn Ethereum dùng Proof of Stake. Cả hai là mạng công khai có số node lớn và danh tính mở, trong khi PBFT cần danh sách node cố định và chi phí thông điệp tăng theo bình phương số node. Xem thêm Bitcoin là gì.

Nếu có đúng 1/3 số node gian lận thì sao?

Điều kiện là n ≥ 3f+1, nghĩa là số node gian lận phải ít hơn 1/3 tổng số. Với 4 node, chịu được 1 node lỗi. Nếu 2 trên 4 node lỗi thì hệ thống không còn bảo đảm, vì không còn đủ 2f+1 = 3 node trung thực để lập đa số.

Pha commit có thừa không, sao không dừng ở prepare?

Không thừa. Prepare chỉ đảm bảo thứ tự trong cùng một view. Nếu primary hỏng giữa chừng và view đổi, pha commit giúp các yêu cầu đã chốt giữ nguyên thứ tự ở view mới. Thiếu commit thì hai replica có thể thực thi hai thứ tự khác nhau sau khi đổi primary.

PBFT khác Raft và Paxos ở điểm nào?

Raft và Paxos chỉ chịu node sập hoặc mất kết nối, và cần 2f+1 node. PBFT chịu cả node nói dối và cần 3f+1. Nếu mọi node thuộc cùng một tổ chức và bạn tin họ, Raft hoặc Paxos đơn giản và nhẹ hơn. Nếu các bên không hoàn toàn tin nhau, bạn cần họ BFT như PBFT.

PBFT có thể mở rộng lên hàng nghìn node không?

PBFT gốc thì không phù hợp, vì mỗi vòng cần khoảng n² thông điệp. Nhiều giao thức đời sau giảm gánh nặng bằng cách chọn một nhóm nhỏ làm uỷ ban bỏ phiếu hoặc dùng cấu trúc thông điệp khác. Bạn nên xem đặc tả của giao thức cụ thể thay vì mặc định kết quả của PBFT gốc.