внутри децентрализованной оценки политики спрятана техническая проблема, о которой почти не говорят, и мне потребовалось чертовски долгое время, чтобы по-настоящему понять, почему это важно.
когда операторы независимо получают актуальные данные, цены на активы, обновления санкционных списков, данные оракула, они могут получить разные значения из одного и того же источника в зависимости от того, когда именно их запрос пришёл. обновления санкционных списков. цены меняются между миллисекундами. если каждый оператор получает чуть разные данные, а затем пытается BLS-подписать результат политики, подписи не агрегируются. для агрегации BLS нужны идентичные сообщения.
операторы, подписывающие разные результаты, не могут сгенерировать единую компактную доказательную запись, согласованную кворумом по исходу.
Это фундаментальная задача для любой децентрализованной системы авторизации, которой нужно проверять политики по живым внешним данным. Ньютон решает её с помощью двухфазного протокола потокового консенсуса, основанного на обмене сообщениями NATS, и важно понимать это подробно.
первая фаза — фаза Prepare. шлюз публикует операторам через NATS запрос на получение данных. каждый оператор в активном наборе валидаторов независимо выполняет WASM-провайдер данных — песочничный плагин, который извлекает внешние данные по собственному сетевому маршруту, создавая независимые ECDSA-подтверждения (attestations) по тем данным, которые он наблюдал. операторы стримят ответы по мере завершения, без барьера синхронизации. затем шлюз вычисляет консенсус на основе медианы по числовым полям в ответах операторов, чтобы получить единый канонический набор данных.
здесь важен механизм медианы. он устойчив к тому, что отдельные операторы отправляют выбросы: один оператор, сообщающий манипулированную цену, не может существенно сдвинуть консенсус, если остальной набор операторов сообщает корректно……
вторая фаза — фаза Evaluate. шлюз публикует набор данных консенсуса операторам через NATS. операторы извлекают политику Rego из IPFS по идентификатору контента (content ID), оценивают её по эталонным данным, вычисляют дайджест консенсуса и выполняют BLS-подпись результата al в одном атомарном шаге. поскольку теперь все операторы оценивают одну и ту же детерминированную политику по одним и тем же данным консенсуса, они получают идентичные результаты и одинаковые дайджесты, что позволяет выполнить BLS-агрегацию.
агрегатор проверяет кворум на каждом входящем подписанном ответе и завершает работу сразу, как только достигается порог, взвешенный по доле (stake), тем самым минимизируя сквозную задержку (end to end latency).
И потоковая архитектура важна не только для решения проблемы недетерминизма. операторы не ждут друг друга. они стримят ответы по мере готовности. агрегатор завершает работу сразу, как только достигнут кворум, а не дожидается ответа каждого оператора…
для задач, где данные политики детерминированы или заранее подготовлены (прекашированы), протокол поддерживает упрощённый оденофазный режим, который пропускает фазу Prepare полностью, снижая задержку до одного сетевого обмена NATS (одного round-trip).
я нахожу механизм консенсуса на основе медианы по-настоящему изящным решением для задач манипулирования данными. не потому, что он теоретически идеален, а потому что он хорошо справляется с практической моделью угроз. злоумышленнику нужно исказить существенную долю набора операторов, чтобы полностью сдвинуть смысл медианы, и у этих операторов есть экономический риск.
Достаточно ли двухфазная архитектура добавляет задержку на практике, чтобы это имело значение для самых чувствительных ко времени приложений — операций высокочастотного хранилища (vault)… операций с транзакциями в реальном времени — это вопрос производительности, на который я хочу получить ответ под реальной нагрузкой??
