Blockchain cepat memperkenalkan tantangan baru untuk manajemen bandwidth dan keadilan RPC. Hari ini kami memperkenalkan mekanisme untuk membentuk akses RPC menggunakan komitmen staking likuid. Sistem ini ditayangkan melalui ShMonad RPC FastLane. Utas ini mengeksplorasi arsitektur dan alasan. 🧵

Jaringan throughput tinggi seperti Monad (waktu blok ~0,5 detik, finalitas ~1 detik) menyisakan sedikit ruang untuk pelambatan reaktif. Pada saat titik akhir RPC mendeteksi berada di bawah serangan spam, kerusakan telah terjadi. Mitigasi harus proaktif dan selaras dengan insentif. /2

Kendala kuncinya adalah bandwidth. Simpul yang berdekatan dengan validator dibatasi sumber daya dan sensitif terhadap latensi. Jika akses tanpa izin diberikan tanpa pandang bulu, klien yang bermusuhan dapat mengerumuni peserta yang jujur—mengakibatkan penurunan biaya UX dan validator tanpa jalan lain. /3

Solusi kami memanfaatkan ShMonad, token staking cair (LST) yang dapat diprogram dengan kemampuan komitmen on-chain. Pengguna menerima URL RPC pribadi sebagai imbalan untuk melakukan ShMON ke "Kebijakan RPC" on-chain. Komitmen ini mengatur batas tingkat akses. /4

Bandwidth dialokasikan secara proporsional: RPS pengguna = (ShMON yang berkomitmen pengguna / total ShMON yang berkomitmen) × RPS_max-global Ini menghasilkan model bandwidth tertimbang saham yang dapat dibagikan secara dinamis tanpa memperkenalkan pembatas kecepatan off-chain terpusat. 5/

Stake diberlakukan untuk durasi tertentu (saat ini 20 blok), yang memungkinkan caching. Relai ini sebentar-sebentar melakukan jajak pendapat dan menggambarkan status komitmen on-chain. Ini mencegah panggilan EVM di jalur kritis dan mendukung penggunaan frekuensi tinggi tanpa latensi tambahan. 6/

Secara empiris, sistem ini menghasilkan latensi yang lebih rendah secara konsisten. Di beberapa sesi pembandingan independen, RPC ShMonad FastLane menunjukkan waktu respons median/rata-rata ~20 ms lebih rendah daripada penyedia tercepat kedua, dengan kesenjangan yang lebih besar terhadap RPC publik. 7/

ShMON yang berkomitmen pada kebijakan RPC dipertaruhkan dengan validator yang berpartisipasi dalam jaringan relai FastLane (saat ini >90% validator Monad). Ini menciptakan keselarasan: konsumen bandwidth mendukung validator yang sama yang melayani lalu lintas mereka, dan validator memiliki potensi untuk diberi kompensasi langsung melalui penalti kelebihan umur. 8/

Tetapi untuk menegakkan batas bandwidth secara kredibel dan tanpa kepercayaan, kita membutuhkan lebih dari sekadar batas tarif ... kita membutuhkan penegakan hukum yang dapat dibuktikan. Untuk saat ini, pengguna dibatasi di relai. Tetapi peta jalan mencakup sistem bukti on-chain berdasarkan delta nonce dan tanda terima penggunaan yang ditandatangani. 9/

Desain minimal dapat membandingkan akun nonces antara tinggi blok n dan m, dan garis miring (yaitu, 'menerapkan biaya tambahan' dan memberikannya kepada validator) kelebihan penggunaan di atas RPS maks. Tapi ada masalah: ini rentan terhadap serangan batch-release oleh relai yang membuat txs tampak meledak.

Untuk mengurangi hal ini, kami memperkenalkan saluran kedua: tanda terima penggunaan stempel waktu asinkron. Ketika transaksi dikirimkan, transaksi akan di-multicast ke validator dan "penerbit tanda terima" yang terpisah. Penerbit mengembalikan objek yang ditandatangani ke pengirim, diberi stempel waktu, dan termasuk metadata nonce pra-eksekusi. Ini mengambil overhead pelacakan dan verifikasi dari jalur panas antara pengguna dan validator. 11/

Tanda terima ini (yang akan ditandatangani) memiliki tujuan ganda: 1. Umpan balik pengguna: Jika tanda terima berhenti sampai, klien dapat secara sukarela menghentikan lalu lintas untuk menghindari biaya berlebih. 2. Bukti on-chain: Tanda terima menjangkar aktivitas temporal, mendisambiguasi spam nyata dari batching yang diinduksi relai. 12/

Model ini mendukung EOA dan 4337 userOps (dengan asumsi bundel yang tidak dibagikan atau integrasi vertikal dengan paymaster kami sendiri). Di versi mendatang, kami dapat memberlakukan bahwa penandatangan transaksi cocok dengan pemegang polis atau masuk daftar putih selama komitmen polis. TBD. 13/

Tujuan kami adalah untuk memindahkan penegakan on-chain tanpa mengorbankan kinerja. Berkat blockspace Monad yang melimpah dan finalitas yang cepat, mengirimkan bukti negara, memverifikasi tanda terima, dan membebankan biaya kelebihan layak secara on-chain... sesuatu yang tidak layak di jaringan berbiaya lebih tinggi. 14/

Penalti kelebihan (analog dengan penetapan harga kemacetan) masih dalam desain. Kami menunggu struktur pasar biaya akhir Monad sebelum menyelesaikan jadwal biaya tambahan - tidak masuk akal bagi kami untuk merancang biaya kelebihan tanpa mengetahui berapa biaya dasarnya. 15/

Throughput RPC saat ini diukur dalam agregat (txs + eth_call), tetapi peningkatan di masa mendatang akan memisahkan kelas bandwidth. Permintaan baca akan dirutekan melalui node yang dioptimalkan secara regional, menghapusnya dari kemacetan yang diciptakan oleh batasan bandwidth validator. 16/

Untuk aplikasi yang sensitif terhadap latensi (misalnya node penuh, pembuat pasar), kami mendukung peering dan feed blok langsung melalui p2p. Untuk blok penuh, prioritas propagasi akan ditimbang oleh saham (LSWQoS): pengguna dengan ShMON yang lebih tinggi menerima blok sedikit lebih awal, tunduk pada ambang batas penyertaan. 17/

Ini merupakan keberangkatan dari RPC "upaya terbaik" tradisional. Dengan permintaan baca ke RPC, jumlah taruhan yang diterapkan menentukan jumlah permintaan. Untuk blok yang dikirim dari node kami, jumlah taruhan yang dikomitmenkan menentukan urutan pengiriman. 18/

Kontrol akses tanpa kepercayaan dapat dilakukan pada rantai throughput tinggi jika insentif, penegakan, dan observabilitas dirancang dari prinsip pertama. RPC ShMonad adalah implementasi referensi dari tesis itu. Kami menantikan iterasi dan pengawasan eksternal. 19/