On-chain identita (ENS a další): kompromis mezi uživatelským komfortem a ochranou datového soukromí

Proč vůbec on-chain identita: lidsky čitelná jména a reputační vrstvy

On-chain identita přináší lidsky čitelná jména (např. alice.eth) a přenosné profily, které fungují napříč peněženkami, aplikacemi a blockchainy. V ideálním případě snižuje tření: místo dlouhých adres používáte aliasy, místo opakovaného „KYC–like“ zadávání údajů přenášíte verifikovatelné tvrzení (credentials). Tyto výhody jsou však spojeny s trvalostí a veřejností záznamů na blockchainu, což vytváří dilema pohodlí vs. soukromí – a v praxi také bezpečnost vs. použitelnost.

Stavebnice on-chain identity: jména, DID a verifikovatelné tvrzení

On-chain jména (např. ENS, ale také alternativní jmenné prostory) poskytují mapování name → adresy/zdroje přes resolver. Zápisy jsou veřejné a strojově zpracovatelné.
DID (Decentralized Identifiers) definují identifikátory jako did:method:… s dokumenty, které uvádějí klíče a služby. DID může odkazovat na on-chain účet, ale nemusí – díky tomu je možná off-chain identita s propojením k blockchainu, když je to potřeba.
Verifikovatelné credentials (VC) umožňují vydávat a dokazovat tvrzení (např. „tento účet patří organizaci X“), ideálně s možností zero-knowledge odhalení pouze nezbytného minima informací.

ENS v kostce: registry, registrář, resolver a záznamy

ENS (Ethereum Name Service) se skládá ze tří vrstev: registry (kdo vlastní které jméno), registrář (pravidla pro získání/obnovu domén, např. .eth) a resolver (kam jméno směřuje). Na úrovni resolveru se typicky nastavují:

Adresy pro různé sítě (ETH, BTC, L2 aliasy, kontrakty),
Textové záznamy (e-mail, url, avatar, sociální profily),
Contenthash (odkaz na IPFS/Arweave obsah),
Reverse record (mapování adresa → jméno pro UX v peněženkách).

Největší riziko ohledně soukromí v praxi vzniká právě u textových záznamů a při zapnutí reverse recordu, které usnadňují navázání veškerého on-chain chování na jednu veřejnou identitu.

Jiné jmenné prostory a sociální identity

Kromě ENS existují alternativní TLD a sociální aliasy (jména v sociálních protokolech, profilové handle v ekosystémech DeFi/SocialFi). Tato jména mohou být:

On-chain NFT domény (převoditelné, s metadaty v kontraktu),
Hybridní (on-chain registrace, off-chain rozlišení přes orákulum/CCIP-Read),
Off-chain (centrální registry s kryptografickými podpisy).

Rozdíly v bezpečnostním modelu (kdo může záznam měnit, jak se dokládá vlastnictví) výrazně ovlivňují důvěryhodnost „identity signálů“ pro airdropy, kurátorství či reputační systémy.

Pohodlí: kde jména opravdu pomáhají

UX při platbách – méně chyb při zadávání adres, vizuální rozlišení příjemce, QR a deeplinky.
Kurátorství a reputace – kurátorské seznamy, podepisování výstupů (blog, kód, výzkum) identitou, která je přenosná a bez platformového lock-inu.
Automatizace – integrace, které čtou resolver (např. avatar, contenthash) a okamžitě aktualizují profil napříč aplikacemi.
Organizační účty – jedno jméno → množství rolí přes subnames (tým@org.eth, grants@org.eth), auditovatelný vlastník v multisigu.

Tmavá stránka pohodlí: deanonymizace a „graph leak“

Pokud adresu spojíte s jménem, každé on-chain průnik (převod, interakce s kontraktem) rozšiřuje veřejně dostupný identity graph. Propojení s CEX výběry/vklady, nákupy NFT, farmění spam transakcí či drop claimy postupně odhalí zvyky, majetek, partnery. Rizika:

Profilování (cílené phishing kampaně, „airdrop“ podvody),
Fyzicko-personální bezpečnost (majetkové cílení),
Compliance/daňové otázky (neúmyslné publikování transakcí spojených s identitou),
Sociální tlaky (veřejná historie hlasování/DAO příspěvků).

Hrozby na aplikační vrstvě: phishing, homoglyfy, typo-squatting

Homoglyfy a vizuální klony: zaměnitelné znaky (latinka vs. cyrilice) v jménech mohou imitovat známou značku.
Typo-squatting: útočník zaregistruje variantu s malou odchylkou (např. alicе.eth s jiným písmenem „e“).
Falešné profily: textové záznamy (twitter, url) přesměrují na phishing.
Supply-chain: kompromitace resolveru nebo webu, který čte záznamy, vede k silent přepisům cílové adresy.

On-chain trvalost a „nezapomenutelnost“

Změny v resolveru jsou sice možné, ale historická mapování a archivní data zůstávají analyzovatelná. To znamená, že i když záznam odstraníte, předchozí úniky mohou kolovat v indexech a datových skladech. Proto je rozumné od začátku modelovat identitu jako vrstvenou a segmentovanou, nikoli jako monolitickou.

Segmentace identity: personální, pracovní, treasury a experimentální

Ověřený a přenositelný vzor, který vyvažuje UX a soukromí:

Veřejná persona – jména, která používáte při komunikaci, PR a sociálních profilech. Omezte finanční toky, používejte rozumné text záznamy (žádné e-maily/telefony).
Provozní účty – pro DAO/projekty s jasným subname prostorem (finance@, ops@), vázané na multisig a politiky.
Treasury a custody – bez reverse recordu, bez zbytečných textových záznamů, oddělené financování, cold procedury.
Laboratorní/experimentační – krátkodobé aliasy pro testy a interakce s novými kontrakty; průběžná rotace.

Subnames, „name wrapper“ a politiky oprávnění

Subdomény (subnames) umožňují delegovat identitu bez sdílení root klíčů. S moderními wrappery lze nastavit trvalá omezení (nepřevoditelnost, zákaz opětovného přiřazení resolveru, expirace), čímž snížíte riziko key compromise u týmů a dodavatelů.

CCIP-Read a off-chain rozlišení: škálování vs. důvěra

Mechanismy typu CCIP-Read umožňují resolveru načíst údaje z off-chain zdroje (server, IPFS) a ověřit je podpisem. Výhody: levnější a flexibilní záznamy. Nevýhody: další důvěra v dostupnost/bezpečnost off-chain komponenty a v správnost podpisových klíčů. U citlivých polí (platební adresy) preferujte on-chain záznamy a minimální množství údajů.

Verifikovatelné credentials a ZK: pohodlí bez úniku

Místo aby jste k profilu přidávali přímá osobní data (jméno, e-mail), používejte VC s volitelným odhalením a ZK důkazy. Příklady použití:

Věk/omezení: prokažte „>= 18“ bez odhalení data narození.
Členství/role: prokažte status v komunitě (člen DAO, contributor) bez odhalení primární adresy.
Sybil odolnost: důkazy singularity (jedna osoba ≠ jedna adresa) bez publikování biometrických dat nebo PII.

Stealth adresy, platební požadavky a oddělení financí

Pokud prostřednictvím veřejného jména sbíráte platby/dary, zvažte modely, v nichž příjemce generuje per-payer cíle (např. mechanismy typu stealth/one-time adresy, „invoice“ s odvozeným klíčem). Minimalizujete tak vazbu „všechny příjmy → jedna adresa“. Pro běžné on-chain platby raději nezveřejňujte master adresu v textových záznamech.

Reverse record: kdy ano a kdy raději ne

Reverse record zlepšuje UX (peněženky zobrazí jméno), ale okamžitě spojuje každou aktivitu daného účtu s reputačním aliasem. Doporučení:

Zapnout pro veřejnou personu s nízkou finanční aktivitou,
Vypnout pro trading, custody a treasury adresy, kde je soukromí základem.

Obnova, expirace a „sniping“

Jména obvykle expirují. Pokud selže obnova, vzniká okno pro sniping (někdo vaše jméno chytí a zneužije reputaci). Nastavte si alerty, automatické obnovy a používejte multisig pro operace s registrátorem. Pro značky je vhodná také registrace obranných variant (snadno zaměnitelné tvary).

Kompatibilita napříč blockchainy: mapování identit v multichain světě

ENS a další jména dokážou mapovat adresy pro různé sítě. Při multichain operacích zavádějte pravidlo: „jedna identita – více cílů, ale každý pouze pro svůj kontext“. Tedy nezveřejňujte univerzální adresy; pro L2/L3 používejte vyhrazené subnames a resolverová pole. Při cross-chain publikování dejte pozor na zpoždění a stale mapování.

Organizační identity: DAO, projekty a právnické osoby

Politiky subnames – pravidla přiřazování, revokace a rotace (onboarding/offboarding členů).
Šablony záznamů – „minimální bezpečný set“ (kontakt → generické issue linky, ne osobní e-maily; avatar → IPFS), zákaz ukládání PII.
Logování a odpovědnost – kdo měnil resolver/registraci, auditní stopa v multisigu, two-person rule.

Právní a compliance úvahy bez zbytečného KYC-lock-inu

On-chain jméno samo o sobě není KYC. Pokud však propojíte profil s právnickou osobou (web, firemní registry), vzniká očekávání konzistence. Pro granty a partnerství používejte VC místo veřejné PII; pro podepsaná oznámení používejte deterministické buildy a podpisy publikované pod identitou (hash na IPFS + podpis peněženkou).

Praktické zásady „privacy by design“ pro on-chain jména

Minimalismus zápisů: udržujte resolver „štíhlý“ (adresy, ne osobní texty; bez e-mailu/telefonu).
Segmentace: minimálně dvě identity – veřejná a finanční; ideálně více podle rolí.
Rotace a expirace: pravidelně revidujte textové záznamy, čistěte staré odkazy, sledujte expirace.
Homoglyph guard: registrujte obranné varianty, používejte vizuální ověřování a varování v UI.
Off-chain VC + ZK: preferujte selektivní odhalení atributů před trvalým on-chain publikováním.
Bezpečné financování: oddělené financování, stealth/invoice adresy, bez reverse recordu pro treasury.
Organizační wrapper: subnames s politikami, nepřevoditelnost podle potřeby, multisig na kritické změny.

Checklist před publikováním identity

Jaké adresy publikuji a proč? Jsou oddělené podle kontextu?
Obsahují text records cokoli, čeho bych litoval, kdyby to zůstalo navždy?
Je reverse record zapnutý jen tam, kde to dává smysl?
Mám plán obnovy, alerty na expirace a obranné domény proti homoglyphům?
Je moje identita navázaná na VC/ZK důkazy místo hrubých PII?
Jsou resolver a registrátor chráněny pomocí multisig/timelock a mám auditovatelný proces změn?