Giới hạn thực tế về cơ chế bắt buộc cho khả năng kháng kiểm duyệt

Nâng caoSep 27, 2024
Bài viết này bàn về những hạn chế của cơ chế bao gồm bắt buộc trong việc giải quyết vấn đề kiểm duyệt giao dịch. Mặc dù các hệ thống như Arbitrum và Optimism sử dụng cơ chế này, cho phép người dùng yêu cầu giao dịch cụ thể được bao gồm trong một khoảng thời gian nhất định, trên các chuỗi trạng thái giàu có, người gửi vẫn có thể làm cho những giao dịch này thất bại bằng cách sửa đổi trạng thái chia sẻ.
Giới hạn thực tế về cơ chế bắt buộc cho khả năng kháng kiểm duyệt

Lời tác giả: init4là một nhóm nghiên cứu làm việc trên các công cụ Ethereum thế hệ tiếp theo. Đây là một ghi chú nghiên cứu, không phải là một tài liệu tiết lộ. Trong khi chúng tôi sẽ thảo luận về những sự tinh vi và khoảng trống trong các mô hình bảo mật của các hệ thống đã triển khai và đề xuất, nhưng việc miêu tả chúng như là “lỗ hổng” hoặc “trước đây chưa biết đến” sẽ là quá đánh đồng.

Kháng kiểm duyệt vẫn là một giá trị cốt lõi của tiền điện tử nói chung, và Ethereum đặc biệt. Chúng tôi tin rằng những lợi ích của việc thực hiện giao dịch trên chuỗi nên được cung cấp cho bất kỳ ai, và rằng các quy tắc của chuỗi nên áp dụng cho tất cả người dùng và mục đích một cách công bằng. Giá trị thúc đẩy không gian này tiến lên phía trước. Kỹ thuật là quá trình kiểm tra giá trị của chúng tôi so với thực tế để tìm ra nơi và cách chúng bị hỏng.

Các quân Domino cũng được sắp xếp theo thứ tự :) Ảnh chụp bởi Tom WilsononUnsplash

Định nghĩa Kháng kiểm duyệt

Chúng tôi có xu hướng mô hình hóa kiểm duyệt là cố ý ngăn chặn các giao dịch xuất hiện trong thứ tự chuẩn (tức là loại trừ giao dịch). Chúng tôi coi các đơn đặt hàng là công bằng hoặc trung lập khi chúng phụ thuộc hoàn toàn vào kết quả kinh tế cho hệ thống đặt hàng và không công bằng hoặc bị kiểm duyệt khi chúng phụ thuộc vào thông tin khác. Ví dụ: khi tạo một khối, có thể chấp nhận từ chối bao gồm một giao dịch phí thấp, nhưng không thể chấp nhận từ chối bao gồm một giao dịch vì nó được gửi bởi một người cụ thể. Do đó, chúng tôi nói rằng một giao dịch bị kiểm duyệt nếu việc đưa nó vào phụ thuộc vào thông tin phi kinh tế. Nếu giao dịch tạo ra nhiều lợi nhuận có thể quan sát được cho hệ thống đặt hàng hơn bất kỳ giao dịch nào được bao gồm, nhưng bản thân nó không được bao gồm, nó được coi là bị kiểm duyệt. Định nghĩa này thúc đẩy công việc về các cơ chế bao gồm bắt buộc để chống kiểm duyệt. Nếu người dùng có thể buộc bao gồm giao dịch của họ, thì nó không thể bị kiểm duyệt theo định nghĩa này.

Cơ chế bắt buộc inclusion

Một mục tiêu bảo mật cốt lõi của các chuỗi OP Stack là rằng Sequencer không thể ngăn ngừa người dùng gửi giao dịch đến chuỗi L2.

Các rollup hiện đại thường có sự xếp hàng tập trung. Điều này có nghĩa là việc kiểm duyệt bởi người xếp hàng là không đáng kể, vì họ có thể đơn giản là chọn không bao gồm bất kỳ giao dịch người dùng nào. Để giảm thiểu điều này, một số rollup - bao gồm Lạc quanArbitrum- có cơ chế bao gồm bắt buộc. Cơ chế này cho phép người dùng đảm bảo rằng giao dịch của họ sẽ được thực hiện bởi rollup sau một khoảng thời gian trễ, bất kể hành vi của sequencer. Việc bao gồm được bắt buộc thông qua một hợp đồng triển khai trên L1. Do đó, các giao dịch bao gồm bắt buộc (lý thuyết là) có sự kháng cự tương tự như các giao dịch Ethereum khác.

Điều kiện bắt buộc chỉ định phạm vi phụ phải được bảo tồn trong bất kỳ thứ tự hợp lệ nào.

Một cơ chế bắt buộc cho sự bao gồm cũng đã được đề xuất cho Ethereum qua EIP-7547.Danh sách bao gồm sẽ cho phép đề xuất khối chỉ định một phần nội dung của khối tiếp theo. Dưới giả định rằng những người đề xuất khối có ít động cơ hơn để kiểm duyệt hơn những người xây dựng khối, điều đó sẽ cung cấp một phương pháp hạn chế hiệu quả cho việc kiểm duyệt.

Nói chung, các cơ chế bắt buộc sự xuất hiện tạo ra các ràng buộc mới về thứ tự hợp lệ. Chúng làm cho các lớp rộng của thứ tự trở nên không hợp lệ theo quy tắc giao thức.1. Sự bao gồm bắt buộc nên được xem như cho phép người dùng chỉ định một phần của thứ tự tương lai. Tất cả các thứ tự hợp lệ phải mở rộng trên tập hợp bắt buộc.

Mở rộng Mô hình của chúng tôi về Kháng kiểm duyệt

Rất tiếc, xác nhận giao dịch chỉ là phương tiện, chứ không phải là mục tiêu. Mô hình của chúng tôi về sự kháng kiểm duyệt là chưa hoàn chỉnh!

Kháng kiểm duyệt phải được xác định dựa trên mục tiêu. Người dùng muốn gửi token, mua NFT, vay vốn, v.v. Xác nhận giao dịch là phụ thuộc vào mục tiêu đó2. Các cơ quan kiểm duyệt cũng có mục tiêu cụ thể. Mục tiêu đó có thể là ngăn chặn một giao dịch hack nào đó thành công, tuân thủ một số quy định pháp luật hoặc can thiệp vào hoạt động kinh doanh của đối thủ cạnh tranh. Tôn trọng ý định của cả hai bên, chúng ta cần định nghĩa lại kháng kiểm duyệt.

Với điều này trong đầu, chúng ta nên mở rộng định nghĩa của chúng ta về kiểm duyệt để nói rằng: một giao dịch bị kiểm duyệt nếu một bên thứ ba có thể ngăn nó đạt được mục tiêu của nó. Nghĩa là, kẻ kiểm duyệt không cần ngăn chặn giao dịch từ xác nhận; họ chỉ cần khiến thực hiện hợp đồng thông minh bị trả lại. Làm cho một giao dịch EVM bị trả lại là kiểm duyệt của giao dịch đó, mặc dù giao dịch đó là một phần của chuỗi cơ sở dữ liệu. Mô hình đe dọa mù đến nội dung của một giao dịch không mô hình kiểm duyệt chính xác, và do đó không thể bảo vệ người dùng khỏi nó một cách hiệu quả.

Một cách bán chính thức, chúng ta có thể nói rằng đối với bất kỳ tương tác nào với chuỗi, có một tiên đề điểm số f đánh giá thứ tự kết quả và tạo ra 0 (mục tiêu thất bại) hoặc 1 (mục tiêu đạt được). Trong mô hình này, hàm điểm số của nhà kiểm duyệt đơn giản là phủ định: f '=! F. Nhà kiểm duyệt đạt được mục tiêu của họ khi người dùng không làm được điều đó.3

Mặc dù mục tiêu của người dùng có thể được giấu kín, giao dịch thực tế hầu như luôn chứa đủ thông tin để suy ra nó. Các giao dịch Uniswap có mục tiêu rõ ràng. Hơn nữa, vì blockchain là xác định được, người kiểm duyệt hoàn toàn có thể dự đoán được những thứ tự nào sẽ thỏa mãn mệnh đề của người kiểm duyệt. Kết quả là, người dùng không thể dựa vào thông tin giấu kín để bảo vệ mình khỏi kiểm duyệt trong mô hình EVM. Chi tiết giao dịch phải là công khai, điều đó có nghĩa là thông tin về mục tiêu của người dùng là công khai.

Đơn giản, hãy giả sử rằng chúng ta đang làm việc trong mô hình trình tự tiến chuẩn4. Chúng tôi sẽ xử lý việc bao gồm bắt buộc dưới sự xoay vòng của bộ điều khiển sau này. Trong mô hình này, bộ điều khiển có quyền kiểm soát hoàn toàn chuỗi và có thể mô phỏng hoàn hảo bất kỳ kết quả nào. Điều đó có nghĩa là họ có quyền lựa chọn từ tập hợp tất cả các thứ tự có thể có. Câu hỏi bán thực về việc kiểm duyệt sau đó trở thành "liệu có tồn tại một thứ tự hợp lệ mà f đánh giá là 0"? Nếu tồn tại một thứ tự như vậy, thì bộ điều khiển có thể chọn nó.

Từ đó, chúng ta có thể mở rộng mô hình của mình để tính đến sự bắt buộc phải bao gồm. “Liệu có tồn tại một thứ tự hợp lệ nào đó, bao gồm thứ tự con của người dùng, mà cho f đánh giá bằng 0 không?” Nếu một thứ tự như vậy tồn tại, bộ sắp xếp có thể chọn nó. Sự bắt buộc phải bao gồm không ngăn cản bộ sắp xếp thực hiện kiểm soát về thứ tự, nó chỉ hạn chế hành vi của họ. Thật không may, sự bắt buộc phải bao gồm có những vấn đề cơ bản ngăn cản nó trở thành một cơ chế sự kháng kiểm duyệt hiệu quả cho nhiều giao dịch.

Vấn đề chuyển giao

Cơ chế bắt buộc bao gồm hai chế độ sắp xếp: không bắt buộc hoặc bắt buộc. Có một điểm được xác định khi nó chuyển từ chế độ không bắt buộc sang chế độ bắt buộc (và ngược lại). Điểm đó là điểm giao nhận. Điểm giao nhận đặt ra một vấn đề gai góc cho thiết kế cơ chế bắt buộc bao gồm.

Phải có sự chuyển giao từ sự bao gồm tự nguyện sang bắt buộc.

Giao dịch bắt buộc được thực hiện trên trạng thái tại thời điểm chuyển giao. Vì vậy, một lần nữa, sự tranh chấp trạng thái5kháng cự trở nên tàn khốc. Khi việc chuyển giao diễn ra trong một lô giao dịch (như một khối), người tạo ra lô có thể kiểm soát trạng thái khi chuyển giao diễn ra. Nếu giao dịch bắt buộc phải bao gồm bất kỳ trạng thái công khai nào, người tạo ra lô có thể viết lại trạng thái đó trước và sau khi giao dịch bắt buộc thực hiện. Sự cạnh tranh đủ để chống lại kiểm duyệt.

Bởi vì người tạo lô có thể kiểm soát trạng thái tại thời điểm chuyển giao, do đó nó có thể ảnh hưởng đến kết quả của giao dịch bắt buộc. Nếu nó có thể ảnh hưởng đến kết quả, nó có thể tiềm ẩn ảnh hưởng đến kết quả của điều kiện đánh điểm. Ví dụ, xem xét một tương tác AMM đơn giản. Người dùng đặt một giá tối thiểu chấp nhận được, tuy nhiên, người tạo lô có thể đảm bảo rằng tại điểm chuyển giao, giá thị trường thấp hơn giá tối thiểu chấp nhận được. Điều này khiến giao dịch của người dùng hoàn nguyên, hiệu quả là kiểm duyệt người dùng.67

Thú vị thay, kiểm duyệt thông qua tranh chấp nhà nước hiệu quả hơn kiểm duyệt thông qua loại trừ. Một giao dịch bị loại trừ có thể được bao gồm trong các khối tương lai. Một giao dịch bị kiểm duyệt thông qua tranh chấp bị vô hiệu hóa vĩnh viễn. Nó đã được bao gồm trong chuỗi và không thể bao giờ được bao gồm lại. Giao dịch đó không bao giờ đạt được mục tiêu của người dùng. Để thử lại, người dùng phải tạo và gửi lại giao dịch (có thể bị kiểm duyệt lại).

Trong các hệ thống thực tế

Bất kỳ người dùng nào cũng có thể hoàn toàn bỏ qua Bộ sắp xếp để gửi bất kỳ giao dịch Arbitrum nào (bao gồm cả giao dịch khởi đầu một tin nhắn từ L2 đến L1 để rút tiền) trực tiếp từ lớp 1. Do đó, cơ chế này duy trì sự kháng kiểm duyệt ngay cả khi Bộ sắp xếp hoàn toàn không phản ứng hoặc thậm chí có ý đồ xấu.

Trong mô hình xếp hàng trước, người xếp hàng gần như hoàn toàn kiểm soát vị trí của việc chuyển giao trong chuỗi, và trả ít phí hơn (vì họ không cần đưa tiền boa và có thể thực hiện một số kiểm soát đối với EIP-1559 basefee). Kết quả là, người xếp hàng đang ở trong vị trí đặc quyền để sử dụng tranh chấp trạng thái để kiểm duyệt hành động của người dùng. Điều này là rất đơn giản. Vấn đề chuyển giao đảm bảo rằng người xếp hàng có thể kiểm duyệt các lớp giao dịch lớn.

Đối với EIP-7547, người xây dựng chọn nơi xảy ra việc chuyển giao khối.8 Do đó, người xây dựng có khả năng chọn vị trí bàn giao trong khối. Điều này có nghĩa là họ có thể chọn tiền tố và hậu tố theo ý muốn,9miễn là họ tôn trọng quy tắc gas khối. Tiền tố có thể đưa chuỗi vào trạng thái mà giao dịch sẽ quay lại, trong khi hậu tố sẽ khôi phục chuỗi về trạng thái bình thường. Danh sách bao gồm EIP-7547 không đủ để ngăn chặn sự kiểm duyệt cho bất kỳ giao dịch nào truy cập trạng thái gây tranh cãi. Vấn đề chuyển giao ngăn chặn ILs khỏi đảm bảo thực hiện giao dịch trong hầu hết các trường hợp.

Bao gồm bắt buộc là không hiệu quả trong việc bảo vệ người dùng khỏi sự kiểm duyệt đối với hầu hết các mục đích sử dụng không tầm thường của blockchain. Vấn đề chuyển giao đảm bảo rằng người kiểm duyệt có đủ quyền quyết định đối với nhà nước ngay cả khi họ không có đủ quyền quyết định về trật tự. Vấn đề này ảnh hưởng đến AMM, thị trường cho vay, đấu giá và hầu hết các hành động DeFi khác. Nhiều hành động quan trọng có thể kiểm duyệt ngay cả khi bạn có thể đảm bảo bao gồm giao dịch. Sự tranh cãi của nhà nước tạo ra những giới hạn cứng về hiệu quả của việc đưa vào cưỡng bức như một cơ chế chống kiểm duyệt.

Nghiên cứu trường hợp

Để thấy tác động xa rộng của điều này, hãy xem xét một người dùng cho vay USDC trên thị trường cho vay trên Optimism. Khi người dùng muốn rút USDC từ thị trường, họ gửi một giao dịch Optimism, mà sequencer kiểm duyệt. Sau đó, họ sử dụng cơ chế bao gồm bắt buộc chính thức để xếp hàng giao dịch của họ trên Ethereum, vượt qua sequencer.

Sequencer có thể nhìn thấy giao dịch đó trong hàng đợi và có thể chọn đặt nó vào giữa. Để kiểm duyệt giao dịch, sequencer vay toàn bộ USDC có sẵn từ thị trường ngay trước giao dịch bắt buộc. Do thị trường không còn thanh khoản, giao dịch bắt buộc bị hoàn nguyên. Sequencer sau đó có thể trả lại USDC ngay lập tức.

Người sắp xếp hoặc người xây dựng có thể thao tác trạng thái tại thời điểm chuyển giao.

Điều này yêu cầu bộ sắp xếp có tài sản đảm bảo đủ để vay USDC, nhưng chỉ áp đặt một chi phí vay rất nhỏ.10Hơn nữa, tài sản đảm bảo có thể tái sử dụng cho mọi sự kiểm duyệt, vì khoản vay không bao giờ được mở. Do đó, người dùng AAVE hoặc Compound trên Optimism (hoặc Arbitrum hoặc bất kỳ rollup theo trình tự trung tâm nào khác) không có bảo đảm rằng họ sẽ có thể rút tài sản đảm bảo bao giờ. Người xếp hàng có thể kiểm duyệt bất kỳ rút tiền từ bất kỳ thị trường cho vay nào vào bất kỳ thời điểm nào. Việc bắt buộc bao gồm đơn giản không đủ để bảo vệ người dùng khỏi sự kiểm duyệt.

Công việc theo dõi

Chúng tôi có một vài lĩnh vực nghiên cứu tiếp theo.

Đầu tiên, EIP-7547 có thể được cải thiện một cách dễ dàng bằng cách yêu cầu các giao dịch IL được xử lý vào cuối khối tiếp theo. Trong ngữ cảnh đấu giá PBS, sự kiểm duyệt là MEV. Người xây dựng tạo ra một số giá trị phi kinh tế, mà họ phải gán cho một giá trị chủ quan được định giá bằng ETH. Sự kiểm duyệt bởi người xây dựng do đó gây ra một sự tăng vọt trong đặt cược khối của người xây dựng.11Điều này mở rộng đến người tìm kiếm, người có thể tạo ra các gói kiểm duyệt. Một phần giá trị kinh tế của việc kiểm duyệt sau đó được thu thập bởi người đề xuất, tạo động lực để chịu đựng việc kiểm duyệt ngay cả khi không tham gia trực tiếp. Đặt các giao dịch bắt buộc bao gồm vào cuối khối sẽ loại bỏ khả năng của người xây dựng khối để dễ dàng đặt các giao dịch IL ở giữa, và tăng chi phí kinh tế của việc kiểm duyệt gây tranh cãi. Ví dụ, việc kiểm duyệt tương tác AMM thông qua tranh chấp trạng thái có thể đòi hỏi từ bỏ một số chênh lệch AMM hoặc một chi phí cao để đẩy thị trường ra khỏi phạm vi mà không thể thu hồi bằng cách đóng sandwich. Ngoài ra, điều này sẽ hạn chế các gói kiểm duyệt được tạo ra bởi người tìm kiếm (chứ không phải người xây dựng) chỉ một gói mỗi khối.12Chúng tôi sẽ khuyến nghị thực hiện đầu block, vì tiền tố quan trọng hơn hậu tố, tuy nhiên, điều đó sẽ tăng đáng kể chi phí của giao dịch IL, vì nó sẽ cho phép trích xuất MEV đầu block thông qua việc bắt buộc bao gồm.13Loại bỏ quyền của người kiểm duyệt tự động thêm hậu tố IL vào các giao dịch là một cải tiến nhỏ.

Vấn đề chuyển giao thứ hai tồn tại vì người kiểm duyệt có thể nhìn vào tương lai thông qua mô phỏng giao dịch và thực hiện kiểm soát trạng thái đầu vào. Nhiều cơ chế kháng MEV giới thiệu thông tin ẩn để loại bỏ khả năng của người kiểm duyệt để suy luận thông tin về mục tiêu của người dùng và mô phỏng kết quả. Thông thường, đây là các kế hoạch cam kết - tiết lộ, trong đó một số thông tin giao dịch là riêng tư cho đến sau khi sắp xếp xảy ra. Phân tách thứ tự-thực hiện và thông tin ẩn dường như hứa hẹn, nhưng lớn phần không tương thích với chuỗi cung ứng MEV, quy trình đồng thuận Ethereum và mô hình sequenced rollup. Một cách để kháng khả năng mô phỏng giao dịch sẽ giải quyết vấn đề kiểm duyệt và các lớp lớn của MEV, nhưng sẽ rất xâm phạm đối với giao thức, các nhà điều hành của giao thức, ứng dụng và người dùng cuối cùng.

Thứ ba, có một loại hàm điểm "độc lập với thứ tự" thú vị. Đây là những mục tiêu không thể bị kiểm duyệt bởi sự tranh cãi của quốc gia, hoặc là vì chúng không truy cập vào trạng thái gây tranh cãi, hoặc là vì trạng thái gây tranh cãi mà chúng truy cập có ràng buộc đủ để làm cho nó "đáng tin cậy" theo một số ý nghĩa nào đó. Các hành động độc lập với thứ tự bao gồm việc gửi ETH đến một EOA, hầu hết các gửi ERC-20,14và một số tương tác DeFi như thêm tài sản thế chấp vào một thị trường. Những hành động này được bảo vệ khỏi kiểm duyệt thông qua sự tranh đấu. Lớp mục tiêu này cũng có những tương ứng thú vị trong việc giao tiếp an toàn giữa các chuỗi và sự chống lại MEV, đáng đồng nghiệp nghiên cứu sâu hơn. Các ứng dụng và giao thức có thể được thiết kế để chỉ bao gồm các hành động độc lập với thứ tự trong một số trường hợp, nhưng cần nghiên cứu thêm.

Kết luận

Nhà nước giàu cho phép các tác nhân độc hại kiểm duyệt các giao dịch trong khi vẫn bao gồm chúng. Vấn đề bàn giao là nền tảng cho các cơ chế hòa nhập bắt buộc, và chỉ có thể được giảm thiểu. Trong các bản tổng hợp được sắp xếp theo trình tự tập trung, không thể giảm nhẹ. Bao gồm bắt buộc không thể giải quyết kiểm duyệt khi có sự hiện diện của nhà nước gây tranh cãi. Các lớp giao dịch lớn quan trọng về kinh tế có thể bị kiểm duyệt, ngay cả khi được bao gồm bằng vũ lực. Vấn đề bàn giao là đặc hữu trong các bản cập nhật hiện đại và hiện diện trong các EIP chống kiểm duyệt của Ethereum. Kết quả là, sự bao gồm bắt buộc, mặc dù có lợi, không bao giờ đủ để cung cấp khả năng chống kiểm duyệt cho các chuỗi nhà nước giàu. Rollups không "kế thừa" các thuộc tính bảo mật của Ethereum và thật ngớ ngẩn khi đề xuất rằng chúng có. Khi bạn ngừng ám ảnh về việc đưa vào, rõ ràng là khả năng chống kiểm duyệt là một trường hợp đặc biệt của kháng MEV.

Chúng tôi muốn cảm ơnMike Neuder, Tarun Chitra, và Brandon Curtisđể xem xét và phản hồi.

1

Như thông thường, đối với L1s, điều này được thực hiện bằng cách từ chối các khối không hợp lệ, trong khi đối với rollups, điều này được thực hiện bằng cách ép buộc các chuỗi không hợp lệ thành chuỗi hợp lệ thông qua một chức năng lọc nào đó.

2

Đây không phải là một bài viết về ý định, thế giới không cần nhiều hơn những điều đó vào thời điểm này.

3

Đây rõ ràng là một mô hình chưa hoàn chỉnh, vì nó không tính đến các giá trị chủ quan của các kết quả. Ví dụ, người kiểm duyệt có thể mất bất kỳ số tiền nào nếu kiểm duyệt thất bại (ví dụ, vì họ có thể bị bắt bởi cảnh sát Pháp nếu họ không kiểm duyệt hành vi cụ thể). Ngược lại, người dùng có thể có thể mất/giành được bất kỳ số tiền nào nếu mục tiêu của họ không đạt được trong một khung thời gian cụ thể (ví dụ, họ đã vay hơn 100 triệu đô la bằng token của họ và cần tái cấp bảo vị trí trước khi bị thanh lý).

4

Ngược lại với mô hình sequencer “dựa trên”. Trong hầu hết các rollup hiện đại, sequencer “chạy trước” Ethereum bằng cách cung cấp xác nhận và thực thi cho một giao dịch trước khi giao dịch đó được cam kết vào Ethereum. Trong mô hình này, Sequencer hoàn toàn kiểm soát chuỗi và kết quả của giao dịch phải độc lập với Ethereum reorgs.

5

Khi nhiều người dùng muốn truy cập vào cùng một hợp đồng, tài sản hoặc trạng thái, giao dịch của họ 'đấu tranh' với nhau và có thể gây can thiệp vào kết quả của nhau. Sự tranh cãi có thể phát sinh ngẫu nhiên hoặc cố ý. Đây là một vấn đề không thể giải quyết của trạng thái phong phú trong hệ thống blockchain. Việc truy cập công cộng đến trạng thái chia sẻ là nguyên nhân gốc của MEV, vấn đề về khả năng mở rộng và sự suy giảm về văn minh trong xã hội hiện đại.

6

Nói chung, bạn nên coi việc kiểm duyệt thông qua tranh chấp nhà nước là một trường hợp chuyên biệt của MEV. Bởi vì giá trị được trích xuất là ngoài chuỗi, không thể quan sát được và có thể rất lớn, nên có thể khó đoán khi nào kiểm duyệt thông qua tranh chấp nhà nước sẽ xảy ra.

7

Chúng tôi đặc biệt đề cập đến việc sử dụng tranh chấp nhà nước để hoàn nguyên các giao dịch trong bài viết năm 2017 của chúng tôi "Thợ đào không phải là bạn của bạn”. Khi đó thuật ngữ “MEV” chưa được sử dụng.

8

Ai cũng biết rằng PBS làm phức tạp đáng kể khả năng chống kiểm duyệt. Xem VB's @vbuterin/pbs_kháng_kiểm duyệt">note nghiên cứu.

9

Việc đặt tiền tố và hậu tố cho một giao dịch thường được gọi là “sandwiching” và được hiểu rõ như một phương pháp sử dụng sự tranh giành trạng thái để trích xuất MEV.

10

Vay được giữ trong chỉ vài giây, nếu có. Trình tự Rollup có thể trong một số trường hợp giữ thời gian dấu thời gian hoặc ranh giới khối để làm thời gian vay hiệu quả bằng 0.

11

Nhà xây dựng sẽ sẵn sàng trả giá trị chủ quan của họ về kiểm duyệt, có khả năng đẩy giá thầu lên trên giá trị có thể trích xuất có thể quan sát khách quan của khối. Trong trường hợp cực đoan, điều này có thể dẫn đến trường hợp người kiểm duyệt có thay đổi số dư ETH âm (tức là họ trả nhiều ETH hơn để tạo khối so với phí và phần thưởng).

12

Lưu ý rằng điều này dựa trên các quy tắc đấu giá MEV ngăn chặn các giao dịch xen kẽ từ các gói khác nhau và không cho phép các giao dịch "phải hoàn nguyên". Nếu các quy tắc đó được nới lỏng để cho phép các gói txn được xen kẽ và / hoặc nếu các nhà xây dựng bắt đầu hỗ trợ các khối "phải hoàn nguyên" trong các gói, sự bảo vệ sẽ bốc hơi. Động lực này phát sinh bởi vì nếu các giao dịch IL phải ở cuối khối, không có giao dịch không bắt buộc nào có thể được xen kẽ, và do đó nhiều nhất là một gói kiểm duyệt người tìm kiếm có thể xảy ra.

13

Cho phép nhà xây dựng tạo các gói giới hạn giữa các khối. Hệ thống tiền đồng thuận trước như Gate.io,FOCILcó thể giảm thiểu điều này.

14

Đối với mã thông báo ERC-20 tiêu chuẩn, cuộc gọi chuyển khoản thường không bị kiểm duyệt thông qua tranh chấp, vì các bên thứ ba không thể giảm số dư của người dùng. Tuy nhiên, hãy xem xét một cuộc gọi chuyểnTừ. Nếu bên chuyển nhượng được chấp thuận là một hợp đồng cho phép tranh chấp trên chính trạng thái của mình, thì hành động có thể bị kiểm duyệt thông qua tranh chấp đó (tiêu thụ sự chấp thuận cần thiết cho việc chuyển nhượngTừ một số cách ngoài ý muốn).

Disclaimer:

  1. Bài viết này được in lại từ [Công nghệ], Tất cả bản quyền thuộc về tác giả gốc [khởi tạo 4]. Nếu có đối sách với việc tái bản này, xin vui lòng liên hệ Gate Họcđội ngũ, và họ sẽ xử lý nhanh chóng.
  2. Bảo Đảm Trách Nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ là của tác giả và không hề đại diện cho bất kỳ lời khuyên đầu tư nào.
  3. Bản dịch bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn các bài báo đã dịch đều bị cấm.

Giới hạn thực tế về cơ chế bắt buộc cho khả năng kháng kiểm duyệt

Nâng caoSep 27, 2024
Bài viết này bàn về những hạn chế của cơ chế bao gồm bắt buộc trong việc giải quyết vấn đề kiểm duyệt giao dịch. Mặc dù các hệ thống như Arbitrum và Optimism sử dụng cơ chế này, cho phép người dùng yêu cầu giao dịch cụ thể được bao gồm trong một khoảng thời gian nhất định, trên các chuỗi trạng thái giàu có, người gửi vẫn có thể làm cho những giao dịch này thất bại bằng cách sửa đổi trạng thái chia sẻ.
Giới hạn thực tế về cơ chế bắt buộc cho khả năng kháng kiểm duyệt

Lời tác giả: init4là một nhóm nghiên cứu làm việc trên các công cụ Ethereum thế hệ tiếp theo. Đây là một ghi chú nghiên cứu, không phải là một tài liệu tiết lộ. Trong khi chúng tôi sẽ thảo luận về những sự tinh vi và khoảng trống trong các mô hình bảo mật của các hệ thống đã triển khai và đề xuất, nhưng việc miêu tả chúng như là “lỗ hổng” hoặc “trước đây chưa biết đến” sẽ là quá đánh đồng.

Kháng kiểm duyệt vẫn là một giá trị cốt lõi của tiền điện tử nói chung, và Ethereum đặc biệt. Chúng tôi tin rằng những lợi ích của việc thực hiện giao dịch trên chuỗi nên được cung cấp cho bất kỳ ai, và rằng các quy tắc của chuỗi nên áp dụng cho tất cả người dùng và mục đích một cách công bằng. Giá trị thúc đẩy không gian này tiến lên phía trước. Kỹ thuật là quá trình kiểm tra giá trị của chúng tôi so với thực tế để tìm ra nơi và cách chúng bị hỏng.

Các quân Domino cũng được sắp xếp theo thứ tự :) Ảnh chụp bởi Tom WilsononUnsplash

Định nghĩa Kháng kiểm duyệt

Chúng tôi có xu hướng mô hình hóa kiểm duyệt là cố ý ngăn chặn các giao dịch xuất hiện trong thứ tự chuẩn (tức là loại trừ giao dịch). Chúng tôi coi các đơn đặt hàng là công bằng hoặc trung lập khi chúng phụ thuộc hoàn toàn vào kết quả kinh tế cho hệ thống đặt hàng và không công bằng hoặc bị kiểm duyệt khi chúng phụ thuộc vào thông tin khác. Ví dụ: khi tạo một khối, có thể chấp nhận từ chối bao gồm một giao dịch phí thấp, nhưng không thể chấp nhận từ chối bao gồm một giao dịch vì nó được gửi bởi một người cụ thể. Do đó, chúng tôi nói rằng một giao dịch bị kiểm duyệt nếu việc đưa nó vào phụ thuộc vào thông tin phi kinh tế. Nếu giao dịch tạo ra nhiều lợi nhuận có thể quan sát được cho hệ thống đặt hàng hơn bất kỳ giao dịch nào được bao gồm, nhưng bản thân nó không được bao gồm, nó được coi là bị kiểm duyệt. Định nghĩa này thúc đẩy công việc về các cơ chế bao gồm bắt buộc để chống kiểm duyệt. Nếu người dùng có thể buộc bao gồm giao dịch của họ, thì nó không thể bị kiểm duyệt theo định nghĩa này.

Cơ chế bắt buộc inclusion

Một mục tiêu bảo mật cốt lõi của các chuỗi OP Stack là rằng Sequencer không thể ngăn ngừa người dùng gửi giao dịch đến chuỗi L2.

Các rollup hiện đại thường có sự xếp hàng tập trung. Điều này có nghĩa là việc kiểm duyệt bởi người xếp hàng là không đáng kể, vì họ có thể đơn giản là chọn không bao gồm bất kỳ giao dịch người dùng nào. Để giảm thiểu điều này, một số rollup - bao gồm Lạc quanArbitrum- có cơ chế bao gồm bắt buộc. Cơ chế này cho phép người dùng đảm bảo rằng giao dịch của họ sẽ được thực hiện bởi rollup sau một khoảng thời gian trễ, bất kể hành vi của sequencer. Việc bao gồm được bắt buộc thông qua một hợp đồng triển khai trên L1. Do đó, các giao dịch bao gồm bắt buộc (lý thuyết là) có sự kháng cự tương tự như các giao dịch Ethereum khác.

Điều kiện bắt buộc chỉ định phạm vi phụ phải được bảo tồn trong bất kỳ thứ tự hợp lệ nào.

Một cơ chế bắt buộc cho sự bao gồm cũng đã được đề xuất cho Ethereum qua EIP-7547.Danh sách bao gồm sẽ cho phép đề xuất khối chỉ định một phần nội dung của khối tiếp theo. Dưới giả định rằng những người đề xuất khối có ít động cơ hơn để kiểm duyệt hơn những người xây dựng khối, điều đó sẽ cung cấp một phương pháp hạn chế hiệu quả cho việc kiểm duyệt.

Nói chung, các cơ chế bắt buộc sự xuất hiện tạo ra các ràng buộc mới về thứ tự hợp lệ. Chúng làm cho các lớp rộng của thứ tự trở nên không hợp lệ theo quy tắc giao thức.1. Sự bao gồm bắt buộc nên được xem như cho phép người dùng chỉ định một phần của thứ tự tương lai. Tất cả các thứ tự hợp lệ phải mở rộng trên tập hợp bắt buộc.

Mở rộng Mô hình của chúng tôi về Kháng kiểm duyệt

Rất tiếc, xác nhận giao dịch chỉ là phương tiện, chứ không phải là mục tiêu. Mô hình của chúng tôi về sự kháng kiểm duyệt là chưa hoàn chỉnh!

Kháng kiểm duyệt phải được xác định dựa trên mục tiêu. Người dùng muốn gửi token, mua NFT, vay vốn, v.v. Xác nhận giao dịch là phụ thuộc vào mục tiêu đó2. Các cơ quan kiểm duyệt cũng có mục tiêu cụ thể. Mục tiêu đó có thể là ngăn chặn một giao dịch hack nào đó thành công, tuân thủ một số quy định pháp luật hoặc can thiệp vào hoạt động kinh doanh của đối thủ cạnh tranh. Tôn trọng ý định của cả hai bên, chúng ta cần định nghĩa lại kháng kiểm duyệt.

Với điều này trong đầu, chúng ta nên mở rộng định nghĩa của chúng ta về kiểm duyệt để nói rằng: một giao dịch bị kiểm duyệt nếu một bên thứ ba có thể ngăn nó đạt được mục tiêu của nó. Nghĩa là, kẻ kiểm duyệt không cần ngăn chặn giao dịch từ xác nhận; họ chỉ cần khiến thực hiện hợp đồng thông minh bị trả lại. Làm cho một giao dịch EVM bị trả lại là kiểm duyệt của giao dịch đó, mặc dù giao dịch đó là một phần của chuỗi cơ sở dữ liệu. Mô hình đe dọa mù đến nội dung của một giao dịch không mô hình kiểm duyệt chính xác, và do đó không thể bảo vệ người dùng khỏi nó một cách hiệu quả.

Một cách bán chính thức, chúng ta có thể nói rằng đối với bất kỳ tương tác nào với chuỗi, có một tiên đề điểm số f đánh giá thứ tự kết quả và tạo ra 0 (mục tiêu thất bại) hoặc 1 (mục tiêu đạt được). Trong mô hình này, hàm điểm số của nhà kiểm duyệt đơn giản là phủ định: f '=! F. Nhà kiểm duyệt đạt được mục tiêu của họ khi người dùng không làm được điều đó.3

Mặc dù mục tiêu của người dùng có thể được giấu kín, giao dịch thực tế hầu như luôn chứa đủ thông tin để suy ra nó. Các giao dịch Uniswap có mục tiêu rõ ràng. Hơn nữa, vì blockchain là xác định được, người kiểm duyệt hoàn toàn có thể dự đoán được những thứ tự nào sẽ thỏa mãn mệnh đề của người kiểm duyệt. Kết quả là, người dùng không thể dựa vào thông tin giấu kín để bảo vệ mình khỏi kiểm duyệt trong mô hình EVM. Chi tiết giao dịch phải là công khai, điều đó có nghĩa là thông tin về mục tiêu của người dùng là công khai.

Đơn giản, hãy giả sử rằng chúng ta đang làm việc trong mô hình trình tự tiến chuẩn4. Chúng tôi sẽ xử lý việc bao gồm bắt buộc dưới sự xoay vòng của bộ điều khiển sau này. Trong mô hình này, bộ điều khiển có quyền kiểm soát hoàn toàn chuỗi và có thể mô phỏng hoàn hảo bất kỳ kết quả nào. Điều đó có nghĩa là họ có quyền lựa chọn từ tập hợp tất cả các thứ tự có thể có. Câu hỏi bán thực về việc kiểm duyệt sau đó trở thành "liệu có tồn tại một thứ tự hợp lệ mà f đánh giá là 0"? Nếu tồn tại một thứ tự như vậy, thì bộ điều khiển có thể chọn nó.

Từ đó, chúng ta có thể mở rộng mô hình của mình để tính đến sự bắt buộc phải bao gồm. “Liệu có tồn tại một thứ tự hợp lệ nào đó, bao gồm thứ tự con của người dùng, mà cho f đánh giá bằng 0 không?” Nếu một thứ tự như vậy tồn tại, bộ sắp xếp có thể chọn nó. Sự bắt buộc phải bao gồm không ngăn cản bộ sắp xếp thực hiện kiểm soát về thứ tự, nó chỉ hạn chế hành vi của họ. Thật không may, sự bắt buộc phải bao gồm có những vấn đề cơ bản ngăn cản nó trở thành một cơ chế sự kháng kiểm duyệt hiệu quả cho nhiều giao dịch.

Vấn đề chuyển giao

Cơ chế bắt buộc bao gồm hai chế độ sắp xếp: không bắt buộc hoặc bắt buộc. Có một điểm được xác định khi nó chuyển từ chế độ không bắt buộc sang chế độ bắt buộc (và ngược lại). Điểm đó là điểm giao nhận. Điểm giao nhận đặt ra một vấn đề gai góc cho thiết kế cơ chế bắt buộc bao gồm.

Phải có sự chuyển giao từ sự bao gồm tự nguyện sang bắt buộc.

Giao dịch bắt buộc được thực hiện trên trạng thái tại thời điểm chuyển giao. Vì vậy, một lần nữa, sự tranh chấp trạng thái5kháng cự trở nên tàn khốc. Khi việc chuyển giao diễn ra trong một lô giao dịch (như một khối), người tạo ra lô có thể kiểm soát trạng thái khi chuyển giao diễn ra. Nếu giao dịch bắt buộc phải bao gồm bất kỳ trạng thái công khai nào, người tạo ra lô có thể viết lại trạng thái đó trước và sau khi giao dịch bắt buộc thực hiện. Sự cạnh tranh đủ để chống lại kiểm duyệt.

Bởi vì người tạo lô có thể kiểm soát trạng thái tại thời điểm chuyển giao, do đó nó có thể ảnh hưởng đến kết quả của giao dịch bắt buộc. Nếu nó có thể ảnh hưởng đến kết quả, nó có thể tiềm ẩn ảnh hưởng đến kết quả của điều kiện đánh điểm. Ví dụ, xem xét một tương tác AMM đơn giản. Người dùng đặt một giá tối thiểu chấp nhận được, tuy nhiên, người tạo lô có thể đảm bảo rằng tại điểm chuyển giao, giá thị trường thấp hơn giá tối thiểu chấp nhận được. Điều này khiến giao dịch của người dùng hoàn nguyên, hiệu quả là kiểm duyệt người dùng.67

Thú vị thay, kiểm duyệt thông qua tranh chấp nhà nước hiệu quả hơn kiểm duyệt thông qua loại trừ. Một giao dịch bị loại trừ có thể được bao gồm trong các khối tương lai. Một giao dịch bị kiểm duyệt thông qua tranh chấp bị vô hiệu hóa vĩnh viễn. Nó đã được bao gồm trong chuỗi và không thể bao giờ được bao gồm lại. Giao dịch đó không bao giờ đạt được mục tiêu của người dùng. Để thử lại, người dùng phải tạo và gửi lại giao dịch (có thể bị kiểm duyệt lại).

Trong các hệ thống thực tế

Bất kỳ người dùng nào cũng có thể hoàn toàn bỏ qua Bộ sắp xếp để gửi bất kỳ giao dịch Arbitrum nào (bao gồm cả giao dịch khởi đầu một tin nhắn từ L2 đến L1 để rút tiền) trực tiếp từ lớp 1. Do đó, cơ chế này duy trì sự kháng kiểm duyệt ngay cả khi Bộ sắp xếp hoàn toàn không phản ứng hoặc thậm chí có ý đồ xấu.

Trong mô hình xếp hàng trước, người xếp hàng gần như hoàn toàn kiểm soát vị trí của việc chuyển giao trong chuỗi, và trả ít phí hơn (vì họ không cần đưa tiền boa và có thể thực hiện một số kiểm soát đối với EIP-1559 basefee). Kết quả là, người xếp hàng đang ở trong vị trí đặc quyền để sử dụng tranh chấp trạng thái để kiểm duyệt hành động của người dùng. Điều này là rất đơn giản. Vấn đề chuyển giao đảm bảo rằng người xếp hàng có thể kiểm duyệt các lớp giao dịch lớn.

Đối với EIP-7547, người xây dựng chọn nơi xảy ra việc chuyển giao khối.8 Do đó, người xây dựng có khả năng chọn vị trí bàn giao trong khối. Điều này có nghĩa là họ có thể chọn tiền tố và hậu tố theo ý muốn,9miễn là họ tôn trọng quy tắc gas khối. Tiền tố có thể đưa chuỗi vào trạng thái mà giao dịch sẽ quay lại, trong khi hậu tố sẽ khôi phục chuỗi về trạng thái bình thường. Danh sách bao gồm EIP-7547 không đủ để ngăn chặn sự kiểm duyệt cho bất kỳ giao dịch nào truy cập trạng thái gây tranh cãi. Vấn đề chuyển giao ngăn chặn ILs khỏi đảm bảo thực hiện giao dịch trong hầu hết các trường hợp.

Bao gồm bắt buộc là không hiệu quả trong việc bảo vệ người dùng khỏi sự kiểm duyệt đối với hầu hết các mục đích sử dụng không tầm thường của blockchain. Vấn đề chuyển giao đảm bảo rằng người kiểm duyệt có đủ quyền quyết định đối với nhà nước ngay cả khi họ không có đủ quyền quyết định về trật tự. Vấn đề này ảnh hưởng đến AMM, thị trường cho vay, đấu giá và hầu hết các hành động DeFi khác. Nhiều hành động quan trọng có thể kiểm duyệt ngay cả khi bạn có thể đảm bảo bao gồm giao dịch. Sự tranh cãi của nhà nước tạo ra những giới hạn cứng về hiệu quả của việc đưa vào cưỡng bức như một cơ chế chống kiểm duyệt.

Nghiên cứu trường hợp

Để thấy tác động xa rộng của điều này, hãy xem xét một người dùng cho vay USDC trên thị trường cho vay trên Optimism. Khi người dùng muốn rút USDC từ thị trường, họ gửi một giao dịch Optimism, mà sequencer kiểm duyệt. Sau đó, họ sử dụng cơ chế bao gồm bắt buộc chính thức để xếp hàng giao dịch của họ trên Ethereum, vượt qua sequencer.

Sequencer có thể nhìn thấy giao dịch đó trong hàng đợi và có thể chọn đặt nó vào giữa. Để kiểm duyệt giao dịch, sequencer vay toàn bộ USDC có sẵn từ thị trường ngay trước giao dịch bắt buộc. Do thị trường không còn thanh khoản, giao dịch bắt buộc bị hoàn nguyên. Sequencer sau đó có thể trả lại USDC ngay lập tức.

Người sắp xếp hoặc người xây dựng có thể thao tác trạng thái tại thời điểm chuyển giao.

Điều này yêu cầu bộ sắp xếp có tài sản đảm bảo đủ để vay USDC, nhưng chỉ áp đặt một chi phí vay rất nhỏ.10Hơn nữa, tài sản đảm bảo có thể tái sử dụng cho mọi sự kiểm duyệt, vì khoản vay không bao giờ được mở. Do đó, người dùng AAVE hoặc Compound trên Optimism (hoặc Arbitrum hoặc bất kỳ rollup theo trình tự trung tâm nào khác) không có bảo đảm rằng họ sẽ có thể rút tài sản đảm bảo bao giờ. Người xếp hàng có thể kiểm duyệt bất kỳ rút tiền từ bất kỳ thị trường cho vay nào vào bất kỳ thời điểm nào. Việc bắt buộc bao gồm đơn giản không đủ để bảo vệ người dùng khỏi sự kiểm duyệt.

Công việc theo dõi

Chúng tôi có một vài lĩnh vực nghiên cứu tiếp theo.

Đầu tiên, EIP-7547 có thể được cải thiện một cách dễ dàng bằng cách yêu cầu các giao dịch IL được xử lý vào cuối khối tiếp theo. Trong ngữ cảnh đấu giá PBS, sự kiểm duyệt là MEV. Người xây dựng tạo ra một số giá trị phi kinh tế, mà họ phải gán cho một giá trị chủ quan được định giá bằng ETH. Sự kiểm duyệt bởi người xây dựng do đó gây ra một sự tăng vọt trong đặt cược khối của người xây dựng.11Điều này mở rộng đến người tìm kiếm, người có thể tạo ra các gói kiểm duyệt. Một phần giá trị kinh tế của việc kiểm duyệt sau đó được thu thập bởi người đề xuất, tạo động lực để chịu đựng việc kiểm duyệt ngay cả khi không tham gia trực tiếp. Đặt các giao dịch bắt buộc bao gồm vào cuối khối sẽ loại bỏ khả năng của người xây dựng khối để dễ dàng đặt các giao dịch IL ở giữa, và tăng chi phí kinh tế của việc kiểm duyệt gây tranh cãi. Ví dụ, việc kiểm duyệt tương tác AMM thông qua tranh chấp trạng thái có thể đòi hỏi từ bỏ một số chênh lệch AMM hoặc một chi phí cao để đẩy thị trường ra khỏi phạm vi mà không thể thu hồi bằng cách đóng sandwich. Ngoài ra, điều này sẽ hạn chế các gói kiểm duyệt được tạo ra bởi người tìm kiếm (chứ không phải người xây dựng) chỉ một gói mỗi khối.12Chúng tôi sẽ khuyến nghị thực hiện đầu block, vì tiền tố quan trọng hơn hậu tố, tuy nhiên, điều đó sẽ tăng đáng kể chi phí của giao dịch IL, vì nó sẽ cho phép trích xuất MEV đầu block thông qua việc bắt buộc bao gồm.13Loại bỏ quyền của người kiểm duyệt tự động thêm hậu tố IL vào các giao dịch là một cải tiến nhỏ.

Vấn đề chuyển giao thứ hai tồn tại vì người kiểm duyệt có thể nhìn vào tương lai thông qua mô phỏng giao dịch và thực hiện kiểm soát trạng thái đầu vào. Nhiều cơ chế kháng MEV giới thiệu thông tin ẩn để loại bỏ khả năng của người kiểm duyệt để suy luận thông tin về mục tiêu của người dùng và mô phỏng kết quả. Thông thường, đây là các kế hoạch cam kết - tiết lộ, trong đó một số thông tin giao dịch là riêng tư cho đến sau khi sắp xếp xảy ra. Phân tách thứ tự-thực hiện và thông tin ẩn dường như hứa hẹn, nhưng lớn phần không tương thích với chuỗi cung ứng MEV, quy trình đồng thuận Ethereum và mô hình sequenced rollup. Một cách để kháng khả năng mô phỏng giao dịch sẽ giải quyết vấn đề kiểm duyệt và các lớp lớn của MEV, nhưng sẽ rất xâm phạm đối với giao thức, các nhà điều hành của giao thức, ứng dụng và người dùng cuối cùng.

Thứ ba, có một loại hàm điểm "độc lập với thứ tự" thú vị. Đây là những mục tiêu không thể bị kiểm duyệt bởi sự tranh cãi của quốc gia, hoặc là vì chúng không truy cập vào trạng thái gây tranh cãi, hoặc là vì trạng thái gây tranh cãi mà chúng truy cập có ràng buộc đủ để làm cho nó "đáng tin cậy" theo một số ý nghĩa nào đó. Các hành động độc lập với thứ tự bao gồm việc gửi ETH đến một EOA, hầu hết các gửi ERC-20,14và một số tương tác DeFi như thêm tài sản thế chấp vào một thị trường. Những hành động này được bảo vệ khỏi kiểm duyệt thông qua sự tranh đấu. Lớp mục tiêu này cũng có những tương ứng thú vị trong việc giao tiếp an toàn giữa các chuỗi và sự chống lại MEV, đáng đồng nghiệp nghiên cứu sâu hơn. Các ứng dụng và giao thức có thể được thiết kế để chỉ bao gồm các hành động độc lập với thứ tự trong một số trường hợp, nhưng cần nghiên cứu thêm.

Kết luận

Nhà nước giàu cho phép các tác nhân độc hại kiểm duyệt các giao dịch trong khi vẫn bao gồm chúng. Vấn đề bàn giao là nền tảng cho các cơ chế hòa nhập bắt buộc, và chỉ có thể được giảm thiểu. Trong các bản tổng hợp được sắp xếp theo trình tự tập trung, không thể giảm nhẹ. Bao gồm bắt buộc không thể giải quyết kiểm duyệt khi có sự hiện diện của nhà nước gây tranh cãi. Các lớp giao dịch lớn quan trọng về kinh tế có thể bị kiểm duyệt, ngay cả khi được bao gồm bằng vũ lực. Vấn đề bàn giao là đặc hữu trong các bản cập nhật hiện đại và hiện diện trong các EIP chống kiểm duyệt của Ethereum. Kết quả là, sự bao gồm bắt buộc, mặc dù có lợi, không bao giờ đủ để cung cấp khả năng chống kiểm duyệt cho các chuỗi nhà nước giàu. Rollups không "kế thừa" các thuộc tính bảo mật của Ethereum và thật ngớ ngẩn khi đề xuất rằng chúng có. Khi bạn ngừng ám ảnh về việc đưa vào, rõ ràng là khả năng chống kiểm duyệt là một trường hợp đặc biệt của kháng MEV.

Chúng tôi muốn cảm ơnMike Neuder, Tarun Chitra, và Brandon Curtisđể xem xét và phản hồi.

1

Như thông thường, đối với L1s, điều này được thực hiện bằng cách từ chối các khối không hợp lệ, trong khi đối với rollups, điều này được thực hiện bằng cách ép buộc các chuỗi không hợp lệ thành chuỗi hợp lệ thông qua một chức năng lọc nào đó.

2

Đây không phải là một bài viết về ý định, thế giới không cần nhiều hơn những điều đó vào thời điểm này.

3

Đây rõ ràng là một mô hình chưa hoàn chỉnh, vì nó không tính đến các giá trị chủ quan của các kết quả. Ví dụ, người kiểm duyệt có thể mất bất kỳ số tiền nào nếu kiểm duyệt thất bại (ví dụ, vì họ có thể bị bắt bởi cảnh sát Pháp nếu họ không kiểm duyệt hành vi cụ thể). Ngược lại, người dùng có thể có thể mất/giành được bất kỳ số tiền nào nếu mục tiêu của họ không đạt được trong một khung thời gian cụ thể (ví dụ, họ đã vay hơn 100 triệu đô la bằng token của họ và cần tái cấp bảo vị trí trước khi bị thanh lý).

4

Ngược lại với mô hình sequencer “dựa trên”. Trong hầu hết các rollup hiện đại, sequencer “chạy trước” Ethereum bằng cách cung cấp xác nhận và thực thi cho một giao dịch trước khi giao dịch đó được cam kết vào Ethereum. Trong mô hình này, Sequencer hoàn toàn kiểm soát chuỗi và kết quả của giao dịch phải độc lập với Ethereum reorgs.

5

Khi nhiều người dùng muốn truy cập vào cùng một hợp đồng, tài sản hoặc trạng thái, giao dịch của họ 'đấu tranh' với nhau và có thể gây can thiệp vào kết quả của nhau. Sự tranh cãi có thể phát sinh ngẫu nhiên hoặc cố ý. Đây là một vấn đề không thể giải quyết của trạng thái phong phú trong hệ thống blockchain. Việc truy cập công cộng đến trạng thái chia sẻ là nguyên nhân gốc của MEV, vấn đề về khả năng mở rộng và sự suy giảm về văn minh trong xã hội hiện đại.

6

Nói chung, bạn nên coi việc kiểm duyệt thông qua tranh chấp nhà nước là một trường hợp chuyên biệt của MEV. Bởi vì giá trị được trích xuất là ngoài chuỗi, không thể quan sát được và có thể rất lớn, nên có thể khó đoán khi nào kiểm duyệt thông qua tranh chấp nhà nước sẽ xảy ra.

7

Chúng tôi đặc biệt đề cập đến việc sử dụng tranh chấp nhà nước để hoàn nguyên các giao dịch trong bài viết năm 2017 của chúng tôi "Thợ đào không phải là bạn của bạn”. Khi đó thuật ngữ “MEV” chưa được sử dụng.

8

Ai cũng biết rằng PBS làm phức tạp đáng kể khả năng chống kiểm duyệt. Xem VB's @vbuterin/pbs_kháng_kiểm duyệt">note nghiên cứu.

9

Việc đặt tiền tố và hậu tố cho một giao dịch thường được gọi là “sandwiching” và được hiểu rõ như một phương pháp sử dụng sự tranh giành trạng thái để trích xuất MEV.

10

Vay được giữ trong chỉ vài giây, nếu có. Trình tự Rollup có thể trong một số trường hợp giữ thời gian dấu thời gian hoặc ranh giới khối để làm thời gian vay hiệu quả bằng 0.

11

Nhà xây dựng sẽ sẵn sàng trả giá trị chủ quan của họ về kiểm duyệt, có khả năng đẩy giá thầu lên trên giá trị có thể trích xuất có thể quan sát khách quan của khối. Trong trường hợp cực đoan, điều này có thể dẫn đến trường hợp người kiểm duyệt có thay đổi số dư ETH âm (tức là họ trả nhiều ETH hơn để tạo khối so với phí và phần thưởng).

12

Lưu ý rằng điều này dựa trên các quy tắc đấu giá MEV ngăn chặn các giao dịch xen kẽ từ các gói khác nhau và không cho phép các giao dịch "phải hoàn nguyên". Nếu các quy tắc đó được nới lỏng để cho phép các gói txn được xen kẽ và / hoặc nếu các nhà xây dựng bắt đầu hỗ trợ các khối "phải hoàn nguyên" trong các gói, sự bảo vệ sẽ bốc hơi. Động lực này phát sinh bởi vì nếu các giao dịch IL phải ở cuối khối, không có giao dịch không bắt buộc nào có thể được xen kẽ, và do đó nhiều nhất là một gói kiểm duyệt người tìm kiếm có thể xảy ra.

13

Cho phép nhà xây dựng tạo các gói giới hạn giữa các khối. Hệ thống tiền đồng thuận trước như Gate.io,FOCILcó thể giảm thiểu điều này.

14

Đối với mã thông báo ERC-20 tiêu chuẩn, cuộc gọi chuyển khoản thường không bị kiểm duyệt thông qua tranh chấp, vì các bên thứ ba không thể giảm số dư của người dùng. Tuy nhiên, hãy xem xét một cuộc gọi chuyểnTừ. Nếu bên chuyển nhượng được chấp thuận là một hợp đồng cho phép tranh chấp trên chính trạng thái của mình, thì hành động có thể bị kiểm duyệt thông qua tranh chấp đó (tiêu thụ sự chấp thuận cần thiết cho việc chuyển nhượngTừ một số cách ngoài ý muốn).

Disclaimer:

  1. Bài viết này được in lại từ [Công nghệ], Tất cả bản quyền thuộc về tác giả gốc [khởi tạo 4]. Nếu có đối sách với việc tái bản này, xin vui lòng liên hệ Gate Họcđội ngũ, và họ sẽ xử lý nhanh chóng.
  2. Bảo Đảm Trách Nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ là của tác giả và không hề đại diện cho bất kỳ lời khuyên đầu tư nào.
  3. Bản dịch bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn các bài báo đã dịch đều bị cấm.
Bắt đầu giao dịch
Đăng ký và giao dịch để nhận phần thưởng USDTEST trị giá
$100
$5500