Cơ chế phí giao dịch đã trở thành mô hình làm việc để hiểu quá trình trung gian của các nhà sản xuất khối giữa người dùng muốn thực hiện giao dịch và "chuỗi" (hoặc "giao thức") mà người dùng thực hiện giao dịch trên đó. Với khả năng sử dụng một phần nguồn cung cấp bởi chuỗi, những nhà sản xuất khối phải điều độ người dùng nào sẽ có khả năng sử dụng tài nguyên khan hiếm của việc thực thi trên chuỗi, và với chi phí bao nhiêu. Trên Ethereum, đối với câu hỏi về chi phí, những nhà sản xuất khối bị ràng buộc bởi cơ chế phí EIP-1559, mà động lực đặt giá dự trữ từ khối này sang khối khác, gọi là "phí cơ bản". Phí cơ bản là một giá, được biểu thị theo đơn vị gas, mà giao dịch của người dùng phải trả để được bao gồm và thực thi. Người dùng có thể cung cấp các "phí ưu tiên" vượt quá phí cơ bản, để khuyến khích thêm những nhà sản xuất khối trong thời gian kẹt xe.

Trong ghi chú này, chúng tôi điều tra câu hỏi về các thể trường phí nhúng, từng nghĩa là thể trường phí mà "sống" bên trong các thể trường phí khác. Câu hỏi này đã đơn cửa trong một bài báo gần đây của Maryam Bahrani, Pranav Garimidi và Tim Roughgarden, "Thiết kế cơ chế phí giao dịch trong thế giới sau MEV 9Trong bài báo này, tác giả mô hình hóa việc sử dụng người tìm kiếm, tạo ra sự trung gian trong việc tiếp cận chuỗi giữa người dùng và nhà sản xuất khối. Nhà sản xuất khối nhận được "gợi ý" từ người tìm kiếm, được biểu hiện bằng gói gọn nguyên tử của giao dịch sẽ được bao gồm bởi chuỗi. Thị trường phí của người tìm kiếm được thúc đẩy bởi mục tiêu tối đa hóa một lượng được biết đến là MEV, hoặc giá trị có thể khai thác tối đa.

Trong cài đặt của chúng tôi, người dùng muốn truy cập vào chuỗi nhưng không thể hiện nhu cầu của mình bằng giao dịch đọc được bằng giao thức. Thay vào đó, người dùng tạo ra “thao tác”, được gói bởi các thực thể được biết đến là “bundlers”, sau đó bundlers sẽ tạo ra một giao dịch đọc được bằng giao thức đóng gói các thao tác lại với nhau để thực hiện. Do đó, đối với cơ chế phí EIP-1559, bundlers là người dùng của chuỗi, tuy nhiên người dùng thực sự phải đạt được việc được bao gồm trong gói của bundler trước khi họ có thể được bao gồm vào chuỗi. Nói cách khác, chúng ta có thể xem cài đặt này như một phần của câu hỏi lớn hơn về sự sáng tạo khối, mà phát sinh với (một phần) người tìm kiếm/xây dựng cũng như danh sách bao gồm.

Hy vọng rằng những quá trình này sẽ được minh bạch nhất có thể, đồng thời không tạo thêm áp lực nhận thức hoặc cơ hội để người dùng bị khai thác một cách không công bằng bởi bộ gói, so với việc giao dịch trực tiếp trên chuỗi. Chúng tôi hy vọng có kết quả mạnh mẽ hơn, trong những trường hợp người dùng thực sự được hưởng lợi từ sự trung gian của bộ gói, khi chi phí được phân bổ cho phép người dùng tận hưởng phúc lợi lớn hơn.

Để điều tra sự phân biệt giữa các thị trường phí trực tiếp và các (phụ) cơ chế nhúng của chúng, chúng ta phải xác định rõ ràng các ràng buộc kinh tế mà một người gói hàng phải tuân theo. Ở phần tiếp theo, chúng tôi đề xuất một mô hình đơn giản của hàm chi phí người gói hàng được truyền cảm hứng bởi thực tiễn, đặc biệt là người gói hàng tham gia vào giao thức ERC-4337, mà chúng tôi tóm tắt ngắn gọn.

Mô hình

Gói trong ERC-4337

Người dùng muốn thực hiện một số hoạt động trên chuỗi thông qua các gói sẽ phát hành Hoạt động của người dùng (UserOp hoặc hoạt động). UserOp này được phát ra từ ví của người dùng, ví dụ: sau khi tương tác với DApp. Khi UserOp được phát sóng, một số bundler nhận được hoạt động có thể quyết định đưa nó vào một gói. Gói là một giao dịch meta "tài khoản thuộc sở hữu bên ngoài" (EOA), ghi dữ liệu của UserOps được bao gồm trong trường bundle.calldata của nó. Bundler phát hành gói theo hướng đưa vào một khối bởi một nhà sản xuất khối (chúng tôi thảo luận về mối quan hệ giữa bundler và nhà sản xuất khối trong một ghi chú trong tương lai).

Khi gói được bao gồm trong khối và khối đi đến chuỗi, gói được thực thi cùng với các giao dịch khác trong khối. Về cơ bản, các bước thực thi gói như sau:

• Pre-verification: Giao dịch EOA của người gói sẽ tiêu tốn 21.000 gas, và cuộc gọi tới hợp đồng EntryPoint sẽ thiết lập các biến quan trọng để theo dõi việc thực hiện các hoạt động trong vòng lặp hoạt động.
• Hoạt động vòng lặp 3: Đối với mỗi hoạt động được bao gồm trong gói, hai bước sau được tiến hành:
  • Bước xác minh: UserOps thực hiện các hoạt động chứa một bước xác minh, được mã hóa trong một "ví hợp đồng thông minh" triển khai ban đầu bởi người dùng (trong một UserOp ban đầu). Bước xác minh có thể chỉ kiểm tra chữ ký hoặc thực hiện các hoạt động phức tạp hơn để "cấp" quyền cho UserOp tiếp tục thực thi. Bước xác minh được đo lường bởi op.verificationGasLimit.
  • Bước thực hiện: Lõi của UserOp, bước thực hiện thực hiện hoạt động được mô tả trong op.callData. Bước này cũng được đo lường bằng cách sử dụng op.callGasLimit.

Như đã được làm rõ bởi phân tích trước đó, bước xác minh trước được thực thi một lần, cung cấp khả năng phân bổ chi phí xác minh trước trên tất cả các người dùng bao gồm. Khi bộ dữ liệu được thực thi, tất cả các chi phí (ví dụ: block.basefee + phí ưu tiên được thanh toán bởi bundler cho nhà sản xuất khối bao gồm chúng) được tính cho bundler, người phải đảm bảo rằng các hoạt động của người dùng đền bù đủ cho chi phí phát sinh. Chúng tôi làm rõ những tuyên bố này trong phần tiếp theo.

Mô hình thị trường phí cho các gói dịch vụ

Chúng tôi cố gắng duy trì tính nhất quán với các mô hình thị trường phí cổ điển. Một người dùng t muốn phát ra một thao tác có một giá trị vt cho việc thực hiện thao tác. Chúng tôi giả định tất cả các thao tác có cùng kích thước S (tức là cùng lượng khí sử dụng cho các bước xác minh và thực hiện), và do đó chúng tôi diễn đạt tất cả các lượng tử dưới dạng giá cả trên mỗi đơn vị khí.

Người dùng thể hiện mong muốn được bao gồm bằng cách gửi một bid bt cùng với hoạt động của họ. Hiện tại, chúng tôi không giả định một ngữ pháp cụ thể cho người dùng để thể hiện sự đấu giá của họ để được bao gồm, ví dụ, khả năng thể hiện một phí tối đa và phí ưu tiên cùng với hoạt động của họ, như họ sẽ làm với EIP-1559. Các hoạt động của người dùng được thu thập trong một mempool M, đại diện cho trạng thái đang chờ xử lý của các hoạt động này cho đến khi được bao gồm.

Thị trường phí EIP-1559 tiết lộ một giá dự trữ r được biết đến là “phí cơ sở”, mà những người đóng gói phải chi trả khi gói của họ được thực hiện. Nếu gói chứa n hoạt động, người đóng gói sau đó phải chi ít nhất n × S × r. Ngoài ra, vì gói tiêu thụ “gas trước xác minh”, ví dụ, một lượng F nào đó, người đóng gói sẽ phải trả thêm F × r

. Các hoạt động được bao gồm trong bộ này được cung cấp bởi tập hợp B.

Hàm chi phí của Bundler

Chúng tôi hiện xem xét những chi phí mà các nhà đóng gói phải chịu để đưa gói của họ vào khối.

Hàm chi phí trên chuỗi: Một người gói phát hành gói B khi phí cơ sở là r chi phí:

Vấn đề gói hàng phản ánh vấn đề nhà sản xuất khối được diễn đạt trong [Roughgarden 2021] 3.Ở đó, nhà sản xuất khối phải đảm bảo việc cung cấp một giá trị nào đó μ bồi thường cho cô ấy chi phí bao gồm một giao dịch bổ sung vào khối của họ (ví dụ, μ có thể bồi thường cho tải thêm của khối, làm chậm sự lan truyền và do đó tăng nguy cơ re-org). Thị trường phí cấp khối sau đó phải đảm bảo rằng nhà sản xuất khối ít nhất được bồi thường cho chi phí tổng cộng n × S × μ, nếu nhà sản xuất khối bao gồm n giao dịch trong khối của họ. Thị trường phí cấp bundler sẽ yêu cầu ít nhất bồi thường bundler cho chi phí bên ngoài

Họ phải chịu Con-chain(B,r) từ thị trường phí lớn hơn mà họ được nhúng vào.

ERC-4337 cung cấp khả năng phân tán chi phí vượt qua việc chia sẻ chi phí gas xác minh trước. Nếu tất cả các hoạt động sử dụng cùng một hệ thống chữ ký cho bước xác minh của họ, chữ ký của những hoạt động này có thểtổng hợp 2bằng cách gom nhóm, thay vì xác minh n chữ ký trên chuỗi, chỉ cần xác minh một chữ ký duy nhất. Trong trường hợp này, chức năng chi phí của bộ gom nhóm sẽ cần tính đến các chi phí ngoại chuỗi mà bộ gom nhóm phải chịu khi thực hiện việc tổng hợp. Trong phần sau, chúng ta giả định rằng các chi phí như vậy tuyến tính theo số lượng hoạt động, tương tự một giả định khác[Wang et al., 2024] 2, với chi phí biên đạo đạo đức ω.

Chúng tôi cũng tính đến mức tiêu thụ khí giảm của mỗi hoạt động, do tiết kiệm từ việc tổng hợp. Khi được tổng hợp, các hoạt động không bắt buộc phải xuất bản chữ ký của chúng, nhưng chúng yêu cầu một thao tác ghép nối bổ sung. Trên các chuỗi nơi chi phí calldata đắt đỏ, nhưng các hoạt động ghép nối / tính toán rẻ, tổng hợp do đó cung cấp tiết kiệm cho mỗi hoạt động. Trong trường hợp này, chúng tôi biểu thị bằng S′ < S kích thước giảm của một giao dịch. Chúng tôi cũng cần tính đến việc tăng mức sử dụng khí xác minh trước F ′ > F, hiện chứa việc xuất bản và xác minh chữ ký tổng hợp trên chuỗi duy nhất.

Hàm chi phí tổng hợp: Một người gói phát hành gói B với các chữ ký tổng hợp khi phí cơ sở là r chi tiêu một chi phí:

Trong ghi chú này, chúng tôi sẽ không đi xa hơn, nhưng người ta cũng có thể xem xét các chi phí xuất bản dữ liệu mà một người đóng gói có thể phải chi trả khi gói của họ giải quyết trên một rollup. Chúng tôi đề xuất hai cách mô hình hóa điều này và để câu hỏi này cho công việc trong tương lai:

• Hoặc chính người đóng gói dữ liệu chịu trách nhiệm cho việc xuất bản dữ liệu (ví dụ như một người sắp xếp), và do đó yêu cầu thu thập từ người dùng số tiền cần thiết để trả các chi phí xuất bản dữ liệu sau này.
• Hoặc thị trường phí cấp bó được nhúng trong một thị trường phí cấp lô lớn hơn, thông qua đó Rollup tiết lộ cho người dùng Rollup (bao gồm bundler) số tiền họ phải trả do tắc nghẽn (ví dụ, phí cơ bản) và chi phí xuất bản dữ liệu cuối cùng. Trong trường hợp này, Rollup chịu trách nhiệm cân bằng chi phí tương lai của họ với doanh thu hiện tại của họ.

Kiểm tra lại số lượng thị trường phí

Bây giờ chúng ta có thể chính thức diễn đạt các khái niệm liên quan đến thị trường phí cấp gói, suy ra chúng một cách trực tiếp từ tài liệu trước đây, trong khi lấy việc nhúng vào xem xét.

Quy tắc phân bổ cấp đóng gói: Một phân bổ (cấp đóng gói) x quyết định tập hợp các hoạt động của người dùng mà người gói gói hàng của họ bao gồm, với bộ nhớ tạm thời hiện tại M và phí cơ sở r.

Quy tắc thanh toán cấp đóng gói: Đưa ra tập hợp các hoạt động đã chọn B, một quy tắc thanh toán gán một khoản phí cho mỗi người dùng được bao gồm

Chức năng tiện ích người dùng:

Về nguyên tắc, chúng ta có thể cho phép tồn tại một quy tắc đốt qt(B) thể hiện rằng người đóng gói không thể nhận được toàn bộ các khoản thanh toán của người dùng đã bao gồm. Tuy nhiên, chúng tôi không xem xét điều đó trong ghi chú này.

(Thành viên) chức năng tiện ích của bundler:

Một TFM cấp gói (x, p) là cổng cổng cổng cổng cổng cổng cổng cổng gian lận cho các gói cắt ngắn (MBIC) nếu, đối với mọi mempool M và phí cơ sở r, một gói cắt ngắn tối đa hóa tiện ích của mình bằng cách tuân theo gợi ý của quy tắc phân bổ x (tức là, đặt B = x(M, r)).

Xây dựng nhiều gói hàng

Trong phần trước, chúng tôi chỉ xem xét khả năng cho người gói gói một gói duy nhất. Tuy nhiên, chúng tôi có thể quan tâm đến khả năng cho người gói tạo nhiều hơn một gói từ các hoạt động có sẵn trong mempool. Cho mempool M, hãy để P(M) biểu thị tập hợp các phân vùng của mempool, gán mỗi hoạt động vào một gói duy nhất (chúng ta có thể giả định rằng đối với mỗi phân vùng, có một tập được gán chỉ số 0 chứa tất cả các hoạt động không được gán cho một gói để bao gồm). Quy tắc phân bổ sau đó trả về chỉ số của tập trong phân vùng mà hoạt động được gán vào.

Chúng tôi có thể viết tập hợp các gói sản phẩm được đầu ra bởi phân vùng x(M,β) như là B(x(M,r)). Một cách trực quan, các gói sản phẩm này được tạo ra từ các hoạt động không thuộc về tập được đánh chỉ số 0. Cho một tập hợp các gói sản phẩm B, quy tắc thanh toán sẽ là:

Chức năng tiện ích của người dùng trở thành:

và chức năng tiện ích bundler trở thành:

Trò chơi bundler

Inclusion of transactions in blocks must remunerate some quantity μ to the block producers, which is assumed to be linear in the transaction size in e.g., [Roughgarden, 2021] 3. Số lượng này chỉ ra chi phí cơ hội cho nhà sản xuất khối để thêm giao dịch phụ vào khối của họ, ví dụ, tăng độ trễ trò chuyện của họ và do đó tăng cơ hội của họ bị re-orged. Trong Proof-of-Stake, mặc dù lịch trình giao thức cho phép đủ thời gian để truyền một khối đầy đủ,trò chơi về thời gianđã gây ra động lực lan truyền "cuối cùng" một lần nữa làm cho tham số μ này trở nên quan trọng.

Trong mọi trường hợp, chúng ta có thể quan sát rằng vấn đề chia sẻ chi phí ở mức khối và mức gói rất khác nhau. Ở mức khối, một giao dịch không cần phải biết những gì đang diễn ra bên trong khối để lập kế hoạch đấu thầu cho việc bao gồm theo EIP-1559 (nó có thể muốn biết những gì đang diễn ra liên quan đến MEV [Bahrani et al., 2024] 9, nhưng chúng ta sẽ xem xét vấn đề này là một vấn đề riêng biệt vào lúc này). Ở cấp độ bó, chi phí phụ trội của bó không còn tuyến tính theo số giao dịch, mà nó có thể được phân bổ cho nhiều giao dịch. Hơn nữa, nếu chi phí tổng hợp các hoạt động người dùng không tuyến tính theo số lượng giao dịch (ví dụ: một số chứng minh có hiệu quả không tuyến tính với kích thước đang được chứng minh), cung cấp khả năng phân bổ chi phí tổng hợp trên nhiều người dùng.

Điều này dẫn đến trò chơi sau: Người gói muốn người dùng đặt giá như thể họ đang đấu giá cho trường hợp tồi nhất, khi người dùng đơn độc trong gói và phải tự đền bù toàn bộ gas F chi phí. Thực tế, người dùng sẽ đối mặt với vấn đề cần thiết lập ba tham số liên quan trong hoạt động của họ:

• op.maxPriorityFeePerGas và op.maxFeePerGas có thể được đặt theo các heuristics mà người dùng sẽ sử dụng theo EIP-1559, tức là, dựa trên một lượng gas dự đoán mà hoạt động của họ sẽ tiêu thụ, người dùng sẽ đặt các thuộc tính này để hiệu chỉnh số tiền mà họ sẵn lòng trả trong trường hợp xấu nhất (maxFee) và số tiền mà họ sẵn lòng bổ sung để trả cho nhà sản xuất khối cuối cùng (maxPriority). Nhưng người dùng nên ước lượng gas như thế nào?
• op.preVerificationGas là một thuộc tính của UserOperation mà phải được thiết lập để chỉ ra số lượng 'gas phụ' mà hoạt động của người dùng dự định tiêu thụ. Trong mô hình của chúng tôi, chúng tôi để
• F đại diện cho “chi phí cố định cho khí đầu ra”. Nếu có n người dùng được bao gồm trong gói, mỗi người dùng nên đặt preVerificationGas = F / n. Tuy nhiên, nếu người dùng chuẩn bị thực hiện hoạt động của họ với tình huống xấu nhất trong tâm trí, họ sẽ đặt preVerificationGas = F.

preVerificationGas sau đó là vector chính thông qua đó người dùng điều chỉnh lượt đặt giá của họ và cố gắng tính toán chi phí phần trả góp bởi người gói. Giả sử có n người dùng đến thị trường với các hoạt động của họ, và tất cả đều bị thuyết phục bởi người gói để đặt giá trong trường hợp tồi tệ nhất là ở một mình trong gói. Chúng ta cũng sẽ giả sử rằng người dùng đang đặt maxPriorityFeePerGas của họ thành không cho ví dụ này. Sau đó, những người dùng này đều đang đặt preVerificationGas = F, và người gói có thể tạo ra một gói trả công cho họ với:

trong khi họ phải chịu một khoản chi phí:

khi họ công bố gói gói tất cả n thao tác lại với nhau trong một khối. Điều này mang lại lợi nhuận cho người đóng gói π = (n−1)×F×r.

Tình hình này có thể được biểu diễn bằng một trò chơi hai giai đoạn, trong đó người dùng đầu tiên thực hiện các hoạt động người dùng của họ, và người gói sau đó quyết định gói chúng. Chúng tôi giả định rằng người dùng không có thông tin về số lượng người dùng chờ xử lý hiện tại, và do đó không thể ước lượng khả năng thực sự của người gói để phân phối chi phí cố định của họ.

Trong giai đoạn đầu tiên, người dùng gửi các hoạt động của họ, mà cam kết với các thuộc tính của họ như preVerificationGas. Trong giai đoạn thứ hai, bundler sau khi nhận được tất cả các giao dịch của người dùng quyết định đưa ra một gói hoặc một tập hợp các gói. Thú vị là ngay cả khi người dùng biết có bao nhiêu người dùng khác sẽ tham gia vào giai đoạn đầu tiên, tức là ngay cả khi n là thông tin chung cho tất cả người dùng, bundler có thể ép buộc người dùng đặt preVerificationGas trong trường hợp tồi nhất là F bằng cách đe dọa tham gia.

, tức là đe dọa giữ mỗi người dùng trong gói riêng của họ và tính họ số lượng gas tối đa F.

Lưu ý rằng mối đe dọa này có thể không đáng tin cậy, vì người dùng sẽ mong đợi người gói sẽ ưu tiên chơi

, tức là đầu ra một bóng duy nhất với tất cả các hoạt động bao gồm ở đó, thực hiện π. Tuy nhiên, người dùng có thể không có quyền truy cập vào giá trị thực sự của n, và do đó họ không thể thiết lập preVerificationGas của họ một cách mà buộc người đóng gói lý tưởng phải gói tất cả chúng.

Trường hợp lý tưởng: chi phí được phân chia giữa những người dùng trong gói. Trường hợp bi quan: người dùng trả quá nhiều và chi phí không được chia.731×755 77.6 KB

Một phần mở rộng của mô hình này có thể xem xét trường hợp Bayesian, trong đó người dùng có quyền truy cập vào một phân phối trên n, tức là họ có thể dự đoán một biến ngẫu nhiên n người dùng xuất hiện tại bất kỳ bước thời gian nào, theo một phân phối nào đó (ví dụ, sự xuất hiện của Poisson), ngay cả khi họ không biết trước kết quả của biến ngẫu nhiên. Điều này có thể dẫn đến kết quả không hiệu quả, như ví dụ dưới đây cho thấy:

Alice mong đợi 9 người dùng khác sẽ xuất hiện ngoài chính cô, và vì vậy cô đặt preVerificationGas của mình thành 1 vì cô biết F = 10. Giá trị của Alice và giá trị của tất cả người dùng khác tương thích với việc họ đặt preVerificationGas = 3, nhưng cô ấy cố gắng trả ít nhất có thể cho việc bao gồm cô ấy. Nhưng như thế, chỉ có 5 người dùng xuất hiện trên thị trường, họ cũng đều đặt preVerificationGas của họ thành 1. Người gói sẽ không được bồi thường cho F = 10 đơn vị gas, do đó người gói không tạo ra một bản gói và người dùng nhận được 0 tiện ích. Điều này rõ ràng không hiệu quả, vì người dùng có thể đã đặt preVerificationGas = 2 ví dụ và nhận được 1 tiện ích (preVerificationGas tối đa mà họ sẵn lòng đặt trừ đi preVerificationGas thực tế họ trả để được bao gồm).

Công việc tương lai

Như trò chơi bundler cho thấy, người dùng muốn được bao gồm bởi bundler đối mặt với vấn đề phân bổ. Trong ghi chú tiếp theo, chúng tôi sẽ đề cập đến các phương pháp khác nhau để khôi phục "trải nghiệm người dùng tốt" để ngăn họ trả quá nhiều cho một bundler hiểu biết tốt hơn về nhu cầu cho khả năng gói của nó. Sự khám phá tiếp theo sẽ đòi hỏi sự hiểu biết về cấu trúc thị trường liên kết người dùng, bundlers và builders/block producers với nhau.

Thông báo:

1. Bài viết này được in lại từ [ethresear], Tất cả bản quyền thuộc về tác giả gốc [DavideRezzoli}Đối với những để xuất bản này, nếu có đối đề, vui lòng liên hệ Gate Learnđội ngũ và họ sẽ xử lý nhanh chóng.
2. Tuyên bố từ chối trách nhiệm: Các quan điểm và ý kiến được trình bày trong bài viết này chỉ 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 nhóm Gate Learn. Trừ khi có ghi chú, việc sao chép, phân phối hoặc đạo văn các bài viết dịch là cấm.