#sxt $SXT @SpaceandTime Есть один вопрос, который, как мне кажется, слишком легко скрывается за фразой «проверяемые данные»: смарт-контракт может видеть только состояние блокчейна — почему же он должен доверять результату запроса к базе данных вне блокчейна? Доказательства с нулевым разглашением звучат как ответ, но большинство не задумывается о том, что именно они доказывают.
Раньше я думал, что ответ в первую очередь кроется в Proof of SQL. Но, изучив индексирующие узлы Space and Time, обязательства валидаторов и процесс генерации доказательств, я понял: настоящий ключ — сначала превратить данные в «объект, на который дано обязательство». Indexer получает данные из разных блокчейнов и декодирует их в таблицы, а Validator формирует криптографическое обязательство для состояния этих данных и подписывает его пороговой подписью. После этого результат любого запроса должен быть связан с этим обязательством: если данные тайно изменили до выполнения запроса, доказательство не пройдет проверку.
Это очень важный шаг. Space and Time не учит смарт-контракт запрашивать базу данных, а превращает «выполнение запроса» в вычисление, которое можно проверить. Prover выполняет SQL вне блокчейна и генерирует доказательство с нулевым разглашением, а контракту нужно лишь проверить обязательство и доказательство — доверять Prover не требуется. То же касается и AI Agent: данные, от которых зависит его решение, можно подвергнуть аудиту.
Поэтому, на мой взгляд, Space and Time решает не задачу «снабдить блокчейн базой данных», а задачу преобразования вычислений вне блокчейна в обязательства, которые можно проверить в блокчейне. Но цена тоже очевидна: полнота индексированных данных, охват нужного снимка обязательством и своевременная генерация доказательств — сбой на любом этапе снизит степень «проверяемости». В особенности Proof of SQL доказывает лишь, что «запрос был выполнен точно», но не то, что исходные данные правдивы: что загрузил, то и получил.
За Space and Time важнее всего наблюдать в долгосрочной перспективе не ради ответа на вопрос, можно ли доказать, что конкретный SQL-запрос не подменяли, а чтобы понять, сможет ли конвейер «обязательство для данных → проверяемый запрос → использование смарт-контрактом» быстро и стабильно работать при реальной нагрузке. AI и DeFi нужны не только изящные криптографические решения, но и инженерная система, в которой ни одно звено не подведет.
Раньше я думал, что ответ в первую очередь кроется в Proof of SQL. Но, изучив индексирующие узлы Space and Time, обязательства валидаторов и процесс генерации доказательств, я понял: настоящий ключ — сначала превратить данные в «объект, на который дано обязательство». Indexer получает данные из разных блокчейнов и декодирует их в таблицы, а Validator формирует криптографическое обязательство для состояния этих данных и подписывает его пороговой подписью. После этого результат любого запроса должен быть связан с этим обязательством: если данные тайно изменили до выполнения запроса, доказательство не пройдет проверку.
Это очень важный шаг. Space and Time не учит смарт-контракт запрашивать базу данных, а превращает «выполнение запроса» в вычисление, которое можно проверить. Prover выполняет SQL вне блокчейна и генерирует доказательство с нулевым разглашением, а контракту нужно лишь проверить обязательство и доказательство — доверять Prover не требуется. То же касается и AI Agent: данные, от которых зависит его решение, можно подвергнуть аудиту.
Поэтому, на мой взгляд, Space and Time решает не задачу «снабдить блокчейн базой данных», а задачу преобразования вычислений вне блокчейна в обязательства, которые можно проверить в блокчейне. Но цена тоже очевидна: полнота индексированных данных, охват нужного снимка обязательством и своевременная генерация доказательств — сбой на любом этапе снизит степень «проверяемости». В особенности Proof of SQL доказывает лишь, что «запрос был выполнен точно», но не то, что исходные данные правдивы: что загрузил, то и получил.
За Space and Time важнее всего наблюдать в долгосрочной перспективе не ради ответа на вопрос, можно ли доказать, что конкретный SQL-запрос не подменяли, а чтобы понять, сможет ли конвейер «обязательство для данных → проверяемый запрос → использование смарт-контрактом» быстро и стабильно работать при реальной нагрузке. AI и DeFi нужны не только изящные криптографические решения, но и инженерная система, в которой ни одно звено не подведет.