bởi: Davide Rezzoli ( @DavideRezzoli ) và Barnabé Monnot ( @barnabe )
Xin chân thành cảm ơn Yoav Weiss ( @yoavw ) đã giới thiệu vấn đề này cho chúng tôi, Dror Tirosh @drortirosh đã đưa ra những bình luận hữu ích về bản thảo và nhóm 4337 đã hỗ trợ. Đánh giá ≠ xác nhận; tất cả lỗi đều là của tác giả.
Công việc này được thực hiện cho ROP-7 .
Giới thiệu
Trong bài đăng trước, chúng tôi đã giới thiệu mô hình Yêu cầu bình luận Ethereum (ERC)-4337. Mô hình này phác thảo cấu trúc thị trường phí cho các bundler và trình bày chi tiết hàm chi phí liên quan đến chi phí xuất bản on-chain và chi phí Ngoài chuỗi (chi phí tổng hợp) của một bundle.
Chúng tôi cũng giới thiệu khái niệm “ Trò chơi Bundler ”. Trò chơi này sẽ là trọng tâm chính của phần thứ hai. Với một tập hợp các giao dịch, một bundler có thể chọn giao dịch nào để đưa vào bundle của họ. Điều này tạo ra sự bất đối xứng về thông tin giữa người đóng gói và người dùng, vì người dùng không biết có bao nhiêu giao dịch sẽ được đưa vào gói. Điều này dẫn đến một trò chơi tổng bằng không, trong đó người dùng rõ ràng là ở thế bất lợi.
Nghiên cứu này nhằm mục đích khám phá các phương pháp cải thiện UX bằng cách đảm bảo rằng người dùng không cần phải trả quá nhiều tiền để được đưa vào gói tiếp theo. Thay vào đó, người dùng sẽ có thể trả phí dựa trên nhu cầu thực tế của thị trường để được đưa vào.
Trạng thái hiện tại của Yêu cầu bình luận Ethereum (ERC)-4337
Trên thị trường hiện nay, mempool P2P 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 Yêu cầu bình luận Ethereum (ERC)-4337 hiện đang hoạt động ở chế độ riêng tư, người dùng kết nối qua RPC đến một bundler riêng tư sau đó sẽ hoạt động với một trình xây dựng để xuất bản hoạt động người dùng của bạn trên chuỗi. Ứng dụng Bundle Bear , do Kofi phát triển, cung cấp một số số liệu thống kê thú vị về trạng thái hiện tại của Yêu cầu bình luận Ethereum (ERC)-4337.
Trong số liệu % Gói nhiều người dùng hàng tuần , chúng tôi quan sát tỷ lệ phần trăm các bundler tạo các bundle bao gồm nhiều userop. Từ đầu năm 2024 đến tháng 6 năm 2024, tỷ lệ 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 điều hành paymaster của riêng họ, các thực thể tài trợ cho các giao dịch thay mặt cho người dùng. Đáng chú ý, hai bundler lớn nhất cũng hoạt động như một paymaster, xét về các hoạt động của người dùng đã công bố, đã tài trợ cho 97% các hoạt động của người dùng sử dụng dịch vụ của họ. Paymaster trả tiền cho một số phần hoạt động của người dùng và phần còn lại được thanh toán bởi Các ứng dụng phi tập trung (DAPPS) hoặc tổ chức khác.
Câu hỏi đặt ra là tại sao các nhà thanh toán, Các ứng dụng phi tập trung (DAPPS), ETC, lại trả tiền cho các hoạt động của người dùng. Liệu người dùng có trả tiền 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 theo tôi đoán thì hiện tại, Các ứng dụng phi tập trung (DAPPS) đang trang trải các khoản phí để tăng mức sử dụng và áp dụng các ứng dụng của họ. Khi mức áp dụng cao, người dùng có thể sẽ phải tự trả tiền cho các giao dịch. Điều đáng nói là việc 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 Yêu cầu bình luận Ethereum (ERC)-4337 cơ bản có giá khoảng 42.000 gas, trong khi một giao dịch thông thường có giá khoảng 21.000 gas.
Các biến thể của Yêu cầu bình luận Ethereum (ERC)-4337
Tổng quan về Yêu cầu bình luận Ethereum (ERC)-4337
Mempool vẫn đang trong giai đoạn thử nghiệm trên Sepolia và chưa có trên mainnet. Nếu không có mempool, người dùng có các tùy chọn hạn chế để sử dụng Account Abstraction. Người dùng tương tác với RPC, có thể được cung cấp bởi một bundler đóng gói UserOps hoặc với một dịch vụ RPC không đóng gói, tương tự như các dịch vụ như Alchemy hoặc Infura, nhận và truyền bá các giao dịch đến các trình đóng gói khác.
Khi mempool hoạt động, luồng giao dịch sẽ giống với sơ đồ bên dưới, tương tự như luồng giao dịch hiện tại. Mempool tăng cường khả năng chống kiểm duyệt cho người dùng vì, không giống như mô hình RPC, nó làm giảm khả năng giao dịch bị loại trừ. 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 có lợi cho những người dùng thích chạy các nút của riêng họ vì nó giảm thiểu rủi ro này.
Trong khi bundler 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ò tách biệt do bối cảnh cạnh tranh. Bundler sẽ phải đối mặt với sự cạnh tranh đáng kể từ những người xây dựng hiện tại, tinh vi, khiến việc xây dựng trở nên kém hấp dẫn hơn và có khả năng ít lợi nhuận hơn. Do đó, bundler có nhiều được khuyến khích hợp tác với các nhà xây dựng có uy tín thay vì tự xây dựng và chịu rủi ro thua lỗ.
Việc kết hợp các vai trò của bundler và builder thành một thực thể duy nhất ngụ ý những thay đổi đáng kể đối với hệ thống hiện tại. Bundler sẽ cần phải cạnh tranh với các builder tinh vi hiện có hoặc ngược lại, các builder hiện tại sẽ cần phải tích hợp theo chiều ngang và đảm nhận luôn vai trò bundler. Kịch bản sau , mặc dù có vẻ hợp lý hơn, nhưng lại làm dấy lên mối lo ngại về sự tập trung thị trường và tác động tiêu cực tiềm tàng đế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 với RPC, mọi thứ chạy trong môi trường riêng tư hơn, điều này không giúp ích cho sự cạnh tranh trên thị trường. Trong tương lai gần, mempool sẽ có mặt trên mạng chính, làm tăng tính cạnh tranh.
Sử dụng mempool, trong đó userops là công khai cho các bundler khác nhau làm tăng tính cạnh tranh, trong trường hợp Account Abstraction không phải gốc, cần có sự tách biệt giữa bundler và builder, trong trường hợp Account Abstraction gốc, sự tách biệt có thể không cần thiết vì builder có thể diễn giải userops như các giao dịch bình thường.
Đối với mô hình của chúng tôi, chúng tôi tin rằng việc tách biệt giữa bundler và builder cũng mang lại một số lợi thế, đặc biệt là về mặt cạnh tranh và khả năng chống kiểm duyệt. Hãy tưởng tượng một kịch bản mà tất cả các bundler đều đưa ra chi phí \textbf{v} v để được đưa vào gói của họ. Sẽ có một bundler muốn thu hút nhiều người dùng hơn để đạt được lợi nhuận cao hơn, vì vậy họ sẽ đưa ra chi phí \textbf{v'} v' trong đó \textbf{v'} < \textbf{v} v' < v với đủ sự cạnh tranh giữa các bundler, \textbf{v'} v' sẽ tiến gần đến \omega ω , chi phí tổng hợp cho bundle. Trong trường hợp này, các bundler có thể tìm kiếm hiệu quả hơn và có phần cứng tốt hơn để bao gồm nhiều giao dịch hơn trong một Gói dịch vụ này sẽ thu được mức phí cao hơn và đổi lại, chi phí sử dụng của người dùng sẽ rẻ hơn.
Điều này có thể dẫn đến kết quả sau: Trong môi trường cạnh tranh , các nhà đóng gói sẽ hạ giá để được người dùng lựa chọn, những người này sẽ 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. Sự cạnh tranh này sẽ tạo ra một hệ thống trong đó bundler đưa ra mức giá tốt nhất sẽ được chọn thường xuyên hơn bundler chỉ cố gắng tối đa hóa lợi nhuận của họ bằng cách tạo ra các bundle nhỏ hơn. Việc 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 ra một bundle của các hoạt động người dùng tổng hợp và gửi đế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 nhà xây dựng không kiểm duyệt có thể chấp nhận và tiến hành xây dựng. Tuy nhiên, cần lưu ý rằng theo 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 đưa thêm một bên tham gia vào sẽ làm tăng thêm chi phí.
RIP-7560
Account Abstraction gốc không phải là một khái niệm mới; nó đã được nghiên cứu trong nhiều năm. Trong khi Yêu cầu bình luận Ethereum (ERC)-4337 đang thu hút sự chú ý, việc triển khai nó bên ngoài giao thức mang lại những lợi thế riêng biệt cùng với những đánh đổi. Đáng chú ý là các EOA hiện tại không thể chuyển đổi liền mạch sang SCW, và nhiều loại danh sách chống kiểm duyệt khó sử dụng hơn. Như đã đề cập trước đó, chi phí gas của chi phí userOp tăng đáng kể so với giao dịch thông thường. RIP-7560 sẽ không giải quyết được vấn đề đang diễn ra liên quan đến chi phí Ngoài chuỗi , nhưng nó làm giảm đáng kể chi phí giao dịch. Từ mức ban đầu ~42000 gas, có thể giảm chi phí xuống ~20000 gas .
Account Abstraction Layer2s
Có thể sử dụng Account Abstraction trong các giải pháp Layer 2 (L2). Một số L2 đã triển khai nó một cách tự nhiên, trong khi những L2 khác tuân theo cách tiếp cận L1 và đang chờ đề xuất mới tương tự như RIP-7560. Trong L2, L1 được sử dụng để dữ liệu có sẵn thừa hưởng tính bảo mật, trong khi hầu hết các tính toán diễn ra Ngoài chuỗi trên L2, cung cấp các giao dịch rẻ hơn và khả năng mở rộng.
Trong các tình huống mà tính toán trên L2 rẻ hơn đáng kể so với chi phí calldata cho tính khả dụng của dữ liệu (DA) trên Mainchain, việc sử dụng tổng hợp chữ ký tỏ ra rất có lợi. Ví dụ, việc ghép nối cho BLS trên mainnet được tạo điều kiện thuận lợi bởi biên dịch trước 0x08 từ Máy ảo Ethereum (EVM), có giá khoảng ~45000k gas. Do đó, sử dụng BLS trên L1 đắt hơn so với các 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 một lần chuyể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 còn ~128 byte.
Trong Lớp 2, tổng hợp chữ ký là một cải tiến quan trọng giúp tăng cường cả hiệu quả giao dịch và hiệu quả về chi phí. Bằng cách kết hợp nhiều chữ ký thành một chữ ký duy nhất, tổng tải dữ liệu được giảm đáng kể, giúp giảm chi phí liên quan đến tính khả dụng của dữ liệu trên Layer 1. Điều này Sự tiến bộ 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, giúp hệ thống tiết kiệm và hiệu quả hơn.
Kinh tế tổng hợp chữ ký trong Layer2
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 nhà điều hành L2, chi phí dựa trên tình trạng tắc nghẽn mạng và chi phí dữ liệu khả dụng trên L1.
Từ một nghiên cứu trước đây về “ Hiểu về kinh tế rollup từ những nguyên tắc đầu tiên ”, chúng ta 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 Layer 2, họ sẽ phải chịu một số chi phí mà chúng ta có thể xác định như sau:
- Phí sử dụng = Phí công bố dữ liệu L1 + Phí vận hành L2 + Phí tắc nghẽn L2
- Chi phí vận hành = Chi phí vận hành L2 + Chi phí công bố dữ liệu L1
- Doanh thu của nhà điều hành = Phí sử 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 nghẽn L2 + MEV
Trong trường hợp Account Abstraction không phải gốc, một thực thể bổ sung, bên đóng gói, có thể đưa ra mức phí để tạo các gói userops.
Xét về người đóng gói, chi phí và lợi nhuận được mở rộng như sau:
- Phí sử dụng = Phí công bố dữ liệu L1 + Phí vận hành L2 + Phí tắc nghẽn L2 + Phí Bundler
- Chi phí Bundler = Báo giá (Phí công bố dữ liệu L1 + Phí vận hành L2 + Phí tắc nghẽn L2)
- Doanh thu của Bundler = Phí người dùng
- Lợi nhuận của bên đóng gói = Doanh thu của bên đóng gói - Chi phí của bên đóng gói = Chênh lệch giữa chi phí L1 và L2 và giá được báo từ bên đóng gói + Phí của bên đóng gói
- Chi phí vận hành = Phí công bố dữ liệu L1 + Phí vận hành L2
- 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 nghẽn L2 + MEV
Người đóng gói kiếm được phí từ người dùng cho các 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 sẽ trang trải chi phí của nhà điều hành L2. Nếu người dùng không biết về quy mô gói, việc ước tính chi phí thực tế để gửi userops trở nên khó khăn, có khả năng dẫn đến việc người đóng gói tính phí cao hơn mức cần thiết để trang trải chi phí vận hành.
Căn chỉnh khuyến khích trong L2
Sự tương tác giữa bundler và L2 giúp giải quyết vấn đề này, vì L2 được khuyến khích giữ chi phí người dùng ở mức thấp do cạnh tranh. Việc tính phí quá cao cho người dùng có thể khiến họ chuyển sang các L2 khác cung cấp mức giá 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 đấu thầu với bundler để đưa vào Block L2 tiếp theo bằng cách đấu thầu giá trị V V . Người dùng muốn giảm thiểu phí công bố dữ liệu, trong khi bundler muốn tối đa hóa phí của họ hoặc đạt được thặng dư từ chi phí tương tác L2 và phí người dùng.
Chi phí liên quan đến việc tạo một gói và xuất bản nó on-chain có thể được chia thành hai phần:
Hàm chi phí on-chain : Một bundler phát hành bundle \mathbf{B} B khi phí cơ sở là r r chi phí:
Hàm chi phí tổng hợp: Bộ đóng gói có hàm chi phí để tổng hợp n n giao dịch trong một gói \mathbf{B} B với phí cơ sở là r r :
với S' < S S ′ < S là kích thước giao dịch được giảm bớt và sử dụng gas xác minh trước F' > F F ′ > F , bao gồm việc công bố và xác minh chữ ký tổng hợp duy nhất on-chain .
Nếu người dùng có thể có được ước tính đáng tin cậy cho n 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ể khiến người dùng đặt giá thầu phù hợp mà không phải ước tính quá cao giá thầu của họ để đưa vào. Hàm 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 n và hàm estimateGas có thể giúp người dùng tránh 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 của n n .
Layer2 vận hành một oracle
Vai trò của oracle là giám sát mempool và ước tính số lượng giao dịch hiện có. Quy trình hoạt động như sau: Layer 2 triển khai 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á thầu của họ để đưa vào một bó. Layer 2 có thể yêu cầu bundler đưa ít nhất một số lượng giao dịch nhất định ( n n ) vào một bó, nếu không thì bó sẽ bị từ chối. Khi bundler thu thập đủ giao dịch để hình thành một bó, nó sẽ gửi bó đó đến Layer 2, sau đó chuyển tiếp bó đó đến mạng chính dưới dạng calldata để dữ liệu có sẵn.
Layer2s với trình sắp xếp được chia sẻ
Một cách tiếp cận thú vị là có nhiều mạng Layer 2 (L2) chạy một trình sắp xếp chung. Thiết lập này có thể cung cấp ước tính chính xác hơn về mempool, vì trình sắp xếp đạt được thỏa thuận thông qua Consensus được tạo điều kiện bởi trình sắp xếp chung.
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 trình sắp xếp chung. Theo các khoảng thời gian đều đặn, các mạng này kiểm tra số lượng hoạt động của người dùng (userops) trong mempool được chia sẻ. Trình sắp xếp chung giúp đồng bộ hóa và tổng hợp dữ liệu từ các mạng này. Khi chúng đạt đến theo thỏa thuận, thông tin sẽ được truyền đạt tới người dùng, cho phép họ đặt giá thầu dựa trên số lượng userops hiện có.
Cách tiếp cận này mang lại một số lợi thế. Đầu tiên, nó cung cấp một phương pháp phi tập trung để xác định số lượng userops trong mempool, tăng cường khả năng chống lại sự thông đồng. 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, trình tự được chia sẻ đảm bảo tính nhất quán và giảm sự khác biệt giữa các giải pháp L2 khác nhau.
Bằng cách tận dụng trình sắp xếp được chia sẻ, phương pháp này đảm bảo một hệ thống mạnh mẽ và đáng tin cậy để ước tính và truyền đạt trạng thái của mempool cho người dùng, do đó cải thiện hiệu quả và tính bảo mật tổng thể của quy trình.
Trong hai cách tiếp cận được giải thích bằng cách sử dụng oracle, có một vector tấn công tiềm ẩn mà kẻ tấn công có thể tạo ra nhiều hoạt động của người dùng trong mempool, biết rằng chúng sẽ hoàn nguyên nếu được tổng hợp lại với nhau. Do đó, oracle thấy rằng có n n giao dịch và yêu cầu một bó lớn, nhưng bundler không thể tạo bó. Sự cố này có thể làm mạng bị đình trệ trong nhiều khối.
Layer2 vận hành bundler riêng của chúng
Trong đề xuất này, bản thân Layer 2 đảm nhận vai trò của bundler, trong khi một thực thể khác xử lý việc tổng hợp các chữ ký (đây có thể là các dịch vụ bundler hiện tại). Quy trình hoạt động như sau: Layer 2 vận hành bundler của riêng mình và người dùng gửi hoạt động (userops) vào mempool. Layer 2 chọn một số userops này từ mempool và gửi chúng "thô" đến aggregator, đền bù cho aggregator vì đã tổng hợp các chữ ký. Sau khi aggregator tạo ra bundle, nó sẽ gửi bundler , sau đó chuyển tiếp dữ liệu này đến mạng chính dưới dạng calldata để dữ liệu có sẵn.
Ý tưởng chính là Layer 2 xử lý việc thu thập userops và sau đó thuê ngoài việc tổng hợp cho một thực thể khác. Layer 2 trả tiền cho việc tổng hợp và tính phí người dùng cho dịch vụ.
Có hai lựa chọn khác nhau:
Mô hình phí cố định: Bộ đóng gói (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í trong tương lai của việc xuất bản dữ liệu L1. Ngoài ra, Layer 2 có thể tính phí người dùng một khoản phí cố định dựa trên chi phí đóng gói n n userops tổng hợp, Layer 2 vẫn phải dự đoán có bao nhiêu giao dịch sẽ có trong gói mà anh ta sẽ xây dựng để báo giá chính xác cho người dùng, điều này có thể được thực hiện theo cùng một cách như bây giờ là nơi Vì hiện tại, L2 tính mức giá cạnh tranh nhất cho người dùng nên việc giữ mức giá cạnh tranh nhất có thể cho người dùng là vì lợi ích tốt nhất của Lớp 2.
Phí cố định 671×702 22,1 KBYêu cầu hoàn tiền: Nếu Layer 2 muốn tăng cường độ tin cậy của mình, nó có thể cho phép hoàn tiền tự động. Điều này sẽ liên quan đến một cơ chế kiểm tra số lượng userop được công bố trong một Block duy nhất và liệu các 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 không và không có khoản hoàn tiền tự động nào được phát hành, người dùng có thể yêu cầu hoàn tiền. Trong trường hợp này, Layer 2 có thể Stake một số tài sản và nếu khoản hoàn tiền không được cung cấp, người dùng có thể thực thi việc hoàn tiền, đảm bảo tính công bằng và trách nhiệm giải trình.
Yêu cầu hoàn tiền 671×702 22,8 KB
Phần kết luận
Trong hai bài đăng khác nhau này, chúng tôi phác thảo những khó khăn mà người dùng gặp phải khi đấu thầu để được đưa vào gói tiếp theo. Trong phần đầu tiên, chúng tôi đã trình bày mô hình Yêu cầu bình luận Ethereum (ERC)-4337, giải thích chi phí mà người đóng gói phải chịu khi đăng một gói on-chain và chi phí liên quan Ngoài chuỗi . Chúng tôi cũng đã phác thảo các thị trường phí cho các bundler và bắt đầu thảo luận về vấn đề định dạng bundler. Người dùng gặp khó khăn khi đấu thầu do thiếu hiểu biết về số lượng giao dịch có trong mempool tại thời điểm bundler.
Trong phần thứ hai, chúng tôi đã giải thích Yêu cầu bình luận Ethereum (ERC)-4337 và RIP-7560. Sau đó, chúng tôi thảo luận lý do tại sao tổng hợp chữ ký có nhiều khả năng xảy ra trên các giải pháp Layer 2 hơn là trực tiếp trên Layer 1. Chúng tôi đã chứng minh cách các giải pháp Layer 2 có thể giải quyết kiến thức không đối xứng mà người dùng trải nghiệm theo nhiều 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 trong mempool, với cách tiếp cận này, người dùng biết họ nên trả giá bao nhiêu và có thể buộc bundler tạo ra các bundle lớn hơn. Cách tiếp cận thứ ba Cách đơn giản nhất là L2 hoạt động như một đơn vị đóng gói và thuê ngoài việc tổng hợp cho một bên thứ ba và để người dùng trả một khoản phí cho việc đó.
