Tiêu đề gốc: Về giới hạn của mempool được mã hóa

Tác giả gốc: Pranav Garimidi, Joseph Bonneau, Lioba Heimbach, a16z

Bản dịch gốc: Saoirse, Foresight News

Trong blockchain, giá trị tối đa có thể kiếm được bằng cách quyết định đóng gói giao dịch nào vào khối, loại trừ giao dịch nào hoặc điều chỉnh thứ tự giao dịch được gọi là "giá trị trích xuất tối đa", hay viết tắt là MEV. MEV phổ biến trong hầu hết các blockchain và là chủ đề được quan tâm và thảo luận rộng rãi trong ngành.

Lưu ý: Bài viết này giả định rằng độc giả đã có hiểu biết cơ bản về MEV. Một số độc giả có thể đọc bài viết khoa học phổ thông về MEV của chúng tôi trước.

Khi quan sát hiện tượng MEV, nhiều nhà nghiên cứu đã đặt ra một câu hỏi rõ ràng: Liệu công nghệ mã hóa có thể giải quyết vấn đề này không? Một giải pháp là sử dụng một nhóm bộ nhớ được mã hóa: người dùng phát sóng các giao dịch được mã hóa, chỉ được giải mã và tiết lộ sau khi chúng được sắp xếp. Điều này đòi hỏi giao thức đồng thuận phải "chọn một cách mù quáng" thứ tự của các giao dịch, điều này dường như ngăn cản việc sử dụng các cơ hội MEV trong giai đoạn sắp xếp.

Nhưng thật không may, các nhóm bộ nhớ được mã hóa không thể cung cấp một giải pháp chung cho vấn đề MEV, cả trong ứng dụng thực tế lẫn lý thuyết. Bài viết này sẽ giải thích những khó khăn và khám phá hướng thiết kế khả thi của các nhóm bộ nhớ được mã hóa.

Cách thức hoạt động của các nhóm bộ nhớ được mã hóa

Đã có nhiều đề xuất cho các nhóm bộ nhớ được mã hóa, nhưng khuôn khổ chung của nó như sau:

1. Người dùng phát sóng các giao dịch được mã hóa.

2. Các giao dịch được mã hóa được gửi lên chuỗi (trong một số đề xuất, các giao dịch trước tiên phải trải qua quá trình xáo trộn ngẫu nhiên có thể xác minh).

3. Khi khối chứa các giao dịch này cuối cùng được xác nhận, các giao dịch sẽ được giải mã.

4. Cuối cùng, các giao dịch này được thực thi.

Cần lưu ý rằng có một vấn đề chính ở bước 3 (giải mã giao dịch): Ai chịu trách nhiệm giải mã? Điều gì sẽ xảy ra nếu giải mã không thành công? Một ý tưởng đơn giản là để người dùng tự giải mã các giao dịch của họ (trong trường hợp này, không cần mã hóa chúng, chỉ cần ẩn cam kết). Nhưng cách tiếp cận này có một lỗ hổng: kẻ tấn công có thể triển khai MEV suy đoán.

Trong MEV đầu cơ, kẻ tấn công đoán rằng một giao dịch được mã hóa cụ thể chứa cơ hội MEV, sau đó mã hóa giao dịch của chính chúng và cố gắng chèn nó vào một vị trí thuận lợi (ví dụ: trước hoặc sau giao dịch mục tiêu). Nếu các giao dịch theo đúng thứ tự dự kiến, kẻ tấn công sẽ giải mã và trích xuất MEV thông qua giao dịch của chúng; nếu không, chúng sẽ từ chối giải mã và giao dịch của chúng sẽ không được đưa vào blockchain cuối cùng.

Có thể áp dụng hình phạt đối với những người dùng không giải mã được, nhưng cơ chế này cực kỳ khó thực hiện. Lý do là hình phạt phải giống nhau đối với tất cả các giao dịch được mã hóa (xét cho cùng, các giao dịch không thể được phân biệt sau khi mã hóa) và hình phạt phải đủ nghiêm khắc để hạn chế MEV đầu cơ ngay cả đối với các mục tiêu có giá trị cao. Điều này sẽ dẫn đến việc một lượng lớn tiền bị khóa và những khoản tiền này phải được giữ ẩn danh (để tránh tiết lộ mối liên hệ giữa giao dịch và người dùng). Thậm chí còn khó khăn hơn, nếu người dùng thực sự không thể giải mã bình thường do lỗ hổng chương trình hoặc lỗi mạng, họ cũng sẽ bị thiệt hại.

Do đó, hầu hết các lược đồ đều khuyến nghị rằng khi mã hóa giao dịch, cần đảm bảo rằng chúng có thể được giải mã tại một thời điểm nào đó trong tương lai, ngay cả khi người dùng khởi tạo ngoại tuyến hoặc từ chối hợp tác. Điều này có thể đạt được theo một số cách:

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

Chia sẻ bí mật và mã hóa ngưỡng:Trong sơ đồ này, người dùng mã hóa giao dịch thành một khóa do một ủy ban cụ thể (thường là một tập hợp con các trình xác thực) nắm giữ chung. Việc giải mã yêu cầu một điều kiện ngưỡng nhất định (ví dụ: hai phần ba số thành viên ủy ban đồng ý).

Khi sử dụng giải mã ngưỡng, bên mang tin cậy sẽ chuyển từ phần cứng sang ủy ban. Những người ủng hộ tin rằng vì hầu hết các giao thức đều giả định rằng các trình xác thực có đặc điểm "đa số trung thực" trong cơ chế đồng thuận, chúng ta cũng có thể đưa ra giả định tương tự rằng hầu hết các trình xác thực sẽ vẫn trung thực và sẽ không giải mã giao dịch trước.

Tuy nhiên, cần lưu ý một điểm khác biệt quan trọng ở đây: hai giả định về độ tin cậy này không phải là cùng một khái niệm. Các lỗi đồng thuận như phân nhánh blockchain có thể được nhìn thấy công khai (một "giả định độ tin cậy yếu"), trong khi các ủy ban độc hại sẽ giải mã giao dịch trước một cách riêng tư mà không để lại bất kỳ bằng chứng công khai nào. Cuộc tấn công này không thể bị phát hiện hoặc trừng phạt (một "giả định tin cậy mạnh"). Do đó, mặc dù bề ngoài, cơ chế đồng thuận và giả định bảo mật của ủy ban mã hóa có vẻ nhất quán, nhưng trong thực tế hoạt động, độ tin cậy của giả định "ủy ban sẽ không thông đồng" lại thấp hơn nhiều.

Mã hóa khóa thời gian và mã hóa trễ: Một giải pháp thay thế cho mã hóa ngưỡng, mã hóa trễ hoạt động bằng cách mã hóa các giao dịch thành một khóa công khai có khóa riêng tương ứng được ẩn trong một câu đố khóa thời gian. Câu đố khóa thời gian là một câu đố mật mã bao hàm một bí mật không thể bị tiết lộ cho đến khi một khoảng thời gian được đặt trước trôi qua, cụ thể hơn, bằng cách thực hiện lặp đi lặp lại một loạt các phép tính không thể song song hóa. Trong cơ chế này, bất kỳ ai cũng có thể giải câu đố để lấy khóa và giải mã giao dịch, nhưng chỉ sau khi hoàn thành một phép tính chậm (về cơ bản là tuần tự) được thiết kế để mất đủ thời gian để đảm bảo rằng giao dịch không thể được giải mã trước khi xác nhận cuối cùng. Dạng mạnh nhất của nguyên thủy mật mã này là tạo công khai một câu đố như vậy thông qua mã hóa trễ; quá trình này cũng có thể được các ủy ban đáng tin cậy xấp xỉ bằng cách sử dụng mã hóa khóa thời gian, nhưng lợi thế của nó so với mã hóa ngưỡng vẫn còn đang nghi vấn tại thời điểm này.

Cho dù sử dụng mã hóa trễ hay để một ủy ban đáng tin cậy thực hiện tính toán, các lược đồ như vậy đều phải đối mặt với nhiều thách thức thực tế: thứ nhất, vì độ trễ về cơ bản phụ thuộc vào quá trình tính toán, nên khó đảm bảo độ chính xác của thời gian giải mã; thứ hai, các lược đồ này dựa vào một thực thể cụ thể chạy phần cứng hiệu suất cao để giải quyết bài toán một cách hiệu quả. Mặc dù bất kỳ ai cũng có thể đảm nhận vai trò này, nhưng vẫn chưa rõ làm thế nào để khuyến khích chủ thể tham gia; cuối cùng, trong các thiết kế như vậ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 ghi cuối cùng vào khối. Các lược đồ dựa trên ngưỡng (hoặc mã hóa chứng kiến) có khả năng giải mã chỉ những giao dịch đã được đưa vào thành công.

Mã hóa chứng kiến:Lược đồ mật mã tiên tiến cuối cùng sử dụng công nghệ "mã hóa chứng kiến". Về lý thuyết, cơ chế của mã hóa chứng kiến là sau khi thông tin được mã hóa, chỉ những người biết "thông tin chứng kiến" tương ứng với một mối quan hệ NP cụ thể mới có thể giải mã nó. Ví dụ, thông tin có thể được mã hóa để chỉ những người giải được câu đố Sudoku hoặc cung cấp một ảnh băm số tiền tố mới có thể hoàn tất việc giải mã.

(Lưu ý: Quan hệ NP là sự tương ứng giữa "câu hỏi" và "câu trả lời có thể được xác minh nhanh chóng")

Đối với bất kỳ quan hệ NP nào, logic tương tự cũng có thể được triển khai thông qua SNARK. Có thể nói rằng mã hóa chứng cứ về cơ bản là mã hóa dữ liệu ở dạng mà chỉ những chủ thể có thể chứng minh rằng các điều kiện nhất định được đáp ứng thông qua SNARK mới có thể giải mã được. Trong trường hợp nhóm bộ nhớ được mã hóa, một ví dụ điển hình của điều kiện như vậy là các giao dịch chỉ có thể được giải mã sau khi khối cuối cùng được xác nhận.

Đây là một nguyên thủy lý thuyết có tiềm năng lớn. Trên thực tế, đây là một lược đồ chung, và phương pháp dựa trên ủy ban và phương pháp dựa trên độ trễ chỉ là các hình thức ứng dụng cụ thể của nó. Đáng tiếc là hiện tại chúng ta chưa có bất kỳ lược đồ mã hóa dựa trên chứng cứ thực tế nào. Hơn nữa, ngay cả khi có một sơ đồ như vậy, cũng khó có thể nói rằng nó có nhiều ưu điểm hơn phương pháp dựa trên ủy ban trong chuỗi bằng chứng cổ phần. Ngay cả khi mã hóa chứng kiến được thiết lập thành "chỉ giải mã sau khi giao dịch được sắp xếp trong khối đã hoàn tất", ủy ban độc hại vẫn có thể mô phỏng giao thức đồng thuận một cách riêng tư để giả mạo trạng thái xác nhận cuối cùng của giao dịch, sau đó sử dụng chuỗi riêng này làm "chứng kiến" để giải mã giao dịch. Trong trường hợp này, việc giải mã ngưỡng bởi cùng một ủy ban có thể đạt được mức độ bảo mật tương tự và đơn giản hơn nhiều.

Tuy nhiên, trong giao thức đồng thuận bằng chứng công việc, lợi thế của mã hóa chứng kiến lại đáng kể hơn. Bởi vì ngay cả khi ủy ban hoàn toàn độc hại, họ cũng không thể khai thác riêng nhiều khối mới ở đầu chuỗi khối hiện tại để giả mạo trạng thái xác nhận cuối cùng.

Những thách thức kỹ thuật mà các nhóm bộ nhớ được mã hóa phải đối mặt

Một số thách thức thực tế hạn chế khả năng ngăn chặn MEV của các nhóm bộ nhớ được mã hóa. Nhìn chung, tính bảo mật thông tin tự nó đã là một vấn đề khó khăn. Cần lưu ý rằng công nghệ mã hóa không được sử dụng rộng rãi trong lĩnh vực Web3, nhưng hàng thập kỷ thực hành của chúng tôi trong việc triển khai công nghệ mã hóa trong các mạng (như TLS/HTTPS) và truyền thông riêng tư (từ PGP đến các nền tảng nhắn tin được mã hóa hiện đại như Signal và WhatsApp) đã phơi bày hoàn toàn những khó khăn: mặc dù mã hóa là một công cụ để bảo vệ tính bảo mật, nhưng nó không thể được đảm bảo tuyệt đối.

Đầu tiên, một số thực thể có thể trực tiếp lấy được thông tin văn bản thuần túy của các giao dịch của người dùng. Trong một kịch bản điển hình, người dùng thường không tự mã hóa giao dịch mà giao phó công việc này cho các nhà cung cấp dịch vụ ví. Điều này sẽ cho phép các nhà cung cấp ví truy cập vào văn bản thuần túy của giao dịch và có khả năng sử dụng hoặc bán thông tin này để trích xuất MEV. Mã hóa chỉ an toàn khi các thực thể có quyền truy cập vào khóa. Phạm vi kiểm soát đối với khóa là ranh giới của bảo mật.

Ngoài ra, vấn đề lớn nhất là siêu dữ liệu, tức là dữ liệu chưa được mã hóa xung quanh tải trọng được mã hóa (giao dịch). Người tìm kiếm có thể sử dụng siêu dữ liệu này để suy ra ý định của giao dịch và thực hiện MEV đầu cơ. Điều quan trọng là phải hiểu rằng người tìm kiếm không cần phải hiểu đầy đủ nội dung giao dịch, cũng không phải đoán đúng mọi lúc. Ví dụ: miễn là họ có thể xác định với xác suất hợp lý rằng một giao dịch là lệnh mua từ một sàn giao dịch phi tập trung (DEX) cụ thể, thì điều đó là đủ để phát động một cuộc tấn công.

Chúng ta có thể chia siêu dữ liệu thành một số loại: một là vấn đề kinh điển vốn có trong mật mã học, và loại còn lại là vấn đề chỉ có ở nhóm bộ nhớ được mã hóa.

· Kích thước giao dịch: Bản thân mật mã học không thể ẩn kích thước của văn bản thuần túy (cần lưu ý rằng định nghĩa chính thức về bảo mật ngữ nghĩa loại trừ rõ ràng việc ẩn kích thước văn bản thuần túy). Đây là một vectơ tấn công phổ biến trong truyền thông được mã hóa. Một ví dụ điển hình là ngay cả sau khi mã hóa, kẻ nghe lén vẫn có thể xác định nội dung đang phát trên Netflix theo thời gian thực bằng kích thước của mỗi gói dữ liệu trong luồng video. Trong nhóm bộ nhớ được mã hóa, một số loại giao dịch nhất định có thể có kích thước duy nhất, do đó làm rò rỉ thông tin.

· Thời gian phát sóng: Mã hóa cũng không thể ẩn thông tin thời gian (đây là một vectơ tấn công kinh điển khác). Trong các kịch bản Web3, một số người gửi (chẳng hạn như các kịch bản bán tháo có cấu trúc) có thể khởi tạo các giao dịch theo các khoảng thời gian cố định. Thời gian giao dịch cũng có thể được liên kết với các 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 sự kiện tin tức. Một cách kín đáo hơn để sử dụng thông tin thời gian là chênh lệch giá giữa các sàn giao dịch tập trung (CEX) và các sàn giao dịch phi tập trung (DEX): bộ sắp xếp có thể tận dụng thông tin giá CEX mới nhất bằng cách chèn các giao dịch được tạo ra càng muộn càng tốt; đồng thời, bộ sắp xếp có thể loại trừ tất cả các giao dịch khác được phát sóng sau một thời điểm nhất định (ngay cả khi đã được mã hóa) để đảm bảo rằng các giao dịch của họ có quyền truy cập độc quyền vào các lợi thế giá mới nhất.

· Địa chỉ IP nguồn: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à theo dõi địa chỉ IP nguồn. Vấn đề này đã được biết đến từ những ngày đầu của Bitcoin (hơn một thập kỷ trước). Điều này có thể có giá trị đối với người tìm kiếm nếu một người gửi cụ thể có mô hình hành vi nhất quán. Ví dụ: việc biết danh tính của người gửi có thể liên kết các giao dịch được mã hóa với các giao dịch lịch sử đã giải mã.

· Thông tin về người gửi giao dịch và phí/gas:Phí giao dịch là một loại siêu dữ liệu duy nhất đối với mempool tiền điện tử. Trong Ethereum, một giao dịch truyền 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í), ngân sách gas tối đa và phí gas đơn vị mà người gửi sẵn sàng trả. Tương tự như địa chỉ mạng nguồn, địa chỉ người gửi có thể được sử dụng để liên kết nhiều giao dịch với các thực thể trong thế giới thực; ngân sách gas có thể gợi ý về mục đích của giao dịch. 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 cố định có thể xác định được.

Một người tìm kiếm tinh vi có thể kết hợp nhiều loại siêu dữ liệu này để dự đoán nội dung của một giao dịch.

Về lý thuyết, tất cả thông tin này có thể được ẩn, nhưng phải trả giá bằng hiệu suất và độ phức tạp. Ví dụ, việc đệm các giao dịch theo độ dài chuẩn có thể ẩn kích thước, nhưng điều này sẽ lãng phí băng thông và không gian trên chuỗi; thêm độ trễ trước khi gửi có thể ẩn thời gian, nhưng nó làm tăng độ trễ; gửi giao dịch qua mạng ẩn danh như Tor có thể ẩn địa chỉ IP, nhưng điều này mang lại những thách thức mới.

Siêu dữ liệu khó ẩn nhất là thông tin phí giao dịch. Mã hóa dữ liệu phí sẽ gây ra một loạt vấn đề cho những người xây dựng khối: Đầu tiên, có vấn đề về thư rác. Nếu dữ liệu phí giao dịch được mã hóa, bất kỳ ai cũng có thể phát các giao dịch được mã hóa không đúng định dạng. Mặc dù các giao dịch này sẽ được sắp xếp, nhưng chúng không thể trả phí. Sau khi giải mã, chúng không thể được thực hiện nhưng không ai có thể chịu trách nhiệm. Vấn đề này có thể được giải quyết bằng SNARK, tức là chứng minh rằng định dạng giao dịch là chính xác và đủ tiền, nhưng nó sẽ làm tăng đáng kể chi phí chung.

Thứ hai là hiệu quả của việc xây dựng khối và đấu giá phí. Người xây dựng dựa vào thông tin phí để tạo ra các khối tối đa hóa lợi nhuận và xác định giá thị trường hiện tại của các tài nguyên trên chuỗi. Mã hóa dữ liệu phí sẽ làm gián đoạn quá trình này. Một giải pháp là đặt một mức phí cố định cho mỗi khối, nhưng điều này không hiệu quả về mặt kinh tế và cũng có thể tạo ra một thị trường thứ cấp cho việc đóng gói giao dịch, đi ngược lại mục đích thiết kế ban đầu của nhóm bộ nhớ được mã hóa. Một giải pháp khác là tiến hành đấu giá phí thông qua tính toán đa bên an toàn hoặc phần cứng đáng tin cậy, nhưng cả hai phương pháp đều cực kỳ tốn kém.

Cuối cùng, một nhóm bộ nhớ được mã hóa an toàn sẽ làm tăng chi phí chung của hệ thống theo nhiều cách: mã hóa sẽ làm tăng độ trễ của chuỗi, độ phức tạp về tính toán và mức tiêu thụ băng thông; không rõ cách kết hợp với các mục tiêu quan trọng trong tương lai như phân mảnh hoặc thực thi song song; nó cũng có thể đưa ra những điểm lỗi mới cho tính sống động (chẳng hạn như ủy ban giải mã và bộ giải hàm trễ trong sơ đồ ngưỡng); đồng thời, độ phức tạp của thiết kế và triển khai sẽ tăng lên đáng kể.

Nhiều vấn đề với mempool tiền điện tử tương tự như những thách thức mà các blockchain được thiết kế để đảm bảo quyền riêng tư giao dịch (như Zcash và Monero) phải đối mặt. Nếu có một hàm ý tích cực, thì đó là việc giải quyết tất cả những thách thức mà mật mã có thể giảm bớt trong MEV cũng sẽ mở đường cho quyền riêng tư giao dịch.

Những Thách Thức Kinh Tế Đối Mặt Với Mempool Tiền Điện Tử

Cuối cùng, mempool tiền điện tử phải đối mặt với những thách thức kinh tế. Không giống như những thách thức kỹ thuật, có thể được giảm bớt dần dần với khoản đầu tư kỹ thuật đầy đủ, những thách thức kinh tế này là những hạn chế cơ bản và cực kỳ khó giải quyết.

Vấn đề cốt lõi của MEV bắt nguồn từ sự bất đối xứng thông tin giữa người tạo giao dịch (người dùng) và người khai thác cơ hội MEV (người tìm kiếm và người xây dựng khối). Người dùng thường không rõ ràng về lượng giá trị có thể trích xuất được chứa trong các giao dịch của họ, vì vậy ngay cả khi có một mempool tiền điện tử hoàn hảo, họ vẫn có thể bị dụ tiết lộ khóa giải mã để đổi lấy phần thưởng thấp hơn giá trị MEV thực tế. Hiện tượng này có thể được gọi là "giải mã được khuyến khích".

Kịch bản này không khó hình dung, bởi vì các cơ chế tương tự như MEV Share đã tồn tại trong thực tế. MEV Share là một cơ chế đấu giá luồng lệnh cho phép người dùng gửi thông tin giao dịch một cách có chọn lọc đến một nhóm, và những người tìm kiếm sẽ cạnh tranh để giành được quyền sử dụng cơ hội MEV của giao dịch. Sau khi người chiến thắng trích xuất MEV, một phần tiền thu được (tức là số tiền đặt giá hoặc một tỷ lệ phần trăm nhất định) sẽ được trả lại cho người dùng.

Mô hình này có thể được điều chỉnh trực tiếp cho nhóm bộ nhớ được mã hóa: người dùng cần tiết lộ khóa giải mã (hoặc một phần thông tin) để tham gia. Tuy nhiên, hầu hết người dùng không biết về chi phí cơ hội khi tham gia vào các cơ chế như vậy. Họ chỉ nhìn thấy lợi ích trước mắt và sẵn sàng tiết lộ thông tin. Có những trường hợp tương tự trong tài chính truyền thống: ví dụ, nền tảng giao dịch không hoa hồng Robinhood, với mô hình lợi nhuận là bán luồng lệnh của người dùng cho bên thứ ba thông qua "luồng lệnh thanh toán".

Một kịch bản khả thi khác là các nhà xây dựng lớn buộc người dùng tiết lộ nội dung giao dịch (hoặc thông tin liên quan) với 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 không gian Web3, nhưng nếu các trình xác thực hoặc nhà xây dựng lớn phải tuân theo các ràng buộc pháp lý (chẳng hạn như các quy định của OFAC) để thực thi danh sách đánh giá, họ có thể từ chối xử lý bất kỳ giao dịch được mã hóa nào. Về mặt kỹ thuật, người dùng có thể chứng minh rằng các giao dịch được mã hóa của họ đáp ứng các yêu cầu đánh giá thông qua bằng chứng không kiến thức, nhưng điều này sẽ làm tăng thêm chi phí và độ phức tạp. Ngay cả khi blockchain có khả năng chống kiểm duyệt cao (đảm bảo bao gồm các giao dịch được mã hóa), các nhà xây dựng vẫn có thể ưu tiên các giao dịch văn bản thuần túy đã biết ở đầu khối và các giao dịch được mã hóa ở cuối khối. Do đó, các giao dịch cần đảm bảo ưu tiên thực hiện cuối cùng có thể bị buộc phải tiết lộ nội dung của chúng cho các nhà xây dựng.

Những Thách Thức Khác Về Hiệu Quả

Mempool tiền điện tử làm tăng chi phí vận hành cho hệ thống theo một số cách rõ ràng. Các giao dịch cần được người dùng mã hóa và hệ thống cần giải mã chúng theo một cách nào đó, điều này làm tăng chi phí tính toán và cũng có thể làm tăng quy mô giao dịch. Như đã đề cập trước đó, việc xử lý siêu dữ liệu càng làm trầm trọng thêm những chi phí vận hành này. Tuy nhiên, cũng có những chi phí về hiệu quả không dễ nhận thấy. Trong tài chính, thị trường được coi là hiệu quả khi giá cả phản ánh tất cả thông tin có sẵn, và độ trễ cùng với sự bất đối xứng thông tin dẫn đến tình trạng thiếu hiệu quả của thị trường. Đây chính xác là những gì mempool tiền điện tử mang lại.

Một hậu quả trực tiếp của những tình trạng thiếu hiệu quả này là sự gia tăng bất ổn về giá, một sản phẩm trực tiếp của độ trễ bổ sung do mempool tiền điện tử gây ra. Kết quả là, có thể có nhiều giao dịch thất bại hơn do vượt quá giới hạn trượt giá, gây lãng phí không gian trên chuỗi.

Tương tự, sự bất ổn về giá này cũng có thể dẫn đến giao dịch MEV đầu cơ, nhằm mục đích kiếm lời từ chênh lệch giá trên chuỗi. Cần lưu ý rằng các nhóm bộ nhớ tiền điện tử có thể khiến những cơ hội như vậy trở nên phổ biến hơn: tình trạng hiện tại của các sàn giao dịch phi tập trung (DEX) còn mơ hồ do sự chậm trễ trong thực hiện, điều này có thể dẫn đến thị trường kém hiệu quả hơn và chênh lệch giá giữa các nền tảng giao dịch khác nhau. Các giao dịch MEV đầu cơ như vậy cũng gây lãng phí không gian khối vì chúng có xu hướng chấm dứt thực hiện khi không tìm thấy cơ hội chênh lệch giá nào.

Tóm tắt

Mục đích ban đầu của bài viết này là giải quyết những thách thức mà các nhóm bộ nhớ tiền điện tử phải đối mặt để mọi người có thể tập trung vào nghiên cứu và phát triển các giải pháp khác, nhưng các nhóm bộ nhớ tiền điện tử vẫn có thể trở thành một phần của giải pháp quản trị MEV.

Một ý tưởng khả thi là thiết kế lai: một số giao dịch được "sắp xếp mù" thông qua nhóm bộ nhớ mã hóa, trong khi một số khác sử dụng các phương thức sắp xếp khác. Đối với một số loại giao dịch nhất định (chẳng hạn như lệnh mua và bán từ những người tham gia thị trường lớn, những người có khả năng mã hóa hoặc thực hiện giao dịch một cách cẩn thận và sẵn sàng trả chi phí cao hơn để tránh MEV), thiết kế lai có thể là một lựa chọn phù hợp. Thiết kế này cũng có ý nghĩa thực tế đối với các giao dịch có độ nhạy cảm cao (chẳng hạn như giao dịch sửa chữa cho các hợp đồng bảo mật có lỗ hổng).

Tuy nhiên, do những hạn chế về kỹ thuật, độ phức tạp kỹ thuật cao và chi phí hiệu năng, nhóm bộ nhớ được mã hóa khó có thể trở thành "giải pháp MEV phổ quát" như mọi người mong đợi. Cộng đồng cần phát triển các giải pháp khác, bao gồm đấu giá MEV, cơ chế phòng thủ ở tầng ứng dụng và rút ngắn thời gian xác nhận cuối cùng. MEV sẽ tiếp tục là một thách thức trong thời gian tới, và cần có nghiên cứu chuyên sâu để tìm ra sự cân bằng giữa các giải pháp khác nhau nhằm giải quyết tác động tiêu cực của nó.

Liên kết gốc

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia