Veřejné spuštění Midnightu v březnu 2026 změnilo praktickou otázku, před níž stojí vývojáři aplikací zaměřených na soukromí. Síť už není jen plánem selektivního zveřejňování a chráněného stavu smart contractů. Jde o produkční prostředí, které zpočátku provozuje federovaný soubor validátorů a v němž aplikace musí před přijetím transakce sítí převést soukromý záměr uživatele na platný zero-knowledge důkaz. The Block uvedl, že Midnight vytvořil svůj genesis block 17. března 2026 a veřejně debutoval později téhož měsíce.
Prover se tím stává součástí kritické cesty aplikace.
Platný důkaz může prokázat, že uživatel měl právo provést změnu stavu, aniž by zveřejnil podkladové soukromé vstupy. Neprokazuje však, že uživatel dokáže získat kapacitu pro vytvoření důkazu, že je příslušný svědek aktuální, že požadavek dorazí k uzlu ani že peněženka uchovává dostatek stavu pro pozdější utrácení. Jde o oddělené technické problémy a soukromá aplikace, která je zamění, nakonec uživatele nechá čekat před načítacím kolečkem.
Architektura Midnightu rozděluje stav smart contractů mezi veřejný stav on-chain a lokální soukromý stav, přičemž uživatelé změny svého stavu prokazují před odesláním transakcí. Výzkumný článek z roku 2025, který The Block publikoval ve spolupráci s Midnightem, popsal rozhraní v prohlížeči a rozšíření komunikující s důkazovým serverem, dále indexer a nehlasující uzel pro aktualizace sítě. Důležitou produkční otázkou není, zda důkazový server existuje. Jde o to, kdo jej provozuje, co vidí a co aplikace udělá, když selže.
Cesta transakce od záměru po finalitu
Představme si soukromý převod nebo kontrolu regulovaného oprávnění. Uživatel v peněžence stiskne potvrzení. Tím vše teprve začíná.
Nejprve peněženka nebo aplikace vytvoří záměr: převést tuto částku, zavolat tuto funkci smart contractu, předložit toto oprávnění nebo aktualizovat tento soukromý záznam. Určí verzi smart contractu, očekávaný veřejný stav, zdroje pro poplatky a dobu vypršení transakce.
Za druhé shromáždí svědka. Svědek představuje soukromý materiál potřebný k uspokojení důkazového obvodu: tajné klíče, poznámky nebo lokální záznamy, autentizační cesty, šifrovaný stav, soukromé vstupy a případně nedávná data z řetězce nutná k prokázání, že utrácený nebo aktualizovaný stav je stále platný. Přesný obsah závisí na konkrétním důkazovém obvodu. Klíčové je něco jednoduššího: svědek je často citlivější než samotná transakce.
Za třetí prover spustí důkazový obvod nad záměrem, veřejnými vstupy a svědkem. Pokud jsou splněna všechna omezení, vytvoří důkaz spolu s veřejnými výstupy, které síť musí vidět, například nullifier, commitment, odkaz na kořen stavu nebo zveřejněný výsledek kontroly souladu.
Za čtvrté peněženka tyto výstupy zabalí do transakce a podepíše autorizaci, kterou protokol vyžaduje. Transakce se odešle na koncový bod pro podání nebo uzel. Validátoři ověří důkaz podle ověřovacího klíče důkazového obvodu a veřejných vstupů a poté transakci zařadí, pokud splňuje také pravidla konsenzu a změny stavu.
Zásadní rozdíl spočívá v tom, že ověřování důkazů je dostatečně levné na to, aby je zajišťovala síť, zatímco vytváření důkazů může zajišťovat zařízení nebo služba. Validátor nepotřebuje svědka. Potřebuje pouze důkaz, veřejné vstupy a správný ověřovací klíč. Nákladnou práci vykonává prover a podle zvolené topologie může pracovat s nejvíce soukromými daty uživatele.
Platnost není dostupnost
Zero-knowledge technologie odpovídá na úzce vymezenou otázku: prokázal někdo, že tato změna dodržuje pravidla důkazového obvodu, aniž by odhalil svědka?
Neodpovídá však na čtyři provozní otázky:
- Dostupnost: Může uživatel právě nyní kontaktovat prover?
- Latence: Dokončí se vytváření důkazu dříve, než uživatel proces opustí nebo transakce vyprší?
- Aktuálnost: Je svědek vytvořen ze stavu, který stále odpovídá řetězci?
- Soukromí metadat: Kdo zjistí, že tento uživatel požádal o tento důkazový obvod v tomto okamžiku z této síťové adresy?
Důkazová služba může být dokonale poctivá a vysoce dostupná, přesto může shromažďovat časování, IP adresu, identifikátor důkazového obvodu, dobu vytváření důkazu, velikost požadavku, verzi klienta a chování při opakovaných pokusech. U soukromé mzdové aplikace, procesu ověřování zdravotního oprávnění nebo AI agenta jednajícího za uživatele může být takový vzorec významný, i když služba nikdy nečte tajný klíč.
Přehled Midnightu od CoinDesk z roku 2025 popsal ranou federovanou fázi na začátku roku 2026 jako stabilní produkční prostředí provozované kombinací IOG a externích podnikových operátorů, před pozdějšími kroky k decentralizaci. Federovaní validátoři mohou pomoci spolehlivému spuštění řetězce. Neznamenají však automaticky decentralizaci cesty vytváření důkazů. Aplikace stále může zavést jediného poskytovatele vytváření důkazů, a vytvořit tak závislost na soukromých datech a dostupnosti mimo konsenzus.
Tři topologie vytváření důkazů
Neexistuje univerzálně správný model. Volba závisí na citlivosti svědka, očekávaném objemu transakcí, typu zařízení a toleranci vůči provozní závislosti.
| Topologie | Kdo vytváří důkaz | Co může operátor vidět | Nejvhodnější použití | Hlavní náklad |
|---|---|---|---|---|
| Lokálně v prohlížeči | Zařízení uživatele | V ideálním případě nic kromě běžného RPC provozu | Vysoké soukromí, nižší objem, technicky zdatní uživatelé | Pomalá zařízení, velké artefakty, limity paměti prohlížeče |
| Služba provozovaná aplikací | Vlastní infrastruktura aplikace | Potenciálně záměr, svědek nebo šifrovaný svědek a metadata | Spotřebitelské produkty vyžadující předvídatelné UX | Aplikace se stává správcem soukromí a dostupnosti |
| Externí prover | Specializovaný poskytovatel | Přinejmenším metadata, případně soukromé vstupy pro vytvoření důkazu | Aplikace s vysokým objemem a potřebou spravované infrastruktury | Koncentrace u třetí strany a smluvní důvěra |
Lokální vytváření důkazů v prohlížeči
Lokální vytváření důkazů v prohlížeči poskytuje nejčistší hranici důvěry. Svědek zůstává v peněžence nebo prohlížeči. Aplikace může stáhnout artefakty důkazového obvodu, odvodit lokální stav, vytvořit důkaz a odeslat jej prostřednictvím jednoho nebo více uzlů.
Jde o lepší návrh, pokud aplikace slibuje, že nemůže nahlížet do soukromých finančních, identitních nebo agentových dat uživatele. Zvyšuje také odolnost: výpadek komerčního proveru nezastaví uživatele s kompatibilní peněženkou a dostupným koncovým bodem RPC.
Náklady jsou reálné. Vytváření důkazů může spotřebovávat paměť, výkon procesoru, baterii i čas. Velké dokazovací klíče je nutné bezpečně distribuovat a přesně verzovat. Mobilní prohlížeče a zařízení s omezeným hardwarem mohou z kryptografické záruky udělat nepoužitelný software. Vývojáři by měli měřit mediánové i mezní doby vytváření důkazů na nejslabším podporovaném zařízení, nikoli na notebooku vývojáře.
Vytváření důkazů provozované aplikací
Hostovaný prover nabízí nejplynulejší uživatelskou zkušenost. Aplikace může ukládat artefakty do mezipaměti, využívat optimalizovaný hardware, automaticky škálovat pracovní procesy a centrálně sledovat selhání. Tam, kde to architektura umožňuje, může také dávkovat pracovní zátěže.
Tvrzení, že „svědek je při přenosu šifrovaný“, však neodpovídá na otázku soukromí. Otázkou je, zda služba svědka dešifruje nebo přijímá dostatek soukromého materiálu k vytvoření důkazu. Pokud ano, nachází se uvnitř hranice důvěryhodnosti. To vyžaduje výslovná pravidla uchovávání dat, řízení přístupu, nakládání s pamětí, redakci záznamů, reakci na incidenty a auditní stopu.
Lépe obhajitelnou střední cestou je vzdálené vytváření důkazů nad šifrovaným nebo rozděleným návrhem svědka, kdy služba přijímá méně než přímo utratitelný tajný údaj. Snižuje to riziko, neodstraňuje však únik metadat ani nutnost důvěřovat implementaci služby. Kryptografie by měla zmenšovat rozsah škod, nikoli se stát marketingovým synonymem pro nulovou důvěru.
Externě zajišťovaná infrastruktura proveru
Vyhrazený poskytovatel proveru může být racionální volbou pro velkou aplikaci. Může provozovat specializovaný hardware, spravovat ukládání artefaktů do mezipaměti a poskytovat kapacitu napříč regiony. Nevýhoda je zřejmá: aplikace přebírá výpadky poskytovatele, limity počtu požadavků, pravidla telemetrie, tempo aktualizací i obchodní riziko.
Pro soukromé procesy je vhodné využívat alespoň dva nezávisle provozované poskytovatele nebo zachovat lokální záložní řešení pro privilegované uživatele. Druhý koncový bod pod stejným cloudovým účtem je jen divadlem redundance.
Pět selhání, která vyžadují produktové rozhodnutí
Zastaralý lokální svědek. Jiná transakce může během vytváření důkazu spotřebovat poznámku, změnit kořen smart contractu nebo zneplatnit předpoklad. Se zastaralým stavem je třeba zacházet jako s běžnou cestou opakování, nikoli jako s výjimečnou chybou. Je nutné znovu načíst stav, znovu sestavit svědka a znovu vytvořit důkaz. Starý důkaz se nikdy nemá bez kontroly znovu odesílat.
Prover, který zjišťuje časování požadavků. I když svědek nikdy neopustí peněženku, vzdálený koncový bod může zjistit, kdy se aktivuje konkrétní důkazový obvod. Riziko lze snížit přímým odesláním po lokálním vytvoření důkazu, relé podle potřeby, hrubší telemetrií, krátkou dobou uchování, doplňováním požadavků tam, kde je to praktické, a absencí identifikátorů uživatelů v záznamech proveru.
Pád po vytvoření důkazu, ale před odvysíláním. Důkaz může být platný, zatímco peněženka nemá záznam o tom, zda transakce dorazila do sítě. Před odvysíláním je nutné uložit šifrovaný deník transakcí. Měl by obsahovat podepsanou transakci, artefakt důkazu nebo reprodukovatelné vstupy pro vytvoření důkazu, čas odeslání, identifikátor idempotence a aktuální stav. Po restartu je třeba před vytvořením náhradní transakce ověřit její zařazení.
Nekompatibilní artefakty po aktualizaci. Důkaz je vázán na důkazový obvod a ověřovací klíč. Pokud se síť nebo smart contract aktualizuje, mohou důkazové klíče uložené v mezipaměti vytvářet důkazy, které validátoři odmítnou. Každý artefakt důkazového obvodu je třeba verzovat pomocí neměnného hashe, před vytvářením důkazů vyžadovat kontrolu kompatibility a dřívější artefakty uchovat, dokud neuplyne doba platnosti všech transakcí, které je používají.
Obnovení peněženky bez stavu umožňujícího utrácení. Seed fráze může obnovit klíče, nikoli však nutně každý lokální záznam, šifrovanou poznámku nebo mezipaměť svědků potřebnou pro efektivní utrácení. Je nutné přesně definovat, co záloha obnovuje: pouze klíče, klíče včetně šifrovaného soukromého stavu, nebo obnovitelnou historii rekonstruovanou z důvěryhodného zdroje. Obnovu je nutné otestovat na novém zařízení, než se peněženka označí za obnovitelnou.
Převod architektury na požadavky
Užitečné posouzení návrhu by mělo přinést odpovědi, které lze testovat:
- Kde se každá třída materiálu svědka nachází, v otevřené podobě i uložená?
- Lze vytvořit důkaz a odeslat jej, pokud není primární prover k dispozici?
- Jaká je maximálně přijatelná latence vytváření důkazu na 95. percentilu?
- Které události zaznamenávají peněženka, aplikace, prover a poskytovatel RPC?
- Jaká metadata může každý operátor vzájemně propojit?
- Jak klient vyhledává, ověřuje a vrací zpět artefakty důkazových obvodů?
- Může uživatel zjistit, zda byla přerušená transakce zařazena?
- Jaká přesná data jsou nutná k obnovení schopnosti utrácet?
Doporučení je přímočaré. Pokud je soukromí produktem a hardware to umožňuje, výchozí volbou by mělo být lokální vytváření důkazů v prohlížeči. Službu provozovanou aplikací je vhodné použít, pokud to vyžaduje uživatelská zkušenost, je však nutné s ní zacházet jako s bezpečnostně kritickým systémem, který může pracovat se soukromými daty. Externí vytváření důkazů má smysl používat pouze s definovanou cestou při výpadku, pravidly pro metadata a plánem odchodu.
Midnight dokáže ověřit správný důkaz, aniž by viděl svědka. To je kryptografický úspěch. Aplikace však stále musí zajistit, aby bylo vytváření důkazů dostupné, obnovitelné a soukromé vůči lidem, kteří je provozují.
- Web Summit · CC BY 2.0
Tento článek byl napsán s pomocí umělé inteligence a publikován automaticky. Tento článek byl strojově přeložen z angličtiny a autorství uvedené v byline náleží autorovi původního textu.