Sắp xếp theo một kế hoạch cụ thể có thể giải quyết tất cả vấn đề được không?

robot
Đang tạo bản tóm tắt

Tác giả: Pavel Paramonov Nguồn: X, @paramonoww Dịch: Shàn ōu bā, Kim cương tài chính

Nhiều người cho rằng "ASS là tất cả những gì bạn cần", coi nó là một giải pháp hoàn chỉnh, gần như không cần cải tiến. Tuy nhiên, ASS không thể giải quyết tất cả vấn đề và cũng tồn tại một số giả định về sự tin cậy.

1. Ứng dụng không gian tự biên dạng là một phần của những người xây dựng Khối

Khi một giao dịch bundle được đưa vào Khối, dApp có quyền trích xuất giá trị tối đa của riêng mình từ MEV, từ các thành viên khác trong Chuỗi cung ứng MEV như người đề xuất, người tìm kiếm và người xây dựng. Tuy nhiên, khái niệm này không hoàn hảo (không có gì hoàn hảo trong thế giới mã hóa) và có thể có một số giả định về sự tin cậy.

4y2I6dyw50Wob26kVMuyRqYGKio4tyZfa4Avqm5J.png

2. Trò chơi dung hòa

Thách thức mà dApp tự giải mã đối mặt là: càng cao giá trị bị ràng buộc, yêu cầu chứa trong Khối càng lớn. Nếu các giao dịch MEV bị bỏ qua trong Khối, chúng có thể trở nên hoàn toàn không sinh lợi, không chỉ gây tổn thương cho các giao dịch khác không thể tạo ra MEV mà còn gây tổn thương cho người dùng.

Đây là một tình huống suy nghĩ thú vị:

  • dApp có khả năng bắt giữ toàn bộ MEV được tạo ra bởi nó
  • Tuy nếu không chỉ mất cơ hội MEV mà còn có thể mất đi người dùng mang lại giá trị cho nền tảng (ví dụ như AMM không ngừng thất bại, ai còn sử dụng nữa), thì việc làm như vậy sẽ không có ý nghĩa.

Điều thú vị là người đề xuất cũng cần phải có lợi nhuận, điều này tạo ra một tình huống thua lỗ kép:

  • Ứng dụng phi tập trung tự chuỗi mất MEV do việc ràng buộc không được bao gồm trongKhối
  • Người đề xuất mất MEV vì không thể giải nén và sắp xếp lại các gói nguyên tử (mặc dù họ có thể chọn giao dịch khác)

3. ASS dApp không nên gây hại cho người dùng thông thường và Nhà cung cấp thanh khoản (LPs) bằng cách rút trích MEV

Như mọi người đều biết, hầu hết MEV được tạo ra và rút ra thông qua lưu lượng độc hại. Các LPs đã mất phần lớn thu nhập từ lưu lượng không thông tin do MEV. Thu hút Thanh khoản đến nền tảng là một trong những điều khó nhất trong lĩnh vực mã hóa, và AMM nên theo dõi phân phối công bằng của MEV cho LPs, điều này có thể giúp giảm Tổn thất vô thường.

Trong thực tế hiện tại, quản lý vị thế LP một cách chủ động (thậm chí là nhiều vị thế LP) có thể được coi là một công việc toàn thời gian. Nếu là một cuộc tấn công bánh mì ba lớp, giá trị sẽ được trả lại cho người giao dịch; nếu là Kinh doanh chênh lệch giá giữa sàn giao dịch tập trung và DEX, giá trị sẽ được trả lại cho LPs. Vậy, vấn đề là họ nên nhận được bao nhiêu phần thưởng, và dApp nên giữ lại bao nhiêu giá trị?

4. Nếu kích thước của bundle xung đột với kích thước Khối của chuỗi gốc thì làm sao?

Rõ ràng, không phải tất cả các dApp đều tự tuần tự hóa (ít nhất là trong tương lai gần). Kích thước (hoặc lô giao dịch) của Khối là hữu hạn; nếu không có giới hạn, không có Khối chuỗi hoặc "Khối chuỗi". Giả sử một Khối có thể chứa tối đa 100 giao dịch, có thể xảy ra những trường hợp sau:

  • dApp đã gửi một gói gồm 100 giao dịch, lấp đầy toàn bộ Khối. Đối với các “thành viên” khác trong Chuỗi cung ứng MEV, việc bao gồm nó, đề xuất Khối và thực hiện nó có khả năng sinh lời bao nhiêu?
  • Ứng dụng phân tán (dApp) đã gửi một gói chứa 99 giao dịch và còn 1 vị trí trống. Người đề xuất có đủ động lực để bao gồm gói này không? (Trừ khi họ thực hiện một số hợp tác, chẳng hạn như xác nhận trước)
  • Hai ứng dụng phi tập trung (dApp) đã gửi các gói giao dịch buộc ghép. Gói buộc đầu tiên chứa 60 giao dịch, gói thứ hai chứa 50 giao dịch. Rõ ràng, chỉ có thể chứa một gói buộc.

uQkGOPSiFFvNWFGafshKpV5TrjxUm8OLMcv3B7jp.png

Điểm quan trọng là, MEV được tạo ra từ gói đầu tiên nhiều hơn gói thứ hai, nhưng từ một góc độ khác, việc kết hợp gói thứ hai có lợi hơn vì 50 giao dịch của các dApp không tự tuần tự khác khi được kết hợp với gói đó có thể tạo ra nhiều giá trị hơn cho Khối.

Vậy ai nên được bao gồm? Ai trong Khối là lợi nhuận nhất, không chỉ là gói gọn bên trong?

Một giải pháp có thể thực hiện được là FCFS (đến trước được phục vụ trước), nhưng nó không thể đảm bảo tính chính xác vì Trễ vẫn còn tồn tại.

Làm thế nào để đảm bảo tuần tự hóa có lợi cho mọi người, chứ không chỉ có lợi cho một bên và lấy đi giá trị của các bên khác (LPs, người dùng)?

Một giải pháp tiềm năng là đặt các quy tắc tuần tự hóa cụ thể, chỉ khi tuân theo các quy tắc này mới có quyền sắp xếp các gói hàng. Điều này rất quan trọng vì tuần tự hóa không đúng có thể dẫn đến lỗ hổng bảo mật.

Đối với các cặp giao dịch AMM, việc sử dụng các quy tắc có thể xác minh tham lam sẽ ngăn các giao dịch bị chèn ép trong một nhóm AMM cụ thể. Tuy nhiên, hầu hết các giao dịch DEX là giao dịch đa hoán đổi, vì vậy các phương tiện khác là cần thiết để cung cấp đảm bảo điện trở MEV.

Vẫn ở giai đoạn sớm!

Hiện tại có nhiều cách để tự trình bày, tôi được truyền cảm hứng từ phương pháp của @SorellaLabs trong chủ đề này. Chúng tôi vẫn đang ở giai đoạn sớm của việc triển khai tự trình bày (hoặc ASS như @ballsyalchemist gọi). Có sự cân nhắc khác nhau trong cơ sở hạ tầng.

73jFauRk5Nd5bDHdIIAbZFzziozxmWNLxzim84DR.png

ASS 的目标是让 dApp 负责其tuần tự hóa,而不关心执行(由链处理)。虽然在 L1 上的 ASS 相对清晰,但在 L2 上更具吸引力,因为只需处理一个tuần tự hóa器,并且 L2 可以通过实施本地tuần tự hóa规则带来更多内容。

tăng lên空间巨大z!(Khối空间除外)

Xem bản gốc
  • Phần thưởng
  • 2
  • Chia sẻ
Bình luận
Không có bình luận