Bài viết của Lin Oshitani (Nethermind Research) và Ulysse Pavloff (Đại học Bern).
Xin cảm ơn Conor , Ahmad , Gustavo , Daniel , David và Yuewang vì những cuộc thảo luận và/hoặc đánh giá.
Công trình này được tài trợ bởi Taiko như một phần của quan hệ đối tác chiến lược Taiko<>Nethermind .
Tóm lại
Việc định giá chi phí ghi nhận L1 trên L2 có thể được xem như một bài toán kiểm soát : một kho lưu trữ theo dõi sự khác biệt tích lũy giữa doanh thu phí L2 và chi phí ghi nhận L1, và phí L2 là đòn bẩy kiểm soát giúp giữ cân bằng kho lưu trữ này. Sử dụng mô phỏng dựa trên dữ liệu phí cơ sở/phí khối L1 trong quá khứ, chúng tôi so sánh các công thức tính phí và thiết kế bộ điều khiển khác nhau để định giá chi phí L1 trên L2.
Giới thiệu
Khái niệm trừu tượng về kho phí
Việc định giá chi phí đăng bài L1 trên L2 có thể được hiểu thông qua một khái niệm trừu tượng cốt lõi: một kho tiền (vault). Mỗi giao dịch L2 đều trả một khoản phí được chuyển vào kho tiền, và mỗi khi L2 đăng dữ liệu hoặc bằng chứng lên L1, chi phí sẽ được chuyển ra khỏi kho tiền. Số dư trong kho tiền tại bất kỳ thời điểm nào phản ánh sự khác biệt tích lũy giữa doanh thu L2 thu được và chi phí L1 phát sinh. Trên thực tế, kho tiền có thể là một hợp đồng thông minh trên L2 tích lũy phí L2 và theo dõi chi phí đăng bài thực tế trên L1 khi chúng được báo cáo từ L1 — xem Ghi chú triển khai để biết cách hoạt động này.
Trong khuôn khổ này, một kho lưu trữ lành mạnh — không có thâm hụt hoặc thặng dư kéo dài — có nghĩa là doanh thu phí L2 và chi phí đăng tải L1 duy trì ở mức cân bằng tương đối theo thời gian. Thâm hụt kho lưu trữ có nghĩa là các bộ điều phối đang ngầm trợ cấp chi phí đăng tải L1; thặng dư kho lưu trữ có nghĩa là người gửi giao dịch bị tính phí quá cao một cách có hệ thống. Do đó, sự sai lệch so với mục tiêu của kho lưu trữ cung cấp một thước đo tự nhiên để đánh giá các cơ chế tính phí. Chúng tôi sử dụng thuật ngữ "sức khỏe kho lưu trữ" để thể hiện sự cân bằng này; một mô tả chính xác hơn được đưa ra trong phần " Điều gì tạo nên một cơ chế tính phí tốt?" .
Giao thức L2 trực tiếp kiểm soát phí L2 mà nó tính cho người dùng. Bằng cách điều chỉnh phí này, giao thức có thể tác động đến số dư trong kho tiền: tăng phí sẽ làm tăng dòng tiền vào (đẩy số dư kho tiền lên), và giảm phí sẽ làm giảm dòng tiền vào (làm cho số dư kho tiền giảm dần). Mục tiêu tự nhiên là thiết lập phí sao cho kho tiền bám sát mục tiêu của nó theo thời gian, phản ứng với những thay đổi về chi phí L1 và nhu cầu L2, đồng thời giữ cho sự biến động của phí đủ thấp để người dùng có thể dự đoán được chi phí giao dịch.
Khung lý thuyết này — một hệ thống với trạng thái có thể đo lường được (số dư trong kho), mục tiêu (mục tiêu kho) và đầu vào có thể điều chỉnh (phí L2) — là một thiết lập lý thuyết điều khiển điển hình trong sách giáo khoa.
Kho phí (hoặc nhóm phí ) ban đầu được giới thiệu bởi Arbitrum trong bài đăng về Nhóm phí của họ. Bài đăng này mở rộng ý tưởng Nhóm phí của Arbitrum theo một số cách:
- Định giá phí khung L2 như một bài toán lý thuyết điều khiển tổng quát.
- Đưa ra một thuật ngữ phản hồi tích cực để tạo điều kiện cho một lý thuyết thống nhất về các cơ chế phí L2 chính, từ OP stack đến Arbitrum.
- Hãy xem xét vấn đề này trong bối cảnh hệ thống điều khiển trình tự phân tán.
- Sử dụng mô phỏng dựa trên dữ liệu L1 lịch sử để so sánh các thiết kế bộ điều khiển.
- Hãy lập tài liệu và phân tích bộ điều khiển định giá L1 của Arbitrum Nitro, một thiết kế chưa được mô tả chi tiết ở những nơi khác, và so sánh nó với các phương pháp tiếp cận khác trong mô phỏng.
Ví dụ tương tự trong lý thuyết điều khiển: Bộ điều nhiệt
Một ví dụ kinh điển trong lý thuyết điều khiển là bộ điều nhiệt: căn phòng có nhiệt độ hiện tại (trạng thái đo được), nhiệt độ mong muốn (mục tiêu), bộ phận gia nhiệt có công suất có thể điều chỉnh (đầu vào điều khiển), và các yếu tố bên ngoài như thời tiết hoặc cửa sổ mở (nhiễu). Bộ điều khiển đọc nhiệt độ, tính toán độ chênh lệch so với mục tiêu, và điều chỉnh công suất gia nhiệt để thu hẹp khoảng cách đó.
Tóm lại, đối với bộ điều nhiệt:
- Trạng thái đo được → nhiệt độ phòng
- Mục tiêu → nhiệt độ mong muốn (ví dụ: 22°C)
- Đầu vào điều khiển → đầu ra bộ gia nhiệt
- Sự nhiễu loạn → thời tiết, mở cửa sổ, v.v.
Bộ điều khiển cơ bản chỉ phản ứng với sự chênh lệch giữa trạng thái đo được và trạng thái mục tiêu; nó chờ cho đến khi lỗi xuất hiện trước khi hiệu chỉnh. Đây là phản hồi : nó phản ứng với tác động của nhiễu loạn sau khi nhiễu loạn đã ảnh hưởng đến hệ thống. Ví dụ như bộ điều nhiệt:
- Phản hồi → Đo nhiệt độ phòng và điều chỉnh máy sưởi dựa trên sự chênh lệch so với nhiệt độ mục tiêu.
Ngược lại, một thành phần phản hồi tiến (feedforward term) phản ứng trực tiếp với nguyên nhân gây nhiễu, trước khi tác động lan truyền khắp hệ thống. Ví dụ đối với bộ điều nhiệt:
- Phản hồi dự báo → Cảm biến nhiệt độ ngoài trời hoặc tham khảo dự báo thời tiết để điều chỉnh công suất máy sưởi một cách chủ động.
Ánh xạ tới Kho phí
Kho chứa phí được ánh xạ trực tiếp lên cấu trúc này:
- Trạng thái đo được → số dư kho tiền
- Mục tiêu → mục tiêu kho tiền
- Đầu vào điều khiển → Phí L2
- Sự cố → Biến động phí cơ sở/khối lượng L1, sự thay đổi nhu cầu L2
Bộ điều khiển kho phí có thể sử dụng cả phản hồi và dự báo:
- Phản hồi → Quan sát số dư trong kho tiền và điều chỉnh phí L2 dựa trên khoảng cách chênh lệch so với số dư mục tiêu.
- Phản hồi tích cực → Quan sát phí cơ bản L1 và phí blob hiện tại rồi tính toán trực tiếp vào phí L2, thay vì chờ số dư trong kho giảm xuống trước.
Trên thực tế, trong khuôn khổ này, các cơ chế phí L2 thông thường được sử dụng bởi các chuỗi như Optimism có thể được xem là các thiết kế chỉ dựa trên cơ chế truyền tiến . Các hệ thống này ước tính chi phí đăng tải L1 cho mỗi giao dịch bằng cách sử dụng phí cơ sở L1 và phí cơ sở blob được quan sát tại thời điểm sắp xếp thứ tự và tính phí người dùng tương ứng. Nói cách khác, chúng định giá dữ liệu L1 dựa trên ước tính được thực hiện tại thời điểm sắp xếp thứ tự, chứ không phải chi phí đăng tải thực tế khi lô dữ liệu được đề xuất. Mặt khác, chúng không duy trì kho lưu trữ hoặc phản ứng với thặng dư hoặc thiếu hụt tích lũy. Về mặt lý thuyết điều khiển, chúng chuyển trực tiếp sự nhiễu loạn (chi phí L1) vào phí thông qua điều khoản truyền tiến, mà không theo dõi chi phí thực tế trong kho lưu trữ hoặc sử dụng phản hồi từ trạng thái kho lưu trữ.
Khung phản hồi + phản hồi tiến này có thể được xem như một khung thống nhất bao trùm tất cả các chiến lược phí L2 chính để thu hồi chi phí L1 . Phản hồi tiến thuần túy (tính phí cho mỗi giao dịch bằng chi phí L1 tại thời điểm sắp xếp trình tự), phản hồi thuần túy (phí chỉ dựa trên thâm hụt kho tiền) và các thiết kế lai đều là những trường hợp cụ thể trong khung này.
Lưu ý về bộ giải trình tự phân tán
Cơ chế khóa an toàn với điều khiển phản hồi đặc biệt phù hợp với các thiết bị cuộn có nhiều bộ điều khiển trình tự xoay, chẳng hạn như của Taiko , vì ba lý do.
- Nó phản ứng với sự thay đổi về nhu cầu, không chỉ là sự thay đổi chi phí L1. Các thiết kế chỉ dựa trên cơ chế phản hồi tiến (feedforward) sẽ không nhận biết được sự thay đổi về nhu cầu ở phía L2. Nếu nhu cầu giảm, số lượng giao dịch sẽ ít hơn để bù đắp cho cùng một chi phí ghi nhận cố định, âm thầm làm giảm số dư, nhưng cơ chế phản hồi tiến sẽ không nhận ra điều này. Một bộ điều phối tập trung có thể giảm thiểu điều này bằng cách chờ cho đến khi một lô giao dịch đầy đủ trước khi ghi nhận, do đó giữ cho nhu cầu phần lớn không đổi. Các bộ điều phối xoay vòng không có được sự linh hoạt đó: mỗi bộ có một khoảng thời gian giới hạn và phải ghi nhận trước một thời hạn, vì vậy nếu nhu cầu thấp trong khoảng thời gian đó, chúng sẽ ghi nhận một lô nhỏ hơn với chi phí L1 gần như tương đương, điều này làm tăng đột biến chi phí cho mỗi giao dịch. Kho tiền ghi nhận điều này, vì sự thay đổi về nhu cầu thể hiện dưới dạng sự thay đổi dòng tiền vào — điều này thể hiện dưới dạng tình trạng sức khỏe của kho tiền bị suy giảm — và bộ điều khiển sẽ điều chỉnh phí cho phù hợp.
- Nó có thể làm giảm bớt sự tăng đột biến chi phí L1 trên các sequencer. Nếu không có quỹ dự phòng, mỗi sequencer sẽ phải chịu bất kỳ chi phí L1 nào phát sinh trong slot của mình. Nếu một sequencer bị ảnh hưởng bởi sự tăng đột biến phí cơ bản, họ sẽ phải chịu toàn bộ chi phí. Với quỹ dự phòng, giao thức có thể hoàn trả cho các sequencer từ quỹ chung, do đó sự tăng đột biến chi phí L1 được làm giảm bớt theo thời gian thay vì chỉ dồn lên một sequencer không may mắn. Điều này đòi hỏi các biện pháp bảo vệ chống lại việc đăng bài thiếu thận trọng của các sequencer không chịu toàn bộ chi phí; xem [Q1] Làm thế nào để ngăn chặn việc đăng bài thiếu thận trọng trong quá trình hoàn trả? để biết chi tiết. Điều này làm cho kinh tế của sequencer trở nên dễ dự đoán hơn và khuyến khích sự tham gia ngay cả trong điều kiện L1 biến động.
- Nó cho phép khôi phục các đề xuất bị bỏ lỡ một cách có tính khuyến khích. Giả sử một trình sắp xếp bỏ lỡ thời gian đăng lên L1. Nếu không có kho lưu trữ, các lựa chọn là hoặc lô bị bỏ lỡ sẽ kích hoạt việc sắp xếp lại L2 (trải nghiệm người dùng kém) hoặc một trình sắp xếp khác sẽ khôi phục nó bằng chi phí của riêng họ mà không có bồi thường (khuyến khích kém). Một kho lưu trữ dùng chung giải quyết vấn đề này, vì trình sắp xếp tiếp theo có thể "khôi phục" lô bị bỏ lỡ bằng cách đăng nó cùng với lô của chính mình và thu phần chi phí L1 từ doanh thu phí của lô được khôi phục như một khoản bồi thường.
Cơ chế thu phí tốt được thiết kế như thế nào?
Trước khi so sánh các công thức tính phí cụ thể, điều đáng lưu ý là cần nêu rõ chúng ta mong muốn điều gì từ chúng. Chúng ta đánh giá các cơ chế dựa trên hai khía cạnh: tình trạng an toàn của kho tiền và sự biến động phí .
- Sức khỏe của kho bạc đo lường mức độ hiệu quả của cơ chế trong việc duy trì sự cân bằng của kho bạc gần mục tiêu theo thời gian. Một cơ chế hoạt động tốt ở khía cạnh này nếu nó tránh được tình trạng thâm hụt sâu hoặc kéo dài và nhanh chóng quay trở lại mục tiêu sau một cú sốc chi phí. Một cơ chế hoạt động kém nếu kho bạc lệch khỏi mục tiêu trong thời gian dài hoặc dao động mà không ổn định.
- Biến động phí đo lường mức độ thay đổi đột ngột của phí L2 từ góc nhìn của người dùng. Những biến động lớn hoặc thường xuyên khiến phí trở nên khó dự đoán hơn, ngay cả khi mức trung bình dài hạn không thay đổi.
Những mục tiêu này đương nhiên mâu thuẫn với nhau. Các cơ chế phản ứng mạnh mẽ để giữ cho quỹ gần mục tiêu có xu hướng truyền các cú sốc trực tiếp hơn đến người dùng, làm tăng sự biến động phí. Các cơ chế làm giảm sự biến động phí cho người dùng có xu hướng hấp thụ các cú sốc trong quỹ, điều này có thể dẫn đến sự sai lệch sâu hơn hoặc kéo dài hơn so với mục tiêu. Các thiết kế được nghiên cứu dưới đây nằm ở các điểm khác nhau dọc theo sự đánh đổi này.
Cần nhấn mạnh rằng trong các thiết kế chỉ dựa trên cơ chế truyền tiến (feedforward), kho tiền được hiểu rõ nhất như một sự trừu tượng hóa kế toán: nó theo dõi sự khác biệt tích lũy giữa doanh thu phí và chi phí ghi nhận giao dịch L1 thực tế. Trong các thiết kế dựa trên cơ chế phản hồi (feedback), số dư kho tiền trở thành một phần của tín hiệu điều khiển được sử dụng để thiết lập phí và có thể tương ứng với một hợp đồng trên chuỗi được quy định rõ ràng.
Mô tả công thức tính phí
Thiết lập bài toán
Với khung lý thuyết điều khiển như vậy, câu hỏi thiết kế trọng tâm là: phí L2 nên được cập nhật chính xác như thế nào dựa trên số dư kho tiền hiện tại và chi phí L1 quan sát được? Các câu trả lời khác nhau cho câu hỏi này dẫn đến các thiết kế bộ điều khiển khác nhau. Các bộ điều khiển được nghiên cứu trong bài báo này được xây dựng từ hai thành phần khác biệt về mặt khái niệm.
Đầu tiên là thuật ngữ phản hồi tiến (FF) : một ước tính trực tiếp về chi phí đăng bài L1 hiện tại, được suy ra từ phí cơ sở L1 và phí khối dữ liệu quan sát được tại thời điểm sắp xếp trình tự. FF hoàn toàn không sử dụng trạng thái kho lưu trữ, nó định giá "sự nhiễu loạn" trước khi nó tác động vào kho lưu trữ.
Thứ hai là một nhóm các điều khoản phản hồi , giúp điều chỉnh khoảng cách giữa số dư trong kho tiền và mục tiêu của nó:
- P (tỷ lệ thuận): phản ứng với mức thiếu hụt hiện tại
epsilon(t) - I (tích phân): phản ứng với sự thiếu hụt tích lũy theo thời gian
- D (đạo hàm): phản ứng với tốc độ thay đổi của thâm hụt.
Các thuật ngữ FF và phản hồi không cùng bản chất: FF là dự đoán, trong khi P/I/D là hiệu chỉnh. Tuy nhiên, chúng vẫn có thể được coi là các khối xây dựng mô-đun: bộ điều khiển có thể sử dụng chúng riêng lẻ, kết hợp một số trong số chúng, hoặc kết hợp các thuật ngữ truyền tiến và phản hồi. Các cơ chế được nghiên cứu ở đây là các kết hợp minh họa trong không gian thiết kế rộng hơn này: chỉ FF, chỉ P, PI (tỷ lệ + tích phân), P+FF, và bộ điều khiển kiểu Arbitrum, được hiểu rõ nhất là PD (tỷ lệ + đạo hàm).
Các giả định và phạm vi:
- Nhu cầu không co giãn. Chúng tôi coi nhu cầu là không co giãn trong suốt quá trình — với một mức phí tối đa nhất định, phí cao hơn luôn làm tăng dòng tiền vào kho bạc. Nếu nhu cầu co giãn, các bộ điều khiển có thể trở nên không ổn định: việc tăng phí khiến người dùng rời bỏ sẽ làm trầm trọng thêm thâm hụt thay vì bù đắp. Xem [Q3] Điều gì xảy ra nếu phí quá cao và khiến người dùng rời bỏ? để biết các biện pháp giảm thiểu.
- Bài viết này chỉ tập trung vào chi phí L1 trong phí L2. Định giá tắc nghẽn L2 (điều chỉnh phí dựa trên mức sử dụng khối L2) là một vấn đề riêng biệt có thể được xem xét độc lập, vì định giá tắc nghẽn phản ứng với mức sử dụng L2 trong khi bộ điều khiển kho lưu trữ phản ứng với khoảng cách chi phí L1.
- Phương pháp hạch toán dữ liệu trừu tượng cho mỗi giao dịch. Trên thực tế, phần chi phí ghi sổ L1 của mỗi giao dịch phụ thuộc vào lượng dữ liệu mà nó đóng góp vào lô dữ liệu đang được ghi sổ. Trong bài viết này, chúng ta sẽ bỏ qua phương pháp hạch toán dữ liệu trừu tượng cho mỗi giao dịch và coi
F(t)như một khoản phí trên mỗi đơn vị dữ liệu.
Ký hiệu
Các biến số phổ biến:
-
t: bước thời gian hiện tại (tức là dấu thời gian của khối) -
F(t): phí L2 được tính tại thời điểmt(đầu ra của bộ điều khiển) -
V(t): giá trị kho tiền tại thời điểmt -
V_target: giá trị kho lưu trữ mục tiêu -
delay: độ trễ quan sát trong các khối L1 (theo thuật ngữ Taiko, độ trễ neo — khoảng cách mà khối L1 đang được neo hiện tại chậm hơn so với khối L1 đầu mới nhất) -
epsilon(t): tỷ lệ thiếu hụt được chuẩn hóa tại thời điểmt, được định nghĩa là(V_target - V(t - delay)) / V_target -
F_min: phí tối thiểu được phép -
F_max: phí tối đa được phép -
FeeRange: phạm vi phí, được định nghĩa làF_max - F_min -
clamp(x, lo, hi): giới hạnxtrong phạm vi[lo, hi]— nếuxnhỏ hơnlothì trả vềlo, nếu lớn hơnhithì trả vềhi, nếu không thì trả về chínhx.
Thiết lập mô phỏng
Tất cả các mô phỏng trong bài đăng này đều dựa trên dữ liệu phí cơ bản của mạng chính Ethereum và phí cơ bản của blob trong 365 ngày (từ 06/02/2025 đến 06/02/2026), được hiển thị bên dưới:
Cửa sổ này bao gồm một đợt tăng đột biến phí blob đáng chú ý xung quanh khối L1 22389679 , điều này có thể hữu ích khi phóng to để so sánh cách các cơ chế phí khác nhau phản ứng với các đợt tăng đột biến:
Các thông số mô phỏng chính:
- Tần suất đăng dữ liệu: cứ sau 10 khối L1
- L2 TPS: 1 tx/s
- Mục tiêu Vault: 10 ETH
- Mức phí: 0,01–1 Gwei
Các tham số này được lựa chọn sao cho phản ánh thực tế và mang tính minh họa một cách tổng quát, chứ không phải được hiệu chỉnh cho một triển khai cụ thể. Dữ liệu phí L1 và mô phỏng bộ điều khiển có thể được khám phá một cách tương tác trong giao diện người dùng của trình mô phỏng này.
Chỉ truyền tiến (FF-only)
Phương pháp chỉ sử dụng điều khiển tiến (feedforward-only) là phương pháp được triển khai rộng rãi nhất hiện nay, và được Optimism cùng các nhà cung cấp dịch vụ L2 lớn khác sử dụng. Ý tưởng là ước tính chi phí đăng bài ở cấp độ L1 tại thời điểm sắp xếp thứ tự và tính phí trực tiếp cho người dùng, không cần kho lưu trữ hay vòng phản hồi. Về mặt lý thuyết điều khiển, đây là điều khiển tiến thuần túy : bộ điều khiển quan sát chi phí (nhiễu) ở cấp độ L1 và tính phí đó vào giá trước khi nó trở thành chi phí đăng bài thực tế.
Công thức như sau:
-
BaseFee(t),BlobFee(t): phí cơ sở thực thi L1 và phí cơ sở blob tại thời điểmt. -
alpha_gas,alpha_blob: các trọng số tỷ lệ chuyển đổi chi phí gas L1 và blob thành phần chia sẻ trên mỗi giao dịch L2.
FF ( t ) = alpha_gas * BaseFee ( t - delay ) + alpha_blob * BlobFee ( t - delay ) F ( t ) = FF ( t ) Tham số delay ở đây phản ánh sự đánh đổi giữa độ tin cậy và độ trễ. Các chuỗi có bộ điều phối đáng tin cậy (như Optimism) có thể đẩy phí cơ sở L1 và phí blob mới nhất vào L2 thông qua một oracle, hoạt động hiệu quả với delay ≈ 0 Một giải pháp thay thế không cần tin cậy là nhập trạng thái L1 thông qua đường dẫn nhắn tin L1→L2 gốc của chuỗi (ví dụ: giao dịch neo của Taiko hoặc hộp thư đến bị trì hoãn của Arbitrum), điều này tránh được giả định về độ tin cậy của oracle nhưng lại tạo ra độ trễ quan sát vài khối L1.
Mô phỏng & Phân tích
Mặc dù FF-only không sử dụng kho tiền làm đầu vào, chúng tôi vẫn theo dõi số dư kho tiền ngầm định trong mô phỏng như một chỉ số đánh giá. Kết quả như sau (có thể xem tương tác thông qua giao diện người dùng tại đây ):
Ưu điểm/nhược điểm của phương pháp này là:
Ưu điểm:
- Kho tiền theo dõi mục tiêu của nó khá tốt trong những khoảng thời gian mà phí có thể điều chỉnh — tức là, khi phí không bị giới hạn ở mức tối đa.
Nhược điểm:
- Việc chỉ sử dụng FF cũng khiến người dùng L2 trực tiếp chịu ảnh hưởng bởi sự biến động phí L1. Mặc dù trong bài viết này, chúng ta giả định nhu cầu không co giãn để đơn giản hóa, nhưng các đợt tăng phí không liên quan đến nhu cầu L2 có thể ảnh hưởng nặng nề đến người dùng khi mức độ sẵn sàng chi trả không tăng lên, khiến nhu cầu trở nên co giãn hơn và làm tăng nguy cơ tắc nghẽn hoạt động L2 trong các đợt tăng phí L1 (ngược lại với các đợt tăng phí do nhu cầu, nơi mức độ sẵn sàng chi trả thường cao hơn). Xem [Q2] Mức độ tách biệt phí L2 khỏi biến động phí L1 như thế nào? để biết chi tiết về việc có nên và làm thế nào để làm giảm sự biến động này.
- Giá FF-only chỉ hiển thị các điều kiện L1 hiện tại, nhưng không thể sửa chữa các lỗi tích lũy. Những lỗi này chủ yếu phát sinh từ việc cắt
F_maxtrong các đợt tăng đột biến L1 lớn. Sau khi đợt tăng đột biến qua đi, không có phản hồi nào để đẩy giá trị trở lại mục tiêu.
Biểu đồ F_max bên dưới làm rõ hơn sự đánh đổi này ( liên kết mô phỏng ). Việc tăng F_max từ 1 gwei lên 2, 5 và 10 gwei cải thiện đáng kể tình trạng của vault, vì ít xung đột L1 bị cắt hơn và nhiều chi phí đăng bài thực tế được chuyển đến người dùng. Nhưng điều này lại dẫn đến sự biến động phí cao hơn đáng kể:
Bộ điều khiển P (chỉ dành cho P)
Bộ điều khiển P thiết lập phí trực tiếp dựa trên mức thâm hụt hiện tại của kho bạc: kho bạc càng thấp hơn mục tiêu thì phí càng cao, và ngược lại. Sự đánh đổi là nếu kho bạc duy trì ở mức thâm hụt nhỏ kéo dài, bộ điều khiển P sẽ áp dụng cùng một mức điều chỉnh nhỏ vô thời hạn mà không tăng lên, khiến kho bạc vẫn ở mức thấp hơn mục tiêu một chút ( độ lệch trạng thái ổn định ).
-
Kp(tỷ lệ tăng): kiểm soát mức độ phản ứng của phí đối với thâm hụt hiện tại.Kpcàng cao thì mức điều chỉnh càng mạnh trên mỗi đơn vị thâm hụt.
Công thức như sau:
P(t) = Kp * epsilon(t) * FeeRange F ( t ) = clamp(P(t), F_min, F_max)Mô phỏng & Phân tích
Kết quả được hiển thị bên dưới ( liên kết mô phỏng ). Biểu đồ đầu tiên cho thấy phí L2 do bộ điều khiển tính theo thời gian, và biểu đồ thứ hai cho thấy diễn biến số dư trong két sắt. Đường màu đỏ đánh dấu mục tiêu, và đường màu xanh theo dõi giá trị thực tế của két sắt (đường đi xuống cho thấy thâm hụt ngày càng tăng).
Khi phóng to khu vực xung quanh điểm tăng đột biến phí:
Ưu điểm/nhược điểm của phương pháp này là:
Ưu điểm:
- So với chỉ sử dụng FF, bộ điều khiển P mang lại độ biến động phí thấp hơn vì nó phản hồi lại lỗi kho tiền tích lũy thay vì truyền thẳng từng đỉnh chi phí L1.
- Nó có thể khôi phục sức khỏe của kho tiền theo thời gian. Sau một cú sốc, phí sẽ duy trì ở mức cao cho đến khi kho tiền phục hồi, thay vì giảm ngay lập tức sau khi đỉnh L1 qua đi.
Nhược điểm:
- Bộ điều khiển hoạt động hoàn toàn theo phản ứng, đột ngột đến mức cần thời gian để các biến động chi phí L1 đột ngột được phản ánh vào phí L2.
- Nó có một xu hướng ổn định : khi số dư trong két sắt giảm xuống dưới mức mục tiêu một chút, bộ điều khiển có thể điều chỉnh mức phí cao hơn một chút để giữ cho két sắt ở gần mức mục tiêu, nhưng không hoàn toàn đạt đến mức đó.
Sự đánh đổi này đặc biệt rõ ràng xung quanh điểm tăng đột biến phí blob gần khối L1 22389679 , như được hiển thị bên dưới so với chỉ sử dụng FF ( liên kết mô phỏng ). Đường màu xanh lam là chỉ sử dụng P, trong khi đường màu xanh lục là chỉ sử dụng FF, được giới hạn ở mức 1 gwei.
Bộ điều khiển PI
Một cách phổ biến để giải quyết sai lệch trạng thái ổn định của bộ điều khiển P là thêm một số hạng tích phân . Tích phân này tích lũy tín hiệu thiếu hụt theo thời gian, vì vậy nếu mức tạ nằm dưới mục tiêu đủ lâu, bộ điều khiển sẽ áp dụng một sự điều chỉnh ngày càng mạnh hơn cho đến khi loại bỏ được sai lệch.
-
Ki(hệ số tích phân): kiểm soát mức độ tăng phí mạnh mẽ như thế nào khi có sự thiếu hụt kéo dài. -
I_acc(t)(bộ tích lũy tích phân): tổng tích lũy của tín hiệu thiếu hụt. -
I_min,I_max: giới hạn trên trạng thái tích phân (đối với hiện tượng chống chồng chéo ).
Công thức như sau:
I_acc(t) = clamp(I_acc(t -1 ) + epsilon(t), I_min, I_max)P(t) = Kp * epsilon(t) * FeeRange I ( t ) = Ki * I_acc(t) * FeeRange F ( t ) = clamp(P(t) + I(t), F_min, F_max)Mô phỏng & Phân tích
Kết quả được hiển thị bên dưới, màu xanh lam là chỉ sử dụng bộ điều khiển P và màu nâu là sử dụng bộ điều khiển PI.
Và nếu chúng ta xem xét kỹ hơn khung thời gian tăng đột biến phí giao dịch:
Ưu điểm/nhược điểm của bộ điều khiển PI là:
Ưu điểm:
- PI giải quyết sai lệch trạng thái ổn định của bộ điều khiển P: nếu số dư trong két sắt ở dưới mức mục tiêu đủ lâu, thuật ngữ tích phân sẽ tích lũy và đẩy phí lên đủ cao để bù đắp khoảng cách còn lại.
- Sau những giai đoạn thiếu hụt kéo dài, PI có xu hướng phục hồi nhanh hơn P-only, vì thuật ngữ tích phân giữ lại "ký ức" về lỗi dai dẳng.
Nhược điểm:
- Thuật ngữ tích phân có thể gây ra hiện tượng vượt mức: sau khi các điều kiện trở lại bình thường (ví dụ: sau khi đỉnh L1 đi qua), tích phân tích lũy có thể giữ cho phí ở mức cao, tạm thời đẩy mức phí trong kho vượt quá mục tiêu, điều này làm tăng sự biến động phí từ góc nhìn của người dùng.
- PI làm tăng thêm độ phức tạp trong việc điều chỉnh (lựa chọn
Kivà các giới hạn chống bão hòa). Việc điều chỉnh kém có thể gây ra dao động hoặc hội tụ chậm.
P + Phản hồi tiến (P+FF)
P+FF là một ví dụ về việc kết hợp các thành phần điều khiển tiến và phản hồi trong một bộ điều khiển duy nhất. Ở đây, thành phần điều khiển tiến định giá các điều kiện L1 quan sát được vào phí ngay lập tức, trong khi thành phần tỷ lệ vẫn điều chỉnh bất kỳ khoản thiếu hụt nào còn lại trong kho tiền.
FF (t) = alpha_gas * BaseFee (t - delay)+ alpha_blob * BlobFee (t - delay) P (t) = Kp * epsilon (t) * FeeRange // same proportional term as above F (t) = clamp ( FF (t) + P (t), F_min, F_max)Mô phỏng & Phân tích
Cách tốt nhất để đánh giá P+FF là so sánh trực tiếp với P-only tại thời điểm phí blob tăng đột biến, nơi mà sự đánh đổi thể hiện rõ nhất:
Ưu điểm/nhược điểm của phương pháp này là:
Ưu điểm:
- Phương pháp này giúp giữ kho tiền gần mục tiêu hơn so với phương pháp chỉ sử dụng P, vì một phần chi phí L1 dự kiến đã được tính vào giá trước khi chi phí giao dịch thực sự được ghi nhận vào kho tiền.
Nhược điểm:
- Nó truyền tải trực tiếp nhiều biến động L1 hơn đến người dùng, tạo ra biến động phí cao hơn so với P-only.
Trên thực tế, sự cải thiện về sức khỏe của kho tiền so với chỉ sử dụng P trong mô phỏng này là không đáng kể, điều này khiến người ta đặt câu hỏi liệu nó có đáng để chịu thêm sự biến động phí hay không.
Bộ điều khiển kiểu Arbitrum
Các bộ điều khiển nêu trên chỉ phản ứng với vị trí số dư trong kho so với mục tiêu. Bộ điều khiển định giá L1 của Arbitrum Nitro cũng phản ứng với tốc độ và hướng thay đổi của khoảng cách . Ngoài tín hiệu "tỷ lệ thuận", nó còn lấy "đạo hàm" của giá trị kho. Theo nghĩa đó, nó được coi là một bộ điều khiển kiểu PD .
-
F(t): mức phí hiệu quả sau khi cập nhậtt -
U(t): đơn vị dữ liệu được tiêu thụ trong khoảng thời gian đăng bài (trong Nitro: byte dữ liệu cuộc gọi được nén × 16) -
EquilUnits: tầm nhìn cân bằng, tức là cần bao nhiêu đơn vị dữ liệu để xử lý lượng dữ liệu dư thừa hiện tại. Giá trị càng lớn thì quá trình điều chỉnh càng nhẹ nhàng. -
Inertia: xác định điểm giữa của quá trình giảm chấn.InertiaUnits = EquilUnits / Inertialà kích thước khoảng mà tại đó một nửa hiệu chỉnh được áp dụng.
InertiaUnits = EquilUnits / InertiadesiredSlope ( t ) = - S ( t ) / EquilUnitsactualSlope ( t ) = ( S ( t ) - S ( t - 1 ) ) / U ( t ) slopeCorrection ( t ) = desiredSlope ( t ) - actualSlope ( t ) feeChange ( t ) = slopeCorrection ( t ) * U ( t ) / ( InertiaUnits + U ( t ) ) F ( t + 1 ) = max ( 0 , F ( t ) + feeChange ( t ) ) Bộ điều khiển hoạt động dựa trên thặng dư S(t) = V(t) - V_target (lưu ý sự đảo dấu so với thâm hụt epsilon(t) được sử dụng ở trên) và cập nhật phí hiệu quả F(t) một cách tăng dần sau mỗi sự kiện ghi sổ. Dựa trên thặng dư hiện tại, nó tính toán desiredSlope , tốc độ mà thặng dư cần thay đổi để trở về 0 trong phạm vi EquilUnits dữ liệu đã ghi sổ. Khi xảy ra ghi sổ theo lô L1, nó tính toán actualSlope , mức độ thay đổi thực tế của thặng dư trên mỗi đơn vị dữ liệu. Phí được điều chỉnh dựa trên sự chênh lệch: slopeCorrection = desiredSlope - actualSlope .
Tuy nhiên, actualSlope có nhiều nhiễu, đặc biệt khi lượng dữ liệu tiêu thụ ít ( U(t) nhỏ). Để tránh phản ứng thái quá, hiệu chỉnh được chia tỷ lệ theo U(t) / (InertiaUnits + U(t)) : khi U(t) nhỏ, phần lớn hiệu chỉnh bị triệt tiêu; khi lớn, phần lớn được áp dụng; khi U(t) = InertiaUnits , chính xác một nửa được áp dụng.
Mô phỏng & Phân tích
Các biểu đồ bên dưới so sánh kiểu Arbitrum với kiểu P-only xung quanh đỉnh phí blob ( liên kết mô phỏng ):
Ưu điểm:
- Phương pháp này đạt được hiệu quả bảo vệ tài nguyên tốt hơn so với chỉ sử dụng P trong giai đoạn tăng đột biến, với mức giảm tài nguyên ít hơn.
- Mức độ biến động phí thấp hơn nhiều so với chỉ sử dụng FF.
Nhược điểm:
- Mức độ biến động phí cao hơn so với chế độ chỉ sử dụng P; phí liên tục dao động giữa các giá trị thấp và cao, thay vì theo đường cong hình gờ mượt mà như ở chế độ chỉ sử dụng P.
- Bộ điều khiển này khó hiểu và điều chỉnh hơn so với bộ điều khiển P thông thường, vì hành vi của nó phụ thuộc vào sự tương tác giữa
EquilUnits,Inertia, nhịp điệu đăng bài và kích thước khoảng thời gianU(t).
Những bài học rút ra từ mô phỏng
Các mô phỏng chỉ ra một sự đánh đổi nhất quán: tình trạng bảo mật của kho tiền thường đi kèm với chi phí là sự biến động phí cao hơn.
- P-controller cung cấp độ biến động phí thấp nhất nhưng sức khỏe kho tiền ở mức trung bình trong các mô phỏng này, đồng thời cũng có khả năng phục hồi thâm hụt theo thời gian. Điểm yếu chính của nó là khả năng phục hồi sức khỏe kho tiền không nhanh nhất và cần thời gian để phản ứng với những biến động đột ngột về chi phí L1.
- Phương thức Arbitrum mang lại khả năng bảo vệ tài khoản mạnh mẽ hơn nhưng lại có phí biến động cao hơn so với phương thức P-only, đặc biệt là trong các sự kiện gây áp lực mạnh như sự tăng đột biến chi phí L1, tuy nhiên phí được cập nhật không đều và phức tạp hơn.
- FF-only có thể theo dõi tốt chi phí L1 thực tế khi phí có đủ biên độ (tức là
F_maxđủ cao để các đỉnh phí không bị cắt), nhưng nó chuyển trực tiếp sự biến động L1 cho người dùng. Và nếu phí bị giới hạn ởF_maxtrong các đợt tăng đột biến lớn, nó không thể bù đắp được doanh thu bị mất sau đó vì không có điều khoản phản hồi nào để đẩy quỹ trở lại mục tiêu. - P+FF cải thiện tình trạng của kho tiền so với chỉ sử dụng P, nhưng trong mô phỏng này, lợi ích đạt được khá khiêm tốn so với chi phí UX phát sinh từ việc đưa thêm biến động L1 trực tiếp vào phí.
- Bộ điều khiển PI cải thiện khả năng theo dõi trạng thái ổn định so với chỉ sử dụng bộ điều khiển P, nhưng có thể gây ra hiện tượng vượt quá giới hạn và biến động phí nhiều hơn đối với người dùng.
Nhìn chung, các mô phỏng cho thấy rằng, nếu biến động phí L2 là một vấn đề đáng quan tâm, thì lựa chọn thiết kế chính là giữa phương pháp chỉ sử dụng P và phương pháp Arbitrum : phương pháp chỉ sử dụng P nếu ưu tiên sự mượt mà của phí, tính đơn giản trong triển khai và khả năng dự đoán; phương pháp Arbitrum nếu việc theo dõi mục tiêu chặt chẽ hơn đáng để chấp nhận phí nhiễu hơn và bộ điều khiển phức tạp hơn. Mặc dù PI làm giảm độ lệch trạng thái ổn định, nhưng nó có xu hướng vượt quá giới hạn, và độ phức tạp trong điều chỉnh làm cho nó kém hấp dẫn hơn, đặc biệt khi độ lệch trạng thái ổn định của phương pháp chỉ sử dụng P nằm trong phạm vi chấp nhận được.
Cần lưu ý rằng các bộ điều khiển được nghiên cứu ở đây chỉ đại diện cho một phần nhỏ trong không gian thiết kế rộng lớn. Nhiều kiến trúc bộ điều khiển khác, bao gồm các biến thể khác của bộ điều khiển PID, các sơ đồ khuếch đại thích ứng và các thiết kế lai kết hợp phản hồi và điều khiển tiến với tỷ lệ khác nhau, vẫn chưa được nghiên cứu và sẽ được dành cho các công việc trong tương lai.
Ghi chú triển khai
Trên thực tế, chi phí ghi sổ L1 phải được nhập từ L1 sang L2 để được hạch toán trong kho lưu trữ, nằm ở L2. Quy trình tổng quan như sau:
- Ghi lại chi phí L1 trên L1. Khi một trình sắp xếp gửi dữ liệu hoặc bằng chứng L2 lên L1, hợp đồng hộp thư đến L1 sẽ ghi lại chi phí gửi thực tế (lượng gas đã sử dụng × phí cơ bản, số lượng blob × phí blob).
- Nhập vào L2 thông qua cơ chế nhắn tin L1→L2. Chi phí được ghi nhận sẽ được chuyển đến hợp đồng kho phí L2 thông qua cơ chế truyền tin nhắn L1→L2 của chuỗi. Trong trường hợp của Taiko, điều này xảy ra thông qua giao dịch neo — mỗi khối L2 bao gồm một neo nhập trạng thái L1 mới nhất, bao gồm bất kỳ chi phí đăng bài nào mới được ghi nhận. Arbitrum sử dụng cơ chế hộp thư đến bị trì hoãn .
- Cập nhật số dư kho tiền và tính phí. Kho tiền phí trên L2 ghi nợ chi phí đã nhập từ số dư của nó, tạo ra
V(t)được cập nhật. Sau đó, bộ điều khiển sử dụng số dư này để tính phí L2 tiếp theoF(t).
Điều này có nghĩa là cái nhìn của kho dữ liệu về chi phí L1 bị chậm trễ một cách cố hữu. Nó chỉ có thể phản ánh các chi phí đã được ghi nhận trên L1 và nhập vào L2. Sự chậm trễ này được thể hiện bằng tham số delay trong các công thức điều khiển ở trên.
Câu hỏi mở
[Q1] Làm thế nào để ngăn chặn việc đăng bài bừa bãi trong quá trình hoàn trả chi phí?
Như đã thảo luận trong phần Ghi chú về Trình tự hóa phân tán , kho tiền có thể hoàn trả cho các trình tự hóa chi phí đăng tải L1 của họ. Nhưng điều này tạo ra một rủi ro đạo đức tiềm tàng: các trình tự hóa có thể đăng tải quá thường xuyên (các lô nhỏ, không hiệu quả), không canh thời gian đăng tải để tránh các đợt tăng phí L1, hoặc trả quá nhiều phí ưu tiên — vì kho tiền dù sao cũng phải chịu chi phí đó.
Các biện pháp giảm thiểu cần xem xét:
- Sử dụng phí ưu tiên cố định trong công thức hoàn trả, hoặc không xem xét phí ưu tiên. Điều này sẽ giới hạn số tiền mà quỹ sẽ chi trả — nếu người thực hiện trình tự trả quá nhiều phí ưu tiên, họ sẽ tự chịu phần vượt quá đó.
- Giới hạn mức hoàn trả dưới 100% (ví dụ: 90%) khi người thực hiện sao chép dữ liệu bị lỗ. Điều này giúp khuyến khích người thực hiện sao chép dữ liệu hoạt động hiệu quả về mặt chi phí, vì họ luôn có một phần vốn đầu tư.
[Q2] Mức độ biến động phí L2 nên được tách biệt như thế nào so với biến động phí L1?
Bất kỳ bộ điều khiển nào có thành phần phản hồi tiến (chỉ FF, P+FF) đều truyền trực tiếp sự biến động phí cơ bản L1 và phí blob vào phí L2. Sự biến động này không phụ thuộc vào nhu cầu L2. Trên L1, các đợt tăng phí là do nhu cầu thúc đẩy, vì vậy những người dùng gây tắc nghẽn là những người phải trả phí, và phí cao hơn không nhất thiết làm tắc nghẽn hoạt động. Trên L2, tình hình khác: một đợt tăng chi phí L1 (ví dụ: từ việc bán token trên L1) làm tăng phí L2 mà không có sự gia tăng tương ứng về mức độ sẵn sàng trả phí của người dùng L2. Bởi vì người dùng L2 không có lý do gì để coi trọng đợt tăng phí này, độ co giãn của nhu cầu sẽ lớn hơn, làm tăng nguy cơ tắc nghẽn hoạt động L2.
Điều này đặt ra một câu hỏi về thiết kế: liệu kho tiền có nên chủ động hấp thụ các đỉnh L1 ngắn hạn để giảm sự biến động phí, hay chuyển tiếp chúng để đảm bảo tính toàn vẹn của kho tiền?
[Q3] Điều gì sẽ xảy ra nếu phí quá cao và khiến người dùng bỏ đi?
Tất cả các bộ điều khiển nêu trên đều giả định rằng phí cao hơn sẽ dẫn đến dòng tiền vào kho bạc lớn hơn trong giới hạn phí tối đa ( F_max ). Nhưng trên thực tế, nếu phí tăng quá cao, người dùng sẽ ngừng giao dịch, và sự sụt giảm khối lượng giao dịch có thể bù đắp hoàn toàn cho khoản phí giao dịch cao hơn. Điều này có thể tạo ra một vòng xoáy luẩn quẩn: phí cao → ít giao dịch hơn → thâm hụt sâu hơn → phí thậm chí còn cao hơn.
Các biện pháp giảm thiểu đã được thực hiện:
-
F_maxclamp : tất cả các bộ điều khiển đều áp đặt mức phí tối đa cố định, đây là biện pháp bảo vệ chính chống lại việc đẩy phí lên quá cao.
Với giả định rằng F_max đủ thấp để không làm giảm đáng kể nhu cầu, các mô phỏng hiện tại vẫn đúng. Nhưng đây vẫn chỉ là một giả định, và nếu F_max nằm trên điểm mà nhu cầu trở nên co giãn , các bộ điều khiển vẫn có thể rơi vào "vòng xoáy tử thần" như đã mô tả ở trên.
Các biện pháp giảm thiểu bổ sung cần xem xét:
- Mô phỏng với đường cong độ co giãn cầu giả định: Chạy mô phỏng bộ điều khiển theo mô hình trong đó khối lượng giao dịch giảm khi phí tăng, để kiểm tra tính ổn định vượt ra ngoài chế độ không co giãn.
- Theo dõi và phản ứng với sự thay đổi nhu cầu: theo dõi lượng sử dụng khí L2 liên tục và tự động điều chỉnh mức tăng phí khi khối lượng sử dụng giảm nhanh sau khi tăng phí.




















