name: Построение с помощью элементов и жидкой сети goal: Научитесь использовать и разрабатывать на основе блокчейн-платформы Elements с открытым исходным кодом и ее ключевых возможностей objectives:

Построение на основе жидкости и элементов

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

Liquid, основанный на фреймворке Elements, предназначен для повышения конфиденциальности, масштабируемости и функциональности финансовых и технических решений. На этом курсе вы получите практический опыт в области эмиссии и управления активами, федеративной двухсторонней привязки, а также использования таких инструментов, как elementsd и elements-cli, что позволит вам создавать инновационные решения, отвечающие вашим потребностям.

Этот курс рассчитан на разработчиков всех уровней. Начинающие и средние пользователи найдут доступные объяснения и практические примеры, а опытные пользователи смогут углубиться в технические детали и малоизвестные возможности Liquid и Elements.

Присоединяйтесь к нам, чтобы повысить свою квалификацию, раскрыть весь потенциал Liquid и Elements и создать эффективные инструменты для будущего инноваций Liquid.

Введение

Обзор курса

Добро пожаловать на курс SID202!

Цель Elements Academy — представить и объяснить ключевые концепции Elements, платформы с открытым исходным кодом, на которой построена сайдчейн Liquid. По завершении этого курса вы должны иметь чёткое понимание основных функций Elements, таких как конфиденциальные транзакции и выпущенные активы, а также процессов, связанных с работой Elements Core. Каждая часть курса включает уроки с пояснительными текстами и видеороликами, которые заканчиваются викториной.

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

Раздел 1: Введение
Мы начнём с комплексного обзора концепций Elements. Вы узнаете, как эта платформа была создана для обеспечения модульной и гибкой базы для создания сайдчейнов, таких как Liquid. Цель — понять структуру Elements перед тем, как перейти к его практическому применению.

Раздел 2: Elements
Этот раздел сосредоточится на работе Elements. Вы узнаете, как настроить узел Elements, управлять им в автономном режиме или использовать его как сайдчейн.

Раздел 3: Использование Elements – Практические примеры
После освоения теоретических основ мы перейдём к практическому применению Elements. Вы узнаете, как выполнять конфиденциальные транзакции, выпускать активы и управлять их переизданием.

Раздел 4: Федерация Elements
Здесь мы рассмотрим продвинутые механизмы, включая федеративное подписание блоков, использование Elements как сайдчейна и создание независимых блокчейнов. Этот раздел поможет вам понять, как обеспечить безопасность, целостность и совместимость блокчейнов на основе Elements.

Готовы исследовать потенциал Elements и сайдчейна Liquid? Поехали!

Обзор элементов

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

По своей сути Elements - это протокол, который позволяет достичь консенсуса в отношении истории транзакций и правил, регулирующих передачу и создание активов, хранящихся в распределенной блокчейн-бухгалтерии.

Дополнительную справочную информацию о Elements можно найти на сайте проекта Elements (https://elementsproject.org/), в официальном блоге Liquid (https://blog.liquid.net/) и на портале разработчиков (https://liquid.net/devs).

Элементы

Запущенный в 2015 году, Elements сокращает внутренние затраты на разработку и исследования и использует самые современные технологии блокчейна, открывая множество новых вариантов использования. Блокчейн на базе Elements может работать как самостоятельный блокчейн или быть привязанным к другому блокчейну и работать как сайдчейн. Запуск Elements в качестве сайдчейна позволяет верифицированно передавать активы между различными блокчейнами.

Построенная на основе кодовой базы Bitcoin и расширяющая ее, она позволяет разработчикам, знакомым с API bitcoind, быстро и без лишних затрат создавать работающие блокчейны и тестировать пробные проекты. Построенная на кодовой базе Bitcoin, Elements также может выступать в качестве тестовой площадки для изменений в самом протоколе Bitcoin.

Далее перечислены некоторые из основных особенностей Elements.

Конфиденциальные сделки

По умолчанию все адреса в Elements ослеплены с помощью Конфиденциальных транзакций. Ослепление - это процесс, при котором сумма и тип передаваемого актива криптографически скрываются от всех, кроме участников и тех, кому они решили раскрыть ключ ослепления.

Выпущенные активы

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

Федеративная двухсторонняя прищепка

Elements - это блокчейн-платформа общего назначения, которая также может быть "привязана" к существующему блокчейну (например, Bitcoin), чтобы обеспечить двустороннюю передачу активов из одной цепи в другую. Реализация Elements в качестве сайдчейна позволяет обойти некоторые свойства, присущие основной цепи, сохраняя при этом значительную степень безопасности, обеспечиваемую активами, защищенными на основной цепи.

Подписанные блоки

В Elements используется сильная федерация подписантов, называемых Block Signers, которые надежно и своевременно подписывают и создают блоки. Это устраняет задержку транзакций в процессе PoW-майнинга, который подвержен большим колебаниям времени блока из-за случайного пуассоновского распределения. Процесс Federated Block Signing обеспечивает надежное создание блоков, не требуя доверия третьей стороны или вычислительных алгоритмов майнинга.

Elements добавляет все эти функции поверх кодовой базы Bitcoin Core, расширяя возможности протокола mainchain и позволяя использовать новые бизнес-кейсы при развертывании в качестве sidechain или отдельного блокчейн-решения.

Элемент

Как работает Elements

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

Elements преодолевает эти проблемы благодаря использованию федеральной блокчейн-подписи и конфиденциальных транзакций.

В отличие от сети Bitcoin, процесс подписания блоков в Elements не зависит от динамических многосторонних подписей (DMMS) и доказательства работы (PoW). Вместо этого Elements использует сильную федерацию подписантов, называемых Block Signers, которые могут подписывать и создавать блоки надежным и своевременным образом. Это устраняет задержку транзакций в процессе майнинга PoW, который подвержен большим колебаниям времени блока из-за его случайного пуассоновского распределения. Процесс Federated Block Signing обеспечивает надежное создание блоков, не требуя доверия третьей стороны.

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

При использовании в качестве сайдчейна Strong Federation также содержит членов, которые обеспечивают безопасную и контролируемую передачу активов между основной цепочкой и сайдчейном Elements. Контролируемая передача активов называется Federated 2-Way Peg, а члены, выполняющие роль передачи активов, называются Watchmen.

Процессы, происходящие в сети Elements, и роли участников сети важны для понимания того, как работает Elements.

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

Сильные федерации

В Elements используется модель консенсуса, впервые предложенная компанией Blockstream и называемая Strong Federations. Сильная федерация не нуждается в доказательстве работы (PoW) и вместо этого полагается на коллективные действия группы взаимно недоверяющих участников, называемых функционерами.

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

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

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

Ознакомиться с информационным бюллетенем "Сильные федерации" можно здесь: https://blockstream.com/strong-federations.pdf

Подписывающие блок

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

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

Федеративная подпись блоков состоит из нескольких этапов:

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

Элементы как сайдчейн - Watchmen и Federated 2-Way Peg

При работе в качестве сайдчейна некоторые члены Сильной Федерации выполняют дополнительную роль - Сторожей. Сторожа отвечают за передачу активов в сайдчейн Elements и из него, процессы, известные как Peg-In и Peg-Out.

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

Функция Federated 2-way Peg позволяет активу быть совместимым с другими блокчейнами и представлять родной актив другого блокчейна. Привязывая свой блокчейн к другому, вы можете расширить возможности основного блокчейна и преодолеть некоторые присущие ему ограничения.

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

Чтобы перевести активы обратно в мейнчейн, пользователь совершает специальную транзакцию peg-out на сайдчейне. Эта транзакция проверяется Watchmen, которые затем подписывают транзакцию, расходуя средства из кошелька с мультиподписью, который они контролируют на mainchain. Пороговое число участников федерации должно подписать транзакцию, прежде чем она станет действительной на mainchain. Когда Watchmen отправляют актив обратно в mainchain, они также уничтожают соответствующую сумму на sidechain, эффективно передавая активы между blockchain.

Настройка и запуск элементов

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

Само программное обеспечение узла Elements называется elementsd и запускается как демон на машине пользователя. Демон (или служба в Windows) - это программа, которая работает в качестве фоновой службы, не требуя прямого контроля со стороны вошедшего в систему пользователя.

Примечание: В этом документе мы всегда будем ссылаться на elementsd как на версию демона, но все можно сделать и с помощью elements-qt, при условии, что опция сервера включена.

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

Программное обеспечение Elements также состоит из клиентской программы elements-cli, которая позволяет отправлять команды Remote Procedure Call (RPC) на elementsd из командной строки. Это можно использовать, например, для запроса баланса кошелька, просмотра данных о транзакциях или блоках или трансляции транзакции. Эта настройка должна быть знакома всем, кто использовал эквиваленты Bitcoin: bitcoind и bitcoin-cli.

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

Репозиторий кода элементов и сообщество

Elements - это проект с открытым исходным кодом, и его исходный код можно найти в репозитории Elements на GitHub по адресу https://github.com/ElementsProject/elements. Репозиторий содержит исходные тексты программ elementsd и elements-cli, а также вспомогательные инструменты для установки и сборки, набор тестов и некоторую обучающую документацию.

В дополнение к репозиторию кода существует веб-сайт https://elementsproject.org - ресурс, ориентированный на сообщество и содержащий объяснения того, что такое Elements, как он работает, а также обширный раздел учебников. Учебник посвящен изучению Elements на примерах из командной строки и показывает, как создавать на его основе простые настольные и веб-приложения. На сайте также представлены популярные форумы для обсуждения Elements, а сам он размещен на GitHub, что позволяет вносить вклад в содержание сайта.

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

Настройка узлов и сети

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

Настройки либо загружаются из указанного файла elements.conf, либо передаются в качестве параметров через командную строку.

Некоторые вещи можно изменить с помощью этих параметров:

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

Использование параметров будет рассмотрено далее в курсе, когда они будут относиться к каждому разделу.

Основные операции с помощью командной строки

В этом курсе будут показаны примеры использования программы elements-cli для выполнения RPC-вызовов к одному или нескольким узлам Elements. Это делается из терминальной сессии, и для того, чтобы сделать команды более краткими, будет использоваться алиас. В соответствии с этим соглашением, когда вы видите что-то вроде следующих команд:

e1-dae
e1-cli getnewaddress

e1-dae и e1-cli на самом деле являются типографским сокращением, использующим функцию терминала alias. При выполнении команды e1-dae и e1-cli будут заменены, и выполняемая команда будет выглядеть следующим образом:

$HOME/elements/src/elementsd -datadir=$HOME/elementsdir1
$HOME/elements/src/elements-cli -datadir=$HOME/elementsdir1 getnewaddress

То, что мы видим выше, - это вызов запуска демона Elements и вызов программ elements-cli, расположенных в директории $HOME/elements/src, и значение параметра datadir. Параметр datadir позволяет нам указать демону и клиентским экземплярам, где располагать их конфигурационные файлы и, в случае демона, где хранить его копию блокчейна. Поскольку у них общий файл конфигурации, клиент сможет выполнять RPC-вызовы к демону.

Выполнив вышеуказанную команду еще раз, но с другим значением datadir, мы сможем запустить несколько экземпляров Elements, каждый со своей отдельной копией блокчейна и настройками конфигурации. В соответствии с этим соглашением мы будем использовать псевдонимы e2-dae и e2-cli в курсе, чтобы ссылаться на каталог datadir, отличный от каталога e1. Таким образом, вышеприведенный пример для нашего второго экземпляра e2 будет выглядеть так:

$HOME/elements/src/elementsd -datadir=$HOME/elementsdir2
$HOME/elements/src/elements-cli -datadir=$HOME/elementsdir2 getnewaddress

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

Использование элемента Практический пример использования

Конфиденциальные сделки

В этом разделе вы узнаете, как использовать функцию "Конфиденциальные сделки" в Elements.

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

Конфиденциальные адреса и конфиденциальные сделки

По умолчанию, когда вы создаете новый адрес в Elements с помощью команды getnewaddress, он создается как конфиденциальный.

Чтобы продемонстрировать конфиденциальные транзакции, мы попросим e2 отправить себе некоторые средства, а затем попытаемся просмотреть транзакцию из e1. Это продемонстрирует конфиденциальный характер транзакций в Elements.

Каждый новый адрес, сгенерированный узлом Elements, по умолчанию является конфиденциальным. Мы можем продемонстрировать это, заставив e2 сгенерировать новый адрес.

e2-cli getnewaddress

Обратите внимание, что адрес начинается с e1. Это идентифицирует его как конфиденциальный адрес. При более детальном изучении адреса с помощью команды getaddressinfo можно получить более подробную информацию об адресе.

e2-cli getaddressinfo <address>

Вы видите, что здесь есть свойство confidential_key, которое говорит нам о том, что это конфиденциальный адрес.

Конфиденциальный_ключ - это открытый ослепляющий ключ, который добавляется к самому конфиденциальному адресу. Именно по этой причине конфиденциальный адрес такой длинный.

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

Теперь мы можем попросить e2 отправить часть средств на сгенерированный им адрес. Впоследствии это продемонстрирует, что e1, поскольку он не является одной из сторон сделки, не сможет просмотреть детали транзакции.

e2-cli sendtoaddress <address>

Запомните идентификатор транзакции. Подтвердите транзакцию.

e2-cli -generate 101

Если посмотреть на транзакцию, в которой e2 отправила часть средств себе, с точки зрения самой e2.

e2-cli gettransaction <txid>

Прокрутив детали транзакции вверх, вы увидите, что e2 может просматривать отправленные и полученные суммы, а также активы, с которыми была проведена операция. Вы также можете увидеть свойства amountblinder и assetblinder, которые используются для скрытия деталей от других узлов, не участвующих в транзакции.

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

e1-cli getrawtransaction <txid>

Это возвращает необработанные данные о транзакции. Если вы посмотрите на раздел vout, то увидите, что здесь есть три экземпляра. Первые два экземпляра - это суммы получения и сдачи, а третий - комиссия за транзакцию. Из этих трех сумм комиссия - единственная, в которой вы можете увидеть значение, поскольку сама комиссия всегда не замазана в Elements.

Слепые ключи

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

Даже если мы импортируем закрытый ключ e2 в кошелек e1, он все равно не сможет увидеть суммы и тип активов, с которыми были совершены операции, поскольку не будет знать о слепом ключе, используемом e2. Мы докажем это, импортировав закрытый ключ, используемый кошельком e2, в кошелек e1. Сначала нам нужно экспортировать ключ из e2

e2-cli dumpprivkey <address>

Затем импортируйте его в e1.

e1-cli importprivkey <privkey>

Теперь мы можем доказать, что e1 по-прежнему не видит значений.

e1-cli gettransaction <txid>

Действительно, он показывает 0 в качестве суммы tx, в то время как на самом деле это была 1.

Чтобы увидеть фактическое, неблинованное значение, нам нужен ключ ослепления. Для этого мы сначала экспортируем ключ ослепления из e2.

e2-cli dumpblindingkey <address>

Затем импортируйте его в e1.

e1-cli importblindingkey <address> <blinding key>

Теперь, когда мы получаем данные о транзакции из e1.

e1-cli gettransaction <txid>

Это показывает, что, импортировав ослепляющий ключ, мы теперь можем увидеть фактическое значение 1 в транзакции.

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

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

На этом урок закончен, удачи в викторине и до встречи в следующем уроке!

Выпущенные активы

В этом разделе вы узнаете, как использовать функцию "Выданные активы" в Elements.

Выпущенные активы позволяют выпускать несколько типов активов и передавать их между участниками сети Elements. Любой узел сети может выпускать свои собственные активы. Эмиссия может представлять собой взаимозаменяемое владение любым активом, включая ваучеры, купоны, валюту, депозиты, облигации, акции и т. д. Выпущенные активы открывают возможности для создания бездоверительных бирж, опционов и других продвинутых смарт-контрактов с использованием самостоятельно выпущенных активов.

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

Для начала нам понадобится доступ к двум узлам Elements, которые мы назовем e1 и e2. Эти узлы обнулили свои блокчейны и разделили между ними активы по умолчанию.

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

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

Это делается с помощью команды listissuances.

e1-cli listissuances
e2-cli listissuances

Как вы можете видеть, оба узла показывают одинаковую историю эмиссии. Они оба отображают один актив - первоначальную эмиссию 21 миллиона биткойнов, которые были созданы при инициализации цепи. Вы можете увидеть шестнадцатеричный идентификатор актива в результатах выполнения приведенной выше команды, а также метку, присвоенную активу, - "bitcoin".

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

Мы попросим e1 выпустить новый актив. Это делается с помощью команды issueasset.

e1-cli issueasset 100 1 false

issueasset принимает 3 параметра.

Количество нового актива для выпуска, мы использовали 100. Количество создаваемых токенов (токены используются для повторной эмиссии количества актива), мы выбрали 1. Последний параметр указывает Elements на то, чтобы создать эмиссию актива вслепую или без слепого контроля. Мы будем использовать вариант "без слепых", так как хотим просмотреть суммы эмиссии из e2 через минуту, поэтому введем false.

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

Сгенерируйте блок для подтверждения транзакции эмиссии.

e1-cli -generate 1

Снова выполните команду listissuances для e1.

e1-cli listissuances

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

Проверьте список известных выпусков e2 еще раз.

e2-cli listissuances

Это говорит о том, что e2 не знает о выпуске активов, который произвел e1. Он может видеть только первоначальную эмиссию биткойна, которую он уже мог видеть.

Это происходит потому, что e2 не знает и не следит за адресом, на который был отправлен новый актив, когда он был выпущен e1.

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

Чтобы e2 мог видеть фактическую выдачу (и, следовательно, выданную сумму), нам нужно добавить адрес в e2 как наблюдаемый адрес.

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

e1-cli gettransaction <the-issuance-transaction-id>

Если прокрутить вверх шестнадцатеричное значение данных транзакции, то вы увидите адрес, на который поступило 100 единиц нашего нового актива, обозначенный шестнадцатеричным значением.

Возьмите адрес и скопируйте его, чтобы мы могли импортировать его в e2.

Теперь давайте импортируем этот адрес в e2. Для этого мы используем команду importaddress.

e2-cli importaddress <the-issued-to-address>

Если мы теперь проверим список выпусков e2.

e2-cli listissuances

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

e1-cli stop

Затем перезапустите его с дополнительным параметром, который сопоставляет гекс актива с предоставленной меткой. Это позволит узлу отображать данные об активе в более понятном для человека формате. Вы можете добавить этот параметр в конец файла elements.conf, если хотите, тогда вам не нужно будет добавлять аргумент демону при каждом запуске. Например:

assetdir=5186d0bc8ed15e6ef85571bd2d8070573adf0e06fd4507082694526975ce4f35:My new asset (MNA)

Но здесь мы будем использовать метод аргументов.

e1-dae -assetdir=<assetid-here>:<name-of-the-new-asset>

Повторный запрос узла на получение списка выпусков.

e1-cli listissuances

Это показывает, что сопоставление шестнадцатеричного значения актива с его меткой работает. Проверяем еще раз список выпусков узла e2.

e2-cli listissuances

Видно, что узел e2 не имеет доступа к этой метке, поскольку метки доступны только тому узлу, который их установил. Действительно, мы можем присвоить одному и тому же гексу актива на узле e2 другую метку, чем на узле e1. Сначала остановите узел e2.

e2-cli stop

Перезапуск с другой меткой, присвоенной гексу нашего нового актива.

e2-dae -assetdir=<assetid-here>:<another-name-for-the-new-asset>

Листинг выпусков из e2.

e2-cli listissuances

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

Сопоставление метки с гексом актива полезно при выполнении таких действий, как транзакции и запросы баланса кошелька, поскольку позволяет сокращенно ссылаться на актив. Например, если бы мы хотели отправить часть нашего нового актива (сумму в 10) из e1 в e2 без использования метки.

Сначала нам нужно получить адрес, на который будет отправлен актив.

e2-cli getnewaddress

Затем используйте команду sendtoaddress.

e1-cli sendtoaddress <address> 10 "" "" false false 1 UNSET false <asset-id-here>

Подтвердите транзакцию, сгенерировав блок.

generate 1

Проверка получения актива на e2.

e2-cli getwalletinfo

Мы видим, что актив действительно был получен.

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

e1-cli sendtoaddress <address> 10 "" "" false false 1 UNSET false <name-of-the-new-asset>

За кулисами Elements отображает локальные метки в шестнадцатеричные значения, чтобы упростить использование выданных активов.

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

Переоформление активов

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

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

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

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

Нам понадобится доступ к двум узлам Elements, которые мы назовем e1 и e2. Эти узлы обнулили свои блокчейны и разделили между ними активы по умолчанию.

Пусть e1 выпустит 100 единиц нового актива и создаст 1 токен перевыпуска для этого же актива. Для упрощения примера мы создадим эмиссию без привязки. Итак, давайте приступим к выпуску актива и связанного с ним токена перевыпуска.

e1-cli issueasset 100 1 false

Обратите внимание на идентификатор актива, а также на идентификатор (перевыпуска) токена.

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

Подтвердите транзакцию.

e1-cli -generate 1

Теперь мы проверим детали транзакции с помощью команды gettransaction:

e1-cli gettransaction <txid>

Прокрутив вверх шестнадцатеричную часть данных транзакции, вы увидите, что в транзакции e1 получил 1 токен перевыпуска и 100 связанных с ним активов.

Сделайте копию адреса, чтобы мы могли импортировать его в e2.

А теперь импортируем адрес в кошелек e2.

e2-cli importaddress <address>

Теперь мы видим, что и e1, и e2 знают о выпуске актива.

e1-cli listissuances
e2-cli listissuances

В настоящее время e1 имеет некоторое количество актива и 1 токен перевыпуска, а e2 - нет.

e1-cli getwalletinfo

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

e2-cli getwalletinfo

Поскольку у e1 есть токен перевыпуска, он может перевыпустить большее их количество. Для этого используется команда reissueasset. Пусть e1 перевыпустит еще 100 единиц актива.

e1-cli reissueasset <asset-id> 100

Проверка повторной выдачи прошла успешно.

e1-cli getwalletinfo

Как и ожидалось, вы видите, что e1 теперь владеет 200 активами.

Поскольку у e2 нет количества токенов для перевыпуска, при попытке перевыпустить актив они получат ошибку.

e2-cli reissueasset <asset-id> 100

Обратите внимание на сообщение об ошибке.

Мы можем просмотреть детали перевыпуска из e1 с помощью команды listissuances.

e1-cli listissuances

Обратите внимание на флаг is_reissuance.

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

e2-cli getnewaddress

Затем отправьте часть RIT из e1 в e2.

e1-cli sendtoaddress <address-of-e2> 0.1 "" "" false false 1 UNSET false <reissuance-token-id>

Подтвердите транзакцию.

e1-cli -generate 1

Теперь мы видим, что e2 удерживает отправленные ему 0,1.

e2-cli getwalletinfo

Это означает, что e2 теперь может перевыпустить большее количество актива, связанного с RIT, который он держит в своем кошельке. Пусть e2 перевыпустит 500 единиц актива.

e2-cli reissueasset <asset-id> 500

Проверьте результат перевыпуска.

e2-cli getwalletinfo

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

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

e2-cli destroyamount <asset-id>
e2-cli getwalletinfo

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

Федерация элементов

Блочная подпись

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

Ранее, для простоты примера, мы создавали блоки с помощью команды generate, которая не требовала наличия нескольких подписей для того, чтобы созданные блоки принимались сетью как действительные.

Мы настроим наши узлы так, чтобы они требовали создания мультисигмальных блоков 2 из 2. Для этого используется параметр signblockscript, который может быть добавлен в конфигурационный файл или передан узлу при запуске. Чтобы инициализировать цепочку с этим параметром, нам сначала нужно создать скрипт, из которого она будет состоять.

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

Нам понадобится доступ к двум узлам Elements, которые мы назовем e1 и e2. Эти узлы обнулили свои блокчейны и разделили между ними активы по умолчанию.

Убедитесь, что параметр con_max_block_sig_size установлен на большое значение в файле elements.conf, иначе в дальнейшем в этом разделе подпись блоков не будет работать. В этом руководстве мы установили con_max_block_sig_size=2000.

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

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

e1-cli getnewaddress
e2-cli getnewaddress

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

e1-cli getaddressinfo <e1-address>
e2-cli getaddressinfo <e2-address>

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

e1-cli dumpprivkey <e1-address>
e2-cli dumpprivkey <e2-address>

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

Любой из узлов, e1 или e2, может сгенерировать мультисигму.

e1-cli createmultisig 2 '["<e1-pubkey>", "<e2-pubkey>"]'

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

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

Удалив существующие данные кошелька и цепочки, мы можем запустить наши узлы и инициализировать новую цепочку с помощью параметра signblockscript. Давайте передадим параметр -evbparams=dynafed:0:::, чтобы отключить активацию dynafed, поскольку в данном примере нам не нужна эта расширенная функция.

e1-dae -signblockscript=<redeem-script> -evbparams=dynafed:0:::
e2-dae -signblockscript=<redeem-script> -evbparams=dynafed:0:::

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

e1-cli importprivkey <e1-priv-key>
e2-cli importprivkey <e2-priv-key>

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

e1-cli -generate 1

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

e1-cli getnewblockhex

Помните, что эта команда только создает предлагаемый блок, но не генерирует его.

Чтобы подтвердить это, мы видим, что в настоящее время в нашем блокчейне нет ни одного блока.

e1-cli getblockcount

Если мы попробуем отправить блок hex, не подписав его сначала.

e1-cli submitblock <block-hex>

Мы получаем сообщение о том, что доказательство блока недействительно. Это происходит потому, что он еще не подписан двумя из необходимых двух сторон.

Итак, давайте попросим e1 подписать предложенный блок.

e1-cli signblock <block-hex>

Попросите e2 подписать гекс.

e2-cli signblock <block-hex>

Обратите внимание, что e2 не подписывает выход, созданный в результате подписи предложенного блока e1. Они оба подписывают предложенный блок hex независимо от результатов друг друга.

Теперь нам нужно объединить подписи блоков e1 и e2. Это может сделать любой из узлов, все, что им нужно, - это подписанный гекс блока от другого узла.

e1-cli combineblocksigs <block-hex> '["<signed-hex-from-e1>", "<signed-hex-from-e2>"]'

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

Теперь любой из узлов может отправить готовый блок hex. Мы попросим e1 сделать это.

e1-cli submitblock <combined-signed-hex>

Проверка правильности отправки.

e1-cli getblockcount
e2-cli getblockcount

Вы видите, что и e1, и e2 приняли блок как действительный и добавили его в вершину своих локальных копий блокчейна.

Подведем итоги процесса. В этом разделе мы имеем:

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

Блок SIgning

Хотя на первый взгляд процесс кажется сложным, последовательность подписания блоков в Elements всегда одинакова, и первоначальную настройку нужно выполнить только один раз:

  1. Первоначальная настройка (выполняется один раз)

  2. Создается адрес с несколькими подписями под названием `signblockscript, использующий открытые ключи подписчиков федеративных блоков.

  3. Полученный скрипт redeem используется для запуска нового блокчейна.

  4. Производство блоков (продолжается)

  5. Предлагаемые блоки генерируются и передаются для подписания.

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

Элемент как боковая цепь

Elements - это блокчейн-платформа общего назначения с открытым исходным кодом, которая также может быть "привязана" к существующему блокчейну, например Bitcoin. Когда Elements привязывается к другому блокчейну, говорят, что он работает как сайдчейн. Сайдчейн позволяет осуществлять двустороннюю передачу активов из одной цепи в другую. Реализация Elements в качестве сайдчейна позволяет обойти некоторые ограничения, присущие мейнчейну, сохраняя при этом значительную степень безопасности, обеспечиваемую активами, защищенными на мейнчейне.

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

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

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

Федеративный скрипт привязки определяет, какие члены сильной федерации могут выполнять функции привязки и отмены привязки. Этих функционеров называют наблюдателями, поскольку они следят за тем, чтобы в основной и побочной цепях были зафиксированы действительные транзакции по вводу и выводу привязки, и выполняют их, если они действительны. Выйти из сети означает переместить привязанные активы из сайдчейна в мейнчейн, а войти в сеть означает переместить привязанные активы в сайдчейн из мейнчейна. Когда мы говорим переместить в сайдчейн, на самом деле мы имеем в виду, что средства фиксируются в адресе с несколькими подписями на мейнчейне, а соответствующее количество актива создается на сайдчейне Elements. Когда мы говорим "выйти из сайдчейна", мы имеем в виду, что активы уничтожаются на сайдчейне Elements, а соответствующая сумма высвобождается из заблокированных средств, хранящихся на мейнчейне. Разрешение на выполнение функций peg-in и peg-out требует, чтобы функционеры подтвердили право собственности на открытые ключи, используемые в федеральном скрипте peg. Это делается с помощью соответствующих закрытых ключей.

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

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

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

e1-cli getnewaddress
e2-cli getnewaddress

Затем мы проверяем адрес, чтобы получить открытые ключи.

e1-cli getaddressinfo <e1-address>
e2-cli getaddressinfo <e2-address>

А затем получите закрытые ключи, связанные с каждым адресом.

e1-cli dumpprivkey <e1-address>
e2-cli dumpprivkey <e2-address>

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

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

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

e1-dae -fedpegscript=5221<e1-pubkey>21<e2-pubkey>52ae
e2-dae -fedpegscript=5221<e1-pubkey>21<e2-pubkey>52ae

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

e1-cli importprivkey <priv-key-1>
e2-cli importprivkey <priv-key-1>

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

Чтобы этот раздел был посвящен федеративной привязке, мы будем генерировать блоки без использования модели подписи блоков, которую мы рассматривали в предыдущем разделе, и вернемся к использованию команды 'generate' для создания новых блоков.

b-cli generate 101
e1-cli generate 1

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

Теперь наша цепочка готова к подключению. Для peg-in нам нужно сгенерировать специальный тип адреса с помощью команды getpeginaddress. Обратите внимание, что время между генерацией адреса peg-in с помощью getpeginaddress и его утверждением с помощью claimpegin должно быть как можно меньше. Адреса peg-in не являются долговременными и не должны использоваться повторно.

e1-cli getpeginaddress

Вы можете видеть, что команда создает новый адрес mainchain, а также новый скрипт, который нужно будет удовлетворить, чтобы получить средства за привязку. Адрес mainchain - это адрес pay to script hash, который будет использоваться функционерами, выполняющими роль Watchmen в сети Elements.

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

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

b-cli getwalletinfo

Мы видим, что в кошельке хранится 50 биткоинов. Мы отправим один биткоин с mainchain на sidechain. Нам нужно отправить средства на адрес mainchain, сгенерированный нашей нодой ранее.

b-cli sendtoaddress <e1-pegin-address>

Мы должны сохранить идентификатор этой транзакции, так как он понадобится нам для подтверждения финансирования в дальнейшем.

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

b-cli getwalletinfo

Нам нужно повторить транзакцию.

b-cli generate 101

Для того чтобы узел Elements мог претендовать на средства peg-in, нам нужно получить доказательство того, что транзакция peg-in была совершена. Криптографическое доказательство использует идентификатор транзакции финансирования для расчета пути Меркеля и доказывает, что транзакция присутствует в подтвержденном блоке.

b-cli gettxoutproof '["<tx-id>"]'

Нам также нужны необработанные данные о транзакциях.

b-cli getrawtransaction <tx-id>

Имея доказательство и исходные данные для транзакции peg-in, наш узел элементов теперь может заявить о peg-in, используя исходную транзакцию и доказательство транзакции.

e1-cli claimpegin <raw> <proof>

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

Проверка баланса e1.

e1-cli getwalletinfo

Генерирование блока для подтверждения утверждения.

e1-cli generate 1

Проверка баланса e1.

e1-cli getwalletinfo

Мы видим, что привязка была успешно заявлена.

При выводе средств на карту процесс аналогичен. Генерируется адрес, на него отправляются средства, и они освобождаются, если транзакция действительна. Мы не будем рассматривать весь процесс peg-out, так как он включает в себя работу с мейнчейном, что выходит за рамки данного курса. Шаги с точки зрения событий Elements состоят в том, что на мейнчейне генерируется адрес.

b-cli getnewaddress

Средства отправляются на адрес mainchain с узла Elements с помощью команды sendtomainchain.

e1-cli sendtomainchain <new-address> 1

Генерирование блока для подтверждения транзакции.

e1-cli generate 1

Проверьте баланс кошелька узла.

e1-cli getwalletinfo

И увидите, что баланс уменьшился.

В этом разделе мы рассмотрели, как:

FederatedPegScript

Для того чтобы Elements мог работать как сайдчейн, блок genesis в его блокчейне должен быть создан с fedpegscript. Это делается путем передачи параметра fedpegscript при запуске узла. Этот скрипт станет частью правил консенсуса блокчейна Elements и позволит проверять и выполнять запросы на привязку и отвязку.

Федпегскрипт состоит из открытых ключей, контролируемых теми, кто уполномочен выполнять действия с привязкой. Ниже показан пример формата федпегскрипта с 2 из 2 мультиподписей:

fedpegscript=5221<public key 1>21<public key 2>52ae

Примечание: Символы за пределами открытых ключей являются разделителями, которые указывают на требования к открытому ключу и n из m. Например, шаблон для 1-оф-1 fedpegscript будет иметь вид '5121<pub key 1>51ae'.

Прищепка

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

Кратковременные реорганизации верхушки блокчейна Биткойна ожидаются как часть нормальной работы механизма консенсуса Proof of Work (PoW). В связи с этим Elements признает привязку действительной только в том случае, если она имеет достаточную глубину в блокчейне Биткойна. Это позволяет Elements не принимать один и тот же peg-in более одного раза.

Прищепка

Вывод привязки происходит, когда узел Elements вызывает команду endtomainchain, которая принимает на вход адрес mainchain (место назначения привязки), а также сумму привязанного актива, которую нужно вывести. Таким образом, создается транзакция вывода привязки на сайдчейн. Как только функционеры, выполняющие роль наблюдателей, обнаружат, что транзакция peg-out была подтверждена на сайдчейне, они займутся фактическим освобождением актива на мейнчейне в пункт назначения peg-out, как мы уже изучали в предыдущих разделах курса.

Элементы как отдельный блокчейн

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

В этом разделе мы рассмотрим:

Инициализируйте новый блокчейн Elements с активом по умолчанию под названием newasset.

Укажите 1 000 000 новых активов, которые будут созданы, а также 2 токена перевыпуска для них.

Заберите все монеты newasset, которые может потратить каждый.

Затребуйте все жетоны перевыпуска для 'newasset'.

Отправьте актив и его токен перевыпуска на кошелек другого узла.

Перевыпустите больше "новых активов" с обоих узлов.

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

Теперь мы начнем новую цепочку с этими параметрами на наших двух соединенных узлах Elements. Мы назовем актив по умолчанию newasset и выпустим один миллион таких активов и два токена перевыпуска newasset.

e1-dae -validatepegin=0 -defaultpeggedassetname=newasset -initialfreecoins=100000000000000 -initialreissuancetokens=200000000
e2-dae -validatepegin=0 -defaultpeggedassetname=newasset -initialfreecoins=100000000000000 -initialreissuancetokens=200000000

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

Проверьте текущий баланс кошелька нашего узла.

e1-cli getwalletinfo
e2-cli getwalletinfo

Мы видим, что инициализация прошла правильно.

Поскольку первоначальная эмиссия активов создается как "каждый может потратить", мы попросим e1 потребовать их все, чтобы удалить доступ e2 к ним.

e1-cli getnewaddress
e1-cli sendtoaddress <e1-address> 1000000 "" "" true

Обратите внимание, что нам не нужно указывать 'newasset' в качестве актива для отправки, так как он уже является активом по умолчанию. и, следовательно, также активом по умолчанию, используемым для оплаты сетевых сборов.

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

e1-cli sendtoaddress <e1-address> 1 "" "" false false 1 UNSET false <reissuance-token-id>

Подтвердите транзакции.

e1-cli generate 101

Мы проверим, что e1 является единственным владельцем актива и токена его перевыпуска.

e1-cli getwalletinfo
e2-cli getwalletinfo

Что, как мы видим, действительно так и есть.

Теперь мы отправим часть "нового актива" в e2, баланс которого в настоящее время равен нулю.

e2-cli getnewaddress
e1-cli sendtoaddress <e2-address> 500 "" "" false

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

Давайте также отправим часть токенов перевыпуска для newasset в e2.

e1-cli sendtoaddress <e2-address> 1 "" "" false false 1 UNSET false <reissuance-token-id>

Подтвердите транзакции.

e1-cli generate 101

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

e1-cli getwalletinfo
e2-cli getwalletinfo

Теперь мы перевыпустим некоторые активы по умолчанию из e1. Обратите внимание, что возможность сделать это обеспечивается параметром запуска initialreissuancetokens. Если его опустить или установить нулевое значение, это приведет к тому, что активы по умолчанию нельзя будет перевыпустить позже.

e1-cli reissueasset newasset 100

Мы смогли использовать метку newasset вместо того, чтобы указывать значение hex id, потому что цепочка Elements всегда маркирует свой актив по умолчанию.

Проверка того, что перевыпуск актива по умолчанию сработал:

e1-cli generate 101
e1-cli getwalletinfo

Теперь мы докажем, что поскольку e2 владеет некоторыми токенами перевыпуска newasset, он также может перевыпустить актив по умолчанию.

e2-cli reissueasset newasset 100

Проверка того, что перевыпуск актива по умолчанию компанией e2 сработал.

e2-cli generate 101
e2-cli getwalletinfo

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

Мы использовали параметры запуска, чтобы:

Инициализируйте новый блокчейн Elements с активом по умолчанию под названием 'newasset'.

Укажите количество актива по умолчанию, создаваемого при инициализации цепочки.

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

В нашей автономной блокчейн-сети Elements все остальные транзакционные операции будут осуществляться так же, как и в примерах, рассмотренных в основных разделах курса, но в качестве актива по умолчанию и платного актива будет использоваться "newasset" вместо bitcoin.

Параметры запуска узла и инициализации цепочки

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

validatepegin=0

Поскольку автономный блокчейн не нуждается в подтверждении транзакций peg-in или peg-out, нам нужно отключить эти проверки. При такой настройке вам не нужно запускать клиентское программное обеспечение Bitcoin или хранить копию блокчейна Bitcoin, поскольку сеть Elements будет работать независимо.

defaultpeggedassetname

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

initialfreecoins

Количество (в эквиваленте единицы Биткойна - сатоши) создаваемого по умолчанию актива.

первоначальная выдача токенов

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

Используя эти параметры, общий процесс запуска узла будет выглядеть примерно так:

e1-dae -validatepegin=0 -defaultpeggedassetname=newasset -initialfreecoins=100000000000000 -initialreissuancetokens=200000000

Основные операции

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

Поэтому отправить 10 новых активов по умолчанию на адрес очень просто:

e1-cli sendtoaddress <destination address> 10 "" "" true

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

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

e1-cli reissueasset <default asset name> <amount>

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

Заключение

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

Мы видели, что исходный код и веб-сайт Elements (https://github.com/ElementsProject/elements) размещены на GitHub и что существуют дискуссионные форумы сообщества, такие как Build On L2 (https://community.liquid.net/c/developers/) или Liquid Developers Telegram (https://t.me/liquid_devel), которые можно использовать для получения дополнительной информации о развертывании и разработке приложений на Elements и Liquid. Были рассмотрены такие ключевые функции, как конфиденциальные транзакции и эмиссионные активы, а также то, как члены сильной федерации обеспечивают федеративную подпись блоков и механизм 2-сторонней привязки.

Следующим шагом будет тест, охватывающий все предыдущие разделы, после чего вы начнете свое путешествие по Элементам... удачи!

Заключительный раздел

Отзывы и рейтинги

true

Заключение

15f62056-c69c-467e-9565-af48d439a1f5 true