Перейти к основному содержимому

Proof of Training

Инференс - не единственный вид работы, который AETRON проверяет. Обучение модели тоже доказывается, механизмом под названием Proof of Training (PoT).

В чём сложность​

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

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

Witnessed Checkpoints​

Основной механизм называется Witnessed Checkpoints и держится на одном факте: отдельный шаг обучения (прямой проход, обратный проход, обновление оптимизатора) детерминирован. При тех же весах, том же состоянии оптимизатора и том же входном батче он воспроизводится бит в бит.

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

Что майнер коммитит до начала обучения​

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

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

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

Что коммитится во время обучения​

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

Как чекпоинт проверяется​

  1. Протокол выбирает случайный шаг по проверяемой случайности из состояния цепи, поэтому майнер заранее не знает, какой шаг будут разбирать.
  2. У майнера запрашивают состояние прямо перед этим шагом: веса, состояние оптимизатора, использованный батч и доказательства Меркла, помещающие соседние хэши внутрь закоммиченного корня.
  3. Проверяющий сначала сверяет обязательство. Присланное предыдущее состояние обязано хэшироваться в закоммиченное значение, а батч обязан быть тем, который закоммиченное расписание назначает этому шагу.
  4. Проверяющий выполняет один шаг обучения на этом состоянии.
  5. Результат сравнивается с закоммиченным хэшем шага. Совпадение означает, что шаг был честным, расхождение - что траектория получена не так, как заявлено.

Проверяющие не публикуют голое «да» или «нет». Сначала они коммитят свой пересчитанный результат, а потом раскрывают его через reveal_witness_value, который несёт пересчитанный хэш и корзину нормы, привязанную к соли и личности самого проверяющего. Вердикт берётся из наибольшего кластера совпавших значений, а не из большинства мнений, поэтому одиночный проверяющий со случайным хэшем просто оказывается вне кластера и ни на что не влияет. Для межархитектурных случаев майнер объявляет эталонную корзину нормы для проверяемого шага через declare_witness_norm_bucket, и победивший кластер сравнивается уже с ней, а не с побитовым хэшем.

Случайность внутри шага​

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

Каноническая спецификация закрывает это требованием политики сида ГСЧ, которой майнер обязан следовать перед каждым прямым проходом. Обычная форма выводит сид для шага из закоммиченного базового сида и индекса шага, поэтому проверяющий восстанавливает ровно тот же сид из назначенного ему шага. Политика с одним сидом в начале тоже работает, ценой переноса состояния ГСЧ в чекпоинтах. Тесты показали разницу отчётливо: с сидом, выведенным на каждый шаг, повторные прогоны совпадали побитово, а без политики сида не совпадали ни разу. Конфигурация задачи, объявляющая ненулевой dropout без политики сида, отклоняется.

Почему подмена не проходит​

Допустим, майнер раздобыл готовую траекторию иным способом и коммитит её хэши как свои. Когда выпадет случайный шаг, вариантов два.

Майнер может отдать предыдущее состояние из этой заимствованной траектории. Проверка обязательства пройдёт, потому что именно эти хэши он и закоммитил. Но батч не свободен: закоммиченное расписание фиксирует, какой сэмпл принадлежит этому шагу. Проверяющий выполняет шаг с заимствованным состоянием и назначенным батчем. Если траектория и правда обучалась на закоммиченном датасете по этому расписанию, результат совпадёт, и это честное обучение, а не подмена. Если она обучалась на чём-то другом, результат не совпадёт.

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

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

Частичный обман​

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

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

Стоимость​

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

Вспомогательные проверки​

Witnessed Checkpoints - основной механизм. Рядом идут дешёвые рантайм-проверки, которым GPU не нужен вообще: закоммиченная последовательность лосса проверяется на монотонное снижение в пределах шумового допуска, на скорость снижения, согласующуюся с моделью и вычислениями, на лосс, застывший на многих чекпоинтах, и на резкие скачки назад. Сами по себе они обучение не доказывают, зато отлавливают очевидно сломанные траектории до того, как кто-то потратит вычисления на пересчёт.

Защита от закладок​

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

В обычных метриках эффект невидим. Валидационный лосс остаётся там, где его оставило бы честное обучение, а модель ведёт себя безопасно, пока не появится триггер. Gensyn опубликовала эту атаку под названием «Backdoor in the Middle» с успешностью 94 процента и заявила, что планирует изучать контрмеры.

Ответ AETRON собран из нескольких независимых сигналов. Часть считается по дельтам весов, которые коммитит каждая стадия, а один читает не веса, а поведение модели на отложенных зондах, поэтому атакующему, подстроившемуся под один из них, остаются остальные. Подробное устройство защиты и её калибровка не публикуются.

Swarm Mode​

Swarm Mode - это распределённая форма обучения, где модель, не влезающая в одну машину, режется на конвейер между несколькими майнерами, и каждый держит одну стадию. Стек защиты от закладок существует именно из-за неё: вброс в стадию конвейера возможен только тогда, когда кто-то контролирует стадию, а не всю модель.

Спецификация прямо очерчивает область. Swarm Mode не входит в первую фазу, которая покрывает задачи обучения на одном майнере примерно до 70B параметров на одной ноде 8xH100; там каждый майнер держит модель целиком, и промежуточной стадии для атаки просто нет. Swarm Mode рассчитан на диапазон от 200B до 1T параметров, где одной ноды уже не хватает, а стек защиты спроектирован и проверен против вариантов атаки, но в рантайме первой фазы не реализован.

Куда идти дальше​

Последнее обновление