AI Data L1 eller ett decentraliserat lagringsprojekt? Som en utveckling med en liten förståelse för blockchain-lagringsutrymmet undersöktes detta projekt nyligen i @irys_xyz. För att vara ärlig har detta projekt inte mycket att göra med AI, utan tillhör faktiskt den typiska kombinationen av decentraliserad lagring + incitamentlager. Som framgår av deras egna blogginlägg är positionering fortfarande att låta data spela sitt rätta värde. Jag har sett många projekt inom decentraliserad lagring, från IPFS och Storj i början, till Arweave, Filecoin och olika Layer 2-lagringslösningar. Irys, som är en ny aktör i detta utrymme, har några tekniska funktioner som är värda att uppmärksamma. 1️⃣ Projektpositionering och koncept Irys påstår sig vara ett lagringslager 1 designat för AI, som i huvudsak är ett decentraliserat datalagringsnätverk, men dess designkoncept är något speciellt. Till skillnad från Filecoins rena lagringsmarknadsmodell, och till skillnad från Arweaves engångsbetalda permanenta lagring, är Irys mer som att försöka lösa ett kärnproblem: hur man säkerställer att lagrad data faktiskt är tillgänglig. Som framgår av kodstrukturen använder Irys ett dubbelt huvudbokssystem: Permanent Ledger och Term Ledger. Denna designidé är faktiskt ganska intressant, den gör det möjligt för data att flöda mellan olika lagringsnivåer och gradvis "främja" från tillfällig lagring till permanent lagring. 2️⃣ Analys av teknisk arkitektur 2.1 Konsensusmekanism: VDF-val Det mest intressanta tekniska valet för Irys är användningen av VDF (Verifiable Delay Function) som kärnan i konsensusmekanismen. VDF är en relativt ny teknik inom blockchain-området. Dess kärnidé är att skapa en funktion som kräver sekventiell beräkning och som inte är parallelliserad, vilket kan generera förutsägbara tidsfördröjningar. Irys VDF är baserad på SHA-256, och varje steg kräver en viss mängd beräkningstid, men verifieringen kan slutföras snabbt. Ur ett teknikhistoriskt perspektiv föreslogs VDF först av Dan Boneh och andra vid Stanford. Chia använder en liknande teknik, men Irys implementering har en smart twist: den introducerar en periodisk "återställningsmekanism" som förhindrar gruvarbetare från att förberäkna för många steg i förväg. Denna design är faktiskt mycket pragmatisk och löser ett klassiskt problem som VDF står inför. 2.2 Proof-of-Access: Balansen mellan ideal och verklighet Irys hävdar att de använder en "Proof-of-Access"-gruvmekanism, ett koncept som låter tilltalande. Kodmässigt kräver systemet att miners kan komma åt och packa upp lagrade datablock. Data lagras i entropipaket, och miners måste räkna om entropi för att packa upp data. Den här designen säkerställer teoretiskt sett datatillgänglighet. Men för att vara ärlig är giltigheten av detta "bevis på tillgång" fortfarande ett frågetecken. Historiskt sett har vi sett alltför många liknande uttalanden som har hamnat i utmaningar i incitamentsdesignen. Det är ofta de ekonomiska incitamenten snarare än de tekniska medlen i sig som verkligen kan säkerställa långsiktig tillgång till data. 2.2 Djup integration med Reth En sak som slog mig var Irys djupa beroende av Reth, och hela projektet använde många Reth-komponenter, till och med en egen gaffelversion. Detta är ett smart val - Reth är en av de mest effektiva av Ethereums olika kunder. 3️⃣ Design av lagringsekonomi Ur ekonomiska modellers perspektiv är utformningen av Irys ganska komplex, med så många som 10+ parametrar för beräkning. Faktorer som tidsförminskning av lagringskostnader, kontroll av prisfluktuationer och krav på flera kopior beaktas. Denna komplexitet är både en fördel och en nackdel. Fördelen är att modellen ligger närmare verkligheten, med hänsyn till den tekniska utvecklingens inverkan på lagringskostnaderna. Nackdelen är att komplexa ekonomiska modeller tenderar att vara svåra att upprätthålla stabilitet i praktiken. I synnerhet är denna "decay_rate" (dämpningshastighet) design elegant i teorin, men det kommer att ta tid att verifiera om den fungerar som förväntat i verklig drift. 4️⃣ Utvärdering av tekniska innovationspunkter 4.1 Datapaketering och CUDA-optimering Irys har gjort många optimeringar i datapaketering och stöder till och med CUDA-acceleration. Detta fokus på prestanda är lovvärt, trots allt är prestandan för ett lagringsnätverk direkt relaterad till användarupplevelsen. 4.2 Faktisk effekt av VDF VDF som ett tidssäkert teknikval är vettigt, men det finns flera frågor att vara medveten om: 4.2.1. Hårdvaruberoende: Skillnader i datorkraft mellan olika hårdvara kan leda till felaktiga tidsprognoser 4.2.2. Nätverkslatens: I en distribuerad miljö kan nätverksfördröjning påverka synkroniseringseffekten av VDF 4.2.3. Problem med energiförbrukning: Kontinuerliga SHA-256-beräkningar är inte miljövänliga 4️⃣ Jämför med konkurrenterna Jämfört med Arweave är Irys dual-ledger-design mer flexibel, men också mer komplex. Arweaves engångsbetalda lagringsmodell för evigt är enkel, medan Irys nivåindelade lagring kräver mer komplex datamigreringslogik. Jämfört med Filecoin fokuserar Irys mer på den faktiska tillgängligheten av data snarare än att bara lagra bevis. Jämfört med IPFS försöker Irys lösa problemet med IPFS:s brist på incitament, men på bekostnad av att införa en komplex blockchain-konsensusmekanism. 5️⃣ Realistiska utmaningar och framtidsutsikter Ur teknisk synvinkel är designen av Irys något innovativ, särskilt kombinationen av VDF+PoA och det dubbla huvudbokssystemet. Men utmaningarna i projektet är också uppenbara: 5.1. Ekologiskt byggande: Framgången för decentraliserade lagringsprojekt beror till stor del på ekologiskt byggande, vilket inte är ett problem som tekniken kan lösa ensam. 5.2. Incitamentsmekanismernas stabilitet på lång sikt: Det kommer att ta tid att kontrollera om komplexa ekonomiska modeller kan upprätthålla balansen i praktiken. 5.3. Hård konkurrens: Det finns redan många mogna konkurrenter på detta område, och nya projekt måste ha tillräckligt starka differentieringsfördelar. Uttalande: Den här artikeln är baserad på analysen av Irys-projektkoden, med fokus på dess tekniska arkitektur och designkoncept. Som ett projekt under utveckling måste dess slutliga prestanda verifieras i verklig drift. Utvärderingen i denna artikel baseras på den aktuella kodimplementerings- och designdokumentationen och utgör inte investeringsrådgivning.