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