Безопасное подписание голосов

Безопасное подписание голосов

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

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

В следующих разделах описывается, как эта архитектура будет работать:

Поток сообщений

1. Узел инициализирует анклав при запуске
   • Анклав генерирует асимметричный ключ и возвращает открытый ключ узлу.
   • Пара ключей является эфемерной. Новая пара ключей создается при загрузке узла. Новая пара ключей также может быть сгенерирована во время выполнения на основе некоторых критериев, которые необходимо определить.
   • Анклав возвращает свой отчет об аттестации узлу.
2. Узел выполняет аттестацию анклава (например, с помощью IAS API от Intel)
   • Узел гарантирует, что Secure Enclave работает на TPM и подписан доверенной стороной.
3. Заинтересованная сторона узла предоставляет эфемерному ключу разрешение на использование своей доли. Этот процесс подлежит определению.
4. Ненадежное, неанклавное программное обеспечение узла вызывает доверенное анклавное программное обеспечение, используя его интерфейс для подписи транзакций и других данных.
   • В случае подписания голосования узлу необходимо проверить PoH. Проверка PoH является неотъемлемой частью подписания. Анклаву будут представлены некоторые поддающиеся проверке данные для проверки перед подписанием голосования.
   • Необходимо определить процесс генерации проверяемых данных в ненадежном пространстве.

Проверка PoH

1. Когда узел голосует за запись en X, существует период блокировки N, в течение которого он не может голосовать за ответвление, которое не содержит X в своей истории.

2. Каждый раз, когда узел голосует за производную от X, скажем, X+y, период блокировки для X увеличивается на коэффициент F \ (т. е. узел продолжительности не может голосовать за ответвление, которое не содержат X увеличивается).

   • Период блокировки для X+y по-прежнему равен N, пока узел снова не проголосует.

3. Увеличение периода блокировки ограничено \ (например, фактор F применяется максимум 32 раза).

4. Подписывающий анклав не должен подписывать голосование, нарушающее эту политику. Это означает

   • Анклав инициализируется с помощью N, F и Factor cap
   • Enclave хранит количество идентификаторов входа, по которому ранее голосовал узел.
   • Запрос на подпись содержит идентификатор записи для нового голосования.
   • Enclave проверяет, что идентификатор записи нового голосования находится в правильном форке \ (в соответствии с правилами #1 и #2 выше)

Проверка предков

Это альтернативный, хотя и менее надежный подход к проверке вилки для голосования. 1. Валидатор поддерживает активный набор узлов в кластере 2. Он наблюдает за голосами из активного набора в последний период голосования 3. Он сохраняет ancestor/last_tick, на котором голосовал каждый узел 4. Он отправляет новый запрос на голосование для голосования -сервис подписи

• Он включает в себя предыдущие голоса от узлов в активном наборе и их соответствующих предков.
  1. Подписывающая сторона проверяет, содержит ли предыдущие голоса голос валидатора, а предок голоса совпадает с большинством узлов.
• Подписывает новое голосование, если проверка прошла успешно
• Он утверждает (поднимает какую-то тревогу), если проверка не удалась

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

5 выше).

Определение форка

Из-за того, что анклав не может обрабатывать PoH, он не имеет прямых сведений об истории форка отправленного голоса валидатора. Каждый анклав следует инициировать с текущим активным набором открытых ключей. Валидатор должен отправить свой текущий голос вместе с голосами активного набора (включая самого себя), которые он наблюдал в слоте своего предыдущего голоса. Таким образом, анклав может предположить голоса, сопровождающие предыдущий голос валидатора, и, таким образом, голосовать за форк. Это невозможно для изначально отправленного голоса валидатора, так как у него не будет «предыдущего» слота для ссылки. Чтобы учесть это, должна применяться короткая заморозка голосования до тех пор, пока не будет отправлено второе голосование, содержащее голоса из активного набора вместе со своим собственным голосом, на пике первоначального голосования.

Конфигурация анклава

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

Проблемы

1. Генерация проверяемых данных в недоверенном пространстве для проверки PoH в анклаве.
2. Нужна инфраструктура для выдачи доли на эфемерный ключ.