Hạt nhân của blockchain là đạt được một sự nhất trí toàn cầu nghiêm ngặt: nghĩa là, bất kể các nút mạng được phân phối ở đâu trong quốc gia nào hoặc múi giờ nào, tất cả các bên tham gia cuối cùng phải đạt được một sự nhất trí về một tập hợp kết quả khách quan.

Nhưng thực tế của các mạng phân tán không hoàn hảo: các nút bị ngắt kết nối, các nút nói dối, và một số ngay còn cố tình phá hoại. Trong trường hợp này, hệ thống làm thế nào để "nói một tiếng" và duy trì tính nhất quán?

Đây là vấn đề mà giao thức đồng thuận nhắm đến giải quyết. Đó về cơ bản là một bộ quy tắc để hướng dẫn một nhóm các nút độc lập và thậm chí là một phần không tin cậy về cách đạt được một quyết định thống nhất về thứ tự và nội dung của mỗi giao dịch.

Và khi 'sự đồng thuận nghiêm ngặt' này được thiết lập, blockchain có thể mở khóa nhiều tính năng chính, như bảo vệ quyền sở hữu tài sản số, mô hình tiền tệ chống lạm phát, và cấu trúc hợp tác xã có khả năng mở rộng. Nhưng điều kiện tiên quyết là giao thức đồng thuận phải đảm bảo hai khía cạnh cơ bản cùng một lúc:

• Hai khối xung đột không thể được xác nhận cùng lúc;
• Mạng lưới phải tiếp tục tiến lên và không thể bị kẹt hoặc dừng lại.

MonadBFT là bước tiến công nghệ mới nhất trong hướng này.

Một bài đánh giá ngắn về sự tiến hóa của các giao thức đồng thuận

Trong lĩnh vực cơ chế đồng thuận, nó đã được nghiên cứu thực sự trong nhiều thập kỷ. Nhóm giao thức sớm nhất, như PBFT (Practical Byzantine Fault Tolerance), đã có thể xử lý một tình huống rất thực tế: ngay cả khi một số nút trong mạng bỏ chuỗi, hành xử độc ác, hoặc nói linh tinh, miễn là chúng không vượt quá một phần ba tổng số, hệ thống vẫn có thể đạt được sự đồng thuận.

Thiết kế của các giao thức ban đầu này "truyền thống" hơn: một người dẫn đầu được chọn trong mỗi vòng để bắt đầu một đề xuất và các trình xác thực khác bỏ phiếu cho đề xuất này trong nhiều vòng để dần dần xác nhận thứ tự giao dịch.

Toàn bộ quá trình bỏ phiếu thường đi qua một số giai đoạn, như chuẩn bị trước, chuẩn bị, cam kết và trả lời. Tại mỗi giai đoạn, tất cả các bộ xác thực cần phải giao tiếp với nhau. Nói cách khác, mọi người phải nói cho tất cả mọi người khác biết, và khối lượng tin nhắn tăng mạnh theo mô hình 'lưới'.

Độ phức tạp của cấu trúc giao tiếp này là n² - tức là, nếu có 100 người xác nhận trong mạng, mỗi vòng thống nhất có thể cần truyền gần 10.000 tin nhắn.

Trong mạng lưới nhỏ, điều này không phải là vấn đề, nhưng một khi số lượng người xác minh tăng lên, gánh nặng giao tiếp của hệ thống sẽ nhanh chóng trở nên không thể chịu đựng, ảnh hưởng trực tiếp đến hiệu suất.

Nguồn thông tin:https://medium.com/coinmonks/pbft-understanding-the-algorithm-b7a7869650ae

Cấu trúc truyền thông phụ ‘mọi người nói chuyện với mọi người’ thực sự rất không hiệu quả. Ví dụ, trong mạng với 100 bên xác thực, mỗi vòng đồng thuận có thể cần xử lý hàng ngàn tin nhắn.

Điều này vẫn có thể được quản lý trong một vòng tròn nhỏ, nhưng khi đặt trong một mạng xích toàn cầu, mở, tải trọng giao tiếp ngay lập tức trở nên không chấp nhận được. Do đó, các giao thức BFT sớm như PBFT và Tendermint thường chỉ được sử dụng trong các mạng được cấp quyền hoặc hệ thống với rất ít người xác minh để hoạt động với sự chấp nhận.

Để cho phép giao thức BFT thích nghi với môi trường chuỗi công khai không cần phép, một số thiết kế thế hệ tiếp theo đang di chuyển đến các phương pháp giao tiếp nhẹ hơn: cho phép mỗi người xác thực giao tiếp chỉ với người dẫn đầu, thay vì với tất cả các thành viên.

Điều này tối ưu hóa độ phức tạp của tin nhắn từ n² ban đầu thành n, giảm bớt đáng kể gánh nặng hệ thống.

Giao thức HotStuff đã được đề xuất vào năm 2018 để giải quyết vấn đề về khả năng mở rộng này. Triết lý thiết kế của nó rất rõ ràng: thay thế quy trình bỏ phiếu phức tạp của PBFT bằng cấu trúc giao tiếp dựa trên người lãnh đạo ngắn gọn hơn.

Một trong những tính năng quan trọng của HotStuff là giao tiếp tuyến tính được gọi là. Trong cơ chế của nó, mỗi người xác thực chỉ cần gửi phiếu của họ cho người đứng đầu hiện tại, người sau đó đóng gói những phiếu này để tạo ra một Chứng chỉ Hội đồng (QC).

Việc QC này về cơ bản là một chữ ký tập thể, chứng minh cho toàn bộ mạng lưới: 'Hầu hết các nút đồng ý với đề xuất này.'

Ngược lại, chế độ giao tiếp của PBFT là 'phát sóng cho tất cả', nơi mọi người nói chuyện trong nhóm, dẫn đến một cảnh hỗn loạn đôi khi. Chế độ của HotStuff giống như 'một người thu thập, một người đóng gói một lúc', có thể duy trì hoạt động hiệu quả bất kể có bao nhiêu người trên mạng.

Hình vẽ so sánh cấu trúc giao tiếp fan-out của HotStuff với chế độ kết nối hoàn toàn của PBFT Nguồn:

https://www.mdpi.com/1424-8220/24/16/5417

Ngoài việc giao tiếp tuyến tính, HotStuff còn có thể được nâng cấp thành phiên bản được phân chia thành các giai đoạn, được sử dụng để tăng cường hiệu suất.

Trong HotStuff ban đầu, cùng một người xác thực sẽ phục vụ như là người dẫn đầu cho nhiều vòng liên tiếp, cho đến khi một khối được xác nhận hoàn toàn. Quá trình này là ‘xử lý một khối mỗi vòng’, với tất cả nỗ lực tập trung vào việc thúc đẩy khối hiện tại.

Trong đường ống HotStuff, cơ chế trở nên linh hoạt hơn: mỗi vòng, một nhà lãnh đạo mới được chọn, và mỗi nhà lãnh đạo có hai nhiệm vụ:

• Đóng gói vòng bỏ phiếu cuối cùng vào một Chứng chỉ Quorum (QC) ở một bên và phát sóng nó đến toàn bộ mạng;
• Ở một bên, đề xuất một khối mới, sẵn sàng bắt đầu vòng tiếp theo.

Nói cách khác, không còn là “xác nhận một trước khi xử lý cái tiếp theo”, mà giống như một dây chuyền sản xuất, các nhà lãnh đạo khác nhau đảm nhận lần lượt từng bước. Người trước đề xuất một khối, người tiếp theo xác nhận và tiếp tục đề xuất các khối mới, và sự đồng thuận trên chuỗi được truyền đi như một cuộc đua tiếp sức.

Đây là nguồn gốc của phép ẩn dụ “dây chuyền lắp ráp”: khối hiện tại vẫn đang trong quá trình xác nhận, trong khi khối tiếp theo đã sẵn sàng, nhiều bước đồng thời, tăng hiệu suất thông lượng.

Tóm lại, các giao thức như HotStuff đã đem lại những cải tiến đáng kể so với BFT truyền thống ở hai chiều hướng:

• Đầu tiên, việc giao tiếp trở nên nhẹ nhàng hơn, với mỗi validator chỉ cần giao tiếp với người dẫn đầu;
• Thứ hai, hiệu suất xử lý cao hơn, và nhiều quy trình xác nhận khối có thể chạy song song.

Điều này khiến HotStuff trở thành một mẫu thiết kế cho nhiều cơ chế đồng thuận blockchain PoS hiện đại. Nhưng mọi thứ đều có ưu và nhược điểm của riêng nó - trong khi cấu trúc ống dẫn mạnh mẽ về hiệu suất, nó cũng một cách im lặng giới thiệu một rủi ro cấu trúc không dễ phát hiện.

Tiếp theo, chúng tôi sẽ nghiên cứu sâu hơn vấn đề này: Tail Forking.

Vấn đề Tail-Forking ở cuối

Mặc dù HotStuff, đặc biệt là phiên bản được phân chia thành nhiều giai đoạn, giải quyết vấn đề về khả năng mở rộ của giao thức đồng thuận, nhưng cũng mang đến một số thách thức mới. Thách thức quan trọng nhất và dễ bị bỏ qua là vấn đề được gọi là vấn đề “Tail Forking”.

Một cái nền được hiểu một cách đơn giản như thế này: một chuỗi khối gặp phải một sự sắp xếp lại khối ngẫu nhiên tại 'đuôi' của chuỗi.

Cụ thể, có một khối hợp lệ, đã được truyền thành công đến phần lớn các máy chủ xác thực và đã nhận đủ số phiếu. Lý thuyết, nó nên được xác nhận và ghi vào chuỗi chính ngay lập tức. Tuy nhiên, cuối cùng, nó bị “bỏ qua,” mồ côi và bị thay thế bởi một khối mới khác cùng độ cao.

Điều này không phải là Lỗi, cũng không phải là cuộc tấn công, nhưng bởi vì trong cấu trúc thiết kế của giao thức chính nó, có khả năng của 'râu chuỗi' này. Nghe có vẻ không công bằng? Vậy, điều này xảy ra như thế nào?

Như chúng tôi đã đề cập trước đó, mỗi lãnh đạo của đường ống HotStuff có hai nhiệm vụ:

• Đề xuất một khối mới (như Bₙ₊₁)
• B. Thu thập phiếu bầu cho khối của nhà lãnh đạo trước đó để tạo ra QC (ví dụ, cuối cùng xác nhận Bₙ)

Hai nhiệm vụ này chạy song song, luân phiên truyền đạt. Nhưng vấn đề nảy sinh ở đây.

Ví dụ, giả sử Alice là người lãnh đạo, và cô ấy đề xuất khối Bn ở độ cao n, nhận được đa số phiếu bầu và "gần như được xác nhận".

Tiếp theo, đến lượt của Bob đảm nhận vai trò là người lãnh đạo, tiếp tục tiến tới khối tiếp theo Bₙ₊₁ của chuỗi, và cũng bao gồm QC (Cam kết Đủ Điều Kiện) của Bₙ trong đề xuất của mình để hoàn tất xác nhận cuối cùng của Bₙ.

Nhưng nếu Bob không trực tuyến vào thời điểm này, hoặc cố ý không gửi QC của Bₙ, thì sẽ có vấn đề.

Vì không ai đóng gói khối của Alice với QC, hồ sơ bỏ phiếu của Bₙ không được lan rộng. Khối này, mà nên đã được xác nhận, vì vậy đã được 'xử lý lạnh' và cuối cùng bị bỏ qua bởi toàn bộ mạng lưới.

Đây là bản chất của một cái nĩa đuôi: một khối từ người đứng đầu trước đó bị bỏ qua do sự cẩu thả hoặc ác ý của người đứng đầu tiếp theo.

Tại sao cái đuôi lại chia rẽ mạnh đến vậy?

Vấn đề của phân nhánh đuôi chủ yếu tập trung vào hai khía cạnh: 1) cơ chế động viên bị phá vỡ, 2) hoạt động của hệ thống bị đe dọa.

Đầu tiên, phần thưởng được nuốt chửng:

Nếu một khối bị bỏ rơi, người lãnh đạo đề xuất sẽ không nhận được bất kỳ phần thưởng nào, cả phần thưởng khối lẫn phí giao dịch. Ví dụ, nếu Alice đề xuất một khối hợp lệ và nhận được sự ủng hộ áp đảo trong cuộc bỏ phiếu, nhưng do lỗi của Bob hoặc hoạt động độc ác, khối không thể được xác nhận, Alice sẽ không nhận được bất kỳ đồng nào cuối cùng. Điều này sẽ dẫn đến cấu trúc động viên bị lỗi: các nút độc ác như Bob có thể 'cắt đứt' nguồn thưởng của họ bằng cách bỏ qua các khối của đối thủ. Hành vi này không đòi hỏi tấn công kỹ thuật, chỉ cần 'không hợp tác' cố ý để làm suy yếu lợi nhuận của đối thủ. Nếu điều này diễn ra lặp đi lặp lại, theo thời gian, sự tham gia và công bằng của toàn hệ thống sẽ giảm đi, và thậm chí gây ra sự đồng lòng giữa các nút.

Thứ hai, bề mặt tấn công MEV mở rộng:

Ngã ba đuôi cũng đặt ra một vấn đề quỷ quyệt nhưng nghiêm trọng hơn: có nhiều chỗ hơn cho MEV (Giá trị có thể trích xuất tối đa) bị thao túng một cách ác ý. Đây là một ví dụ: Giả sử Alice có một giao dịch chênh lệch giá có giá trị trong khối của mình. Nếu Bob muốn gây rắc rối, anh ta có thể thông đồng với thủ lĩnh tiếp theo, Carol, và cố tình không lan rộng khối của Alice. Carol sau đó xây dựng lại một khối mới ở cùng độ cao, "đánh cắp" giao dịch chênh lệch giá ban đầu của Alice - khiến MEV có được của riêng mình. Thực hành "sắp xếp lại đầu xích + thông đồng và chiếm đoạt" này vẫn là một khối theo quy tắc trên bề mặt, nhưng nó thực sự là một vụ cướp bóc được thiết kế tốt. Tệ hơn nữa, nó gây ra "sự thông đồng" giữa các nhà lãnh đạo, biến xác nhận khối thành một trò chơi chia sẻ lợi ích hơn là một dịch vụ công.

Thứ ba, làm suy yếu đảm bảo sự cuối cùng, ảnh hưởng đến trải nghiệm người dùng:

So với các giao thức giống Nakamoto, một lợi ích lớn của BFT là sự xác định cuối cùng: một khi một khối được cam kết, nó không thể bị quay lại. Tuy nhiên, tail fork phá vỡ sự đảm bảo này, đặc biệt là trên các khối 'đã cam kết nhưng chưa được xác nhận chính thức'. Một số ứng dụng dapps có khả năng xử lý thông lượng cao thường muốn đọc dữ liệu ngay sau khi bỏ phiếu khối để giảm độ trễ, và nếu khối bất ngờ bị loại bỏ, nó có thể gây ra trạng thái người dùng bị quay trở lại—như số dư tài khoản bất thường, các giao dịch đòn bẩy cao vừa hoàn thành biến mất không lý do, hoặc đặt lại trạng thái trò chơi đột ngột.

Thứ tư, có thể gây ra sự cố chuỗi phản ứng:

Nói chung, một cái nĩa đuôi chỉ có thể trì hoãn xác nhận một khối trong một vòng, điều này không phải là một tác động lớn. Tuy nhiên, trong một số trường hợp biên, nếu một số người dẫn đầu liên tiếp chọn bỏ qua khối trước đó, hệ thống có thể bị kẹt, và không ai muốn “đảm nhận” khối trước đó. Toàn bộ chuỗi bị kẹt cho đến khi một người dẫn đầu sẵn lòng đảm nhận cuối cùng xuất hiện, và mạng sẽ tiếp tục di chuyển về phía trước.

Mặc dù trước đây đã có một số giải pháp, như cơ chế tránh fork đuôi được đề xuất bởi giao thức BeeGees, nhưng thường đòi hỏi hy sinh hiệu suất, chẳng hạn như việc giới thiệu lại sự phức tạp trong giao tiếp phụ, điều đó không xứng đáng với sự mất mát.

MonadBFT là gì?

MonadBFT là một giao thức đồng thuận thế hệ mới được thiết kế đặc biệt để giải quyết vấn đề tail fork. Sức mạnh của nó nằm ở việc: trong khi giải quyết những lỗ hổng cấu trúc, nó không hy sinh những lợi ích về hiệu suất mang lại bởi đường ống HotStuff. Nói cách khác, MonadBFT không bắt đầu từ đầu, mà tiếp tục tối ưu hóa dựa trên khung cơ bản của HotStuff. Nó giữ ba đặc điểm chính:

1) Lãnh đạo xoay vòng: Chọn một lãnh đạo mới cho mỗi vòng để đẩy chuỗi tiến lên;
2) Pipelined commits: Quá trình xác nhận khởi nhiệm một lúchat có thể chỗ;
3) Giao tiếp tuyến tính (tin nhắn tuyến tính): Mỗi bộ xác minh chỉ cần giao tiếp với người dẫn đầu, tiết kiệm rất nhiều tải trên mạng.

Nhưng chỉ dựa vào ba điểm này không đủ an toàn. Để khắc phục điểm yếu cấu trúc của đuôi nghịch, MonadBFT đã thêm vào hai cơ chế chính:

1) Cơ chế đề xuất lại bắt buộc (Đề xuất lại)
2) Chứng chỉ không bảo lãnh (NEC)

Cơ chế Đề xuất lại

Trong giao thức BFT, thời gian được chia thành các vòng (được gọi là views), với một người lãnh đạo trong mỗi vòng chịu trách nhiệm đề xuất một khối mới. Nếu người lãnh đạo thất bại (ví dụ, không đề xuất một khối đúng thời gian hoặc với đề xuất không hợp lệ), hệ thống chuyển sang vòng tiếp theo và chọn một người lãnh đạo mới.

MonadBFT đã thêm một cơ chế để đảm bảo rằng bất kỳ khối được đề xuất một cách trung thực nào trong quá trình chuyển đổi quan điểm sẽ không 'rơi khỏi chuỗi' do việc quay vòng lãnh đạo.

Khi nhà lãnh đạo hiện tại thất bại, các nhà xác thực sẽ gửi một tin nhắn đã ký để chuyển vòng (thay đổi quan điểm), cho biết rằng vòng hiện tại đã hết giờ.

Đặc biệt, tin nhắn này không chỉ cho biết ‘hết thời gian chờ’, mà còn phải bao gồm thông tin khối về phiếu bầu gần đây của người xác thực, tương đương với việc nói, ‘Tôi không nhận được một đề xuất hợp lệ, đây là khối mới nhất mà tôi đang nhìn thấy.’

Vòng lãnh đạo mới sẽ thu thập những tin nhắn hết thời gian này từ các nhà xác thực đa số (2f+1) và hợp nhất chúng vào Chứng chỉ Hết thời gian (TC). TC này đại diện cho bản chụp tinh thần thống nhất của 'khối đầu chuỗi' của toàn bộ mạng khi vòng trước thất bại. Lãnh đạo mới sẽ chọn khối có chiều cao cao nhất (hoặc số view mới nhất), được biết đến là đỉnh cao, từ đó.

MonadBFT yêu cầu: Đề xuất của một nhà lãnh đạo mới phải bao gồm một TC hợp lệ và phải đề xuất lại khối đang chờ cao nhất trong TC để cung cấp cơ hội cho khối này được xác nhận một lần nữa.

Tại sao? Như đã đề cập trước đó: chúng tôi không muốn một khối gần như được xác nhận mất đi.

Ví dụ, giả sử Alice là người đứng đầu của quan điểm 5, đề xuất một khối hợp lệ và nhận được đa số phiếu bầu. Tiếp theo, khi người đứng đầu quan điểm 6, Bob, không hoạt động và không thể tiến hành quá trình chuỗi, đến lúc Carol tiếp quản là người đứng đầu quan điểm 7, theo quy tắc của MonadBFT, cô ấy phải bao gồm TC và đề xuất lại khối của Alice. Theo cách này, công việc trung thực của Alice sẽ không phí công.

Nếu Carol không có khối của Alice, cô ấy có thể yêu cầu nó từ các nút khác. Các nút có thể:

• Cung cấp khối, hoặc
• Trả về một thông điệp đã ký 'Không ủng hộ (NE)', chỉ ra rằng người gửi không có khối này (cơ chế của nó sẽ được giải thích sau này). (Đến f nút Byzantine có thể chọn bỏ qua yêu cầu và không phản hồi).

Một khi Carol đề xuất lại khối của Alice, cô ấy sẽ có cơ hội đề xuất bổ sung để đảm bảo rằng cô ấy không 'liên lụy' do sự cố của người đứng đầu trước đó.

Vai trò của cơ chế đề xuất lại này rõ ràng: đảm bảo rằng sự tiến bộ của chuỗi là công bằng, và không có công việc hợp lệ nào bị lãng phí một cách im lặng do xui xẻo hoặc phá hoại của ai đó.

Chứng chỉ không thể chuyển nhượng (NEC)

Tiếp tục với ví dụ trước: Sau khi lượt chơi của Bob hết giờ, Carol yêu cầu các nhà xác minh khác cung cấp khối cao nhất (tức là khối của Alice). Tại thời điểm này, ít nhất 2f+1 nhà xác minh sẽ phản hồi:

• Hoặc cung cấp các khối của Alice
• Gửi thông điệp NE đã được ký cho biết rằng bạn không nhận được khối của Alice.

Miễn là Carol nhận được block của Alice, cô ấy phải đề xuất lại theo quy tắc. Carol chỉ có thể bỏ qua block và đề xuất một block mới khi ít nhất f+1 validators đã ký vào thông điệp NE.

Tại sao f+1? Trong một hệ thống BFT gồm 3f+1 người xác nhận, tối đa chỉ có f có thể là độc hại. Nếu khối của Alice thực sự nhận được đa số phiếu bầu, thì ít nhất 2f+1 nút trung thực đã nhận được nó.

Do đó, nếu Carol khẳng định, “Tôi không thể nhận block của Alice,” cô ấy phải sản xuất f+1 chữ ký của validator để chứng minh rằng không ai trong số họ đã nhận được nó. Điều này cấu thành một Giấy chứng nhận Không Ủng hộ (NEC).

NEC là chứng chỉ "tuyên bố từ chối trách nhiệm" của một nhà lãnh đạo: đó là bằng chứng có thể kiểm chứng được rằng việc cấm trước đó chưa sẵn sàng để được xác nhận, không phải bị bỏ qua một cách ác ý, mà bị "bỏ rơi" với lý do.

Đề xuất lại + Chứng chỉ không được chứng nhận = Giải quyết cái nhi đuôi

MonadBFT giới thiệu một bộ quy tắc xử lý block chain nghiêm ngặt và rõ ràng bằng cách giới thiệu cơ chế đề xuất lại và Chứng chỉ Không Tán Thành (NEC).

Hoặc cuối cùng cam kết với khối 'gần như được xác nhận';

Hoặc cung cấp đủ bằng chứng để chứng minh rằng khối chưa sẵn sàng được xác nhận,

Nếu không, không được phép bỏ qua hoặc thay thế khối trước đó.

Cơ chế này đảm bảo rằng bất kỳ khối nào đã nhận được đa số phiếu bầu hợp pháp sẽ không bị bỏ qua do lỗi của nhà lãnh đạo hoặc tránh được cố ý.

Các rủi ro cấu trúc của cái đuôi nghêu đã được giải quyết một cách có hệ thống, và giao thức có thể rõ ràng hạn chế hành vi bỏ qua không đúng.

Nếu một nhà lãnh đạo cố gắng bỏ qua khối trước mà không cung cấp bằng chứng NEC, giao thức sẽ ngay lập tức nhận ra và từ chối hành vi đó. Hành vi nhảy mà không có bằng chứng mật mã sẽ được coi là bất hợp pháp và sẽ không nhận được sự ủng hộ của sự đồng thuận mạng.

Từ góc độ động viên kinh tế, thiết kế này cung cấp sự bảo vệ rõ ràng cho các nhà xác nhận:

• Miễn là khối được đề xuất một cách trung thực và nhận được sự ủng hộ bằng cách bỏ phiếu, thì phần thưởng của nó sẽ không bị tước do các sự cố sau này.
• Ngay cả trong những tình huống cực đoan, như khi một nút cố ý bỏ qua vòng đề xuất của mình và cố gắng hỗ trợ người khác trong việc chiếm lợi MEV từ khối trước đó, giao thức sẽ buộc người dẫn đầu tiếp theo ưu tiên đề xuất lại khối gốc, ngăn chặn kẻ tấn công từ việc thu được lợi ích kinh tế bằng cách bỏ qua quá trình.

Quan trọng hơn, MonadBFT không hy sinh hiệu suất giao thức để tăng cường bảo mật.

Một số thiết kế giải quyết vấn đề tail forks (như giao thức BeeGees) trong quá khứ có một số khả năng bảo vệ nhất định, nhưng thường phụ thuộc vào độ phức tạp trong giao tiếp cao (n²) hoặc cho phép quá trình giao tiếp nặng nề trong mỗi vòng, điều này tăng đáng kể gánh nặng hệ thống trong thực tế.

Chiến lược thiết kế của MonadBFT tinh vi hơn:

Thông điệp bổ sung (như thông báo timeout, đề xuất lại khối) chỉ được khởi tạo khi quan điểm thất bại hoặc tồn tại các bất thường. Trên con đường thông thường nơi mà hầu hết các nhà lãnh đạo trung thực liên tục tạo ra các khối, giao thức vẫn duy trì trạng thái hoạt động nhẹ và hiệu quả.

Sự cân bằng động giữa hiệu suất và bảo mật chính là một trong những lợi thế cốt lõi của MonadBFT so với các giao thức tiền nhiệm của nó.

Tóm tắt

Bài viết này đánh giá cơ chế cơ bản của sự đồng thuận truyền thống PBFT, sắp xếp con đường phát triển của giao thức HotStuff, và tập trung vào cách mà MonadBFT giải quyết vấn đề cắt đuôi bẩm sinh của đường ống HotStuff tại cấu trúc lớp giao thức.

Các cánh sau có thể làm biến dạng các động cơ kinh tế của người đề xuất khối và tạo ra mối đe dọa tiềm năng đối với hoạt động mạng lưới. MonadBFT đảm bảo rằng bất kỳ khối nào được đề xuất bởi các nhà lãnh đạo trung thực và được thông qua bằng cách bỏ phiếu đa số theo quy định sẽ không bị bỏ qua hoặc bỏ qua bằng cách giới thiệu cơ chế đề xuất lại và Chứng chỉ Không được Đề xuất (NEC).

Trong bài viết tiếp theo, chúng tôi sẽ tiếp tục khám phá hai tính năng cốt lõi khác của MonadBFT:

1) Sự Chấp Nhận Rủi Ro Cuối Cùng
2）Tích cực Đáp ứng

Phân tích sâu hơn về những cơ chế này và ý nghĩa thực tế của chúng đối với người xác thực và nhà phát triển.

Tuyên bố:

1. Bài viết này được in lại từ [michael_lwy], bản quyền thuộc về tác giả gốc [michael_lwy]，nếu bạn có bất kỳ ý kiến ​​nào về việc sao chép, vui lòng liên hệ Gate Learn Team)，đội ngũ sẽ xử lý càng sớm càng tốt theo quy trình liên quan.
2. Tuyên bố miễn trách nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ là của tác giả và không hề đại diện cho bất kỳ lời khuyên đầu tư nào.
3. Các phiên bản ngôn ngữ khác của bài viết được dịch bởi nhóm Gate Learn, mà không đề cập đếnGateKhông sao chép, phân phối hoặc sao chép bài viết dịch mà không có sự cho phép.