
Con đường chống kiểm duyệt của Ethereum: BRAID và FOCIL, ai vượt trội hơn?
Tuyển chọn TechFlowTuyển chọn TechFlow

Con đường chống kiểm duyệt của Ethereum: BRAID và FOCIL, ai vượt trội hơn?
BRAID là một phương án cải tiến cho đề xuất viên đa đồng thời (MCP). FOCL là một phương án cải tiến cho danh sách bao gồm (IL).
Bài viết: 0XNATALIE
Trong quá trình tạo và xác thực khối trên Ethereum, các nhà xây dựng (builder) chịu trách nhiệm sắp xếp giao dịch và gửi khối đến người đề xuất (proposer) thông qua cơ chế đấu giá. Người đề xuất sau đó chọn một khối để ký và đề xuất lên chuỗi khối. Vì người đề xuất là một thực thể duy nhất có quyền lựa chọn cuối cùng, điều này dẫn đến nguy cơ cấu kết giữa người đề xuất và nhà xây dựng nhằm kiểm duyệt giao dịch.
Một trong những giá trị cốt lõi của blockchain là khả năng chống kiểm duyệt – tức là bất kỳ ai cũng có thể thực hiện giao dịch mà không bị can thiệp bởi một bên trung tâm nào. Khi người đề xuất có thể kiểm soát việc giao dịch nào được đưa vào khối, đặc điểm này sẽ bị đe dọa, làm tổn hại đến tính công bằng và minh bạch. Ngoài ra, họ có thể lợi dụng quyền lực này để thao túng thứ tự giao dịch trong khối nhằm thu lợi kinh tế bổ sung, dẫn đến vấn đề MEV.
Các giải pháp chống kiểm duyệt hiện tại
Để giải quyết thách thức này, cộng đồng đã đề xuất nhiều giải pháp chống kiểm duyệt, ví dụ như Danh sách Bao gồm Buộc (FOCIL - Forced Inclusion List). Trong cơ chế FOCIL, mỗi slot (khe thời gian) sẽ chọn ngẫu nhiên một nhóm bộ xác thực để hình thành Ủy ban Danh sách Bao gồm. Các thành viên ủy ban này sẽ tạo danh sách bao gồm cục bộ dựa trên quan điểm chủ quan về mempool (hàng đợi giao dịch) của họ và phát tán danh sách đó. Người đề xuất có trách nhiệm thu thập và tổng hợp các danh sách cục bộ này thành một danh sách tổng hợp, rồi đưa vào khối. Cơ chế này đảm bảo tính công bằng của khối, vì các bộ xác thực sẽ kiểm tra tính đúng đắn của danh sách tổng hợp dựa trên danh sách cục bộ mà họ đã phát trước đó; chỉ những khối tuân thủ quy tắc đồng thuận mới được chấp nhận và thêm vào blockchain.
Bên cạnh FOCIL, cộng đồng cũng thảo luận về phương án Nhiều Người Đề xuất Đồng thời (MCP - Multiple Concurrent Proposers). Khái niệm này lần đầu tiên được Max Resnick đề xuất trong cơ chế Multiplicity, nhằm phân tán quyền lực bằng cách giới thiệu nhiều người đề xuất khối song song, giảm khả năng kiểm duyệt giao dịch của một nút đơn lẻ. Trong cơ chế Multiplicity, mỗi bộ xác thực chọn một phần giao dịch từ mempool của mình để tạo thành một "gói giao dịch đặc biệt". Các bộ xác thực ký gói giao dịch này và gửi đến người đề xuất ở vòng hiện tại. Người đề xuất khi nhận được, phải đưa ít nhất 2/3 số gói giao dịch vào khối mà họ đề xuất. Chỉ khi đó, khối mới được coi là hợp lệ. Cơ chế này đảm bảo rằng người đề xuất không thể đơn phương quyết định nội dung khối, từ đó giảm thiểu khả năng kiểm duyệt. Để khuyến khích người đề xuất bao gồm giao dịch một cách công bằng hơn, cơ chế áp dụng quy tắc "tiền boa có điều kiện": chỉ những người đề xuất thực sự đưa giao dịch vào khối mới được chia tiền boa. Tiền boa cho giao dịch không tự động thuộc về người đề xuất đầu tiên chứa nó, mà được phân phối theo điều kiện cho tất cả những người đề xuất thực sự chứa giao dịch đó. Điều này làm tăng chi phí kiểm duyệt — nếu muốn kiểm duyệt, kẻ xấu phải hối lộ tất cả các người đề xuất đã chứa giao dịch.
BRAID: Giải pháp MCP được cải tiến
Dựa trên nền tảng Multiplicity, Max Resnick tiếp tục đề xuất BRAID — một triển khai MCP phức tạp và hoàn thiện hơn. Tại hội thảo do Paradigm tổ chức với chủ đề "DeFi in MEV Era", Max đã giới thiệu BRAID. BRAID đạt được MCP bằng cách cho phép nhiều người đề xuất đưa ra khối trên các chuỗi song song khác nhau, đồng thời sử dụng cơ chế đồng thuận đồng bộ để duy trì tính nhất quán giữa các chuỗi. Mỗi chuỗi con có người đề xuất riêng, và tất cả người đề xuất cùng công bố khối của họ trong cùng một slot. Lớp thực thi Ethereum tập hợp toàn bộ giao dịch từ các khối được tạo trên các chuỗi con trong slot đó, hình thành một khối thực thi, sau đó loại bỏ trùng lặp, sắp xếp và thực thi giao dịch theo các quy tắc định sẵn, từ đó giảm khả năng thao túng bản ghi giao dịch của bất kỳ thực thể đơn lẻ nào.
Thiết kế BRAID không giới thiệu vai trò bổ sung nào, do đó tránh được sự phức tạp đến từ các cơ chế khuyến khích/phạt, tuy nhiên việc triển khai tương đối phức tạp, đòi hỏi phải đồng bộ hóa và xử lý dữ liệu giữa nhiều chuỗi con.

Vấn đề của cơ chế BRAID
Jonahb từ Blockchain Capital chỉ ra một vấn đề tồn tại trong cơ chế BRAID: mô hình "tiền boa có điều kiện" yêu cầu thanh khoản, từ đó ảnh hưởng đến trải nghiệm người dùng. Mô hình này là một chiến lược định giá động, yêu cầu người dùng dự trữ một lượng thanh khoản nhất định để đảm bảo tính chống kiểm duyệt cho giao dịch. Khi gửi giao dịch, người dùng cần thiết lập hai mức phí boa (T và t). Số tiền boa thực tế cuối cùng phụ thuộc vào số lượng người đề xuất đã bao gồm giao dịch đó.
-
Phí boa cao T: đại diện cho mức phí tối đa mà người dùng sẵn sàng trả để đảm bảo giao dịch không bị kiểm duyệt. Mục đích là khuyến khích người đề xuất bao gồm giao dịch khi không có người đề xuất nào khác muốn làm vậy. Nếu chỉ có một người đề xuất đồng ý chứa giao dịch, anh ta sẽ nhận toàn bộ T.
-
Phí boa thấp t: đây là mức phí thấp mà người dùng đặt, và nếu giao dịch được nhiều người đề xuất cùng chứa, người dùng chỉ cần trả t. Số tiền t này sẽ được chia đều giữa các người đề xuất. Nếu người dùng không quan tâm đến khả năng chống kiểm duyệt, họ có thể đặt T = t và chỉ gửi giao dịch đến một người đề xuất duy nhất.
Tuy nhiên, yêu cầu thanh khoản bổ sung này làm tăng độ phức tạp và chi phí khi tham gia giao dịch trên blockchain. Người dùng phải dành sẵn một khoản tiền trong lúc thực hiện giao dịch chỉ để đảm bảo khả năng chống kiểm duyệt. Những khoản tiền này sẽ bị đóng băng cho đến khi không còn cần dùng đến.
Trước vấn đề này, Jonahb đề xuất hai giải pháp:
-
Proof of Post-State Liquidity (Bằng chứng thanh khoản sau trạng thái): Người dùng khi gửi giao dịch cung cấp một bằng chứng cho thấy họ sẽ có đủ thanh khoản để trả T sau khi giao dịch được thực thi (ví dụ: sau giao dịch, người dùng sẽ có $1M thanh khoản). Như vậy, ngay cả khi chưa có đủ tiền trả T trước giao dịch, người dùng vẫn có thể thực hiện nhờ cam kết thanh toán sau. Thách thức của phương pháp này là người đề xuất phải biết trước trạng thái cuối cùng của giao dịch trước khi thực thi, nhưng hầu hết các giao dịch tài chính liên quan đến trạng thái chung (ví dụ: nhiều giao dịch dùng chung số dư tài khoản), nên người đề xuất không thể xác định chính xác trạng thái sau khi thực thi trước khi thứ tự giao dịch được cố định. Điều này đòi hỏi phải có bằng chứng tùy chỉnh cho từng loại giao dịch, khiến tính khả thi thực tiễn thấp.
-
Censorship Insurance (Bảo hiểm chống kiểm duyệt): Giới thiệu nhà cung cấp bảo hiểm chống kiểm duyệt (CI Provider) để bảo lãnh khoản T cho người dùng. Người dùng trả một khoản phí bảo hiểm rT, trong đó r được tính toán dựa trên khả năng giao dịch bị kiểm duyệt. Giải pháp này không chỉ giảm nhu cầu người dùng phải chuẩn bị lượng lớn thanh khoản ngay lập tức, mà còn giúp CI cảnh báo người dùng khi T quá thấp và có nguy cơ kiểm duyệt cao. Tuy nhiên, việc xây dựng thị trường giữa người dùng và nhà cung cấp CI cần thời gian.
Quan điểm của cộng đồng về FOCIL và BRAID
Terence, nhà phát triển client Ethereum Prysm, cho rằng một ưu điểm nổi bật của BRAID là không cần thêm người tham gia. Trong hầu hết các thiết kế Danh sách Bao gồm (IL) như FOCIL, cần có một bên tham gia bổ sung, điều này làm tăng áp lực về thời gian trong khe thời gian Ethereum — ví dụ như thời gian gửi IL, cập nhật giá đấu giá, và thời gian bộ xác thực kiểm tra IL. Tuy nhiên, FOCIL dễ triển khai và linh hoạt hơn so với BRAID.
Dan Robinson, nhà nghiên cứu tại Paradigm, đánh giá cao thiết kế của BRAID trong việc xử lý thứ tự ưu tiên giao dịch, thay vì để người lãnh đạo (người đề xuất đơn lẻ) tự quyết, từ đó hiệu quả giảm MEV. Hơn nữa, cơ chế tiền boa có điều kiện trong BRAID khuyến khích hành vi không kiểm duyệt — điều mà FOCIL chưa phản ánh rõ.
Dev, một nhà phát triển, thích FOCIL hơn MCP, cho rằng FOCIL vượt trội hơn trong việc cung cấp khả năng chống kiểm duyệt mạnh mẽ và đơn giản hóa việc triển khai. Anh cũng đưa ra một số cải tiến giúp FOCIL dễ thực hiện hơn.
Barnabe.eth, nhà nghiên cứu Ethereum, cho rằng FOCIL là một cơ chế khá tổng quát và có khả năng mở rộng. Anh thừa nhận BRAID có thể cải thiện một số khía cạnh so với các đảm bảo mà FOCIL mang lại, nhưng thận trọng trước việc từ bỏ hoàn toàn mô hình dựa trên người lãnh đạo, và cho rằng hiện tại đây chưa phải là sự đồng thuận, cần thêm nhiều nghiên cứu để chứng minh tính khả thi.
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














