Ez Mark Jeffovic, az easyDNS Technologies Inc. társalapítójának és vezérigazgatójának vezércikkje. és a “Managing Mission Critical Domains and DNS” szerzője.
Attól a pillanattól kezdve, hogy 2013-ban felfedeztem a Bitcoint, tudtam, hogy végül léteznie kell egy módnak a pénztárcacímekre való hivatkozásra ember által olvasható címkékkel.
A Bitcoin hosszú címeivel az a nagy probléma, hogy nem emlékezetesek, és a Bitcoin álneves vagy névtelen funkciói ellenére gyakran szeretne könnyen igényelni vagy ellenőrizni, hogy egy pénztárca címe egy adott entitáshoz tartozik – gondoljon a jó célra történő adományozásra. vagy tömegalap. Ez minden blokkláncot érint.
DNS (Domain Name System) srácként már láttam ezt a filmet: a DNS-t arra találták ki, hogy ugyanazt a problémát oldja meg az IPv4 címzéssel. Az idő múlásával a DNS sokkal többre fejlődött – a DNS nemcsak az IPv6-címek feloldásának lehetőségét adta, hanem egyre gyakrabban használják metaadatok átvitelére egy névtéren keresztül. Gondoljon az SRV-rekordokra, a NAPTR-ekre, az RBL-blokkolistákra, a válaszházirend-zónákra (RPZ-k) és a mindenütt jelenlévő TXT-rekordra (SPF-hez, DMARC-hoz, DKIM-hez és minden máshoz, amely alapértelmezés szerint nem illeszkedik a protokollhoz).
Együtt jön a Bitcoin, és ugyanaz a probléma, nagyra írva.
A Bitcoin és a Lightning sajátos problémája
Úgy tűnik, hogy a fizetési tranzakciós tevékenységek nagy része a 2. rétegbe fog kerülni olyan protokollokkal, mint a Lightning és a Lightning-cím közelmúltbeli megérkezése.
A Lightning címek az LNURL fizetési protokolltól függenek, és úgy néznek ki, mint egy e-mail cím:
Az e-mail cím nómenklatúrája tökéletes módja a személyazonossági adatok továbbításának. Könnyen elhatárolja a szervezeteket, és tovább osztja őket egységekre vagy személyekre. Mindenki hozzászokott már ehhez a formátumhoz, és amint látni fogjuk, sokkal több információt közvetíthet, mint a célpostafiókok.
Évekig arra számítottam, hogy ez a formátum lesz a de facto szabvány a Session Initiation Protocol (SIP) és az XMPP identitásvégpontok számára.
A SIP és az XMPP nem egészen úgy uralta a világot, ahogyan azt vártam (legalábbis még nem), és egy ideig az azonosítók elkezdtek elmozdulni a központosított platformok felé, mint például a Twitter kezelõk és a Github felhasználói azonosítók. Ezt mindig szkeptikusnak találtam, különösen a Bitcoinerek körében.
A Lightning-címekkel visszatérő utat látunk a decentralizált azonosítókhoz, mivel maguk az e-mail címek decentralizáltak, magának a DNS-rendszernek a korlátain belül (erről bővebben alább).
Csak egy probléma van: a definiált LNURL specifikációból hiányzik az absztrakció szintje. Enélkül a világítási címek használata nagyon korlátozottá válik.
Adott a Lightning cím:
[email protected]
Ez azt jelenti, hogy a jelenlegi specifikáció szerint a fizetési leíró a következő helyen található:
https://example.com/.well-known/lnurlp/satoshi/
De mi van akkor, ha a Satoshi nem tud hozzáférni az example.com webszerverhez? Ha ragaszkodunk az e-mail-cím analógiájához, csak azért, mert ez a címe, nem jelenti azt, hogy a megfelelő gazdagépnévvel rendelkező kiszolgáló az az e-mail, amelyre az e-mailt kézbesítjük.
Valójában valószínűleg nem ez a helyzet gyakrabban, mint amilyen. Emiatt létezik az MX rekordtípus a DNS-ben, amely egy további indirektségi szinttel vezérli az e-mailek célhelyét. Továbbíthatják az e-mailek kézbesítését olyan gazdagépnevekre, amelyek teljesen más domain néven működnek (gondoljunk arra, hogy egy külső e-mail szolgáltatót használnak, de saját egyéni domainnel).
Ugyaneznek kell történnie a Lightning-címekkel is, nagyjából ugyanazon okok miatt. Előfordulhat, hogy a „@” jeltől jobbra lévő gazdagépnévben egyáltalán nem található webszerver, vagy a felhasználó szükségtelenül korlátozódik egy Lightning-cím használatára, ahol a gazdagépnév összetevő csak a JSON-fájlt tároló webszerveré lehet. Ez problémát jelenthet egy olyan Lightning-cím közzétételekor, amelyet a felhasználó később módosítani szeretne.
DNS-srácként a megoldás kézenfekvőnek tűnt, de én túlgondoltam:
2017-ben az akkori Ethereum névszolgáltatási munkacsoport meghívott egy londoni találkozóra, hogy kidolgozzam az ENS nyilvántartás specifikációját.
Abban a gondolatban hagytam el a találkozót, hogy szükség van egy új DNS-erőforrásrekordra, egy új rekordtípusra, amely hivatkozhat a régi DNS blokklánc-erőforrásaira.
Szerintem valami SRV- vagy NAPTR-rekordhoz hasonlítana, különböző mezőkkel a protokollokhoz, portokhoz és súlyokhoz (az a tény, hogy a webböngészők még ma sem nézik meg a webcímek SRV-rekordjait, az egyik nagy elszalasztott lehetőség az internet korszakából).
Az én működő rövidítésem a „BCPTR” a „Blockchain Pointer” volt, és túl bonyolult, bonyolult specifikációja volt ahhoz, hogy pontosan meg tudja mondani, melyik blokkláncra mutat egy rekord, és milyen típusú erőforrásról van szó.
Aztán a Lightning GitHub kiadásban, ahol az LNURL RFC-t vitatták meg, valaki azt javasolta, hogy a „_lud16” aldomain elé csak egy címet tegyünk.
Az aláhúzásjelek használata bizonyos elnevezési attribútumok és valódi gazdagépnevek megkülönböztetésére már egy ideje létezik. Az eredeti SRV RR specifikációban, az RFC2872-ben használták, és később az RFC 8552-ben “aláhúzásként” írták le.
A felvetés azonnal felrobbant a fejemben, és rájöttem, hogy évek óta gondolkodtam ezen.
A DNS-ben található hatókörű címke, például a _tcp vagy _udp, nem különbözteti meg a kis- és nagybetűket, és az SRV- és NAPTR-rekordokban látjuk őket SIP-, VOIP- és ENUM-alkalmazásokban való használatra, a terheléselosztásról nem is beszélve a DKIM és DomainKeys TXT rekordjairól.
Gyakorlatilag minden érvényes DNS-címke, például a _lud16 vagy _btc, biztosít számunkra egy olyan mechanizmust, amellyel korlátozhatjuk a válaszokat a DNS-fában a szülőcsomópont alatti hatókörnek megfelelő lekérdezésekre.
Jelentése:
$ORIGIN example.com.
_ie.test IN TXT “ez egy teszt”_eg.test IN TXT “ez egy külön teszt”
A TXT típusú DNS-lekérdezés a „test.example.com” webhelyen nem ad vissza választ (NXDOMAIN).
A TXT típusú DNS-lekérdezés a „_ie.test.example.com” webhelyen semmi de eredményt ad vissza az első rekordhoz.
A TXT típusú DNS-lekérdezés a “test._ie.example.com” oldalon semmi de vissza a második rekordot.
Más szavakkal, több TXT rekordunk van a teszt.example.com leaf, azonban csak azt adjuk vissza, amelyik a tartománycímkével van lekérdezve, azt, amelyik aláhúzással kezdődik.
Kiderült, hogy ez elég erős a céljaink szempontjából. Használati esetünkben is a legegyszerűbb, optimális megoldás, mert:
- Bárki használhatja.
- Ez egy olyan formátum, amelyet az emberek könnyen felismernek.
- DNS-en keresztül bármely meglévő e-mail címre utólag illeszthető.
- Lehetővé teszi, hogy a json-rekord a szerveren kívül máshol is létezzen (például hogyan működik az MX rekord).
- Bármilyen rakományt szállíthat.
- Minden blokkláncon működhet.
Hogyan használható az aláhúzás hatóköre a blokkláncokban
A Lightning Addressesben használt e-mail-címformátumot figyelembe véve a DNS-en keresztüli konvenciót használhatjuk arra, hogy mindenféle végpontot megadjunk ugyanazon identitáshoz:
$ORIGIN bomber.com.
_lud16.markjr IN TXT “https://my.ln-node/.well-known/lnurlp/markjr”
_btc.markjr IN TXT “bc1qu059yx6ygg9e6tgedktlsndm56jrckyf3waszl”
_ens.markjr IN TXT “0xEbE7CcC5A0D656AD3A153AFA3d543160B2E9EdFb”
Innen eljuthatunk anélkül, hogy bármit is eltörnénk, ami már a helyén van:
- Azok az alkalmazások, amelyek már használnak LNurl-címet, mindig használhatják azt
- Az alkalmazások hozzáadhatják a DNS-keresést
De a DNS központosított!
Igaz, hogy a DNS-nek van egy fordított fastruktúrája, amely a “.” gyökérnél végződik. De még ez a gyökér is meglehetősen decentralizált, és több ezer szervert tartalmaz, amelyet legalább 13 különböző operátor kezel. Az örökölt DNS logikailag centralizált lehet, de a valóságban inkább egyfajta decentralizált összevonásként működik.
Még ez is változik, fejlődik. Úgy gondolom, hogy végül az a hely, ahol a névterek átfogják a meglévő fordított fagyökeret és a teljesen decentralizált blokkláncokat.
Ezek egy része már ma is megvan: használhat olyan dolgokat, mint a Stacks és a .btc domainek, amelyek a Bitcoinhoz rögzíthetők, és valószínűleg más névterek is épülnek majd közvetlenül a Bitcoinra.
Nem minden decentralizált névtér rendelkezik örökölt DNS-feloldóval, de ez megváltozik. Dolgoznak egy új DNS-feloldó megvalósításán is, amely a Stacks, .btc és HNS tartományokat Handshake és Unstoppable legfelső szintű tartományokon keresztül oldja fel. Tesztelheti az alpha.dnsresolvers.com webhelyen található keresésekkel:
% dig +short easydns.btc @alpha.dnsresolvers.com
3.14.49.122
(Ez a szerver a koncepció bizonyítéka, és a jövőben eltűnik, kérlek ne add hozzá a resolv.conf.)
Mindez, és megoldja a hamis Twitter-kilincs problémáját is!
Amint konvencióvá tesszük az aláhúzás hatókör használatát, azt találjuk, hogy mindenféle problémát meg tudunk oldani meglévő módszerekkel.
Vessünk egy pillantást a hamis Twitter-fogantyú-problémára, amely a Bitcoin-teret sújtja.
A Twitter-felhasználók adatstruktúrája így néz ki:
Az aláhúzás hatókörével érvényesíthetjük a gazdagépnév valódi Twitter-fogóját az url elemben, a következő konvenciót alkalmazva:
$ORIGIN bomber.com.
stuntpope._twitter IN TXT “Stuntpope”
*._twitter IN TXT “hamis”
Ez önmagában nem tesz semmit. Senki nem fog megnyitni egy terminálablakot és beírni:
“dig -t TXT +short stunt pope._twitter.bombthrower.com”
…hogy megtudja, hogy az a személy, aki DM-et küld Önnek, “Hogy áll a kereskedése ma?” igazi vagyok-e vagy valamelyik légiók a StuntPope csalók közül a Twitteren. (Természetesen viccelek, ép elméjű ember nem utánozna engem. De sok fintwit készüléknél ez valós probléma.)
De mi történhet, ha ez a konvencióvá válik, az az, hogy a fejlesztők gyors és piszkos horgokat építhetnek be alkalmazásaikba a keresések végrehajtásához.
Amikor egy hamis Twitter-profil kiadja magát valakinek, általában minden adatot szó szerint másol, beleértve a Twitter-profil URL mezőjében található gazdagép nevét is. Ha a valódi felhasználó rendelkezik a fent leírt rekordokkal, akkor a konvenció az, hogy a hamisítvány Twitter fogantyú a Igazi Az URL-ből hiányzik a valódi profil _twitter TXT rekordja, és a helyettesítő karaktert találja, ami eltérést okoz.
Az easyDNS Githubon keresztül kiadtunk egy proof-of-concept Chrome-bővítményt, amely három móddal pontosan ezt teszi:
A) Nem igényeltek információt;
B) A profil megfelel az igényelt információnak;
C) A profil nem egyezik az igényelt információval (hamis).
Mindezt és még sok mást meg lehet tenni egy már megvalósított, mindenütt jelenlévő protokoll nagyon egyszerű konvencióival.
Következtetés
A pénztárcacímek alkalmasak valamilyen elnevezési mechanizmusra. Többféle felhasználási eset is létezik, amikor az identitás címének biztonságos megadása elsőbbséget élvez az álnévvel vagy névtelenséggel szemben.
Továbbá az ember által olvasható címkék vagy azonosítók használatához szükségünk van egy absztrakciós rétegre, amely rugalmasságot és könnyen felismerhető formátumot kínál.
Végül mindezt a DNS segítségével érhetjük el, amely már támogatja az Internet technikai infrastruktúráját, de már decentralizált föderációként működik, és a decentralizált Layer 1 protokollokon való lehorgonyzás felé tart. Ezt anélkül tehetjük meg, hogy új rekordtípusokat adnánk hozzá, vagy protokoll-kiegészítéseket tennénk a meglévő specifikációkhoz.
Ez Mark Jeffovic vendégbejegyzése. A kifejtett vélemények teljes mértékben a sajátjuk, és nem feltétlenül tükrözik a BTC Inc. vagy a Bitcoin Magazin.
.