Nopeat lohkoketjut tuovat uusia haasteita kaistanleveyden hallinnalle ja RPC:n oikeudenmukaisuudelle. Tänään esittelemme mekanismin, jolla RPC-käyttöoikeuksia voidaan muokata likvidien panostussitoumusten avulla. Järjestelmä on käytössä FastLanen ShMonad RPC:n kautta. Tässä ketjussa tarkastellaan arkkitehtuuria ja perusteluja. 🧵

Suuren suorituskyvyn verkot, kuten Monad (~0,5 s lohkoaika, ~1 s lopullisuus), jättävät vain vähän tilaa reaktiiviselle kuristamiselle. Kun RPC-päätepiste havaitsee olevansa roskapostihyökkäyksen kohteena, vahinko on jo tapahtunut. Hillitsemisen on oltava ennakoivaa ja kannustimien mukaista. /2

Tärkein rajoitus on kaistanleveys. Validaattorin vierekkäiset solmut ovat resurssirajoitettuja ja viiveherkkiä. Jos luvaton käyttöoikeus myönnetään umpimähkäisesti, vastakkaiset asiakkaat voivat syrjäyttää rehelliset osallistujat, mikä johtaa heikentyneisiin UX- ja validointikustannuksiin ilman oikeussuojakeinoja. /3

Ratkaisumme hyödyntää ShMonadia, ohjelmoitavaa likvidiä panostustokenia (LST), jolla on ketjun sisäiset sitoutumisominaisuudet. Käyttäjät saavat yksityisen RPC-URL-osoitteen vastineeksi siitä, että he sitoutuvat ShMON:iin ketjun sisäiseen "RPC-käytäntöön". Tämä sitoumus säätelee käyttönopeuden rajoituksia. /4

Kaistanleveys jaetaan suhteellisesti: käyttäjän RPS = (käyttäjän sitoutunut ShMON / sitoutunut ShMON yhteensä) × RPS_max-globaali Tämä tuottaa dynaamisesti jaettavan, panospainotetun kaistanleveysmallin ilman keskitettyjä ketjun ulkopuolisia nopeudenrajoittimia. 5/

Stake on sidottu ajaksi (tällä hetkellä 20 lohkoa), mikä mahdollistaa välimuistin. Viesti tekee ajoittain kyselyjä ja tilannekuvia ketjun sitoutumisen tilasta. Tämä estää EVM-puhelut kriittisellä polulla ja tukee korkeataajuista käyttöä ilman ylimääräistä viivettä. 6/

Empiirisesti tämä järjestelmä johtaa jatkuvasti pienempään latenssiin. Useissa riippumattomissa vertailuistunnoissa FastLanen ShMonad RPC:n mediaani/keskimääräinen vasteaika on ~20 ms pienempi kuin toiseksi nopeimmalla palveluntarjoajalla, ja ero julkisiin RPC:hen nähden on suurempi. 7/

RPC-käytäntöön sitoutunut ShMON on panostettu FastLane-välitysverkkoon osallistuvien validoijien kanssa (tällä hetkellä >90 % Monad-validoijista). Tämä luo yhdenmukaisuutta: kaistanleveyden kuluttajat tukevat samoja validoijia, jotka palvelevat heidän liikennettään, ja validoijilla on mahdollisuus saada korvaus suoraan ylitysrangaistuksilla. 8/

Mutta kaistanleveysrajoitusten valvomiseksi uskottavasti ja luotettavasti tarvitsemme muutakin kuin nopeusrajoituksia... tarvitsemme todistettavaa täytäntöönpanoa. Toistaiseksi käyttäjät ovat releen kurissa. Etenemissuunnitelma sisältää kuitenkin ketjun sisäisiä järjestelmiä, jotka perustuvat nonce-deltoihin ja allekirjoitettuihin käyttökuitteihin. 9/

Minimaalinen suunnittelu voisi verrata lohkojen korkeuksien n ja m välisiä tilinonceja ja vinoviivaa (eli "sovella lisämaksua" ja antaa se validoijalle) ylimääräistä käyttöä maksimiRPS:n yläpuolella. Mutta siinä on ongelma: tämä on alttiina releen erävapautushyökkäyksille, jotka saavat txs:t näyttämään räjähtäviltä.

Tämän lieventämiseksi otamme käyttöön toisen kanavan: asynkroniset aikaleimatut käyttökuitit. Kun tapahtuma lähetetään, se lähetetään sekä validoijalle että erilliselle "kuitin myöntäjälle". Myöntäjä palauttaa lähettäjälle allekirjoitetun objektin, joka on aikaleimattu ja sisältää suoritusta edeltävät nonce-metatiedot. Se poistaa seurannan ja todentamisen yleiskustannukset käyttäjän ja validaattorin väliseltä kuumalta polulta. 11/

Näillä kuitteilla (jotka allekirjoitetaan) on kaksi tarkoitusta: 1. Käyttäjäpalaute: Jos kuitteja ei enää tule, asiakkaat voivat vapaaehtoisesti pysäyttää liikenteen välttääkseen ylimääräiset maksut. 2. Ketjun sisäinen todiste: Kuitit ankkuroivat ajallisen toiminnan ja erottavat todellisen roskapostin releen aiheuttamasta erästä. 12/

Tämä malli tukee sekä EOA:ta että 4337 userOpsia (olettaen, että ne ovat jakamattomia paketteja tai vertikaalista integraatiota oman paymasterimme kanssa). Tulevissa versioissa saatamme vaatia, että tapahtuman allekirjoittaja vastaa vakuutuksenottajaa tai oli sallittujen listalla vakuutuksen sitoumuksen aikana. TBD. 13/

Tavoitteenamme on siirtää valvonta ketjuun suorituskyvystä tinkimättä. Monadin runsaan lohkotilan ja nopean lopullisuuden ansiosta valtion todistusten lähettäminen, kuittien tarkistaminen ja ylimääräisten maksujen veloittaminen on kannattavaa ketjussa... jotain, mikä on mahdotonta kalliimmissa verkoissa. 14/

Ylitysrangaistuksia (ruuhkahinnoittelun tapaan) suunnitellaan edelleen. Odotamme Monadin viimeisteltyä maksumarkkinarakennetta ennen lisämaksuaikataulun viimeistelyä - meidän ei olisi järkevää suunnitella ylitysmaksua tietämättä, mikä perusmaksu on. 15/

RPC-siirtonopeus mitataan tällä hetkellä koosteena (txs + eth_call), mutta tulevat päivitykset erittelevät kaistanleveysluokat. Lukupyynnöt reititetään alueellisesti optimoitujen solmujen kautta, mikä poistaa ne validaattorin kaistanleveysrajoitusten luomasta pullonkaulasta. 16/

Latenssiherkissä sovelluksissa (esim. täydet solmut, markkinatakaajat) tuemme peeringiä ja suoraa lohkosyöttöä p2p:n kautta. Täysien lohkojen etenemisprioriteetti on panospainotettu (LSWQoS): käyttäjät, joilla on suurempi sitoutunut ShMON, saavat lohkoja hieman aikaisemmin sisällyttämiskynnysarvojen mukaisesti. 17/

Tämä poikkeaa perinteisestä "best effort" -RPC:stä. RPC:n lukupyynnöissä vahvistettu panosmäärä määrittää pyyntöjen määrän. Solmuistamme lähetettyjen lohkojen osalta sidotun panoksen määrä määrittää lähetysjärjestyksen. 18/

Luotettava kulunvalvonta on toteuttamiskelpoinen korkean suorituskyvyn ketjuissa, jos kannustimet, täytäntöönpano ja tarkkailtavuus suunnitellaan ensimmäisistä periaatteista. ShMonadin RPC on tämän väitöskirjan referenssitoteutus. Odotamme innolla iteraatiota ja ulkoista tarkastelua. 19/