Về giới hạn của mempool mã hóa

Giá trị có thể được trích xuất bằng cách bao gồm, loại trừ hoặc sắp xếp lại các giao dịch trong một khối được gọi là "giá trị tối đa có thể trích xuất, hoặc MEV. MEV phổ biến trên hầu hết các blockchain, và đã trở thành một chủ đề gây chú ý và thảo luận rộng rãi trong cộng đồng.

Lưu ý: Bài viết trên blog này giả định rằng bạn có sự quen thuộc cơ bản với MEV. Một số độc giả có thể muốn bắt đầu bằng cách đọc bài viết của chúng tôi Giải thích MEV.

Nhiều nhà nghiên cứu, quan sát tình hình MEV, đã đặt ra một câu hỏi rõ ràng: Liệu mật mã có giải quyết được vấn đề không? Một cách tiếp cận là mempool được mã hóa, nơi người dùng phát sóng các giao dịch được mã hóa chỉ được tiết lộ sau khi chúng được sắp xếp. Do đó, một giao thức đồng thuận sẽ phải cam kết sắp xếp giao dịch một cách mù quáng, dường như ngăn chặn khả năng tận dụng các cơ hội MEV trong quá trình sắp xếp.

Thật không may, vì cả lý do thực tiễn và lý thuyết, chúng tôi không thấy các mempool được mã hóa cung cấp một giải pháp phổ quát cho MEV. Chúng tôi phác thảo những khó khăn và khám phá cách mà các mempool được mã hóa có thể được thiết kế.

Cách hoạt động của mempool được mã hóa

Đã có nhiều đề xuất cho các mempool được mã hóa, nhưng khung tổng thể cho các mempool được mã hóa như sau:

1. Người dùng phát tán các giao dịch được mã hóa của họ.
2. Các giao dịch được mã hóa được cam kết trên chuỗi (trong một số đề xuất sau khiđược xáo trộn một cách có thể chứng minh ngẫu nhiên)
3. Sau khi khối cam kết được hoàn tất, các giao dịch sẽ được giải mã.
4. Cuối cùng, các giao dịch được thực hiện.

Lưu ý rằng bước 3 (giải mã giao dịch) đặt ra một thách thức quan trọng: Ai sẽ giải mã, và nếu việc giải mã không xảy ra thì sao? Một giải pháp ngây thơ sẽ là nói rằng chính người dùng tự giải mã giao dịch của họ (trong trường hợp này người ta thậm chí không cần mã hóa, mà chỉ cần ẩn các cam kết). Tuy nhiên, cách tiếp cận này dễ bị tổn thương: Một kẻ tấn công có thể thực hiệnMEV suy đoán.

Với MEV suy đoán, một kẻ tấn công cố gắng đoán rằng một giao dịch mã hóa nhất định mang lại một số MEV. Họ mã hóa các giao dịch của riêng mình mà hy vọng sẽ xuất hiện ở một vị trí thuận lợi (ví dụ: ngay trước hoặc sau một giao dịch mục tiêu). Nếu giao dịch được sắp xếp theo thứ tự như mong đợi, kẻ tấn công giải mã và giao dịch của họ trích xuất MEV. Nếu không, họ từ chối giải mã và giao dịch của họ không được đưa vào chuỗi cuối cùng.

Có thể người dùng sẽ phải đối mặt với một số hình phạt nếu không giải mã được, nhưng điều này khó thực hiện. Hình phạt cần phải giống nhau cho tất cả các giao dịch được mã hóa (do chúng được mã hóa và do đó không thể phân biệt), nhưng cũng phải đủ lớn để ngăn chặn MEV đầu cơ ngay cả đối với các mục tiêu có giá trị cao. Điều này sẽ yêu cầu phải chôn vốn lớn, vốn nên được ẩn danh (để tránh rò rỉ thông tin về các giao dịch do ai đăng tải). Và nó sẽ khiến người dùng trung thực phải chịu chi phí trong trường hợp có lỗi hoặc sự cố mạng ngăn cản nỗ lực hợp pháp của họ để giải mã.

Do đó, hầu hết các đề xuất gợi ý rằng các giao dịch nên được mã hóa theo cách mà việc giải mã được đảm bảo có thể thực hiện được vào một thời điểm nào đó trong tương lai — ngay cả khi người đăng tải không trực tuyến hoặc không hợp tác. Điều này có thể đạt được theo nhiều cách:

TEEs: Người dùng có thể mã hóa giao dịch của họ bằng một khóa được giữ bởi Môi trường thực thi đáng tin cậy ( TEE) enclave. Trong một số phiên bản đơn giản, TEE chỉ được sử dụng để giải mã các giao dịch sau một thời hạn nhất định (điều này yêu cầu một khái niệm về thời gian trong TEE). Các phương pháp tiên tiến hơn sử dụng TEE để giải mã các giao dịch và xây dựng khối, sắp xếp chúng dựa trên một số tiêu chí như thời gian đến hoặc phí. Một lợi thế của TEE so với các phương pháp mempool mã hóa khác là khả năng hoạt động trên các giao dịch plaintext, do đó giảm thiểu spam trên chuỗi bằng cách lọc ra những giao dịch sẽ bị đảo ngược. Tuy nhiên, phương pháp này yêu cầu sự tin tưởng vào phần cứng.

Chia sẻ bí mật và mã hóa ngưỡng: Với phương pháp này, người dùng mã hóa giao dịch bằng một khóa được chia sẻ bởi một ủy ban, thường là một phần của các validator. Một ngưỡng nhất định (ví dụ, hai phần ba của ủy ban) là cần thiết để giải mã.

Cách tiếp cận đơn giản nhất sử dụng một khóa giải mã chung mới trong mỗi vòng (ví dụ, mỗi khối hoặc thời kỳ trên Ethereum), mà ủy ban tái tạo và công bố sau khi các giao dịch được sắp xếp trong một khối đã hoàn tất. Cách tiếp cận này có thể sử dụng chia sẻ bí mật đơn giản. Nhược điểm là điều này tiết lộ tất cả các giao dịch từ mempool, ngay cả những giao dịch không được bao gồm trong một khối. Cách tiếp cận này cũng yêu cầu một quá trình tạo khóa phân tán (DKG) mới trong mỗi vòng.

Một cách tiếp cận tốt hơn cho quyền riêng tư là chỉ giải mã những giao dịch thực sự được bao gồm. Điều này có thể được thực hiện bằng cách sử dụng giải mã ngưỡng. Cách tiếp cận này cũng cho phép phân bổ chi phí của các giao thức DKG bằng cách sử dụng cùng một khóa cho nhiều khối với ủy ban giải mã ngưỡng các giao dịch sau khi chúng được sắp xếp trong một khối đã hoàn tất. Một thách thức là ủy ban phải làm nhiều công việc hơn. Một cách đơn giản, công việc của ủy ban là tuyến tính theo số lượng giao dịch cần giải mã, mặc dù gần đâycông việcđề xuất giải mã ngưỡng theo lô, điều này có thể cải thiện đáng kể.

Với giải mã ngưỡng, niềm tin chuyển từ một phần cứng sang một ủy ban. Khẳng định là, vì hầu hết các giao thức đã đưa ra giả định đa số trung thực về các validator cho giao thức đồng thuận, chúng ta có thể đưa ra một giả định tương tự rằng một đa số các validator là trung thực và sẽ không giải mã các giao dịch sớm. Tuy nhiên, cần lưu ý rằng đây không phải là cùng một giả định về niềm tin. Các thất bại đồng thuận như phân nhánh chuỗi là công khai (được gọi là giả định niềm tin yếu), trong khi một ủy ban độc hại giải mã các giao dịch sớm một cách riêng tư sẽ không tạo ra bất kỳ bằng chứng công khai nào và do đó, một cuộc tấn công như vậy không thể bị phát hiện hoặc bị giảm bớt (một giả định niềm tin mạnh). Do đó, trong khi từ bên ngoài, các giả định an ninh cho đồng thuận và một ủy ban mã hóa có thể trông giống nhau, các cân nhắc thực tiễn khiến giả định rằng một ủy ban sẽ không thông đồng trở nên mong manh hơn.

Mã hóa khóa thời gian và trì hoãn: Một phương pháp thay thế cho mã hóa ngưỡng xuất hiện dưới dạng mã hóa trì hoãn. Người dùng mã hóa giao dịch của họ bằng một khóa công khai mà khóa bí mật ẩn bên trong một câu đố khóa thời gian. Một câu đố khóa thời gian là một câu đố mật mã học bao gồm một bí mật, chỉ có thể được tiết lộ sau một khoảng thời gian đã được xác định trước – cụ thể hơn, câu đố này có thể được giải mã bằng cách thực hiện lặp đi lặp lại một số tính toán không thể thực hiện song song. Trong trường hợp này, bất kỳ ai cũng có thể mở câu đố này để phục hồi khóa và giải mã giao dịch, nhưng chỉ sau một tính toán chậm (vốn dĩ là tuần tự) được thiết kế để mất đủ thời gian mà các giao dịch không thể được giải mã trước khi chúng được hoàn tất. Phiên bản mạnh nhất của phương pháp này sử dụng mã hóa trễ để công khai tạo ra một câu đố như vậy. Nó cũng có thể được ước lượng bằng cách sử dụng một ủy ban đáng tin cậy để tính toán câu đố thông qua mã hóa khóa thời gian, mặc dù vào lúc đó, những lợi thế so với mã hóa ngưỡng là đáng nghi.

Dù là thông qua mã hóa trì hoãn hay tính toán bởi một ủy ban đáng tin cậy, có một số thách thức thực tiễn. Thứ nhất, việc đảm bảo thời gian giải mã chính xác trở nên khó khăn hơn, vì độ trễ mang tính chất tính toán. Thứ hai, các phương án này phụ thuộc vào một thực thể vận hành phần cứng tinh vi để giải quyết các câu đố một cách hiệu quả. Trong khi bất kỳ ai cũng có thể đảm nhận vai trò này, thì việc khuyến khích bên này vẫn chưa rõ ràng. Cuối cùng, trong các thiết kế này, tất cả các giao dịch được phát sóng sẽ được giải mã, bao gồm cả những giao dịch chưa bao giờ được hoàn tất trong một khối. Các giải pháp dựa trên ngưỡng (hoặc mã hóa nhân chứng) có thể chỉ giải mã các giao dịch được bao gồm thành công.

Mã hóa nhân chứng. Cuối cùng, phương pháp mã hóa tiên tiến nhất sử dụng một công cụ gọi là mã hóa nhân chứng. Về lý thuyết, mã hóa nhân chứng cho phép mã hóa thông tin cho bất kỳ ai biết nhân chứng cho một mối quan hệ NP cụ thể. Ví dụ, người ta có thể mã hóa để bất kỳ ai có giải pháp cho một câu đố Sudoku nhất định, hoặc bất kỳ ai có hình ảnh băm của một giá trị nhất định, có thể giải mã.

SNARKs cũng có thể được áp dụng cho bất kỳ mối quan hệ NP nào. Người ta có thể nghĩ về mã hóa chứng cứ như là mã hóa dữ liệu cho bất kỳ ai có thể tính toán một SNARK chứng minh một điều kiện mong muốn. Đối với các mempool được mã hóa, một ví dụ cho một điều kiện như vậy sẽ là các giao dịch chỉ có thể được giải mã khi một khối đã được hoàn tất.

Đây là một nguyên lý lý thuyết rất mạnh mẽ. Thực tế, đây là một sự tổng quát mà từ đó các phương pháp dựa trên ủy ban và các phương pháp dựa trên độ trễ là các trường hợp cụ thể. Thật không may, chúng tôi không có bất kỳ cấu trúc thực tiễn nào của mã hóa dựa trên nhân chứng. Hơn nữa, ngay cả khi chúng tôi có, thì cũng không rõ làm thế nào nó cải thiện so với phương pháp dựa trên ủy ban cho các chuỗi proof-of-stake. Ngay cả khi mã hóa nhân chứng được thiết lập để các giao dịch chỉ có thể được giải mã khi chúng được sắp xếp trong một khối đã hoàn tất, một ủy ban ác ý vẫn có thể mô phỏng riêng tư giao thức đồng thuận sao cho giao dịch được hoàn tất, và sau đó sử dụng chuỗi riêng tư này như một nhân chứng để giải mã các giao dịch. Tại thời điểm đó, việc sử dụng giải mã ngưỡng bởi cùng một ủy ban cung cấp sự bảo mật tương đương và đơn giản hơn nhiều.

Mã hóa nhân chứng cung cấp một lợi thế quyết định hơn trong các giao thức đồng thuận proof-of-work, vì ngay cả một ủy ban hoàn toàn ác ý cũng không thể khai thác riêng tư nhiều khối mới trên đỉnh hiện tại để mô phỏng sự kết thúc.

Những thách thức kỹ thuật cho mempool được mã hóa

Nhiều thách thức thực tiễn quan trọng hạn chế khả năng của các mempool được mã hóa trong việc ngăn chặn MEV. Nói chung, việc giữ thông tin bí mật là rất khó. Thú vị thay, mã hóa là một công cụ hiếm khi được sử dụng trong không gian web3. Nhưng chúng ta có hàng thập kỷ kinh nghiệm thực tiễn cho thấy những thách thức khi triển khai mã hóa trên web (TLS/HTTPS) và cho việc giao tiếp riêng tư (từ PGP đến các nền tảng nhắn tin mã hóa hiện đại như Signal hoặc Whatsapp). Trong khi mã hóa là một công cụ để bảo vệ tính bảo mật, nó không đảm bảo được điều đó.

Đầu tiên, có thể có những bên với quyền truy cập trực tiếp vào văn bản rõ của giao dịch của người dùng. Trong các trường hợp điển hình, người dùng có thể không mã hóa giao dịch của chính họ mà giao việc này cho nhà cung cấp ví của họ. Do đó, nhà cung cấp ví có quyền truy cập vào giao dịch văn bản rõ và có thể sử dụng hoặc bán thông tin này để trích xuất MEV. Mã hóa không bao giờ mạnh hơn tập hợp các bên có quyền truy cập vào khóa.

Ngoài ra, vấn đề lớn nhất là siêu dữ liệu, tức là dữ liệu xung quanh payload được mã hóa (giao dịch), mà không được mã hóa. Những người tìm kiếm có thể sử dụng siêu dữ liệu này để đoán ý định của một giao dịch và sau đó cố gắng thực hiện MEV suy đoán. Hãy nhớ rằng, những người tìm kiếm không cần phải hiểu hoàn toàn một giao dịch, hoặc phải đúng mỗi lần. Chỉ cần họ biết, ví dụ, rằng với một xác suất hợp lý nào đó, một giao dịch đại diện cho một đơn hàng mua từ một DEX cụ thể.

Chúng ta có thể xem xét một số loại siêu dữ liệu, một số trong đó là những thách thức cổ điển với mã hóa và một số là duy nhất cho các mempool được mã hóa.

• Kích thước giao dịch: Mã hóa tự nó không che giấu kích thước của văn bản rõ ràng được mã hóa. (Có một ngoại lệ cụ thể nổi tiếng được đưa ra trong các định nghĩa chính thức về an ninh ngữ nghĩa để loại trừ việc che giấu kích thước của văn bản rõ ràng đang được mã hóa.) Đây là một vector tấn công cổ điển đối với giao tiếp được mã hóa. (Trong một ví dụ nổi tiếng, ngay cả khi có mã hóa, một kẻ nghe lén...có thể xác định video nào đang được phát trực tiếp trên Netflix theo thời gian thực từ kích thước của từng gói trong luồng video.) Trong bối cảnh mempool được mã hóa, một số loại giao dịch có thể có kích thước cụ thể mà rò rỉ thông tin.

• Thời gian phát sóng: Mã hóa cũng không che giấu thông tin thời gian (khácvector tấn công cổ điển). Trong bối cảnh web3, một số người gửi — chẳng hạn như trong việc bán có cấu trúc — có thể thực hiện giao dịch ở các khoảng thời gian đều đặn. Thời gian giao dịch cũng có thể liên quan đến thông tin khác, chẳng hạn như hoạt động trên các sàn giao dịch bên ngoài hoặc các sự kiện tin tức. Một cách tinh tế hơn để khai thác thông tin thời gian là chênh lệch giá giữa CEX và DEX. Một trình sắp xếp có thể hưởng lợi từ việc chèn một giao dịch được tạo ra muộn nhất có thể, tận dụng thông tin gần đây hơn về giá CEX. Trình sắp xếp đó có thể loại trừ bất kỳ giao dịch nào khác (ngay cả khi được mã hóa) được phát sóng sau một thời điểm nhất định, đảm bảo rằng giao dịch của nó một mình có lợi thế về thông tin giá mới nhất.

• Địa chỉ IP ban đầu: Những người tìm kiếm có thể suy ra danh tính của người gửi giao dịch bằng cách theo dõi mạng ngang hàng và quan sát địa chỉ IP ban đầu. Vấn đề này thực tế là được xác định cách đây hơn mười năm trong những ngày đầu của Bitcoin. Điều này có thể hữu ích cho những người tìm kiếm nếu các người gửi cụ thể có những mẫu cụ thể — ví dụ, biết người gửi có thể cho phép liên kết một giao dịch mã hóa với các giao dịch trước đó đã được giải mã.

• Thông tin người gửi giao dịch và phí/gas: Cuối cùng, phí giao dịch đại diện cho một loại siêu dữ liệu đặc trưng cho các mempool được mã hóa. Trong Ethereum, giao dịch thường bao gồm một địa chỉ người gửi (trên chuỗi), được sử dụng để thanh toán phí, cũng như một ngân sách gas tối đa và một mức phí mỗi đơn vị gas mà người gửi sẵn sàng trả. Địa chỉ người gửi, giống như địa chỉ mạng gốc, có thể được sử dụng để liên kết các giao dịch với nhau và với các thực thể trong thế giới thực. Ngân sách gas có thể được sử dụng để ước lượng những gì giao dịch dự định thực hiện. Ví dụ, việc tương tác với một DEX cụ thể có thể yêu cầu một lượng gas nhất định có thể nhận diện.

Các nhà tìm kiếm tinh vi có thể sử dụng bất kỳ sự kết hợp nào của các loại siêu dữ liệu ở trên để dự đoán nội dung của một giao dịch.

Tất cả thông tin này có thể bị ẩn đi, nhưng với chi phí hiệu suất và độ phức tạp. Ví dụ, việc thêm vào các giao dịch lên đến một giới hạn tiêu chuẩn ẩn kích thước giao dịch, nhưng lại lãng phí băng thông và không gian trên chuỗi. Việc thêm độ trễ trước khi gửi tin nhắn ẩn thời gian giao dịch, nhưng lại làm tổn hại đến độ trễ. Việc gửi giao dịch qua một mạng ẩn danh như Tor có thể ẩn địa chỉ IP của người gửi, nhưng điều này có những thách thức riêng của nó.

Dữ liệu metadata khó nhất để ẩn là dữ liệu phí giao dịch. Mã hóa dữ liệu này tạo ra một số thách thức cho người xây dựng. Vấn đề đầu tiên là spam. Nếu dữ liệu thanh toán phí giao dịch được mã hóa, thì bất kỳ ai cũng có thể phát tán các giao dịch mã hóa bị biến dạng mà sẽ được sắp xếp nhưng không có khả năng thanh toán phí. Do đó, sau khi giải mã, họ sẽ không thể thực hiện nhưng không bên nào có thể bị phạt. Điều này có thể được giải quyết bằng SNARKs chứng minh rằng một giao dịch là hợp lệ và được tài trợ, nhưng điều này sẽ làm tăng đáng kể chi phí.

Vấn đề thứ hai là xây dựng khối hiệu quả và đấu giá phí. Các nhà xây dựng sử dụng phí để xây dựng khối có lợi nhuận cao nhất và thiết lập giá thị trường hiện tại cho các tài nguyên onchain. Mã hóa dữ liệu này làm gián đoạn quá trình này. Điều này có thể được giải quyết bằng cách thiết lập một khoản phí cố định trong mỗi khối, nhưng điều này không hiệu quả về mặt kinh tế và có thể khuyến khích các thị trường thứ cấp cho việc đưa giao dịch vào mà sẽ làm suy yếu mục đích của việc có một mempool được mã hóa. Việc tiến hành đấu giá phí bằng cách sử dụng tính toán đa bên an toàn hoặc phần cứng đáng tin cậy là khả thi, nhưng cả hai đều là những bước tốn kém.

Cuối cùng, các mempool được mã hóa và bảo mật tạo ra chi phí cho hệ thống theo nhiều cách. Mã hóa làm tăng độ trễ, chi phí tính toán và băng thông cho chuỗi. Cách kết hợp nó với hỗ trợ cho sharding hoặc thực thi song song — những mục tiêu quan trọng trong tương lai — là điều không dễ dàng. Nó có thể tạo ra các điểm thất bại bổ sung cho việc duy trì hoạt động (ví dụ: ủy ban giải mã cho các giải pháp ngưỡng hoặc bộ giải hàm trễ). Và chắc chắn rằng nó làm tăng độ phức tạp trong thiết kế và triển khai.

Nhiều vấn đề của mempool mã hóa được chia sẻ bởi các blockchain tự mình có mục tiêu đảm bảo quyền riêng tư giao dịch (ví dụ: Zcash, Monero). Nếu có một điều tích cực, đó là việc giải quyết tất cả các thách thức của việc mã hóa để giảm thiểu MEV sẽ có tác dụng phụ là mở đường cho quyền riêng tư giao dịch.

Những thách thức kinh tế cho các mempool mã hóa

Cuối cùng, các mempool mã hóa phải đối mặt với những thách thức kinh tế. Khác với những thách thức kỹ thuật, có thể giảm thiểu với đủ nỗ lực kỹ thuật, đây là những hạn chế cơ bản mà dường như khó giải quyết.

Vấn đề cơ bản của MEV xuất phát từ sự bất đối xứng thông tin giữa người dùng tạo giao dịch và các nhà tìm kiếm và xây dựng tìm kiếm cơ hội MEV. Người dùng thường không biết có bao nhiêu MEV có thể được khai thác từ các giao dịch của họ. Do đó, ngay cả khi có một mempool được mã hóa hoàn hảo, người dùng có thể bị thuyết phục từ bỏ các khóa giải mã của họ để đổi lấy một khoản thanh toán từ các nhà xây dựng mà ít hơn giá trị được khai thác. Chúng ta có thể gọi đây là giải mã có động lực.

Không khó để tưởng tượng điều này sẽ trông như thế nào vì một phiên bản của nó, được gọi là MEV Share, hiện đang tồn tại. MEV Share là một cuộc đấu giá luồng đơn đặt hàng cho phép người dùng chọn lọc gửi thông tin về giao dịch của họ vào một bể nơi các tìm kiếm cạnh tranh để có cơ hội khai thác cơ hội MEV mà giao dịch đó mang lại. Người tìm kiếm có giá thầu thắng sẽ khai thác MEV và hoàn trả một phần lợi nhuận của họ (tức là giá thầu hoặc một phần của giá thầu) cho người dùng.

Mô hình này có thể được điều chỉnh ngay lập tức trong không gian mempool được mã hóa, yêu cầu người dùng tiết lộ khóa giải mã của họ (hoặc có thể chỉ một số thông tin một phần) để tham gia. Nhưng hầu hết người dùng sẽ không hiểu chi phí cơ hội của việc tham gia vào một kế hoạch như vậy, chỉ nhìn thấy phần thưởng quay trở lại với họ và vui vẻ từ bỏ thông tin của mình. Cũng có những ví dụ từ tài chính truyền thống (ví dụ: các dịch vụ giao dịch không phí như Robinhood) kiếm lợi từ việc bán dòng lệnh của người dùng cho các bên thứ ba trong cái gọi là ".payment-for-order-flow” mô hình kinh doanh.

Các kịch bản khác có thể bao gồm những nhà phát triển lớn buộc người dùng phải tiết lộ giao dịch của họ (hoặc một số thông tin về chúng) vì lý do kiểm duyệt. Khả năng chống kiểm duyệt là một chủ đề quan trọng và gây tranh cãi trong web3, nhưng nếu các nhà đề xuất lớn và/hoặc nhà phát triển bị buộc phải thực thi một danh sách kiểm duyệt (ví dụ, bởi OFAC), họ có thể từ chối sắp xếp bất kỳ giao dịch được mã hóa nào. Có thể giải quyết vấn đề này một cách kỹ thuật, nếu người dùng có thể sản xuất một bằng chứng không kiến thức rằng giao dịch được mã hóa của họ tuân thủ danh sách kiểm duyệt, nhưng điều này cũng sẽ tăng thêm chi phí và độ phức tạp. Ngay cả khi chuỗi có khả năng kháng kiểm duyệt mạnh mẽ, nơi các giao dịch được mã hóa được đảm bảo sẽ được bao gồm, các nhà xây dựng khối vẫn có thể ưu tiên đặt các giao dịch mà họ biết ở dạng văn bản rõ ở đầu khối và hạ thấp bất kỳ giao dịch được mã hóa nào xuống dưới cùng của khối. Do đó, các giao dịch muốn có những đảm bảo thực thi nhất định có thể buộc phải tiết lộ nội dung của chúng cho các nhà xây dựng dù sao đi nữa.

Các thách thức về hiệu quả khác

Mempool được mã hóa tạo ra gánh nặng cho hệ thống theo một vài cách rõ ràng. Người dùng phải mã hóa các giao dịch và hệ thống phải bằng cách nào đó giải mã chúng. Điều này làm tăng chi phí tính toán và có thể làm tăng kích thước giao dịch. Như đã thảo luận ở trên, việc xử lý siêu dữ liệu có thể làm cho các gánh nặng này trở nên tồi tệ hơn. Tuy nhiên, một số chi phí hiệu quả khác thì ít rõ ràng hơn. Trong tài chính, một thị trường được coi là hiệu quả nếu giá cả phản ánh tất cả thông tin có sẵn, và sự không hiệu quả xuất hiện từ các sự chậm trễ và sự bất đối xứng thông tin — những hậu quả tự nhiên của mempool được mã hóa.

Một trong những hệ quả của những sự không hiệu quả này là sự không chắc chắn về giá tăng lên, kết quả của sự trì hoãn bổ sung mà các mempool được mã hóa giới thiệu. Do đó, số lượng giao dịch thất bại do vượt quá ngưỡng trượt giá có khả năng sẽ tăng lên và lãng phí không gian chuỗi.

Tương tự, sự không chắc chắn về giá này cũng có thể dẫn đến các giao dịch MEV đầu cơ cố gắng kiếm lợi từ việc chênh lệch giá trên chuỗi. Quan trọng là, những cơ hội này có thể trở nên phổ biến hơn với các mempool được mã hóa vì sự không chắc chắn gia tăng xung quanh trạng thái hiện tại của các DEX, trong bối cảnh việc thực hiện bị trì hoãn, có khả năng tạo ra các thị trường kém hiệu quả hơn với sự chênh lệch giá giữa các địa điểm. Những loại giao dịch MEV đầu cơ này cũng sẽ lãng phí không gian khối vì chúng thường sẽ bị hủy bỏ nếu không tìm thấy cơ hội nào như vậy.

Mục tiêu của chúng tôi ở đây là phác thảo những thách thức trong mempool được mã hóa, để mọi người có thể tập trung vào việc xây dựng và giải quyết các vấn đề theo những cách khác, chúng có thể vẫn là một phần của giải pháp cho MEV.

Một giải pháp có thể là thiết kế lai, nơi một số giao dịch được sắp xếp mù thông qua một mempool được mã hóa và một số khác được sắp xếp thông qua một giải pháp khác. Đối với một số loại giao dịch — ví dụ, các đơn hàng mua/bán từ các nhà tham gia thị trường lớn có thể cẩn thận mã hóa/lấp đầy chúng và sẵn sàng trả nhiều hơn để tránh MEV — các thiết kế lai có thể là giải pháp đúng đắn. Những thiết kế này cũng có thể hợp lý cho một số giao dịch cực kỳ nhạy cảm, chẳng hạn như sửa lỗi cho một hợp đồng bảo mật có lỗ hổng.

Tuy nhiên, do những hạn chế về công nghệ, cũng như độ phức tạp kỹ thuật đáng kể và chi phí hiệu suất, các mempool được mã hóa khó có thể trở thành giải pháp hoàn hảo cho MEV như đôi khi chúng được cho là vậy. Cộng đồng sẽ cần phải phát triển các giải pháp khác, bao gồm đấu giá MEV, phòng thủ lớp ứng dụng và giảm thiểu thời gian hoàn tất. MEV sẽ là một thách thức trong một thời gian tới, và cần phải điều tra cẩn thận để tìm ra sự cân bằng đúng đắn của các giải pháp nhằm quản lý những bất lợi của nó.

Pranav Garimidi là một Nghiên cứu viên tại a16z Crypto. Anh ấy nghiên cứu về các vấn đề trong thiết kế cơ chế và lý thuyết trò chơi thuật toán liên quan đến các hệ thống blockchain. Anh ấy đặc biệt tập trung vào cách mà các ưu đãi tương tác qua các lớp blockchain. Trước khi gia nhập a16z, Pranav là sinh viên tại Đại học Columbia, nơi anh tốt nghiệp với bằng Cử nhân Khoa học Máy tính.

Joseph Bonneau là một Phó Giáo sư tại Khoa Khoa học Máy tính của Viện Courant, Đại học New York, và là cố vấn kỹ thuật cho a16z crypto. Nghiên cứu của ông tập trung vào mật mã ứng dụng và an ninh blockchain. Ông đã giảng dạy các khóa học về tiền mã hóa tại Đại học Melbourne, NYU, Stanford và Princeton, và nhận bằng Tiến sĩ về khoa học máy tính từ Đại học Cambridge cùng với bằng Cử nhân/Kỹ sư từ Stanford.

Lioba Heimbach là sinh viên tiến sĩ năm thứ tư được hướng dẫn bởi GS. TS. Roger Wattenhofer trong Điện toán phân tán (Disco)nhóm tại ETH Zurich. Nghiên cứu của cô tập trung vào các giao thức blockchain với trọng tâm là tài chính phi tập trung (DeFi). Cụ thể, nó chú trọng vào việc tạo ra một hệ sinh thái blockchain và DeFi có thể tiếp cận, phi tập trung, công bằng và hiệu quả. Cô đã là thực tập sinh nghiên cứu tại a16z crypto trong mùa hè năm 2024.

Các quan điểm được nêu ở đây là của các cá nhân được trích dẫn từ AH Capital Management, L.L.C. (“a16z”) và không phải là quan điểm của a16z hoặc các công ty liên kết của nó. Một số thông tin có trong đây đã được thu thập từ các nguồn bên thứ ba, bao gồm từ các công ty danh mục đầu tư của các quỹ do a16z quản lý. Mặc dù được lấy từ các nguồn được cho là đáng tin cậy, a16z không xác minh độc lập thông tin đó và không đưa ra bất kỳ tuyên bố nào về độ chính xác hiện tại hoặc lâu dài của thông tin hoặc sự phù hợp của nó cho một tình huống nhất định. Ngoài ra, nội dung này có thể bao gồm quảng cáo của bên thứ ba; a16z không xem xét các quảng cáo đó và không ủng hộ bất kỳ nội dung quảng cáo nào có trong đó.

Nội dung này được cung cấp chỉ với mục đích thông tin và không nên được dựa vào như là lời khuyên pháp lý, kinh doanh, đầu tư hoặc thuế. Bạn nên tham khảo ý kiến của các cố vấn riêng của bạn về những vấn đề đó. Các tham chiếu đến bất kỳ chứng khoán hoặc tài sản kỹ thuật số nào chỉ mang tính minh họa và không cấu thành một khuyến nghị đầu tư hoặc đề nghị cung cấp dịch vụ tư vấn đầu tư. Hơn nữa, nội dung này không nhằm vào hoặc không được dự định cho việc sử dụng của bất kỳ nhà đầu tư hoặc nhà đầu tư tiềm năng nào, và không thể được dựa vào trong bất kỳ hoàn cảnh nào khi đưa ra quyết định đầu tư vào bất kỳ quỹ nào được quản lý bởi a16z. (Một đề nghị đầu tư vào một quỹ a16z sẽ chỉ được thực hiện thông qua bản ghi nhớ chào bán riêng, thỏa thuận đăng ký và các tài liệu liên quan khác của bất kỳ quỹ nào như vậy và nên được đọc toàn bộ.) Bất kỳ khoản đầu tư hoặc công ty danh mục nào được đề cập, nhắc đến hoặc mô tả đều không đại diện cho tất cả các khoản đầu tư trong các phương tiện được quản lý bởi a16z, và không có sự đảm bảo nào rằng các khoản đầu tư sẽ có lợi nhuận hoặc rằng các khoản đầu tư khác được thực hiện trong tương lai sẽ có các đặc điểm hoặc kết quả tương tự. Danh sách các khoản đầu tư được thực hiện bởi các quỹ được quản lý bởi Andreessen Horowitz (không bao gồm các khoản đầu tư mà nhà phát hành không cấp phép cho a16z công bố công khai cũng như các khoản đầu tư chưa được công bố vào các tài sản kỹ thuật số giao dịch công khai) có sẵn tại https://a16z.com/investments/.

Nội dung chỉ có giá trị tính đến ngày được chỉ định. Mọi dự đoán, ước tính, dự báo, mục tiêu, triển vọng và/hoặc ý kiến được thể hiện trong tài liệu này có thể thay đổi mà không cần thông báo và có thể khác hoặc trái ngược với ý kiến được thể hiện bởi những người khác. Vui lòng xem https://a16z.com/disclosures cho thông tin quan trọng bổ sung.

Lời từ chối trách nhiệm:

1. Bài viết này được đăng lại từ [a16zcrypto]. Tất cả bản quyền thuộc về tác giả gốc [Pranav GarimidiJoseph Bonneauandy Lioba Heimbach] . Nếu có bất kỳ phản đối nào đối với việc tái bản này, vui lòng liên hệ với Gate Learnđội ngũ, và họ sẽ xử lý nó kịp thời.
2. Tuyên bố miễn trừ trách nhiệm: Các quan điểm và ý kiến được nêu trong bài viết này hoàn toàn là 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 bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi đội ngũ 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 viết đã dịch là bị cấm.