AI Data L1, eller et desentralisert lagringsprosjekt? Som en utvikling med en liten forståelse av blokkjedelagringsplassen, ble dette prosjektet nylig sett på @irys_xyz. For å være ærlig har ikke dette prosjektet mye med AI å gjøre, men tilhører faktisk den typiske kombinasjonen av desentralisert lagring + insentivlag. Som man kan se av deres egne blogginnlegg, er posisjonering fortsatt for å la data spille sin rettmessige verdi. Jeg har sett mange prosjekter i det desentraliserte lagringssporet, fra IPFS og Storj i de tidlige dagene, til Arweave, Filecoin og ulike Layer 2-lagringsløsninger. Irys, som en ny aktør på dette området, har noen tekniske funksjoner som er verdt å ta hensyn til. 1️⃣ Prosjektposisjonering og konsept Irys hevder å være et lagringslag 1 designet for AI, som egentlig er et desentralisert datalagringsnettverk, men designkonseptet er noe spesielt. I motsetning til Filecoins rene lagringsmarkedsmodell, og i motsetning til Arweaves engangsbetalte permanente lagring, er Irys mer som å prøve å løse et kjerneproblem: hvordan sikre at lagrede data faktisk er tilgjengelige. Som det fremgår av kodestrukturen, bruker Irys et dobbelt hovedboksystem: Permanent Ledger og Term Ledger. Denne designideen er faktisk ganske interessant, den lar data flyte mellom forskjellige lagringsnivåer, og gradvis "forfremme" fra midlertidig lagring til permanent lagring. 2️⃣ Analyse av teknisk arkitektur 2.1 Konsensusmekanisme: VDF-valg Det mest interessante tekniske valget for Irys er bruken av VDF (Verifiable Delay Function) som kjernen i konsensusmekanismen. VDF er en relativt ny teknologi innen blokkjedefeltet. Kjerneideen er å lage en funksjon som krever sekvensiell beregning og ikke er parallellisert, noe som kan generere forutsigbare tidsforsinkelser. Irys' VDF er basert på SHA-256, og hvert trinn krever en viss mengde beregningstid, men verifiseringen kan fullføres raskt. Fra et teknisk historisk perspektiv ble VDF først foreslått av Dan Boneh og andre ved Stanford. Chia bruker en lignende teknikk, men Irys' implementering har en smart vri: den introduserer en periodisk "reset"-mekanisme som hindrer gruvearbeidere i å forhåndsberegne for mange trinn på forhånd. Denne designen er faktisk veldig pragmatisk og løser et klassisk problem som VDF står overfor. 2.2 Proof-of-Access: Balansen mellom idealer og virkelighet Irys hevder å bruke en "Proof-of-Access"-gruvemekanisme, et konsept som høres tiltalende ut. Kodemessig krever systemet at gruvearbeidere kan få tilgang til og pakke ut lagrede datablokker. Data lagres i entropiemballasje, og gruvearbeidere må beregne entropi på nytt for å pakke ut dataene. Denne designen sikrer teoretisk datatilgjengelighet. Men for å være ærlig er gyldigheten av dette "beviset på tilgang" fortsatt et spørsmålstegn. Historisk sett har vi sett for mange lignende utsagn som endte opp med utfordringer i insentivdesign. Det er ofte de økonomiske insentivene snarere enn de tekniske midlene i seg selv som virkelig kan sikre langsiktig tilgang til data. 2.2 Dyp integrasjon med Reth En ting som slo meg var Irys' dype avhengighet av Reth, og hele prosjektet brukte mange Reth-komponenter, til og med sin egen gaffelversjon. Dette er et smart valg - Reth er en av de mest effektive av Ethereums forskjellige klienter. 3️⃣ Design av lagringsøkonomi Fra perspektivet til økonomiske modeller er utformingen av Irys ganske kompleks, med så mange som 10+ parametere for beregning. Faktorer som tidsforfall av lagringskostnader, prissvingningskontroll og krav til flere kopier vurderes. Denne kompleksiteten er både en fordel og en ulempe. Fordelen er at modellen er nærmere virkeligheten, tatt i betraktning virkningen av teknologiske fremskritt på lagringskostnadene; Ulempen er at komplekse økonomiske modeller har en tendens til å være vanskelige å opprettholde stabilitet i praksis. Spesielt er denne "decay_rate" (dempningshastigheten) designen elegant i teorien, men det vil ta tid å verifisere om den fungerer som forventet i faktisk drift. 4️⃣ Evaluering av teknologiske innovasjonspunkter 4.1 Datapakking og CUDA-optimalisering Irys har gjort mange optimaliseringer i datapakking og støtter til og med CUDA-akselerasjon. Dette fokuset på ytelse er prisverdig, tross alt er ytelsen til et lagringsnettverk direkte relatert til brukeropplevelsen. 4.2 Faktisk effekt av VDF VDF som et tidssikringsteknologivalg er fornuftig, men det er flere problemer å være klar over: 4.2.1. Maskinvareavhengighet: Forskjeller i datakraft mellom forskjellig maskinvare kan føre til unøyaktige tidsprognoser 4.2.2. Nettverksforsinkelse: I et distribuert miljø kan nettverksforsinkelse påvirke synkroniseringseffekten til VDF 4.2.3. Problemer med energiforbruk: Kontinuerlige SHA-256-beregninger er ikke miljøvennlige 4️⃣ Sammenlign med konkurrentene Sammenlignet med Arweave er Irys' dual-ledger-design mer fleksibel, men også mer kompleks. Arweaves engangsbetalte lagringsmodell for alltid er enkel, mens Irys' lagdelte lagring krever mer kompleks datamigreringslogikk. Sammenlignet med Filecoin fokuserer Irys mer på den faktiske tilgjengeligheten til data i stedet for bare å lagre bevis. Sammenlignet med IPFS forsøker Irys å løse problemet med IPFS sin mangel på insentiver, men på bekostning av å introdusere en kompleks blokkjede-konsensusmekanisme. 5️⃣ Realistiske utfordringer og utsikter Fra et teknisk synspunkt er designet til Irys noe innovativt, spesielt kombinasjonen av VDF+PoA og det doble hovedboksystemet. Men utfordringene i prosjektet er også åpenbare: 5.1. Økologisk konstruksjon: Suksessen til desentraliserte lagringsprosjekter avhenger i stor grad av økologisk konstruksjon, som ikke er et problem som teknologien kan løse alene. 5.2. Langsiktig stabilitet av insentivmekanismer: Hvorvidt komplekse økonomiske modeller kan opprettholde balanse i faktisk drift vil ta tid å verifisere. 5.3. Hard konkurranse: Det er allerede mange modne konkurrenter i dette sporet, og nye prosjekter må ha sterke nok differensieringsfordeler. Uttalelse: Denne artikkelen er basert på analysen av Irys-prosjektkoden, med fokus på dens tekniske arkitektur og designkonsept. Som et prosjekt under utvikling, må den endelige ytelsen verifiseres i faktisk drift. Evalueringen i denne artikkelen er basert på gjeldende kodeimplementering og designdokumentasjon og utgjør ikke investeringsrådgivning.