Con đường chống lại sự kiểm duyệt của Ethereum: Ai tốt hơn, BRAID hay FOCIL?

Tiêu đề gốc: "Con đường chống kiểm duyệt của Ethereum: Ai tốt hơn, BRAID hay FOCIL?" 》

Tác giả gốc: 0xNatalie, ChainFeeds Research

Trong quy trình xác minh và tạo khối Ethereum, người xây dựng chịu trách nhiệm sắp xếp các giao dịch và chuyển chúng qua phiên đấu giá cơ chế. Khối được gửi đến người đề xuất. Người đề xuất chọn một khối để ký và đề xuất khối đó lên blockchain. Vì người đề xuất, với tư cách là một thực thể duy nhất, có tiếng nói cuối cùng nên điều này tạo ra nguy cơ có thể xảy ra sự thông đồng giữa người đề xuất và nhà thầu để xem xét thỏa thuận.

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 có sự can thiệp từ cơ quan trung ương. Thuộc tính này bị đe dọa khi người đề xuất có thể kiểm soát những giao dịch nào được đưa vào khối. Phá hoại sự công bằng và minh bạch. Và quyền lực này có thể được sử dụng để thao túng thứ tự giao dịch trong khối nhằm thu được thêm lợi ích kinh tế và gây ra các vấn đề về MEV.

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

Để 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 khác nhau. -các giải pháp kiểm duyệt, chẳng hạn như danh sách đưa vào bắt buộc (FOCIL). Trong cơ chế FOCIL, một nhóm người xác nhận được chọn ngẫu nhiên cho từng vị trí (khe thời gian) để tạo thành ủy ban danh sách đưa vào. Các thành viên ủy ban này tạo ra các danh sách bao gồm địa phương dựa trên quan điểm chủ quan tương ứng của họ về mempool và phổ biến chúng. 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 để tạo thành một danh sách tổng hợp và đưa nó vào khối. Cơ chế này đảm bảo tính công bằng của khối, bởi vì người xác thực sẽ xác minh tính chính xác của danh sách tổng hợp dựa trên danh sách cục bộ đã phát trước đó và chỉ các khối tuân thủ 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ề giải pháp nhiều người đề xuất đồng thời (MCP). Khái niệm này lần đầu tiên được đề xuất bởi Max Resnick trong cơ chế Đa bội, nhằm mục đích phân cấp quyền lực bằng cách giới thiệu nhiều người đề xuất khối song song và giảm khả năng xem xét giao dịch của một nút duy nhất. Trong cơ chế Đa bội, mỗi người xác nhận chọn một phần giao dịch từ nhóm giao dịch của riêng mình để tạo thành "gói giao dịch đặc biệt". Những người xác nhận này ký và gửi các gói giao dịch đã chọn của họ cho những người đề xuất vòng hiện tại. Sau khi người đề xuất nhận được nó, anh ta cần đưa ít nhất 2/3 số gói giao dịch vào khối đề xuất của mình. Chỉ khi đó khối sẽ được coi là hợp lệ. Cơ chế này đảm bảo rằng người đề xuất không thể tự mình quyết định chặn nội dung, từ đó 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", theo đó chỉ những người đề xuất bao gồm giao dịch mới nhận được một phần tiền boa giao dịch. Tiền boa của 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 theo các điều kiện nhất định. Điều này làm tăng chi phí kiểm duyệt, đòi hỏi phải hối lộ tất cả những người đề xuất các giao dịch được đưa vào.

BRAID: Cải thiện việc triển khai MCP

Dựa trên Multiplicity, Max Resnick còn đề xuất thêm BRAID, một giải pháp phức tạp hơn và hoàn thiện việc thực hiện MCP. Tại hội thảo có chủ đề “DeFi trong kỷ nguyên MEV” do Paradigm tổ chức, Max đã giới thiệu BRAID. BRAID triển khai MCP bằng cách cho phép nhiều người đề xuất đề xuất các khối trên các chuỗi song song khác nhau và tận 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 có người đề xuất riêng và tất cả những người đề xuất xuất bản các khối của họ đồng thời trong cùng một vị trí. Lớp thực thi Ethereum thu thập các giao dịch khối được tạo bởi tất cả các chuỗi con trong khe để tạo thành một khối thực thi và loại bỏ trùng lặp, sắp xếp và thực hiện các giao dịch này theo các quy tắc được xác định trước, do đó giảm rủi ro cho bất kỳ thực thể nào có khả năng thao túng hồ sơ giao dịch.

Thiết kế của BRAID không đưa ra các vai trò bổ sung, do đó tránh được sự phức tạp do cơ chế khuyến khích/trừng phạt gây ra. Tuy nhiên, việc thực hiện nó tương đối phức tạp và cần có sự phối hợp. của nhiều hệ thống con. Đồng bộ hóa chuỗi và xử lý dữ liệu.

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

Nhóm Blockchain Capital Jonahb đã chỉ ra một vấn đề trong cơ chế BRAID: mô hình "tiền boa có điều kiện" có yêu cầu về thanh khoản, ả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á linh hoạt, yêu cầu người dùng chuẩn bị một lượng thanh khoản nhất định để đảm bảo rằng các giao dịch có khả năng chống kiểm duyệt. Người dùng cần đặt hai giá trị tiền boa (T và t) khi gửi giao dịch. Tiền boa thực tế cuối cùng được trả tùy thuộc vào số lượng người đề xuất có trong giao dịch.

1. Tip T cao hơn: thể hiện mức phí cao nhất mà người dùng sẵn sàng trả để đảm bảo các giao dịch không bị kiểm duyệt. Mục đích là để khuyến khích những người đề xuất đưa vào một giao dịch khi không có người đề xuất nào khác sẵn sàng đưa nó vào. Cuối cùng, nếu chỉ có một người đề xuất sẵn sàng đưa vào, anh ta sẽ nhận được T.

2. Mẹo thấp hơn t: Đây là số tiền thấp hơn do người dùng đặt ra. Miễn là người dùng thực hiện giao dịch đó. chỉ cần Pay t. t sẽ được chia cho nhiều 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 của mình cho một người đề xuấ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 các giao dịch blockchain. Người dùng cần phải dành thêm một khoản tiền tại thời điểm giao dịch. Cần có một khoản tiền chỉ để đảm bảo khả năng chống kiểm duyệt của giao dịch. Những khoản tiền dự trữ này sẽ bị đóng băng cho đến khi chúng thực sự được sử dụng.

Về vấn đề này, Jonahb đề xuất hai giải pháp:

· Bằng chứng về tính thanh khoản sau nhà nước ( bằng chứng thanh khoản sau trạng thái):Khi gửi giao dịch, người dùng cung cấp bằng chứng rằng 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 USD thanh khoản sau khi giao dịch ). Bằng cách này, ngay cả khi không có đủ tiền để thanh toán T trước giao dịch, người dùng vẫn có thể chứng minh rằng mình có thể thanh toán sau giao dịch. Thách thức với cách tiếp cận này là người đề xuất phải biết trạng thái cuối cùng của giao dịch trước khi giao dịch được thực hiện, nhưng hầu hết các giao dịch tài chính đều liên quan đến trạng thái chia sẻ (chẳng hạn như nhiều giao dịch có cùng số dư tài khoản), do đó người đề xuất không thể đánh giá chính xác cho đến khi thứ tự giao dịch được xác định. Điều này đòi hỏi bằng chứng tùy chỉnh cho từng loại giao dịch, điều này ít thực tế hơn.

· Bảo hiểm kiểm duyệt (bảo hiểm kiểm duyệt): Giới thiệu nhà cung cấp bảo hiểm kiểm duyệt bên thứ ba (nhà cung cấp CI) để đảm bảo cho người dùng T. Người dùng trả một khoản rT cao cấp cho việc này, trong đó r được tính dựa trên khả năng giao dịch sẽ bị kiểm duyệt. Giải pháp này không chỉ giúp người dùng giảm nhu cầu chuẩn bị ngay lượng lớn thanh khoản mà còn cảnh báo người dùng thông qua CI rằng T quá thấp và có nguy cơ kiểm duyệt cao. Nhưng việc xây dựng thị trường giữa người dùng và nhà cung cấp CI cần có thời gian.

Quan điểm của cộng đồng về FOCIL và BRAID

Khách hàng Ethereum Nhà phát triển Prysm Terence cho rằng Một lợi thế đáng kể của BRAID là nó không yêu cầu thêm người tham gia. Trong hầu hết các thiết kế Danh sách bao gồm (IL), bao gồm FOCIL, cần có thêm một người tham gia, điều này bổ sung các ràng buộc về thời gian trong các khe thời gian Ethereum, chẳng hạn như khi IL được gửi, khi giá thầu được cập nhật và người xác nhận kiểm tra thời gian IL. Tuy nhiên, giải pháp FOCIL thực hiện đơn giản và linh hoạt hơn BRAID.

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

Nhà phát triển Dev thích FOCIL hơn MCP. Anh ấy tin rằng FOCIL có nhiều lợi thế hơn trong việc cung cấp khả năng kháng cự mạnh mẽ và đơn giản hóa việc triển khai. Và cung cấp một số giải pháp cải tiến để giúp FOCIL dễ thực hiện hơn.

Nhà nghiên cứu Ethereum barnabe.eth tin rằng FOCIL là một cơ chế khá chung chung và có thể mở rộng. Ông thừa nhận rằng BRAID có tiềm năng cải thiện các đảm bảo do FOCIL cung cấp ở một số khía cạnh. cảnh giác với việc từ bỏ hoàn toàn mô hình dựa vào người lãnh đạo, cho rằng nó vẫn chưa đạt được sự đồng thuận và cần nhiều nỗ lực hơn để chứng minh tính khả thi của nó.

Liên kết gốc