Раньше я читал «trustless verification» на странице Babylon про TBV так, будто это значит, что вся цепочка доверия удалена, а не просто одно звено в ней.
Потом я вник и посмотрел, что именно охватывает это доказательство.
Три компонента делают это работающим: on-chain-контракты, доказательства для light-client, которые запускаются на ZK-SNARK, и независимые индексаторы — всё это сшито вместе, чтобы можно было проверять консенсус Bitcoin и состояние UTXO где-то совершенно в другом месте, не полагаясь на то, что один конкретный доверенный посредник поручится за это.
Хм.
Потому что SNARK доказывает нечто более узкое, чем подсказывает подача. Он подтверждает, что заявленный переход состояния Bitcoin соответствует правилам, «зашитым» в схему — той же схеме, которая кодирует собственную консенсус-логику Bitcoin, проверку математических вычислений.
При этом он предполагает две вещи, не доказывая ни одну из них. Что заголовок и данные транзакций, подаваемые в схему, изначально были точными, и что сама схема была собрана корректно с самого начала.
Я закрыл страницу и проследил оба допущения туда, где они на самом деле живут.
Первое — это работа индексатора: отдельный, заменяемый компонент, который стоит рядом с системой доказательств. Второе — у того, кто построил и аудировал схему: это разовый вопрос доверия, а не постоянно текущий.
Я не говорю, что это делает дизайн слабым. В любой ZK-схеме light-client, которая опирается на данные внешней цепочки, где-то есть такие стыки. Babylon просто называет их, вместо того чтобы складывать это в общую «подачу».
Если SNARK идеально верифицирует переход состояния, но неверным оказалось одно из допущений, то действительно ли «trustless» часть удержалась, или лишь та часть, которая и так изначально не была доверительной?
#baby
$BABY
@BabylonLabs_io
$BABY
#baby
Потом я вник и посмотрел, что именно охватывает это доказательство.
Три компонента делают это работающим: on-chain-контракты, доказательства для light-client, которые запускаются на ZK-SNARK, и независимые индексаторы — всё это сшито вместе, чтобы можно было проверять консенсус Bitcoin и состояние UTXO где-то совершенно в другом месте, не полагаясь на то, что один конкретный доверенный посредник поручится за это.
Хм.
Потому что SNARK доказывает нечто более узкое, чем подсказывает подача. Он подтверждает, что заявленный переход состояния Bitcoin соответствует правилам, «зашитым» в схему — той же схеме, которая кодирует собственную консенсус-логику Bitcoin, проверку математических вычислений.
При этом он предполагает две вещи, не доказывая ни одну из них. Что заголовок и данные транзакций, подаваемые в схему, изначально были точными, и что сама схема была собрана корректно с самого начала.
Я закрыл страницу и проследил оба допущения туда, где они на самом деле живут.
Первое — это работа индексатора: отдельный, заменяемый компонент, который стоит рядом с системой доказательств. Второе — у того, кто построил и аудировал схему: это разовый вопрос доверия, а не постоянно текущий.
Я не говорю, что это делает дизайн слабым. В любой ZK-схеме light-client, которая опирается на данные внешней цепочки, где-то есть такие стыки. Babylon просто называет их, вместо того чтобы складывать это в общую «подачу».
Если SNARK идеально верифицирует переход состояния, но неверным оказалось одно из допущений, то действительно ли «trustless» часть удержалась, или лишь та часть, которая и так изначально не была доверительной?
#baby
$BABY
@BabylonLabs_io
$BABY
#baby