Giới thiệu

Trong bài viết trước đó của chúng tôi bài viết 15, chúng tôi giới thiệu mô hình ERC-4337. Mô hình này chỉ ra cấu trúc thị trường phí cho người đóng gói và chi tiết về hàm chi phí liên quan đến chi phí xuất bản trên chuỗi và chi phí ngoại chuỗi (chi phí tổng hợp) của một gói.

Chúng tôi cũng giới thiệu khái niệm của "Bundler Game". Trò chơi này sẽ là trọng tâm chính của phần hai. Với một tập hợp các giao dịch, một bundler có thể chọn các giao dịch nào sẽ được bao gồm trong gói của họ. Điều này tạo ra một bất đối xứng thông tin giữa bundlers và người dùng, vì người dùng không biết có bao nhiêu giao dịch sẽ được bao gồm trong gói. Điều này dẫn đến một trò chơi zero-sum, trong đó người dùng ở trong tình trạng thiệt hại rõ ràng.

Nghiên cứu này nhằm khám phá các phương pháp để cải thiện trải nghiệm người dùng bằng cách đảm bảo rằng người dùng không cần phải trả quá nhiều để được bao gồm trong gói tiếp theo. Thay vào đó, người dùng nên có thể trả một khoản phí dựa trên nhu cầu thị trường thực tế để được bao gồm.

Tình hình hiện tại của ERC-4337

Trong thị trường hiện nay, P2P mempool không hoạt động trên mainnet và đang được thử nghiệm trên testnet Sepolia. Các công ty xây dựng trên ERC-4337 hiện đang hoạt động ở chế độ riêng tư, người dùng kết nối qua RPC với một người gói riêng tư sẽ sau đó làm việc với một người xây dựng để xuất bản useroperation của bạn trên chuỗi.Ứng dụng Bundle Bear 3, doanh nghiệp phát triển bởi Kofi, cung cấp một số thống kê hấp dẫn về tình trạng hiện tại của ERC-4337.

Trong Gói Bundles 1 Multi-UserOp hàng tuần %theo hệ thống mét, chúng tôi quan sát phần trăm các bundler tạo ra gói bao gồm nhiều userops. Từ đầu năm 2024 đến tháng 6 năm 2024, phần trăm này không vượt quá 6,6%. Dữ liệu này trở nên thú vị hơn khi xem xét rằng nhiều bundler còn chạy paymasters của riêng mình, các thực thể tài trợ giao dịch thay mặt người dùng. Đáng chú ý, hai bundler lớn nhất cũng hoạt động như paymaster, theo số lượng hoạt động người dùng công bố,sponsored 97% 1về các hoạt động của người dùng sử dụng dịch vụ của họ. Người thanh toán trả tiền cho một số phần của hoạt động của người dùng và phần còn lại được trả bởi các ứng dụng phi tập trung hoặc khácthực thể 1.

Câu hỏi đặt ra là tại sao người thanh toán, dApps, v.v., đang thanh toán cho các hoạt động của người dùng. Liệu người dùng có trả lại cho họ trong tương lai không? Chúng ta không thể chắc chắn điều gì sẽ xảy ra, nhưng dự đoán cá nhân của tôi là hiện tại, các dApps đang chi trả phí để tăng sử dụng và sự áp dụng của ứng dụng của họ. Khi sự áp dụng cao, người dùng có lẽ sẽ phải trả tiền cho các giao dịch của họ. Đáng chú ý rằng để người dùng trả tiền cho một hoạt động của người dùng với mô hình hiện tại không phải là lựa chọn tốt nhất, vì một hoạt động ERC-4337 cơ bản tốn khoảng ~42.000 gas, trong khi một giao dịch bình thường tốn khoảng ~21.000 gas.

Biến thể trên ERC-4337

Tổng quan về ERC-4337

The mempool is still in a testing phase on Sepolia and is not live on the mainnet. Without the mempool, users have limited options for using account abstraction. Users interact with an RPC, which may be offered by a bundler that bundles UserOps, or with an RPC service that doesn’t bundle, similar to services like Alchemy or Infura, which receive and propaGate transactions to other bundlers.

Khi mempool được triển khai, luồng giao dịch sẽ giống như sơ đồ dưới đây, tương tự luồng giao dịch hiện tại. Mempool cải thiện khả năng chống kiểm duyệt cho người dùng bởi vì, khác với mô hình RPC, nó giảm khả năng một giao dịch bị loại bỏ. Tuy nhiên, ngay cả với mempool, vẫn có rủi ro là nhà cung cấp RPC có thể không chuyển tiếp giao dịch, nhưng mô hình mempool đặc biệt hữu ích cho người dùng muốn chạy nút riêng của họ, vì nó giảm rủi ro này.

Mặc dù các gói có tiềm năng hoạt động như những người xây dựng, chúng tôi muốn giữ các vai trò riêng biệt do bối cảnh cạnh tranh. Bundlers sẽ phải đối mặt với sự cạnh tranh đáng kể từ các nhà xây dựng tinh vi, hiện có, làm cho việc xây dựng kém hấp dẫn hơn và có khả năng ít lợi nhuận hơn. Do đó, các gói được khuyến khích hợp tác với các nhà xây dựng đã thành lập hơn là xây dựng độc lập và có nguy cơ thua lỗ.

Kết hợp vai trò của bundler và builder thành một thực thể duy nhất đòi hỏi các thay đổi đáng kể đối với hệ thống hiện tại. Bundlers sẽ cần phải cạnh tranh với các [Gate] hiện có.nhà thầu tinh vi, hoặc có thể là các nhà xây dựng hiện tại sẽ cần tích hợp theo chiều ngang và đảm nhận vai trò người gói cũng như. Kịch bản sau, mặc dù có vẻ khả thi hơn, nhưng đặt ra những lo ngại về tập trung thị trường và tiềm năng ảnh hưởng tiêu cực đến khả năng chống kiểm duyệt.

Bundlers và builders là hai thực thể khác nhau

Với người dùng kết nối trực tiếp đến RPC, mọi thứ chạy trong một môi trường riêng tư hơn, điều đó không giúp đỡ cho sự cạnh tranh trên thị trường. Trong tương lai gần, mempool sẽ được đưa lên mainnet tăng cường sự cạnh tranh.

Sử dụng mempool, trong đó userops được công khai cho các gói khác nhau làm tăng tính cạnh tranh, trong trường hợp trừu tượng hóa tài khoản không phải bản địa cần có sự tách biệt giữa bundler và builder, trong trường hợp trừu tượng hóa tài khoản gốc, việc tách biệt có thể không cần thiết vì trình tạo có thể diễn giải userops như các giao dịch bình thường.

Điều này có thể dẫn đến kết quả sau: Trong môi trường cạnh tranh, các gói sẽ giảm giá của họ để được lựa chọn bởi người dùng, những người sẽ lần lượt tìm kiếm mức giá thấp nhất để đưa hoạt động người dùng của họ vào một gói. Cuộc thi này sẽ tạo ra một hệ thống trong đó người đóng gói cung cấp giá tốt nhất sẽ được chọn thường xuyên hơn so với người đóng gói chỉ cố gắng tối đa hóa lợi nhuận của họ bằng cách tạo các gói nhỏ hơn. Tách biệt vai trò của bundler và builder cũng có thể tăng cường khả năng chống kiểm duyệt. Một bundler có thể tạo một gói các hoạt động người dùng tổng hợp và gửi nó đến các nhà xây dựng khác nhau. Nếu gói bao gồm các hoạt động có thể bị kiểm duyệt, một người xây dựng không kiểm duyệt có thể chấp nhận nó và tiến hành xây dựng. Tuy nhiên, điều đáng chú ý là từ quan điểm của người dùng, thiết lập này có thể làm tăng chi phí, vì việc giới thiệu gói bổ sung thêm một bên, dẫn đến chi phí cao hơn.

RIP-7560

Trừu tượng tài khoản bản địa không phải là một khái niệm mới; nó đã được nghiên cứu từ nhiều năm trước. Trong khi ERC-4337 đang được chú ý, việc triển khai nó bên ngoài giao thức mang lại những lợi ích đặc biệt cùng với những đánh đổi. Đáng chú ý, các EOA hiện có không thể chuyển tiếp mượt mà sang SCWs, và việc sử dụng các loại danh sách kháng kiểm duyệt khác nhau khó hơn. Như đã đề cập trước đó, chi phí gas của một userOp tăng đáng kể so với giao dịch bình thường.RIP-7560 2không tự nhiên giải quyết vấn đề liên quan đến chi phí ngoại khối, nhưng nó giảm đáng kể chi phí giao dịch. Từ ~42000 gas ban đầu, có thể giảm chi phí bằng~20000 gas.

Layer2s Account Abstraction

Trừu tượng hóa tài khoản có thể được sử dụng trong các giải pháp Lớp 2 (L2). Một số L2 đã triển khai nó một cách nguyên bản, trong khi những người khác tuân theo phương pháp L1 và đang chờ đợi một đề xuất mới tương tự RIP-7560. Trong L2, L1 được sử dụng cho khả năng sẵn có của dữ liệu để kế thừa bảo mật, trong khi hầu hết các tính toán xảy ra ngoài chuỗi trên L2, cung cấp các giao dịch rẻ hơn và có khả năng mở rộng.

Trong các tình huống khi tính toán trên L2 rẻ hơn đáng kể so với chi phí của calldata cho sẵn dữ liệu (DA) trên mainchain, việc sử dụng tổng hợp chữ ký rất có lợi. Ví dụ, việc kết hợp cho BLS trên mainnet được tạo điều kiện bởi 0x08 1precompile từ EVM, mất khoảng ~45000k gas. Do đó, việc sử dụng BLS trên L1 đắt hơn giao dịch truyền thống.

Các kỹ thuật nén trên L2 đã được sử dụng, chẳng hạn như nén 0 byte, giúp giảm chi phí từ ~ 188 byte xuống ~ 154 byte cho việc truyền ERC20. Với tổng hợp chữ ký, hiệu quả nén có thể được tăng cường hơn nữa bằng cách sử dụng một chữ ký duy nhất, giảm kích thước xuống ~ 128 byte.

Trong Layer 2, việc tổng hợp chữ ký là một đổi mới quan trọng, giúp cải thiện cả hiệu suất giao dịch và hiệu quả chi phí. Bằng cách kết hợp nhiều chữ ký thành một chữ ký duy nhất, lượng dữ liệu tổng thể được giảm đáng kể, từ đó giảm chi phí liên quan đến khả năng truy cập dữ liệu trên Layer 1. Sự tiến bộ này không chỉ cải thiện khả năng mở rộng mà còn giảm chi phí giao dịch cho người dùng, làm cho hệ thống trở nên kinh tế và hiệu quả hơn.

Kinh tế Tập hợp Chữ ký trong Layer2s

Khi sử dụng dịch vụ L2, người dùng phải chịu một số chi phí, bao gồm phí cho người vận hành L2, chi phí dựa trên tình trạng tắc nghẽn mạng lưới, và chi phí của việc sẵn có dữ liệu trên L1.

Từ một nghiên cứu trước đó vềHiểu về kinh tế cuộn từ nguyên lý cơ bản”, chúng tôi có thể phác thảo các chi phí mà người dùng phải đối mặt khi sử dụng dịch vụ L2 như sau:

Khi người dùng tương tác với một lớp 2, anh ta có một số chi phí mà chúng ta có thể xác định như sau:

• Phí người dùng = Phí xuất bản dữ liệu L1 + Phí của nhà điều hành L2 + Phí tắc nghẽn L2
• Chi phí của nhà điều hành = Chi phí của nhà điều hành L2 + Chi phí xuất bản dữ liệu L1
• Doanh thu của nhà điều hành = Phí người dùng + MEV
• Lợi nhuận của Nhà điều hành = Doanh thu của Nhà điều hành - Chi phí của Nhà điều hành = Phí tắc đường L2 + MEV

Trong trường hợp trừu tượng hóa tài khoản không bản địa, một thực thể bổ sung, người gói, có thể giới thiệu một khoản phí cho việc tạo các gói các hoạt động của người dùng.

Xét đến người đóng gói, chi phí và lợi nhuận được mở rộng như sau:

• Phí người dùng = phí xuất bản dữ liệu L1 + phí nhà điều hành L2 + phí tắc nghẽn L2 + Phí Bundler
• Chi phí của Bundler = Quoted (Phí xuất bản dữ liệu L1 + Phí của nhà điều hành L2 + Phí tắc nghẽn L2)
• Doanh thu Bundler = Phí người dùng
• Lợi nhuận của người đóng gói = Doanh thu của người đóng gói - Chi phí của người đóng gói = Sự khác biệt giữa chi phí L1 và L2 và giá trích dẫn từ người đóng gói + Phí của người đóng gói
• Chi phí của người vận hành = Phí xuất bản dữ liệu L1 + Phí của người vận hành L2
• Lợi nhuận của người điều hành = Doanh thu của người điều hành - Chi phí của người điều hành = Phí tắc đường L2 + MEV

Bundler kiếm phí từ người dùng cho dịch vụ của họ, trong khi phần còn lại của khoản thanh toán của người dùng bao gồm chi phí của nhà điều hành L2. Nếu người dùng không biết về kích thước gói, ước lượng chi phí thực tế của việc gửi userops trở nên khó khăn, có thể dẫn đến bundler tính phí cao hơn so với mức cần thiết để bù đắp chi phí của nhà điều hành.

Điều chỉnh động lực trong L2

Sự tương tác giữa người gói và L2 giúp giải quyết vấn đề này, vì L2 được động viên để giữ chi phí người dùng thấp do cạnh tranh. Quá tải người dùng có thể khiến họ chuyển sang các L2 khác cung cấp giá cả công bằng hơn.

Hãy định nghĩa lại mô hình của chúng ta bằng cách giới thiệu toán tử. Người dùng đặt giá cho bundler để được bao gồm trong khối L2 tiếp theo bằng cách đặt giá trị V. Người dùng nhằm mục tiêu giảm thiểu phí xuất bản dữ liệu, trong khi bundler tìm cách tối đa hóa phí hoặc có được một lợi tức từ chi phí tương tác L2 và phí người dùng.

Các chi phí liên quan đến việc tạo một gói và xuất bản nó trên chuỗi có thể được chia thành hai phần:

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

Hàm chi phí tổng hợp: Người gói có một hàm chi phí để tổng hợp n giao dịch trong một bundle B với phí cơ bản là r:

với S' F, bao gồm việc xuất bản và xác minh chữ ký đã tổng hợp trên chuỗi.

Nếu người dùng có thể có được ước tính đáng tin cậy cho n, họ có thể tính toán chi phí của mình bằng cách sử dụng hàm estimateGas, có sẵn trong hầu hết các giải pháp L2. Có một ước tính tốt có thể làm cho người dùng đặt giá thầu phù hợp mà không phải đánh giá quá cao giá thầu của họ để đưa vào. Chức năng này xác định chi phí cần thiết để đảm bảo bao gồm. Có một ước tính tốt cho n và hàm estimateGas có thể tránh cho người dùng phải trả tiền cho preVerificationGas cao hơn. Trong phần tiếp theo, chúng ta sẽ khám phá các cơ chế khác nhau để đảm bảo ước tính đáng tin cậy về n.

Layer2s hoạt động như một bộ truy vấn

Vai trò của oracle là giám sát mempool và ước tính số lượng giao dịch hiện có. Quá trình hoạt động như sau: Layer 2 triển khai một oracle để kiểm tra mempool và sau đó thông báo cho người dùng về số lượng giao dịch trong mempool. Điều này cho phép người dùng ước tính giá đặt chào của mình để được bao gồm trong một gói. Layer 2 có thể yêu cầu bundler bao gồm ít nhất một số giao dịch được chỉ định (n) trong một gói, nếu không thì gói sẽ bị từ chối. Khi bundler thu thập đủ giao dịch để tạo thành một gói, nó gửi gói đó đến Layer 2, sau đó Layer 2 chuyển tiếp nó đến mainnet như là calldata để có sẵn dữ liệu.

Đề xuất theo dõi 691×642 47.4 KB

Layer2s với bộ xếp hàng chia sẻ

Một cách tiếp cận thú vị là có nhiều mạng Layer 2 (L2) chạy trên một sequencer chia sẻ. Thiết lập này có thể cung cấp một ước lượng chính xác hơn về mempool, khi sequencer đạt được một thỏa thuận thông qua sự đồng thuận được tạo bởi sequencer chia sẻ.

Trong cấu hình này, các mạng L2 khác nhau hoạt động độc lập nhưng chia sẻ một sequencer chung. Định kỳ, các mạng này kiểm tra số lượng hoạt động của người dùng (userops) trong shared mempool. Sequencer chung giúp đồng bộ và tổng hợp dữ liệu từ các mạng này. Sau khi đạt được thỏa thuận, thông tin được truyền đến người dùng, cho phép họ đấu giá dựa trên số lượng userops hiện có.

Phương pháp này mang lại một số lợi ích. Thứ nhất, nó cung cấp một phương pháp phi tập trung để xác định số lượng userops trong mempool, nâng cao khả năng chống đối phó. Thứ hai, nó loại bỏ điểm lỗi duy nhất có thể xảy ra nếu chỉ có một hệ thống quản lý giao tiếp giữa người dùng và mempool. Thứ ba, sequencer chia sẻ đảm bảo tính nhất quán và giảm sai biệt giữa các giải pháp L2 khác nhau.

Bằng cách tận dụng bộ xử lý chung, phương pháp này đảm bảo một hệ thống mạnh mẽ và đáng tin cậy để ước lượng và truyền thông trạng thái của mempool cho người dùng, từ đó cải thiện hiệu quả và an ninh tổng thể của quy trình.

Shared Sequencer764×785 66.3 KB

Trong hai phương pháp được giải thích bằng cách sử dụng trình giám sát, có một vector tấn công tiềm năng khi kẻ thù có thể tạo ra nhiều hoạt động người dùng trong mempool, biết rằng chúng sẽ quay trở lại nếu được tổng hợp lại. Kết quả là, trình giám sát thấy rằng có

n

giao dịch và yêu cầu một bó lớn, nhưng người gói không thể tạo bó. Vấn đề này có thể làm đình trệ mạng lưới trong nhiều khối.

Layer2s hoạt động với bundler riêng của họ

Trong đề xuất này, bản thân Lớp 2 đảm nhận vai trò của gói, trong khi một thực thể khác xử lý việc tổng hợp chữ ký (đây có thể là các dịch vụ gói hiện tại). Quá trình này hoạt động như sau: Lớp 2 vận hành gói riêng của nó và người dùng gửi các hoạt động của họ (userops) đến mempool. Lớp 2 chọn một số userops này từ mempool và gửi chúng "thô" đến trình tổng hợp, bù đắp cho trình tổng hợp để tổng hợp các chữ ký. Khi trình tổng hợp tạo ra gói, nó sẽ gửi nó đến bundler, sau đó chuyển tiếp nó đến mạng chính dưới dạng calldata cho tính khả dụng của dữ liệu.

Ý tưởng chính là Lớp 2 xử lý việc thu thập userops và sau đó giao việc tổng hợp cho một thực thể khác. Lớp 2 thanh toán cho việc tổng hợp và thu phí từ người dùng cho dịch vụ.

Có hai tùy chọn khác nhau:

1. Mô hình Phí cố định: Người gói hàng (Sequencer) chọn một số giao dịch và tính phí cố định cho người dùng. Phí cố định này được tính tương tự như các giao dịch Layer 2 hiện tại, dự đoán chi phí tương lai của việc xuất bản dữ liệu L1. Hoặc Layer 2 có thể tính phí cố định cho người dùng dựa trên chi phí gói hàng n
2. tổng hợp userops, layer 2 vẫn phải dự đoán có bao nhiêu giao dịch sẽ có mặt trong bundle mà anh ta sẽ contruct để trích dẫn chính xác người dùng, điều này có thể được thực hiện theo cách tương tự như bây giờ là nơi . Vì bây giờ l2 tính giá tốt nhất cho người dùng rằng lợi ích tốt nhất của Lớp 2 là giữ giá cạnh tranh nhất có thể cho người dùng.
   
3. Phí cố định 671×702 22.1 KB
4. Yêu cầu hoàn tiền: Nếu Lớp 2 muốn tăng tính đáng tin cậy của mình, nó có thể kích hoạt hoàn tiền tự động. Điều này sẽ liên quan đến một cơ chế kiểm tra xem có bao nhiêu userops được xuất bản trong một khối duy nhất và xem liệu giao dịch có thể đã được tổng hợp hay không. Nếu một userop có thể đã được tổng hợp mà không, và không có hoàn tiền tự động được phát hành, người dùng có thể yêu cầu hoàn tiền. Trong kịch bản này, Lớp 2 có thể đặt cược một số tài sản, và nếu không có hoàn tiền, người dùng có thể bắt buộc hoàn tiền, đảm bảo sự công bằng và trách nhiệm.
   
5. Yêu cầu hoàn tiền671×702 22.8 KB

Kết luận

Trong hai bài đăng khác nhau này, chúng tôi chỉ ra những khó khăn mà người dùng gặp phải khi đấu giá để được bao gồm trong gói tiếp theo. Trong phần đầu tiên, chúng tôi trình bày mô hình ERC-4337, giải thích các chi phí mà người đóng gói phải chịu khi đăng một gói trên chuỗi và các chi phí ngoại chuỗi liên quan. Chúng tôi cũng đề cập đến thị trường phí cho người đóng gói và bắt đầu thảo luận về vấn đề định dạng người đóng gói. Người dùng gặp khó khăn khi đấu giá do thiếu kiến thức về số lượng giao dịch hiện có trong mempool tại thời điểm đóng gói.

Trong phần thứ hai, chúng tôi đã giải thích ERC-4337 và RIP-7560. Sau đó, chúng tôi đã thảo luận vì sao việc tổng hợp chữ ký có khả năng xảy ra hơn trên các giải pháp Layer 2 thay vì trực tiếp trên Layer 1. Chúng tôi đã minh họa cách các giải pháp Layer 2 có thể giải quyết sự không cân đối của kiến thức mà người dùng trải qua theo các cách khác nhau. Cách đầu tiên là sử dụng oracles để báo hiệu cho người dùng biết có bao nhiêu giao dịch hiện có trong mempool, với cách tiếp cận này, người dùng biết họ nên đặt giá bao nhiêu và có thể ép buộc người gói gói gói lớn hơn. Cách tiếp cận thứ ba, đơn giản nhất, là L2 hoạt động như một người gói và giao việc tổng hợp cho một bên thứ ba và để người dùng trả phí cho nó.

Bản phủ định:

1. Bài viết này được sao chép từ [GateEthresearChuyển tiếp Tiêu đề ban đầu ‘Thị trường phí nhúng và ERC-4337 (phần 2)’, Bản quyền thuộc về tác giả gốc [ DavideRezzoli & Barnabé Monnot ]. Nếu có ý kiến ​​phản đối về việc tái in này, vui lòng liên hệ với Gate Learnđội và họ sẽ xử lý ngay lập tức.

2. Tuyên bố Miễn trừ trách nhiệm: Các quan điểm và ý kiến được đưa ra trong bài viết này chỉ là quan điểm của tác giả và không đại diện cho 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 đề 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à không được phép.