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

Tác giả: 0xNatalie

Trong quá trình tạo và xác minh khối Ethereum, người xây dựng chịu trách nhiệm thu thập dữ liệu từ nhóm giao dịch Các giao dịch được chọn và sắp xếp, đồng thời các khối được gửi tới những người đề xuất thông qua cơ chế đấu giá. Người đề xuất chọn một khối từ các khối được gửi này để ký và đề xuất nó 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 biện 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òn 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 đíchphân phối sức mạnh và giảm khả năng xem xét giao dịch của một nút duy nhấtbằng cách giới thiệu nhiều người đề xuất khối song song. 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ể quyết định chặn nội dung một mình, 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: Triển khai MCP được cải thiện

Dựa trên Multiplicity, Max Resnick BRAID được đề xuất thêm, đây là một triển khai MCP phức tạp và đầy đủ hơn. Tại hội thảo do Paradigm tổ chức với chủ đề “DeFi trong kỷ nguyên MEV”, 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 triển khai nó tương đối phức tạp và đòi hỏi sự phối hợp của nhiều bên. đồng bộ hóa chuỗi và xử lý dữ liệu.

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

h3>

Nhóm Blockchain Capital Jonahb  đã chỉ ra một vấn đề trong cơ chế BRAID: mô hình "mẹo có điều kiện" có 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à 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. Tiền cao hơn T: Thể hiện mức phí tối đa mà người dùng sẵn sàng trả để đảm bảo rằng giao dịch sẽ 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, miễn là giao dịch Nếu được nhiều người đề xuất đưa vào cùng lúc thì người dùng chỉ cần trả 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 và người dùng cần phải Dự trữ thêm một khoản tiền số tiền tại thời điểm giao dịch chỉ để đảm bảo rằng giao dịch có khả năng chống kiểm duyệt. 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:

• < strong>Bằng chứng về tính 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ụ: giao dịch sau, người dùng sẽ có 1 triệu đô la thanh khoản). 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: Giới thiệu nhà cung cấp bảo hiểm đánh giá bên thứ ba (nhà cung cấp CI) Cung cấp bảo đảm cho T của người dùng . 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

Ether The nhà phát triển ứng dụng khách Prysm terence tin rằng 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 thực 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 BRAID trong việc ưu tiên các giao dịch thay vì để nó theo quyết định riêng của người lãnh đạo (người đề xuất duy nhất), Giảm bớt 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 . Ông 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ó thể được sử dụng trong một số trường hợp. Chúng tôi hy vọng sẽ cải thiện các đảm bảo được cung cấp. bởi FOCIL ở một số khía cạnh, nhưng chúng tôi thận trọng về việc từ bỏ hoàn toàn mô hình dựa trên người lãnh đạo, tin rằng đây vẫn chưa phải là sự đồng thuận và cần nhiều nỗ lực hơn để chứng minh tính khả thi của nó.