Tác giả: Giáo sư Wang Yongge, một nhà mật mã học nổi tiếng của Trung Quốc, giáo sư khoa học máy tính tại Đại học Bắc Carolina ở Charlotte (UNC, Charlotte), tiến sĩ của Đại học Heidelberg, và nhà khoa học trưởng của Sperax.
chữ
Lamport, Leslie. "The part-time parliament." ACM Transactions on Computer Systems (TOCS) 16.2 (1998): 133-169.
Việc thiết kế các giao thức đồng thuận luôn là một chủ đề rất thách thức. Người chiến thắng giải thưởng Turing Lamport đã sử dụng một nhóm các nhà lập pháp nghiệp dư trên đảo Paxos của Hy Lạp cổ đại để làm luật vào năm 1989 nhằm mô tả giao thức đồng thuận Paxos mà ông đã thiết kế cho điện toán phân tán. Lamport đã gửi bài báo của mình cho ACM TOCS. Có lẽ biên tập viên của tạp chí này đã không đánh giá cao tầm quan trọng của bài báo, vì vậy ông đã không bao giờ đồng ý xuất bản nó. Mãi cho đến khi giao thức đồng thuận Paxos được thảo luận rộng rãi trong giới học thuật và được sử dụng rộng rãi trong ngành, tạp chí đã xuất bản bài báo vào năm 1998:
Lamport tự đùa rằng đây là thời gian chờ đợi lâu thứ hai để xuất bản bất kỳ bài báo nào của ông. Cho đến nay, giao thức đồng thuận Paxos đã được sử dụng trong hầu hết các hệ thống phân tán. Ví dụ: Bigtable của Google sử dụng hệ thống dịch vụ khóa Chubby để đảm bảo tính nhất quán của dữ liệu tại mỗi nút. Dịch vụ khóa Chubby dựa trên giao thức Paxos. Ngoài ra, các hệ thống dịch vụ đám mây của Microsoft, IBM và Amazon đều sử dụng giao thức Paxos để mang lại tính nhất quán cho hệ thống. Nói một cách đại khái, giao thức Paxos bao gồm một loạt các VÒNG. VÒNG bắt đầu từ 0 cho đến khi đạt được sự đồng thuận. Mỗi VÒNG bao gồm bốn bước sau:
1. Nút chủ tạo một số sê-ri và phát nó tới tất cả các nút. Tôi hy vọng mọi người sẽ tham gia vào hoạt động của số sê-ri này
2. Mỗi nút gửi thông tin sau đến nút chính: số thứ tự của các phiếu bầu mà anh ấy đã tham gia và các phiếu bầu mà anh ấy đã bình chọn
3. Sau khi nhận được hầu hết các câu trả lời trong bước thứ hai, nút chính chọn một giá trị v sẽ không vi phạm AN TOÀN. quảng bá giá trị v này cho tất cả các nút
4. Sau khi mỗi nút nhận được giá trị v từ nút chính trong bước thứ ba, nó sẽ bỏ phiếu cho v và phát phiếu bầu của mình cho tất cả các nút
Do giao thức Paxos khó thực hiện nên các nhà nghiên cứu của Stanford đã đề xuất một giao thức Paxos mô-đun và dễ thực hiện vào năm 2014, đồng thời đặt tên cho giao thức này là giao thức Raft. Giao thức Paxos/Raft hoạt động theo mô hình mối đe dọa nhẹ hơn. Nói cách khác, giao thức chỉ mạnh đối với các lỗi không phải của Byzantine trong các mạng không đồng bộ. Trong mô hình mối đe dọa phi Byzantine, các nút bị lỗi chỉ có thể mắc lỗi thụ động (chẳng hạn như ngừng hoạt động) và không thể khởi động các cuộc tấn công chủ động. Số nút lỗi không phải Byzantine tối đa mà một hệ thống có n nút có thể chịu đựng được là (n-1)/2. Giao thức Paxos/Raft đạt được số nút chịu lỗi tối đa này.
Do giao thức Paxos/Raft không mạnh đối với các lỗi Byzantine nên chúng không thể được sử dụng trong hệ thống mạng mở (chẳng hạn như hệ thống chuỗi khối). Lỗi Byzantine là những lỗi tích cực tích cực, chẳng hạn như nói dối, giả mạo thông điệp, tấn công thông đồng hoặc khởi chạy các cuộc tấn công DoS có chọn lọc. Chúng tôi đã đề cập trong các bài viết trước rằng hệ thống chuỗi khối phi tập trung dựa trên hệ thống mạng mở, vì vậy chúng tôi phải sử dụng mô hình mối đe dọa Byzantine.
Thỏa thuận Byzantine được sử dụng rộng rãi nhất trong chuỗi khối trên thị trường là hệ thống chịu lỗi Byzantine thực tế PBFT (BFT thực tế) được thiết kế bởi người đoạt giải Turing, Barbara Liskov và sinh viên của cô, Castro. PBFT được sử dụng rộng rãi trong các chuỗi liên minh (như Hyperledger răng cưa và Hyperchain của Qulian Technology) và nhiều chuỗi công khai. PBFT có thể được coi là phiên bản Byzantine của giao thức Paxos. Sự khác biệt chính là PBFT thêm bước xác minh vào giao thức Paxos để ngăn lỗi Byzantine. Trước khi phân tích tính bảo mật của nó, trước tiên chúng tôi đưa ra mô tả chính thức về giao thức của nó.
Trong giao thức PBFT, chúng tôi giả định rằng có n=3t+1 nút P1, ..., Pn. Trong số đó, nhiều nhất t nút được kiểm soát bởi kẻ tấn công. PBFT yêu cầu tất cả các nút cùng duy trì trạng thái và thực hiện các hành động nhất quán. Giao thức PBFT được thực hiện thông qua một loạt các chế độ xem. Trong mỗi khung nhìn, có một nút được gọi là nút chính (lãnh đạo). Đầu tiên, một hệ thống PBFT bắt đầu với một chế độ xem (v=0), sau đó chuyển sang các chế độ xem v=1, v=2, …, v.v. thông qua giao thức thay thế chế độ xem. Chỉ khi hệ thống tin rằng nút chính không thể hoạt động bình thường, nó mới bắt đầu giao thức thay thế chế độ xem và chuyển sang chế độ xem tiếp theo. Chúng tôi giả định rằng tất cả các nút đều biết ai là nút chính cho mỗi chế độ xem. Bất cứ khi nào khách hàng gửi một tác vụ tới nút chính của chế độ xem hiện tại, giao thức PBFT sẽ thực hiện ba giai đoạn giao tiếp: gán số thứ tự (chuẩn bị trước), tương tác lẫn nhau (chuẩn bị) và xác nhận số thứ tự (cam kết). Giai đoạn phân bổ số sê-ri (chuẩn bị trước) chỉ định một số sê-ri cho từng tác vụ và các giai đoạn tương tác lẫn nhau (chuẩn bị) và xác nhận số sê-ri (cam kết) cung cấp thứ tự chung cho tất cả các tác vụ. Giả sử chúng ta đang ở chế độ xem v và nút chính là Pi. Sau đó, quá trình của toàn bộ thỏa thuận như sau:
1. Máy khách gửi yêu cầu tác vụ m để kích hoạt hoạt động dịch vụ của nút chủ.
2. Sau khi nút chủ Pi nhận được yêu cầu tác vụ m, nó bắt đầu giao thức ba pha:
m,
a.Giai đoạn cấp phát số thứ tự (chuẩn bị trước): nút chủ chọn một số thứ tự thứ tự duy nhất cho yêu cầu tác vụ m. Nút chính sau đó phát thông báo sau tới tất cả các nút
trong đó H là một hàm băm. Một nút Pj chấp nhận thông báo trên nếu các điều kiện sau được đáp ứng
i. Chữ ký số CHỮ KÝ hợp lệ
ii. Pj chưa chấp nhận yêu cầu nhiệm vụ khác với cùng v, seq
iii. Số sê-ri nằm trong phạm vi hợp lý
b.Giai đoạn tương tác lẫn nhau (chuẩn bị): Nếu nút Pj chấp nhận thông báo quảng bá từ nút chủ, thì Pj bước vào giai đoạn tương tác (chuẩn bị) và phát thông báo sau tới tất cả các nút
Sau khi sẵn sàng cho Pj, Pj phát thông báo xác nhận sau tới tất cả các nút:
Khi một nút nhận được 2t+1 thông báo xác nhận, nút đó sẽ thực hiện tác vụ có trong yêu cầu tác vụ m và gửi kết quả trực tiếp đến máy khách.
3. Client chờ phản hồi từ các nút khác nhau, nếu t+1 phản hồi giống nhau thì phản hồi là kết quả của thao tác.
Yongge Wang. Byzantine Fault Tolerance in Partially Connected Asynchronous Networks
Gần đây chúng tôi đã phân tích tính bảo mật của PBFT trong các bài viết sau:
Phân tích của bài viết này kết luận rằng giao thức đồng thuận PBFT không an toàn trong mạng không đồng bộ. Trong bài viết này, chúng tôi giới thiệu sơ lược về phương thức tấn công do chúng tôi thiết kế trên giao thức PBFT trong mạng không đồng bộ. Để đơn giản hóa mô tả của chúng tôi, chúng tôi giả sử rằng hệ thống có n=3+1=4 nút P1, P2, P3, P4. Trong số đó, nút P1 được kiểm soát bởi kẻ tấn công. Ngoài ra, chúng tôi giả sử rằng nút chính của chế độ xem v là P1. Cuộc tấn công của chúng tôi mở ra trong chế độ xem v:
, CHỮ KÝ" gửi đến P1, P2, P3. Nhưng không đến P4.
Nó đã sẵn sàng cho các nút P1,P2,P3. Bởi vì P4 đã nhận được nhiều nhất hai tin nhắn tương tác và chúng tôi cần ít nhất 2+1=3 tin nhắn để chuẩn bị một mảng, vì vậy đối với P4, mảng này chưa sẵn sàng.
, CHỮ KÝ" được gửi đến tất cả các nút. Tất nhiên, nếu có thể, kẻ tấn công có thể khởi động một cuộc tấn công DoS để ngăn không cho nút P4 nhận các thông báo quảng bá từ các nút P2 và P3 (cuộc tấn công DoS này không quan trọng lắm đối với cuộc tấn công của chúng tôi). Tại thời điểm này, các nút P1 và P2 đã nhận được 3 thông báo xác nhận cho nhiệm vụ m. Các nút P3 và P4 nhận được nhiều nhất 2 thông báo xác nhận cho tác vụ m. Vì vậy, nút P2 sẽ thực hiện tác vụ có trong yêu cầu tác vụ m và gửi kết quả trực tiếp đến máy khách. Nhưng P1,P3,P4 sẽ không thực hiện nhiệm vụ này. Vì vậy, khách hàng không nhận được đủ câu trả lời.
Sau khi thực hiện cuộc tấn công trên, nút P1 sẽ không còn trả lời bất kỳ tin nhắn nào của bất kỳ chế độ xem nào v. Như vậy hệ thống sẽ bắt đầu giao thức thay thế khung nhìn để vào khung nhìn tiếp theo v+1. Sau khi vào chế độ xem v +1, trạng thái dữ liệu bên trong của các nút trung thực P2, P3, P4 là khác nhau. Vì vậy, hệ thống đi vào trạng thái không phối hợp.
Trong giao thức PBFT, để giải quyết vấn đề một số nút có thể không nhận được một số thông báo nhất định (chẳng hạn như kịch bản tấn công ở trên), giao thức PBFT đã thiết kế quy trình cập nhật trạng thái CHECKPOINT. Đặc biệt, sau mỗi 100 tác vụ được thực hiện, mỗi nút Pj sẽ phát thông báo trạng thái hiện tại của nó tới tất cả các nút:
Nếu nút Pi nhận được thông báo cập nhật trạng thái 2t+1 như trên và trạng thái của nó là trạng thái, thì nút Pi sẽ thay thế trạng thái hiện tại của nó bằng trạng thái trạng thái trong thông báo trên. Trong cuộc tấn công ở trên của chúng tôi, nếu nút không trung thực P1 không xuất bản thông báo cập nhật trạng thái, thì thông báo cập nhật trạng thái do P2 đưa ra sẽ khác với thông báo cập nhật trạng thái do P3 và P4 đưa ra. Bởi vì chúng tôi cần ít nhất 2+1=3 thông báo cập nhật trạng thái giống hệt nhau để cập nhật trạng thái của một nút, trạng thái của P2 không thể được cập nhật thành trạng thái của P3 và P4. Vì vậy, hệ thống sẽ luôn ở trạng thái không điều phối.
Ở dạng xem sau, nút không trung thực P1 có thể hợp tác với các nút trung thực P3 và P4 để cùng thực hiện một yêu cầu tác vụ khác từ máy khách. Do đó, trạng thái của mỗi nút sẽ chuyển sang trạng thái không phối hợp không thể phục hồi.
Trong bài viết trước, chúng tôi đã đề cập rằng trong công nghệ chuỗi khối dựa trên Internet, các cuộc tấn công DoS rất dễ thực hiện. Vì Internet là một mạng không đồng bộ, chúng tôi sử dụng mô hình sau để mô tả giao tiếp mạng của nó:
Có một Thời gian Ổn định Toàn cầu (GST), trước đó bất kỳ thông báo nào cũng có thể bị mất (chẳng hạn như một cuộc tấn công DoS) hoặc được sắp xếp lại. Sau GST, mạng trở thành mạng đồng bộ. Nhưng khi GST sẽ bắt đầu, không ai biết.
IOS
Android