Modulära blockkedjor: följ exekvering, data och avveckling
En modulär blockkedja delar upp ansvar mellan komponenter snarare än att be ett system att utföra varje uppgift. Det kan få en nätverksbeskrivning att låta enkel: exekvering sker här, data går dit och avveckling sker någon annanstans. Den viktiga frågan är vad varje komponent faktiskt garanterar.
Den här artikeln jämför arkitektoniska roller, inte symboliska priser eller en rankning av projekt. En modulär design innebär inte automatiskt lägre risk, högre investeringsavkastning eller identisk säkerhet för alla implementeringar.
Separera jobben innan du jämför system
Utförande tillämpar transaktionsregler och beräknar en föreslagen tillståndsändring. Datatillgänglighet handlar om huruvida den information som behövs för att verifiera systemet har gjorts tillgänglig. Avveckling handlar om hur kryptografiska åtaganden om kedjans tillstånd (state commitments), bevis eller tvister accepteras enligt ett visst protokoll. Consensus bestämmer överenskommen ordning eller accepterad historik inom ett system.
Dessa roller kan överlappa eller fördelas på olika sätt. Projektetiketter räcker inte: ett nätverk kan kalla sig modulärt samtidigt som det behåller betydande kontroll i en sequencer, uppgraderingsnyckel eller datakommitté. Rita den faktiska beroendekartan istället för att anta att alla modulära nätverk delar en förtroendemodell.
Ethereums dokumentation om datatillgänglighet förklarar varför verifiering beror på tillgång till transaktionsdata och varför lätta kunder och sammanslagningar behöver lämpliga garantier. Dataåtkomst är en annan fråga än om en utförd beräkning är korrekt.
Följ en hypotetisk transaktion
Föreställ dig att en användare skickar en transaktion till ett exekveringsnätverk. En sequencer inkluderar den i en batch. Systemet gör den erforderliga informationen tillgänglig med hjälp av dess valda datalager och skickar ett kryptografiskt åtagande om kedjans tillstånd (state commitment), med den verifieringsmekanism som krävs av dess design, till ett avvecklingslager.
Användaren kan se en tidig bekräftelse innan varje steg når sin slutliga status. Registrera vad varje status betyder: mottagen, ordnad i sekvens, utförd, data publicerad, bevis accepterat eller bestridande fönster avslutat. Märk inte den tidigaste bekräftelsen som slutlig avräkning om inte protokollet stödjer den tolkningen.
Det här exemplet beskriver roller snarare än att föreskriva en universell sekvens. Olika rollups och modulära system kan kombinera steg eller använda olika bevis- och slutgiltiga arrangemang.
Fråga vad som händer när en komponent misslyckas
Om en sequencer stannar, kan användare skicka transaktioner på ett annat sätt, och under vilka förhållanden? Om en datatjänst undanhåller information, vem upptäcker den och vad kan användarna verifiera? Om ett avvecklingslager är överbelastat, hur påverkas åtaganden eller uttag?
Svara på dessa frågor från aktuell dokumentation, inklusive nödprocedurer och administrativa kontroller. En reserv som beskrivs i en färdplan är inte nödvändigtvis operativ. Ett nätverk som fortsätter att visa saldon kan fortfarande ha nedsatt förmåga att acceptera transaktioner eller slutföra uttag.
Granska bryggberoenden separat. En token som visas på två nätverk betyder inte att överföringsvägen ärver alla säkerhetsegenskaper hos båda kedjorna.
Jämför hela kostnaden och användarupplevelsen
En låg utförandeavgift är bara en del av transaktionens kostnad. Datapublicering, avveckling, överbryggning och uttag kan lägga till avgifter eller förseningar. Jämför motsvarande åtgärder under samma period och förklara vem som betalar vilken kostnad.
Mät hela rutten som är relevant för användaren: inträde, utförande, bekräftelse, uttag och återgång till önskad tillgång eller nätverk. Ett riktmärke som endast omfattar en etapp ska inte presenteras som priset för en hel tur och retur. Kostnadsbesparingar kan också variera med efterfrågan och förhållandena i dataskiktet.
Använd en checklista för beroende
För varje system, registrera utföranderegler, beställningsmyndighet, dataplats, verifieringsmekanism, avvecklingsdestination, uppgraderingskontroller och exitprocedur. Markera vilka anspråk som är aktiva och vilka som är planerade. Inkludera källor och det kontrollerade datumet, eftersom arkitektoniska inställningar kan ändras.
För ett relaterat men distinkt problem, läs cross-chain message comparison: den följer instruktioner mellan kedjor, medan den här guiden följer arbetsfördelningen i en arkitektur.
Ett protokolls tekniska design och dess tokens ekonomiska rättigheter är separata forskningsfrågor. Kontrollera tokens nytta och faktisk marknadstillgänglighet oberoende av officiell dokumentation och OrangeX-marknadssidan, istället för att behandla ett skalningsanspråk som en handelsslutsats.
