В прошлом средства, с помощью которых выделялись новые пространства имен, представляли собой централизованный процесс, при котором владельцы контрактов на пространство имен (команда Kadena) действовали аналогично корневому серверу имен, записывая пространства имен в реестр по запросу. Однако теперь, когда экосистема Kadena стремительно развивается, команда Kadena представляет первый из серии шагов по децентрализации процесса регистрации и делегированию определения пространства имен пользователям, позволяя им создавать имена пространств имен, производные от выбранных ими средств управления.
Эта статья служит введением в концепцию пространств имен, как они работают в Kadena и как новый децентрализованный процесс работает для пользователей. Если вы уже знакомы с пространствами имен и с тем, как они работают, то смело переходите к последнему разделу.
Что в названии (пробел)?
Пространства имен Kadena относительно просты на практике. Они используются ровно в двух сценариях:
- Определение контракта, в котором модуль публикуется в пространстве имен, что позволяет получить доступ к модулю и его членам с помощью префикса пространства имен и точки (например, если у вас есть пространство имен my-namespace, то, если вы определите my-module внутри него, вы можете получить доступ к его членам выдав my-namespace.my-module.my-function.
- Определение набора ключей, в котором набор ключей определен в пространстве имен, и на него можно ссылаться по его имени с префиксом имени пространства имен, в котором он был определен. Это позволяет наборам ключей существовать с одинаковым именем, позволяя пространству имен различать, на какой набор ключей с общим именем ссылается конкретный фрагмент кода. Это также работает для именованных ссылок на наборы ключей.
Есть две встроенные функции, необходимые для определения и “ввода” пространства имен для определения конструкций: define-namespace и namespace. При определении пространства имен необходимо предоставить протокол управления пользователями и администраторами (набор ключей или, в более общем плане, guard), чтобы определить пространство имен и тех, кто может загружать в него данные. Для более подробного обсуждения смотрите Pact Language ReadTheDocs.
В целом, процесс довольно прост. Чтобы определить пространство имен, необходимо только выполнить следующее:
Пространства имен в блокчейне
На практике, при взаимодействии с публичным блокчейном Kadena прикладной уровень Pact реализует средства, с помощью которых достигается разрешение пространства имен, поэтому для правильного разрешения необходимо немного "завязать узел". В genesis все основополагающие контракты были загружены в корневое пространство имен, которое было зарезервировано для специальных определений. Одним из них был контракт пространства имен под названием ns, который предоставлял логику разрешения и таблицу реестра для пространств имен.
Уровень выполнения транзакции указывает на конкретную функцию в этом контракте под названием “validate”, которая обеспечивает направление во время компиляции для разрешения пространств имен через таблицу реестра пространств имен. Вот тут-то и происходит волшебство. Контракт на пространство имен сам по себе не является “особенным” с точки зрения возможности обновления или владения; логика, с помощью которой разрешаются имена, может быть изменена по мере изменения требований внутри экосистемы. Это чрезвычайно мощная и недооцененная функция, не похожая ни на один блокчейн: пространства имен и связанные с ними политики разрешения созданы для масштабирования с помощью блокчейна и немедленно поддаются децентрализованному управлению.
Автономно генерируемые пространства имен
В качестве первого шага к децентрализованному определению пространства имен Kadena решила предложить автономное определение пространства имен, производное от набора ключей, и мы называем такое определение “основным” пространством имен. Эти пространства имен являются основными в том смысле, что они автономно воспроизводятся из административного набора ключей и, как результат, глобально уникальны. Процесс довольно прост, но для начала требуется немного знаний.
Kadena обновила свой контракт на пространство имен mainnet (ns), добавив функцию, которую пользователь может вызвать, чтобы сгенерировать имя основного пространства имен, которое они могут использовать без регистрации в реестре ns, а также изменив способ проверки пространства имен, чтобы позволить пользователям начать использовать свои основные пространства имен без дальнейшей работы. В качестве предостережения, такие определения основного пространства имен доступны только для наборов ключей с одним и несколькими знаками.
Чтобы создать основное пространство имен, нужны только ключи, которые они хотят использовать для администрирования пространства имен, и вызвать новую функцию create-principal-namespace, экспортированную из ns. В коде:
А как насчет пространств имен vanity?
Немедленной реакцией на это, очевидно, будет: “Какой непрозрачный формат! Разве у меня не может быть чего-то вроде the cool kids с доменами .eth?” Ответ заключается в том, что текущая функциональность является ступенькой на пути к созданию доменных имен vanity в том же смысле, в каком сопоставления имен в стиле ENS преобразуют имена в контрактные адреса. Текущая итерация, по крайней мере, обеспечивает децентрализованное определение пространства имен и является необходимым шагом к масштабированию блокчейна Kadena для разработчиков.
Вывод
Я надеюсь, что этот головокружительный тур по пространствам имен был полезен для всех! Мы стремимся предоставлять как можно больше обновлений, поскольку Kadena продолжает внедрять инновации. У нас впереди светлое, оптимистичное будущее, поскольку мы продолжаем раскрывать возможности децентрализации и масштабируемости для разработчиков нашей экосистемы. Следите за обновлениями до 2023 года — впереди еще многое!
Sign up for the Kadena Newsletter