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 se však pojí s trvalostí a veřejností záznamů na blockchainu, což vytváří dilema komfort vs. soukromí – a v praxi i 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 směřovat na on-chain účet, ale nemusí – díky tomu je možná off-chain identita s propojením na řetězec, 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 nejnutnější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 (email, 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ší privacy riziko v praxi vzniká právě u textových záznamů a při zapnutí reverse recordu, které usnadňují propojení veškerého vašeho 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 změnit, jak se dokazuje vlastnictví) výrazně ovlivňují důvěryhodnost „signalů identity“ pro airdropy, kurátorství či reputační systémy.
Komfort: kde jména skutečně 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řenositelná 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 → mnoho rolí přes subnames (tým@org.eth, grants@org.eth), auditovatelný vlastník v multisigu.
Temná stránka komfortu: 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, farmování spam transakcí či drop claimy postupně odhalí zvyky, majetek, partnery. Rizika:
- Profilování (cílené phishingové kampaně, „airdop“ scamy),
- Fyzicko-personální bezpečnost (cílení na majetek),
- Compliance/daňové otázky (neúmyslné zveřejně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 vrstevnatou a segmentovanou, nikoliv 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é textové 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í/experimentální – krátkodobé aliasy na 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 re-assignu resolvera, 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 komponentu a ve správnost podpisových klíčů. U citlivých polí (payment adresy) preferujte on-chain záznamy a minimální množství údajů.
Verifikovatelná credentials a ZK: komfort bez úniku
Místo připojování přímých osobních údajů k profilu (jméno, email) používejte VC s volitelným odhalením a ZK důkazy. Příklady použití:
- Věk/omezení: dokažte „>= 18“ bez odhalení data narození.
- Členství/role: dokažte status v komunitě (DAO člen, contributor) bez odhalení hlavní adresy.
- Sybil odolnost: důkazy jedinečnosti (jedna osoba ≠ jedna adresa) bez publikování biometrie nebo PII.
Stealth adresy, platební požadavky a oddělení financí
Pokud přes veřejné jméno sbíráte platby/dary, zvažte modely, ve kterých příjemce generuje per-payer cíle (např. mechanismy typu stealth/one-time adresy, „invoice“ s odvozeným klíčem). Minimalizujete tím 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í:
- Zapnuto pro veřejnou personu s nízkou finanční aktivitou,
- Vypnuto pro trading, custody a treasury adresy, kde je soukromí prvořadé.
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 (lehce zaměnitelné tvary).
Kompatibilita napříč řetězci: mapování identit v multichain světě
ENS a další jména umí mapovat adresy pro různé sítě. Při multichain operacích si zaveďte 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 resolver pole. Při cross-chain publikování pozor na zpoždění a stale mapování.
Organizační identity: DAO, projekty a právnické osoby
- Politiky subnames – pravidla přidělová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, audit trail 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 ale 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áznamů: 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é funding kanály, stealth/invoice adresy, bez reverse recordu pro treasury.
- Organizační wrapper: subnames s politikami, nepřevoditelnost dle 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, co bych litoval, kdyby 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 homoglyfům?
- Je moje identita svázaná s VC/ZK důkazy místo hrubých osobních údajů?
- Jsou resolver a registrátor chráněny přes multisig/timelock a mám auditovatelný proces změn?
Riziková matice: komfort vs. soukromí
| Rozhodnutí | Benefit | Riziko | Mitigace |
|---|---|---|---|
| Zapnout reverse record | Sk
 Eva SenkováRelated Story |
