這是由easyDNS Technologies Inc. 的聯合創始人兼首席執行官、“管理關鍵任務域和DNS”一書的作者Mark Jeftovic 撰寫的一篇觀點社論。
從我在2013 年發現比特幣的那一刻起，我就知道最終必須有一種方法可以使用人類可讀的標籤來引用錢包地址。
比特幣長地址的一個大問題是它們不易記住，儘管比特幣具有假名或匿名特徵，但很多時候你希望能夠輕鬆斷言或驗證錢包地址屬於特定實體——想想捐贈給慈善機構或眾籌。這會影響每個區塊鏈。
作為一名DNS（域名系統）人員，我以前看過這部電影：發明DNS 是為了解決IPv4 尋址的相同問題。隨著時間的推移，DNS 發展得更多——DNS 不僅增加了解析IPv6 地址的能力，而且還越來越多地用於傳達有關命名空間的元數據。思考 SRV 記錄，NAPTR 的RBL 阻止列表, 響應政策區 （RPZ）和 無處不在的TXT記錄 （用於SPF、DMARC、DKIM 和其他任何本身不適合該協議的東西）。
隨之而來的是比特幣，我們也有同樣的問題。
比特幣和閃電網絡特有的問題
看起來大部分支付交易活動將通過Lightning 等協議轉移到第2 層，最近還有 閃電地址.
閃電地址依賴 在LNURL-pay 協議，它們看起來很像一個電子郵件地址：
通過：https://github.com/andrerfneves/lightning-address/blob/master/README.md
電子郵件地址命名法是傳達身份信息的完美方式。它可以輕鬆地劃分組織並進一步細分為其中的單位或人員。每個人都已經習慣了這種格式，正如我們將看到的，它有可能傳達比目標郵箱更多的信息。
多年來，我一直期待這種格式成為身份端點的事實標準 會話發起協議 (SIP) 和 XMPP.
SIP 和XMPP 並沒有像我預期的那樣接管世界（至少現在還沒有），有一段時間，標識符開始被集中式平台所吸引，比如Twitter 句柄和Github 用戶ID。我總是覺得這很奇怪，尤其是在比特幣愛好者中。
借助閃電地址，我們看到了一條回歸去中心化標識符的道路，因為電子郵件地址本身是去中心化的，在DNS 系統本身的限制內（更多內容見下文）。
只有一個問題：定義的LNURL 規範缺少抽象級別。沒有它，Lighting Addresses 的用例就會變得非常受限。
鑑於閃電地址：
這意味著在當前規範下，支付描述符將位於：
https://example.com/.well-known/lnurlp/satoshi/
但是，如果Satoshi 無法訪問example.com 網絡服務器怎麼辦？如果我們堅持使用電子郵件地址的類比：僅僅因為您將其作為您的地址並不意味著具有匹配主機名的服務器就是發送電子郵件的地方。
事實上，情況可能並非如此。出於這個原因，DNS 中存在MX 記錄類型，它增加了一個額外的間接級別來控制電子郵件的目的地。他們可能會將電子郵件發送到在完全不同的域名下運行的主機名（想想使用外部電子郵件提供商但擁有自己的自定義域的人）。
出於相同的原因，閃電地址也需要發生同樣的事情。 “@”右側的主機名可能根本沒有網絡服務器，或者用戶被過度限制使用閃電地址，其中主機名組件只能是託管JSON 文件的網絡服務器的主機名組件。在發布用戶想要更改的閃電地址時，這可能是一個問題。
作為一名DNS 專家，解決方案似乎很明顯，但我為過度思考而感到內疚：
2017 年，當時的以太坊名稱服務工作組邀請我參加在倫敦舉行的一次會議，以製定ENS 註冊表的規範。
我離開那個會議時認為需要有一個新的DNS 資源記錄，一種能夠從舊DNS 中引用區塊鏈資源的新記錄類型。
在我看來，它看起來有點像SRV 或NAPTR 記錄，它們具有不同的協議、端口和權重字段（事實上，今天的網絡瀏覽器仍然不查看SRV 記錄的網址，這是錯失的絕佳機會之一。互聯網時代）。
我的工作簡寫是“區塊鏈指針”的“BCPTR”，它有一個過於復雜、令人費解的規範，用於準確指出一條記錄指向哪個區塊鏈以及它是什麼類型的資源。
然後在討論LNURL RFC 的Lightning GitHub 問題中，有人 建議只需在地址前面加上“_lud16” 子域。
使用下劃線將某些命名屬性與實際主機名區分開來已經有一段時間了。它用於原始的SRV RR 規範 RFC2872 後來在中描述為“下劃線範圍” RFC 8552.
這個建議立即在我的腦海中爆發，我意識到我多年來一直在想這件事。
DNS 中的範圍標籤，如_tcp 或_udp，不區分大小寫，我們在SRV 和NAPTR 記錄中看到它們，用於SIP、VOIP 和ENUM 應用程序、負載平衡，更不用說在DKIM 和DomainKeys 的TXT 記錄中使用了。
任何有效的DNS 標籤，如_lud16 或_btc，都為我們提供了一種機制來限制對與範圍匹配的查詢的響應，位於DNS 樹的父節點下。
意義：
$ORIGIN example.com。
_ie.test IN TXT “這是一個測試”_eg.test IN TXT “這是一個單獨的測試”
“test.example.com”上TXT 類型的DNS 查詢不會返回答案(NXDOMAIN)。
在“_ie.test.example.com”上對TXT 類型的DNS 查詢將 只要 返回第一條記錄的結果。
“test._ie.example.com”上TXT 類型的DNS 查詢將 只要 返回第二條記錄。
換句話說，我們有多個TXT 記錄 test.example.com 但是，我們將只返回使用範圍標籤查詢的那個，即以下劃線開頭的那個。
事實證明，這對於我們的目的來說非常強大。它也是我們用例中最簡單、最佳的解決方案，因為：
- 每個人都可以使用它。
- 這是一種人們很容易識別的格式。
- 它可以通過DNS 改裝到任何現有的電子郵件地址。
- 它使json 記錄能夠存在於服務器以外的某個地方（例如MX 記錄的功能）。
- 可以提供任何類型的有效載荷。
- 可以跨所有區塊鏈工作。
下劃線範圍如何在區塊鏈中使用
通過採用Lightning Addresses: 中使用的電子郵件地址格式，我們可以通過DNS 使用約定來為同一身份指定各種端點：
$ORIGIN bombthrower.com。
_lud16.markjr IN TXT “https://my.ln-node/.well-known/lnurlp/markjr“
_btc.markjr IN TXT “bc1qu059yx6ygg9e6tgedktlsndm56jrckyf3waszl”
_ens.markjr IN TXT “0xEbE7CcC5A0D656AD3A153AFA3d543160B2E9EdFb”
我們可以從這裡到達那裡，而不會破壞任何已經存在的東西：
- 已經使用LNURL 地址的應用程序可以一直使用該地址
- 應用程序可以添加DNS 查找
但是DNS 是集中式的！
確實，DNS 有一個倒置的樹結構，終止於根“.”。但即使是這個根也相當分散，包括由至少13 個不同的運營商運營的數千台服務器。傳統DNS 在邏輯上可能是集中式的，但實際上其功能更像是一種分散的聯合。
即便是這種情況也在改變、發展。我認為我們最終的結果是命名空間跨越現有的倒置樹根和完全去中心化的區塊鏈。
其中一些今天已經在這裡：你可以使用類似的東西 堆棧和.btc 域 哪些固定到比特幣，可能還會有其他直接構建在比特幣之上的命名空間。
並非所有去中心化命名空間都有傳統的DNS 解析器，但這也會改變。還有一個新的工作正在做 DNS解析器 實現將通過Handshake 和Unstoppable 頂級域解析Stacks、.btc 和HNS 域。您可以通過查找alpha.dnsresolvers.com 對其進行測試：
% 挖+short easydns.btc @alpha.dnsresolvers.com
3.14.49.122
（此服務器是概念驗證，將來會消失， 請不要添加 到你的resolv.conf。 ）
所有這一切，它也解決了假Twitter 句柄問題！
一旦我們約定使用下劃線範圍，我們發現我們可以使用現有方法解決各種問題。
讓我們看看困擾比特幣空間的假推特處理問題。
Twitter 用戶的數據結構如下所示：
通過下劃線範圍，我們可以使用以下約定從url 元素中的主機名斷言真正的Twitter 句柄：
$ORIGIN bombthrower.com。
stuntpope._twitter IN TXT “StuntPope”
*._twitter IN TXT “假”
就其本身而言，這沒有任何作用。沒有人會打開終端窗口並輸入：
“dig -t TXT +short stuntpope._twitter.bombthrower.com”
……看看那個人是否給你發了私信，“你今天的交易怎麼樣？” 真的是我，還是其中之一 軍團 Twitter 上的StuntPope 冒名頂替者。 （我當然是在開玩笑，沒有人會冒充我。但對於很多fintwit 名人來說，這是一個真正的問題。）
但是如果這成為慣例會發生什麼，開發人員可以在他們的應用程序中構建快速而骯髒的掛鉤來進行這些查找。
當虛假Twitter 個人資料冒充某人時，他們通常會逐字複製所有數據，包括Twitter 個人資料URL 字段中的主機名。如果真實用戶有上面列出的記錄，那麼查找 偽造的 Twitter句柄在 真實的 URL 將錯過真實個人資料的實際_twitter TXT 記錄，並命中通配符記錄，從而導致不匹配。
我們通過 易DNS Github，它通過三種模式做到這一點：
A) 未聲明任何信息；
B) 配置文件與聲明的信息相匹配；
C) 個人資料與聲明的信息不匹配（這是假的）。
所有這些以及更多，都可以在已經部署的無處不在的協議中使用非常簡單的約定來完成。
結論
錢包地址需要某種命名機制。有多個用例需要從身份安全地斷言地址優先於假名或匿名。
此外，為了使用人類可讀的標籤或標識符，我們需要一個提供靈活性和易於識別的格式的抽象層。
最後，我們可以使用DNS 來實現這一切，它已經支撐了互聯網的技術基礎設施，已經是一個去中心化的聯邦，並且正在錨定在去中心化的第1 層協議上。我們可以在不添加任何新記錄類型或在現有規範中添加任何協議的情況下這樣做。
這是馬克·傑夫托維奇的客座文章。所表達的意見完全是他們自己的，不一定反映BTC Inc 或 比特幣雜誌.