O (de)centralizaci a (definování) latence: Za prvé, existují dva typy centralizace: fyzická vs. logická. Příklady: X(.com) je logicky centralizované, ale logicky decentralizované. Síť PoS může být logicky decentralizovaná, ale fyzicky centralizovaná (jako Hyperliquid, jehož validátory jsou převážně v japonském Tokiu nebo v jeho blízkosti). Jaký je vztah mezi centralizací a latencí? Stručná odpověď zní, že *logická* centralizace může vždy poskytnout (potenciálně) nižší latenci mnoha různých typů, na úkor odporu vůči cenzuře. Jak přesně definujeme latenci přesněji? Toto je můj rámec: ke specifikaci latence potřebujeme tři parametry: (1) začátek měření, (2) konec měření a (3) poskytnutá záruka. Začátek měření může být například v okamžiku, kdy uživatel odešle transakci do uzlu, nebo to může být, když sekvencer tuto transakci přijme. V konečném důsledku jsou nejdůležitější záruky pro účastníky a uživatele systému. Zde jsou některé latence, které jsou zajímavé: 1. Zpoždění potvrzení zařazení: začátek je, když uživatel odešle transakci, konec je, když uživatel obdrží potvrzení, že transakce bude zahrnuta s určitou zárukou. 2. Latence provádění mezi koncovými body: začátek je, když uživatel odešle transakci, konec je, když uživatel obdrží plný efekt transakce (např. realizační cenu tržního swapu DeFi). 3. End-to-end provedení a latence finality: jako 2 výše, ale konec se měří, když je transakce také dokončena konsensem. Opět platí, že všechny tyto míry latence by mohly být nižší pro logicky centralizované, ale fyzicky decentralizované systémy, při ztrátě odolnosti vůči cenzuře (a dalších vlastností, které přicházejí s decentralizací).