Chúng tôi đã học được rằng các hệ thống phân tán thường đạt được tính nhất quán thông qua nguyên tắc sao chép trạng thái [1]. Ý tưởng cốt lõi là tất cả các bản sao trong hệ thống chạy cùng một máy trạng thái. Miễn là tất cả các bản sao bắt đầu với cùng một trạng thái ban đầu và thực hiện một tập hợp các hoạt động theo cùng một trình tự dựa trên cùng một trạng thái ban đầu, thì tất cả các trạng thái cuối cùng sẽ hội tụ. , tức là toàn bộ hệ thống thể hiện tính nhất quán ra bên ngoài. Việc xác định nhóm hoạt động này theo cùng một thứ tự yêu cầu hệ thống phải đạt được sự đồng thuận.Hơn nữa, tất cả các nút trung thực đều đạt được sự đồng thuận về thứ tự thực hiện.Đây là bài toán nổi tiếng của Byzantine Generals [2].

Chúng tôi đã học được rằng các hệ thống phân tán thường đạt được tính nhất quán thông qua nguyên tắc sao chép trạng thái [1]. Ý tưởng cốt lõi là tất cả các bản sao trong hệ thống chạy cùng một máy trạng thái. Miễn là tất cả các bản sao bắt đầu với cùng một trạng thái ban đầu và thực hiện một tập hợp các hoạt động theo cùng một trình tự dựa trên cùng một trạng thái ban đầu, thì tất cả các trạng thái cuối cùng sẽ hội tụ. , tức là toàn bộ hệ thống thể hiện tính nhất quán ra bên ngoài. Việc xác định nhóm hoạt động này theo cùng một thứ tự yêu cầu hệ thống phải đạt được sự đồng thuận.Hơn nữa, tất cả các nút trung thực đều đạt được sự đồng thuận về thứ tự thực hiện.Đây là bài toán nổi tiếng của Byzantine Generals [2].

Đảm bảo an ninh lý thuyết của thuật toán đồng thuận Byzantine, nghĩa là n>3f, n là tổng số nút và f là số nút độc hại. Thuật toán đồng thuận Byzantine cần đảm bảo hai thuộc tính:

• Bảo mật: Tất cả các nút trung thực đều tin rằng trạng thái hệ thống là s tại một thời điểm nhất định

• Hoạt động: Tất cả các nút trung thực cuối cùng có thể xác định s là trạng thái hệ thống

Trong đó s là một khái niệm trừu tượng, có thể hiểu là trong hệ thống tồn tại một biến S, giá trị của biến S này chính là trạng thái của hệ thống, các nút trong hệ thống nhận được một loạt các lệnh thao tác về S. Tại một thời điểm nhất định (giả sử rằng không có lỗi trong đồng hồ của mỗi nút) Đồng thuận về giá trị của S, tất cả các nút trung thực xác định biến S=s để đáp ứng an toàn, tất cả các nút trung thực phải đưa ra quyết định về giá trị của biến S và chấm dứt để đáp ứng sự sống động.

Trước đây, trong nghiên cứu về các hệ thống phân tán, sự đồng thuận của Byzantine thường đi kèm với độ phức tạp trong giao tiếp cao, gây ra mức tiêu thụ mạng lớn và quy mô của hệ thống không dễ mở rộng. Ví dụ, trong thuật toán PBFT cổ điển, nó cần trải qua ba giai đoạn để đạt được sự đồng thuận. Trong giai đoạn CHUẨN BỊ TRƯỚC, nút chính gửi thông báo yêu cầu đến các nút khác. Sau khi các nút khác xác minh thông báo, chúng sẽ gửi thông báo chuẩn bị tin nhắn đến các nút khác. Giai đoạn này tạo ra n^2 tin nhắn. Để đảm bảo tính nhất quán giữa các chế độ xem, một nút sẽ gửi một thông báo cam kết tới các nút khác sau khi nhận được ít nhất các thông báo chuẩn bị đại biểu. Khi nút cuối cùng nhận được một thông báo cam kết có ít nhất đại biểu, thì cuối cùng nút đó sẽ gửi yêu cầu. Tuy nhiên, khi một nút bất thường của mạng hết thời gian chờ và kích hoạt chuyển đổi chế độ xem, thì cần có độ phức tạp giao tiếp là o(n^3)

Hiểu công việc của từng giai đoạn trong PBFT là cơ sở của HotStuff và mục tiêu của từng giai đoạn trong PBFT là đảm bảo an toàn và sống động.

Giả sử rằng hệ thống nhận được lệnh S'=S+1 tại một thời điểm nhất định, nút chính sẽ gửi lệnh S'=S+1 này đến nút không phải là nút chính (đây là thông báo chuẩn bị trước), bởi vì nó là một Vấn đề Byzantine, nút trung thực không chắc chắn về chính nó Liệu tin nhắn nhận được có nhất quán với các nút trung thực khác hay không (nút chính gửi tin nhắn không nhất quán) và các nút cần giao tiếp với nhau một lần để đảm bảo rằng tin nhắn được nhận bởi chính họ và các nút trung thực khác nhất quán (xác định rằng nút chính không gửi thông báo không nhất quán), mỗi nút Gửi thông báo chuẩn bị tới tất cả các nút khác và nếu bạn nhận được thông báo chuẩn bị đại biểu và vượt qua xác minh (xác minh rằng hướng dẫn được chỉ ra trong chuẩn bị phù hợp với bản thân), vòng đồng thuận đầu tiên đạt được (đây là giai đoạn CHUẨN BỊ). Tại thời điểm này, có vẻ như các thông điệp mà các nút trung thực nhận được là nhất quán. Nhưng điều kiện ngầm định ở đây là các nút đã đạt được sự đồng thuận chỉ nhìn thấy nó từ quan điểm của riêng họ: Tôi đã nhận và xác minh các thông báo nhất quán về đại biểu. Tuy nhiên, các nút khác có thể không nhất thiết nhận được thông báo chuẩn bị đại biểu để đạt được sự đồng thuận. Nếu việc gửi được thực hiện vào thời điểm này và xảy ra lỗi mạng, thì nút được gửi sẽ biết rằng đã đạt được sự đồng thuận. Miễn là mạng phục hồi, hướng dẫn này chắc chắn sẽ được chấp nhận bởi toàn bộ hệ thống. Tuy nhiên, các nút khác có thể không đạt được sự đồng thuận do lỗi mạng và họ không thể chắc chắn liệu họ có thể gửi sau khi chờ đợi hay không. Để giữ cho hệ thống hoạt động, chuyển đổi chế độ xem được thực hiện và tại thời điểm này, nút chính mới cần xác định xem có nên thực hiện các lệnh mới trên cơ sở S' hay S hay không. Nếu không tìm thấy một số nút đã gửi lệnh và một lệnh khác S''=S+2 đã được đồng ý và gửi, hệ thống sẽ có sự không thống nhất về giá trị của biến S. Do đó, có những vấn đề bảo mật để gửi vào thời điểm này.

Nếu một giai đoạn đồng thuận khác được thực hiện, sau khi đạt được sự đồng thuận PREPARE, mỗi nút sẽ gửi một thông báo cam kết khác và mỗi nút sẽ chờ để chấp nhận và xác minh các thông báo cam kết đại biểu trước khi gửi. Họ sẽ gặp phải vấn đề tương tự. Các nút đã đạt được sự đồng thuận của COMMIT đã gửi. Họ biết rằng nếu mạng bình thường thì sớm muộn gì hệ thống cũng sẽ gửi, nhưng các nút khác chưa đạt được sự đồng thuận của COMMIT thì không chắc liệu họ có có thể gửi cuối cùng. Sau khi xảy ra lỗi mạng, nếu nút chính trong chế độ xem mới không tìm thấy các nút đã gửi, nó vẫn sẽ gây ra sự không nhất quán. Mâu thuẫn ở đây là chúng ta cần chuyển đổi chế độ xem để tiếp tục đồng thuận cho hoạt động; để bảo mật, chúng tôi cũng cần đảm bảo rằng giá trị của S nhất quán trước khi chế độ xem mới bắt đầu đồng thuận và các hướng dẫn đã gửi cũng phải được gửi trong chế độ xem mới. xem. Trong PBFT, phương pháp gửi tin nhắn đến các nút khác để chứng minh trạng thái của S của chính nó khi chế độ xem được chuyển đổi được sử dụng, tức là gửi một tin nhắn chuẩn bị trước cho S mới nhất của nó và các tin nhắn chuẩn bị đại biểu tương ứng. Khi chế độ xem được chuyển đổi, nút chính mới có thể đánh giá liệu S'=S+1 có cần được gửi trước khi có sự đồng thuận hay không.

• Nếu không có nút nào đạt được sự đồng thuận về PREPARE cho S'=S+1, thì nút đó sẽ không tiếp tục gửi S'=S+1.

• Nếu có một cặp nút đạt được sự đồng thuận về giai đoạn CHUẨN BỊ của S'=S+1, thì không thể đạt được sự đồng thuận về một lệnh mâu thuẫn S''=S+2 và gửi nó.

Theo quy tắc này, tính bảo mật và hoạt động được đảm bảo, nhưng độ phức tạp do phương pháp này mang lại là o(n^3). Do đó, thuật toán vẫn không thể được sử dụng trong các mạng quy mô lớn. Thuật toán đồng thuận HotStuff [4] do Yin Maofan và cộng sự đề xuất có các đặc điểm thay đổi chế độ xem tuyến tính, giúp giải quyết nút thắt cổ chai của sự đồng thuận PBFT cổ điển hoặc thậm chí BFT. Việc chuyển đổi của nút chính không cần tăng các giao thức và chi phí khác, và hệ thống vẫn có thể thực hiện công việc nhất quán bên ngoài. Nó làm giảm sự phức tạp trong giao tiếp của quy trình đồng thuận xuống còn o(n).

——Khái niệm cơ bản về HotStuff——

Hiểu thuật toán hotstuff yêu cầu giới thiệu một số khái niệm liên quan đến quy trình đồng thuận:

1) Chữ ký ngưỡng [5] (Chữ ký ngưỡng): Lược đồ chữ ký ngưỡng A (k, n) đề cập đến một nhóm chữ ký bao gồm n thành viên, tất cả các thành viên chia sẻ một khóa chung và mỗi thành viên có khóa riêng của mình. Miễn là chữ ký của k thành viên được thu thập và chữ ký hoàn chỉnh được tạo, chữ ký có thể được xác minh bằng khóa công khai.

2) Chứng chỉ (Chứng chỉ đại biểu, QC): Sau khi nút chính nhận được ít nhất cặp nút đại biểu thông báo biểu quyết (có chữ ký) cho một đề xuất, nó sẽ sử dụng chữ ký ngưỡng để tổng hợp QC. QC này có thể được hiểu là chữ ký ngưỡng hoàn chỉnh Chữ ký được tạo có nghĩa là đã đạt được sự đồng thuận về đề xuất.

3) Chế độ xem: Chế độ xem là đơn vị cơ bản của sự đồng thuận. Một chế độ xem có thể đạt được sự đồng thuận nhiều nhất một lần và nó tăng lên một cách đơn điệu. Mỗi chế độ xem dần dần xoay vòng để thúc đẩy sự đồng thuận.

4) Cây trạng thái đồng thuận: mỗi khối đồng thuận có thể được coi là một nút cây, mỗi nút cây chứa nội dung đề xuất tương ứng (hướng dẫn thao tác trước đó) và QC tương ứng, và mỗi nút cây chứa hàm băm nút cây mẹ để tạo thành một cây cấu trúc và nút chính tạo ra các nút cây mới dựa trên nhánh cục bộ dài nhất. Nút trễ đồng bộ hóa các nút cây bị thiếu trung gian với các nút cây mới nhất trên các nhánh dài nhất của các nút khác.

—— Quy trình đồng thuận HotStuff ——

chữ

▲ Basic Hotstuff

Basic HotStuff là quá trình đồng thuận cơ bản. Trong số đó, chế độ xem liên tục được chuyển đổi theo cách tăng dần đơn điệu. Mỗi chế độ xem có một nút chính duy nhất chịu trách nhiệm về đề xuất, thu thập và chuyển tiếp tin nhắn cũng như tạo QC. Toàn bộ quá trình bao gồm 4 giai đoạn: giai đoạn chuẩn bị (PREPARE), giai đoạn trước khi gửi (PRE-COMMIT), giai đoạn gửi (COMMIT), giai đoạn giai đoạn quyết định (DECIDE), nút chính đệ trình (đạt được sự đồng thuận) một nhánh nhất định, thu thập thông báo bỏ phiếu có chữ ký từ các nút đồng thuận đại biểu trong ba giai đoạn CHUẨN BỊ, CAM KẾT TRƯỚC và CAM KẾT, sử dụng chữ ký ngưỡng để tổng hợp QC , sau đó phát nó đến nút khác.

Kết hợp với chữ ký ngưỡng, HotStuff có thể chuyển đổi phương pháp phát thông báo đồng thuận trước đó sang nút chính để xử lý, hợp nhất và chuyển tiếp, đồng thời độ phức tạp của giao tiếp có thể giảm xuống còn o(n). Nói tóm lại, HotStuff sử dụng chữ ký ngưỡng + hai vòng truyền thông để đạt được Hiệu ứng đồng thuận của một vòng truyền thông PBFT.

So với thuật toán PBFT, sự đồng thuận bắt đầu khi nút chính gửi yêu cầu đến các nút khác trong giai đoạn chuẩn bị trước, nút chính đã hoàn thành trách nhiệm của vòng đồng thuận này và sau đó nó sẽ giống như các nút khác. Toàn bộ quá trình đồng thuận bao gồm giai đoạn đề xuất quảng bá (giai đoạn TRƯỚC-CHUẨN BỊ) và hai giai đoạn đồng thuận (giai đoạn CHUẨN BỊ, giai đoạn CAM KẾT).

Giai đoạn CHUẨN BỊ:

Nút chính: 1) Theo thông báo Chế độ xem mới của số đại biểu đã nhận, chứa chuẩn bịQC có chiều cao cao nhất trong cây trạng thái của người gửi, nút chính tính toán QC chiều cao cao nhất từ ​​chuẩn bịQC nhận được, được ghi là highQC ;

2) Theo nhánh được trỏ bởi nút của highQC này, đóng gói khối để tạo nút cây mới và nút cha của nó là nút được trỏ bởi highQC;

3) Gửi đề xuất đã tạo tới các nút nô lệ khác trong thông báo chuẩn bị và đề xuất hiện tại chứa highQC.

Nút nô lệ: 1) Sau khi nhận được thông báo chuẩn bị, xác minh thông tin trong chuẩn bị, bao gồm tính hợp lệ của chữ ký trong qc; cho dù đó là đề xuất của chế độ xem hiện tại;

2) Liệu nút trong thông báo chuẩn bị có được mở rộng từ nhánh của LockQC (nghĩa là nút con) hoặc số lượt xem của highQC trong thông báo chuẩn bị có lớn hơn so với LockQC hay không (cái trước là điều kiện bảo mật và sau là điều kiện hoạt động để đảm bảo đồng bộ kịp thời khi nút bị chậm);

3) Tạo một thông báo chuẩn bị bỏ phiếu và gửi nó đến nút chính kèm theo chữ ký.

Giai đoạn CAM KẾT TRƯỚC:

Khi nút chính nhận được thông báo biểu quyết chuẩn bị đại biểu cho đề xuất hiện tại, chuẩn bị QC có được bằng cách tổng hợp các chữ ký một phần của đại biểu; sau đó nút chính phát thông báo trước cam kết với chuẩn bị QC tổng hợp.

Nút phụ: các nút khác nhận thông báo xác nhận trước và sau khi xác minh, gửi thông báo bỏ phiếu xác nhận trước tới nút chính.

⚠️Lưu ý rằng tại thời điểm này, chuẩn bịQC trong pre-commit được gửi bởi nút chính cho biết thông báo đề xuất trong thông báo chuẩn bị và tất cả các nút đã bỏ phiếu để đạt được sự đồng thuận thành công. Thời điểm này tương tự như sự đồng thuận đạt được trong giai đoạn CHUẨN BỊ trong PBFT.

Giai đoạn cam kết:

Nút chính: Tương tự như giai đoạn tiền cam kết. 1) Trước tiên, nút chính thu thập các thông báo bỏ phiếu trước khi cam kết đại biểu, sau đó tổng hợp QC trước khi cam kết của giai đoạn này và gửi nó đến các nút khác trong thông báo cam kết. 2) Đặt QC bị khóa cục bộ thành pre-commitQC.

Nút phụ: Khi nhận được thông báo cam kết, quá trình xác minh thông báo được thông qua và QC bị khóa cục bộ cũng được cập nhật dưới dạng pre-commitQC trong thông báo cam kết, và nó được ký và một phiếu bầu cam kết được tạo và gửi đến nút chính

⚠️Lưu ý rằng tại thời điểm này, pre-commitQC được đính kèm với thông báo cam kết được gửi bởi nút chính tương tự như vòng thứ hai của sự đồng thuận giai đoạn CAM KẾT trong PBFT, trong đó sự đồng thuận của giai đoạn này trong PBFT biểu thị sự đồng thuận của giai đoạn đầu tiên của cặp nút để đạt được sự đồng thuận, nghĩa là đảm bảo rằng ít nhất các nút đại biểu đã hoàn thành giai đoạn CHUẨN BỊ và khi chuyển đổi chế độ xem xảy ra, đủ các nút có thể chứng minh rằng đã đạt được sự đồng thuận CHUẨN BỊ đối với đề xuất và nội dung đề xuất cần sẽ được gửi trong chế độ xem mới.

Giai đoạn QUYẾT ĐỊNH:

Nút chính: 1) Khi thông báo biểu quyết cam kết đại biểu được thu thập, commitQC được tổng hợp và gửi đến các nút khác trong thông báo quyết định;

2) Khi các nút khác nhận được thông báo quyết định, giao dịch trong đề xuất được chỉ định bởi commitQC sẽ được thực thi;

3) Sau đó tăng số lượt xem số lượt xem, bắt đầu vòng đồng thuận tiếp theo và xây dựng thông báo Chế độ xem mới theo chuẩn bị QC.

Nút nô lệ: Sau khi xác minh thông báo, hãy thực hiện giao dịch của nút cây được chỉ định bởi commitQC trong thông báo quyết định.

giai đoạn gián đoạn nextView: Nếu sự kiện hết thời gian chờ xảy ra trong bất kỳ giai đoạn nào khác của quy trình đồng thuận, việc gửi thông báo chế độ xem mới cho chế độ xem mới sẽ trực tiếp bắt đầu vòng đồng thuận mới tiếp theo.

chữ

▲ Chained HotStuff

Có thể thấy rằng các quy trình của từng giai đoạn trong Basic HotStuff rất giống nhau. Tác giả của HotStuff đã đề xuất Chained HotStuff để đơn giản hóa loại thông báo của Basic HotStuff và cho phép mỗi giai đoạn của Basic HotStuff xử lý các giao dịch theo cách đường ống dẫn.

Quy trình của Chained HotStuff như sau:

Như có thể thấy trong hình, mỗi giai đoạn chuyển đổi chế độ xem, vì vậy mỗi đề xuất có chế độ xem riêng. Các nút ở trong các chế độ xem khác nhau cho các đề xuất khác nhau. Các phiếu bầu trong giai đoạn CHUẨN BỊ được tổng hợp thành QC bởi nút chính của chế độ xem hiện tại và được chuyển tiếp đến nút chính của chế độ xem tiếp theo. Chuyển sang giai đoạn CAM KẾT TRƯỚC của chế độ xem trước đó. Mỗi giai đoạn có cấu trúc tương tự nhau và giai đoạn CHUẨN BỊ của chế độ xem v+1 có thể được coi là giai đoạn CAM KẾT TRƯỚC của chế độ xem v. Giai đoạn CHUẨN BỊ của chế độ xem v+2 được coi là giai đoạn CAM KẾT TRƯỚC của chế độ xem v+1 và giai đoạn CAM KẾT của chế độ xem v. cmd1 trong v1 sẽ thực hiện các giai đoạn PREPARE, PRE-CAMIT và CAM KẾT trong các chế độ xem v1, v2 và v3 tương ứng và cam kết trong v4. cmd2, v.v. Việc tạo các đề xuất cmd trong mỗi giai đoạn sẽ đi kèm với QC được bình chọn trong giai đoạn trước. Quá trình làm việc của phiên bản hợp lý hóa của HotStuff như sau:

Nút chính: 1) Chờ thông báo XEM MỚI và gửi đề xuất của chính nó;

2) Chờ các nút khác bỏ phiếu;

3) Gửi tin nhắn XEM MỚI tới nút chính tiếp theo.

Nút phụ: 1) Chờ thông báo đề xuất từ ​​nút chính;

2) Kiểm tra QC trong đề xuất, cập nhật highQC cục bộ, QC bị khóa và gửi phiếu bầu;

3) Gửi tin nhắn XEM MỚI tới nút chính tiếp theo.

▲ Event-driven HotStuff

Từ Chained HotStuff đến HotStuff hướng sự kiện, bài báo ban đầu tách rời tính an toàn (safety) và tính sống động (liveness) của toàn bộ giao thức và tính năng sống động trở thành một mô-đun máy điều hòa nhịp tim riêng biệt. Mô-đun máy điều hòa nhịp tim đảm bảo khả năng hoạt động sau Thời gian ổn định toàn cầu (GST). Cung cấp hai chức năng:

• Chọn và xác minh nút chính cho mỗi chế độ xem.

• Giúp các masternode tạo đề xuất.

Nói cách khác, với chi phí chuyển đổi chế độ xem thấp như vậy, bất kỳ cơ chế xoay nút phù hợp nào và bất kỳ chiến lược tạo đề xuất nào đều có thể được áp dụng trong máy tạo nhịp tim.

Nguyên tắc của Hotstuff hướng sự kiện và các phiên bản khác vẫn là sự đồng thuận ba giai đoạn cốt lõi. Sự khác biệt chỉ là sự tiện lợi của việc triển khai kỹ thuật. Để biết chi tiết, hãy xem mã giả của bài báo [4]

tiêu đề phụ

Tối ưu hóa cơ chế hoạt động

Cơ chế hoạt động là chìa khóa cho sự tiến bộ liên tục của sự đồng thuận. Trong bài báo gốc của HotStuff, cơ chế liveness đã sử dụng thời gian chờ nhất quán trên toàn cầu để xác định thời gian chờ của chế độ xem. Trong NoxBFT, chúng tôi đã thiết kế một cơ chế linh hoạt hơn để đối phó với sự bất ổn của môi trường mạng.

tiêu đề phụ

vùng đệm giao dịch

Trong ứng dụng của chuỗi khối, để tránh mất giao dịch, chúng tôi đã thiết kế một nhóm bộ đệm giao dịch để lưu trữ các giao dịch của khách hàng. Mô-đun đồng thuận tích cực lấy các giao dịch để đóng gói. Nhóm giao dịch cũng có thể giảm khối lượng công việc đồng thuận và loại bỏ các giao dịch trùng lặp. Chúng tôi xác định các giao dịch thông qua hàm băm nội dung giao dịch và ghi các giao dịch đã thực hiện vào bộ lọc Bloom để ngăn chặn các cuộc tấn công chi tiêu gấp đôi và cải thiện tính ổn định của thuật toán đồng thuận.

cơ chế phục hồi nhanh

Môi trường mạng không ổn định có thể khiến các nút đồng thuận mất thông báo đồng thuận, khiến các nút bị tụt lại phía sau. Trong bài báo gốc của HotStuff, tác giả đã để việc triển khai cụ thể phần này cho các nhà phát triển. Chúng tôi đã triển khai thuật toán đồng bộ hóa có sẵn trong dự án để khôi phục chức năng đặt hàng của các nút đồng thuận bị trễ, được chia thành hai bước:

1) Nút bị tụt lại phía sau và trực tiếp kéo các khối từ các nút khác để khôi phục về điểm kiểm tra mới nhất.

2) Tiến độ đồng thuận sau khi điểm kiểm tra tụt lại phía sau và Cam kếtQC mới nhất được lấy từ các nút khác để nhanh chóng khôi phục tiến độ đồng thuận.

Để nâng cao hiệu quả, chúng tôi áp dụng cơ chế kéo song song các khối từ các nút khác nhau và mức độ song song có thể được cấu hình linh hoạt. Đầu tiên, các khối được kéo song song được duy trì và sau đó được thực hiện theo cách có thứ tự. Đồng thời, điểm hiệu quả kéo của từng nút được ghi lại để có thể chọn nút mục tiêu một cách hiệu quả để đồng bộ hóa vào lần tiếp theo. Toàn bộ quá trình có thể kéo tất cả các giao dịch bị mất với tốc độ nhanh nhất, giảm thời gian chờ đợi của toàn bộ quá trình.

chữ ký tổng hợp

tóm tắt

tóm tắt

Giới thiệu về tác giả

Giới thiệu về tác giả

Thành Thái Ninh

người giới thiệu

người giới thiệu

[1] Schneider F B . The state machine approach: A tutorial[J]. Springer New York, 1990.

[2] Lamport L ,  Shostak R ,  Pease M . The Byzantine Generals Problem[J]. ACM Transactions on Programming Languages and Systems, 1982, 4(3).

[3] Castro M, Liskov B. Practical Byzantine fault tolerance[C]. OSDI.1999, 99(1999): 173-186.

[4] Yin M ,  Malkhi D ,  Reiter M K , et al. HotStuff: BFT Consensus in the Lens of Blockchain[J].  2018.

[5] Shoup V . Practical Threshold Signatures[C]// International Conference on Theory & Application of Cryptographic Techniques. Springer-Verlag, 2000.