💬 Упрощение биткойн-адресов с помощью DNS

Упрощение биткойн-адресов с помощью DNS

Это редакционная статья Марка Джефтовича, соучредителя и генерального директора easyDNS Technologies Inc., а также автора книги «Управление критически важными доменами и DNS».

С того момента, как я открыл для себя Биткойн в 2013 году, я знал, что рано или поздно появится способ ссылаться на адреса кошельков с помощью удобочитаемых меток.

Большая проблема с длинными адресами Биткойн заключается в том, что они не запоминаются, и, несмотря на псевдонимные или анонимные функции Биткойн, большую часть времени вы хотите иметь возможность легко подтвердить или проверить, что адрес кошелька принадлежит определенному юридическое лицо — подумайте о пожертвованиях на благотворительность или в краудфандинг. Это влияет на каждую цепочку блоков.

Как специалист по DNS (система доменных имен), я уже видел этот фильм: DNS был изобретен для решения той же проблемы с адресацией IPv4. Со временем DNS развилась, чтобы делать гораздо больше — DNS не только добавила возможность разрешать адреса IPv6, но и все чаще используется для передачи метаданных о пространстве имен. Вспомните записи SRV, NAPTR, черные списки RBL, зоны политик ответа (RPZ) и повсеместную запись TXT (которая используется для SPF, DMARC, DKIM и всего остального, что изначально не соответствует протоколу).

Приходит биткойн, и у нас та же проблема, только в больших масштабах.

Проблема, специфичная для биткойнов и Lightning

Похоже, большая часть платежных транзакций переместится на уровень 2 с такими протоколами, как Lightning, а совсем недавно — с появлением адреса Lightning.

Адреса Lightning основаны на протоколе LNURL-pay и очень похожи на адреса электронной почты:

Номенклатура адресов электронной почты — это идеальный способ передать идентификационную информацию. Он легко разграничивает организации и далее подразделяет на подразделения или людей внутри него. Все уже привыкли к этому формату, и, как мы увидим, он может передавать гораздо больше информации, чем почтовые ящики назначения.

В течение многих лет я ожидал, что этот формат станет стандартом де-факто для конечных точек идентификации с протоколом инициации сеанса (SIP) и XMPP.

SIP и XMPP не захватили мир так, как я ожидал (по крайней мере, пока), и какое-то время идентификаторы начали тяготеть к централизованным платформам, таким как дескрипторы Twitter и идентификаторы пользователей Github. Я всегда находил это забавным, особенно среди биткойнеров.

С Lightning Addresses мы видим обратный путь к децентрализованным идентификаторам, поскольку адреса электронной почты сами по себе децентрализованы в рамках самой системы DNS (подробнее об этом ниже).

Есть только одна проблема: в спецификации LNURL отсутствует уровень абстракции. Без него варианты использования Lighting Addresses становятся очень ограниченными.

Для Lightning-адреса:

[email protected]

Это означает, что согласно текущей спецификации дескриптор платежа будет расположен по адресу:

https://example.com/.well-known/lnurlp/satoshi/

Но что, если у Сатоши нет доступа к веб-серверу example.com? Если мы придерживаемся аналогии с адресом электронной почты: то, что он указан в качестве вашего адреса, не означает, что сервер с совпадающим именем хоста является местом доставки электронной почты.

На самом деле, скорее всего, это не так. По этой причине в DNS существует тип записи MX, который добавляет дополнительный уровень косвенности для управления пунктом назначения электронной почты. Они могут направлять доставку электронной почты на хосты, работающие под совершенно другим доменным именем (подумайте о людях, которые используют внешнего поставщика услуг электронной почты, но со своим собственным доменом).

То же самое должно произойти с адресами Lightning по тем же причинам. Имя хоста справа от «@» может вообще не иметь веб-сервера, или пользователь неправомерно ограничен использованием адреса Lightning, где компонент имени хоста может быть только именем веб-сервера, на котором размещен файл JSON. Это может стать проблемой при публикации адреса Lightning, который пользователь захочет изменить в будущем.

Как сотрудник DNS, решение казалось очевидным, но я был виновен в том, что слишком много думал:

В 2017 году рабочая группа Ethereum Name Service пригласила меня на встречу в Лондоне для разработки спецификации реестра ENS.

Я ушел с этой встречи, думая, что должна быть новая запись ресурса DNS, новый тип записи, который мог бы ссылаться на ресурсы блокчейна из устаревшей DNS.

На мой взгляд, это выглядело бы как запись SRV или NAPTR, в которой были бы разные поля для протоколов, портов и весов (тот факт, что веб-браузеры сегодня все еще не смотрят записи SRV для веб-адресов, является одним из замечательных упущенные возможности эпохи Интернета).

Моим рабочим сокращением для этого было «BCPTR» для «Указатель блокчейна», и у него была слишком сложная, запутанная спецификация для указания, на какой именно блокчейн указывает запись и к какому типу ресурса она относится.

Затем в выпуске Lightning GitHub, где обсуждался LNURL RFC, кто-то предложил просто добавить к адресу субдомен «_lud16».

Использование символов подчеркивания, чтобы отличить определенные атрибуты именования от реальных имен хостов, используется уже некоторое время. Он использовался в исходной спецификации SRV RR RFC2872, а позже был описан как «область подчеркивания» в RFC 8552.

Это предложение немедленно взорвалось в моем мозгу, и я понял, что много лет обдумывал это.

Метки области в DNS, такие как _tcp или _udp, нечувствительны к регистру, и мы видим их в записях SRV и NAPTR для использования в приложениях SIP, VOIP и ENUM, балансировки нагрузки, не говоря уже о записях TXT для DKIM и DomainKeys.

Практически любая допустимая метка DNS, например _lud16 или _btc, предоставляет нам механизм для ограничения ответа на запрос, соответствующий области действия, родительским узлом в дереве DNS.

Значение:

$ORIGIN example.com._ie.test В TXT «это тест» _eg.test IN TXT «это отдельный тест»

$ORIGIN example.com._ie.test В TXT «это тест»

_eg.test В TXT «это отдельный тест»

Запрос DNS для типа TXT на «test.example.com» не возвращает ответ (NXDOMAIN).

Запрос DNS для типа TXT на «_ie.test.example.com» вернет результат только для первой записи.

Запрос DNS для типа TXT на «test._ie.example.com» вернет только вторую запись.

Другими словами, у нас есть несколько записей TXT для листа test.example.com, однако мы вернем только ту, которая запрошена с меткой области действия и начинается с символа подчеркивания.

Оказывается, это достаточно мощно для наших целей. Это также самое простое и оптимальное решение в нашем случае использования, потому что:

Как можно использовать область подчеркивания в блокчейнах

Взяв формат адреса электронной почты, используемый в Lightning Addresses: , мы можем использовать соглашение через DNS для указания всех видов конечных точек для одного и того же идентификатора:

$ Origin Bombthrower.com._lud16.markjr в txt "https: //my.ln-node/.well-known/lnurlp/markjr" _btc.markjr в txt "bc1qu059yx6ygg9e6tgtlsndm56jrckyf3waszl" _ens.markjr.mals3.saled ".

$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"

Отсюда мы можем добраться туда, не ломая ничего из того, что уже есть на месте:

Но DNS централизован!

Это правда, что DNS имеет перевернутую древовидную структуру, которая заканчивается корнем «.». Но даже этот корень довольно децентрализован и включает в себя тысячи серверов, управляемых как минимум 13 разрозненными операторами. Устаревшая DNS может быть логически централизованной, но на самом деле она больше похожа на своего рода децентрализованную федерацию.

Даже это меняется, развивается. Я думаю, что в конечном итоге мы окажемся там, где пространства имен охватывают как существующий перевернутый корень дерева, так и полностью децентрализованные блокчейны.

Кое-что из этого уже существует сегодня: вы можете использовать что-то вроде стеков и доменов .btc, которые привязываются к биткойну, и, вероятно, будут другие пространства имен, построенные непосредственно поверх биткойна.

Не все децентрализованные пространства имен имеют устаревшие преобразователи DNS, но это тоже изменится. Также ведется работа над новой реализацией DNSresolvers, которая будет разрешать домены Stacks, .btc и HNS с помощью рукопожатия и домены верхнего уровня Unstoppable. Вы можете проверить это с помощью поиска на alpha.dnsresolvers.com:

% dig +short easydns.btc @alpha.dnsresolvers.com 3.14.49.122

% dig +short easydns.btc @alpha.dnsresolvers.com

3.14.49.122

(Этот сервер является экспериментальным и в будущем его не будет, пожалуйста, не добавляйте его в свой resolv.conf.)

Все это, и это также решает проблему поддельного дескриптора Twitter!

Как только мы установим соглашение об использовании области действия с подчеркиванием, мы обнаружим, что можем решать любые проблемы, используя существующие методы.

Давайте рассмотрим проблему с фальшивыми дескрипторами Twitter, от которой страдает биткойн-пространство.

Структура данных пользователя Twitter выглядит следующим образом:

С областью действия подчеркивания мы можем утверждать истинный дескриптор Twitter из имени хоста в элементе url, используя следующее соглашение:

$ORIGIN bombthrower.com. stuntpope._twitter В TXT «StuntPope» *._twitter В TXT «фейк»

$ORIGIN bombthrower.com.

stuntpope._twitter В TXT «StuntPope»

*._twitter В TXT «фейк»

Само по себе это ничего не делает. Никто не собирается открывать окно терминала и вводить:

«копать -t TXT + короткий stuntpope._twitter.bombthrower.com»

"dig -t TXT +short stuntpope._twitter.bombthrower.com"

… чтобы узнать, пишет ли вам человек: «Как продвигается ваша торговля сегодня?» на самом деле я или один из легионов самозванцев StuntPope в Твиттере. (Шучу, конечно, никто в здравом уме не будет выдавать себя за меня. Но для многих светил финтуита это настоящая проблема.)

Но что может случиться, если это станет соглашением, так это то, что разработчики могут встраивать в свои приложения быстрые и грязные крючки для выполнения этих поисков.

Когда поддельный профиль Twitter выдает себя за кого-то, они обычно копируют все данные дословно, включая имя хоста в поле URL-адреса профиля Twitter. Если у реального пользователя есть описанные выше записи, то при поиске фальшивого дескриптора Twitter по реальному URL-адресу будет пропущена фактическая запись _twitter TXT для настоящего профиля, и попадется запись с подстановочным знаком, что приведет к несоответствию.

Мы выпустили экспериментальное расширение Chrome через easyDNS Github, которое работает в трех режимах:

A) Информация не заявлена;

B) Профиль соответствует заявленной информации;

C) Профиль не соответствует заявленной информации (это подделка).

Все это и многое другое можно сделать с помощью очень простых соглашений в уже развернутом вездесущем протоколе.

Вывод

Адрес кошелька сам по себе нуждается в каком-то механизме именования. Есть несколько случаев использования, когда необходимость безопасного подтверждения адреса от удостоверения имеет приоритет над псевдонимом или анонимностью.

Кроме того, чтобы использовать удобочитаемые метки или идентификаторы, нам нужен уровень абстракции, который обеспечивает гибкость и легко узнаваемый формат.

Наконец, мы можем добиться всего этого, используя DNS, который уже лежит в основе технической инфраструктуры Интернета, уже является децентрализованной федерацией и находится на пути к привязке к децентрализованным протоколам уровня 1. Мы можем сделать это без добавления каких-либо новых типов записей или каких-либо дополнений протокола к существующим спецификациям.

Это гостевой пост Марка Джефтовича. Высказанные мнения являются полностью их собственными и не обязательно отражают точку зрения BTC Inc или Bitcoin Magazine.