Давно хотел(а) посмотреть это: как валидаторы Newton'а на самом деле согласуются по attest-у (подтверждению), потому что одно лишь «quorum» не объясняет механику.
Newton использует BLS-подписи для attest-а, и консенсус построен не вокруг одного дайджеста: он строится вокруг двух.
Валидаторы подписывают раздельно по policy-digest и по execution-digest для одного и того же намерения (intent).
Это разделение означает, что согласие — это не «да, одобрить это», а два независимых «да»: одно подтверждает, что была выполнена логика policy, и второе подтверждает, что фактические исполняемые данные (call data) соответствуют тому, что было attested.
Вот ту часть я раньше не разделял(а).
Схема с одним дайджестом позволяет одной подписью поручиться за весь intent сразу — policy и execution объединены. Если бы после подписания была подменена любая из половин, не было бы способа изолировать, какая именно не прошла проверку.
Два дайджеста означают, что подпись валидатора можно опровергнуть (сфальсифицировать) против каждой половины независимо.
Можно доказать, что policy была корректной, а execution-digest был повреждён, или наоборот — вместо того чтобы одна подпись покрывала «склеенное» утверждение, которое нельзя разложить.
Это значимо более сильная гарантия, чем «операторы согласились». Это согласие операторов по двум раздельным вещам, агрегированное через BLS, так что сеть по‑прежнему проверяет одну объединённую подпись on-chain.
То, чего в документации Newton не прописано явно, — что происходит операционно, когда два дайджеста расходятся для одного конкретного валидатора: будет ли это отклонено напрямую, помечено и разрешено через fallback-логику.
Вот вопрос, с которым я сейчас сижу: защищает ли split на два дайджеста от частичной подмены или просто переносит туда, где проявляется неоднозначность.
@NewtonProtocol #NEWT $NEWT $B $SKL
Newton использует BLS-подписи для attest-а, и консенсус построен не вокруг одного дайджеста: он строится вокруг двух.
Валидаторы подписывают раздельно по policy-digest и по execution-digest для одного и того же намерения (intent).
Это разделение означает, что согласие — это не «да, одобрить это», а два независимых «да»: одно подтверждает, что была выполнена логика policy, и второе подтверждает, что фактические исполняемые данные (call data) соответствуют тому, что было attested.
Вот ту часть я раньше не разделял(а).
Схема с одним дайджестом позволяет одной подписью поручиться за весь intent сразу — policy и execution объединены. Если бы после подписания была подменена любая из половин, не было бы способа изолировать, какая именно не прошла проверку.
Два дайджеста означают, что подпись валидатора можно опровергнуть (сфальсифицировать) против каждой половины независимо.
Можно доказать, что policy была корректной, а execution-digest был повреждён, или наоборот — вместо того чтобы одна подпись покрывала «склеенное» утверждение, которое нельзя разложить.
Это значимо более сильная гарантия, чем «операторы согласились». Это согласие операторов по двум раздельным вещам, агрегированное через BLS, так что сеть по‑прежнему проверяет одну объединённую подпись on-chain.
То, чего в документации Newton не прописано явно, — что происходит операционно, когда два дайджеста расходятся для одного конкретного валидатора: будет ли это отклонено напрямую, помечено и разрешено через fallback-логику.
Вот вопрос, с которым я сейчас сижу: защищает ли split на два дайджеста от частичной подмены или просто переносит туда, где проявляется неоднозначность.
@NewtonProtocol #NEWT $NEWT $B $SKL
