alex-ru
Well-known member
Мы рады представить сообществу новую идею, которая сейчас находится в разработке: долгосрочные кворумы мастернод (Long Living Masternode Quorums) или просто LLMQs. Эта идея некоторым образом повлияет на имеющие и не имеющие отношения к Evolution темы и функции, что через некоторое время вы и сами сможете увидеть. Позже запланировано опубликовать об этом дополнительные посты в блог, которые раскроют больше подробностей и сильнее углубятся в детали.
Ссылки на DIP-ы и сопутствующие документы
DIP6 - Долгосрочные Кворумы Мастернод
DIP7 - LLMQ Запросы на подпись / Сессии
Схема подписи BLS
BLS Пороговая схема M-из-N и Распределённая генерация ключей
Что такое долгосрочные кворумы мастернод?
В предыдущем посте я уже описывал систему кворумов, которую мы сейчас используем для InstantSend. В том посте также описываются проблемы и ограничения старой системы и есть ответ на вопрос, почему мы не можем применить её для новых вариантов использования. LLMQs дают нам решение описанных проблем, и будут использоваться как часть платформы Evolution.
Они долгосрочные (как можно догадаться из названия) и возможно очень большие, а также имеют повышенный уровень безопасности. В то же время, они повышают потребление необходимых ресурсов (CPU, RAM, сеть) только у участников подобных кворумов, не повышая при этом нагрузку на всю сеть.
“Долгосрочные” означает, что вместо того, чтобы каждый раз при необходимости создавать свежий кворум, мы создаём кворумы заранее, до того, как они нам фактически потребуются, и затем повторно используем их в течение определённого периода. Суть в том, что LLMQ выполняет сессии с необходимым уровнем согласия M-из-N чтобы собрать большинство голосов, когда нужно принять решение. Новая схема M-из-N требует выполнения недоверительного и распределённого протокола генерации ключей (DGK) перед тем, как непосредственно произойдёт подписание или голосование. Поскольку этот DGK протокол довольно требователен к ресурсам, мы делаем это заранее, а затем повторно используем эти ключи для подписи и других сессий, требующих консенсуса.
Почему и каким образом LLMQs решают проблему ограничений?
Как уже говорилось в прошлом посте о кворумах, старая система требует растпространения каждого индивидуального голоса каждого участника кворума. Распространение голоса по сети означает, что голоса пересылаются всем нодам сети, которые должны подтвердить их и затем хранить. Такой подход не очень хорошо масштабируется и может также вызвать множество проблем с консенсусом.
Напротив, LLMQs требуют от участников кворума только то, чтобы они произвели распространение и подтверждение их индивидуальных голосов (подпись доли) только внутри их кворума. В конечном итоге финальная общая подпись создаётся и распространяется среди остальной части сети только тогда, когда консенсус достигнут внутри рассматриваемого кворума. Поскольку итоговый результат это результат основанной на BLS сессии с пороговой подписью M-из-N, он представляет собой всего лишь одну итоговую BLS подпись. Распространение лишь одной подписи в сети требует намного меньше ресурсов CPU, RAM и пропускной способности сети.
Поскольку участники только одной LLMQs берут на себя нагрузку по достижению консенсуса, и множество LLMQs одновременно работают параллельно, в одно и то же время, общая нагрузка на всю сеть остаётся хорошо распределённой.
Прочие преимущества
Благодаря использованию BLS, мы также получаем несколько дополнительных преимуществ. Все BLS подписи детерминированы и уникальны, что означает, что для каждой комбинации сообщения и ключей существует только одна верная подпись. Это также верно и для пороговых подписей M-из-N, которые в конечном итоге являются обычными BLS подписями. Следовательно, результат сессии подписания LLMQ также является детерминированным и уникальным.
Когда дело касается хранения кворумных решений ончейн, эти качества становятся очень важны. Без них, проблемы с нестабильностью проявятся также и в не относящиеся к транзакциям функции, например, в аккаунтах пользователей на блокчейне или применительно к переходам статусов. Устраняя эту нестабильность, Dash Evolution может задействовать такие функции, безопасное внедрение которых до этого представлялось почти невозможным.
LLMQ кворумы и подтверждение сессий подписания
LLMQs созданы с помощью протокола распределённой генерации ключей (DKG). Работа этого протокола (консенсуса на основе кворумов) привязывается к майнингу блокчейна перед активацией и непосредственным использованием LLMQ. Это означает, что достигается чёткий консенсус относительно того, какие LLMQs будут задействованы и какие именно мастерноды принадлежат к каждому LLMQ. Это также означает, что, в отличии от старой кворумной системы, сессия подписания внутри каждого кворума может быть подтверждена навсегда. Это очень важно, когда кворумные решения переносятся майнерами в блокчейн или когда SPV кошелькам (или в будущем DAPI) понадобится подтвердить кворумные подписи.
Размер LLMQ кворумов
Мы будем поддерживать разные типы LLMQs, которые (что важно) будут различаться по размеру и продолжительности. Мы ещё не решили, какие размеры кворумов нужно будет использовать, но мы можем поддерживать большие LLMQs размером в несколько сотен (например, 400) участников и также небольшие с 10 участниками. Всё это зависит от конкретных вариантов использования кворумов и соответствующих требований.
Реализация LLMQs в качестве платформы
Практическая реализация LLMQ кворумов в Dash уже нами сделана, и она уже довольно продвинутая (это не просто проверка концепции). Она разрабатывается, чтобы стать платформой, или базовым уровнем, для дальнейших вариантов использования, которым потребуются механизмы LLMQs. Изначально, внедрение новых вариантов использования должно просто вызывать несколько функций в платформе LLMQ. Это функции вроде “подписать это сообщение”, “есть ли у нас большинство?”, “есть ли конфликт?”. Таким образом, внедрять новые варианты использования должно быть очень просто, поскольку им не нужно будет взаимодействовать с внутренними настройками LLMQs, DKG, подписных сессий и так далее.
Необходимые изменения в DIP3
Чтобы поддерживать LLMQs, необходимо внести небольшие изменения в DIP3. Процесс DKG требует, чтобы публичные ключи BLS были распознаны и подтверждены до того, как начнётся сессия DKG. Это означает, что нам придётся использовать публичный ключ BLS вместо публичного ключа ECDSA для ключа оператора мастерноды. DIP3 будут обновлены тогда, когда мы примем окончательное решение, какой вариант BLS использовать.
Варианты использования LLMQs
Первый и наиболее очевидный вариант использования LLMQs - это InstantSend. Его можно реализовать, просто требуя от участников LLMQ подписать пороговым способом ввод обрабатываемой транзакции. Если какой-либо участник LLMQ соберёт достаточную пороговую долю, они смогут создать конечный результат и распространить его по всей сети. В результате, в сеть нужно будет распространять только одно сообщение на каждый вход транзакции. Если ноды увидят подобные подтверждения для всех входов транзакции, такая транзакция InstantSend может считаться подтверждённой.
Вскоре я напишу ещё одну статью об ещё одном DIP, которая ещё больше раскроет тему InstantSend и то, каким образом мы можем улучшить его с помощью LLMQs.
Другой вариант использования напрямую затрагивает функции, имеющие отношение к Evolution, особенно Переходы состояний (state transitions). Мы также изучаем варианты использования, которые могут улучшить не относящиеся к Evolution функции. В дальнейшем, вас ждёт больше постов и DIPов обо всём этом.
ПЕРЕВОД
Оригинал: https://blog.dash.org/introducing-long-living-masternode-quorums-76ea8b23a85a
Ссылки на DIP-ы и сопутствующие документы
DIP6 - Долгосрочные Кворумы Мастернод
DIP7 - LLMQ Запросы на подпись / Сессии
Схема подписи BLS
BLS Пороговая схема M-из-N и Распределённая генерация ключей
Что такое долгосрочные кворумы мастернод?
В предыдущем посте я уже описывал систему кворумов, которую мы сейчас используем для InstantSend. В том посте также описываются проблемы и ограничения старой системы и есть ответ на вопрос, почему мы не можем применить её для новых вариантов использования. LLMQs дают нам решение описанных проблем, и будут использоваться как часть платформы Evolution.
Они долгосрочные (как можно догадаться из названия) и возможно очень большие, а также имеют повышенный уровень безопасности. В то же время, они повышают потребление необходимых ресурсов (CPU, RAM, сеть) только у участников подобных кворумов, не повышая при этом нагрузку на всю сеть.
“Долгосрочные” означает, что вместо того, чтобы каждый раз при необходимости создавать свежий кворум, мы создаём кворумы заранее, до того, как они нам фактически потребуются, и затем повторно используем их в течение определённого периода. Суть в том, что LLMQ выполняет сессии с необходимым уровнем согласия M-из-N чтобы собрать большинство голосов, когда нужно принять решение. Новая схема M-из-N требует выполнения недоверительного и распределённого протокола генерации ключей (DGK) перед тем, как непосредственно произойдёт подписание или голосование. Поскольку этот DGK протокол довольно требователен к ресурсам, мы делаем это заранее, а затем повторно используем эти ключи для подписи и других сессий, требующих консенсуса.
Почему и каким образом LLMQs решают проблему ограничений?
Как уже говорилось в прошлом посте о кворумах, старая система требует растпространения каждого индивидуального голоса каждого участника кворума. Распространение голоса по сети означает, что голоса пересылаются всем нодам сети, которые должны подтвердить их и затем хранить. Такой подход не очень хорошо масштабируется и может также вызвать множество проблем с консенсусом.
Напротив, LLMQs требуют от участников кворума только то, чтобы они произвели распространение и подтверждение их индивидуальных голосов (подпись доли) только внутри их кворума. В конечном итоге финальная общая подпись создаётся и распространяется среди остальной части сети только тогда, когда консенсус достигнут внутри рассматриваемого кворума. Поскольку итоговый результат это результат основанной на BLS сессии с пороговой подписью M-из-N, он представляет собой всего лишь одну итоговую BLS подпись. Распространение лишь одной подписи в сети требует намного меньше ресурсов CPU, RAM и пропускной способности сети.
Поскольку участники только одной LLMQs берут на себя нагрузку по достижению консенсуса, и множество LLMQs одновременно работают параллельно, в одно и то же время, общая нагрузка на всю сеть остаётся хорошо распределённой.
Прочие преимущества
Благодаря использованию BLS, мы также получаем несколько дополнительных преимуществ. Все BLS подписи детерминированы и уникальны, что означает, что для каждой комбинации сообщения и ключей существует только одна верная подпись. Это также верно и для пороговых подписей M-из-N, которые в конечном итоге являются обычными BLS подписями. Следовательно, результат сессии подписания LLMQ также является детерминированным и уникальным.
Когда дело касается хранения кворумных решений ончейн, эти качества становятся очень важны. Без них, проблемы с нестабильностью проявятся также и в не относящиеся к транзакциям функции, например, в аккаунтах пользователей на блокчейне или применительно к переходам статусов. Устраняя эту нестабильность, Dash Evolution может задействовать такие функции, безопасное внедрение которых до этого представлялось почти невозможным.
LLMQ кворумы и подтверждение сессий подписания
LLMQs созданы с помощью протокола распределённой генерации ключей (DKG). Работа этого протокола (консенсуса на основе кворумов) привязывается к майнингу блокчейна перед активацией и непосредственным использованием LLMQ. Это означает, что достигается чёткий консенсус относительно того, какие LLMQs будут задействованы и какие именно мастерноды принадлежат к каждому LLMQ. Это также означает, что, в отличии от старой кворумной системы, сессия подписания внутри каждого кворума может быть подтверждена навсегда. Это очень важно, когда кворумные решения переносятся майнерами в блокчейн или когда SPV кошелькам (или в будущем DAPI) понадобится подтвердить кворумные подписи.
Размер LLMQ кворумов
Мы будем поддерживать разные типы LLMQs, которые (что важно) будут различаться по размеру и продолжительности. Мы ещё не решили, какие размеры кворумов нужно будет использовать, но мы можем поддерживать большие LLMQs размером в несколько сотен (например, 400) участников и также небольшие с 10 участниками. Всё это зависит от конкретных вариантов использования кворумов и соответствующих требований.
Реализация LLMQs в качестве платформы
Практическая реализация LLMQ кворумов в Dash уже нами сделана, и она уже довольно продвинутая (это не просто проверка концепции). Она разрабатывается, чтобы стать платформой, или базовым уровнем, для дальнейших вариантов использования, которым потребуются механизмы LLMQs. Изначально, внедрение новых вариантов использования должно просто вызывать несколько функций в платформе LLMQ. Это функции вроде “подписать это сообщение”, “есть ли у нас большинство?”, “есть ли конфликт?”. Таким образом, внедрять новые варианты использования должно быть очень просто, поскольку им не нужно будет взаимодействовать с внутренними настройками LLMQs, DKG, подписных сессий и так далее.
Необходимые изменения в DIP3
Чтобы поддерживать LLMQs, необходимо внести небольшие изменения в DIP3. Процесс DKG требует, чтобы публичные ключи BLS были распознаны и подтверждены до того, как начнётся сессия DKG. Это означает, что нам придётся использовать публичный ключ BLS вместо публичного ключа ECDSA для ключа оператора мастерноды. DIP3 будут обновлены тогда, когда мы примем окончательное решение, какой вариант BLS использовать.
Варианты использования LLMQs
Первый и наиболее очевидный вариант использования LLMQs - это InstantSend. Его можно реализовать, просто требуя от участников LLMQ подписать пороговым способом ввод обрабатываемой транзакции. Если какой-либо участник LLMQ соберёт достаточную пороговую долю, они смогут создать конечный результат и распространить его по всей сети. В результате, в сеть нужно будет распространять только одно сообщение на каждый вход транзакции. Если ноды увидят подобные подтверждения для всех входов транзакции, такая транзакция InstantSend может считаться подтверждённой.
Вскоре я напишу ещё одну статью об ещё одном DIP, которая ещё больше раскроет тему InstantSend и то, каким образом мы можем улучшить его с помощью LLMQs.
Другой вариант использования напрямую затрагивает функции, имеющие отношение к Evolution, особенно Переходы состояний (state transitions). Мы также изучаем варианты использования, которые могут улучшить не относящиеся к Evolution функции. В дальнейшем, вас ждёт больше постов и DIPов обо всём этом.
ПЕРЕВОД
Оригинал: https://blog.dash.org/introducing-long-living-masternode-quorums-76ea8b23a85a