Na tomto rozlišení záleží. Hard fork není synonymem pokroku. Jde o rozdělení konsensu, při němž uzly musí přijmout nová pravidla platnosti, nebo přestanou sledovat kanonický řetězec. Hua může hard fork obsahovat, ale označovat tuto fázi za hard fork před upřesněním aktivačních pravidel zakrývá skutečnou otázku: dokáže Midnight změnit, kdo síť provozuje, aniž by zneplatnil soukromý stav, na němž už uživatelé a aplikace závisejí?
Midnight spustil svůj genesis block 17. března 2026 s federovaným modelem validátorů. The Block uvedl, že mezi jmenované rané provozovatele patřily Google Cloud, Worldpay, MoneyGram, Bullish, eToro, Blockdaemon a další. Jeho návrh kombinuje samostatný ledger a konsensuální systém s zero-knowledge důkazy, kontrakty Compact a hybridním modelem, v němž může transakce obsahovat veřejná i soukromá data.
Běžný veřejný ledger může migraci ověřit přehráním blocků: začít od genesis, provést každou transakci a porovnat výsledný kořen stavu. Systém zaměřený na soukromí však nese další zátěž. Řetězec může zveřejňovat commitmenty, nullifiery a důkazy, ale witness pro utrácení, tedy data potřebná k tomu, aby držitel prokázal nárok na soukromý note, zůstává lokální. Uzel může ověřit, že je důkaz platný, aniž by witness znal. Nemůže však rekonstruovat soukromý stav každé peněženky pouze z ledgeru.
To je podstatou rizika migrace. Veřejný stav řetězce musí zůstat konzistentní, systém však zároveň musí zachovat schopnost offline nebo jen zřídka používaných peněženek vytvářet po změně pravidel platné witnessy. Upgrade, který udrží validátory synchronizované, ale způsobí, že staré notes nebude možné utratit, není úspěšnou migrací zachovávající soukromí. Jde o událost ztráty stavu, jejíž oběti nemusí být okamžitě patrné.
Plocha kompatibility je širší než konsensus
FAQ Midnightu uvádí, že mainnet začíná v důvěryhodném federovaném systému validátorů s až 13 povolenými uzly a poté se postupně přesune k provozu bez oprávnění. Hua je proto přechodem jak v oblasti pravomocí, tak softwarových předpokladů. Protokol musí prokázat nejen to, že blocky může validovat více stran, ale i to, že tyto strany nezávisle dospějí ke stejnému rozhodnutí o platnosti ze stejných veřejných vstupů.
Tato plocha zahrnuje strom commitmentů ledgeru, pravidla nullifierů, kódování transakcí, ověřovací klíče důkazů, sémantiku jazyka Compact, vytváření witnessů v peněženkách, pravidla řazení, software validátorů a bridge důkazy. Všechny tyto prvky jsou vzájemně provázané.
Příkladem je upgrade důkazového obvodu. Důkazový obvod je omezený program vymezující, co musí prover doložit. Může například prokázat, že note existuje ve stromu commitmentů, nebyl utracen a je autorizován tajným klíčem, aniž by odhalil samotný note nebo tajemství. Pokud Hua důkazový obvod změní, musí určit, zda se notes před H ua budou neomezeně ověřovat starým obvodem, převedou pomocí migračního důkazu, nebo se zabalí do verzované vrstvy kompatibility.
Nebezpečnou možností je implicitní převod. Peněženky nemohou bezpečně odvodit nový formát witnessu pouze z veřejného commitmentu, pokud zásadní soukromý materiál nikdy nebyl na chainu. Protokol musí přesně určit, které historické commitmenty zůstávají utratitelné, jaké proving keys je ověřují a zda peněženka může vytvářet transakci zahrnující starou i novou verzi stavu.
Poznámky k vydání uzlu Midnightu dokumentují konkrétní požadavky na kompatibilitu uzlů a runtime, včetně povinných upgradů validátorů, chování při přehrávání a známého problému se synchronizací. Nejde o vedlejší provozní poznámky. Ukazují, že přehrávání historie a koordinace verzí jsou otázkami bezpečnosti protokolu, a to ještě před rozsáhlejším přechodem k decentralizaci.
Robustní návrh Hua by proto měl verzování výslovně zavést na každé vrstvě. Transakce potřebují verzi formátu. Notes a commitmenty potřebují značku verze nebo jednoznačné oddělení domén. Důkazové obvody potřebují pevně určené ověřovací klíče a veřejný registr klíče přijímaného každou verzí runtime. Kontrakty Compact potřebují hranice sémantických verzí, zejména tam, kde soukromé přechody stavu závisejí na výstupu kompilátoru nebo chování knihoven. Validátoři musí odmítnout transakci, která mísí nekompatibilní verze stavu, pokud protokol nenabízí konkrétní auditovanou cestu převodu.
Checkpointy jsou nezbytné, ale nestačí
Checkpoint kořene stavu je přirozeným kotvicím bodem pro přechod od federované produkce k širší validaci. Ve zvolené výšce blocku se odcházející síť shodne na kořeni stavu, vydání softwaru, sadě ověřovacích klíčů a stavu bridge. Nastupující sada validátorů začne od těchto hodnot. Tím se novým provozovatelům zabrání, aby nenápadně vybrali jinou historii.
Checkpoint však nedokazuje, že federované období bylo správné. Dokazuje pouze, že jej přijímá následující režim. Ve veřejném chainu mohou nezávislí pozorovatelé přehrát historii a otestovat kořen stavu. V chainu zaměřeném na soukromí mohou kontrolovat každý zveřejněný důkaz podle tehdy platných ověřovacích klíčů, nemohou však zkoumat skryté vstupy. Bezpečnostní model proto musí spoléhat na správnost důkazových obvodů, bezchybnost kódu ověřovače, poctivé předpoklady setupu, kde se uplatňují, a na pravidlo, že platný nullifier brání dvojímu utracení note.
Proto je nutné minimalizaci důvěry měřit ve vrstvách. Větší sada validátorů snižuje závislost na původních provozovatelích při produkci blocků. Automaticky však neodstraňuje závislost na autorech důkazových obvodů, setupu důkazového systému, autoritě pro upgrady, bridge relayerech, implementaci peněženky ani na žádném výboru, který může vybrat checkpoint.
Kritický případ je proto závažnější než známá výtka, že federovaný start není decentralizovaný. KuCoin uvedl, že Justin Bons z Cyber Capital zpochybnil decentralizaci Midnightu, transparentnost kódu a distribuci tokenů, zatímco Charles Hoskinson síť charakterizoval jako federovanou v období přechodu k širší účasti uzlů. Nejde o tvrzení, že federace je ze své podstaty nelegitimní. Start zaměřený nejprve na spolehlivost může být racionální volbou nasazení. Podstatné je, že oznámený přechod není totéž jako dokončené odstranění privilegované kontroly.
Cardano Insight Lab argumentoval, že federovaný model vytváří problém důvěryhodnosti, protože tvrzení o soukromí a decentralizaci zůstávají závislá na kontrolované sadě validátorů, dokud nebude přechod dokončen. Learn Midnight označil tuto volbu za záměrný kompromis ve prospěch spolehlivosti a současně uznal napětí mezi jmenovanými institucionálními provozovateli a příslibem blockchainu minimalizovat důvěru.
Oba pohledy ukazují na stejný cíl auditu: odchod od federace.
Co musí Hua zveřejnit
Skutečný milník decentralizace vyžaduje více než novou sestavu validátorů. Hua by měl zveřejnit aktivační výšku, deterministický artefakt runtime, staré a nové ověřovací klíče, matici kompatibility důkazových obvodů, checkpoint kořene commitmentů, pravidla přehrávání a podmínky návratu zpět. Měl by vyžadovat souběžný provoz: kandidátní validátoři nezávisle přehrají produkční historii, ověří stínovou síť od checkpointu a před aktivací porovnají výsledky blocků, kořenů stavu a přijímání důkazů.
Aktivace bridge by měla být oddělena samostatnou podmínkou. Bridge bez nutnosti důvěry přebírá předpoklady finality a platnosti stavu obou propojených chainů. Neměl by začít převádět hodnotu v okamžiku, kdy se nová sada validátorů, nový runtime a nová pravidla důkazů poprvé setkají s produkčním provozem. Nejprve je třeba stabilizovat konsensus. Poté prokázat přehrání historie. Až následně aktivovat bridge důkazy po období nezávislého auditu.
Popis roadmapy v CoinDesku vykreslil Hua jako rozhodující konečný bod. Formulace Foundation je opatrnější: jde o fázi na cestě k decentralizované síti. Právě tento rozdíl by měl určovat hodnocení.
Hua bude mít význam, pokud nezávislý validátor, vývojář peněženky i implementátor bridge dokážou každý samostatně reprodukovat jeho bezpečnostní tvrzení ze zveřejněných artefaktů, bez soukromého seznamu výjimek nebo ujištění důvěryhodného provozovatele. Soukromý stav přežije decentralizaci jen tehdy, když uživatel uchovává tajemství, každý validátor může ověřit jeho důsledek a ani jedna strana nemusí druhé důvěřovat, že zachová minulost.
Jared Zimmerman is not a person. No notebook, no deadlines, no face behind the name — just a byline this newsroom publishes under. Here is the production line underneath it, because a name beside a portrait reads like a journalist, and this one is not one.
The models. Writing: gpt-5.6-luna and gpt-5.6-terra. Out on the live web: gpt-5.6-terra and gpt-5.6-luna. Pictures: gpt-image-1 and flux. Swap one in the newsroom and this line swaps with it — it is read off the machines, not typed here.
How a story is made
- Research. The searching model reads around the story, pointed at primary sources — the filing, the post, the repository — rather than at somebody else's write-up of them.
- Writing. The writing model drafts it against what was found, at Jared Zimmerman's usual length and in Jared Zimmerman's usual register.
- The loop. A reviewer reads the draft and sends it back with notes. Then reads it again. A piece can go round several times before it leaves the building.
- Enrichment. A quotation has to appear word for word on the page it is taken from. A chart may only use figures that appear in the source it cites. Whatever fails is dropped, and the reason is kept.
- Fact check. A last pass hunts for claims the article makes and its sources do not.
- A human stop. Sensitive subjects are held for a person to read before publication, and a person can kill any of it at any point.
If that sounds less like a newsroom and more like a factory: quite. It is called Press Factory.
Tento článek vytvořila umělá inteligence a byl publikován automaticky bez redakční kontroly před zveřejněním. Tento článek byl strojově přeložen z angličtiny a autorství uvedené v byline náleží autorovi původního textu.
How this article was made
The article was produced by the Grandmonts Media News Engine using automated research, drafting and verification workflows. No human editor reviewed the article before publication. Grandmonts Media remains responsible for the published content. Errors can be reported at office@grandmonts.cz.