Обмен электронных валют по самому выгодному курсу!
 


Kurbetsoft
Доступно в Google PlayВсе, что вы не знали о системе доменных имён Handshake

Статья о том, как один блокчейн-проект собирается победить Хранителей Интернета.

За созданием этого проекта стоят люди, подарившие миру Purse и Private Internet Access.

Handshake, несмотря на популярное заблуждение, не стремится децентрализовать существующую DNS-инфраструктуру во всей её полноте. Это значило бы замахнуться на нечто много большее, чем то, что может быть по зубам любой криптовалютной системе. Отчасти по этой причине ни одному из предшественников Handshake не удалось добиться истинного принятия.

Согласно белой книге проекта,

«Протокол именования Handshake отличается от предшественников тем, что он не содержит концепции организации пространства доменных имён или дочерних доменов на консенсус-уровне. Цель проекта заключается в замещении не всей системы доменных имён, но только файла корневой зоны и корневых серверов».

Многие не понимают, что система доменных имён уже децентрализована, за исключением одного критически важного компонента: корневой зоны, или, проще, совокупности доменов верхнего уровня (Top Level Domain, TLD). И этот «якорь доверия» удерживается небольшой федерацией авторитетных органов, наивысшей инстанцией среди которых на сегодняшний день является ICANN.

Проект Handshake намеревается заместить посредника в лице ICANN децентрализованным блокчейном на основе proof-of-work и использовать криптографические подписи для управления этой неотъемлемой частью инфраструктуры, на которой основывается безопасность самого интернета.

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

Я говорила с Кристофером Джеффри, плодовитым системным инженером, который спроектировал и написал реализацию блокчейна Handshake, а до того известным тем, что представил альтернативный биткойн-клиент bcoin.

Кроме того, я много дискутировала с Джозефом Пуном, безумным гением, стоящим за двумя главными решениями второго уровня для масштабирования блокчейнов – Lightning Network и Plasma, – который участвовал в разработке предлагаемых механизмов распределения для Handshake.

Готовы? Ведь вас ожидает погружение в самые глубины этого протокола, и чем дальше, тем больше технических подробностей будут вам открываться.

Все, что вы не знали о системе именования Handshake

Центры сертификации

Центры сертификации в DNS-сети, построенной так, как сегодня, являются доверенными распорядителями, ответственными за функционирование интернета. Целью этих организаций, как объясняется в whitepaper проекта, является максимизация прибыли. То есть, у ICANN нет альтруистических стимулов действовать добросовестно, но зато у неё есть все стимулы для сохранения своей естественной монополии на управление критически важным слоем глобальной сети. И даже если пока центры сертификации действуют добросовестно, точка зрения сторонников децентрализации основывается на том, что нам вообще не следовало бы полагаться на один централизованный орган управления, особенно если речь идёт о пространстве, где сосредоточено всё человеческое знание.

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

Познакомьтесь с Handshake

«Handshake – это проект по созданию децентрализованной сети, в рамках которой создаются криптоэкономические стимулы для координирования консенсуса относительно связи между именами и сертификатами».

Вопреки распространённому мнению, бóльшая часть проблем, с которыми мы сталкиваемся сегодня, с помощью блокчейна не решается. И многие из вас, скептиков, прекрасно это понимают. Но что касается Handshake, что делает этот специализированный блокчейн настолько полезным и, пожалуй, идеальным решением для управления распределением доменных имён?

Трилемма Зуко гласит, что, если речь идёт о пространстве имён, то одновременно можно удовлетворить только два из этих трёх свойств:

  1. удобочитаемые имена
  2. безопасность
  3. распределённое пространство имён

«Последние инновации в области блокчейн-технологий открывают возможность для обхода этой трилеммы через создание одной точки консенсуса в отношении связи между именами и сертификатами в виде единого децентрализованного блокчейна, представленного многими сторонами, проверяющими сеть. Для того чтобы достичь этого свойства безопасности, нужно не только перепроектировать «якорь доверия» центров сертификации, но и глубоко интегрироваться в саму инфраструктуру распределения имён», – whitepaper проекта Handshake.

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

Handshake, будучи блокчейном базового уровня, едва ли когда-то столкнётся с проблемами масштабируемости.

На вопрос о масштабируемости Handshake Кристофер ответил, что «этот блокчейн не предназначен для платежей, так что нет никакой нужды масштабировать его до пропускной способности Visa. Существующая корневая зона состоит всего из ~1500 доменов. Для того чтобы её заместить, блокчейн должен быть способен обработать 1500 доменов. Это совершенно пренебрежимое количество. Мы думаем, что он может обработать около 50–100 миллионов транзакций. С учётом продлений и определённых ограничений в ончейн-операциях, он, возможно, никогда и не выйдет за рамки 50–100 миллионов доменных имён. В конце концов, большую часть блоков будут составлять именно операции продления срока владения именем. Для каждого имени это нужно делать дважды в год».

Софт-форк к массовому принятию

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

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

Blockstack и ENS – вот два примера систем именования, которые никогда и не будут реально использоваться по назначению. Позвольте мне объяснить, почему. В обеих системах, для того чтобы преобразовать доменное имя, пользователь должен запустить полный валидирующий узел. И для чего мне нужны такие сложности, если всё, что мне нужно сделать для открытия веб-страницы, это через обычный браузер отправить запрос на DNS-резолвер Google?

«Мы намерены сохранять прозрачность и полную совместимость своей децентрализованной системы с протоколом, используемым IANA и ICANN. От большинства пользователей это не потребует никаких дополнительных действий».

Handshake был кропотливо реализован таким образом, чтобы быть софт-форком для существующей интернет-инфраструктуры, с полным осознанием того, что любые попытки перевести пользователей на новую, непроверенную систему являются нереалистичными и препятствуют широкому использованию системы. Речь идёт об ассимиляции, а не о миграции. И это делает использование системы именования Handshake намного более удобным в сравнении с предшественниками.

Для ускорения принятия своей системы проект использует два метода:

  • Компактные доказательства для локального разрешения имён (SPV)
  • Интегрирование стимулов от сопровождающих пакетов

Разрешение имён с SPV

Для обеспечения максимальной открытости, децентрализации, безопасности и, самое главное, устойчивости к цензуре, Handshake использует алгоритм proof-of-work. Такое решение позволяет тем, кто содержит узлы упрощённой проверки платежей (Simplified Payment Verification, SPV) бездоверительным образом разрешать имена со скоростью, превосходящей отправку запроса на DNS-резолверы Google. Это быстрее в том случае, если ваш полный/SPV узел имеет локальный кэш данных. (Я попробовала это на своём опыте, запустив SPV-клиент!)

В отличие от предшествующих протоколов, Handshake с введением компактных SPV-доказательств открывает совершенно новые перспективы. Это по определению позволяет исключить (что очень важно) из процесса верификации доверие к третьей стороне, так как ваш SPV-клиент позволяет локально запускать собственный рекурсивный DNS-резолвер. Архитектура же существующей DNS просто не допускает такого прямого разрешения без посредничества центрального органа.

Изначально в Handshake использовалась требовательная к памяти функция графа под названием Cuckoo Cycle, созданная Джоном Тромпом и применявшаяся в таких проектах, как æternity и MimbleWimble. Впоследствии от неё было решено отказаться в пользу SHA3, старой доброй хеширующей функции, которую невозможно взломать даже с использованием всех существующих вычислительных мощностей мира (и даже с квантовыми вычислениями будущего). Кристофер всерьёз обмолвился, что хочет сделать блокчейн Handshake настолько надёжным, чтобы он продолжал функционировать и после того, как человечество покинет Землю.

Интеграция со стороны сообщества FOSS (Free and Open-Source Software)

«…наша цель – работать с DNS, а не против него».

«Для того чтобы замена корневой зоны происходила прозрачно, рекурсивные резолверы должны ссылаться на авторитетный сервер имён, который обслуживает записи, внесённые в блокчейн, а не файл корневой зоны ICANN. Работать с такой динамикой трудно, поскольку практически ни одно пользовательское устройство в настоящее время не поставляется с локальным рекурсивным резолвером», – whitepaper проекта Handshake.

Целевой аудиторией «эйрдропов», или распределения кранов, является скорее всё FOSS-сообщество – в Github, Internet Relay Chat (IRC) и даже с эйрдропами среди долгосрочных держателей PGP и SSH-ключей – и призваны создать финансовый стимул для, например, разработчиков открытого ПО и сопровождающих пакетов, чтобы они включили в своё ПО библиотеку интеграции либо пакет со вспомогательной программой Handshake (hnsd). Чем выше интеграция, тем больше принятие.

«Это избавляет среднего пользователя от необходимости устанавливать дополнительные программы и возлагает ответственность за это на разработчиков ПО».

В этом есть большой смысл! Почему другие проекты так не делают?

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

Тем не менее социальный стимул для создания ПО, включающего в себя библиотеку интеграции Handshake, остаётся.

Рождение Urkel: от разреженных деревьев Меркла, Merklix-деревьев и MerkleSet к высокооптимизированному хранилищу проверенных данных

Следующий раздел основан на расшифровке моего интервью с Кристофером:

«Множество прошлых проектов именования не имели хорошей SPV, и это проблема, если вы действительно хотите безопасно разрешать имена. Вам не нужно содержать для этого полный узел; большинство людей не собираются этого делать. Большинство людей не станут локально хранить сотни гигабайтов данных блокчейна только для того, чтобы веб-браузер продолжал работать. Так что поддержка SPV для проекта Handshake была чрезвычайно важна. И поэтому нам была нужна какая-то структура проверенных данных».

– Кристофер Джеффри

Появление Handshake принесло с собой множество инноваций, которые, я думаю, ещё окажут воздействие на развитие всей криптосферы. Одно из наиболее примечательных таких новшеств – это проверяемое хранилище данных, называемое деревом Urkel. В отличие от всех предшествующих блокчейн-систем, Handshake использует собственную – первую в своём роде и реализованную специально для использования с блокчейнами – структуру аутентифицированных данных, которая не касается levelDB или любого другого хранилища данных.

Раздел whitepaper проекта с описанием дерева Urkel называется “Flat-File Merkle Tree” («Дерево Меркла с плоскими файлами»). Прежде чем остановить свой выбор на таком виде дерева, Кристофер провёл месяцы, исследуя структуры данных, используемые в существующих системах, а именно 16-ричное префиксное дерево (trie) Эфириума и разреженное дерево Меркла Google.

Но, поскольку задача протокола состоит в замещении корневой зоны DNS, поиск должен быть необременённым и быстрым, а доказательства – компактными. Эти бескомпромиссные требования привели к созданию Urkel. “Размер среднего DNS-сообщения составляет несколько сотен байтов. Поэтому, если вы хотите соответствовать скорости существующей корневой зоны и минимизировать накладные расходы, нужно, чтобы размер доказательств был как можно меньше», – говорит Кристофер.

«Наше дерево находится в серии плоских файлов только для записи, что, в сущности делает дерево собственной базой данных (поэтому нам не нужна levelDB) и имеет все необходимые функции традиционной базы данных: мгновенные снимки, корректное восстановление после сбоя, запросы по диапазону и итерацию.»

Urkel на данный момент написан на JavaScript, а портативная библиотека C запланирована на ближайшее будущее.

Дерево Меркла с плоскими файлами представляет собой адаптацию предложенных (хотя и не реализованных) Брэмом Коэном (Chia Network) и Амори Сечетом (deadal nix) (Bitcoin ABC) меркелизованных структур данных, называемых MerkleSet и Merklix Tree соответственно.

Кристофер обнаружил, что ни 16-ричное trie Эфириума, ни разреженное дерево Меркла, не отвечают требованиям Handshake:

«Поэтому я начал работать над собственным меркелизованным двоичным trie. Я хотел сделать его двоичным, чтобы максимально уменьшить размер доказательств. Каждый внутренний узел должен иметь только два возможных дочерних узла. И ещё я хотел реализовать это дерево в плоских файлах, непосредственно в файловой системе, без levelDB. Каждый внутренний узел содержит указатели на следующие узлы, а те хранятся где-то в файле. И для каждого узла, вы просто переходите к следующему, прочитав указатель. Такое решение показало себя очень хорошо. Код был проще, всё работало быстрее, доказательства были меньше».

Все, что вы не знали о системе именования Handshake
Меркелизованное двоичное префиксное дерево

Исследуя 16-ричное префиксное дерево Эфириума

«Мы рассмотрели множество вариантов; на исследование ушли месяцы. Начали мы с используемого в Эфириуме 16-ричного trie (на самом деле в Ethereum используется несколько таких деревьев). Это одна из немногих реально используемых структур аутентифицированных данных, поэтому нам было важно изучить её получше. Проблема с ней… На самом деле проблем было несколько, но главная заключалась в размере доказательства. Доказательства префиксного дерева Эфириума очень большие, поскольку это 16-ричное trie. Это означает, что каждый внутренний узел в trie имеет 16 дочерних узлов, и это делает внутренние узлы огромными. Так что, как только trie становится относительно глубоким, доказательства становятся большими. Мы видели доказательства размером в несколько Кбайт, и для нас это было неприемлемо. Другая проблема заключалось в том, что оно было реализовано поверх levelDB, и это замедляло производительность до совершенно черепашьих скоростей, поскольку бóльшую часть нагрузки на CPU и систему создавало одно только уплотнение levelDB. И оно постоянно сходит с ума, потому что в дереве levelDB так много обновлений. Так что таким образом вы получаете дерево внутри дерева, и это не очень оптимально».

Все, что вы не знали о системе именования Handshake
16-ричное префиксное дерево Ethereum

Ключевые результаты исследования:

  • В тестах производительности Urkel продемонстрировал примерно в 50–100 раз лучшую скорость, чем 16-ричное trie Эфириума.
  • Размер двоичных доказательств Urkel оказался в 4 раза меньше 16-ричных доказательств Ethereum.

Исследуя разреженное дерево Меркла

В процессе исследования реально используемых структур данных, прежде чем принять решение о выборе в пользу автономной структуры данных, предназначенной специально для блокчейнов, Кристофер пришёл к конструкции, которую рассматривал и Виталик в качестве предпочтительной структуры проверенных данных для Plasma, и называемой разреженным деревом Меркла (Sparse Merkle Tree, SMT). При её реализации Кристофер обнаружил, что этот вариант не жизнеспособен, так как тяжёлое кэширование, необходимое для поиска в базе данных, негативно влияло на удобство использования. Так что от этого варианта тоже было решено отказаться.

Проект Certificate Transparency от Google единственный использует в эксплуатационной среде SMT, реализованный также поверх существующего хранилища данных (levelDB).

Это решение было чрезвычайно медленным с точки зрения ввода-вывода с диска и циклов CPU. Для того чтобы вставить 5000 листьев, нужно сделать миллион кругов хеширования – просто безумие. Это нестрашно, если вы храните списки отзыва сертификатов, потому что они не так часто обновляются. Но для блокчейна, который часто обновляет дерево, это довольно плохое решение.

Блокчейны медленны по многим другим причинам. Для того чтобы увеличить скорость их работы, нужно, чтобы кэширование было эффективным. В таких языках, как Go, JavaScript или любом языке с автоматическим управлением памятью, помещать все эти данные в память просто страшно. В конце концов вы переложите слишком много активности на механизм автоматического управления памятью, в его работе произойдёт сбой, и проблема выплывет наружу. Как правило, хороший вариант – не нагружать память так сильно. Но с SMT вам нужно держать в памяти безумное количество данных просто для того, чтобы обеспечить скорость поиска. Да, можно добавлять данные пакетами. То есть можно вставить 5000 листьев одновременно. Если эти листья находятся где-то рядом друг с другом, это позволит пропустить несколько раундов хеширования. Проблема в том, что, если глубина дерева составляет 256 уровней, то вероятность того, что узлы будут находиться рядом составляет 1 к 2²⁵⁶, т.е. это практически невозможно. Впрочем, по мере движения вверх по дереву, вы экономите на раундах хеширования. Но вся система работает настолько медленно, что даже не имеет особого смысла возиться со сложным и трудозатратным процессом пакетирования данных. В конце концов, это практически ничего не меняет – настолько медленна сама по себе вся эта структура. Это нормально, если вы используете её для отзыва сертификатов, как Google, но использовать её с блокчейном – очень, очень плохая идея».

Ключевые результаты исследования:

  • Превосходство Urkel в быстродействии по сравнению с разреженным деревом Меркла от Google было поразительным – в 500 раз.
  • При этом компактные доказательства Urkel имели приблизительно тот же размер, что и сжатые SMT-доказательства – <1 Кбайта на десятки миллионов листьев. (Бинго!)

Из этого исследования Кристофер заключил, что «структуры проверенных данных, реализованные… поверх существующих хранилищ данных, имеют врождённые проблемы масштабируемости».

Такова истинная история происхождения Urkel (а не то, что вам покажут по телевизору).

Все, что вы не знали о системе именования Handshake

Ковенанты

Блокчейн Handshake не просто хранит историю переходов прав собственности на доменные имена; он реализует аукционную систему на уровне протокола и ончейн через предварительно заданные «смарт-контракты», называемые «ковенантами» (covenants) и впервые описанные Мальте Мёзер, Иттаем Эялом и Эмином Гюн Сирером.

Эти ковенанты допускают динамическое поведение на уровне консенсуса, обычно отсутствующее в высокоограниченных основанных на UTXO машинах состояний, как Биткойн. Стремление к ковенант-подобному поведению, в сущности, привело к эксперименту по созданию платформы приложений, известному как Ethereum, система на основе счетов. Но Handshake, с реализацией смарт-контрактов поверх системы, основанной на UTXO, с добавлением новых опкодов скриптов в готовый к использованию код – это ещё один пример инноваций, открывающий новые возможности для всей экосистемы. Эта конструкция позволяет посредством софт-форков вводить в протокол поддержку новых типов ковенантов способом, прямо совместимым с будущей сетевой инфраструктурой DNS. Однако ковенанты в Handshake остаются специализированными и не предназначены для построения децентрализованных приложений, как смарт-контракты в Ethereum – ещё одно проектное решение, делающее блокчейн Handshake в высокой степени оптимизированным для решения конкретной задачи именования.

«С нашей существующей на уровне консенсуса системой ковенантов мы можем реализовать на уровне блокчейна практически любой вид смарт контрактов».

Как работает аукционная система

Аукционная система реализована как ковенант на уровне консенсуса, разбитый на отдельные действия, описанные на выходном слое как covenant_type (настолько низкоуровнево, насколько возможно). В Handshake используется аукцион Викри, однораундный закрытый аукцион, в котором право на покупку получает участник, предложивший максимальную ставку, но покупка осуществляется по второй максимальной ставке. На том, как принималось решение об алгоритме проведения аукциона, мы подробно останавливаться не будем. Вместо этого я лучше расскажу вам непосредственно о процессе приобретения имён на Handshake.

Приведём наглядный пример: для того чтобы сделать ставку на приобретение доменного имени, нужно использовать тип ковенанта bid. Вы отправляете деньги на счёт ковенанта, где они блокируются до окончания аукциона. Это слепые ставки, истинные ставки других участников вам неизвестны. То есть, у вас есть фактическая ставка (скажем, 5 HNS), но по желанию вы можете задать для маскировки большее значение (например, 10 HNS), которое будет скрывать истинный размер вашей ставки.

Ковенант принимает вашу фактическую ставку, связывает её с неким случайным одноразовым кодом, хеширует и предоставляет вам полученный хеш. После недельного периода раскрытия вы раскрываете (reveal) использованный код, что открывает вашу фактическую ставку в 5 HNS. После раскрытия вы выводите со счёта ковенанта 5 HNS сдачи.

(заблокированная сумма) – (фактическая ставка) = ваша сдача

5 HNS вашей фактической ставки остаются заблокированными в течение двух недель, пока аукцион не будет закрыт. По окончании аукциона выбирается его победитель, а проигравшие получают свои ставки обратно – проигравшие могут выйти из ковенанта.

Деньги победителя – помните, покупка происходит по второй максимальной ставке – отправляются на другой ковенант, register. Ковенант register предназначен для ведения и обновления имён. Монеты, отправляемые на этот ковенант, не могут быть из него выведены, то есть монеты победителей аукционов фактически сжигаются.

Отзыв

Отдельно следует упомянуть ковенант с функцией отзыва имени (REVOKE). Подобно функции выхода из игры в Plasma, отзыв в Handshake является крайней мерой и последней возможностью для законного владельца имени отменить или оспорить его передачу в случае утраты владельцем своих ключей. Наличие этой опции полностью лишает кражу имён финансового стимула.

DNSSEC “доказательства владения”

Ещё одна ошибка в дизайне предшественников Handshake, которая станет для них фатальной, заключается в игнорировании существующих владельцев имён. Представим, что я Microsoft и вложил существенный капитал в свой бренд, стоимость которого инкапсулирована в доменное имя. И вот появляется какая-то новая предлагаемая DNS-система, которая говорит мне, что в их системе я больше не владею этим именем. С чего бы мне на неё переходить?

Имея это в виду, Handshake предварительно резервирует топ-100.000 имён по версии Alexa, право собственности на которые может быть заявлено их полноправными владельцами в течение 4-х лет с даты запуска основной сети. Для того чтобы предъявить право собственности на свои имена, владельцы просто представляют очень конкретное DNSSEC-доказательство, которое в протоколе Handshake довольно остроумно перепрофилировано для использования в качестве безопасного подтверждения права владения именем. Важно то, как именно они реализовали процесс подтверждения имён существующими владельцами – распределение имён производится автоматически блокчейном, без участия кого-либо, хоть как-то причастного к проекту.

Вот что рассказал мне об этом процессе Кристофер:

«Сложно сделать это криптографически, потому что у нас нет ключей всех этих людей. Да и не так много людей в действительности используют DNSSEC. Мы смотрели на DNSSEC и поняли, что их можно использовать для доказательства права собственности, хотя основная их функция заключается в другом. Они предназначены для защиты от атак «злоумышленник-в-середине», чтобы никто не мог подменить данные в процессе их передачи. Однако их можно использовать и для доказательства права владения, используя гораздо более строгое подмножество DNSSEC-доказательств, которое мы называем «DNSSEC-доказательства права владения».

 

Что мы делаем: поскольку большинство людей не настраивали DNSSEC, мы берём существующие ключи подписывания ключей (KSK) ICANN. Есть два вида таких ключей: один они создали в 2010 г., и сейчас они собираются переходить на новый ключ, созданный в 2017 г. В принципе, наличие этих двух RSA-ключей, жёстко закодированных в правила консенсуса, позволяет каждому из Alexa топ-100.000 в существующей корневой зоне доказать, что они владеют своим доменным именем, даже если на данный момент у них не настроен DNSSEC – они могут настроить его позже. Блокчейн будет валидировать цепь доверия DNSSEC, начиная с ключей подписывания ключей ICANN.

 

Это было непросто реализовать, потому что 1) DNSSEC – довольно сложная штука со множеством странных пограничных случаев, из-за чего мы используем для доказательств владения лишь небольшое подмножество DNSSEC, и 2) потому что большинство ключей – это RSA-ключи. RSA-ключи очень большие и подписи тоже не уступают в размере ключам. Каждый криптографический алгоритм, включая ECDSA, всегда имел по-настоящему странные пограничные случаи, которые нужно иметь в виду. Кроме того, RSA, в частности, открывает векторы для DoS-атак, потому что ключи могут быть разного размера. Так что нам потребовалось приложить много усилий для изучения DoS-лимитов для RSA-ключей и пограничных случаев с подписями PKCS1 v1.5. Мы даже обнаружили пограничные случаи в RSA-подписях, которые, я думаю, ещё не были замечены в DNSSEC. Думаю, что мы нашли несколько таких новых сценариев, пока прописывали всё это в протокол консенсуса. О них не упоминалось ни в каких RFC. Даже при том, что DNSSEC за десять лет был досконально описан во множестве самых разных RFC, ни в одном из запросов не было упоминаний о пограничных случаях, которые мы обнаружили. Это говорит о том, что специфицирование протокола консенсуса на самом деле даёт не так много, потому что всегда будут находиться эти самые пограничные случаи».

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

Вот где пригодятся средства венчурных капиталистов и фондов. Если ICO-модель потенциально деактуализирует этот класс инвесторов, то в модели изобилия им предназначена очень важная функция: оценить стоимость этих новосозданных койнов на основании сделанных инвестиций. С их инвестиционной поддержкой койны получают внутреннюю стоимость ещё до того, как будут выпущены на свободный рынок для определения цены. На момент написания статьи, венчурный капитал оценивает токен HNS в 0,10 $.

  • В общей сложности 7,5 % из 1,36 млрд монет HNS предназначены для выплат существующим владельцам доменных имён при предоставлении ими достаточно надёжных DNSSEC-доказательств собственности.
  • Ещё 2,5 % из 1,36 млрд монет предназначены для владельцев TLD, при условии, что они заявят и свои права на них.

Невостребованные монеты будут сожжены по окончании 4-летнего периода после запуска основной сети.

Интервал вывода имён

Люди могут открыть аукцион для любого имени, если оно не находится в списке предварительно зарезервированных имён и находится в пределах интервала вывода. Интервал вывода – это еженедельный вывод имён, которые становятся доступными для приобретения. В течение одного года для участия в торгах станут доступны все имена.

Для определения того, находится ли имя в интервале вывода, аналогично тому, как это реализовано в ENS, протокол Handshake хеширует имя, которое вы хотите открыть, запускает SHA3 над строкой, берёт остаток от деления на 52 и даёт вам конкретный номер недели, затем умножает это число на среднее количество блоков в неделю, в результате чего вы получаете высоту блока, на которой будет выводиться на рынок ваше имя. Таким образом, интервал вывода является детерминистически случайным и равномерно распределяется для всех доступных имён.

Заключительные замечания

Я написала эту статью, потому что очень верю в будущее Handshake, зная уровень мастерства и степень дотошности, с какими реализовывался этот проект.

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

«Это исключительно дорого стоит – построить крупную организацию с иерархической вертикальной структурой для замещения укоренившихся интересов, поэтому мы предлагаем строить структуру с нуля, по принципам экономики дарения, что возможно лишь с применением новых блокчейн-технологий, позволяющих учитывать стоимость без участия централизованного управления, а также с инструментами широкомасштабной координации усилий миллионов людей… Handshake – это открытая инициатива участников со всего мира по формированию новой системы именования и принесению её в дар всему мировому сообществу».

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

 

Подписывайтесь на BitNovosti в Telegram!
Делитесь вашим мнением об этой статье в комментариях ниже.

Источник




[vkontakte] [facebook] [twitter] [odnoklassniki] [mail.ru] [livejournal]

Каталог сайтов