Учет доли в схемах пороговой подписи
Что такое пороговая подпись и как она используется в Axelar?
Пороговая схема подписи позволяет группе сторон разделить секретный ключ для схемы подписи таким образом, что любое подмножество из t+1 или более сторон может сотрудничать для создания подписи, но никакая подгруппа из t или меньшего числа сторон не может создать подпись или даже узнать любую информацию о секретном ключе.
Пороговые протоколы существуют для наиболее широко используемых сегодня схем подписи, включая схему ECDSA, используемую в Биткойне и Эфириуме. Подписи, создаваемые пороговым протоколом, неотличимы от обычных (непороговых) подписей ECDSA.
Валидаторы Axelar используют пороговые схемы подписи для коллективного ведения учетных записей в различных блокчейнах, таких как Биткойн и Эфириум. Эти учетные записи позволяют валидаторам Axelar разблокировать активы в цепочке A, чтобы переместить эти активы в цепочку B.
Необходимость взвешенных пороговых подписей
Сеть Axelar использует консенсус Proof-of-Stake; между валидаторами Axelar может быть неравное распределение доли. Полезно подумать о простом примере с тремя валидаторами Axelar: Алисой, Бобом и Клэр, проценты ставок которых составляют 47%, 17% и 36%.
Фундаментальный принцип заключается в том, что активы на пороговых счетах могут быть перемещены только в том случае, если достаточно большая часть доли Axelar согласна на их перемещение. Продолжая наш пример, давайте предположим, что доля равна 40%, так что только те подмножества Алисы, Боба и Клэр, чья общая доля превышает 40%, могут перемещать активы. Таким образом, у Алисы достаточно доли, чтобы перемещать активы самостоятельно, но Боб должен объединиться с Клэр, чтобы перемещать активы без Алисы.
К сожалению, существующие схемы пороговой подписи предполагают, что все стороны протокола имеют равные полномочия для создания подписей. Наивное использование пороговых подписей могло бы выделить одну долю секретного ключа каждому из Алисы, Боба и Клэр. В этом случае нет порогового значения t, которое может обеспечить только что описанную структуру доступа:
- Если t>=1, то Алиса не может сделать подпись сама, несмотря на то, что она контролирует >40% акций Axelar.
- Если t<1, то либо Боб, либо Клэр могут сделать подпись самостоятельно, несмотря на то, что ни один из них не контролирует 40% акций Axelar.
Что нам нужно, так это способ воспроизвести нашу желаемую структуру доступа, используя существующие схемы пороговой подписи.
Добавление весов к пороговым подписям
Одно из решений нашей проблемы в принципе довольно простое: выделить несколько пороговых долей каждому валидатору пропорционально сумме доли, контролируемой этим валидатором. Но есть несколько надоедливых крайних случаев, которые нужно решить.
Давайте начнем с более подробного описания решения, а затем посмотрим, как оно справляется с надоедливыми пограничными случаями. Решение распределяет цель в n полных долей порога между валидаторами в соответствии со следующим методом:
- Для начала каждый валидатор получает 1 пороговую долю за каждую 1/n долю доли, которую он контролирует, округляя в меньшую сторону.
- Если общее количество долей на данный момент меньше целевого, то присудите одну дополнительную акцию каждой стороне в порядке убывания ставки, пока не будет достигнута цель (также должно быть указано произвольное правило разрешения ничьей).
Применяя этот метод к нашему примеру, давайте установим цель n = 100 общих акций, поэтому порог t = 40. Затем Алиса получает 47 акций, Боб — 17, а Клэр — 36. Легко!
Числа в этом примере работают хорошо, но что, если числа не такие хорошие? Вместо этого предположим, что доли Алисы и Боба составляют 47,5% и 16,5%. Должны ли (Алиса, Боб) получить (48, 16) или (47,17) доли? В соответствии с описанной выше процедурой дополнительная доля достается Алисе, а не Бобу.
На первый взгляд выбор дать дополнительную долю Алисе в приведенном выше примере может показаться произвольным, поэтому давайте мотивируем его другим примером. Предположим вместо этого, у нас есть 200 валидаторов со следующим распределением ставок:
- 50 валидаторов имеют долю 0,7%
- 50 валидаторов имеют долю 0,6%
- 50 валидаторов имеют долю 0,4%
- 50 валидаторов имеют долю 0,3%
В этом случае ясно, что правильное распределение 100 акций выглядит следующим образом:
И это именно то распределение, которое мы получаем от этого решения.
Рекомендации по реализации
Концептуально просто выделить несколько пороговых долей для каждого валидатора, но это в программной библиотеке приводит к увеличению сложности на низком уровне и ведению учета по сравнению с наивным правилом «одна доля на валидатор».
Например, к каждому сообщению в протоколе пороговой подписи должна быть прикреплена дополнительная информация о маршрутизации. Уже недостаточно реализовать «Алиса отправляет сообщение m Бобу». Вместо этого нам нужно реализовать «Алиса №3 отправляет сообщение m Бобу №7». Программное обеспечение пороговой подписи должно упаковывать и распаковывать дополнительные метаданные «#3», «#7».
Пользователь библиотеки — валидатор Axelar — не должен беспокоиться о маршрутизации. Вместо этого валидатор должен знать только «Алиса отправляет сообщение Бобу». Действительно, единственное отличие от наивного «одна акция на валидатора» с точки зрения валидатора заключается в следующем: чтобы инициировать протокол генерации ключа, валидатор должен указать один раз в начале протокола, сколько шаров получает каждая сторона. Библиотека обрабатывает все остальное. После инициализации API библиотеки должен быть неотличим от более простого протокола «один общий ресурс на валидатор».
Рассмотрим следующую архитектурную схему:
Валидатор Axelar (Алиса) имеет 3 пороговые доли, выделенные ей. Она получает сообщения из сети Axelar, адресованные ей. Маршрутизатор Алисы распаковывает каждое сообщение ровно настолько, чтобы определить, какая из ее общих папок (№1, №2, №3) является конечным пунктом назначения для сообщения. Каждый общий ресурс управляется отдельным экземпляром порогового протокола («Протокол №1» и т. д. на схеме). Каждый экземпляр протокола добавляет данные маршрутизации к своим исходящим сообщениям и отправляет их непосредственно в сеть Axelar. Окончательный результат каждого экземпляра соответствующим образом агрегируется Алисой в соответствии с деталями базового порогового протокола, прежде чем единый окончательный результат будет отправлен в сеть Axelar.
Этот окончательный результат также может быть сохранен в локальном хранилище данных Алисы для последующего использования. Например, если конечным результатом является совместное использование секретного ключа с пороговым значением, Алисе необходимо запомнить эти секретные данные, чтобы участвовать в подписании сообщений в будущем.