Cốt lõi của blockchain nằm ở việc đạt được một sự đồng thuận toàn cầu nghiêm ngặt (strict global consensus): tức là, bất kể các nút mạng phân bố ở quốc gia nào, múi giờ nào, tất cả người tham gia cuối cùng phải đồng ý về một tập hợp các 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ị mấ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 lòng", duy trì sự nhất quán?
Đây là vấn đề mà giao thức đồng thuận cần giải quyết. Nó về cơ bản là một tập hợp các quy tắc để hướng dẫn một nhóm các nút độc lập, thậm chí không hoàn toàn đáng tin cậy, làm thế nào để đạt được quyết định thống nhất 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 sẽ mở ra một số tính năng chính, chẳng hạn như bảo vệ tài sản 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 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ể có hai khối mâu thuẫn được xác nhận.
Mạng phải tiếp tục tiến về phía trước và không bị kẹt hoặc tắt.
MonadBFT là bước đột phá công nghệ mới nhất trong hướng này.
Tổng quan ngắn gọn về sự tiến hóa của giao thức đồng thuận
Trên thực tế, lĩnh vực cơ chế đồng thuận đã được nghiên cứu trong nhiều thập kỷ. Các giao thức sớm nhất, chẳng hạn như PBFT (Practical Byzantine Fault Tolerance), đã có thể đối phó với một tình huống rất thực tế: ngay cả khi một số nút trong mạng nằm ngoài chuỗi, làm điều ác và nói chuyện 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ể đồng ý.
Các phương pháp thiết kế của những giao thức sớm này khá "truyền thống": mỗi vòng sẽ chọn ra một người lãnh đạo, người này sẽ khởi xướng đề xuất, các xác thực viên khác sẽ thực hiện nhiều vòng bỏ phiếu về đề 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 một số giai đoạn, chẳng hạn như pre-prepare, prepare, commit, reply. Ở mỗi giai đoạn, tất cả các xác thực viên đều phải giao tiếp với nhau. Nói cách khác, mỗi người đều phải nói với từng người một, khối lượng tin nhắn tăng theo kiểu 'mạng lưới' bùng nổ.
Độ phức tạp của cấu trúc giao tiếp này là n² - tức là, nếu trong mạng có 100 người xác thực, thì 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 phải là vấn đề lớn trong mạng nhỏ, nhưng một khi số lượng người xác nhận 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, hiệu suất sẽ bị giảm sút.
Nguồn thông tin:
Cấu trúc giao tiếp thứ cấp "mỗi người đều phải giao tiếp với mỗi người" này thực sự rất kém hiệu quả. Ví dụ, trong một mạng lưới có 100 người xác thực, mỗi vòng đồng thuận có thể phải xử lý hàng nghìn tin nhắn.
Điều này có thể xử lý trong một vòng tròn nhỏ, nhưng nếu đặt trong một mạng lưới chuỗi mở, toàn cầu, thì tải trọng giao tiếp ngay lập tức trở nên không thể chấp nhận được. Vì vậy, các giao thức BFT sớm như PBFT và Tendermint thường chỉ được sử dụng trong các tình huống có giấy phép (permissioned network) hoặc trong các hệ thống có số lượng người xác thực rất ít, mới có thể hoạt động một cách khó khăn.
Để cho giao thức BFT cũng có thể thích ứng với môi trường công khai không cần giấy phép, một số thiết kế thế hệ mới bắt đầu hướng tới phương thức giao tiếp nhẹ nhàng hơn: để mỗi người xác thực chỉ giao tiếp với người lãnh đạo, thay vì tất cả cùng truyền đạt cho nhau.
Điều này đã tối ưu hóa độ phức tạp của thông điệp từ n² xuống n - giảm nhẹ gánh nặng cho hệ thống rất nhiều.
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. Nguyên tắc 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 khiển.
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ế của nó, mỗi trình xác thực chỉ cần gửi phiếu bầu của họ cho người lãnh đạo hiện tại, người sau đó đóng gói các phiếu bầu đó để tạo Chứng chỉ Đại biểu (QC).
QC này thực chất là một chữ ký tập thể, chứng minh với toàn bộ mạng rằng: "Đa số các nút đã đồng ý với đề xuất này."
So với đó, mô hình giao tiếp của PBFT là "phát sóng toàn bộ", mọi người đều nói chuyện trong nhóm, tình hình trở nên rất 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ể có bao nhiêu người trong mạng, vẫn có thể duy trì hoạt động hiệu quả.
Hình trên so sánh cấu trúc giao tiếp phát tán của HotStuff với mô hình kết nối toàn mạng của PBFT.
Nguồn:
Ngoài giao tiếp tuyến tính, HotStuff còn có thể nâng cấp thêm thành phiên bản theo đường ống (HotStuff theo đường ống), nhằm nâng cao hiệu quả.
Trong HotStuff gốc, cùng một người xác thực sẽ liên tiếp đảm nhận vai trò lãnh đạo qua nhiều vòng cho đến khi một khối được xác nhận hoàn toàn. Quá trình này là "mỗi vòng xử lý một khối", mọi nỗ lực đều tập trung vào việc thúc đẩy khối hiện tại.
Và trong chuỗi HotStuff, cơ chế trở nên linh hoạt hơn: Mỗi vòng sẽ chọn ra một nhà lãnh đạo mới, và nhiệm vụ của mỗi nhà lãnh đạo có hai nhiệm vụ:
Một bên đóng gói phiếu bầu của vòng trước thành Chứng nhận Quorum (QC) và phát sóng đến toàn bộ mạng.
Một bên đưa ra một khối mới, chuẩn bị bắt đầu vòng tiếp theo.
Nói cách khác, nó không còn là "xác nhận cái này rồi 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 thay phiên nhau chịu trách nhiệm cho từng liên kết. Bit trước đề xuất một khối, bit tiếp theo xác nhận nó và chuyển sang đề xuất một khối mới và sự đồng thuận trên chuỗi được truyền lại như một cuộc đua tiếp sức.
Đây là nguồn gốc của phép ẩn dụ "dòng chảy": 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 thực hiện những cải tiến đáng kể so với BFT truyền thống theo hai chiều:
Một là giao tiếp nhẹ hơn, mỗi người xác thực chỉ cần giao tiếp với người lãnh đạo;
Thứ hai là hiệu suất xử lý cao hơn, 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 PoS hiện đại. Tuy nhiên, mọi thứ đều có hai mặt - mặc dù cấu trúc dây chuyền có 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ông dễ phát hiện.
Tiếp theo, chúng ta sẽ đi sâu vào vấn đề cốt lõi này: Phân nhánh đuôi (Tail Forking).
Vấn đề phân nhánh đuôi (Tail-Forking)
Mặc dù HotStuff - đặc biệt là phiên bản theo dòng - đã giải quyết vấn đề khả năng mở rộng của giao thức đồng thuận, nhưng nó cũng mang lại một số thách thức mới. Vấn đề quan trọng nhất, và cũng dễ bị bỏ qua nhất, đó là vấn đề "đường phân nhánh đuôi" (Tail Forking).
Phân nhánh cuối là gì? Có thể hiểu đơn giản là: một sự tái tổ chức khối bất ngờ xảy ra ở "đuôi chuỗi" của blockchain (reorg).
Cụ thể, có một khối, nó là hợp lệ, và đã được truyền thành công đến hầu hết các xác thực viên, còn nhận được đủ nhiều sự ủng hộ từ các phiếu bầu, theo lý mà nói, nó sẽ ngay lập tức đượ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 ở cùng độ cao.
Đây không phải là lỗi, cũng không phải là tấn công, mà là do cấu trúc thiết kế của giao thức có khả năng tồn tại "rơi chuỗi". Nghe có vẻ hơi 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 lãnh đạo trong dòng chảy HotStuff đều 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 nhà lãnh đạo trước đó, tạo ra QC (ví dụ như hoàn tất xác nhận cuối cùng cho Bₙ)
Hai nhiệm vụ này là song song, lần lượt tiếp sức. Nhưng vấn đề nằm ở đây.
Giả sử Alice là người lãnh đạo, cô ấy đã đề xuất khối Bₙ ở độ cao thứ n, khối này đã nhận được sự bỏ phiếu của đa số tuyệt đối và đã "gần như được xác nhận".
Tiếp theo, Bob sẽ đảm nhận vai trò lãnh đạo, tiếp tục thúc đẩy khối tiếp theo của chuỗi Bₙ₊₁, đồng thời cũng nên đóng gói QC (chứng minh đa số hợp pháp) của Bₙ vào đề xuất của mình, hoàn thành xác nhận cuối cùng của Bₙ.
Nhưng nếu Bob offline vào lúc này, hoặc cố tình không nộp QC của Bₙ, thì sẽ có vấn đề.
Bởi vì không ai thực hiện QC đóng gói cho khối của Alice, nên bản ghi bỏ phiếu của Bₙ không thể được truyền đi, và khối này lẽ ra nên được xác nhận, đã bị "lạnh" như vậy, cuối cùng bị toàn bộ mạng lưới bỏ qua.
Đây chính là bản chất của nhánh cuối: Khối của nhà lãnh đạo trước bị bỏ qua vì sự thiếu trách nhiệm hoặc ác ý của nhà lãnh đạo tiếp theo.
Tại sao phần đuôi lại bị phân nhánh nghiêm trọng?
Vấn đề phân nhánh ở cuối chủ yếu tập trung vào hai khía cạnh: 1) Cơ chế khuyến khích bị phá hủy, 2) Tính năng hoạt động của hệ thống bị đe dọa.
Đầu tiên, phần thưởng bị nuốt:
Nếu một khối bị loại bỏ, người lãnh đạo đề xuất nó không nhận được phần thưởng. Cho dù đó là phần thưởng khối hay phí giao dịch. Ví dụ: Alice đã đề xuất một khối hợp pháp và nhận được phiếu bầu đa số, nhưng do những sai lầm hoặc hành động độc hại của Bob, việc chặn không được xác nhận và cuối cùng Alice đã không nhận được một xu. Điều này dẫn đến một cấu trúc khuyến khích sai: các nút độc hại như Bob có thể "vặt" nguồn phần thưởng của họ bằng cách bỏ qua khối của đối thủ. Loại hành vi này không đòi hỏi một cuộc tấn công kỹ thuật, chỉ là một sự "không hợp tác" có chủ ý để làm suy yếu thu nhập của đối thủ cạnh tranh. Nếu loại điều này xảy ra lặp đi lặp lại, theo thời gian, nó sẽ làm giảm sự tham gia và công bằng của toàn bộ hệ thống, và thậm chí gây ra sự thông đồng giữa các nút.
Thứ hai, không gian tấn công MEV mở rộng:
Phuộc đuôi cũng đặt ra một vấn đề xảo quyệt nhưng nghiêm trọng hơn: có nhiều chỗ hơn cho MEV (Giá trị trích xuất tối đa) bị thao túng độc hại. Đâ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 cô ấy. 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 truyền 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 - làm cho MEV có được của riêng mình. Hành vi "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 các 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 việc 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, phá hủy đảm bảo cuối cùng, ảnh hưởng đến trải nghiệm người dùng:
Một trong những lợi thế lớn của BFT so với các giao thức giống Nakamoto là tính cuối cùng xác định: một khi một khối đã được cam kết, nó không thể được quay trở lại. Nhưng phuộc đuôi làm suy yếu sự đảm bảo này, đặc biệt là trên 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 thông lượng cao thường muốn có thể đọc dữ liệu ngay sau khi một khối được bỏ phiếu để giảm độ trễ và nếu khối bị loại bỏ đột ngột, nó có thể dẫn đến việc khôi phục trạng thái của người dùng - chẳng hạn như số dư tài khoản bất thường, giao dịch đòn bẩy cao vừa được hoàn thành biến mất mà không có lý do, đặt lại trạng thái trò chơi đột ngột, v.v.
Thứ tư, có thể gây ra sự cố dây chuyền:
Thông thường, việc phân nhánh ở phần cuối có thể chỉ khiến một khối bị xác nhận muộ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 liên tiếp vài lãnh đạo chọn bỏ qua khối trước đó, hệ thống có thể rơi vào trạng thái ngưng trệ, không ai muốn "nhận" khối trước. Toàn bộ chuỗi sẽ bị kẹt lại cho đến khi cuối cùng xuất hiện một lãnh đạo "sẵn sàng gánh vác trách nhiệm", mạng lưới mới có thể tiếp tục tiến lên.
Mặc dù trước đây cũng đã có một số giải pháp, chẳng hạn như cơ chế tránh phân nhánh cuối được đề xuất bởi giao thức BeeGees, nhưng thường phải hy sinh hiệu suất, chẳng hạn như tái đưa vào độ phức tạp của giao tiếp thứ cấp, không đáng.
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 cuối. Điểm mạnh của nó là: trong khi giải quyết các rủi ro cấu trúc, nó không hy sinh những lợi thế về hiệu suất mà HotStuff mang lại. Nói cách khác, MonadBFT không phải là bắt đầu lại từ đầu, mà là tiếp tục tối ưu hóa dựa trên khung chính của HotStuff. Nó giữ lại ba đặc điểm chính:
1）Lãnh đạo luân phiên (rotating leader): Mỗi vòng sẽ chọn ra một lãnh đạo mới để thúc đẩy chuỗi;
2）Gửi theo quy trình (pipelined commits): Nhiều quá trình xác nhận khối có thể diễn ra chồng chéo.
Giao tiếp tuyến tính (linear messaging): Mỗi xác thực viên chỉ cần giao tiếp với người lãnh đạo, tiết kiệm rất nhiều chi phí mạng.
Nhưng chỉ dựa vào ba điểm này vẫn chưa đủ an toàn. Để bịt kín lỗ hổng cấu trúc ở phần đuôi này, MonadBFT đã thêm hai cơ chế quan trọng:
1）Cơ chế đề xuất lại cưỡng chế (Re-Proposal)
2）Chứng chỉ không chứng thực (NEC, No-Endorsement Certificate)
Cơ chế đề xuất lại (Re-Proposal)
Trong giao thức BFT, thời gian được chia thành các vòng (gọi là view), mỗi vòng có một nhà lãnh đạo chịu trách nhiệm đề xuất khối mới. Nếu nhà lãnh đạo thất bại (ví dụ như không đề xuất khối kịp thời, hoặc đề xuất không hợp lệ), hệ thống sẽ chuyển sang vòng tiếp theo và bầu chọn nhà lãnh đạo mới.
MonadBFT đã thêm một cơ chế để đảm bảo rằng trong quá trình chuyển đổi view, bất kỳ khối nào được đề xuất một cách trung thực sẽ không bị "mất kết nối" do sự thay đổi lãnh đạo.
Khi nhà lãnh đạo hiện tại không còn hoạt động, các xác thực sẽ phát đi một thông điệp chuyển đổi vòng đã ký (view change), cho biết rằng vòng hiện tại đã hết thời gian.
Đặc biệt, thông điệp này không chỉ đơn thuần là "hết thời gian", mà còn phải bao gồm thông tin về khối mà người xác thực đã bỏ phiếu lần cuối, tương đương với việc nói: "Tôi không nhận được đề xuất hợp pháp, đây là khối mới nhất mà tôi thấy."
Lãnh đạo mới sẽ thu thập các thông điệp quá thời gian này từ một siêu đa số (2f+1) các trình xác thực và kết hợp chúng thành một chứng chỉ quá thời gian (Timeout Certificate, TC). TC này đại diện cho: khi vòng trước thất bại, toàn bộ mạng lưới có một bức ảnh nhận thức thống nhất về "khối đầu chuỗi". Lãnh đạo mới sẽ chọn ra khối có độ cao cao nhất (hoặc số lượt xem mới nhất), được gọi là high_tip.
Yêu cầu MonadBFT: Đề xuất của nhà lãnh đạo mới phải bao gồm một TC hợp pháp và phải đề xuất lại khối tạm dừng cao nhất trong TC, để khối này có cơ hội được xác nhận lại.
Tại sao? Như chúng tôi đã đề cập trước đó: Chúng tôi 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 Bob của view 6 không trực tuyến, không thể thúc đẩy tiến trình chuỗi. Khi Carol đảm nhận vai trò người lãnh đạo view 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. Như vậy, công sức chân chính của Alice sẽ không bị lã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 này, hoặc
Trả về một thông điệp "không chứng thực" (No-Endorsement, NE) đã được ký, thể hiện rằng mình không có khối này (cơ chế sẽ được giới thiệu sau). (Tối đa f nút Byzantine có thể chọn bỏ qua 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 rằng cô ấy sẽ không bị "trừng phạt" vì sự thất bại của người lãnh đạo ở vòng trước.
Cơ chế đề xuất lại này có vai trò rõ ràng: đảm bảo rằng việc tiến triển của chuỗi là công bằng, và bất kỳ công việc hợp lệ nào cũng sẽ không bị bỏ qua một cách lén lút do gặp vận xui hoặc có người quấy rối.
Chứng chỉ không có bảo lãnh (NEC)
Tiếp tục với ví dụ trước: Sau khi vòng của Bob hết thời gian, Carol yêu cầu các xác nhận viên khác cung cấp khối high_tip (tức là khối của Alice). Lúc này, ít nhất 2f+1 xác nhận viên sẽ phản hồi:
Cung cấp khối của Alice
Gửi một tin nhắn NE được ký, cho thấy rằng mình không nhận được khối của Alice.
Chỉ cần Carol nhận được khối của Alice, cô ấy phải đề xuất lại theo quy tắc. Chỉ khi ít nhất có f+1 xác thực viên ký vào thông điệp NE, Carol mới có thể bỏ qua khối đó và đề xuất một cái mới.
Tại sao là f+1? Trong một hệ thống BFT gồm 3f+1 người xác thực, tối đa chỉ có f người có thể làm sai. Nếu khối của Alice thực sự nhận được phiếu bầu của siêu đa số, thì ít nhất có 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", thì cô ấy phải đưa ra f+1 chữ ký của các xác nhận viên, chứng minh rằng những người này đều chưa nhận được. Điều này tạo thành một chứng chỉ không có sự chứng thực (No-Endorsement Certificate, NEC).
NEC là chứng chỉ "miễn trừ" dẫn đầu: nó là một bằng chứng có thể xác minh, 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 là bỏ qua một cách ác ý, mà là "từ bỏ" một cách có lý có chứng.
Đề xuất lại + Chứng chỉ không bảo lãnh = Giải quyết phân nhánh phần cuố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 ủng hộ (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 thành việc gửi cuối cùng cho khối "gần được xác nhận";
Cung cấp đủ bằng chứng để chứng minh rằng khối này chưa đủ điều kiện để được xác nhận,
Nếu không, không được 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 số phiếu hợp pháp đa số sẽ không bị bỏ qua do sai sót của lãnh đạo hoặc cố tình lẩn tránh.
Rủi ro cấu trúc của các nhánh cuối cùng đã được hệ thống hóa giải, giao thức có thể tạo ra ràng buộc rõ ràng đối với hành vi nhảy cóc không đúng cách.
Nếu một nhà 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 bằng chứng NEC, giao thức sẽ ngay lập tức phát hiện và từ chối hành vi đó. Hành vi bỏ qua không có bằng chứng mã hóa sẽ được coi là bất hợp pháp và sẽ không nhận được sự hỗ trợ từ sự đồng thuận của mạng.
Từ góc độ kích thích kinh tế, thiết kế này cung cấp sự bảo vệ rõ ràng cho những người xác thực:
Chỉ cần là khối được đưa ra một cách trung thực và nhận được sự hỗ trợ của cuộc bỏ phiếu, thì phần thưởng của nó sẽ không bị tước đi do lỗi ở các bước tiếp theo;
Ngay cả trong các tình huống cực đoan, chẳng hạn như khi một nút cố tình bỏ qua vòng đề xuất của chính mình, cố gắng hỗ trợ người khác chiếm đoạt MEV của khối trước, giao thức cũng sẽ buộc các lãnh đạo kế tiếp ưu tiên đề xuất lại khối gốc, khiến kẻ tấn công không thể thu được lợi ích 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 của giao thức để nâng cao tính bảo mật.
Trước đây, một số thiết kế để đối phó với phân nhánh đuôi (như giao thức BeeGees) mặc dù có khả năng bảo vệ nhất định, nhưng thường phụ thuộc vào độ phức tạp giao tiếp cao (n²) hoặc kích hoạt lại quy trình giao tiếp trong mỗi vòng, điều này sẽ làm tăng đáng kể gánh nặng cho hệ thống trong thực tế.
Chiến lược thiết kế của MonadBFT thì tinh vi hơn nhiều:
Chỉ khởi động giao tiếp bổ sung (như thông báo hết thời gian, đề xuất lại khối) khi có sự cố trong việc xem hoặc có ngoại lệ. Trong hầu hết các trường hợp lãnh đạo trung thực liên tục xuất khối, giao thức vẫn duy trì trạng thái hoạt động nhẹ nhàng và hiệu quả.
Sự cân bằng động giữa hiệu suất và tính 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 thế hệ trước.
Tóm tắt
Bài viết này xem lại cơ chế cơ bản của sự đồng thuận PBFT truyền thống, tổng hợp con đường phát triển của giao thức HotStuff, và nhấn mạnh cách MonadBFT giải quyết vấn đề phân nhánh cuối cùng nội sinh của HotStuff từ cấu trúc lớp giao thức.
Phân nhánh ở cuối có thể làm biến dạng động lực kinh tế của người đề xuất khối, đồng thời tạo ra mối đe dọa tiềm tàng đối với hoạt động của mạng lưới. MonadBFT bằng cách giới thiệu cơ chế đề xuất lại và chứng chỉ không cần bảo lãnh (NEC), đảm bảo rằng bất kỳ khối nào được đề xuất bởi lãnh đạo trung thực và nhận được phiếu bầu quá bán hợp pháp sẽ không bị bỏ qua hoặc bị bỏ rơi.
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:
1）Định tính cuối cùng (Speculative Finality)
2）Phản ứng lạc quan (Optimistic Responsiveness)
Và phân tích thêm ý nghĩa thực tế của những cơ chế này đối với các xác thực viên và nhà phát triển.
Chưa xong.
Xem bản gốc
Nội dung chỉ mang tính chất tham khảo, không phải là lời chào mời hay đề nghị. Không cung cấp tư vấn về đầu tư, thuế hoặc pháp lý. Xem Tuyên bố miễn trừ trách nhiệm để biết thêm thông tin về rủi ro.
MonadBFT: Định nghĩa lại an ninh nhận thức chung Blockchain, tạm biệt rủi ro phân nhánh đuôi.
Tác giả: michaellwy
Cốt lõi của blockchain nằm ở việc đạt được một sự đồng thuận toàn cầu nghiêm ngặt (strict global consensus): tức là, bất kể các nút mạng phân bố ở quốc gia nào, múi giờ nào, tất cả người tham gia cuối cùng phải đồng ý về một tập hợp các 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ị mấ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 lòng", duy trì sự nhất quán?
Đây là vấn đề mà giao thức đồng thuận cần giải quyết. Nó về cơ bản là một tập hợp các quy tắc để hướng dẫn một nhóm các nút độc lập, thậm chí không hoàn toàn đáng tin cậy, làm thế nào để đạt được quyết định thống nhất 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 sẽ mở ra một số tính năng chính, chẳng hạn như bảo vệ tài sản 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 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ể có hai khối mâu thuẫn được xác nhận.
Mạng phải tiếp tục tiến về phía trước và không bị kẹt hoặc tắt.
MonadBFT là bước đột phá công nghệ mới nhất trong hướng này.
Tổng quan ngắn gọn về sự tiến hóa của giao thức đồng thuận
Trên thực tế, lĩnh vực cơ chế đồng thuận đã được nghiên cứu trong nhiều thập kỷ. Các giao thức sớm nhất, chẳng hạn như PBFT (Practical Byzantine Fault Tolerance), đã có thể đối phó với một tình huống rất thực tế: ngay cả khi một số nút trong mạng nằm ngoài chuỗi, làm điều ác và nói chuyện 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ể đồng ý.
Các phương pháp thiết kế của những giao thức sớm này khá "truyền thống": mỗi vòng sẽ chọn ra một người lãnh đạo, người này sẽ khởi xướng đề xuất, các xác thực viên khác sẽ thực hiện nhiều vòng bỏ phiếu về đề 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 một số giai đoạn, chẳng hạn như pre-prepare, prepare, commit, reply. Ở mỗi giai đoạn, tất cả các xác thực viên đều phải giao tiếp với nhau. Nói cách khác, mỗi người đều phải nói với từng người một, khối lượng tin nhắn tăng theo kiểu 'mạng lưới' bùng nổ.
Độ phức tạp của cấu trúc giao tiếp này là n² - tức là, nếu trong mạng có 100 người xác thực, thì 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 phải là vấn đề lớn trong mạng nhỏ, nhưng một khi số lượng người xác nhận 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, hiệu suất sẽ bị giảm sút.
Nguồn thông tin:
Cấu trúc giao tiếp thứ cấp "mỗi người đều phải giao tiếp với mỗi người" này thực sự rất kém hiệu quả. Ví dụ, trong một mạng lưới có 100 người xác thực, mỗi vòng đồng thuận có thể phải xử lý hàng nghìn tin nhắn.
Điều này có thể xử lý trong một vòng tròn nhỏ, nhưng nếu đặt trong một mạng lưới chuỗi mở, toàn cầu, thì tải trọng giao tiếp ngay lập tức trở nên không thể chấp nhận được. Vì vậy, các giao thức BFT sớm như PBFT và Tendermint thường chỉ được sử dụng trong các tình huống có giấy phép (permissioned network) hoặc trong các hệ thống có số lượng người xác thực rất ít, mới có thể hoạt động một cách khó khăn.
Để cho giao thức BFT cũng có thể thích ứng với môi trường công khai không cần giấy phép, một số thiết kế thế hệ mới bắt đầu hướng tới phương thức giao tiếp nhẹ nhàng hơn: để mỗi người xác thực chỉ giao tiếp với người lãnh đạo, thay vì tất cả cùng truyền đạt cho nhau.
Điều này đã tối ưu hóa độ phức tạp của thông điệp từ n² xuống n - giảm nhẹ gánh nặng cho hệ thống rất nhiều.
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. Nguyên tắc 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 khiển.
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ế của nó, mỗi trình xác thực chỉ cần gửi phiếu bầu của họ cho người lãnh đạo hiện tại, người sau đó đóng gói các phiếu bầu đó để tạo Chứng chỉ Đại biểu (QC).
QC này thực chất là một chữ ký tập thể, chứng minh với toàn bộ mạng rằng: "Đa số các nút đã đồng ý với đề xuất này."
So với đó, mô hình giao tiếp của PBFT là "phát sóng toàn bộ", mọi người đều nói chuyện trong nhóm, tình hình trở nên rất 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ể có bao nhiêu người trong mạng, vẫn có thể duy trì hoạt động hiệu quả.
Hình trên so sánh cấu trúc giao tiếp phát tán của HotStuff với mô hình kết nối toàn mạng của PBFT.
Nguồn:
Ngoài giao tiếp tuyến tính, HotStuff còn có thể nâng cấp thêm thành phiên bản theo đường ống (HotStuff theo đường ống), nhằm nâng cao hiệu quả.
Trong HotStuff gốc, cùng một người xác thực sẽ liên tiếp đảm nhận vai trò lãnh đạo qua nhiều vòng cho đến khi một khối được xác nhận hoàn toàn. Quá trình này là "mỗi vòng xử lý một khối", mọi nỗ lực đều tập trung vào việc thúc đẩy khối hiện tại.
Và trong chuỗi HotStuff, cơ chế trở nên linh hoạt hơn: Mỗi vòng sẽ chọn ra một nhà lãnh đạo mới, và nhiệm vụ của mỗi nhà lãnh đạo có hai nhiệm vụ:
Một bên đóng gói phiếu bầu của vòng trước thành Chứng nhận Quorum (QC) và phát sóng đến toàn bộ mạng.
Một bên đưa ra một khối mới, chuẩn bị bắt đầu vòng tiếp theo.
Nói cách khác, nó không còn là "xác nhận cái này rồi 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 thay phiên nhau chịu trách nhiệm cho từng liên kết. Bit trước đề xuất một khối, bit tiếp theo xác nhận nó và chuyển sang đề xuất một khối mới và sự đồng thuận trên chuỗi được truyền lại như một cuộc đua tiếp sức.
Đây là nguồn gốc của phép ẩn dụ "dòng chảy": 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 thực hiện những cải tiến đáng kể so với BFT truyền thống theo hai chiều:
Một là giao tiếp nhẹ hơn, mỗi người xác thực chỉ cần giao tiếp với người lãnh đạo;
Thứ hai là hiệu suất xử lý cao hơn, 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 PoS hiện đại. Tuy nhiên, mọi thứ đều có hai mặt - mặc dù cấu trúc dây chuyền có 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ông dễ phát hiện.
Tiếp theo, chúng ta sẽ đi sâu vào vấn đề cốt lõi này: Phân nhánh đuôi (Tail Forking).
Vấn đề phân nhánh đuôi (Tail-Forking)
Mặc dù HotStuff - đặc biệt là phiên bản theo dòng - đã giải quyết vấn đề khả năng mở rộng của giao thức đồng thuận, nhưng nó cũng mang lại một số thách thức mới. Vấn đề quan trọng nhất, và cũng dễ bị bỏ qua nhất, đó là vấn đề "đường phân nhánh đuôi" (Tail Forking).
Phân nhánh cuối là gì? Có thể hiểu đơn giản là: một sự tái tổ chức khối bất ngờ xảy ra ở "đuôi chuỗi" của blockchain (reorg).
Cụ thể, có một khối, nó là hợp lệ, và đã được truyền thành công đến hầu hết các xác thực viên, còn nhận được đủ nhiều sự ủng hộ từ các phiếu bầu, theo lý mà nói, nó sẽ ngay lập tức đượ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 ở cùng độ cao.
Đây không phải là lỗi, cũng không phải là tấn công, mà là do cấu trúc thiết kế của giao thức có khả năng tồn tại "rơi chuỗi". Nghe có vẻ hơi 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 lãnh đạo trong dòng chảy HotStuff đều 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 nhà lãnh đạo trước đó, tạo ra QC (ví dụ như hoàn tất xác nhận cuối cùng cho Bₙ)
Hai nhiệm vụ này là song song, lần lượt tiếp sức. Nhưng vấn đề nằm ở đây.
Giả sử Alice là người lãnh đạo, cô ấy đã đề xuất khối Bₙ ở độ cao thứ n, khối này đã nhận được sự bỏ phiếu của đa số tuyệt đối và đã "gần như được xác nhận".
Tiếp theo, Bob sẽ đảm nhận vai trò lãnh đạo, tiếp tục thúc đẩy khối tiếp theo của chuỗi Bₙ₊₁, đồng thời cũng nên đóng gói QC (chứng minh đa số hợp pháp) của Bₙ vào đề xuất của mình, hoàn thành xác nhận cuối cùng của Bₙ.
Nhưng nếu Bob offline vào lúc này, hoặc cố tình không nộp QC của Bₙ, thì sẽ có vấn đề.
Bởi vì không ai thực hiện QC đóng gói cho khối của Alice, nên bản ghi bỏ phiếu của Bₙ không thể được truyền đi, và khối này lẽ ra nên được xác nhận, đã bị "lạnh" như vậy, cuối cùng bị toàn bộ mạng lưới bỏ qua.
Đây chính là bản chất của nhánh cuối: Khối của nhà lãnh đạo trước bị bỏ qua vì sự thiếu trách nhiệm hoặc ác ý của nhà lãnh đạo tiếp theo.
Tại sao phần đuôi lại bị phân nhánh nghiêm trọng?
Vấn đề phân nhánh ở cuối chủ yếu tập trung vào hai khía cạnh: 1) Cơ chế khuyến khích bị phá hủy, 2) Tính năng hoạt động của hệ thống bị đe dọa.
Đầu tiên, phần thưởng bị nuốt:
Nếu một khối bị loại bỏ, người lãnh đạo đề xuất nó không nhận được phần thưởng. Cho dù đó là phần thưởng khối hay phí giao dịch. Ví dụ: Alice đã đề xuất một khối hợp pháp và nhận được phiếu bầu đa số, nhưng do những sai lầm hoặc hành động độc hại của Bob, việc chặn không được xác nhận và cuối cùng Alice đã không nhận được một xu. Điều này dẫn đến một cấu trúc khuyến khích sai: các nút độc hại như Bob có thể "vặt" nguồn phần thưởng của họ bằng cách bỏ qua khối của đối thủ. Loại hành vi này không đòi hỏi một cuộc tấn công kỹ thuật, chỉ là một sự "không hợp tác" có chủ ý để làm suy yếu thu nhập của đối thủ cạnh tranh. Nếu loại điều này xảy ra lặp đi lặp lại, theo thời gian, nó sẽ làm giảm sự tham gia và công bằng của toàn bộ hệ thống, và thậm chí gây ra sự thông đồng giữa các nút.
Thứ hai, không gian tấn công MEV mở rộng:
Phuộc đuôi cũng đặt ra một vấn đề xảo quyệt nhưng nghiêm trọng hơn: có nhiều chỗ hơn cho MEV (Giá trị trích xuất tối đa) bị thao túng độc hại. Đâ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 cô ấy. 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 truyền 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 - làm cho MEV có được của riêng mình. Hành vi "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 các 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 việc 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, phá hủy đảm bảo cuối cùng, ảnh hưởng đến trải nghiệm người dùng:
Một trong những lợi thế lớn của BFT so với các giao thức giống Nakamoto là tính cuối cùng xác định: một khi một khối đã được cam kết, nó không thể được quay trở lại. Nhưng phuộc đuôi làm suy yếu sự đảm bảo này, đặc biệt là trên 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 thông lượng cao thường muốn có thể đọc dữ liệu ngay sau khi một khối được bỏ phiếu để giảm độ trễ và nếu khối bị loại bỏ đột ngột, nó có thể dẫn đến việc khôi phục trạng thái của người dùng - chẳng hạn như số dư tài khoản bất thường, giao dịch đòn bẩy cao vừa được hoàn thành biến mất mà không có lý do, đặt lại trạng thái trò chơi đột ngột, v.v.
Thứ tư, có thể gây ra sự cố dây chuyền:
Thông thường, việc phân nhánh ở phần cuối có thể chỉ khiến một khối bị xác nhận muộ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 liên tiếp vài lãnh đạo chọn bỏ qua khối trước đó, hệ thống có thể rơi vào trạng thái ngưng trệ, không ai muốn "nhận" khối trước. Toàn bộ chuỗi sẽ bị kẹt lại cho đến khi cuối cùng xuất hiện một lãnh đạo "sẵn sàng gánh vác trách nhiệm", mạng lưới mới có thể tiếp tục tiến lên.
Mặc dù trước đây cũng đã có một số giải pháp, chẳng hạn như cơ chế tránh phân nhánh cuối được đề xuất bởi giao thức BeeGees, nhưng thường phải hy sinh hiệu suất, chẳng hạn như tái đưa vào độ phức tạp của giao tiếp thứ cấp, không đáng.
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 cuối. Điểm mạnh của nó là: trong khi giải quyết các rủi ro cấu trúc, nó không hy sinh những lợi thế về hiệu suất mà HotStuff mang lại. Nói cách khác, MonadBFT không phải là bắt đầu lại từ đầu, mà là tiếp tục tối ưu hóa dựa trên khung chính của HotStuff. Nó giữ lại ba đặc điểm chính:
1）Lãnh đạo luân phiên (rotating leader): Mỗi vòng sẽ chọn ra một lãnh đạo mới để thúc đẩy chuỗi;
2）Gửi theo quy trình (pipelined commits): Nhiều quá trình xác nhận khối có thể diễn ra chồng chéo.
Nhưng chỉ dựa vào ba điểm này vẫn chưa đủ an toàn. Để bịt kín lỗ hổng cấu trúc ở phần đuôi này, MonadBFT đã thêm hai cơ chế quan trọng:
1）Cơ chế đề xuất lại cưỡng chế (Re-Proposal)
2）Chứng chỉ không chứng thực (NEC, No-Endorsement Certificate)
Cơ chế đề xuất lại (Re-Proposal)
Trong giao thức BFT, thời gian được chia thành các vòng (gọi là view), mỗi vòng có một nhà lãnh đạo chịu trách nhiệm đề xuất khối mới. Nếu nhà lãnh đạo thất bại (ví dụ như không đề xuất khối kịp thời, hoặc đề xuất không hợp lệ), hệ thống sẽ chuyển sang vòng tiếp theo và bầu chọn nhà lãnh đạo mới.
MonadBFT đã thêm một cơ chế để đảm bảo rằng trong quá trình chuyển đổi view, bất kỳ khối nào được đề xuất một cách trung thực sẽ không bị "mất kết nối" do sự thay đổi lãnh đạo.
Khi nhà lãnh đạo hiện tại không còn hoạt động, các xác thực sẽ phát đi một thông điệp chuyển đổi vòng đã ký (view change), cho biết rằng vòng hiện tại đã hết thời gian.
Đặc biệt, thông điệp này không chỉ đơn thuần là "hết thời gian", mà còn phải bao gồm thông tin về khối mà người xác thực đã bỏ phiếu lần cuối, tương đương với việc nói: "Tôi không nhận được đề xuất hợp pháp, đây là khối mới nhất mà tôi thấy."
Lãnh đạo mới sẽ thu thập các thông điệp quá thời gian này từ một siêu đa số (2f+1) các trình xác thực và kết hợp chúng thành một chứng chỉ quá thời gian (Timeout Certificate, TC). TC này đại diện cho: khi vòng trước thất bại, toàn bộ mạng lưới có một bức ảnh nhận thức thống nhất về "khối đầu chuỗi". Lãnh đạo mới sẽ chọn ra khối có độ cao cao nhất (hoặc số lượt xem mới nhất), được gọi là high_tip.
Yêu cầu MonadBFT: Đề xuất của nhà lãnh đạo mới phải bao gồm một TC hợp pháp và phải đề xuất lại khối tạm dừng cao nhất trong TC, để khối này có cơ hội được xác nhận lại.
Tại sao? Như chúng tôi đã đề cập trước đó: Chúng tôi 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 Bob của view 6 không trực tuyến, không thể thúc đẩy tiến trình chuỗi. Khi Carol đảm nhận vai trò người lãnh đạo view 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. Như vậy, công sức chân chính của Alice sẽ không bị lã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 này, hoặc
Trả về một thông điệp "không chứng thực" (No-Endorsement, NE) đã được ký, thể hiện rằng mình không có khối này (cơ chế sẽ được giới thiệu sau). (Tối đa f nút Byzantine có thể chọn bỏ qua 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 rằng cô ấy sẽ không bị "trừng phạt" vì sự thất bại của người lãnh đạo ở vòng trước.
Cơ chế đề xuất lại này có vai trò rõ ràng: đảm bảo rằng việc tiến triển của chuỗi là công bằng, và bất kỳ công việc hợp lệ nào cũng sẽ không bị bỏ qua một cách lén lút do gặp vận xui hoặc có người quấy rối.
Chứng chỉ không có bảo lãnh (NEC)
Tiếp tục với ví dụ trước: Sau khi vòng của Bob hết thời gian, Carol yêu cầu các xác nhận viên khác cung cấp khối high_tip (tức là khối của Alice). Lúc này, ít nhất 2f+1 xác nhận viên sẽ phản hồi:
Cung cấp khối của Alice
Gửi một tin nhắn NE được ký, cho thấy rằng mình không nhận được khối của Alice.
Chỉ cần Carol nhận được khối của Alice, cô ấy phải đề xuất lại theo quy tắc. Chỉ khi ít nhất có f+1 xác thực viên ký vào thông điệp NE, Carol mới có thể bỏ qua khối đó và đề xuất một cái mới.
Tại sao là f+1? Trong một hệ thống BFT gồm 3f+1 người xác thực, tối đa chỉ có f người có thể làm sai. Nếu khối của Alice thực sự nhận được phiếu bầu của siêu đa số, thì ít nhất có 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", thì cô ấy phải đưa ra f+1 chữ ký của các xác nhận viên, chứng minh rằng những người này đều chưa nhận được. Điều này tạo thành một chứng chỉ không có sự chứng thực (No-Endorsement Certificate, NEC).
NEC là chứng chỉ "miễn trừ" dẫn đầu: nó là một bằng chứng có thể xác minh, 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 là bỏ qua một cách ác ý, mà là "từ bỏ" một cách có lý có chứng.
Đề xuất lại + Chứng chỉ không bảo lãnh = Giải quyết phân nhánh phần cuố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 ủng hộ (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 thành việc gửi cuối cùng cho khối "gần được xác nhận";
Cung cấp đủ bằng chứng để chứng minh rằng khối này chưa đủ điều kiện để được xác nhận,
Nếu không, không được 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 số phiếu hợp pháp đa số sẽ không bị bỏ qua do sai sót của lãnh đạo hoặc cố tình lẩn tránh.
Rủi ro cấu trúc của các nhánh cuối cùng đã được hệ thống hóa giải, giao thức có thể tạo ra ràng buộc rõ ràng đối với hành vi nhảy cóc không đúng cách.
Nếu một nhà 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 bằng chứng NEC, giao thức sẽ ngay lập tức phát hiện và từ chối hành vi đó. Hành vi bỏ qua không có bằng chứng mã hóa sẽ được coi là bất hợp pháp và sẽ không nhận được sự hỗ trợ từ sự đồng thuận của mạng.
Từ góc độ kích thích kinh tế, thiết kế này cung cấp sự bảo vệ rõ ràng cho những người xác thực:
Chỉ cần là khối được đưa ra một cách trung thực và nhận được sự hỗ trợ của cuộc bỏ phiếu, thì phần thưởng của nó sẽ không bị tước đi do lỗi ở các bước tiếp theo;
Ngay cả trong các tình huống cực đoan, chẳng hạn như khi một nút cố tình bỏ qua vòng đề xuất của chính mình, cố gắng hỗ trợ người khác chiếm đoạt MEV của khối trước, giao thức cũng sẽ buộc các lãnh đạo kế tiếp ưu tiên đề xuất lại khối gốc, khiến kẻ tấn công không thể thu được lợi ích 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 của giao thức để nâng cao tính bảo mật.
Trước đây, một số thiết kế để đối phó với phân nhánh đuôi (như giao thức BeeGees) mặc dù có khả năng bảo vệ nhất định, nhưng thường phụ thuộc vào độ phức tạp giao tiếp cao (n²) hoặc kích hoạt lại quy trình giao tiếp trong mỗi vòng, điều này sẽ làm tăng đáng kể gánh nặng cho hệ thống trong thực tế.
Chiến lược thiết kế của MonadBFT thì tinh vi hơn nhiều:
Chỉ khởi động giao tiếp bổ sung (như thông báo hết thời gian, đề xuất lại khối) khi có sự cố trong việc xem hoặc có ngoại lệ. Trong hầu hết các trường hợp lãnh đạo trung thực liên tục xuất khối, giao thức vẫn duy trì trạng thái hoạt động nhẹ nhàng và hiệu quả.
Sự cân bằng động giữa hiệu suất và tính 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 thế hệ trước.
Tóm tắt
Bài viết này xem lại cơ chế cơ bản của sự đồng thuận PBFT truyền thống, tổng hợp con đường phát triển của giao thức HotStuff, và nhấn mạnh cách MonadBFT giải quyết vấn đề phân nhánh cuối cùng nội sinh của HotStuff từ cấu trúc lớp giao thức.
Phân nhánh ở cuối có thể làm biến dạng động lực kinh tế của người đề xuất khối, đồng thời tạo ra mối đe dọa tiềm tàng đối với hoạt động của mạng lưới. MonadBFT bằng cách giới thiệu cơ chế đề xuất lại và chứng chỉ không cần bảo lãnh (NEC), đảm bảo rằng bất kỳ khối nào được đề xuất bởi lãnh đạo trung thực và nhận được phiếu bầu quá bán hợp pháp sẽ không bị bỏ qua hoặc bị bỏ rơi.
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:
1）Định tính cuối cùng (Speculative Finality)
2）Phản ứng lạc quan (Optimistic Responsiveness)
Và phân tích thêm ý nghĩa thực tế của những cơ chế này đối với các xác thực viên và nhà phát triển.
Chưa xong.