Cốt lõi của blockchain là đạt được sự đồng thuận toàn cầu nghiêm ngặt: nghĩa là, bất kể nút mạng được phân bổ ở quốc gia hay múi giờ nào, tất cả những người tham gia cuối cùng phải đạt được sự đồng thuận về một tập hợp các kết quả khách quan.
Nhưng mạng phân tán trên thực tế không lý tưởng: một số nút ngoại tuyến, một số nút nói dối và một số người thậm chí còn cố tình phá hoại. Trong trường hợp này, làm thế nào để hệ thống duy trì được tính nhất quán?
Đây chính là vấn đề mà giao thức đồng thuận có thể giải quyết. Về cơ bản, đây là một tập hợp các quy tắc hướng dẫn một nhóm nút độc lập và thậm chí không đáng tin cậy về cách đạt được sự đồng thuận về thứ tự và nội dung của mỗi giao dịch.
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 quan trọng, chẳng hạn như bảo vệ quyền sở hữu kỹ thuật số, mô hình tiền tệ chống lạm phát và cấu trúc cộng tác xã hội mở rộng. Nhưng tiền đề là bản thân giao thức đồng thuận phải đảm bảo hai nguyên tắc cơ bản cùng một lúc:
- Không thể xác nhận hai khối xung đột;
- Mạng phải tiếp tục di chuyển về phía trước và không thể bị kẹt hoặc dừng lại.
MonadBFT là bước đột phá công nghệ mới nhất theo hướng này.
Một đánh giá ngắn gọn về sự phát triển của các giao thức đồng thuận
Lĩnh vực cơ chế đồng thuận thực tế đã được nghiên cứu trong nhiều thập kỷ. Nhóm giao thức đầu tiên, chẳng hạn như PBFT (Practical Byzantine Fault Tolerance), có thể xử lý được một tình huống rất thực tế: ngay cả khi một số nút trong mạng bị lỗi, có hành vi ác ý hoặc nói những điều vô nghĩa, miễn là chúng không vượt quá 1/3 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 tương đối "truyền thống": một người lãnh đạo được bầu ở mỗi vòng, người này sẽ khởi xướng Đề án và những người xác thực khác sẽ bỏ phiếu cho Đề án đó trong nhiều vòng để xác nhận từng bước lệnh giao dịch.
Toàn bộ quá trình bỏ phiếu thường trải qua nhiều giai đoạn như chuẩn bị trước, chuẩn bị, cam kết và trả lời. Ở mỗi giai đoạn, tất cả các trình xác thực đều giao tiếp với nhau. Nói cách khác, mọi người đều phải chia sẻ với nhau và lượng thông tin tăng trưởng một cách bùng nổ theo cách "giống như mạng lưới".
Độ phức tạp của cấu trúc truyền thông này là n² - nghĩa là, nếu có 100 trình xác thực trong mạng, mỗi vòng đồng thuận có thể yêu cầu truyền gần 10.000 tin nhắn.
Đây không phải là vấn đề lớn trong một mạng nhỏ, nhưng khi số lượng trình xác thực tăng lên, gánh nặng truyền thông của hệ thống sẽ nhanh chóng trở nên không thể chịu đựng được và hiệu quả sẽ bị giảm trực tiếp.
Cấu trúc giao tiếp lần này "mọi người phải giao tiếp với mọi người" thực sự rất kém hiệu quả. Ví dụ, trong một mạng lưới có 100 trình xác thực, mỗi vòng đồng thuận có thể phải xử lý hàng chục nghìn tin nhắn.
Điều này có thể quản lý được trong phạm vi nhỏ, nhưng nếu đặt trong mạng lưới Chuỗi mở toàn cầu, tải trọng truyền thông sẽ ngay lập tức trở nên không thể chấp nhận được. Do đó, các giao thức BFT ban đầu như PBFT và Tendermint thường chỉ được sử dụng trong các mạng hoặc hệ thống được cấp phép với số lượng trình xác thực nhỏ và hầu như không thể chạy được.
Để giao thức BFT thích ứng với hoàn cảnh chuỗi công khai không cần cấp phép, một số thiết kế thế hệ mới đang bắt đầu chuyển sang phương thức giao tiếp nhẹ nhàng hơn: để mỗi trình xác thực chỉ giao tiếp với người đứng đầu, thay vì tất cả các thành viên giao tiếp với nhau.
Điều này tối ưu hóa độ phức tạp của tin nhắn từ n² đến n, giúp giảm đáng kể gánh nặng cho hệ thống.
Giao thức HotStuff được đề xuất vào năm 2018 để giải quyết vấn đề mở rộng này. Khái niệm 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 một cấu trúc truyền thông đơn giản hơn do người lãnh đạo điều hành.
Tính năng chính của HotStuff là cái gọi là giao tiếp tuyến tính. Trong cơ chế này, mỗi người xác thực chỉ cần gửi phiếu bầu của mình cho người lãnh đạo hiện tại, sau đó người lãnh đạo sẽ đóng gói các phiếu bầu này và tạo ra Giấy chứng nhận đủ số phiếu (QC, giấy chứng nhận đa số hợp pháp).
QC này về cơ bản là chữ ký tập thể chứng minh với toàn bộ mạng lưới: "Phần lớn nút đều đồng ý với Đề án này."
Ngược lại, chế độ giao tiếp của PBFT là "phát sóng tới tất cả các thành viên", trong đó mọi người trong nhóm đều nói chuyện và bối cảnh trước đây rất hỗn loạn. Mô hình của HotStuff giống như "một người thu thập, một gói hàng", cho phép duy trì hoạt động hiệu quả bất kể có bao nhiêu người trên mạng.
Ngoài giao tiếp tuyến tính, HotStuff có thể được nâng cấp thêm lên phiên bản đường ống (pipelined HotStuff) để cải thiện hiệu quả.
Trong HotStuff gốc, cùng một trình xác thực sẽ đóng vai trò là người dẫn đầu trong nhiều vòng cho đến khi khối được xác nhận đầy đủ. Quá trình này diễn ra "một khối mỗi vòng" và toàn bộ năng lượng tập trung vào việc phát triển khối hiện tại.
Trong quy trình HotStuff, cơ chế này linh hoạt hơn: một người lãnh đạo mới được chọn trong mỗi vòng và mỗi người lãnh đạo có hai nhiệm vụ:
- Một mặt, các phiếu bầu của vòng trước được đóng gói thành Giấy chứng nhận đủ số phiếu (QC) và phát sóng tới toàn bộ mạng lưới;
- Khi đề xuất một khối mới, hãy chuẩn bị bắt đầu vòng tiếp theo.
Nói cách khác, không còn tình trạng "xác nhận cái này trước khi xử lý cái tiếp theo" nữa mà giống như dây chuyền sản xuất, các trưởng nhóm khác nhau sẽ thay phiên nhau chịu trách nhiệm cho từng khâu. 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 Chuỗi được truyền đi như một cuộc đua tiếp sức.
Đây chính là nguồn gốc của ẩ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 và khối tiếp theo đã được chuẩn bị, với nhiều bước diễn ra song song để cải thiện hiệu quả thông lượng.
Tóm lại, các giao thức như HotStuff đã có những cải tiến đáng kể ở hai chiều so với BFT truyền thống:
- Đầu tiên, việc giao tiếp nhẹ nhàng hơn và mỗi người xác thực chỉ cần giao tiếp với người lãnh đạo;
- Thứ hai, hiệu quả xử lý cao hơn và nhiều quy trình xác nhận khối có thể được thực hiện song song.
Điều này khiến HotStuff trở thành 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 - mặc dù cấu trúc dây chuyền lắp ráp có hiệu suất mạnh mẽ, nhưng nó cũng âm thầm phát sinh rủi ro về cấu trúc mà không dễ phát hiện.
Tiếp theo, chúng ta sẽ nói sâu hơn về vấn đề cốt lõi này: Tail Fork.
Đuôi - Fork
Mặc dù HotStuff — đặc biệt là phiên bản theo đường ống — giải quyết được vấn đề mở rộng của các giao thức đồng thuận, nhưng nó cũng mang đến một số thách thức mới. Trong đó quan trọng nhất và dễ bị bỏ qua nhất là vấn đề được gọi là "Tail Fork".
Fork đuôi là gì? Có thể hiểu đơn giản là: blockchain đã trải qua quá trình tổ chức lại khối (reorg) bất ngờ ở "cuối Chuỗi".
Cụ thể hơn, có một khối hợp lệ, đã được truyền đạt thành công đến phần lớn người xác thực và nhận được đủ số phiếu ủng hộ. Về mặt logic, thông tin này sẽ sớm được xác nhận và ghi vào Chuỗi chính. Nhưng cuối cùng, nó đã bị "bỏ qua" và loại bỏ (bị mồ côi), và thay thế bằng một khối mới khác ở cùng độ cao.
Đây không phải là lỗi hay cuộc tấn công, mà là do cấu trúc thiết kế của chính giao thức tạo ra khả năng "bỏ Chuỗi". Nghe có vẻ hơi bất công phải không? Vậy, chuyện này xảy ra như thế nào?
Như chúng tôi đã nói trước đây, mỗi người đứng đầu đường ống HotStuff có hai nhiệm vụ:
- A. Đề xuất một khối mới (như Bₙ₊₁)
- B. Thu thập phiếu bầu cho khối của người lãnh đạo trước đó và tạo QC (ví dụ: hoàn tất xác nhận cuối cùng cho Bₙ)
Hai nhiệm vụ này được thực hiện song song và luân phiên nhau. Nhưng đó chính là vấn đề.
Ví dụ: Giả sử Alice là người dẫn đầu và cô ấy đề xuất khối Bₙ ở độ cao n. Khối này đã nhận được số phiếu bầu đa số áp đảo và “gần như được xác nhận”. Tiếp theo, Bob sẽ dẫn đầu và tiếp tục tiến tới khối tiếp theo của Chuỗi, Bₙ₊₁. Đồng thời, anh ta cũng nên đưa QC (bằng chứng đa số hợp pháp) của Bₙ vào Đề án của mình để hoàn tất việc xác nhận cuối cùng của Bₙ.
Nhưng nếu Bob ngoại tuyến vào thời điểm này hoặc cố tình không gửi QC của Bₙ thì sẽ có vấn đề.
Vì không có ai hoàn thành việc đóng gói QC cho khối của Alice nên hồ sơ bỏ phiếu của Bₙ không thể được truyền bá. Khối này, đáng lẽ phải được xác nhận, đã bị “xử lý lạnh” và cuối cùng bị toàn bộ mạng lưới bỏ qua.
Đây chính là bản chất của một fork đuôi: khối của người dẫn đầu trước đó bị bỏ qua do sự bất cẩn hoặc ác ý của người dẫn đầu tiếp theo.
Tại sao tình trạng đuôi fork lại nghiêm trọng ?
Các vấn đề với fork đuôi chủ yếu tập trung vào hai khía cạnh: 1) cơ chế khích lệ bị phá hủy và 2) hoạt động của hệ thống bị đe dọa.
Đầu tiên, phần thưởng sẽ bị nuốt: Nếu một khối bị bỏ rơi, người đứng đầu đề xuất sẽ không nhận được bất kỳ phần thưởng nào. Cho dù đó là phần thưởng khối hay phí giao dịch. Ví dụ, Alice đã đề xuất một lệnh cấm hợp pháp và nhận được đa số phiếu bầu. Tuy nhiên, do lỗi hoặc hành vi cố ý của Bob nên lệnh chặn không thể được xác nhận và cuối cùng Alice không nhận được một xu nào. Điều này sẽ dẫn đến một cấu trúc khích lệ sai: nút độc hại như Bob có thể "cắt" nguồn phần thưởng của chúng bằng cách bỏ qua các khối của đối thủ. Hành vi này không đòi hỏi phải tấn công về mặt kỹ thuật mà chỉ cần cố tình “không hợp tác” để làm suy yếu lợi nhuận của đối thủ cạnh tranh. Nếu điều này xảy ra nhiều lần theo thời gian, sự tham gia và tính công bằng của toàn bộ hệ thống sẽ giảm và thậm chí có thể dẫn đến sự thông đồng giữa nút.
Thứ hai, không gian tấn công MEV mở rộng: Fork xe cũng sẽ mang đến một vấn đề tiềm ẩn nhưng nghiêm trọng hơn: không gian để MEV (giá trị rút tối đa) bị thao túng một cách ác ý đã tăng lên. Ví dụ: giả sử có một giao dịch chênh lệch giá rất có giá trị trong khối của Alice. 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 là Carol và cố tình không truyền bá sự ngăn cản của Alice. Sau đó, Carol xây dựng lại một khối mới ở cùng độ cao và "sao chép" giao dịch chênh lệch giá ban đầu của Alice, biến lợi nhuận MEV thành của riêng mình. Thực tiễn “sắp xếp lại đầu Chuỗi+ thông đồng và biển thủ” này có vẻ như tuân thủ theo quy định, nhưng thực chất đây là hành vi cướp bóc được lên kế hoạch cẩn thận. Tệ hơn, nó sẽ gây ra sự “thông đồng” giữa các nhà lãnh đạo, biến việc xác nhận khối thành trò chơi phân phối lợi nhuận thay vì là một dịch vụ công.
Thứ ba, nó làm suy yếu tính đảm bảo tính cuối cùng và ảnh hưởng đến trải nghiệm của người dùng: So với các giao thức kiểu Nakamoto, một lợi thế lớn của BFT là tính cuối cùng mang tính xác định: một khi một khối đã được gửi đi, nó không thể được khôi phục lại. Nhưng fork đuôi làm suy yếu sự đảm bảo này, đặc biệt là đối với các khối đã được bỏ phiếu nhưng chưa được xác nhận chính thức. Một số dapp có thông lượng cao thường hy vọng có thể đọc dữ liệu ngay sau khi bỏ phiếu khối được thông qua để giảm độ trễ. Nếu khối đột nhiên bị loại bỏ, trạng thái của người dùng có thể bị đảo ngược - ví dụ, số dư tài khoản bất thường, giao dịch đòn bẩy cao vừa hoàn tất biến mất, trạng thái trò chơi đột ngột bị đặt lại, v.v.
Thứ tư, nó có thể gây ra phản ứng dây chuyền thất bại: Nói chung, một fork đuôi chỉ có thể khiến một khối được xác nhận sau một vòng, điều này không có tác động lớn. Nhưng trong một số kịch bả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ể trở nên trì trệ và không ai muốn "tiếp quản" khối trước đó. Sự tiến triển của toàn bộ Chuỗi sẽ bị đình trệ cho đến khi một nhà lãnh đạo "sẵn sàng chịu trách nhiệm" xuất hiện, và mạng lưới sẽ tiếp tục tiến về phía trước.
Mặc dù đã có một số giải pháp trước đây, chẳng hạn như cơ chế tránh fork do giao thức BeeGees đề xuất, nhưng chúng thường đòi hỏi phải hy sinh hiệu suất, chẳng hạn như phải đưa lại sự phức tạp của giao tiếp lần, điều này không đáng giá.
MonadBFT là gì ?
MonadBFT là giao thức đồng thuận thế hệ mới được thiết kế riêng để giải quyết vấn đề tail fork. Điểm mạnh của nó nằm ở chỗ: trong khi giải quyết các rủi ro về cấu trúc, nó không làm mất đi những lợi thế về hiệu suất mà đường ống HotStuff mang lại. Nói cách khác, MonadBFT không phải là một bản đại tu hoàn chỉnh mà vẫn tiếp tục tối ưu hóa dựa trên khuôn khổ cốt lõi của HotStuff. Nó vẫn giữ lại ba đặc tính chính:
- Người lãnh đạo luân phiên: Một người lãnh đạo mới được chọn trong mỗi vòng để thúc đẩy Chuỗi;
- Cam kết theo đường ống: nhiều quy trình xác nhận khối có thể chồng chéo nhau;
- Nhắn tin tuyến tính: Mỗi người xác thực chỉ cần giao tiếp với người đứng đầu, giúp tiết kiệm lượng lớn chi phí mạng.
Nhưng chỉ ba điểm này thôi thì không đủ an toàn. Để lấp lỗ hổng cấu trúc của phuộc đuôi, MonadBFT bổ sung hai cơ chế chính:
- Cơ chế đề xuất lại bắt buộc
- Giấy chứng nhận không xác nhận (NEC)
Đề xuất lại
Trong giao thức BFT, thời gian được chia thành lần(gọi là lượt xem) và mỗi lần có một người đứng đầu chịu trách nhiệm đề xuất các khối mới. Nếu người dẫn đầu thất bại (ví dụ, không đề xuất chặn đúng hạn hoặc Đề án không hợp lệ), hệ thống sẽ chuyển sang vòng tiếp theo và bầu một người dẫn đầu mới.
MonadBFT bổ sung một cơ chế để đảm bảo rằng trong quá trình chuyển đổi chế độ xem, bất kỳ khối nào được đề xuất một cách trung thực sẽ không bị "loại bỏ" do sự xoay vòng của người dẫn đầu.
Khi người dẫn đầu vòng hiện tại không thành công, trình xác thực sẽ gửi tin nhắn chuyển đổi lần đã ký (thay đổi chế độ xem) để thông báo rằng lần hiện tại đã hết thời gian.
Điều đặc biệt là thông báo này không chỉ có nghĩa là “hết thời gian” mà còn phải chứa thông tin khối của phiếu bầu gần đây nhất của người xác thực, tương đương với việc nói rằng: “Tôi không nhận được Đề án hợp lệ, đây là khối mới nhất mà tôi thấy cho đến nay”.
Người dẫn đầu vòng mới sẽ thu thập các thông báo hết thời gian chờ này từ những người xác thực đa số (2f+1) và hợp nhất chúng thành một Chứng chỉ hết thời gian chờ (TC). TC này biểu thị: khi lần trước thất bại, toàn bộ ảnh chụp nhận thức thống nhất của "khối đầu Chuỗi" trong mạng. Người lãnh đạo mới sẽ chọn khối có chiều cao cao nhất (hoặc số lượt xem mới nhất), được gọi là high_tip.
MonadBFT yêu cầu Đề án của người lãnh đạo mới phải chứa TC hợp lệ và phải đề xuất lại khối đang chờ xử lý cao nhất trong TC để khối này có thêm cơ hội được xác nhận.
Tại sao? Như đã đề cập trước đó: chúng tôi không muốn một khối sắp được xác nhận lại biến mất.
Ví dụ: giả sử Alice là người đứng đầu nhóm 5, đề xuất một khối hợp lệ và nhận được số phiếu bầu đa số. Tiếp theo, người đứng đầu nhóm 6, Bob, đã ngoại tuyến và không thể tiếp tục Chuỗi. Khi Carol trở thành người dẫn đầu lượt xem thứ 7, theo quy tắc của MonadBFT, cô ấy phải đưa TC vào và đề xuất lại khối của Alice. Bằng cách này, công sức chân chính của Alice sẽ không trở nên vô ích.
Nếu Carol không có khối của Alice, cô ấy có thể yêu cầu nó từ nút khác. Nút có thể:
- Cung cấp khối, hoặc
- Trả về tin nhắn "Không xác nhận" (NE) đã ký, cho biết tin nhắn không có khối này (cơ chế này sẽ được giới thiệu sau). (Nhiều nhất f nút Byzantine có thể chọn bỏ qua yêu cầu và không phản hồi.)
Khi Carol đề xuất lại khối của Alice, cô ấy sẽ có thêm một cơ hội Đề án để đảm bảo rằng cô ấy sẽ không bị "trừng phạt" vì người dẫn đầu đã thất bại ở vòng trước.
Mục đích của cơ chế đề xuất lại này rất rõ ràng: để đảm bảo Chuỗi tiến triển công bằng và mọi công việc hợp lệ không bị loại bỏ một cách lặng lẽ do vận rủi hoặc phá hoại.
Không có Giấy chứng nhận xác nhận (NEC )
Tiếp tục với ví dụ trước: sau khi vòng của Bob hết lần, Carol yêu cầu những người xác thực khác cung cấp khối high_tip (tức là khối của Alice). Tại thời điểm này, ít nhất 2f+1 trình xác thực sẽ phản hồi:
- Hoặc cung cấp khối của Alice
- Hoặc gửi một tin nhắn NE đã ký để cho biết rằng bạn chưa nhận được khối của Alice
Ngay khi Carol nhận được khối của Alice, cô ấy phải đề xuất lại theo đúng quy tắc. Chỉ khi có ít nhất f+1 người xác thực đã ký vào tin nhắn NE thì Carol mới có thể bỏ qua khối và đề xuất khối mới.
Tại sao lại là f+1? Trong hệ thống BFT bao gồm 3f+1 trình xác thực, nhiều nhất chỉ có f trình xác thực có thể hoạt động có hại. Nếu khối của Alice nhận được số phiếu bầu đa số tuyệt đối thì ít nhất 2f+1 nút trung thực đã nhận được nó.
Do đó, nếu Carol tuyên bố "Tôi không thể lấy được khối của Alice", cô ấy phải cung cấp chữ ký của người xác thực f+1 để chứng minh rằng không ai trong số họ nhận được nó. Đây chính là Giấy chứng nhận không xác nhận (NEC).
NEC là giấy chứng nhận “miễn tội” của người đứng đầu: đó là bằng chứng có thể kiểm chứng được rằng khối trước đó chưa sẵn sàng để xác nhận, và nó không bị bỏ qua một cách cố ý, mà bị “bỏ rơi” có lý do và cơ sở.
Đề xuất lại + không có giấy chứng nhận xác nhận = sửa fork
MonadBFT thiết lập một bộ quy tắc xử lý đầu Chuỗi rõ ràng và nghiêm ngặt bằng cách giới thiệu cơ chế đề xuất lại và chứng chỉ không xác nhận (NEC):
Hoàn tất việc gửi cuối cùng cho khối "sắp được xác nhận"; hoặc cung cấp đủ bằng chứng để chứng minh rằng khối đó không đáp ứng các điều kiện xác nhận. Nếu không, việc bỏ qua hoặc thay thế khối trước đó sẽ không được phép.
Cơ chế này đảm bảo rằng bất kỳ khối nào đạt được số phiếu bầu đa số sẽ không bị hủy bỏ do lỗi của người lãnh đạo hoặc cố tình lách luật. Các rủi ro về cấu trúc của fork đuôi được giải quyết một cách có hệ thống và giao thức có thể áp dụng những hạn chế rõ ràng đối với hành vi bỏ qua không đúng cách.
Nếu một người đứng đầu cố gắng bỏ qua một khối trước đó mà không có lý do nhưng không cung cấp bằng chứng NEC, giao thức sẽ ngay lập tức xác định và từ chối hành động đó. Bất kỳ hành động nào không có bằng chứng crypto đều bị coi là bất hợp pháp và sẽ không được sự đồng thuận của mạng lưới hỗ trợ.
Theo quan điểm khích lệ kinh tế, thiết kế này cung cấp sự bảo vệ rõ ràng cho người xác thực:
- Miễn là khối được đề xuất và bỏ phiếu một cách trung thực, phần thưởng của khối đó sẽ không bị mất do các lỗi liên kết sau đó;
- Ngay cả trong những tình huống cực đoan, chẳng hạn như khi một nút cố tình bỏ qua lần Đề án của chính mình để hỗ trợ những nút khác chiếm lấy MEV của khối trước đó, giao thức sẽ buộc nút dẫn đầu tiếp theo phải ưu tiên đề xuất lại khối ban đầu, khiến kẻ tấn công không thể đạt được lợi nhuận kinh tế bằng cách bỏ qua quy trình.
Quan trọng hơn, MonadBFT không hy sinh hiệu suất giao thức để cải thiện tính bảo mật.
Một số thiết kế trước đây cho fork máy bay (như giao thức BeeGees) có một số khả năng bảo vệ nhất định, nhưng chúng thường dựa vào độ phức tạp của giao tiếp cao (n²) hoặc cho phép các quy trình giao tiếp nặng nề trong mỗi vòng, điều này sẽ làm tăng đáng kể gánh nặng của hệ thống trong thực tế.
Chiến lược thiết kế của MonadBFT phức tạp hơn:
Giao tiếp bổ sung (ví dụ: thông báo hết thời gian, đề xuất chặn lại) chỉ được khởi tạo nếu chế độ xem không thành công hoặc có ngoại lệ. Trên con đường thông thường mà hầu hết những người lãnh đạo trung thực liên tục tạo ra các khối, giao thức vẫn nhẹ và hiệu quả.
Sự cân bằng động giữa hiệu suất và bảo mật là một trong những lợi thế cốt lõi của MonadBFT so với các giao thức thế hệ trước.
Phần kết luận
Bài viết này xem xét cơ chế cơ bản của sự đồng thuận PBFT truyền thống, sắp xếp lộ trình phát triển của giao thức HotStuff và tập trung vào cách MonadBFT giải quyết vấn đề fork đuôi nội sinh của đường ống HotStuff từ cấu trúc lớp giao thức.
Fork đuôi làm biến dạng khích lệ kinh tế của những người đề xuất khối và gây ra mối đe dọa tiềm tàng đến sự sống động của mạng lưới. MonadBFT đảm bảo rằng bất kỳ khối nào do một nhà lãnh đạo trung thực đề xuất và được bỏ phiếu đủ số phiếu sẽ không bị hủy bỏ hoặc bỏ qua bằng cách đưa ra cơ chế đề xuất lại và giấy chứng nhận không xác nhận (NEC).
Trong bài viết tiếp theo, chúng ta sẽ tiếp tục khám phá hai tính năng cốt lõi khác của MonadBFT:
- Sự kết thúc suy đoán
- Phản ứng lạc quan
Và phân tích sâu hơn ý nghĩa thực tiễn của các cơ chế này đối với người xác thực và nhà phát triển.
Còn tiếp.
