Kung paano na-neutralize ng Solana ang isang 6 Tbps na pag-atake gamit ang isang partikular na traffic-shaping protocol na ginagawang imposibleng mag-scale ang spam

Kapag ang isang network ay nagyayabang tungkol sa throughput, ang totoo'y ipinagmamalaki nito kung gaano karaming kaguluhan ang kaya nitong lunukin bago ito masakal. Kaya naman ang pinaka-kagiliw-giliw na bahagi ng pinakabagong “stress test” ng Solana ay ang kawalan ng anumang kwento.

Isang delivery network na tinatawag na Pipe ang naglabas ng datos na naglalagay sa kamakailang pag-atake sa Solana sa humigit-kumulang 6 terabits bawat segundo, at sinuportahan ng mga co-founder ng Solana ang pangunahing punto nito sa mga pampublikong post. Kung tama ang bilang, ito ang uri ng dami ng trapiko na karaniwang nakalaan para sa pinakamalalaking target sa internet, ang klase ng bagay na sinusulat ng Cloudflare ng mahahabang blog post dahil hindi ito dapat maging normal.

At gayon pa man, patuloy na nagpoproseso ng mga block ang Solana. Walang naganap na coordinated restart o validator-wide group chat na naging parang late-night disaster movie.

Ayon sa sariling ulat ng CryptoSlate tungkol sa insidente, nanatiling matatag ang block production at tuloy-tuloy ang mga kumpirmasyon, nang walang makabuluhang pagtaas sa user fees. Mayroon pang kontra-punto sa mga usapan: binanggit ng SolanaFloor na may isang Anza contributor na nagsabing ang 6 Tbps na numero ay isang maikling peak burst at hindi isang tuloy-tuloy na linggong pader ng trapiko, na mahalaga dahil ang “peak” ay maaaring parehong totoo at medyo theatrical.

Ayos lang ang ganitong uri ng detalye. Sa totoong mundo ng denial-of-service, kadalasan ang peak ang mahalaga, dahil kahit isang maikling suntok ay maaaring magpatumba ng isang sistemang nakatutok para sa steady state.

Ipinapakita ng threat reporting ng Cloudflare kung gaano karaming malalaking atake ang mabilis natatapos, minsan masyadong mabilis para makareact ang tao, kaya’t ang modernong depensa ay dapat awtomatiko. Ipinapakita ngayon ng pinakabagong insidente ng Solana ang isang network na natutong gawing boring ang spam.

Anong uri ng atake ito, at ano ba talaga ang gusto ng mga umaatake?

Ang DDoS ay ang pinakapayak ngunit pinaka-epektibong sandata sa internet: lamunin ang normal na trapiko ng target sa pamamagitan ng pagbaha dito ng junk traffic mula sa maraming makina nang sabay-sabay. Ang depinisyon ng Cloudflare ay tuwiran; ito ay isang malisyosong pagtatangka na gambalain ang normal na trapiko sa pamamagitan ng pagbaha sa target o kalapit na imprastraktura ng internet traffic, na karaniwang nagmumula sa mga compromised na sistema.

Iyan ang web2 na bersyon, at ito ang bersyon na tinutukoy ng Pipe gamit ang terabits-per-second na chart. Ang mga crypto network ay nagdadagdag ng pangalawang, mas crypto-native na lasa: spam na hindi lang “junk packets sa isang website” kundi “walang katapusang transaksyon sa isang chain,” kadalasan dahil may pera sa kabilang panig ng congestion.

Ang sariling kasaysayan ng outage ng Solana ay parang handbook para sa problemang insentibo na iyan. Noong Setyembre 2021, nag-offline ang chain ng mahigit 17 oras, at inilarawan ng maagang postmortem ng Solana ang pagbaha ng bot-driven transactions bilang, sa esensya, isang denial-of-service event na konektado sa isang Raydium-hosted IDO.

Noong Abril 2022, inilarawan ng opisyal na outage report ng Solana ang mas matinding pader ng inbound transactions, 6 milyon kada segundo, na may mga indibidwal na node na nakakakita ng mahigit 100 Gbps. Sinabi sa ulat na walang ebidensya ng isang klasikong denial-of-service campaign, at ang mga fingerprint ay mukhang mga bot na sumusubok manalo sa isang NFT mint kung saan ang unang tumawag ang nananalo.

Huminto sa pagpoproseso ng mga block ang network noong araw na iyon at kinailangang mag-coordinate ng restart.

Kaya ano ang gusto ng mga umaatake, bukod sa atensyon at kasiyahan ng pagsira ng Linggo ng lahat? Minsan ito ay tuwirang pangingikil: bayaran kami, o patuloy naming bubuksan ang firehose.

Minsan ito ay paninira ng reputasyon, dahil ang isang chain na hindi kayang manatiling live ay hindi mapagkakatiwalaang mag-host ng mga app na gustong buuin ng mga tao. Minsan ito ay laro sa merkado, kung saan ang sirang UX ay lumilikha ng kakaibang pagpepresyo, naantalang liquidations, at sapilitang reroutes na nagbibigay gantimpala sa mga nakaposisyon para sa kaguluhan.

Sa on-chain spam na bersyon, maaaring tuwiran ang layunin: manalo sa mint, manalo sa trade, manalo sa liquidation, manalo sa block space.

Ang pagkakaiba ngayon ay mas marami nang paraan ang Solana para tumanggi sa paanyaya.

Ang mga pagbabago sa disenyo na nagpapanatili sa Solana na tumatakbo

Naging mas mahusay ang Solana sa pananatiling online sa pamamagitan ng pagbabago kung saan lumalabas ang sakit. Noong 2022, pamilyar ang anyo ng mga pagkabigo: sobrang dami ng inbound requests, sobrang strain sa node-level resources, kulang sa kakayahang pabagalin ang masasamang aktor, at mga epekto na nagiging sanhi ng congestion na maging liveness problems.

Ang mga upgrade na pinakamahalaga ay nasa gilid ng network, kung saan tumatama ang trapiko sa mga validator at leader. Isa rito ang paglipat sa QUIC para sa network communication, na kalaunan ay inilista ng Solana bilang bahagi ng stability work nito, kasama ng local fee markets at stake-weighted quality of service.

Hindi mahika ang QUIC, ngunit ito ay ginawa para sa controlled, multiplexed connections sa halip na mga lumang pattern ng koneksyon na ginagawang mura ang pang-aabuso.

Mas mahalaga, inilalarawan ng validator-side documentation ng Solana kung paano ginagamit ang QUIC sa loob ng Transaction Processing Unit path: may mga limitasyon sa sabayang QUIC connections bawat client identity, limitasyon sa sabayang streams bawat koneksyon, at mga limitasyong umaayon sa stake ng nagpadala. Inilalarawan din nito ang packets-per-second rate limiting na nakabase sa stake, at binabanggit na maaaring i-drop ng server ang mga stream gamit ang throttling code, na inaasahan ng mga client na mag-back off.

Iyon ay ginagawang “spam” na “spam na itinatapon sa mabagal na linya.” Hindi na sapat ang may bandwidth at botnet, dahil ngayon kailangan mo ng pribilehiyadong access sa leader capacity, o nakikipagkumpitensya ka para sa mas makitid na bahagi nito.

Ang developer guide ng Solana para sa stake-weighted QoS ay nagpapaliwanag nito: kapag naka-enable ang feature, ang validator na may hawak na 1% ng stake ay may karapatang magpadala ng hanggang 1% ng mga packet sa leader. Pinipigilan nito ang mga low-stake sender na bahain ang lahat at pinapataas ang Sybil resistance.

Sa madaling salita, nagiging uri ng bandwidth claim ang stake, hindi lang voting weight.

At naroon ang bahagi ng fee, kung saan sinusubukan ng Solana na iwasan ang “isang maingay na app ang sumisira sa buong lungsod.” Ang local fee markets at priority fees ay nagbibigay sa mga user ng paraan para makipagkumpitensya para sa execution nang hindi ginagawang chain-wide auction ang bawat abalang sandali.

Ipinapaliwanag ng fee documentation ng Solana kung paano gumagana ang priority fees sa pamamagitan ng compute units, kung saan maaaring magtakda ang mga user ng compute unit limit at optional compute unit price, na parang tip para hikayatin ang prioritization. Binabanggit din nito ang isang praktikal na babala: ang priority fee ay nakabase sa requested compute unit limit, hindi sa aktwal na nagamit, kaya’t maaaring magbayad para sa hindi nagamit na headroom ang mga hindi maingat sa settings.

Iyon ay nagpapataw ng presyo sa computationally heavy na gawain at nagbibigay sa network ng kontrol para gawing mas mahal ang pang-aabuso kung saan ito masakit.

Pagsamahin ang mga bahaging ito, at makakakuha ka ng ibang failure mode. Sa halip na baha ng ingay na nagtutulak sa mga node sa memory death spirals, mas maraming paraan ang network para mag-throttle, mag-prioritize, at mag-contain.

Ang Solana mismo, sa pagbalik-tanaw sa panahon ng 2022, ay inilarawan ang QUIC, local fee markets, at stake-weighted QoS bilang mga konkretong hakbang na ginawa upang mapanatili ang reliability nang hindi isinusuko ang bilis.

Iyan ang dahilan kung bakit maaaring dumaan ang isang terabit-scale na weekend nang walang tunay na epekto: mas maraming automatic na “no’s” ang chain sa harap at mas maraming paraan para mapanatiling gumagalaw ang linya para sa mga user na hindi sinusubukang sirain ito.

Hindi ibig sabihin nito na immune na ang Solana sa masasamang araw. Kahit ang mga pumupuri sa 6 Tbps anecdote ay nagtatalo tungkol sa ibig sabihin ng numero at kung gaano ito katagal, na magalang na paraan ng pagsasabing magulo ang internet measurements at ang bragging rights ay walang kasamang audit report.

At hindi nawawala ang mga trade-off. Ang sistemang nag-uugnay ng mas magandang traffic treatment sa stake ay, sa disenyo, mas pabor sa mga well-capitalized operator kaysa sa mga hobbyist validator. Ang sistemang nananatiling mabilis sa ilalim ng load ay maaari pa ring maging lugar para sa mga bot na handang magbayad.

Gayunpaman, mahalaga ang katahimikan ng network. Ang mga naunang outage ng Solana ay hindi “napansin ng mga tao ang kaunting latency.” Ganap na tumigil ang block production, sinundan ng mga pampublikong restart at mahahabang coordination window, kabilang ang April 2022 halt na inabot ng ilang oras bago maresolba.

Sa kabaligtaran, ang kwento ngayong linggo ay nanatiling live ang chain habang ang trapiko ay diumano’y umabot sa antas na mas karaniwan sa threat reports ng Cloudflare kaysa sa crypto lore.

Kumikilos ang Solana na parang isang network na inaasahang aatakehin at nagpasya na ang umaatake ang dapat unang mapagod.

Ang post na How Solana neutralized a 6 Tbps attack using a specific traffic-shaping protocol that makes spam impossible to scale ay unang lumabas sa CryptoSlate.