Giới thiệu FairFlow: TimeBoost với hình thức đấu giá kiểu Hà Lan

Về tác giả
Tác giả, Ko Sunghun , là sinh viên đại học tại KAIST và là thực tập sinh nghiên cứu tại Radius. Tác giả xin cảm ơn Tariz , AJ Park và Chanyang Ju từ Radius vì phản hồi và những bình luận hữu ích của họ.

Tóm lại

• Chúng tôi đã xem xét các chính sách giải trình tự hiện có được L2 sử dụng và giải thích cách những người chơi ngoài giao thức gần đây đã áp dụng các chiến lược mới để gian lận chính sách.
• Chúng tôi đề xuất FairFlow, phiên bản tinh chỉnh của TimeBoost, như một giải pháp thay thế có thể ngăn chặn các hoạt động như vậy và cuối cùng cho phép L2 thu được nhiều doanh thu hơn.

Đây là phiên bản đăng chéo của một bài đăng trên blog .

Giới thiệu

Mạng lớp 2 (L2) cung cấp phí giao dịch thấp và thời gian thực hiện nhanh hơn, đóng vai trò quan trọng trong việc duy trì hệ sinh thái Ethereum như một đơn vị dẫn đầu trong ngành công nghiệp blockchain. Sự tăng trưởng kinh tế của L2 không chỉ thúc đẩy việc áp dụng mạng Ethereum mà còn thu hút nhiều người dùng hơn nữa. Tuy nhiên, hiện tại, không có nguồn doanh thu rõ ràng nào ở cấp độ giao thức cho các L2 mới ra mắt ngoài thu nhập từ phí giao dịch. Vì phí thấp là yếu tố chính trong việc áp dụng chúng, nên L2 không thể chỉ tăng chi phí để đạt được lợi nhuận. Do đó, việc nắm bắt Giá trị khai thác được của thợ đào (MEV) mà không ảnh hưởng đến trải nghiệm của người dùng, chẳng hạn như thông qua việc nắm bắt doanh thu tồn đọng, đã trở thành một thách thức đáng kể. Nhiều chiến lược sắp xếp khác nhau đã được đề xuất và triển khai, nhưng các báo cáo gần đây chỉ ra rằng một số loại cơ hội nhất định có thể bị khai thác, cho phép một số người chơi trò gian lận hệ thống và nắm bắt một phần đáng kể MEV mà không chia sẻ. Trong bài đăng này, chúng tôi sẽ xem xét kỹ lưỡng những hiện tượng này và các nỗ lực trước đây và đề xuất một chính sách sắp xếp thay thế được thiết kế để giảm thiểu các chiến thuật như vậy và nội bộ hóa nhiều doanh thu hơn, cuối cùng thúc đẩy sự tăng trưởng kinh tế của L2.

Chính sách sắp xếp hiện tại

Đấu giá khối

Đấu giá khối là phương pháp được sử dụng trên Ethereum L1. Nó dựa trên thực tế là không có quy tắc trong giao thức để sắp xếp các giao dịch và bất kỳ giao dịch hợp lệ nào cũng có thể được đưa vào một khối. Các chuyên gia bên ngoài cạnh tranh để giành quyền xây dựng toàn bộ khối và người chiến thắng sẽ được trao toàn quyền kiểm soát việc xây dựng khối.

Thứ tự ưu tiên

Trong Priority Ordering , các giao dịch hợp lệ được sắp xếp theo thứ tự giảm dần dựa trên priorityFeePerGas . Cách tiếp cận đơn giản này hoạt động tốt trong hầu hết các trường hợp và là thiết lập mặc định của chuỗi OP Stack. Theo thứ tự ưu tiên, những người chơi tìm kiếm lợi nhuận (người tìm kiếm) sẵn sàng trả phí cao hơn để đảm bảo vị trí ở đầu khối. Ngược lại, những người dùng thông thường, những người ít nhạy cảm hơn với lệnh giao dịch và thời gian chờ, vẫn có thể bao gồm các giao dịch của họ ngay cả với mức phí thấp hơn.

FCFS

First-Come, First-Served (FCFS) xử lý các giao dịch theo thứ tự thời gian mà chúng được nhận. Mặc dù cách tiếp cận này có vẻ trực quan và công bằng (và được người dùng thường xuyên ưa chuộng), nhưng nó lại có những nhược điểm đáng kể. Sự cạnh tranh gay gắt giữa những người tìm kiếm dẫn đến việc spam mạng, gây lãng phí không gian khối. Hơn nữa, những nỗ lực của những người tìm kiếm để có độ trễ thấp hơn được đầu tư vào cơ sở hạ tầng ngoài giao thức (ví dụ: đồng định vị) và giao thức không kiếm được gì từ nó.

Tăng tốc thời gian

Được đề xuất vào năm 2023, TimeBoost được xây dựng trên FCFS nhưng bổ sung tùy chọn tăng thời gian gửi giao dịch dựa trên giá thầu đính kèm. Cơ chế này khuyến khích những người tham gia nhạy cảm với thời gian, chẳng hạn như người tìm kiếm, trả nhiều hơn và do đó hoạt động như một nguồn doanh thu bổ sung cho việc tổng hợp. Trong quá trình triển khai Arbitrum, người chiến thắng trong một cuộc đấu giá định kỳ được hưởng quyền tham gia không chậm trễ trong phút tiếp theo, trong khi các giao dịch từ những người còn lại phải chịu độ trễ 200 ms.

Xây dựng khối an toàn (SBB)

SBB , do Radius đề xuất, cho phép trình sắp xếp L2 nắm bắt lợi nhuận chạy ngược mà không ảnh hưởng đến trải nghiệm người dùng (UX). Đầu tiên, giao dịch của người dùng được trình sắp xếp L2 xác nhận nhanh chóng (theo đơn vị bó) và sau khi xác nhận, bó đó được chuyển tiếp đến trình tìm kiếm. Sau đó, trình tìm kiếm tạo giao dịch chạy ngược dựa trên bó đã nhận và giao dịch mới tạo này được đưa vào cuối khối L2. Trong suốt quá trình này, một mempool được mã hóa được sử dụng, nghĩa là giao dịch của người dùng được truyền đến trình sắp xếp L2 dưới dạng được mã hóa để bảo vệ chống lại sự thao túng có chủ đích, trong khi trình tìm kiếm sử dụng thông tin đã giải mã khi nhận được để xác định các cơ hội chạy ngược một cách hiệu quả.

Hoạt động của Searcher đang phát triển

Bất chấp các chính sách sắp xếp, nhằm mục đích nhận được nhiều phí hơn từ những người tìm thấy nhiều giá trị hơn từ việc đưa vào (nhanh hơn), người tìm kiếm có thể tránh phải trả phí cao và nắm bắt giá trị cho các cơ hội cụ thể. Hai chiến thuật dưới đây nằm trong số các chiến thuật như vậy.

Chạy ngược mù quáng

Blind backrunning là một hình thức chênh lệch giá nguyên tử xác định các cơ hội hoán đổi trong quá trình thực hiện giao dịch. Chiến lược này khả thi chủ yếu trên các blockchain có phí gas thấp. Các bot sử dụng blind backrunning làm tràn ngập mạng lưới bằng các giao dịch từ nhiều tài khoản, mỗi tài khoản được thiết lập với các cấu hình khác nhau (ví dụ: phí ưu tiên). Trên các chuỗi có thứ tự ưu tiên (ví dụ: Cơ sở) hoặc quy tắc FCFS (ví dụ: Arbitrum), chiến thuật này cho phép các bot chạy ngược gần như mọi giao dịch. Hành vi như vậy không chỉ hút giá trị ra khỏi giao thức mà còn khiến giao thức (L2 trong trường hợp này) khó nội bộ hóa hoàn toàn doanh thu giao dịch. Hơn nữa, vì nhiều giao dịch trong số này cuối cùng sẽ hoàn nguyên (gần đây, tỷ lệ hoàn nguyên đã giảm, nhưng điều này không nhất thiết có nghĩa là hoạt động blind backrunning đã giảm; xem tại đây ), không gian khối bị lãng phí chỉ để kiểm tra giá của các nhóm DEX nhiều lần.

Luồng lệnh riêng tư

Luồng lệnh riêng tư trên L1 đã bị chỉ trích vì đẩy nhanh quá trình tập trung hóa . Trong L2, nó vẫn là vấn đề nhưng lý do thì hơi khác một chút; nó làm suy yếu khả năng nội bộ hóa doanh thu của giao thức. Các thực thể có luồng lệnh riêng tư có thể tạo các bó "giả" nắm giữ gần như toàn bộ doanh thu từ việc chạy ngược. Tất cả các cơ chế sắp xếp theo trình tự được mô tả ở trên đều dễ bị tổn thương trước vectơ này. Ví dụ, theo chính sách sắp xếp theo thứ tự ưu tiên, người tìm kiếm có thể đặt priorityFeePerGas của giao dịch của mình thấp hơn chỉ 1 wei so với giao dịch của người dùng mục tiêu, gần như đảm bảo rằng giao dịch của mình sẽ được định vị ngay sau giao dịch của người dùng. Tương tự như vậy, trong FCFS hoặc các biến thể của nó, việc gửi nhiều giao dịch với độ trễ tối thiểu gần như đảm bảo cơ hội chạy ngược (đó là cách Polygon Fastlane đảm bảo việc đóng gói ).
Hơn nữa, hầu hết các giao dịch giữa người tìm kiếm và dApp (hoặc ví) đều được thực hiện ngoài chuỗi và không có thị trường chuẩn hóa cho luồng lệnh. Bối cảnh thị trường không minh bạch và không rõ ràng như vậy của luồng lệnh riêng tư gây ra sự bất đối xứng thông tin giữa người bán (người khởi tạo giao dịch) và người mua (người tìm kiếm), dẫn đến tình trạng kém hiệu quả.

Những nỗ lực trước đó

Mặc dù bối cảnh có thể thay đổi đôi chút, nhưng đã có nhiều nỗ lực nhằm giải quyết những vấn đề tương tự.

Gờ giảm tốc

Trong tài chính truyền thống (TradFi), các sàn giao dịch thường áp dụng các rào cản tốc độ bất đối xứng để ngăn chặn việc cắt giá và tăng tính thanh khoản. Vì chính sách này chỉ nhắm vào một loại lệnh cụ thể (lệnh thị trường cắt giá), tình huống này giống với trường hợp của chúng tôi. Chúng tôi không muốn đưa ra một cơ chế quá phức tạp hoặc chính sách tùy tiện; chúng tôi muốn ngăn chặn việc chạy ngược chiều một cách mù quáng và sự lãng phí không gian khối được tạo ra.

Thị trường phí địa phương

Tại Solana và một số chuỗi khác , thị trường phí cục bộ được đề xuất và áp dụng để việc tương tác chỉ với các hợp đồng hoặc kho lưu trữ cụ thể thường xuyên được chạm đến trở nên tốn kém, trong khi các giao dịch khác vẫn rẻ. Một lần nữa, chính sách này có thể hiệu quả đối với L2 để ngăn chặn hoặc không khuyến khích chạy ngược trở lại một cách mù quáng. Tuy nhiên, nó có nguy cơ làm giảm UX đối với các giao dịch bao gồm việc chuyển một số mã thông báo ERC-20 phổ biến và sẽ khó triển khai phù hợp.

Quy định về cuộc thi của SEC Order

SEC gần đây đã đề xuất quy tắc cạnh tranh lệnh gọi là Quy tắc đề xuất 615 để giải quyết vấn đề với luồng lệnh riêng. Lý do chính của họ là bằng cách buộc đấu giá quyền định tuyến mỗi lệnh, họ có thể đảm bảo cho nhà đầu tư thực hiện tốt hơn so với hiện trạng. Mặc dù không dẫn đến việc thực hiện, nhưng đáng chú ý là việc tổ chức đấu giá cho mỗi lệnh hoặc giao dịch là một lựa chọn khả thi.

Giới thiệu FairFlow

Trong phần này, chúng tôi trình bày một biến thể của TimeBoost có tên là FairFlow, nhằm mục đích thu lợi nhuận từ các cơ hội chạy ngược mà các phương pháp sắp xếp trình tự hiện tại bỏ qua, mà không ảnh hưởng đến trải nghiệm của người dùng. Nó đạt được mục tiêu đó bằng cách tạo ra một thị trường cho việc chạy ngược mà bất kỳ ai cũng có thể tham gia. Bằng cách kết hợp các yếu tố của đấu giá kiểu Hà Lan với TimeBoost, FairFlow khuyến khích người tìm kiếm tham gia và cạnh tranh trong thị trường được chỉ định này thay vì dựa vào các giao thức OFA của bên thứ ba. Chúng tôi tin rằng FairFlow có thể hỗ trợ các giải pháp Lớp 2 trong việc khôi phục giá trị từ việc chạy ngược hiệu quả hơn và giảm lãng phí không gian khối.

Mục tiêu

Dưới đây là các mục tiêu chúng tôi muốn đạt được với FairFlow:

Thiết lập một thị trường không cần xin phép cho các cơ hội chạy ngược
Chúng tôi mong muốn tạo ra một thị trường thúc đẩy sự cạnh tranh lành mạnh giữa những người tìm kiếm và tạo điều kiện cho việc khám phá giá cho mỗi cơ hội chạy ngược. Mục tiêu cuối cùng của chúng tôi là nâng cao hiệu quả và tính minh bạch chung của thị trường dòng lệnh và biến việc gửi giao dịch trực tiếp đến FairFlow cho người dùng trở thành chiến lược chủ đạo.
Bảo vệ người dùng
Chúng tôi nỗ lực giảm thiểu rủi ro liên quan đến các cuộc tấn công kiểu sandwich và front-running, cũng như lãng phí không gian khối do các giao dịch spam gây ra. Mục tiêu của chúng tôi là tạo ra một môi trường nơi người dùng L2 có thể giao dịch an toàn và thuận tiện, không có sự chậm trễ đáng kể hoặc chi phí bổ sung.
Xây dựng nền kinh tế L2 bền vững
Bằng cách nội bộ hóa doanh thu chạy ngược ở cấp độ giao thức, chúng tôi hỗ trợ L2 trong việc phát triển cấu trúc doanh thu ổn định. Cách tiếp cận này dự kiến sẽ thúc đẩy một chu kỳ lành mạnh góp phần vào sự phát triển của toàn bộ hệ sinh thái Ethereum.

Nó hoạt động như thế nào

Như đã đề cập, FairFlow về cơ bản là một biến thể của TimeBoost của Arbitrum và chính sách sắp xếp của nó có thể được chia thành ba bước:

1. Khi trình sắp xếp nhận được giao dịch của người dùng, nó sẽ khởi tạo một cuộc đấu giá kiểu Hà Lan để giành quyền chạy ngược giao dịch đó. Những người tìm kiếm muốn chạy ngược giao dịch của người dùng sẽ gửi chữ ký EIP-712 cho giao dịch đấu giá và chạy ngược cho người đấu giá (trình sắp xếp). Lưu ý rằng người dùng có thể đính kèm giá thầu cho chính mình (tự đấu giá).
2. Khi giá dự trữ nhỏ hơn hoặc bằng một trong những giá thầu đã gửi, phiên đấu giá sẽ kết thúc và giao dịch của người dùng cùng giao dịch chạy ngược (nếu có) sẽ được nhóm lại với nhau rồi thêm vào BundleList.
3. Tại mỗi lần tạo khối, các bó được chọn từ BundleList—lên đến giới hạn gas—và được đưa vào khối để thực thi tuần tự theo cách FCFS (tức là bó cũ hơn sẽ được thực thi trước).

Tóm lại, để đạt được các mục tiêu đã đề cập ở trên, chúng tôi đã áp dụng cơ chế TimeBoost với một điều chỉnh đơn giản: cho phép bất kỳ ai thúc đẩy giao dịch của người dùng bằng cách đấu giá thay mặt cho người dùng và đổi lại, người đó nhận được quyền chạy ngược giao dịch của người dùng. Trong phần sau, chúng tôi sẽ giải thích lý do đằng sau thiết kế như vậy và cách nó cuối cùng sẽ ngăn chặn việc spam các thử nghiệm chạy ngược mù quáng và cho phép L2 kiếm được nhiều doanh thu hơn.

Phân tích

Cơ sở lý luận

• Thị trường công cộng duy nhất
  Mỗi giao dịch được tiết lộ cho người đăng ký trước khi đưa vào, thiết lập thị trường này như một nền tảng thống trị và tổng hợp cho luồng lệnh. Cách tiếp cận này làm giảm sự phân mảnh và tăng cường khám phá giá.
• Đấu giá của Hà Lan
  Bằng cách triển khai hệ thống đấu giá ngoài chuỗi, chúng ta có thể giới hạn các giao dịch spam ở mức tối đa là một giao dịch cho mỗi người dùng. Ngoài ra, bản chất của đấu giá kiểu Hà Lan cho phép giao thức này nắm bắt doanh thu hiệu quả, ngay cả khi có giao thức On-chain Frontrunning Alternatives (OFA) của bên thứ ba. Nếu người tìm kiếm có được thông tin về giao dịch đến, họ phải trả giá cao; nếu không, thông tin đó sẽ được chia sẻ với những người khác, ngăn họ khai thác tình hình một cách hiệu quả mà không có sự đền bù thỏa đáng.
  Hơn nữa, ngay cả khi một giao thức bên thứ ba bên ngoài quản lý để đóng gói các giao dịch, chẳng hạn như bằng cách sử dụng một cuộc đấu giá ngoài chuỗi dựa trên chữ ký khiến cho ý định của người dùng và hoạt động của người tìm kiếm trở nên không thể tách rời, thì chúng thường sẽ phải chịu nhiều sự chậm trễ hơn. Điều này là do người tìm kiếm thắng cuộc đấu giá để thực hiện ý định của người dùng sẽ có ít nguồn lực ngân sách hơn (đã trả tiền để giành được OFA), do đó hạn chế khả năng đấu giá đủ để thúc đẩy giao dịch. Do đó, đối với các hoạt động nhạy cảm về thời gian như đúc NFT hoặc mua memecoin mới ra mắt, việc sử dụng một nền tảng như vậy có thể không phải là lựa chọn tối ưu nhất.

Kết quả mong đợi

Chúng tôi chủ yếu dự đoán hai kết quả chính:

• Giảm thư rác và lãng phí không gian khối : Bằng cách giới hạn số lần thử chạy ngược mù ở mức tối đa một lần cho mỗi giao dịch của người dùng, ngay cả trong trường hợp có nhiều thực thể thử chạy ngược mù, chúng tôi kỳ vọng sẽ giảm đáng kể không gian khối bị lãng phí.
• Tăng cường doanh thu nội bộ và hiệu quả thị trường : Thay vì phân phối luồng lệnh trên các thị trường rời rạc và không minh bạch, tất cả các giao dịch sẽ được tạo điều kiện thuận lợi trong một thị trường duy nhất có nhiều nhà thầu cạnh tranh. Sự hợp nhất này sẽ cải thiện hiệu quả và phát hiện giá của luồng lệnh, cuối cùng thúc đẩy doanh thu cho giao thức và các đối tác liên kết của nó.

Hạn chế

• Chúng tôi lưu ý rằng theo phiên bản hiện tại, những người khởi tạo giao dịch (ví và dApp) không thể kiếm được doanh thu và việc thiết lập chính sách hoàn trả một cách mù quáng sẽ làm méo mó thêm động lực (chia sẻ doanh thu có thể dẫn đến việc hạ giá dự trữ cho người tìm kiếm). Mặc dù chúng tôi không thảo luận về hoàn trả hoặc chia sẻ doanh thu trong bài đăng này, nhưng có vẻ như việc đưa các địa chỉ vào danh sách trắng thủ công (ví dụ: kho bạc đa chữ ký của các dApp được liên kết) để chia sẻ doanh thu nói chung là một chính sách đúng đắn.
• Ngoài ra, mặc dù nhìn chung là không khôn ngoan về mặt kinh tế, các cuộc tấn công sandwich hoặc frontrunning về mặt lý thuyết là khả thi bằng cách trả giá cao hơn giao dịch của người dùng ngay khi nhận được và nhận ra ý định của người dùng. Tuy nhiên, điều quan trọng cần lưu ý là ngay cả khi một cuộc tấn công như vậy là khả thi, kẻ tấn công vẫn phải đối mặt với những rủi ro đáng kể, vì giao dịch tấn công của chính họ cũng sẽ được phát cho những người tìm kiếm khác và có thể chạy ngược lại.
• Thật khó để thiết lập các thông số một cách chính xác. Để FairFlow hoạt động như mong muốn và không cản trở trải nghiệm của người dùng, thời gian đấu giá không được quá dài cũng không được quá ngắn. Nếu quá dài, người dùng trung bình sẽ phải chịu sự chậm trễ quá lâu. Nếu quá ngắn, không có người tìm kiếm nào sẽ đánh giá đúng các cơ hội chạy ngược và chọn spam hoặc bỏ qua chúng. Hơn nữa, đường cong giá dự trữ phải giảm dần một cách hợp lý để nắm bắt được toàn bộ giá trị một cách đầy đủ. Mặc dù chúng tôi không cung cấp các con số chính xác trong bài đăng này, nhưng chúng tôi sẽ đề cập đến các điểm chung cần xem xét trong phần sau.

Mô tả kỹ thuật

Phần này mô tả cơ chế và hệ thống tổng thể một cách chi tiết hơn.

Thuật ngữ

• Sequencer : Thực thể L2 chịu trách nhiệm tiếp nhận giao dịch của người dùng, khởi tạo phiên đấu giá ngược và quản lý thứ tự các giao dịch để đưa vào khối.
• User : Người dùng cuối hoặc dApp gửi giao dịch để đưa vào khối L2.
• Searcher(s) : Các thực thể (bot hoặc nhà điều hành) theo dõi các giao dịch đang chờ xử lý, tham gia đấu giá và gửi các giao dịch trả chậm.
• Executor : Thực thể L2 tổng hợp và thực hiện các giao dịch trong mỗi khối. Mặc dù không cần phải là một thực thể khác với Sequencer , nhưng để giúp hiểu rõ hơn trong bài viết này, chúng tôi đã chia chúng thành hai.
• UserTx : Giao dịch gốc do người dùng gửi.
• Auctioneer Contract : hợp đồng thông minh duy trì số dư của mỗi người đấu giá và thanh toán cho mỗi phiên đấu giá.
• Bid : Một yêu cầu từ người tìm kiếm hoặc người dùng nâng cao, dưới dạng chữ ký EIP-712, cho biết họ sẵn sàng chạy ngược lại một giao dịch nhất định với một khoản phí cụ thể.
• BackrunTx : Giao dịch chạy ngược được người tìm kiếm gửi như một phần trong giá thầu của họ.
• BundleList : Hàng đợi có thứ tự lưu trữ các gói đã hoàn tất (mỗi gói bao gồm một UserTx và nếu có thể, một BackrunTx chiến thắng) đang chờ để đưa vào khối.
• Tham số đấu giá: Các tham số này xác định hình dạng của đường cong giá dự trữ cho một cuộc đấu giá kiểu Hà Lan. Mặc dù các tham số cần thiết có thể thay đổi theo đường cong cơ sở (tuyến tính, nghịch đảo, hàm mũ, …), bài viết này giới thiệu những điều sau:
  • max_period : Khoảng thời gian tối đa mà người đấu giá sẽ chờ để có giá thầu, tức là thời gian đấu giá tối đa có thể.
  • min_price : Giá tối thiểu mà người đấu giá muốn nhận. Nếu không có giá thầu nào vượt quá hoặc bằng giá trị này, phiên đấu giá sẽ được giải quyết mà không có người chiến thắng sau khi max_period trôi qua.
  • decay_rate : Tỷ lệ giảm của giá dự trữ.

Vòng đời của giao dịch

Theo FairFlow, giao dịch của người dùng sẽ trải qua quy trình sau:

1. Nộp bài:
   User gửi giao dịch ( UserTx ) đến Sequencer và tùy chọn là Bid theo hình thức đấu giá kiểu Hà Lan.
2. Bắt đầu đấu giá:
   Khi nhận được UserTx mới, Sequencer sẽ khởi tạo phiên đấu giá kiểu Hà Lan để giành quyền thực hiện lại giao dịch.
3. Thông báo:
   Sequencer chuyển tiếp thông tin chi tiết UserTx tới Searcher(s) đã đăng ký giao dịch của người dùng với API FF_newPendingTransactions .
4. Đấu thầu:
   Searcher(s) phân tích giao dịch đang chờ xử lý để tìm cơ hội chạy ngược. Nếu xác định được cơ hội, người tìm kiếm sẽ gửi Bid và BackrunTx bằng API FF_submitBackrunTxAndBid .
5. Giải quyết đấu giá:
   Sequencer chờ cho đến khi giá dự trữ (được xác định bởi đường cong giá dự trữ giảm dần) giảm xuống dưới một trong những giá thầu hợp lệ đã gửi. Tại thời điểm đó, phiên đấu giá kết thúc và giá thầu chiến thắng được xác định. (Lưu ý: Có thể không có người chiến thắng nếu không có người tìm kiếm nào quan tâm.)
6. Đóng gói:
   Gói kết quả (chứa UserTx ban đầu và nếu có, BackrunTx chiến thắng) được thêm vào BundleList .
7. Xác nhận trước:
   Một cam kết lệnh sẽ được gửi tới người dùng, đảm bảo giao dịch sẽ được thực hiện theo thứ tự đã định trước.
8. Bao gồm khối:
   Ngay trước khi tạo khối, Sequencer sẽ chọn các bundle cũ nhất từ BundleList (lên đến giới hạn gas) và chuyển chúng đến Executor thông qua API FF_requestBundleList .
9. Xây dựng khối:
   Executor xây dựng một khối bằng cách thực hiện tuần tự các giao dịch trong các bó đã nhận và công bố khối đó.

Đấu giá chạy ngược

Trong phần này, chúng tôi sẽ giải thích sâu hơn về phiên đấu giá.

Đường cong giá dự trữ

Hình dạng và các thông số của đường cong giá dự trữ là rất quan trọng. Thiết lập không phù hợp có thể dẫn đến việc nắm bắt giá trị không đáng kể trong khi gây ra sự chậm trễ quá mức. Chúng tôi đề xuất hai mô hình đường cong:

Đường cong suy giảm tuyến tính

Đường cong suy giảm tuyến tính là một mô hình đơn giản và trực quan giúp giảm giá dự trữ ở mức không đổi:
reserve_price(t) = min_price + decay_rate × (max_period - t) .
Mặc dù nó có thể không nắm bắt được giá trị đầy đủ trong trường hợp có giá trị ngoại lệ, nhiều giao thức đã áp dụng đường cong như vậy do tính đơn giản của nó. Các giao thức đó bao gồm:

• 1inch Fusion: 1inch Fusion sử dụng đường cong tuyến tính một phần có thể cấu hình bởi người dùng.
• UniswapX: Tương tự như 1inch Fusion, UniswapX bán quyền thực hiện lệnh của người dùng cho “người thực hiện” theo hình thức đấu giá kiểu Hà Lan, với đường cong tuyến tính có thể định cấu hình bởi người dùng.
• Các ví dụ khác bao gồm, nhưng không giới hạn ở, phiên đấu giá thanh lý của DAI, phiên đấu giá tái cân bằng kho chiến lược cua của Opyn, v.v.

Đường cong suy giảm tương hỗ

Mô hình này sử dụng hàm nghịch đảo của một hàm ban đầu được đề xuất trong bài báo TimeBoost gốc , được gọi là dạng hàm trì hoãn đơn giản nhất:
reserve_price(t) = min_price + decay_rate × (max_period / t - 1) .
Với điều kiện độ trễ của người tìm kiếm đủ thấp thì nó có thể nắm bắt được hầu hết giá trị trong hầu hết mọi trường hợp.

Thiết lập các thông số và sự đánh đổi

Trong khi mỗi L2 có thể tự do lựa chọn đường cong và thông số thì vẫn có một số khuyến nghị chung để thiết lập thông số.

• Khoảng thời gian tối đa không nên quá dài vì có thể làm hỏng trải nghiệm của người dùng. Chúng tôi khuyên bạn nên đặt khoảng thời gian dưới 1 giây, quá đủ cho hầu hết những người tìm kiếm nhắm mục tiêu vào giao dịch của người dùng để kiếm lợi nhuận chênh lệch giá. Một số nền tảng và bản dùng thử khác cũng đang áp dụng khoảng thời gian đấu giá khoảng 100ms-500ms.
• Đường cong không nên suy giảm quá nhiều ở các giai đoạn trước. Do giới hạn vật lý, một số độ trễ không thể tránh khỏi và chỉ một số ít người chơi có thể đấu giá tại thời điểm đó, dẫn đến rò rỉ giá trị. Do đó, ngay từ đầu, giá phải được đặt cao hơn giá trị mong đợi và nên áp dụng đường cong nghịch đảo hoặc đường cong tuyến tính có độ cong ở các giai đoạn trước.
• Nên điều chỉnh các thông số theo từng bước để phần lớn độ phân giải có thể đạt được vào giữa phiên đấu giá thay vì vào đầu hoặc cuối phiên đấu giá.
• Một số liệu khác cần xem xét là khoảng cách giữa giá thầu và giá dự trữ tại thời điểm tiếp nhận giá thầu. Hầu hết người tìm kiếm sẽ giảm thiểu khoảng cách thời gian giữa việc gửi giá thầu và giải quyết đấu giá để tránh biến động. Nếu khoảng cách quá lớn, đường cong có thể suy giảm quá nhanh và không nắm bắt được giá trị đầy đủ.

Giải quyết đấu thầu

Người tìm kiếm hoặc người dùng nâng cao gửi giá thầu của họ với BackrunTx bằng chữ ký EIP-712. Auctioneer Contract trên mỗi L2 xử lý các lần gửi này. Cuộc đấu giá được giải quyết khi giá dự trữ giảm xuống dưới một trong các giá thầu đã gửi. Một tài khoản đấu giá do Sequencer sở hữu sẽ gửi giao dịch thanh toán, giao dịch này sẽ khấu trừ số dư của người đấu giá trong Auctioneer Contract . Lưu ý rằng việc thanh toán có thể không đồng bộ với việc thực hiện gói. Ngoài ra, trong khi Sequencer có thể không cần mô phỏng việc thực hiện và theo dõi toàn bộ trạng thái của chuỗi, thì nó sẽ theo dõi số dư của người đấu giá tại kho tiền và sẽ chỉ chấp nhận giá thầu sao cho số dư được báo cáo cuối cùng lớn hơn một số ngưỡng nhất định của giá thầu đã gửi. Điều này nhằm ngăn chặn tình trạng mất khả năng thanh toán. Monad đã triển khai một hệ thống tương tự để cung cấp cả việc đưa vào nhanh chóng đồng thời ngăn chặn việc gửi thư rác từ các tài khoản có số dư thấp.

Thông số kỹ thuật

Trong phần này, chúng tôi cung cấp sơ đồ trình tự và thông số kỹ thuật để làm rõ hơn cấu trúc và cách tương tác của từng thực thể.

Người dùng ↔️ Trình sắp xếp

eth_sendRawTransaction : Gửi giao dịch tiêu chuẩn.
FF_sendRawTransactionAndBid : gửi cho người dùng nâng cao bao gồm tùy chọn tự đấu giá. Thông qua tự đấu giá, người dùng có thể đẩy nhanh giao dịch của mình.

Người tìm kiếm ↔️ Trình sắp xếp

FF_newPendingTransactions : Cho phép người tìm kiếm đăng ký và nhận thông báo về các yêu cầu UserTx mới đang chờ xử lý.
FF_submitBackrunTxAndBid : Cho phép người tìm kiếm gửi giá thầu đã ký EIP-712 cùng với BackrunTx .
FF_newBundleAdded : Cho phép người tìm kiếm đăng ký và nhận thông báo về các gói mới được thêm vào để mô phỏng và đoán trạng thái gần đây nhất của chuỗi.

Người thực hiện ↔️ Người sắp xếp

FF_requestBundleList : Bộ thực thi sử dụng điểm cuối này để truy xuất các gói đã hoàn thiện ( UserTx + BackrunTx ) để xây dựng khối.

Phần kết luận

Thông qua bài đăng này, chúng tôi đã xem xét các chính sách sắp xếp hiện có và cách các chiến lược được phát triển gần đây đang khai thác các chính sách này, cuối cùng làm giảm trải nghiệm của người dùng và cản trở các giao thức nội bộ hóa doanh thu hiệu quả. Để đáp lại, chúng tôi đề xuất FairFlow, thiết lập một thị trường đấu giá công khai duy nhất, cho phép tất cả những người tham gia đấu giá công bằng cho các cơ hội chạy ngược. Thiết kế của chúng tôi cụ thể triển khai một cuộc đấu giá cấp giao thức cho mỗi giao dịch và ngầm đưa ra các sự chậm trễ bổ sung cho các giao dịch có chứa MEV được trích xuất riêng tư bên ngoài giao thức. Cơ chế này không chỉ khuyến khích những người tham gia thị trường tham gia vào cuộc đấu giá công khai mà còn cho phép L2 và người tìm kiếm nội bộ hóa MEV từ các cơ hội chạy ngược hiệu quả hơn, giải quyết tình trạng kém hiệu quả phát sinh từ thị trường luồng lệnh riêng tư và các giao dịch thư rác. Chúng tôi cung cấp các API và sơ đồ trình tự chi tiết để làm rõ hơn về việc triển khai. Chúng tôi hy vọng thiết kế này sẽ hữu ích và đủ hợp lý để các L2 sắp tới (hoặc hiện tại) áp dụng.

Giới thiệu về Radius

Radius cam kết thúc đẩy hệ sinh thái L2 của Ethereum bằng cách nắm bắt MEV công bằng và minh bạch. Cơ sở hạ tầng backrunning cấp giao thức của chúng tôi hỗ trợ tính bền vững và lợi nhuận của L2, góp phần vào tầm nhìn của chúng tôi về sự phát triển của Ethereum như một nền tảng hàng đầu.
Nghiên cứu của chúng tôi về FairFlow khám phá các phương pháp tiếp cận tiềm năng cho các thách thức của L2. Nếu bạn quan tâm đến việc tìm hiểu thêm về nghiên cứu hoặc các sản phẩm của chúng tôi như Secure Block Building (SBB) hoặc Lighthouse , chúng tôi rất muốn kết nối . Cùng nhau, chúng ta có thể giúp L2 tạo ra doanh thu ổn định, thu hút người dùng và củng cố hệ sinh thái Ethereum.