零寬字符，讓ENS 距離成為Web3.0 基礎設施更遠了一步。
昨日，一位資深的Web2.0 域名交易者「Hero 桀」在其個人Mirror 上發表了一篇名為《請停止註冊一切ENS 域名，因為它一文不值》的文章。 Hero 桀自稱是資深Web2.0 域名交易者，並曾賣出xiaomiquan、wuyinli 等多個知名域名，目前仍持有ouyi 這一優質域名。
該文章指出了一個肉眼不可見的「ZWJ（零寬字符）」所導致的設計疏漏，正為ENS 埋下重大安全風險。該文章在部分加密社區流傳甚廣，並引發了部分投資者對ENS 的質疑。
這一問題允許多個肉眼所見完全相同的.eth 域名同時出現。正如Web3.0 革新了陳舊的傳統互聯網一樣，在Web3.0 時代，ENS 也為釣魚攻擊帶來了Web2.0 不曾出現過的全新升級的新方法。
在現階段，「.eth」域名更多的被作為「網名」而廣泛使用，一個獨特的eth 域名就像Web2.0 時代的QQ 靚號。在這種難以稱之為基礎設施的應用場景下，一些設計疏漏雖然會對用戶造成困擾，但終歸無法撼動ENS 去中心化域名龍頭的地位。
而在ENS 的願景實現之後，這個疏漏仍然是可以被忽視的嗎？ 「Decentralised naming for wallets, websites, &more.」這是ENS 官網上用醒目的字體所寫的宏大使命。在這個願景中，ENS 將成為命名一切數字資源的域名系統、打開theblockbeats.eth 就像打開theblockbeats.info 一樣自然，而此時ENS 的零寬字符將為整個Web3.0 世界帶來深遠的安全隱患。
零寬字符，讓ENS 距離成為Web3.0 基礎設施更遠了一步。
我，V 神，打錢
當你看到「vitalik.eth」時，你會認為這個人是誰？毫無疑問，這一ENS 域名由V 神所有。那麼，我能否註冊這一域名呢？按照ENS 的規則，這一域名已被註冊，其他用戶自然無法在註冊同樣的域名。但值得注意的是，這裡僅僅指對計算機而言完全一致的域名。那麼，我有沒有辦法找到一個和V 神域名有所不同但看上去又一致的域名呢？
當然可以，只要在任意位置插入ZWJ 即可。
ZWJ（zero width joiner）即零寬字符，這一符號頗為特殊。對於計算機來說，ZWJ 仍然為一個字符，在Unicode 字符集中擁有獨立的編碼，你在Word 鍵入這一字符它仍會被計入字數統計。而這一字符的寬度卻為0，也就是說對於肉眼而言，零寬字符完全不可見。
這也就意味著，我只要在「vitalik」這一單詞中任意位置插入零寬字符，即可註冊一個肉眼看上去和V 神域名完全一致的ENS 域名。
在註冊ENS 域名時，只要在任意位置鍵入「%E2%80%8C」或者「%E2%80%8D」，即可在單詞中插入一個零寬字符。這樣，一個V 神同款ENS 即可成功註冊了。如果插入零寬字符之後，依然已被人提前註冊，你甚至可以插入連續的兩個、三個、四個……多個零寬字符，直至嘗試到無人註冊為止。
做不好域名的ENS，敘事難以持續
ENS 不止是Ethereum 網絡的重要基建之一，同樣也是Web3.0 網絡的重要基建。 ENS 的創始人曾公開表示，ENS 的願景是要做「全球每一個數字資源的域名服務商」。不止是用戶的賬戶名，更是整個Web3.0 網絡的命名系統。
還記得早年間關於Web3.0 最初版本的想像嗎？去中心化存儲保存文件、去中心化域名提供尋址系統、智能合約擁有鏈上計算的能力、去中心化錢包充當支付通道，在這個版本的Web3.0 中，一切都是運行於去中心化網絡、無需許可、無審查的，這是一個真正自由的互聯網。在這個版本中，使用Web3.0 瀏覽器訪問theblockbeats.eth 就像你打開theblockbeats.info 一樣自然。
遺憾的是，這一版本的Web3.0，至今尚未實現。且主流瀏覽器至今尚未支持.eth 域名的訪問。儘管ENS 仍在持續的建設之中，但它似乎難以成為這一版本的Web3.0 的主流基礎設施了。倘若真的建成，也將為Web3.0 時代的網上沖浪留下巨大的安全隱患。
仔細回想一下，你是如何打開這篇文章的？
想必你定當是在某處見到了本篇文章的鏈接，鼠標或手指的一次點擊，將你帶到了這個頁面。而絕非是在地址欄鍵入漫長的一串https://www.theblockbeats.info/news/28611 。毋庸置疑，幾乎所有的用戶，都在使用URL 進行網上沖浪。一個又一個縱橫交錯的超鏈接構成了我們當今時代的互聯網，超鏈接組織起了互聯網的繁雜信息、超鏈接為搜索引擎提供了尋找信息的技術基礎、超鏈接為信息提供了開放自由的互聯通道，可以說沒有超鏈接，就沒有當今世界的互聯網。
基於ENS 域名的Web3.0 網站是否可以做到這一切？至少當前是極為困難的。因為它為我們帶來了極大的安全風險。
在Web2.0 時代，釣魚網站攻擊時刻都在對世界網民造成著嚴重的損失，而這還是在域名無法重名的情況下。想像一下，你在網上沖浪時看到網友分享的一個鏈接，該鏈接「肉眼可見」的是某知名平台，域名拼寫和真實地址分毫不差，於是你便點了進去。但其實這是一個通過零寬字符偽造的釣魚網站。
當用戶只是進行點對點轉賬時，手動輸入的習慣讓零寬字符或許只是一個無關痛癢的惡作劇。而當ENS 試圖達到它的使命、命名一切數字資源時，這一切都變了。 Web2.0 的釣魚只是域名相似，而Web3.0 的釣魚已經迭代為完全一致。這將是一個重大的安全隱患。
我們處在一個基於超鏈接編織而成的互聯網。 DeFi、交易平台、Web3.0 博客、Web3.0 社交；網站鏈接、dapp 鏈接、API 接口鏈接、一切用例的入口鏈接……若以鏈接形式存在的.eth 域名不再可信，.eth 如何拓展它在「網名」之外的用例？如何成為Web3.0 基礎設施？ ENS 域名的宏大敘事如何繼續展開？這一風險或將從根基衝擊ENS 的估值體系。
而頗為諷刺的是，這一問題甚至在Web2.0 中並不存在。
Web2.0 如何解決這一問題？
Web2.0 的解決方案簡單明了——不支持使用零寬字符和拉丁字母的混排作為域名。具體可參閱《IDN2008 規範》的「UTS46」標準。
前文我們曾提到零寬字符「%E2%80%8C」和「%E2%80%8D」這兩組神秘代碼。這是16 進制的UTF-8 編碼。它們的Unicode 編號分別為「U+200C」和「U+200D」。這些字符通常被用於在阿拉伯文與印度語係等文字中，用於控製字符間是否產生連字的效果。在其他大多數語言中，你並不能打出這個字符。
而在Web2.0 的域名註冊中，此類較為特殊的字符並不被接受。但這並不代表Web2.0 沒有類似的攻擊手段。事實上，外形相似的域名所偽裝的釣魚網站，一直在Web2.0 的世界裡廣泛存在。
舉個例子，你能否準確的區分”e” 和”е” 、”a”和”а”、「Ο」和「O」以及「О」？這些字母包括我們頻繁使用的拉丁字母，以及較少用到的西里爾字母和希臘字母。
起初，域名註冊僅支持ASCII 字符，即我們口語中所說的「英文字母」和阿拉伯數字。這也是在世界各地被使用最為廣泛的字符集，幾乎所有支持字符顯示的設備都支持ASCII，但卻不一定可以正常顯示其他文字。在IDN（國際化域名）普及之後，域名註冊新增支持了多種語言文字，將支持字符從ASCII 字符集擴展至部分Unicode 字符集。這讓世界各地的人民均可使用自己的母語註冊域名，以中文為例，你可以通過「http://新華網. 中國/」直接訪問新華網。
而在如此之多的文字中找到和拉丁字母相似的字符並不是什麼難事。這種使用相似字符偽裝成釣魚網站進行欺詐的情況逐漸多了起來。這一欺詐被稱為同形文字（homograph）攻擊。
早在2001 年，以色列的安全人員發表了一篇名為《同形文字攻擊》的論文，並註冊了一個包含西里爾字母的microsoft. com 的變體。這也是可考證的第一個homograph 欺詐域名。可以說，homograph 問題在Web2.0 時代由來已久，但其危害性和嚴重性遠不及Web3.0 的ENS 域名。
我們以一組IDN 域名為例：ԚԚ.com、аӏірау.com、аӏірау.com。打開這些域名，你可以看到什麼？
瀏覽器自動將域名轉換為了以「xn--」開頭的域名，這一編碼方式被稱為Punycode。
在《IDNA2003》的規範中，為避免homograph 欺詐，域名應經過二次處理，這一過程被稱為「兼容性規範化(compatibility normalization,NFKC)」。在非ASCII 字符域名中，所有的字符都可被通過Punycode 轉換為更為通用的ASCII 字符（「xn--」域名）。這一編碼方式遵循UTR36 標準，已被主流瀏覽器使用，這從用戶端降低了homograph 攻擊的風險。
同樣，在IDN 域名的註冊環節，ICANN 也做出了相應的規範。各國域名註冊組織也在逐漸做出跟進，例如，俄羅斯的域名管理機構已經禁止了.ru 域名中混用西里爾字母和拉丁字母。
ENS 域名無疑支持著遠多於DNS 域名的字符，你不僅可以像DNS 一樣使用各種文字註冊域名，甚至還可以使用emoji 註冊域名，以及本次被熱議的安全隱患零寬字符註冊域名。 （值得一提的是，emoji 域名並不是Web3.0 的特例，傳統域名中的「.tk」、「.ws」等根域名同樣也支持emoji 註冊。）
而在Web3.0 中，我們能否通過相似的手段消除這一隱患呢？
面對homograph attack，ENS 開發者態度曖昧
遺憾的是，ENS 開發者似乎並不打算從註冊入口上解決這一問題。
在ENS 社區的討論中，這一問題早在2021 年4 月就已被用戶提出。而ENS 開發者對此的解釋是，對零寬字符的支持是在合約層面的，因此無法移除對這些可能被用於欺詐的字符。此外，還有一個更重要的原因——零寬字符支撐著emoji 在ENS 中的應用。
ENS 創始人nick.eth 針對零寬字符問題做出了這樣的回應：「我們不像ICANN 對大部分通用頂級域名那麼嚴格，像emoji 這樣的域名就很好的運用了ENS。」「ENS 禁止解析非UTS-46 規範的域名並不在合約層面實現——將規範寫入合約是不切實際的——這應作為客戶端所需解決問題的一部分。」當然，他也對用戶做出了積極的表態，「我們將考慮對規範化規則作出補充，以禁止您發現的這種情況。」
emoji 表情符號數量繁雜，事實上，有大量的emoji 均為基礎emoji 的複合，例如，「女人」、「零寬字符」、「火箭」三個連在一起即會被計算機識別為「宇航員」。通過零寬字符，可以在精簡編碼集的基礎上納入更多的表情。而這也是ENS 支持幾乎所有emoji 的基礎。因此，ENS 無法屏蔽掉零寬字符的使用。
前文我們曾提到Web2.0 的「.tk」域名，這是世界上第一個支持emoji 的域名，傳統的Web2.0 域名是如何解決這一問題的？在前文提到的《IDN2008 規範》的「UTS46」標準中，零寬字符在不同文字中的使用、在emoji 中的使用，均被做出嚴格規範。
在4 月份的討論中，nick 向社區成員解釋，零寬字符的使用是在智能合約層級的，「不過，這很好，ENS 的設計一直是這樣。」「白名單規則在這裡沒用，因為域名中可以包含多個字符，而不僅僅只是emoji。」
風險控制與隱患消除
截至目前，我們尚未看到ENS 團隊在合約層面有任何修復這一安全隱患的舉措。所有對於這一風險的防範均由中心化的Web2.0 前端所作出。
在OpenSea，包含零寬字符的ENS 域名被標記上了黃色驚嘆號。
在etherscan，存在同樣隱患的ENS 域名則被標記了星號。
在Metamask 上，雖然並不會額外給出風險提示，但Metamask 可以識別到字符串中包含一位零寬字符，並用”?”將這一字符顯示出來。
借助於中心化的手段，ENS 域名的安全風險在一定程度上有所減少。但當我們進入一個完全開放的Web3.0 的世界，中心化的手段又將起到多大的作用呢？如果這隱患無法消除，ENS 距離他命名一切數字資源的願景，仍然相距甚遠。
在未來的某一天，有人發送給你一則網址為www.binance.eth 的公告鏈接，你敢點開嗎？
展開全文打開碳鏈價值APP 查看更多精彩資訊