Trong quá trình sản xuất và xác nhận khối Ethereum, người xây dựng có trách nhiệm sắp xếp giao dịch và gửi các khối đến người đề xuất thông qua cơ chế đấu giá. Người đề xuất sau đó chọn một khối để ký và đề xuất nó vào chuỗi khối. Khi người đề xuất có quyền quyết định cuối cùng như một thực thể đơn lẻ, có nguy cơ kết hợp giữa người đề xuất và người xây dựng để 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, có nghĩa là giao dịch có thể được tiến hành mà không bị can thiệp từ các cơ quan trung ương. Khi người đề xuất kiểm soát giao dịch nào được bao gồm trong một khối, tính năng này bị đe dọa, gây tổn hại đến sự công bằng và minh bạch. Hơn nữa, quyền lực này có thể được lợi dụng để thao túng thứ tự các giao dịch trong một khối, dẫn đến lợi ích kinh tế bổ sung và gây ra các vấn đề liên quan đến Giá trị khai thác của Nhà khai thác (MEV).

Giải pháp chống kiểm duyệt hiện có

Để đối phó với thách thức này, cộng đồng đã đề xuất một số giải pháp chống kiểm duyệt, như Danh sách Bắt Buộc (FIL)FOCILTrong cơ chế FOCIL, một nhóm người xác thực được chọn ngẫu nhiên cho mỗi khe cắm để tạo thành một ủy ban danh sách bao gồm. Những thành viên của ủy ban này tạo ra danh sách bao gồm cục bộ dựa trên quan điểm chủ quan của họ về mempool và phát sóng chúng. Người đề xuất sau đó chịu trách nhiệm thu thập và tổng hợp những danh sách cục bộ này thành một danh sách tổng hợp duy nhất để được bao gồm trong khối. Cơ chế này đảm bảo sự công bằng trong việc bao gồm khối vì người xác thực xác minh danh sách tổng hợp so với các danh sách cục bộ được phát sóng trước đó, và chỉ có các khối đáp ứng các quy tắc đồng thuận mới được chấp nhận và thêm vào blockchain.

Ngoài FOCIL, cộng đồng cũng đã thảo luận về các chương trình Đề xuất Đồng thời Nhiều Bên (MCP). Khái niệm này ban đầu được đề xuất bởi Max ResnicktrongĐa dạng cơ chế, nhằm mục đích 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, làm giảm khả năng kiểm duyệt các giao dịch của bất kỳ nút đơn lẻ nào. Trong cơ chế Đa dạng, mỗi trình xác thực chọn một phần giao dịch từ mempool của riêng họ để tạo thành một "gói giao dịch đặc biệt". Những người xác thực này ký các gói giao dịch đã chọn của họ và gửi chúng cho người đề xuất vòng hiện tại. Người đề xuất phải bao gồm ít nhất 2/3 các gói giao dịch này trong khối mà họ đề xuất để nó đượ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 của khối, do đó làm giảm khả năng kiểm duyệt. Để khuyến khích hơn nữa những người đề xuất bao gồm các giao dịch một cách công bằng, cơ chế này thực hiện quy tắc "tiền boa có điều kiện", trong đó chỉ những người đề xuất bao gồm giao dịch mới nhận được phí giao dịch. Phí giao dịch không được tự động trao cho người đề xuất đầu tiên bao gồm giao dịch mà được phân phối cho tất cả những người đề xuất thực sự bao gồm giao dịch dựa trên các điều kiện cụ thể. Điều này làm tăng chi phí kiểm duyệt, vì hối lộ tất cả những người đề xuất bao gồm giao dịch sẽ là cần thiết.

BRAID: Một cài đặt MCP cải tiến

Xây dựng trên khái niệm Multiplicity, Max Resnick giới thiệu BRAID, một cài đặt phức tạp và hoàn thiện hơn của MCP. Max đã trình bày BRAIDtại hội thảo “DeFi trong thời đại MEV” được tổ chức bởi Paradigm. BRAID đạt được MCP bằng cách cho phép nhiều người đề xuất khối trên các chuỗi song song khác nhau và sử dụng cơ chế đồng thuận đồng bộ để duy trì tính nhất quán giữa các chuỗi này. Mỗi chuỗi có đề xuất riêng của mình, và tất cả các đề xuất viên đồng thời phát hành khối của họ trong cùng một khe. Lớp thực thi Ethereum tổng hợp các khối được tạo ra bởi tất cả các chuỗi con trong khe đó, hình thành một khối thực thi. Sau đó, nó loại bỏ bản sao, sắp xếp và thực thi các giao dịch này theo các quy tắc được xác định trước, giảm khả năng của bất kỳ thực thể đơn lẻ nào để thao tác các bản ghi giao dịch.

Thiết kế của BRAID tránh việc giới thiệu các vai trò bổ sung, do đó tránh các khó khăn liên quan đến cơ chế động viên/ phạt. Tuy nhiên, việc triển khai của nó tương đối phức tạp, đòi hỏi phối hợp đồng bộ các tiểu chuỗi và xử lý dữ liệu.

Vấn đề với cơ chế BRAID

Jonahbtừ nhóm Blockchain Capital đã chỉ ra mộtvấn đềvới cơ chế BRAID: mô hình “gợi ý điều kiện” đặt yêu cầu về tính thanh khoản, ảnh hưởng đến trải nghiệm người dùng. Mô hình này là chiến lược định giá động, yêu cầu người dùng cung cấp một số lượng thanh khoản nhất định để đảm bảo tính chống kiểm duyệt của giao dịch. Khi gửi một giao dịch, người dùng phải đặt hai giá trị gợi ý (T và t). Giá trị gợi ý thực tế được trả phụ thuộc vào số lượng người đề xuất bao gồm giao dịch.

1. Một giá trị tIP cao hơn, T, đại diện cho phí tối đa mà người dùng sẵn lòng trả để đảm bảo giao dịch của họ không bị kiểm duyệt. Mục tiêu là khuyến khích các người đề xuất để bao gồm giao dịch ngay cả khi không có người đề xuất nào sẵn lòng làm như vậy. Nếu chỉ có một người đề xuất nào đó bao gồm giao dịch, họ sẽ nhận toàn bộ số tiền, T.
2. Giá trị gợi ý thấp hơn, t, là số tiền tối thiểu được đặt bởi người dùng. Nếu giao dịch được bao gồm bởi nhiều người đề xuất cùng một lúc, người dùng chỉ cần thanh toán t, số tiền này sẽ được chia sẻ giữa những người đề xuất. Nếu người dùng ít quan tâm đến sự chống lại sự kiểm duyệt, họ có thể đặt T bằng t và gửi giao dịch của họ chỉ đến một người đề xuất.

Tuy nhiên, yêu cầu thanh khoản bổ sung này tăng sự phức tạp và chi phí khi tham gia giao dịch blockchain. Người dùng cần dành dự trữ thêm tiền vào thời điểm giao dịch chỉ để đảm bảo tính chống kiểm duyệt của nó. Những khoản tiền được dự trữ này vẫn đóng băng cho đến khi chúng thực sự được sử dụng.

Để giải quyết vấn đề này, Jonahb đề xuất hai giải pháp:

• Chứng minh thanh khoản sau trạng thái: Người dùng cung cấp chứng minh vào thời điểm gửi giao dịch, cho biết họ sẽ có đủ thanh khoản để thanh toán T sau khi giao dịch được thực hiện (ví dụ, người dùng sẽ có 1 triệu đô la thanh khoản sau giao dịch). Phương pháp này cho phép người dùng tiến hành giao dịch ngay cả khi họ không đủ tiền để thanh toán T trước giao dịch. Thách thức của phương pháp này là các người đề xuất cần biết trạng thái cuối cùng của giao dịch trước khi thực hiện. Tuy nhiên, nhiều giao dịch tài chính liên quan đến trạng thái chia sẻ (như nhiều giao dịch ảnh hưởng đến cùng một số dư tài khoản), làm cho việc xác định chính xác trạng thái sau giao dịch trước khi thứ tự giao dịch được hoàn tất trở nên khó khăn đối với người đề xuất. Phương pháp này yêu cầu chứng minh tùy chỉnh cho mỗi loại giao dịch, làm cho nó ít thực tế hơn.
• Bảo hiểm chống kiểm duyệt: Giới thiệu các nhà cung cấp bảo hiểm chống kiểm duyệt bên thứ ba (CI providers) để đảm bảo T của người dùng. Người dùng trả một khoản phí bảo hiểm, rT, trong đó r dựa trên khả năng giao dịch bị kiểm duyệt. Phương pháp này giảm bớt nhu cầu cho người dùng phải chuẩn bị ngay lượng thanh khoản lớn và có thể cảnh báo người dùng nếu T của họ quá thấp và có nguy cơ bị kiểm duyệt cao. Tuy nhiên, việc thiết lập một thị trường giữa người dùng và CI providers mất thời gian.

Ý kiến cộng đồng về FOCIL vs. BRAID

Nhà phát triển Prysm của Ethereum clientTerence ghi chúMột lợi thế quan trọng của BRAID là nó không đòi hỏi các bên tham gia bổ sung. Hầu hết các thiết kế Danh sách Bao gồm (IL), bao gồm FOCIL, đòi hỏi một bên tham gia bổ sung, điều này tạo ra hạn chế về thời gian trong các khe cắm Ethereum, chẳng hạn như thời gian để nộp IL, cập nhật các đấu giá và các nhà xác minh kiểm tra IL. Tuy nhiên, FOCIL đơn giản hơn và linh hoạt hơn để triển khai so với BRAID.

Nhà nghiên cứu mô hìnhDan Robinson đánh giá caoThiết kế của BRAID cho việc ưu tiên giao dịch, không được xác định bởi một lãnh đạo duy nhất (người đề xuất), do đó hiệu quả trong việc giảm thiểu MEV. Ngoài ra, cơ chế tiền tệ điều kiện của BRAID khuyến khích hành vi không kiểm duyệt, không có trong FOCIL.

Nhà phát triểnDev thíchFOCIL hơn MCP, tin rằng FOCIL cung cấp khả năng chống lại sự kiểm duyệt mạnh mẽ hơn và dễ triển khai hơn. Anh ấy cũng đề xuất một số cải tiến để FOCIL dễ triển khai hơn.

Nhà nghiên cứu Ethereumbarnabe.ethquan điểmFOCIL là một cơ chế khá chung và có thể mở rộng. Anh ấy nhận thấy rằng BRAID có thể cải thiện một số đảm bảo được cung cấp bởi FOCIL nhưng cẩn trọng khi hoàn toàn từ bỏ mô hình dựa trên nhà lãnh đạo. Anh ấy tin rằng cần phải làm thêm công việc để chứng minh tính khả thi của BRAID.

tuyên bố:

1. Bài viết này được tái bản từ [Nghiên cứu ChainFeeds], tiêu đề gốc là "Con đường chống kiểm duyệt của Ethereum: Ai tốt hơn, BRAID hay FOCIL?", Bản quyền thuộc về tác giả gốc [0XNATALIE], nếu bạn có bất kỳ ý kiến phản đối nào về việc sao chép, vui lòng liên hệ Đội ngũ học viên của Gate , đội ngũ sẽ xử lý nó càng sớm càng tốt theo các quy trình liên quan.

2. Tuyên bố từ chối trách nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ đại diện cho quan điểm cá nhân của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.

3. Các phiên bản ngôn ngữ khác của bài viết được dịch bởi nhóm Gate Learn, không được đề cập trongGate.io, bài viết dịch có thể không được sao chép, phân phối hoặc đạo văn.