Strávil jsem dost času sledováním slibů "levných dat", které se střetávají s reálnými inženýrskými omezeními, a tak jsem se stal obezřetným užitečným způsobem. V raných infrastrukturních cyklech týmy dodávají něco, co funguje na demonstračním měřítku, a pak se účet objeví, když se používání stane chaotickým: špičky šířky pásma, obrat uzlů a najednou předpoklady designu vykonávají většinu práce. Proto věnuji zvláštní pozornost návrhům úložišť, které vycházejí z nákladového modelu, nikoli ze sloganu.
Hlavní tření je jednoduché: blockchainy jsou postaveny kolem replikace stavových strojů (SMR), což znamená, že každý plný uzel znovu vykonává transakce a ukládá stejný stav, takže si všichni souhlasí. To je skvělé pro malé, vysoce hodnotné stavy, ale je to brutálně neefektivní pro velké blobové objekty, jako jsou herní aktiva, média, modelové soubory nebo protokoly. Plná replikace promění "uložit jeden soubor" na "uložit to Nkrát," kde N je počet uzlů, které mají význam. I když tlačíte blobové objekty do transakčního calldata, stále platíte síti, aby nesla data, která většina uzlů nechce uchovávat navždy.
Je to jako požádat každého knihovníka ve městě, aby měl plnou kopii každé nové knihy, i když většina lidí potřebuje pouze vědět ISBN a kde lze knihu získat.
Walrus řeší tuto zátěž oddělením integrity od hromadného úložiště. Místo toho, aby byla vrstva SMR nucena replikovat celý blob, protokol považuje blockchain za kotvu integrity a koordinační plochu, zatímco samotná data existují v specializované síti úložišť. Hlavním trikem je kódování ztrát: blob je rozdělen na kusy, které jsou poté zakódovány do mnoha "sliverů", takže původní může být zrekonstruován pouze z podmnožiny z nich. To znamená, že získáte trvanlivost a dostupnost, aniž byste museli ukládat více plných kopií. Celková zátěž úložiště se stává funkcí kódovacího poměru, nikoli funkcí "kolik validátorů existuje."
Pod kapotou existuje několik vrstev, které se musí čistě zarovnat. První je výběr výboru pro úložné uzly: síť potřebuje definovaný soubor operátorů odpovědných za udržování sliverů po určité období (často organizováno podle epoch). Tento výběr není jen seznam; je to bezpečnostní hranice, protože model nepřítele se mění, když se členství otáčí. Druhý je stavový model: řetěz nezachovává blob, ukládá identifikátory a kryptografické závazky k tomu, čím by blob měl být. Ten závazek svazuje obsah, takže kdokoli, kdo načítá data, může ověřit, že odpovídá původnímu záměru, aniž by musel důvěřovat poskytovateli úložiště. Třetí je kryptografický tok: klienti kódují blob, distribuují slivery mezi mnoha uzly a později ověřují slivery a rekonstruují blob. Síť může také přidat odpovědnost tím, že vyžaduje od operátorů, aby reagovali na audity/výzvy, které prokazují, že stále drží přidělené slivery, takže "byl jsem včera upřímný" se nestane trvalým bezplatným průjezdem.
Co se mi líbí z pohledu stavitele, je, že tento design je upřímný ohledně toho, co jsou blockchainy nejlepší. SMR je úžasný pro dohodu a konečnost, nikoli pro to, že je globálním pevným diskem. Pokud udržíte vrstvu konsensu soustředěnou na závazky, členství a platby, snížíte tlak na hardware uzlů a udržíte ověřování lehké. To může na oplátku způsobit, že "vytvořit aplikaci, která používá velké soubory" se cítí méně jako boj s základní vrstvou a více jako její používání tak, jak bylo zamýšleno.
Role tokenu WAL se hodí do ekonomiky úložišť spíše než do ekonomiky hype. Poplatky fungují jako předplacené nájemné za úložiště po pevných obdobích: uživatelé platí za ukládání a načítání, tyto platby plynou k operátorům (a potenciálně stakerům/delegátorům) v průběhu času, a obnovy jsou skutečným signálem vhodnosti produktu na trhu. Staking je mechanismus vyjednávání na straně nabídky: spojuje operátory s dlouhodobým chováním, pomáhá síti rozhodnout, kdo je způsobilý sloužit, a dává protokolu páku k penalizaci nedostatečného výkonu. Správa je pomalá kontrolní plocha, která může ladit parametry jako cenové plány, pravidla epoch a váhy pobídek, když skutečný svět učí nové lekce.
Dlouhodobá spolehlivost stále závisí na udržované účasti uzlů a disciplině pobídek pod stresem; obraty, výpadky a nepřátelské chování se obvykle objevují později než měřítka.
Pokud byste navrhovali aplikaci, která potřebuje velké soubory, raději byste platili za plnou replikaci "jen pro případ," nebo platili za ověřitelnou dostupnost s rekonstrukcí z podmnožiny - jaký kompromis vám připadá bezpečnější?
