Když The Block informoval, že zakladatel Cardana Charles Hoskinson představil Midnight jako partnerský řetězec chránící soukromí, titulky se soustředily na kryptografii řetězce. Fungující síť zaměřená na soukromí ale musí vyřešit praktičtější otázku. Pokud jsou výstupy transakcí stíněné, jak peněženka zjistí, která šifrovaná data patří jejímu uživateli, získá svědka potřebného k jejich utracení, dozví se, které notes byly zneplatněny nullifierem, a zůstane aktuální i při reorganizacích, aniž by indexeru předala průběžný záznam svého finančního života?
Oficiální oznámení Midnightu o spuštění uvádí, že síť byla uvedena do provozu 29. března 2026, čímž vznikla trvalá kontinuita stavu a začala produkční činnost. Tím se povaha této otázky mění. Vyhledávání stíněného stavu už není návrhovou abstrakcí. Jde o problém spolehlivosti, soukromí a infrastruktury, v němž musí peněženky, poskytovatelé služeb i uživatelé fungovat v nepřátelských podmínkách.
Klíčový rozdíl lze snadno přehlédnout. Šifrování může chránit obsah notu. Automaticky ale nechrání samotný akt dotazování na tento note. Peněženka, která opakovaně vyžaduje data související s klíčem pro prohlížení, adresou, nedávnou transakcí nebo konkrétním rozsahem bloků, může odhalit užitečný záznam chování, i když ani peněženka, ani indexer nikdy nevidí nešifrovaná data patřící jinému uživateli.
Účetní kniha může být veřejná, zatímco stav zůstává soukromý
FAQ Midnightu vysvětluje, že jeho architektura ukládá závazky, nullifiery a důkazy do veřejné účetní knihy, zatímco soukromý stav, klíče a vstupy pro důkazy zůstávají zašifrovány v zařízení uživatele. V praxi řetězec potřebuje veřejně ověřitelné důkazy, že transakce je platná a že dříve utratitelný note nebyl utracen dvakrát. Nemusí zveřejňovat každý detail, který odesílateli umožnil tento důkaz sestavit.
Toto rozdělení vytváří dva odlišné úkoly.
Prvním je konsensus. Uzly ověřují transakce, udržují strom závazků, zaznamenávají nullifiery a shodují se na blocích. Druhým je obnova soukromého stavu. Peněženky musí určit, které šifrované texty jsou relevantní, tyto šifrované texty lokálně dešifrovat nebo jinak testovat, udržovat vlastní sadu notes, přiřazovat notes ke stromu závazků a sestavit svědka a důkaz potřebné pro pozdější utracení.
Právě při druhém úkolu může soukromí nenápadně zmizet.
Závazek je viditelný pro všechny a lze jej vložit do veřejného stromu závazků. Nullifier je rovněž veřejný a umožňuje validátorům odmítnout druhý pokus o utracení stejného notu. Peněženka naopak potřebuje soukromá data notu a jeho pozici nebo cestu v příslušném stromu. Veřejný řetězec tak může prokázat, že určitý přechod stavu byl legitimní, zatímco každý uživatel musí sám zjistit, zda mu byl určen některý šifrovaný výstup.
To není totéž jako stažení běžného zůstatku účtu. V řetězci založeném na účtech se peněženka často může dotázat na zůstatek adresy a seznam transakcí. Ve stíněném systému může peněženka potřebovat procházet proud šifrovaných výstupů, testovat, zda každý z nich dokáže dešifrovat nebo rozpoznat, a poté sestavit vlastní lokální pohled na utratitelný stav.
To je základní infrastrukturní zátěž: soukromý stav není jednoduše uložen. Je nutné jej najít.
Co indexer může vědět a co mohou prozradit jeho požadavky
Oficiální repozitář Midnight Indexer popisuje systém zahrnující indexer řetězce, API indexeru, indexer peněženek a indexer SPO, který používá komponenty včetně PostgreSQL, NATS a přístupu přes GraphQL. Toto rozdělení je důležité, protože ukazuje, že produkční architektura není jediná neprůhledná databáze. Jde o proces, který přijímá aktivitu řetězce, ukládá a distribuuje indexované informace a obsluhuje různé typy klientů.
Repozitář nezajišťuje soukromí každého nasazení už ve výchozím nastavení. Žádná architektura indexeru to nemůže zajistit pouhým ukládáním šifrovaných textů.
Indexer nemusí být schopen číst obsah notes peněženky, přesto může sledovat:
- síťovou adresu a časování požadavků peněženky, pokud provoz není přesměrován nebo jinak chráněn;
- výšku bloku, na níž peněženka zahajuje nebo obnovuje synchronizaci;
- četnost a velikost požadavků na synchronizaci;
- zda se klient opakovaně dotazuje na úzký rozsah dat;
- který vzorec odběru či API používá pro aktualizace;
- metadata na úrovni služby, například chyby, opakované pokusy a délku relace.
FAQ rovněž popisuje viditelná metadata transakcí a bloků. Přesný rozsah veřejně dostupných údajů je důležitý, protože závazky, nullifiery, zahrnutí transakce a řazení bloků slouží účelům konsensu. Tento veřejný záznam může podporovat infrastrukturu užitečnou pro peněženky, ale může také umožnit korelaci, pokud uživatelé, provozovatelé služeb nebo třetí strany propojí časování a síťovou aktivitu s externími informacemi.
To je rozdíl mezi důvěrnými daty a soukromým přístupem. Šifrovaný text může být chráněn před přímým čtením. Opakovaná interakce peněženky se systémem však stále může prozradit, že je aktivní, přibližně kdy přijala prostředky, kdy se pokusila o utracení a zda reaguje na konkrétní událost v řetězci.
Rizikem pro soukromí není selhání důkazu. Jde o sledování na okrajích systému.
Nightriders argumentovali, že časování, poplatky, nullifiery, financování peněženek a selektivní zveřejňování mohou vytvářet chování, které lze vzájemně propojit, i když je obsah transakcí šifrován. Jde o názor, nikoli o zjištění týkající se protokolu, správně však vymezuje cíl auditu: systém kolem důkazu, včetně požadavků, opakovaných pokusů, endpointů a časování.
Čtyři způsoby distribuce stíněného stavu
Soukromá synchronizace peněženky nemá jediné řešení. Existují kompromisy mezi šířkou pásma, latencí, hardwarem klienta, provozními náklady a důvěrou. Užitečné srovnání nespočívá v abstraktním dělení na centralizované a decentralizované systémy. Podstatné je, která strana vidí vzorec dotazů, kdo může data zadržet a co dokáže peněženka nezávisle ověřit.
| Model | Co peněženka získává | Hlavní riziko pro soukromí | Hlavní provozní riziko |
|---|---|---|---|
| Centralizovaný indexer | Cílená data o notes a svědcích | Indexer může sledovat požadavky a časování | Cenzura, zastaralá data, selektivní zadržování |
| Skenování na straně klienta | Široký proud bloků nebo výstupů | Menší specifičnost dotazů, síťový provoz však zůstává viditelný | Vysoké nároky na šířku pásma, úložiště a baterii |
| Replikované indexery | Data od několika nezávislých služeb | Korelace, pokud jsou dotazy u různých poskytovatelů stejné | Vyšší náklady a složitější kontroly konzistence |
| Delegované skenování | Služba skenuje jménem peněženky | Delegát se může dozvědět o oprávnění k prohlížení nebo aktivitě | Správa klíčů a koncentrace důvěry |
| Infrastruktura provozovaná uživatelem | Lokálně řízený uzel a indexer | Menší vystavení dotazů třetím stranám | Významná údržba a nároky na zdroje |
Centralizovaný indexer poskytuje mobilní peněžence nejplynulejší používání. Dokáže skenovat data řetězce, uchovávat relevantní struktury, poskytovat kompaktní API a vracet data potřebná k synchronizaci. Cenou je, že indexer se stává privilegovaným pozorovatelem. I když nedokáže dešifrovat obsah notes, může potenciálně vytvářet záznam o chování klienta.
Skenování na straně klienta volí opačný přístup. Peněženka stahuje dostatečně široký proud dat a relevanci určuje lokálně. Tím se minimalizuje potřeba zveřejnit přesnou množinu zájmů, zátěž se však přesouvá na zařízení. Kompletní datový proud může být náročný na šířku pásma, úložiště, čas procesoru i výdrž baterie. Systém se také musí bránit škodlivě utvářeným datům, která mají vyčerpat zdroje klienta.
Kompaktní filtry představují střední cestu. Server může distribuovat malé shrnutí pro každý blok, navržené tak, aby peněženky mohly levně rozhodnout, zda blok může obsahovat relevantní data. Peněženka pak stahuje pouze pravděpodobné shody. Technickým problémem je, že kompaktní filtry často umožňují falešně pozitivní výsledky, které mohou zastřít relevanci a vyvolat další stahování, soukromí ale závisí na konstrukci filtru a vzorcích následného získávání dat. Filtry také vyžadují pečlivou konstrukci: pokud se peněženka dotazuje jen na několik odpovídajících bloků, samotný vzorec požadavků může uživatele identifikovat.
Soukromé získávání informací nabízí jiný kompromis. Namísto přímého požadavku na konkrétní položku u indexeru může peněženka použít protokol, jehož cílem je skrýt, kterou položku získala. Teoreticky se tím omezuje přímý únik informací z dotazů. V praxi to přidává výpočetní nároky na server, složitost pro klienta a nové otázky ohledně dávkování požadavků, vzorců provozu a ochrany před útoky typu denial-of-service. PIR může skrýt index v databázovém dotazu. Sám o sobě však nemůže skrýt, že je konkrétní zařízení aktivní v určitou dobu.
Replikované databáze mohou omezit moc kteréhokoli jednotlivého poskytovatele, zejména pokud peněženka porovnává odpovědi, střídá poskytovatele nebo odděluje získávání bloků od získávání svědků. Replikace ale soukromí automaticky nevytváří. Odeslání stejného charakteristického dotazu třem indexerům může třem provozovatelům poskytnout stejný behaviorální graf. Přínos pro soukromí závisí na protokolu získávání dat, nezávislosti provozovatelů a na tom, zda klient dokáže zabránit tomu, aby byl jeho vzorec požadavků jedinečně rozpoznatelný.
Delegované skenování je pro omezená zařízení často lákavé. Uživatel opravňuje službu, aby identifikovala relevantní výstupy a poskytla připravený pohled peněženky. Může to být praktické, je však třeba věc pojmenovat otevřeně: důvěra při skenování se přesouvá ze zařízení na prostředníka. Přijatelnost takového řešení závisí na tom, které klíče nebo oprávnění jsou delegovány, co z nich může služba vyvodit a zda peněženka dokáže ověřit úplnost.
Dostupnost je součástí soukromí
Oficiální repozitář Midnight Wallet SDK ukazuje, že peněženky synchronizují stíněný stav přes klienta indexeru a zároveň odděleně komunikují s uzly Midnightu a klienty pro vytváření důkazů. Toto oddělení je cenné, protože vytváří možnost vzájemné kontroly. Indexer může poskytovat použitelný pohled na data řetězce, zatímco uzel nabízí nezávislý referenční bod pro stav bloků, kořeny či další informace o konsensu.
Oddělení však pomáhá jen tehdy, pokud se skutečně využívá.
Diskuse k problému v Midnight Wallet upozornila, že dokončení synchronizace může být měřeno vůči vrcholu řetězce, který indexer sám uvádí, bez nezávislé kontroly finality. Diskuse navrhovala kontrolovat kořeny stromu závazků a stav bloků vůči uzlu. Jde o kritický pohled přispěvatelů projektu, nikoli o důkaz, že tímto způsobem selhává každé nasazení. Přesto poukazuje na základní vlastnost, kterou stíněná peněženka potřebuje: musí rozlišovat mezi tvrzením „služba říká, že jsem synchronizován“ a stavem „můj stav odpovídá stavu řetězce nezávisle ověřenému sítí“.
Indexer, který zadrží šifrovaný výstup, jej nemusí ukrást. Může udělat něco nenápadnějšího: přimět uživatele, aby věřil, že jeho zůstatek je nižší, než ve skutečnosti je, zabránit tomu, aby se note zobrazil jako utratitelný, nebo zpozdit reakci peněženky na platbu. Dostupnost a úplnost proto patří do modelu soukromí. Uživatel, který po selhání synchronizace musí naléhavě přejít k odhalující službě, nedostal úplnou záruku soukromí.
Poznámky k vydání Wallet SDK popisují opravy a omezení týkající se dostupnosti indexeru, zastaralých dat, ztracených odběrů, chování při opakovaných pokusech a počáteční absence nezávislých kontrol indexeru pro stíněné a DUST peněženky. I zde je předložen pouze kritický pohled. Nebylo poskytnuto žádné opačné hodnocení, a není tedy důvod je vytvářet.
Reorganizace, svědci a denial-of-service
Produkční indexer stíněného stavu potřebuje víc než rychlou databázi.
Potřebuje politiku pro reorganizace. Pokud je blok nahrazen, peněženka možná musí odebrat notes, aktualizovat svou pozici ve stromu závazků, zahodit cestu svědka nebo znovu skenovat od bezpečného předka. Indexer by měl sdělovat identitu bloku, jeho výšku, vztah k rodičovskému bloku a stav finality způsobem, který peněženka dokáže ověřit vůči uzlu. Pouhá monotónně rostoucí „nejnovější výška“ nestačí.
Potřebuje politiku pro svědky. Note není utratitelný jen proto, že jej peněženka rozpoznala. Peněženka rovněž potřebuje příslušné informace o stromu závazků, aby prokázala příslušnost. API indexeru by měla umožnit získat nebo rekonstruovat svědky při definovaných stavech řetězce a klienti by měli ověřovat kořeny namísto přijímání neověřené cesty jako pravdy.
Potřebuje politiku ukládání dat. Uchovávání každého šifrovaného výstupu, závazku, nullifieru, aktualizace stromu a historických materiálů svědků vytváří tlak na růst. Prořezávání může snížit náklady, ale neopatrné prořezávání promění staré notes v problém obnovy. Systém by měl uvádět, která historická data lze znovu vytvořit z bloků, která data se uchovávají a co potřebuje nové zařízení k bezpečné obnově peněženky.
A potřebuje politiku pro denial-of-service. Útočník se může pokusit zahltit indexery nákladnými dotazy GraphQL, vytvářet úlohy, které nutí klienta k nadměrnému skenování, vyvolávat opakovanou resynchronizaci nebo zneužívat chování při opětovném připojení odběrů. Omezení rychlosti, stránkování, ověřené úrovně služeb a omezená velikost odpovědí mohou dostupnosti pomoci, každý z těchto nástrojů však může mít náklady na soukromí, pokud usnadní identifikaci intenzivních či neobvyklých uživatelů.
Praktický princip návrhu je přímočarý: peněženka by měla indexer považovat za službu pro výkon, nikoli za nejvyšší autoritu ohledně obsahu řetězce.
Co musí prokázat důvěryhodný návrh stíněného stavu
Otázkou pro Midnight není, zda mohou stíněná data existovat ve veřejné účetní knize. Jeho model dvojího stavu je navržen právě kolem tohoto oddělení. Otázkou je, zda okolní architektura získávání dat dokáže zajistit použitelnost soukromého stavu, aniž by každou peněženku proměnila v předvídatelného klienta malé skupiny datových brokerů.
Audit peněženky a indexeru by měl položit tyto otázky:
- Dokáže peněženka nezávisle ověřit synchronizovaný vrchol řetězce, kořen stromu závazků a stav reorganizace?
- Dokáže odhalit chybějící data, namísto pouhého přijetí prohlášení indexeru o úplnosti?
- Jaká přesná metadata získává indexer z běžné synchronizace a odběrů?
- Mohou uživatelé zvolit skenování na straně klienta, více poskytovatelů, lokální infrastrukturu nebo získávání dat chránící soukromí?
- Jaké jsou náklady jednotlivých možností na šířku pásma, latenci a baterii?
- Jak se pracuje s daty svědků, historickou obnovou a prořezáváním?
- Které ochrany proti denial-of-service odhalují neobvyklé chování uživatelů?
Šifrování chrání to, co může pozorovatel přečíst. Soukromý přístup určuje, co z něj může vyvodit. Živá síť Midnightu činí z této druhé otázky problém, na který nyní musí vývoj peněženek veřejně odpovědět.
Jesica Davis 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 Jesica Davis's usual length and in Jesica Davis'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.