alex-ru
Well-known member
ПЕРЕВОД
Оригинал: https://blog.dash.org/introducing-deterministic-masternode-lists-daaa7c9bef34
Мы рады сообщить, что мы наконец готовы выпустить в свет следующую большую часть Предложений по Улучшению Dash (DIP), а именно DIP2, DIP3 и DIP4. Все они закладывают основу для тех вещей, которые мы бы хотели реализовать и внедрить после релиза 12.3: списки детерминированных Мастернод.
Ссылки на DIP-ы:
DIP2 - специальные транзакции
DIP3 - списки детерминированных Мастернод
DIP4 - Упрощенная верификация списка детерминированных Мастернод
Что такое списки детерминированных Мастернод?
Списки детерминированных Мастернод - это списки Мастернод, которые полностью взяты из данных блокчейна. DIP2 и DIP3 вводят новые системы транзакций и специфические их типы, что позволит сети регистрировать и обновлять Мастерноды on-chain. Все прочие ноды получат свои списки Мастернод от этих транзакций по цепи, и все ноды придут к консенсусу относительно валидного на данный момент списка Мастернод.
Внедрение списков детерминированных Мастернод также некоторым образом повлияет на владельцев Мастернод и операторов, и об этом мы поговорим ниже.
Это связано с Dash Evolution?
И да, и нет. Существует множество причин для перехода на списки детерминированных Мастернод, и часть из них никак не связана с Evolution. В разделе “Мотивация” в DIP3 приведены несколько примеров, почему эти действия улучшают сеть, независимо от обещанных функций и возможностей Evolution. В то же время, все обещанные функции и возможности зависят от консенсуса (то есть, полностью on-chain) по списку Мастернод. Таким образом, списки детерминированных Мастернод не зависят от Evolution, но Evolution сильно зависит от них.
Краткое описание нынешней системы
На данный момент, владелец Мастерноды должен иметь как минимум 1000 Dash и настроить свой локальный кошелёк (в “masternode.conf”), чтобы тот ссылался на IP серверной части Мастерноды, UTXO транзакции с “залогом” и приватный ключ его Мастерноды. В то же время, серверная часть Мастерноды также должна быть настроена на работу с приватным ключом Мастерноды (в “masternodeprivkey”).
После этого владелец запускает команду “masternode start-xxx”, чтобы заявить о себе сети и запустить свою Мастерноду. Каждый раз, когда Мастернода долгое время не работает, или когда нужно обновление, владельцу нужно запускать команду “masternode start-xxx” в своём локальном кошельке заново.
С точки зрения сети, в такой последовательности действий есть некоторые проблемы, которые мы описываем в разделе “Мотивация” в DIP3. Также тут есть проблемы с точки зрения владельцев Мастернод и операторов, о которых мы поговорим ниже.
Проблемы с точки зрения владельцев Мастернод
В нынешней системе, единственные оперативные роли Мастерноды, которые сейчас идентифицируются - владелец залога и оператор Мастерноды. Владелец залога в 1000 Dash может держать приватные ключи от этого залога у себя в локальном кошельке и обязан делиться ключом от Мастерноды только с оператором серверной части Мастерноды. В связи с этим может возникнуть несколько проблем.
Во-первых, команда “masternode start-xxx” может быть запущена только в том случае, если вы владеете приватным ключом от залоговых 1000 DASH, и это означает, что сам оператор не может запустить или перезапустить Мастерноду самостоятельно. Особенно остро эта проблема встаёт, когда нужно обновить версию ПО Мастерноды, поскольку в таком случае оператору приходится полагаться лишь на то, что владелец Мастерноды сделает это вовремя. В качестве возможного решения этой проблемы владелец мог бы перечислить свой залог в 1000 Dash оператору, но этот вариант потребует огромного доверия к оператору.
Во-вторых, приватный ключ Мастерноды, которым которым делится владелец, используется одновременно и для решения оперативных сервисных задач, и для голосования по бюджетным предложениям Dash. Из этого следует, что если владелец Мастерноды решит пользоваться услугами сервиса по хостингу Мастернод, ему также придётся доверять этому провайдеру в том, что тот не будет использовать его ключ для голосования от его имени.
В-третьих, вознаграждения Мастерноды могут выплачиваться только по тому же адресу, который используется для хранения самого залога в 1000 DASH. В то же время, залоговый адрес может быть только P2PKN адресом, что ограничивает возможности для владельцев и операторов.
Новая Система детерминированных Мастернод
В новой системе Мастернода создаётся через специальную транзакцию (ProRegTx) сети. Эта транзакция содержит необходимые метаданные (IP, публичные ключи, адрес для вознаграждения, и т.д.), и также переводит залоговые 1000 Dash на новый адрес. После завершения этого перевода, эта Мастернода добавляется к списку Мастернод и сразу же включается в работу (то есть, команда “masternode start-xxx” не нужна). Другие специальные транзакции (ProUpRegTx, ProUpServTx) могут быть использованы, чтобы обновить метаданные Мастерноды.
Новые роли
В новой системе мы определяем и выделяем три разные роли. Каждая из них имеет свои собственные приватные ключи и может с их помощью совершить определённый набор действий и обновлений данных Мастерноды. Вот эти три роли:
Залоги и вознаграждения
Регистрационная транзакция будет также и залоговой, что означает, что один из его выходов будет содержать 1000 Dash. Если этот выход будет впоследствии потрачен (залог перемещён), Мастернода будет исключена из списка Мастернод. Новая система работает только с залоговыми адресами формата P2PKH (pay-to-public-key-hash) или P2SH (pay-to-script-hash).
Ограничение, по которому вознаграждение Мастерноды могло быть выплачено только на залоговый адрес, было снято путём добавления в данные регистрационной транзакции адреса для выплаты вознаграждения. Адрес для вознаграждения в новой системе также может быть в P2SH-формате.
Владелец также может обозначить процент от вознаграждения Мастерноды, который он хочет передать оператору Мастерноды за его услуги. Это значение может быть установлено только один раз при регистрации Мастерноды, и поэтому нужно обсудить его заранее. Чтобы оператор получал своё вознаграждение автоматически, при обновлении оперативной информации Мастерноды оператору нужно будет указать свой актуальный адрес для получения вознаграждения.
Обновление IP Мастерноды
IP рассматривается в качестве оперативной сервисной информации. Только оператор Мастерноды может изменить его и он может это сделать без одобрения или помощи со стороны владельца Мастерноды.
Изначально IP устанавливается при регистрационной транзакции, однако он может и не указываться при регистрации Мастерноды. Если он не был указан, необходимо обновление данных от оператора, чтобы полностью запустить Мастерноду. Этот шаг должен сократить общение между владельцем и оператором, а также снизить количество ошибок, которые может совершить владелец Мастерноды.
SPV клиенты и Мастерноды
В текущей (то есть, старой) системе, SPV-клиенты не имеют возможности верифицировать список Мастернод. Причина состоит в том, что для этого им потребуется верифицировать залоговый UTXO каждой Мастерноды, и это может быть сделано только при наличии полного блокчейна. Кроме того, сетевой трафик, который требуется для постоянной актуализации списка Мастернод, не очень-то подходит для SPV клиентов мобильных устройств.
С обновлением DIP4, мы внедряем подходящий SPV клиентам способ для получения и подтверждения полного списка Мастернод. Главным образом это сделано за счёт выделения нового хэш-дерева транзакции, которая затем будет использоваться SPV-клиентом для верификации списка Мастернод.
Эти изменения положительным образом повлияют на экосистему Dash. Они дадут возможность SPV клиентам (включая мобильные клиенты) пользоваться продвинутыми функциями Dash, например, PrivateSend и получать/верифицировать InstantSend (при этом для самого отправления InstantSend список Мастернод не нужен). Они также закладывают фундамент для будущих функций Evolution, связанных с SPV клиентами.
PoSe (Доказательство оказания услуги) блокируемых Мастернод
DIP3 внедряет концепцию “блокируемых согласно PoSe” Мастернод. Существуют Мастерноды, которые не смогли пройти PoSe-верификацию, и поэтому они будут удаляться из действующей подгруппы Мастернод. DIP-ы для PoSe-верификации ещё не полностью доработаны, и мы планируем опубликовать их отдельно.
Интерфейс новой системы
Новой системе потребуется набор новых RPC-команд, чтобы создавать и обновлять детерминированные Мастерноды. Мы опишем новый интерфейс в отдельном посте, и позже обновим необходимую документацию.
Кроме того, мы переместим все манипуляции с ключами, которые имеют отношения к Мастерноде, в сам кошелёк. Это означает, что больше не нужно будет вручную редактировать или обновлять файл “masternode.conf”.
Специальные транзакции
DIP2 внедряет новую версию транзакций. Новая версия разрешает добавление чётко обозначенной нагрузки к транзакциям, и закладывает основу для других DIP-ов, упомянутых в этом посте. Она также станет основной для многих других функций, которые сейчас находятся в стадии разработки.
Статус DIP-ов
Подразумевается, что DIP-ы являются предложениями, и потому открыты для обсуждения. Мы просим сообщество и участников Dash Core рассмотреть и прокомментировать их. Если DIP-ы нуждаются в каких-то изменениях, мы их внедрим.
Кроме того, существуют другие DIP-ы на различных этапах исследований, дизайна и разработки, для работы которых могут потребоваться изменения в уже опубликованных DIP-ах. Пока что неизвестно, каким образом будущие DIPы повлияют на уже опубликованные DIPы.
Внедрение
Запуск системы детерминированных Мастернод уже начался. Разработчики Dash Core дошли до того момента, когда DIP2, DIP3 и DIP4 были внедрены и протестированы. Эти функции уже стабильно работают в одной из наших тестовых сетей Dash для разработчиков. Скоро будут созданы/выпущены соответствующие заявки для изменения кода.
Развёртывание
Внедрение системы детерминированных Мастернод требует многоступенчатого развёртывания и изменений во многих частях экосистемы Dash. Мы разработали план развёртывания, который многократно протестировали (благодаря testnet сети для разработчиков). Пост с детально расписанным планом развёртывания новой системы мы выпустим отдельно.
Оригинал: https://blog.dash.org/introducing-deterministic-masternode-lists-daaa7c9bef34
Мы рады сообщить, что мы наконец готовы выпустить в свет следующую большую часть Предложений по Улучшению Dash (DIP), а именно DIP2, DIP3 и DIP4. Все они закладывают основу для тех вещей, которые мы бы хотели реализовать и внедрить после релиза 12.3: списки детерминированных Мастернод.
Ссылки на DIP-ы:
DIP2 - специальные транзакции
DIP3 - списки детерминированных Мастернод
DIP4 - Упрощенная верификация списка детерминированных Мастернод
Что такое списки детерминированных Мастернод?
Списки детерминированных Мастернод - это списки Мастернод, которые полностью взяты из данных блокчейна. DIP2 и DIP3 вводят новые системы транзакций и специфические их типы, что позволит сети регистрировать и обновлять Мастерноды on-chain. Все прочие ноды получат свои списки Мастернод от этих транзакций по цепи, и все ноды придут к консенсусу относительно валидного на данный момент списка Мастернод.
Внедрение списков детерминированных Мастернод также некоторым образом повлияет на владельцев Мастернод и операторов, и об этом мы поговорим ниже.
Это связано с Dash Evolution?
И да, и нет. Существует множество причин для перехода на списки детерминированных Мастернод, и часть из них никак не связана с Evolution. В разделе “Мотивация” в DIP3 приведены несколько примеров, почему эти действия улучшают сеть, независимо от обещанных функций и возможностей Evolution. В то же время, все обещанные функции и возможности зависят от консенсуса (то есть, полностью on-chain) по списку Мастернод. Таким образом, списки детерминированных Мастернод не зависят от Evolution, но Evolution сильно зависит от них.
Краткое описание нынешней системы
На данный момент, владелец Мастерноды должен иметь как минимум 1000 Dash и настроить свой локальный кошелёк (в “masternode.conf”), чтобы тот ссылался на IP серверной части Мастерноды, UTXO транзакции с “залогом” и приватный ключ его Мастерноды. В то же время, серверная часть Мастерноды также должна быть настроена на работу с приватным ключом Мастерноды (в “masternodeprivkey”).
После этого владелец запускает команду “masternode start-xxx”, чтобы заявить о себе сети и запустить свою Мастерноду. Каждый раз, когда Мастернода долгое время не работает, или когда нужно обновление, владельцу нужно запускать команду “masternode start-xxx” в своём локальном кошельке заново.
С точки зрения сети, в такой последовательности действий есть некоторые проблемы, которые мы описываем в разделе “Мотивация” в DIP3. Также тут есть проблемы с точки зрения владельцев Мастернод и операторов, о которых мы поговорим ниже.
Проблемы с точки зрения владельцев Мастернод
В нынешней системе, единственные оперативные роли Мастерноды, которые сейчас идентифицируются - владелец залога и оператор Мастерноды. Владелец залога в 1000 Dash может держать приватные ключи от этого залога у себя в локальном кошельке и обязан делиться ключом от Мастерноды только с оператором серверной части Мастерноды. В связи с этим может возникнуть несколько проблем.
Во-первых, команда “masternode start-xxx” может быть запущена только в том случае, если вы владеете приватным ключом от залоговых 1000 DASH, и это означает, что сам оператор не может запустить или перезапустить Мастерноду самостоятельно. Особенно остро эта проблема встаёт, когда нужно обновить версию ПО Мастерноды, поскольку в таком случае оператору приходится полагаться лишь на то, что владелец Мастерноды сделает это вовремя. В качестве возможного решения этой проблемы владелец мог бы перечислить свой залог в 1000 Dash оператору, но этот вариант потребует огромного доверия к оператору.
Во-вторых, приватный ключ Мастерноды, которым которым делится владелец, используется одновременно и для решения оперативных сервисных задач, и для голосования по бюджетным предложениям Dash. Из этого следует, что если владелец Мастерноды решит пользоваться услугами сервиса по хостингу Мастернод, ему также придётся доверять этому провайдеру в том, что тот не будет использовать его ключ для голосования от его имени.
В-третьих, вознаграждения Мастерноды могут выплачиваться только по тому же адресу, который используется для хранения самого залога в 1000 DASH. В то же время, залоговый адрес может быть только P2PKN адресом, что ограничивает возможности для владельцев и операторов.
Новая Система детерминированных Мастернод
В новой системе Мастернода создаётся через специальную транзакцию (ProRegTx) сети. Эта транзакция содержит необходимые метаданные (IP, публичные ключи, адрес для вознаграждения, и т.д.), и также переводит залоговые 1000 Dash на новый адрес. После завершения этого перевода, эта Мастернода добавляется к списку Мастернод и сразу же включается в работу (то есть, команда “masternode start-xxx” не нужна). Другие специальные транзакции (ProUpRegTx, ProUpServTx) могут быть использованы, чтобы обновить метаданные Мастерноды.
Новые роли
В новой системе мы определяем и выделяем три разные роли. Каждая из них имеет свои собственные приватные ключи и может с их помощью совершить определённый набор действий и обновлений данных Мастерноды. Вот эти три роли:
- Владелец. Это владелец залога в 1000 Dash. Владелец может изменять адрес для выплаты вознаграждений, а также делегировать право оператора и право голосования другим людям.
- Оператор. Это оператор серверной части Мастерноды. Оператор может изменять только IP и адрес для выплаты вознаграждения хостинг-оператора.
- Избиратель. Это тот, который может голосовать от имени этой Мастерноды. Он не может изменять метаданные Мастерноды.
Залоги и вознаграждения
Регистрационная транзакция будет также и залоговой, что означает, что один из его выходов будет содержать 1000 Dash. Если этот выход будет впоследствии потрачен (залог перемещён), Мастернода будет исключена из списка Мастернод. Новая система работает только с залоговыми адресами формата P2PKH (pay-to-public-key-hash) или P2SH (pay-to-script-hash).
Ограничение, по которому вознаграждение Мастерноды могло быть выплачено только на залоговый адрес, было снято путём добавления в данные регистрационной транзакции адреса для выплаты вознаграждения. Адрес для вознаграждения в новой системе также может быть в P2SH-формате.
Владелец также может обозначить процент от вознаграждения Мастерноды, который он хочет передать оператору Мастерноды за его услуги. Это значение может быть установлено только один раз при регистрации Мастерноды, и поэтому нужно обсудить его заранее. Чтобы оператор получал своё вознаграждение автоматически, при обновлении оперативной информации Мастерноды оператору нужно будет указать свой актуальный адрес для получения вознаграждения.
Обновление IP Мастерноды
IP рассматривается в качестве оперативной сервисной информации. Только оператор Мастерноды может изменить его и он может это сделать без одобрения или помощи со стороны владельца Мастерноды.
Изначально IP устанавливается при регистрационной транзакции, однако он может и не указываться при регистрации Мастерноды. Если он не был указан, необходимо обновление данных от оператора, чтобы полностью запустить Мастерноду. Этот шаг должен сократить общение между владельцем и оператором, а также снизить количество ошибок, которые может совершить владелец Мастерноды.
SPV клиенты и Мастерноды
В текущей (то есть, старой) системе, SPV-клиенты не имеют возможности верифицировать список Мастернод. Причина состоит в том, что для этого им потребуется верифицировать залоговый UTXO каждой Мастерноды, и это может быть сделано только при наличии полного блокчейна. Кроме того, сетевой трафик, который требуется для постоянной актуализации списка Мастернод, не очень-то подходит для SPV клиентов мобильных устройств.
С обновлением DIP4, мы внедряем подходящий SPV клиентам способ для получения и подтверждения полного списка Мастернод. Главным образом это сделано за счёт выделения нового хэш-дерева транзакции, которая затем будет использоваться SPV-клиентом для верификации списка Мастернод.
Эти изменения положительным образом повлияют на экосистему Dash. Они дадут возможность SPV клиентам (включая мобильные клиенты) пользоваться продвинутыми функциями Dash, например, PrivateSend и получать/верифицировать InstantSend (при этом для самого отправления InstantSend список Мастернод не нужен). Они также закладывают фундамент для будущих функций Evolution, связанных с SPV клиентами.
PoSe (Доказательство оказания услуги) блокируемых Мастернод
DIP3 внедряет концепцию “блокируемых согласно PoSe” Мастернод. Существуют Мастерноды, которые не смогли пройти PoSe-верификацию, и поэтому они будут удаляться из действующей подгруппы Мастернод. DIP-ы для PoSe-верификации ещё не полностью доработаны, и мы планируем опубликовать их отдельно.
Интерфейс новой системы
Новой системе потребуется набор новых RPC-команд, чтобы создавать и обновлять детерминированные Мастерноды. Мы опишем новый интерфейс в отдельном посте, и позже обновим необходимую документацию.
Кроме того, мы переместим все манипуляции с ключами, которые имеют отношения к Мастерноде, в сам кошелёк. Это означает, что больше не нужно будет вручную редактировать или обновлять файл “masternode.conf”.
Специальные транзакции
DIP2 внедряет новую версию транзакций. Новая версия разрешает добавление чётко обозначенной нагрузки к транзакциям, и закладывает основу для других DIP-ов, упомянутых в этом посте. Она также станет основной для многих других функций, которые сейчас находятся в стадии разработки.
Статус DIP-ов
Подразумевается, что DIP-ы являются предложениями, и потому открыты для обсуждения. Мы просим сообщество и участников Dash Core рассмотреть и прокомментировать их. Если DIP-ы нуждаются в каких-то изменениях, мы их внедрим.
Кроме того, существуют другие DIP-ы на различных этапах исследований, дизайна и разработки, для работы которых могут потребоваться изменения в уже опубликованных DIP-ах. Пока что неизвестно, каким образом будущие DIPы повлияют на уже опубликованные DIPы.
Внедрение
Запуск системы детерминированных Мастернод уже начался. Разработчики Dash Core дошли до того момента, когда DIP2, DIP3 и DIP4 были внедрены и протестированы. Эти функции уже стабильно работают в одной из наших тестовых сетей Dash для разработчиков. Скоро будут созданы/выпущены соответствующие заявки для изменения кода.
Развёртывание
Внедрение системы детерминированных Мастернод требует многоступенчатого развёртывания и изменений во многих частях экосистемы Dash. Мы разработали план развёртывания, который многократно протестировали (благодаря testnet сети для разработчиков). Пост с детально расписанным планом развёртывания новой системы мы выпустим отдельно.
