Phân tích MonadBFT (Phần 1): Cách giải quyết vấn đề phân nhánh cuối
Tuyển chọn TechFlowTuyển chọn TechFlow
Phân tích MonadBFT (Phần 1): Cách giải quyết vấn đề phân nhánh cuối
Việc phân nhánh cuối cùng sẽ làm sai lệch các động lực kinh tế của người đề xuất khối và cũng gây ra mối đe dọa tiềm tàng đối với tính hoạt động của mạng. MonadBFT đảm bảo rằng bất kỳ khối nào do nhà lãnh đạo trung thực đề xuất và nhận được đa số phiếu bầu hợp lệ đều không bị bỏ lại hoặc bỏ qua, thông qua việc giới thiệu cơ chế đề xuất lại và chứng chỉ không có xác nhận (NEC).
Chuyên sâu báo cáo Web3Trọng tâm của blockchain nằm ở việc đạt được một dạng đồ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 phân bố ở 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 mạng phân tán trong thực tế 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 gây rối. Trong những trường hợp như vậy, hệ thống làm thế nào để "đồng thanh nhất trí", duy trì sự thống nhất?
Đâ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 các nút độc lập với nhau, thậm chí không hoàn toàn đáng tin cậy, cách đưa ra quyết định thống nhất về thứ tự và nội dung của mỗi giao dịch.
Một khi loại "đồ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 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, và 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à chính 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ể có 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 bị kẹt hoặc ngừng hoạt động.
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 bị lỗi, hành xử ác ý hay nói sai, 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ự 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 khởi xướng đề xuất, các trình xác thực khác bỏ phiếu cho đề xuất này qua nhiều vòng, 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 khác một lần, lượng thông điệp tăng vọt theo kiểu "mạng lưới".
Độ phức tạp về mặt truyền thông của cấu trúc này là n² — tức 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 thông điệp.
Đ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.
Cấu trúc truyền thông bậc hai kiểu "mỗi người phải nói 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 thông điệp.
Điều này còn chấp nhận được trong phạm vi nhỏ, nhưng nếu đặt vào mạng lưới chuỗi mở trên toàn cầu, tải truyền thông sẽ trở nên không thể chấp nhận. Vì vậy, các giao thức BFT đầu tiên như PBFT, Tendermint thường chỉ được sử dụng trong các môi trường được cấp phép (permissioned network) hoặc hệ thống có số lượng trình xác thực rất ít, mới có thể chạy được.
Để các giao thức BFT cũng thích nghi được với môi trường chuỗi công cộng 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ả mọi người đều gửi tin lẫn 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, chính là để 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à gọi là truyền thông tuyến tính (linear communication). Trong cơ chế này, 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 này lại, 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: "đa số nút đã đồng ý với đề xuất này".
So sánh, mô hình truyền thông của PBFT là "phát sóng toàn bộ", mỗi người đều nói trong nhóm, tình trạng lúc nào cũng 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 có thể vận hành hiệu quả.
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 dây chuyền (pipelined HotStuff) nhằm 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 giữ 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 tập trung vào việc đẩy khối hiện tại.
Trong khi đó, trong pipelined HotStuff, 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ị bắt đầu vòng tiếp theo.
Nói cách khác, không còn là "xác nhận xong một khối rồi mới xử lý khố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, đồng thuận trên chuỗi cứ như vậy truyền tiếp như chạy tiếp sức.
Đây chính là nguồn gốc của cụm từ "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, nâng cao hiệu suất thông lượng.
Tóm lại, các giao thức như HotStuff so với BFT truyền thống đã cải thiện đáng kể trên hai phương diện:
- 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 mẫu thiết kế cho cơ chế đồng thuận của nhiều blockchain PoS hiện đại. Nhưng cái gì cũng có hai mặt — mặc dù cấu trúc dây chuyền hiệu suất mạnh mẽ, nhưng nó cũng âm thầm đưa vào một rủi ro cấu trúc khó phát hiện.
Tiếp theo, 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 dây chuyền của 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 đó, quan trọng nhất và dễ bị bỏ qua nhất, chính là vấn đề gọi là "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ờ ở "đuôi chuỗi".
Cụ thể, có một khối, nó hợp lệ, đã được truyền thành công đến đa số trình xác thực, và nhận được đủ phiếu ủng hộ, theo lẽ thường thì nó sắp được xác nhận, ghi vào chuỗi chính. Nhưng cuối cùng, nó bị "bỏ qua", bị loại bỏ (orphaned), thay vào đó là một khối mới ở cùng độ cao.
Đây không phải lỗi (bug), cũng không phải tấn công, mà là do chính cấu trúc thiết kế của giao thức tồn tại khả năng "rơi mất đuôi chuỗi". Nghe có vẻ không công bằng đúng không? Vậy chuyện này xảy ra thế nào?
Chúng ta đã nói trước đó, mỗi người lãnh đạo trong pipelined HotStuff 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 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 siêu đa số phiếu, đã "gần như được xác nhận". Tiếp theo Bob sẽ làm người lãnh đạo, tiếp tục đẩy khối tiếp theo Bₙ₊₁, đồng thời nên đóng gói QC của Bₙ (bằng chứng đa số pháp định) vào đề xuất của anh ta, hoàn tất xác nhận cuối cùng cho Bₙ.
Nhưng nếu lúc này Bob ngoại tuyến, hoặc cố tình không nộp QC của Bₙ, thì sẽ có vấn đề.
Bởi vì không ai hoàn tất việc đóng gói QC cho khối của Alice, bản ghi phiếu bầu cho Bₙ không được lan truyền, khối lẽ ra đã được xác nhận này bị "bỏ quên", 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 người lãnh đạo sau thiếu trách nhiệm hoặc ác ý.
Tại sao phân nhánh đuô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) tính sẵn sàng của hệ thống bị đe dọa.
Thứ nhất, phần thưởng bị nuốt chửng: Một khối nếu 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à 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 phiếu siêu đa số, nhưng do sơ suấ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 khô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 thưởng 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ủ. 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 đề nghiêm trọng và ẩn sâu hơn: không gian thao túng giá trị khai thác tối đa (MEV) bị mở rộng. Ví dụ: giả sử khối của Alice chứa giao dịch chênh lệch giá trị cao. Nếu Bob muốn gây rối, có thể thông đồng với người lãnh đạo tiếp theo Carol, cố tình không 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 chênh lệch đó 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 tắc tạo khối, thực chất là một cuộc cướp có tính toán. Tệ hơn nữa, nó sẽ thúc đẩy các người lãnh đạo hình thành "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 còn là dịch vụ công cộng.
Thứ ba, phá vỡ đảm bảo tính dứt khoát, ả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 dứt khoát chắc chắn: một khi khối được gửi, sẽ không thể hoàn tác. Nhưng phân nhánh đuôi phá vỡ sự đảm bảo này, đặc biệt là với các khối "đã nhận phiế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 khối được thông qua để giảm độ trễ, nếu khối đó bị loại bỏ đột ngột, có thể dẫn đế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 bỗng nhiên biến mất, trạng thái trò chơi đột ngột đặt lại, v.v.
Thứ tư, có thể gây ra lỗi dây chuyền: Thông thường, phân nhánh đuôi có thể chỉ làm 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ộ chuỗi bị kẹt, cho đến khi cuối cùng xuất hiện một người lãnh đạo "chịu gánh trách nhiệm", mạng mới tiếp tục tiến lê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 trong giao thức BeeGees, 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ế đặc biệt để 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 mối lo cấu trúc mà không đánh mất lợi thế hiệu suất do pipelined HotStuff 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 điểm then chốt:
- 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 để đẩy chuỗi;
- Xác nhận dây chuyền (pipelined commits): nhiều quy trình xác nhận khối có thể chồng lấn;
- 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ỉ ba điểm này thôi thì chưa đủ an toàn. Để chặn khe hở cấu trúc phân nhánh đuôi, MonadBFT bổ sung hai cơ chế then chốt:
- Cơ chế đề xuất lại bắt buộc (Re-Proposal)
- Chứng chỉ không hậu thuẫ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 tiếp theo và chọn người lãnh đạo mới.
MonadBFT thêm một cơ chế đảm bảo rằng 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ơi" do thay đổi 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 thông báo chuyển view có chữ ký, cho biết vòng hiện tại đã hết thời gian chờ.
Đặc biệt, thông báo này không chỉ nói "hết giờ", mà còn phải chứa thông tin khối mà trình xác thực gần đây nhất đã 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 thông báo 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 "bản chụp nhanh nhận thức chung" của toàn mạng về "khối đầu chuỗi" khi vòng trước thất bại. Người lãnh đạo mới sẽ chọn khối treo cao nhất (hoặc có số view mới nhất) từ TC, gọi là 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, cho khối đó cơ hội được xác nhận.
Tại sao? Như chúng ta đã nói trước đó: chúng ta không muốn một khối gần được xác nhận lại 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. Tiếp theo, người lãnh đạo view 6 là Bob ngoại tuyến, không đẩy được tiến trình chuỗi. Khi Carol là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 thông điệp "không hậu thuẫn" (No-Endorsement, NE) có chữ ký, cho biết họ không có khối đó (cơ chế sẽ giới thiệu 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 người lãnh đạo trước thất bại.
Tác dụng của cơ chế đề xuất lại là rõ ràng: đảm bảo việ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 quấy phá.
Chứng chỉ không hậu thuẫ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 thông điệp NE có chữ ký, cho biết họ không nhận được khối của Alice
Chỉ khi Carol nhận được khối của Alice, cô ấy mới 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ý NE, Carol mới được phép bỏ qua khối đó và đề xuấ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ể ác ý. Nếu khối của Alice thực sự nhận được siêu đa số phiếu, thì ít nhất 2f+1 nút trung thực đã nhận được nó.
Vì vậy, 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ý từ f+1 trình xác thực, chứng minh những người này đều không nhận được. Đây chính là Chứng chỉ không hậu thuẫn (No-Endorsement Certificate, NEC).
NEC là bằng chứng "miễn trách" cho người lãnh đạo: đây 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 không phải cố tình bỏ qua mà là "bỏ qua" có căn cứ.
Đề xuất lại + Chứng chỉ không hậu thuẫn = Giải quyết phân nhánh đuôi
MonadBFT thông qua việc đưa vào cơ chế Đề xuất lại (Re-Proposal) và Chứng chỉ không hậu thuẫn (NEC, No-Endorsement Certificate), thiết lập một bộ quy tắc xử lý đầu chuỗi nghiêm ngặt và rõ ràng:
Hoặc hoàn tất xác nhận cuối cùng cho khối "gần được xác nhận"; hoặc cung cấp đủ bằng chứng cho thấy khối đó chưa đủ điều kiện 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 đa số pháp định sẽ không bị bỏ do lỗi hoặc cố tình né tránh của người lãnh đạo. 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 hành vi bỏ qua không đúng.
Nếu một người lãnh đạo cố gắng bỏ qua khối trước mà không có NEC, 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 mà 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 khuyến khích 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 phiếu ủng hộ, phần thưởng sẽ không bị tước do lỗi ở 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 MEV của 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ũ, khiến kẻ tấn công không thể kiếm lợi kinh tế từ việc bỏ qua.
Quan trọng hơn, MonadBFT không đánh đổi hiệu suất để tăng tính an toàn.
Một số thiết kế đối phó phân nhánh đuôi trước đây (như giao thức BeeGees) tuy có khả năng phòng thủ nhất định, nhưng thường phụ thuộc 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 (như thông báo 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 tạo 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à an toàn 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 đã ôn lại cơ chế cơ bản của đồng thuận PBFT truyền thống, trình bày 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 đề nội sinh phân nhánh đuôi của pipelined HotStuff ở tầng giao thức.
Phân nhánh đuôi làm méo mó động lực kinh tế của người đề xuất khối, đồng thời tiềm ẩn đe dọa đến tính sẵn sàng của mạng. MonadBFT thông qua việc đưa vào cơ chế đề xuất lại và chứng chỉ không hậu thuẫ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 đa số pháp định sẽ không bị bỏ rơi hoặc bỏ qua.
Trong bài tiếp theo, chúng ta sẽ tiếp tục khám phá hai đặc điểm cốt lõi khác của MonadBFT:
- Tính dứt khoát dự đoán (Speculative Finality)
- Khả năng phản hồi tích cực (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 kỳ sau.
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
