MonadBFT: Định nghĩa lại an toàn đồng thuận blockchain, tạm biệt rủi ro phân nhánh đuôi
Tuyển chọn TechFlowTuyển chọn TechFlow
MonadBFT: Định nghĩa lại an toàn đồng thuận blockchain, tạm biệt rủi ro phân nhánh đuôi
MonadBFT là giao thức đồng thuận thế hệ mới được thiết kế đặc biệt để giải quyết vấn đề phân nhánh cuối.
Chuyên sâu báo cáo Web3Tác giả: michaellwy
Trọng tâm của blockchain là đạt được một sự đồng thuận toàn cầu nghiêm ngặt (strict global consensus): nghĩa là, bất kể các nút mạng nằm ở quốc gia hay múi giờ nào, tất cả người tham gia cuối cùng đều phải thống nhất về một tập kết quả khách quan.
Nhưng trong thực tế, mạng phân tán không lý tưởng: có nút bị ngắt kết nối, có nút nói dối, thậm chí có người cố tình phá hoại. Trong trường hợp này, hệ thống làm thế nào để "đồng thanh nhất trí", duy trì sự nhất quán?
Đây chính là vấn đề mà giao thức đồng thuận cần giải quyết. Về bản chất, nó là một bộ quy tắc hướng dẫn một nhóm nút độc lập với nhau, thậm chí không hoàn toàn đáng tin cậy, cách đạt được quyết định thống nhất về thứ tự và nội dung của mỗi giao dịch.
Và một khi loại "sự đồng thuận nghiêm ngặt" này được thiết lập, blockchain có thể mở khóa nhiều đặc tính then chốt như đảm bảo quyền sở hữu kỹ thuật số, mô hình tiền tệ chống lạm phát, cũng như cấu trúc hợp tác xã hội có thể mở rộng. Nhưng điều kiện tiên quyết là bản thân giao thức đồng thuận phải đồng thời đảm bảo hai nền tảng cơ bản:
-
Không thể xuất hiện hai khối mâu thuẫn nhau đều được xác nhận;
-
Mạng phải tiếp tục tiến triển, không được bị kẹt hay dừng lại.
MonadBFT là bước đột phá công nghệ mới nhất theo hướng này.
Tổng quan ngắn gọn về sự phát triển của giao thức đồng thuận
Lĩnh vực cơ chế đồng thuận thực ra đã được nghiên cứu hàng thập kỷ. Những giao thức đầu tiên, ví dụ 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 phần nút trong mạng gặp trục trặc, hành xử ác ý hoặc nói bậy nói bạ, miễn là chúng không vượt quá 1/3 tổng số nút, hệ thống vẫn có thể đạt được sự nhất trí.
Các giao thức sớm này được thiết kế theo cách khá "truyền thống": mỗi vòng chọn ra một người lãnh đạo, do anh ta đưa ra đề xuất, các trình xác thực khác sẽ bỏ phiếu nhiều vòng cho đề xuất này, từng bước xác nhận thứ tự giao dịch.
Toàn bộ quy trình bỏ phiếu thường trải qua vài giai đoạn, ví dụ như pre-prepare, prepare, commit, reply. Ở mỗi giai đoạn, tất cả các trình xác thực đều phải liên lạc với nhau. Nói cách khác, mọi người đều phải nói với mọi người một lần, lượng tin nhắn tăng vọt theo dạng "mạng lưới".
Độ phức tạp truyền thông theo cấu trúc này là n² —— nghĩa là, nếu mạng có 100 trình xác thực, mỗi vòng đồng thuận có thể phải truyền gần 10.000 tin nhắn.
Điều này không thành vấn đề trong mạng nhỏ, nhưng một 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 nổi, hiệu suất giảm mạnh.
Nguồn:
https://medium.com/coinmonks/pbft-understanding-the-algorithm-b7a7869650ae
Cấu trúc truyền thông bậc hai kiểu "mỗi người phải nói chuyện với mọi người" này thực ra rất kém hiệu quả. Ví dụ, trong một mạng có 100 trình xác thực, mỗi vòng đồng thuận có thể phải xử lý hàng ngàn tin nhắn.
Điều này còn chấp nhận được trong phạm vi nhỏ, nhưng nếu đặt vào môi trường mạng chuỗi mở trên phạm vi toàn cầu, tải truyền thông sẽ nhanh chóng trở nên không thể chấp nhận được. Do đó, các giao thức BFT đầu đời như PBFT, Tendermint thường chỉ được sử dụng trong các kịch bản được cấp phép (mạng permissioned) hoặc trong các hệ thống có số lượng trình xác thực rất ít, mới có thể vận hành được.
Để các giao thức BFT cũng có thể thích nghi với môi trường công khai không cần cấp phép, một số thiết kế thế hệ mới bắt đầu hướng tới phương thức truyền thông nhẹ hơn: mỗi trình xác thực chỉ cần giao tiếp với người lãnh đạo, thay vì tất cả cùng truyền tin cho nhau.
Việc này giảm độ phức tạp tin nhắn từ n² ban đầu xuống còn n —— giảm đáng kể gánh nặng hệ thống.
Giao thức HotStuff được đề xuất vào năm 2018 nhằm giải quyết vấn đề mở rộng này. Triết lý thiết kế của nó rất rõ ràng: dùng cấu trúc truyền thông đơn giản, do người lãnh đạo điều khiển, thay thế quy trình bỏ phiếu phức tạp của PBFT.
Tính năng then chốt của HotStuff là loại gọi là truyền thông tuyến tính (linear communication). Trong cơ chế của nó, mỗi trình xác thực chỉ cần gửi phiếu bầu của mình đến người lãnh đạo hiện tại, người lãnh đạo sau đó đóng gói các phiếu bầu này, tạo thành một Quorum Certificate (QC, bằng chứng đa số pháp định).
QC này về bản chất là một chữ ký tập thể, chứng minh với toàn bộ mạng rằng: "phần lớn các nút đã đồng ý với đề xuất này."
So với mô hình truyền thông "phát sóng toàn mạng" của PBFT, nơi mọi người đều nói trong nhóm, tình hình khá hỗn loạn. Mô hình của HotStuff giống như "một người thu thập, một lần đóng gói", bất kể mạng có bao nhiêu người, vẫn duy trì hoạt động hiệu quả.
Hình trên so sánh cấu trúc truyền thông dạng quạt của HotStuff và mô hình kết nối toàn mạng của PBFT
Nguồn:
https://www.mdpi.com/1424-8220/24/16/5417
Bên cạnh truyền thông tuyến tính, HotStuff còn có thể nâng cấp thêm thành phiên bản theo dây chuyền (pipelined HotStuff) để cải thiện hiệu suất.
Trong HotStuff nguyên bản, cùng một trình xác thực sẽ liên tục đảm nhiệm vai trò người lãnh đạo trong nhiều vòng, cho đến khi một khối được xác nhận hoàn chỉnh. Quá trình này là "xử lý một khối mỗi vòng", mọi nỗ lực đều tập trung vào việc thúc đẩy khối hiện tại.
Trong khi đó, ở HotStuff theo dây chuyền, cơ chế linh hoạt hơn: mỗi vòng sẽ chọn ra một người lãnh đạo mới, và mỗi người lãnh đạo có hai nhiệm vụ:
-
Một mặt, đóng gói phiếu bầu của vòng trước thành Quorum Certificate (QC), phát sóng cho toàn mạng;
-
Một mặt, đề xuất một khối mới, chuẩn bị cho vòng tiếp theo.
Nói cách khác, không còn là "xác nhận xong một rồi xử lý cái tiếp theo", mà giống như dây chuyền sản xuất, các người lãnh đạo luân phiên phụ trách từng khâu. Người trước đề xuất khối, người sau xác nhận nó và tiếp tục đề xuất khối mới, sự đồng thuận trên chuỗi được truyền như chạy tiếp sức.
Đây là nguồn gốc của phép ẩn dụ "theo dây chuyền": khối hiện tại vẫn đang trong quy trình xác nhận, khối tiếp theo đã được chuẩn bị, nhiều bước song song, tăng hiệu suất thông lượng.
Tóm lại, các giao thức như HotStuff đã có những cải thiện lớn so với BFT truyền thống ở hai khía cạnh:
-
Một là truyền thông nhẹ hơn, mỗi trình xác thực chỉ cần giao tiếp với người lãnh đạo;
-
Hai là hiệu suất xử lý cao hơn, nhiều quy trình xác nhận khối có thể diễn ra song song.
Điều này khiến HotStuff trở thành khuôn mẫu thiết kế cho cơ chế đồng thuận của nhiều blockchain PoS hiện đại. Nhưng mọi việc đều có hai mặt —— cấu trúc theo dây chuyền tuy hiệu suất cao, lại âm thầm đưa vào một rủi ro cấu trúc khó phát hiện.
Sau đây chúng ta sẽ đi sâu vào vấn đề cốt lõi này: vấn đề phân nhánh đuôi (Tail Forking).
Vấn đề phân nhánh đuôi (Tail-Forking)
Dù HotStuff —— đặc biệt là phiên bản theo dây chuyền —— đã giải quyết được vấn đề mở rộng của giao thức đồng thuận, nhưng nó cũng mang đến một số thách thức mới. Trong đó nghiêm trọng nhất và dễ bị bỏ qua nhất là vấn đề "phân nhánh đuôi" (Tail Forking).
Phân nhánh đuôi là gì? Có thể hiểu đơn giản là: blockchain xảy ra một lần tái tổ hợp khối (reorg) bất ngờ ở "phần đuôi chuỗi".
Cụ thể, có một khối, nó hợp lệ, cũng đã được lan truyền thành công đến phần lớn trình xác thực, và nhận được đủ phiếu bầu ủng hộ, lẽ ra nó sắp được xác nhận, ghi vào chuỗi chính. Nhưng cuối cùng, nó lại bị "bỏ qua", bị loại bỏ (orphaned), thay vào đó là một khối mới khác ở cùng độ cao.
Đây không phải lỗi phần mềm, cũng không phải tấn công, mà là do trong cấu trúc thiết kế của giao thức, tồn tại khả năng "rớt đuôi" này. Nghe có vẻ bất công đúng không? Vậy điều này xảy ra như thế nào?
Chúng ta đã nói trước đó, mỗi người lãnh đạo trong HotStuff theo dây chuyền có hai nhiệm vụ:
-
A. Đề xuất một khối mới (ví dụ Bₙ₊₁)
-
B. Thu thập phiếu bầu cho khối của người lãnh đạo trước, tạo thành QC (ví dụ hoàn tất xác nhận cuối cùng cho Bₙ)
Hai nhiệm vụ này diễn ra song song, luân phiên tiếp sức. Nhưng vấn đề nằm ở đây.
Ví dụ: giả sử Alice là người lãnh đạo, cô ấy đề xuất khối Bₙ ở độ cao n, khối này nhận được đa số phiếu bầu siêu lớn, đã "gần như được xác nhận".
Tiếp theo Bob đảm nhiệm vai trò người lãnh đạo, tiếp tục thúc đẩy khối Bₙ₊₁ cho chuỗi, đồng thời cũng nên đóng gói QC (bằng chứng đa số pháp định) cho Bₙ vào đề xuất của mình, hoàn tất xác nhận cuối cùng cho Bₙ.
Nhưng nếu lúc này Bob bị offline, hoặc cố tình không nộp QC cho Bₙ, thì sẽ xảy ra vấn đề.
Vì không ai hoàn tất việc đóng gói QC cho khối của Alice, dữ liệu phiếu bầu cho Bₙ không được lan truyền ra ngoài, khối lẽ ra đã được xác nhận này bị "bỏ lạnh", cuối cùng bị toàn bộ mạng bỏ qua.
Đây chính là bản chất của phân nhánh đuôi: khối của người lãnh đạo trước bị bỏ qua do sự thiếu trách nhiệm hoặc ác ý của người lãnh đạo tiếp theo.
Tại sao phân nhánh đuôi lại nghiêm trọng?
Vấn đề phân nhánh đuôi chủ yếu tập trung vào hai khía cạnh: 1) Cơ chế khuyến khích bị phá vỡ, 2) Hoạt tính của hệ thống bị đe dọa.
Thứ nhất, phần thưởng bị nuốt chửng:
Nếu một khối bị loại bỏ, người lãnh đạo đề xuất nó sẽ không nhận được bất kỳ phần thưởng nào. Dù là phần thưởng tạo khối hay phí giao dịch. Ví dụ Alice đề xuất một khối hợp lệ, còn nhận được sự ủng hộ phiếu bầu siêu đa số, nhưng do sai sót hoặc hành vi ác ý của Bob, khối này không được xác nhận, cuối cùng Alice chẳng nhận được đồng nào. Điều này dẫn đến cấu trúc khuyến khích sai lệch: các nút ác ý như Bob có thể "cắt đứt" nguồn thu nhập của đối thủ bằng cách bỏ qua khối của họ. Hành vi này không cần tấn công kỹ thuật, chỉ cần cố tình "không hợp tác", có thể làm suy yếu lợi ích của đối thủ cạnh tranh. Nếu việc này xảy ra thường xuyên, lâu dần sẽ làm giảm sự tham gia và công bằng của toàn hệ thống, thậm chí gây ra thông đồng giữa các nút.
Thứ hai, mở rộng không gian tấn công MEV:
Phân nhánh đuôi còn mang đến một vấn đề ẩn sâu và nghiêm trọng hơn: không gian thao túng giá trị khai thác tối đa (MEV - Maximum Extractable Value) bị mở rộng. Ví dụ: giả sử khối của Alice chứa một giao dịch arbitrage cực kỳ giá trị. Nếu Bob muốn gây rối, anh ta có thể thông đồng với người lãnh đạo tiếp theo Carol, cố tình không lan truyền khối của Alice. Sau đó Carol xây dựng lại một khối mới ở cùng độ cao, "chép" giao dịch arbitrage giá trị đó từ khối của Alice —— biến lợi nhuận MEV thành của riêng mình. Cách làm "sắp xếp lại đầu chuỗi + thông đồng chiếm đoạt" này, bề ngoài vẫn tuân thủ quy trình tạo khối, thực chất là một cuộc cướp có tính toán kỹ lưỡng. Tệ hơn nữa, nó sẽ thúc đẩy các người lãnh đạo thiết lập mối quan hệ "thông đồng", biến việc xác nhận khối thành trò chơi phân phối lợi ích, chứ không phải dịch vụ công cộng.
Thứ ba, phá vỡ đảm bảo tính tất yếu, ảnh hưởng trải nghiệm người dùng:
So với các giao thức kiểu Nakamoto, ưu điểm lớn của BFT là tính tất yếu xác định: một khi khối được gửi vào, sẽ không thể hoàn tác. Nhưng phân nhánh đuôi phá vỡ đảm bảo này, đặc biệt đối với các khối "đã nhận phiếu bầu nhưng chưa được xác nhận chính thức". Một số dapp tốc độ cao thường muốn đọc dữ liệu ngay sau khi phiếu bầu khối được thông qua để giảm độ trễ, nếu khối đó đột nhiên bị loại bỏ, có thể khiến trạng thái người dùng bị hoàn tá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 vô cớ biến mất, trạng thái trò chơi đột ngột reset, v.v.
Thứ tư, có thể gây ra sự cố dây chuyền:
Nói chung, phân nhánh đuôi có thể chỉ khiến một khối bị chậm xác nhận một vòng, ảnh hưởng không lớn. Nhưng trong một số tình huống biên, nếu nhiều người lãnh đạo liên tiếp chọn bỏ qua khối trước đó, hệ thống có thể rơi vào trạng thái đình trệ, không ai muốn "nhận" khối trước. Toàn bộ việc thúc đẩy chuỗi bị kẹt lại, cho đến khi cuối cùng xuất hiện một người lãnh đạo "sẵn sàng gánh vác trách nhiệm", mạng mới tiếp tục tiến triển.
Mặc dù trước đây cũng có một số giải pháp, ví dụ như cơ chế tránh phân nhánh đuôi do giao thức BeeGees đề xuất, nhưng thường phải đánh đổi hiệu suất, ví dụ như đưa lại độ phức tạp truyền thông bậc hai, thiệt hơn lời.
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 đề phân nhánh đuôi. Điểm tuyệt vời của nó nằm ở chỗ: giải quyết được các nguy cơ cấu trúc mà không hy sinh lợi thế hiệu suất do HotStuff theo dây chuyền mang lại. Nói cách khác, MonadBFT không phải xây lại từ đầu, mà là tiếp tục tối ưu hóa dựa trên khung cốt lõi của HotStuff. Nó giữ lại ba đặc tính then chốt:
1) Luân chuyển người lãnh đạo (rotating leader): mỗi vòng chọn ra người lãnh đạo mới để thúc đẩy chuỗi;
2) Gửi theo dây chuyền (pipelined commits): nhiều quy trình xác nhận khối có thể chồng lấn nhau;
3) Truyền thông tuyến tính (linear messaging): mỗi trình xác thực chỉ cần giao tiếp với người lãnh đạo, tiết kiệm đáng kể chi phí mạng.
Nhưng chỉ dựa vào ba điểm này thì chưa đủ an toàn. Để bịt kín lỗ hổng cấu trúc phân nhánh đuôi, MonadBFT bổ sung thêm hai cơ chế then chốt:
1) Cơ chế đề xuất lại bắt buộc (Re-Proposal)
2) Chứng chỉ không phê chuẩn (NEC, No-Endorsement Certificate)
Cơ chế đề xuất lại (Re-Proposal)
Trong giao thức BFT, thời gian được chia thành từng vòng (gọi là view), mỗi vòng có một người lãnh đạo chịu trách nhiệm đề xuất khối mới. Nếu người lãnh đạo thất bại (ví dụ không đề xuất khối đúng hạn, hoặc đề xuất không hợp lệ), hệ thống sẽ chuyển sang vòng mới và chọn người lãnh đạo mới.
MonadBFT bổ sung một cơ chế, đảm bảo trong quá trình chuyển view, bất kỳ khối nào được đề xuất trung thực sẽ không bị "rớt" do luân chuyển người lãnh đạo.
Khi người lãnh đạo vòng hiện tại thất bại, các trình xác thực sẽ gửi một tin nhắn chuyển view đã ký, báo hiệu rằng vòng hiện tại đã hết thời gian chờ.
Đặc biệt, tin nhắn này không chỉ biểu thị "hết giờ", mà còn phải chứa thông tin khối mà trình xác thực đó lần cuối cùng bỏ phiếu, tương đương nói rằng: "Tôi không nhận được đề xuất hợp lệ, đây là khối mới nhất tôi thấy."
Người lãnh đạo vòng mới sẽ thu thập các tin nhắn hết giờ này từ siêu đa số (2f+1) trình xác thực, và hợp nhất thành một bằng chứng hết giờ (Timeout Certificate, TC). TC này đại diện cho: khi vòng trước thất bại, bản chụp nhanh sự nhận thức thống nhất của toàn mạng về "khối đầu chuỗi". Người lãnh đạo mới sẽ chọn ra khối có độ cao cao nhất (hoặc số hiệu view mới nhất) từ đó, tức high_tip.
MonadBFT yêu cầu: đề xuất 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 treo cao nhất trong TC, để khối này có cơ hội được xác nhận một lần nữa.
Tại sao? Như đã nói trước đó: chúng ta không muốn một khối gần được xác nhận cứ thế biến mất.
Ví dụ: giả sử Alice là người lãnh đạo view 5, đề xuất một khối hợp lệ và nhận được đa số phiếu bầu. Tiếp theo, người lãnh đạo view 6 là Bob bị offline, không thúc đẩy được tiến trình chuỗi. Khi Carol đảm nhiệm người lãnh đạo view 7, theo quy tắc MonadBFT, cô ấy phải chứa TC và đề xuất lại khối của Alice. Như vậy, lao động trung thực của Alice sẽ không bị uổng phí.
Nếu Carol không có khối của Alice, cô ấy có thể yêu cầu từ các nút khác. Các nút có thể:
-
Cung cấp khối đó, hoặc
-
Trả về một tin nhắn "không phê chuẩn" đã ký (No-Endorsement, NE), cho biết họ không có khối này (cơ chế sẽ trình bày sau). (Tối đa f nút Byzantine có thể chọn phớt lờ yêu cầu, không phản hồi.)
Một khi Carol đề xuất lại khối của Alice, cô ấy sẽ nhận được một cơ hội đề xuất bổ sung, đảm bảo không bị "vạ lây" do sự thất bại của người lãnh đạo trước.
Tác dụng của cơ chế đề xuất lại là rõ ràng: đảm bảo việc thúc đẩy chuỗi là công bằng, bất kỳ công việc hợp lệ nào cũng không bị lặng lẽ loại bỏ do xui xẻo hay có người gây rối.
Chứng chỉ không phê chuẩn (NEC)
Tiếp tục ví dụ trước: sau khi Bob hết giờ, Carol yêu cầu các trình xác thực khác cung cấp khối high_tip (tức khối của Alice). Lúc 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 tin nhắn NE đã ký, cho biết họ không nhận được khối của Alice
Miễn là Carol nhận được khối của Alice, cô ấy phải theo quy tắc đề xuất lại nó. Chỉ khi có ít nhất f+1 trình xác thực ký tin nhắn NE, Carol mới được phép bỏ qua khối đó và đề xuất một khối mới.
Tại sao là f+1? Trong một hệ thống BFT gồm 3f+1 trình xác thực, tối đa chỉ có f nút có thể hành xử ác ý. Nếu khối của Alice thực sự nhận được phiếu bầu siêu đa số, 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 lấy được khối của Alice", cô ấy phải đưa ra chữ ký của f+1 trình xác thực, chứng minh những người này đều không nhận được. Điều này tạo thành một Chứng chỉ Không Phê Chuẩn (No-Endorsement Certificate, NEC).
NEC là bằng chứng "miễn trách" cho người lãnh đạo: nó là bằng chứng có thể kiểm chứng, cho thấy khối trước chưa sẵn sàng để được xác nhận, bản thân mình không phải ác ý bỏ qua, mà là "bỏ" một cách có căn cứ.
Đề xuất lại + Chứng chỉ không phê chuẩn = Giải quyết phân nhánh đuôi
MonadBFT thông qua việc giới thiệu cơ chế đề xuất lại (Re-Proposal) và chứng chỉ không phê chuẩn (NEC, No-Endorsement Certificate), thiết lập một bộ quy tắc xử lý đầu chuỗi chặt chẽ và rõ ràng:
Hoặc hoàn tất việc gửi cuối cùng cho khối "gần được xác nhận";
Hoặc cung cấp đủ bằng chứng chứng minh khối đó chưa đủ điều kiện để đượ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: bất kỳ khối nào đã nhận được phiếu bầu đa số pháp định, sẽ không bị từ bỏ do lỗi người lãnh đạo hoặc cố tình né tránh.
Rủi ro cấu trúc phân nhánh đuôi được giải quyết hệ thống, giao thức có thể ràng buộc rõ ràng các hành vi bỏ qua sai trái.
Nếu một người lãnh đạo cố gắng bỏ qua khối trước mà không có lý do, nhưng không cung cấp NEC để chứng minh, giao thức sẽ ngay lập tức nhận diện và từ chối hành vi đó. Hành vi nhảy vọt không có bằng chứng mã hóa sẽ bị coi là bất hợp pháp, không nhận được sự đồng thuận của mạng.
Xét về mặt động lực kinh tế, thiết kế này cung cấp sự bảo vệ rõ ràng cho các trình xác thực:
-
Bất kỳ khối nào được đề xuất trung thực và nhận được sự ủng hộ phiếu bầu, phần thưởng của nó sẽ không bị tước đoạt do sự cố ở khâu sau;
-
Ngay cả trong tình huống cực đoan, ví dụ một nút cố tình bỏ qua lượt đề xuất của mình, nhằm giúp người khác chiếm đoạt MEV từ khối trước, giao thức cũng sẽ buộc người lãnh đạo kế tiếp ưu tiên đề xuất lại khối cũ, làm cho kẻ tấn công không thể thu lợi 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 để nâng cao tính bảo mật.
Một số thiết kế trước đây ứng phó phân nhánh đuôi (như giao thức BeeGees) tuy có khả năng bảo vệ nhất định, nhưng thường dựa vào độ phức tạp truyền thông cao (n²) hoặc kích hoạt lại quy trình truyền thông ở mỗi vòng, điều này trong thực tế sẽ làm tăng đáng kể gánh nặng hệ thống.
Chiến lược thiết kế của MonadBFT tinh tế hơn:
Chỉ khi view thất bại hoặc có bất thường, mới khởi động truyền thông bổ sung (ví dụ tin nhắn hết giờ, đề xuất lại khối). Trên con đường thông thường khi các người lãnh đạo trung thực liên tiếp đề xuất khối, giao thức vẫn duy trì trạng thái vận hành nhẹ và hiệu quả.
Sự cân bằng động giữa hiệu suất và bảo mật này 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 trước đó.
Tổng kết
Bài viết này đã điểm lại cơ chế cơ bản của đồng thuận PBFT truyền thống, vạch ra lộ trình phát triển của giao thức HotStuff, và tập trung giải thích cách MonadBFT giải quyết vấn đề phân nhánh đuôi vốn có trong HotStuff theo dây chuyền từ góc độ cấu trúc giao thức.
Phân nhánh đuôi làm sai lệch động lực kinh tế của người đề xuất khối, đồng thời tiềm ẩn mối đe dọa đối với hoạt tính mạng. MonadBFT thông qua việc giới thiệu cơ chế đề xuất lại và chứng chỉ không phê chuẩn (NEC), đảm bảo bất kỳ khối nào do người lãnh đạo trung thực đề xuất và nhận được phiếu bầu đa số pháp định sẽ không bị bỏ rơi hay bỏ qua.
Ở bài tiếp theo, chúng ta sẽ tiếp tục khám phá hai đặc tính cốt lõi khác của MonadBFT:
1) Tính tất yếu dự đoán (Speculative Finality)
2) Phản hồi lạc quan (Optimistic Responsiveness)
Và phân tích sâu hơn ý nghĩa thực tế của các cơ chế này đối với trình xác thực và nhà phát triển.
Mời đón xem phần tiếp theo.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
