Thiết kế khối mới nhất của NEAR Doomslug so sánh PBFT, Tendermint và HotStuff

Tiêu đề gốc: "Thiết kế khối mới nhất của NEAR Doomslug so sánh PBFT, Tendermint, HotStuff"
Nguồn gốc: NEAR Chinese Community



Bài viết này sẽ phân tích sự khác biệt giữa công nghệ tạo khối mới nhất của NEAR Doomslug và PBFT, Tendermint và HotStuff. Chúng ta sẽ tìm hiểu sâu về cách hoạt động của PBFT, Tendermint và HotStuff, bao gồm các chuyển đổi khung nhìn, đường dẫn, khả năng phản hồi và các chi tiết khác.

Vào ngày cuối cùng của thế kỷ 21 (31/12/2019), NEAR đã phát hành bài báo của Doomslug (https://near. ai/ doomslug_14), đề xuất một phương pháp tạo khối mới cho phép NEAR đạt được mức độ chắc chắn thực tế nhất định thông qua một vòng giao tiếp và cung cấp sự chắc chắn BFT hoàn toàn sau hai vòng giao tiếp thông qua thành phần cuối cùng.

(Nói một cách đơn giản, Dung sai lỗi Byzantine (BFT) là một thuộc tính hệ thống có khả năng chống lại một loạt lỗi do các Tướng Byzantine gây ra Vấn đề. Điều này có nghĩa là Điều này có nghĩa là ngay cả khi một số nút bị lỗi hoặc có hành vi nguy hiểm, hệ thống chịu lỗi Byzantine vẫn có thể tiếp tục hoạt động. - Binance Academy)

Những gì chúng tôi nói Sự chắc chắn thực tế, hay Sự chắc chắn của Doomslug, có nghĩa là trừ khi một nút làm điều xấu, một khối do Doomslug tạo ra là không thể thay đổi được. Một tính năng tuyệt vời khác của Doomslug là chỉ cần một nửa số người tham gia trực tuyến hoặc trung thực, nó có thể tiếp tục tạo và xác định các khối, không giống như các cơ chế đồng thuận BFT khác yêu cầu 2/3 số người trực tuyến (tất nhiên, các Thành phần cuối cùng vẫn yêu cầu hai phần ba số người tham gia trực tuyến).

Bây giờ Doomslug đã được triển khai trên NEAR, đã đến lúc giải thích cách hoạt động của nó và cách thức hoạt động của nó với các phương pháp tạo khối khác. Sự khác biệt, đặc biệt là sự khác biệt giữa Tendermint và HotStuff.

Nếu bạn có bất kỳ ý tưởng nào về bài viết này, chúng tôi hoan nghênh phản hồi. Bạn có thể đặt câu hỏi trong diễn đàn.
https://near.ai/discuss_14

Cách thức hoạt động của Doomslug

Nói một cách đơn giản, Doomslug hoạt động bằng cách yêu cầu một nhóm người tham gia thay phiên nhau tạo và phát các khối. Khi người tham gia nhận được khối có chiều cao h, họ sẽ gửi xác nhận của mình cho khối này tới nhà sản xuất khối h+1. Nếu nhà sản xuất khối h+1 không tạo khối sau một khoảng thời gian định sẵn, người gửi xác nhận sẽ gửi một tin nhắn khác đến nhà sản xuất khối h+2, đề nghị họ nên bỏ qua khối h +1.



Khi người tham gia có hơn một nửa tổng số xác nhận hoặc bỏ qua thông tin, anh ta có thể tự tạo thông tin của mình của các khối.

Miễn là sự chậm trễ thông tin và một số tình huống xấu thực sự được giải quyết, phương pháp tưởng chừng đơn giản này có thể cung cấp các tính năng mà chúng tôi mong muốn. : Nếu một khối do Doomslug tạo ra được hơn một nửa số nhà sản xuất khối của khối trước đó xác nhận thì khối trước đó sẽ không thể đảo ngược trừ khi ít nhất một trong số các nhà sản xuất khối làm điều gì đó xấu xa. Quan trọng hơn, nó đảm bảo rằng ngay cả khi mạng chậm và thông tin bị trễ, một khối chứa hơn một nửa số xác nhận sẽ luôn được tạo nên thuật toán sẽ không bị lỗi.

Như đã đề cập trước đó, sẽ có thành phần cuối cùng chạy cùng với Doomslug. Trong trường hợp bình thường, khi khối h+1 được tạo ra, khối có chiều cao h sẽ đạt được kết thúc Doomslug, trong khi khối có chiều cao h-1 sẽ có kết thúc BFT đầy đủ. Nói cách khác, chỉ cần không có một phần ba số người làm điều ác thì khối đó không thể sửa đổi được. Chúng tôi sẽ so sánh Doomslug với các thuật toán đồng thuận khác.

Các thành phần Doomslug và Finality đều cung cấp khả năng không thể đảo ngược của khối mà không cần giả định về tốc độ và độ tin cậy của mạng. Nói cách khác, cả Doomslug và thành phần cuối cùng đều có thể cung cấp bảo mật trên cơ sở mạng không đồng bộ. Tuy nhiên, việc đảm bảo rằng hai thuật toán này không bị lỗi (hoặc "đang hoạt động") đòi hỏi phải có một mạng đồng bộ hóa nhất định. Đây là một giả định phổ biến và tất cả các thuật toán đồng thuận được thảo luận trong bài viết này đều có cùng một giả định về lập luận "tính sống động" của chúng. Không thể có cả sự an toàn và sự sống động trong một mạng không đồng bộ, được gọi là "Không thể có FLP".

Giới thiệu ngắn gọn về PBFT, Tendermint và HotStuff

Trước khi so sánh Doomslug với Tendermint và HotStuff, chúng ta hãy xem hai thuật toán còn lại hoạt động như thế nào.

Trong trường hợp tốt nhất, PBFT, Tendermint và HotStuff hoạt động rất giống nhau:



Các giao thức đồng thuận thường hoạt động ở nhiều phạm vi, ít nhất là một phạm vi. Mỗi chân trời sẽ có một người lãnh đạo được chỉ định để thực thi sự đồng thuận. Người lãnh đạo đề xuất một kết quả cụ thể. Ở chân trời đầu tiên, việc lựa chọn các kết quả là tùy ý. Người lãnh đạo gửi kết quả này cho những người tham gia khác, những người phản hồi bằng phiếu bầu trước cho kết quả này. Sau khi có được 2/3 số phiếu bầu trước, người tham gia sẽ gửi cam kết trước về kết quả đó. Sự đồng thuận đạt được khi hai phần ba số người tham gia cam kết trước.

Cách trao đổi thông tin giữa những người tham gia khác nhau tùy thuộc vào giao thức. Trong Tendermint, những người tham gia sử dụng giao thức tin đồn và mỗi người tham gia sẽ tích lũy số phiếu bầu trước và cam kết trước tại địa phương; trong HotStuff, người lãnh đạo sẽ tính toán thông tin và cung cấp lại cho những người tham gia.

Toàn bộ quá trình có thể được hoàn thành chỉ với chi phí mạng tăng tuyến tính. Trên thực tế, nếu chỉ người lãnh đạo đếm số phiếu bầu trước và số cam kết trước thì lần phát sóng đầu tiên về một kết quả cụ thể và phản hồi về số phiếu bầu trước và cam kết trước từ những người tham gia khác đã là tuyến tính. Chi phí tăng trưởng bậc hai duy nhất là gửi phiếu bầu trước và cam kết trước tích lũy, nhưng điều này cũng có thể được giải quyết thông qua các phương pháp như chữ ký BLS.

Nếu vì lý do nào đó người lãnh đạo không đạt được sự đồng thuận, họ sẽ chuyển sang chân trời tiếp theo và người lãnh đạo tiếp theo sẽ thử lại . Sự chuyển đổi góc nhìn là sự khác biệt đáng kể nhất giữa HotStuff, Tendermint và PBFT. Trong PBFT, mỗi người tham gia có một bộ đếm thời gian để tính toán lượng thời gian đã trôi qua kể từ khi bắt đầu đường chân trời. Khi bộ đếm thời gian vượt quá một ngưỡng nhất định, một thông báo thay đổi đường chân trời sẽ được gửi đến người lãnh đạo tiếp theo. Khi người lãnh đạo tiếp theo thu được hơn 2/3 thông tin về sự thay đổi của chân trời, anh ta sẽ trả lời bằng một thông điệp mở ra một chân trời mới. Toàn bộ quá trình này đòi hỏi ít nhất một mức chi phí chung và cũng khá khó để thực hiện chính xác.

Tendermint và HotStuff sử dụng các phương pháp khác nhau để thực hiện chuyển đổi khung nhìn. Cả hai giai đoạn bỏ phiếu trước và cam kết trước đều có cài đặt thời gian chờ. Khi thời gian chờ được kích hoạt, người tham gia sẽ gửi thông báo bỏ phiếu trước hoặc cam kết trước tương ứng tới "đối tượng null" và chuyển sang giai đoạn hoặc đường chân trời tiếp theo cục bộ . Vì vậy, chuyển đổi góc nhìn không phải là một bước phối hợp mà là một hoạt động bí mật. Do cơ chế thực hiện thay đổi chế độ xem và các khối cam kết về cơ bản là giống nhau nên điều này làm cho thuật toán trở nên khá đơn giản.

Tendermint có hai điểm khác biệt chính với HotStuff. Đầu tiên, HotStuff được tạo đường ống, nghĩa là cam kết trước của chế độ xem trước là bỏ phiếu trước cho chế độ xem tiếp theo, giúp giảm gần một nửa số bước so với phiên bản không có đường ống. Có ý kiến cho rằng Tendermint cũng nên được đưa vào đường ống, nhưng phiên bản được Cosmos đề xuất và sử dụng không có thiết kế đường ống. Điểm thứ hai và cũng là điểm được thảo luận nhiều nhất, đó là HotStuff có thiết kế đáp ứng và một nhà lãnh đạo trung thực sẽ luôn đạt được sự đồng thuận đúng hạn, bất kể độ trễ của mạng, không bị hết thời gian chờ. Đây không phải là trường hợp của Tendermint. Trong giai đoạn cam kết trước, nếu người tham gia nhận thấy rằng ba trong số hai người tham gia đã gửi cam kết trước đến đối tượng trống, họ sẽ không thể chuyển sang chế độ xem tiếp theo cho đến khi hết thời gian chờ Ngược lại, một cặp Kẻ tấn công có khả năng kiểm soát mạng tốt có thể khiến thuật toán chuyển đổi giữa các chân trời mãi mãi.

Mặc dù khả năng đáp ứng là một thiết kế đơn giản nhưng nó cũng gây hiểu nhầm ở một mức độ nhất định. Cụ thể, nó chỉ đảm bảo rằng nếu người lãnh đạo trực tuyến và trung thực thì thời gian đạt được sự đồng thuận sẽ bị giới hạn bởi độ trễ của mạng. Nếu người dẫn đầu không trực tuyến, hệ thống sẽ vẫn đợi toàn bộ thời gian chờ và chuyển sang chân trời tiếp theo. Trong ứng dụng thực tế của Cosmos, nó đã chạy một số lượng lớn nút Tendermint trong một thời gian dài. Tất cả các thay đổi về chế độ xem xảy ra là do người lãnh đạo ngoại tuyến chứ không phải do cam kết trước với các đối tượng trống, điều đó có nghĩa là ngay cả với Thiết kế đáp ứng của HotStuff cho đến nay sẽ không giúp ích được gì cho Cosmos.

Bài viết này sẽ không đi sâu vào các vòng giao tiếp bổ sung cần thiết để HotStuff đạt được khả năng phản hồi. Ở góc nhìn thứ nhất, vòng giao tiếp bổ sung như vậy có thể được bỏ qua, còn ở góc nhìn thứ hai, nó được bù đắp bằng những ưu điểm mà pipeline mang lại nên vòng giao tiếp bổ sung này ít có khả năng là vấn đề lớn.

Doomslug vs Tendermint & HotStuff

Tình huống lý tưởng

Bây giờ, hãy so sánh Doomslug với các thành phần cuối cùng với Tendermint và HotStuff trong các tình huống khác nhau. Đầu tiên, chúng ta hãy xem xét trường hợp không có sự thay đổi nào xảy ra và tất cả thông tin đều đến được với người dẫn đầu kịp thời.



Như minh họa trong hình trên, khối màu xám là khối được đề xuất và khối màu xanh lam là Khối với tính hữu hạn của BFT, các khối màu vàng là các khối có tính hữu hạn của Doomslug.

Trong trường hợp bình thường, HotStuff và Tendermint hoạt động giống hệt nhau: khi một khối được đề xuất, sau hai vòng giao tiếp, khối The khối được hoàn thiện và hai vòng sau, khối tiếp theo cũng được hoàn thiện. Điều đáng chú ý là HotStuff không kết nối giữa các khối mà chỉ giữa các chế độ xem, do đó việc tạo hai khối vẫn cần 4 vòng giao tiếp thay vì 3 vòng.

Doomslug không giảm độ trễ cần thiết để đạt được kết thúc BFT, vì vậy khi khối đầu tiên được tạo ra, vẫn cần hai vòng giao tiếp để đạt được sự chắc chắn của BFT. Tuy nhiên, như đã đề cập ở trên, sau một vòng giao tiếp, khối đã đạt đến độ chắc chắn yếu hơn BFT, tức là độ chắc chắn của Doomslug, tức là trừ khi có ít nhất một nhà sản xuất khối làm điều ác thì khối đó sẽ không thể đảo ngược.

Cũng lưu ý rằng do đặc điểm của các thành phần cuối cùng nên thông lượng của chúng giống với số khối cơ bản, vì vậy trong After ba vòng giao tiếp, hai khối đã đạt đến kết thúc BFT và sau bốn vòng giao tiếp, có ba khối. Nói cách khác, mặc dù Doomslug với thành phần cuối cùng yêu cầu cùng một thời gian cho một khối. Các khối đạt được kết thúc BFT, nhưng Doomslug có thể hoàn thành số khối gấp đôi so với Tendermint và Hotstuff trong cùng một khoảng thời gian. Mặc dù nó không cải thiện độ trễ nhưng nó đã tăng gấp đôi thông lượng.

Tình huống không lý tưởng



Bây giờ chúng ta hãy xem xét các tình huống không lý tưởng, chẳng hạn như một số người tham gia ngoại tuyến hoặc không đạt được sự đồng thuận vì những lý do khác. Hình ảnh trên cho thấy sự thất bại của hai góc nhìn liên tiếp. Trong trường hợp của Tendermint, có thêm hai vòng liên lạc cho mỗi đường chân trời không thành công, có nghĩa là phải mất 6 vòng để hoàn thành một khối. Trong trường hợp HotStuff, đường ống bắt đầu hoạt động và các khối được hoàn thiện sau 4 vòng liên lạc. Vì thành phần cuối cùng có cùng thông lượng với chuỗi khối cơ bản, nên Doomslug có khả năng xử lý tương tự và cũng sẽ hoàn thiện các khối sau 4 vòng giao tiếp. Nhưng lưu ý rằng sau 3 vòng đầu tiên, khối đã đạt đến trạng thái cuối cùng của Doomslug và vào thời điểm vòng khối giao tiếp thứ tư được hoàn tất, một khối khác đã đạt đến trạng thái cuối cùng của Doomslug.

Các khía cạnh khác

Tóm lại, chúng ta đã thảo luận về các phương pháp so sánh giữa cơ chế sản xuất khối và thuật toán đồng thuận từ một chiều: điều gì cần thiết để đạt được tính hữu hạn trong các tình huống khác nhau. của vòng đấu. Thực tế có nhiều cách khác để suy nghĩ về vấn đề này. Ví dụ: mặc dù tất cả các thuật toán đồng thuận được thảo luận trong bài viết này đều đang hoạt động (nói cách khác, chúng sẽ không thất bại trong một số trường hợp nhất định), nhưng chúng hoạt động khác nhau khi đối mặt với độ trễ mạng và gián đoạn mạng. Có sự khác biệt đáng kể về thời gian họ cần để phục hồi sau khi mất liên kết kéo dài. Trong các thử nghiệm của chúng tôi, Doomslug đã nhanh chóng phục hồi sau một thời gian dài không hoạt động trên mạng
(https://github.com/nearprotocol/nearcore /blob/staging/ chain/chain/tests/doomslug.rs#L297),
Nhưng nhìn chung, từ góc độ này, thuật toán đồng thuận Rất ít nghiên cứu được thực hiện .

Một khía cạnh khác là mức độ phức tạp của việc triển khai. Giả sử rằng một phần ba số nhà sản xuất khối không bao giờ có thể bị hỏng, thì một giao thức được xây dựng trên Tendermint hoặc HotStuff sẽ không cần triển khai bất kỳ logic nào để ngăn chặn sự phân nhánh. Doomslug hoàn thiện các khối chậm hơn so với việc tạo ra các khối, vì vậy có thể xảy ra phân nhánh trước khi khối được hoàn tất. Do đó, giao thức cần có khả năng xử lý các vấn đề phân tách như vậy, điều này làm tăng đáng kể độ phức tạp của việc triển khai giao thức. Đối với NEAR, vì chúng tôi là một giao thức blockchain áp dụng nguyên tắc chuỗi dài nhất nên chúng tôi đã có tất cả logic để xử lý các nhánh và đã tiến hành thử nghiệm nghiêm ngặt. Tuy nhiên, đối với những người muốn xây dựng một giao thức blockchain từ đầu, nói chung là không cần phải giải quyết các vấn đề phân nhánh sẽ làm giảm đáng kể khó khăn khi thực hiện.

Văn bản gốc: ALEXANDER SKIDANOV
Bản dịch: Buster

Liên kết nguồn: weixin.qq.com

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia