LinhNB
768 Публикации
LinhNB
Трейдер с регулярными сделками
5.8 г
128 подписок(и/а)
219 подписчиков(а)
901 понравилось
Посты
Все
Цитирования
Я провёл последние две недели, пытаясь понять один вопрос о GRVT: как биржа может ощущаться настолько близкой к CEX, при этом позволяя пользователям сохранять самоcтоятельное хранение? Меня удивило, что ответ был не в Matching Engine. Он заключался в Cryptographic Order Batching. Сначала я думал, что батчинг — это просто способ снизить комиссии за газ. Чем больше я изучал архитектуру GRVT, тем менее убедительным становилось такое объяснение.
GRVT утверждает, что её Matching Engine способен обрабатывать более 600 000 ордеров в секунду с задержкой ниже 2 миллисекунд. Ethereum никогда не был предназначен для проверки сотен тысяч транзакций каждую секунду. Если каждый ордер будет урегулироваться по отдельности on-chain, со временем выполнение неизбежно упрётся в ограничения расчётов. Более быстрый Matching Engine сам по себе не сделает биржу заметно быстрее.
Cryptographic Order Batching не существует потому, что Ethereum медленный. Он существует потому, что Matching Engine и Ethereum работают в принципиально разных условиях производительности. Ордеры сопоставляются off-chain и представляются одним Zero-Knowledge-доказательством. Ethereum проверяет итоговое состояние вместо того, чтобы проверять каждый отдельный ордер. Это изменило то, как я думаю о самостоятельном хранении.
Раньше я связывал самоcтоятельное хранение с полной прозрачностью исполнения. GRVT разделяет эти вещи. Пользователи по-прежнему контролируют свои обеспечительные активы, а расчёты остаются проверяемыми. Что они теряют — это непрерывную видимость каждого решения сопоставления. Это не обязательно слабость. Это — другое архитектурное решение. Система меняет непрерывную наблюдаемость исполнения на криптографическую уверенность в финальном состоянии.
Я всё ещё не уверен, имеет ли значение это различие для большинства трейдеров. Если ваш приоритет — скорость исполнения, самоcтоятельное хранение и проверяемый расчёт, вероятно, нет. Если важнее всего прозрачность исполнения, вероятно, да. Для меня Cryptographic Order Batching больше не похож на технику масштабирования. Он выглядит как механизм, позволяющий Hybrid Exchange отделять исполнение от проверки, не отделяя производительность от доверия.
@grvt_io #grvt $LAB
GRVT утверждает, что её Matching Engine способен обрабатывать более 600 000 ордеров в секунду с задержкой ниже 2 миллисекунд. Ethereum никогда не был предназначен для проверки сотен тысяч транзакций каждую секунду. Если каждый ордер будет урегулироваться по отдельности on-chain, со временем выполнение неизбежно упрётся в ограничения расчётов. Более быстрый Matching Engine сам по себе не сделает биржу заметно быстрее.
Cryptographic Order Batching не существует потому, что Ethereum медленный. Он существует потому, что Matching Engine и Ethereum работают в принципиально разных условиях производительности. Ордеры сопоставляются off-chain и представляются одним Zero-Knowledge-доказательством. Ethereum проверяет итоговое состояние вместо того, чтобы проверять каждый отдельный ордер. Это изменило то, как я думаю о самостоятельном хранении.
Раньше я связывал самоcтоятельное хранение с полной прозрачностью исполнения. GRVT разделяет эти вещи. Пользователи по-прежнему контролируют свои обеспечительные активы, а расчёты остаются проверяемыми. Что они теряют — это непрерывную видимость каждого решения сопоставления. Это не обязательно слабость. Это — другое архитектурное решение. Система меняет непрерывную наблюдаемость исполнения на криптографическую уверенность в финальном состоянии.
Я всё ещё не уверен, имеет ли значение это различие для большинства трейдеров. Если ваш приоритет — скорость исполнения, самоcтоятельное хранение и проверяемый расчёт, вероятно, нет. Если важнее всего прозрачность исполнения, вероятно, да. Для меня Cryptographic Order Batching больше не похож на технику масштабирования. Он выглядит как механизм, позволяющий Hybrid Exchange отделять исполнение от проверки, не отделяя производительность от доверия.
@grvt_io #grvt $LAB
Есть один аспект протокола Newton, который остался со мной после прочтения документации. Вопреки тому, что многие предполагают, проект на самом деле не пытается решать вопрос приватности. Он меняет то, что блокчейн должен знать, чтобы устанавливать доверие.
Годы подряд блокчейны полагались на простое допущение: прозрачность порождает доверие. Однако самая ценная информация в финансах — записи KYC, инвестиционные стратегии, корпоративные данные и внутренние модели рисков — никогда не может быть сделана публичной. Если доверие зависит от раскрытия конфиденциальной информации, блокчейн всегда будет испытывать трудности с поддержкой AI-агентов, RWAs и институциональных финансов.
Протокол Newton использует другой подход. Блокчейну не нужно знать, что именно содержат данные. Ему достаточно доказательства того, что данные были использованы в соответствии с корректной политикой, корректным уполномоченным лицом и в правильном контексте до того, как действие было разрешено. Newton не меняет способ защиты данных. Он меняет то, что блокчейны обязаны проверять.
Поэтому я не рассматриваю Privacy-Preserving Workflows (рабочие процессы с сохранением приватности) как нечто большее, чем просто фреймворк шифрования. Privacy Envelopes, HPKE и Distributed Key Generation — это лишь инфраструктура. Настоящее новаторство в том, что ни одна сторона не может преобразовать приватные данные в разрешённое действие без выполнения заранее заданных политик. Newton защищает не только конфиденциальность, но и легитимность самого действия.
Здесь же Newton отличается от многих решений по приватности в Web3. Большинство сосредоточены на сокрытии информации. Newton фокусируется на доказательстве того, что полномочия были реализованы корректно. Блокчейну больше не нужно читать данные; ему достаточно проверить, что право на действие было подтверждено до выполнения.
Для меня именно в этом заключается истинная значимость Privacy-Preserving Workflows. Следующее поколение блокчейнов, возможно, больше не будут оценивать по тому, сколько данных они хранят, а по тому, сколько легитимных решений они могут проверить, не получая никогда доступа к лежащим в основе данным. Протокол Newton — это не просто добавление ещё одного слоя приватности. Он переопределяет то, как блокчейны создают доверие.@NewtonProtocol $NEWT #Newt $LAB
Годы подряд блокчейны полагались на простое допущение: прозрачность порождает доверие. Однако самая ценная информация в финансах — записи KYC, инвестиционные стратегии, корпоративные данные и внутренние модели рисков — никогда не может быть сделана публичной. Если доверие зависит от раскрытия конфиденциальной информации, блокчейн всегда будет испытывать трудности с поддержкой AI-агентов, RWAs и институциональных финансов.
Протокол Newton использует другой подход. Блокчейну не нужно знать, что именно содержат данные. Ему достаточно доказательства того, что данные были использованы в соответствии с корректной политикой, корректным уполномоченным лицом и в правильном контексте до того, как действие было разрешено. Newton не меняет способ защиты данных. Он меняет то, что блокчейны обязаны проверять.
Поэтому я не рассматриваю Privacy-Preserving Workflows (рабочие процессы с сохранением приватности) как нечто большее, чем просто фреймворк шифрования. Privacy Envelopes, HPKE и Distributed Key Generation — это лишь инфраструктура. Настоящее новаторство в том, что ни одна сторона не может преобразовать приватные данные в разрешённое действие без выполнения заранее заданных политик. Newton защищает не только конфиденциальность, но и легитимность самого действия.
Здесь же Newton отличается от многих решений по приватности в Web3. Большинство сосредоточены на сокрытии информации. Newton фокусируется на доказательстве того, что полномочия были реализованы корректно. Блокчейну больше не нужно читать данные; ему достаточно проверить, что право на действие было подтверждено до выполнения.
Для меня именно в этом заключается истинная значимость Privacy-Preserving Workflows. Следующее поколение блокчейнов, возможно, больше не будут оценивать по тому, сколько данных они хранят, а по тому, сколько легитимных решений они могут проверить, не получая никогда доступа к лежащим в основе данным. Протокол Newton — это не просто добавление ещё одного слоя приватности. Он переопределяет то, как блокчейны создают доверие.@NewtonProtocol $NEWT #Newt $LAB
Если бы самодепозитарное хранение (self-custody) было поставлено на суд, я думаю, его бы неправомерно признали виновным.
Обвинение звучит убедительно.
«Трейдера всё ещё можно ликвидировать, потому что система неверно рассчитывает маржу. Так что же самодепозитарное хранение на самом деле защищает?»
Чем глубже я изучал архитектуру GRVT, тем больше понимал: эта критика направлена не на тот компонент.
Самодепозитарное хранение никогда не обещало предотвращать некорректные ликвидации. Оно лишь гарантирует, что ваши активы остаются вашими — даже если оператор биржи станет неплатёжеспособным или будет действовать со злым умыслом.
Маржа — это совсем другая проблема.
Risk Engine не спрашивает: «Кому принадлежат эти активы?» Он спрашивает: «При текущих рыночных условиях это обеспечение по-прежнему достаточно, чтобы поддерживать позицию?» Проверка принадлежности активов и оценка рисков решают разные задачи, поэтому они относятся к разным архитектурным уровням.
Это означает, что трейдер может оставаться законным владельцем каждого актива — и при этом его всё равно могут ликвидировать, если оценка обеспечения, поддерживающая маржа или риски портфеля были рассчитаны неверно. Ликвидация вызвана уровнем рисков — а не уровнем хранения.
Для меня это и есть главное архитектурное прозрение GRVT.
Вместо того чтобы строить одну систему, отвечающую за всё, GRVT разделяет обязанности. Самодепозитарное хранение защищает от риска оператора, а Unified Margin и Risk Engine определяют, остаётся ли позиция финансово безопасной. Каждый уровень отвечает за свою категорию отказов.
Это разделение меняет то, как работает доверие. Вместо доверия одному единственному «чёрному ящику» пользователи могут понять, какой уровень несёт ответственность, когда что-то идёт не так.
Если бы мне пришлось вынести вердикт, я бы признал самодепозитарное хранение невиновным.
Не потому, что оно устраняет все риски. А потому, что оно никогда этого и не обещало.
Настоящий вклад GRVT — не в создании системы, которая никогда не выходит из строя. Он создаёт систему, в которой каждый сбой имеет чётко отвечающий за него архитектурный уровень. И, на мой взгляд, именно это делает Hybrid Exchange по-настоящему более заслуживающим доверия.
@grvt_io #grvt $LAB $BEAT
Обвинение звучит убедительно.
«Трейдера всё ещё можно ликвидировать, потому что система неверно рассчитывает маржу. Так что же самодепозитарное хранение на самом деле защищает?»
Чем глубже я изучал архитектуру GRVT, тем больше понимал: эта критика направлена не на тот компонент.
Самодепозитарное хранение никогда не обещало предотвращать некорректные ликвидации. Оно лишь гарантирует, что ваши активы остаются вашими — даже если оператор биржи станет неплатёжеспособным или будет действовать со злым умыслом.
Маржа — это совсем другая проблема.
Risk Engine не спрашивает: «Кому принадлежат эти активы?» Он спрашивает: «При текущих рыночных условиях это обеспечение по-прежнему достаточно, чтобы поддерживать позицию?» Проверка принадлежности активов и оценка рисков решают разные задачи, поэтому они относятся к разным архитектурным уровням.
Это означает, что трейдер может оставаться законным владельцем каждого актива — и при этом его всё равно могут ликвидировать, если оценка обеспечения, поддерживающая маржа или риски портфеля были рассчитаны неверно. Ликвидация вызвана уровнем рисков — а не уровнем хранения.
Для меня это и есть главное архитектурное прозрение GRVT.
Вместо того чтобы строить одну систему, отвечающую за всё, GRVT разделяет обязанности. Самодепозитарное хранение защищает от риска оператора, а Unified Margin и Risk Engine определяют, остаётся ли позиция финансово безопасной. Каждый уровень отвечает за свою категорию отказов.
Это разделение меняет то, как работает доверие. Вместо доверия одному единственному «чёрному ящику» пользователи могут понять, какой уровень несёт ответственность, когда что-то идёт не так.
Если бы мне пришлось вынести вердикт, я бы признал самодепозитарное хранение невиновным.
Не потому, что оно устраняет все риски. А потому, что оно никогда этого и не обещало.
Настоящий вклад GRVT — не в создании системы, которая никогда не выходит из строя. Он создаёт систему, в которой каждый сбой имеет чётко отвечающий за него архитектурный уровень. И, на мой взгляд, именно это делает Hybrid Exchange по-настоящему более заслуживающим доверия.
@grvt_io #grvt $LAB $BEAT
Десять операторов не обязательно означают десять независимых решений.
С этого предположения я и начал сомневаться, когда изучал протокол Newton. Мы часто оцениваем децентрализацию, просто считая операторов, однако авторизационная сеть защищается не количеством узлов, а тем, сколько независимых путей могут привести к одному и тому же решению авторизации.
В Newton операторы выполняют одну и ту же Rego Policy, скомпилированную в WASM, над тем же Intent и PolicyData до того, как начнётся Execution. Реплицировать вычисления легко. Доказать, что независимые участники приходят к одной и той же границе авторизации, — именно то, что формирует доверие.
Вот почему разнообразие инфраструктуры важнее, чем количество операторов. Если большинство операторов использует одного и того же облачного провайдера, они также разделяют одну и ту же область отказов. Единственный сбой инфраструктуры может нарушить оценку Policy у многих операторов, из-за чего Authorization будет зависеть не только от Policy, но и от инфраструктуры вне протокола.
Для меня это не слабость Newton. Это стандарт, которому должен соответствовать протокол авторизации. Как только Policy становится «воротами» между Intent и Execution, ни одна область отказов не должна иметь возможности влиять на эти ворота. Иначе децентрализация существует в топологии, но не в Authorization.
Fail-closed конструкция Newton отражает именно эту философию. Если Authorization нельзя установить с достаточной уверенностью, Execution останавливается. Протокол намеренно предпочитает временную недоступность решению об авторизации, которому нельзя доверять.
Рассматривая это таким образом, разнообразие операторов больше не является просто операционной оптимизацией. Это часть модели безопасности Newton. Реальный вопрос не в том, сколько операторов в сети онлайн, а в том, может ли любая одна область отказов решить, существует ли Authorization. Если ответ «да», сеть просто умножила количество операторов, не умножив по-настоящему доверие.
@NewtonProtocol $NEWT #Newt $LAB
С этого предположения я и начал сомневаться, когда изучал протокол Newton. Мы часто оцениваем децентрализацию, просто считая операторов, однако авторизационная сеть защищается не количеством узлов, а тем, сколько независимых путей могут привести к одному и тому же решению авторизации.
В Newton операторы выполняют одну и ту же Rego Policy, скомпилированную в WASM, над тем же Intent и PolicyData до того, как начнётся Execution. Реплицировать вычисления легко. Доказать, что независимые участники приходят к одной и той же границе авторизации, — именно то, что формирует доверие.
Вот почему разнообразие инфраструктуры важнее, чем количество операторов. Если большинство операторов использует одного и того же облачного провайдера, они также разделяют одну и ту же область отказов. Единственный сбой инфраструктуры может нарушить оценку Policy у многих операторов, из-за чего Authorization будет зависеть не только от Policy, но и от инфраструктуры вне протокола.
Для меня это не слабость Newton. Это стандарт, которому должен соответствовать протокол авторизации. Как только Policy становится «воротами» между Intent и Execution, ни одна область отказов не должна иметь возможности влиять на эти ворота. Иначе децентрализация существует в топологии, но не в Authorization.
Fail-closed конструкция Newton отражает именно эту философию. Если Authorization нельзя установить с достаточной уверенностью, Execution останавливается. Протокол намеренно предпочитает временную недоступность решению об авторизации, которому нельзя доверять.
Рассматривая это таким образом, разнообразие операторов больше не является просто операционной оптимизацией. Это часть модели безопасности Newton. Реальный вопрос не в том, сколько операторов в сети онлайн, а в том, может ли любая одна область отказов решить, существует ли Authorization. Если ответ «да», сеть просто умножила количество операторов, не умножив по-настоящему доверие.
@NewtonProtocol $NEWT #Newt $LAB
Некоторые пути начинаются всего с нескольких шагов. Но после того, как по ним прошли тысячи, никто уже не помнит, зачем их создали. Люди продолжают идти дальше, потому что предполагают, что те, кто был до них, уже нашли самый лучший путь.
Читая о @NewtonProtocol is Policy Marketplace, я понял: ценность политики может расти так же.
Сначала я думал, что ценность приходит из качества. Чем точнее, безопаснее и адаптивнее политика, тем больше протоколов должно её принять. Если бы так и было, Policy Marketplace превратился бы в рынок, где знания вознаграждаются.
Но рынки редко работают именно так.
В технологиях люди часто перенимают доверие до качества. Качество может создать доверие, но со временем доверие начинает само себя укреплять.
Политика, которую используют тысячи протоколов, получает больше аудитов, инструментов и истории внедрения. Разработчики могут уже не выбирать её потому, что внимательно изучили. Они выбирают её, потому что её уже использует все вокруг.
И именно тогда меняется ценность.
Политика больше не ценится только за своё качество.
Её ценят за доверие, накопленное вокруг неё.
Вот парадокс, который я вижу в Policy Marketplace. Хорошая политика создаёт сетевые эффекты. Но когда эти эффекты становятся достаточно сильными, они делают лучшие политики сложнее заменить. Рынок начинает вознаграждать популярность больше, чем улучшения.
Если так случится, Policy Marketplace перестанет находить лучшие политики.
Он будет сохранять самые уже укоренившиеся.
Это и есть реальная задача, которую Ньютону нужно решить.
Рынок должен не только сделать политики переиспользуемыми. Он также должен обеспечить, чтобы доверие постоянно можно было заслуживать. Политика не должна оставаться ценной просто потому, что она существует уже много лет. Она должна продолжать доказывать свою состоятельность через производительность, адаптивность и реальные результаты.
Иначе сетевые эффекты вытеснят качество.
Но если Ньютон сможет построить систему, где репутация обновляется доказательствами, а не наследуется из истории, Policy Marketplace станет не просто местом для обмена политиками.
Он станет рынком, где конкурирует само доверие.
И, возможно, именно этого блокчейну не хватало.
$NEWT #Newt $LAB $TAC
Читая о @NewtonProtocol is Policy Marketplace, я понял: ценность политики может расти так же.
Сначала я думал, что ценность приходит из качества. Чем точнее, безопаснее и адаптивнее политика, тем больше протоколов должно её принять. Если бы так и было, Policy Marketplace превратился бы в рынок, где знания вознаграждаются.
Но рынки редко работают именно так.
В технологиях люди часто перенимают доверие до качества. Качество может создать доверие, но со временем доверие начинает само себя укреплять.
Политика, которую используют тысячи протоколов, получает больше аудитов, инструментов и истории внедрения. Разработчики могут уже не выбирать её потому, что внимательно изучили. Они выбирают её, потому что её уже использует все вокруг.
И именно тогда меняется ценность.
Политика больше не ценится только за своё качество.
Её ценят за доверие, накопленное вокруг неё.
Вот парадокс, который я вижу в Policy Marketplace. Хорошая политика создаёт сетевые эффекты. Но когда эти эффекты становятся достаточно сильными, они делают лучшие политики сложнее заменить. Рынок начинает вознаграждать популярность больше, чем улучшения.
Если так случится, Policy Marketplace перестанет находить лучшие политики.
Он будет сохранять самые уже укоренившиеся.
Это и есть реальная задача, которую Ньютону нужно решить.
Рынок должен не только сделать политики переиспользуемыми. Он также должен обеспечить, чтобы доверие постоянно можно было заслуживать. Политика не должна оставаться ценной просто потому, что она существует уже много лет. Она должна продолжать доказывать свою состоятельность через производительность, адаптивность и реальные результаты.
Иначе сетевые эффекты вытеснят качество.
Но если Ньютон сможет построить систему, где репутация обновляется доказательствами, а не наследуется из истории, Policy Marketplace станет не просто местом для обмена политиками.
Он станет рынком, где конкурирует само доверие.
И, возможно, именно этого блокчейну не хватало.
$NEWT #Newt $LAB $TAC
Ньютон не управляет временем. Он управляет тем, как долго решение может оставаться заслуживающим доверия.
Пока я читал документацию Ньютона, заметил деталь, которую легко упустить. Большинство обсуждений сосредоточены на политиках, Rego и PolicyData, но редко задают более простой вопрос: как долго авторизационное решение должно оставаться надежным?
Традиционные блокчейны рассматривают авторизацию как разрешение. После проверки решение обычно считается действительным до момента выполнения. Ньютон подходит к этому иначе. Каждая авторизация — результат оценки конкретного набора данных в конкретный момент, а не истина, которая должна оставаться действительной вечно.
Эта идея прослеживается по всей архитектуре. Статические параметры в data.params могут оставаться неизменными месяцами, тогда как наблюдения из PolicyData могут меняться на каждом блоке. Политика оценивает их вместе, хотя они развиваются по разным временным шкалам. Следовательно, авторизация зависит не только от корректности логики, но и от того, отражает ли информация актуальное состояние мира.
Поэтому я не вижу Decision Lifetime просто как механизм истечения срока. Он отражает более глубокое предположение: каждое решение начинает «стареть» с момента своего создания. Не потому, что политика неверна, а потому что рынки движутся, балансы меняются, а внешние наблюдения продолжают эволюционировать.
Ньютон не пытается продлить срок жизни авторизации. Вместо этого он ограничивает, как долго система должна доверять более раннему решению, прежде чем пересмотреть его заново на основе свежих наблюдений.
Возможно, поэтому время не является реальным фокусом архитектуры Ньютона.
На самом деле Ньютон управляет тем, как долго решение остается заслуживающим доверия.
Даже идеально написанная политика может привести к неверному результату, если тот мир, который она оценила, уже изменился. В Ньютоне безопасность заключается не только в принятии правильного решения, но и в понимании того, когда этому решению больше нельзя доверять.
@NewtonProtocol #Newt $NEWT $LAB $BEE
Пока я читал документацию Ньютона, заметил деталь, которую легко упустить. Большинство обсуждений сосредоточены на политиках, Rego и PolicyData, но редко задают более простой вопрос: как долго авторизационное решение должно оставаться надежным?
Традиционные блокчейны рассматривают авторизацию как разрешение. После проверки решение обычно считается действительным до момента выполнения. Ньютон подходит к этому иначе. Каждая авторизация — результат оценки конкретного набора данных в конкретный момент, а не истина, которая должна оставаться действительной вечно.
Эта идея прослеживается по всей архитектуре. Статические параметры в data.params могут оставаться неизменными месяцами, тогда как наблюдения из PolicyData могут меняться на каждом блоке. Политика оценивает их вместе, хотя они развиваются по разным временным шкалам. Следовательно, авторизация зависит не только от корректности логики, но и от того, отражает ли информация актуальное состояние мира.
Поэтому я не вижу Decision Lifetime просто как механизм истечения срока. Он отражает более глубокое предположение: каждое решение начинает «стареть» с момента своего создания. Не потому, что политика неверна, а потому что рынки движутся, балансы меняются, а внешние наблюдения продолжают эволюционировать.
Ньютон не пытается продлить срок жизни авторизации. Вместо этого он ограничивает, как долго система должна доверять более раннему решению, прежде чем пересмотреть его заново на основе свежих наблюдений.
Возможно, поэтому время не является реальным фокусом архитектуры Ньютона.
На самом деле Ньютон управляет тем, как долго решение остается заслуживающим доверия.
Даже идеально написанная политика может привести к неверному результату, если тот мир, который она оценила, уже изменился. В Ньютоне безопасность заключается не только в принятии правильного решения, но и в понимании того, когда этому решению больше нельзя доверять.
@NewtonProtocol #Newt $NEWT $LAB $BEE
Блокчейн решает одну фундаментальную проблему: сохранять то, что произошло. После подтверждения транзакции состояние становится неизменяемым.
Но @NewtonProtocol указывает на более глубокое ограничение: блокчейн сохраняет результат, а не всегда лежащие в основе него рассуждения.
Транзакция может быть действительной согласно логике смарт-контракта, однако решение, которое позволило её, может больше не быть обоснованным при изменении рыночных условий, данных или состояния.
Так возникает разрыв между корректностью исполнения и легитимностью решения.
Традиционный блокчейн спрашивает:
«Является ли эта транзакция действительной согласно коду?»
Newton спрашивает:
«Является ли решение, лежащее в основе этой транзакции, действительным с точки зрения замысла, политики и состояния на тот момент?»
Это основа модели Decision-Centric Security Model (Безопасности, ориентированной на решения).
Newton не отменяет неизменяемость. Он разделяет то, что должно оставаться финальным, и то, что должно эволюционировать.
Исполнение требует финальности.
Логика решений требует адаптивности.
Поэтому Newton вводит слой политики:
Intent - Policy - Decision - Execution
Замысел задаёт цель. Политика определяет границу авторизации. Решение проверяет, продолжает ли исполнение соответствовать замыслу.
Самая сложная проблема — не изменение политики. Самая сложная проблема — сохранять легитимность решений во времени.
Решение зависит от версии политики, состояния, данных оракулов и контекста. Без них система может доказать, что транзакция произошла, но не может объяснить, почему её одобрили.
Именно здесь становятся критически важными Policy Versioning (Версионирование политики), Decision Provenance (Происхождение решения), Stateful Authorization (Состояниезависимая авторизация) и Decision Reproducibility (Воспроизводимость решений).
Они обеспечивают прослеживаемость решений: восстановление логики, приведшей к авторизации.
Newton вводит более глубокую концепцию: неизменяемые рассуждения.
Блокчейн сделал финальное состояние неизменяемым. Newton делает контекст решения проверяемым во времени.
Будущее децентрализованных финансов будет зависеть не только от неизменяемого исполнения.
Оно будет зависеть от того, остаются ли решения объяснимыми, воспроизводимыми и заслуживающими доверия по мере развития систем.
Протокол Newton не делает блокчейн менее неизменяемым.
Он делает изменения более подотчётными.
$NEWT #Newt $LAB $EVAA
Но @NewtonProtocol указывает на более глубокое ограничение: блокчейн сохраняет результат, а не всегда лежащие в основе него рассуждения.
Транзакция может быть действительной согласно логике смарт-контракта, однако решение, которое позволило её, может больше не быть обоснованным при изменении рыночных условий, данных или состояния.
Так возникает разрыв между корректностью исполнения и легитимностью решения.
Традиционный блокчейн спрашивает:
«Является ли эта транзакция действительной согласно коду?»
Newton спрашивает:
«Является ли решение, лежащее в основе этой транзакции, действительным с точки зрения замысла, политики и состояния на тот момент?»
Это основа модели Decision-Centric Security Model (Безопасности, ориентированной на решения).
Newton не отменяет неизменяемость. Он разделяет то, что должно оставаться финальным, и то, что должно эволюционировать.
Исполнение требует финальности.
Логика решений требует адаптивности.
Поэтому Newton вводит слой политики:
Intent - Policy - Decision - Execution
Замысел задаёт цель. Политика определяет границу авторизации. Решение проверяет, продолжает ли исполнение соответствовать замыслу.
Самая сложная проблема — не изменение политики. Самая сложная проблема — сохранять легитимность решений во времени.
Решение зависит от версии политики, состояния, данных оракулов и контекста. Без них система может доказать, что транзакция произошла, но не может объяснить, почему её одобрили.
Именно здесь становятся критически важными Policy Versioning (Версионирование политики), Decision Provenance (Происхождение решения), Stateful Authorization (Состояниезависимая авторизация) и Decision Reproducibility (Воспроизводимость решений).
Они обеспечивают прослеживаемость решений: восстановление логики, приведшей к авторизации.
Newton вводит более глубокую концепцию: неизменяемые рассуждения.
Блокчейн сделал финальное состояние неизменяемым. Newton делает контекст решения проверяемым во времени.
Будущее децентрализованных финансов будет зависеть не только от неизменяемого исполнения.
Оно будет зависеть от того, остаются ли решения объяснимыми, воспроизводимыми и заслуживающими доверия по мере развития систем.
Протокол Newton не делает блокчейн менее неизменяемым.
Он делает изменения более подотчётными.
$NEWT #Newt $LAB $EVAA
То, что изменило мой взгляд на @NewtonProtocol , и оказалось, что это не AI Agent.
Сначала я думал, что @NewtonProtocol — это протокол, который помогает ИИ выполнять on-chain задачи безопаснее.
Но после прочтения документации я понял: ИИ — лишь верхушка айсберга. Ключевой момент Newton — в authorization.
Newton не начинается с вопроса «Насколько умным является агент?»
Вместо этого: «Что агенту разрешено делать, в каких пределах, и как доказать, что он не выходит за рамки выданных прав?»
Именно поэтому zkPermissions становится центром архитектуры.
Пользователь не передаёт агенту все полномочия целиком. Права определяются policy: какие активы можно использовать, в каких пределах, какие условия должны быть выполнены и когда полномочия заканчиваются.
Агент не обладает authority.
Он может выполнять только delegated execution, когда действие всё ещё находится в подтверждённой политике.
Это самое большое отличие.
Традиционный блокчейн спрашивает: «Эта транзакция корректна?»
Newton добавляет: «Права, создавшие эту транзакцию, всё ещё действительны?»
Одна сторона защищает корректность транзакции.
Другая сторона защищает границы полномочий представителя.
Поэтому я не рассматриваю zkPermissions как просто функцию безопасности для ИИ.
Это способ Newton сделать authorization тем, что можно определить policy, ограничивать условиями и подтверждать с помощью zero-knowledge proofs.
Это не попытка решить все проблемы ИИ.
Они фокусируются на более базовой задаче:
Как можно проверять полномочия делегирования в блокчейне, а не просто доверять им?
Если ИИ станет новым слоем исполнения Web3, контроль прав агента перестанет быть второстепенной функцией.
Он станет инфраструктурой.
#Newt $NEWT $LAB $BEAT
Сначала я думал, что @NewtonProtocol — это протокол, который помогает ИИ выполнять on-chain задачи безопаснее.
Но после прочтения документации я понял: ИИ — лишь верхушка айсберга. Ключевой момент Newton — в authorization.
Newton не начинается с вопроса «Насколько умным является агент?»
Вместо этого: «Что агенту разрешено делать, в каких пределах, и как доказать, что он не выходит за рамки выданных прав?»
Именно поэтому zkPermissions становится центром архитектуры.
Пользователь не передаёт агенту все полномочия целиком. Права определяются policy: какие активы можно использовать, в каких пределах, какие условия должны быть выполнены и когда полномочия заканчиваются.
Агент не обладает authority.
Он может выполнять только delegated execution, когда действие всё ещё находится в подтверждённой политике.
Это самое большое отличие.
Традиционный блокчейн спрашивает: «Эта транзакция корректна?»
Newton добавляет: «Права, создавшие эту транзакцию, всё ещё действительны?»
Одна сторона защищает корректность транзакции.
Другая сторона защищает границы полномочий представителя.
Поэтому я не рассматриваю zkPermissions как просто функцию безопасности для ИИ.
Это способ Newton сделать authorization тем, что можно определить policy, ограничивать условиями и подтверждать с помощью zero-knowledge proofs.
Это не попытка решить все проблемы ИИ.
Они фокусируются на более базовой задаче:
Как можно проверять полномочия делегирования в блокчейне, а не просто доверять им?
Если ИИ станет новым слоем исполнения Web3, контроль прав агента перестанет быть второстепенной функцией.
Он станет инфраструктурой.
#Newt $NEWT $LAB $BEAT
Однажды я неверно понял, как @NewtonProtocol на самом деле полагается на консенсус
Долгое время я думал, что протокол Newton — это исключительно техническая вещь: он просто наследует консенсус лежащей в основе цепочки. Если цепочка надёжна, то Newton надёжен. Такое объяснение звучит разумно, но чем больше я наблюдал реальную автоматизацию на практике, тем яснее понимал: дело упускает нечто более важное, чем сама по себе безопасность — время.
Автоматизация не живёт в «окончательной истине». Она существует в промежутке времени до того, как эта истина окончательно зафиксируется. Намерение не может ждать бесконечно абсолютной окончательности, потому что к тому моменту экономическая возможность уже будет упущена. Поэтому протокол Newton, даже если он не говорит об этом прямо, исходит из того, что консенсус базовой цепочки ведёт себя достаточно предсказуемо, чтобы время оставалось пригодным для работы. Это допущение не о корректности, а о задержках и регулярности финализации.
Есть редко обсуждаемый аспект: каждое намерение в протоколе Newton по сути является ставкой на распределение реорганизаций (reorgs). Когда вы выбираете ожидание N блоков, вы неявно заявляете, что реорганизации глубже N блоков достаточно редки, чтобы с ними можно было мириться. Документация упоминает откаты при reorgs, но не говорит, что весь «альфа» автоматизации возникает благодаря тому, что эти откаты происходят достаточно редко. Когда reorgs становятся непредсказуемыми, автоматизация не становится «неправильной» — она становится экономически бессмысленной.
Отсюда — ещё одно заблуждение, которое я долго держал. Протокол Newton не является по-настоящему нейтральным по отношению к лежащей в основе цепочке. Он не выбирает форки — это правда. Но он заставляет строителей оценивать качество консенсуса через то, как они используют время. Более долгий ожидание покупает безопасность; более раннее действие даёт преимущество. Ни один нижний слой не поглощает этот компромисс за вас.
Поэтому реальный вопрос при развёртывании протокола Newton — не «есть ли у этой цепочки финальность?»
Реальный вопрос: достаточно ли стабильна финальность этой цепочки, чтобы время можно было считать активом?
Если нет, Newton всё равно будет работать, но автоматизация станет не более чем более элегантным cron job.
@NewtonProtocol $NEWT #Newt $LAB $BEAT
Долгое время я думал, что протокол Newton — это исключительно техническая вещь: он просто наследует консенсус лежащей в основе цепочки. Если цепочка надёжна, то Newton надёжен. Такое объяснение звучит разумно, но чем больше я наблюдал реальную автоматизацию на практике, тем яснее понимал: дело упускает нечто более важное, чем сама по себе безопасность — время.
Автоматизация не живёт в «окончательной истине». Она существует в промежутке времени до того, как эта истина окончательно зафиксируется. Намерение не может ждать бесконечно абсолютной окончательности, потому что к тому моменту экономическая возможность уже будет упущена. Поэтому протокол Newton, даже если он не говорит об этом прямо, исходит из того, что консенсус базовой цепочки ведёт себя достаточно предсказуемо, чтобы время оставалось пригодным для работы. Это допущение не о корректности, а о задержках и регулярности финализации.
Есть редко обсуждаемый аспект: каждое намерение в протоколе Newton по сути является ставкой на распределение реорганизаций (reorgs). Когда вы выбираете ожидание N блоков, вы неявно заявляете, что реорганизации глубже N блоков достаточно редки, чтобы с ними можно было мириться. Документация упоминает откаты при reorgs, но не говорит, что весь «альфа» автоматизации возникает благодаря тому, что эти откаты происходят достаточно редко. Когда reorgs становятся непредсказуемыми, автоматизация не становится «неправильной» — она становится экономически бессмысленной.
Отсюда — ещё одно заблуждение, которое я долго держал. Протокол Newton не является по-настоящему нейтральным по отношению к лежащей в основе цепочке. Он не выбирает форки — это правда. Но он заставляет строителей оценивать качество консенсуса через то, как они используют время. Более долгий ожидание покупает безопасность; более раннее действие даёт преимущество. Ни один нижний слой не поглощает этот компромисс за вас.
Поэтому реальный вопрос при развёртывании протокола Newton — не «есть ли у этой цепочки финальность?»
Реальный вопрос: достаточно ли стабильна финальность этой цепочки, чтобы время можно было считать активом?
Если нет, Newton всё равно будет работать, но автоматизация станет не более чем более элегантным cron job.
@NewtonProtocol $NEWT #Newt $LAB $BEAT
Вчера я встретил(а) Ли, когда мы гуляли. Мы часто так встречаемся, чтобы поговорить о Ньютоновском протоколе. Ли спросил(а) меня:
«Почему @NewtonProtocol выбирает конфликт вместо того, чтобы разрешить его заранее?»
Я ответил(а) не сразу. Потому что сам вопрос звучал так, будто он предполагает нечто, чего на самом деле нет внутри системы: идею о том, что конфликт — это то, что можно выбрать, чтобы сохранять или устранять. В Ньютоновском протоколе это работает не так.
В этой системе вывод не переходит напрямую к заключению. Он одновременно порождает несколько гипотез, и поначалу они пересекаются, а не существуют как отдельные возможности. То, что мы называем конфликтом, — это просто состояние неразрешённой запутанности, где ни один исход не стал достаточно различимым, чтобы существовать самостоятельно.
«Разрешить» звучит как активный шаг, но в Ньютоновском протоколе это не всегда разрешено. Это происходит только тогда, когда выбор одной ветви не искажает общую структуру, стоящую за ней. Если это условие не выполняется, то разрешение «заранее» — не «быстрее прогресс», а просто преждевременная приверженность.
Ключевой момент в том, что Ньютоновский протокол не рассматривает конфликт как то, что нужно исправить. Он рассматривает его только как сигнал: ещё не время решать. Отдельного механизма для устранения конфликта нет, потому что конфликт естественным образом исчезает, как только выполнены условия для валидного заключения.
Иными словами, этот подход выбирается потому, что он не приоритизирует скорость достижения заключения. Он приоритизирует корректность тайминга. Если разрешить слишком рано, результат может всё ещё выглядеть правильным локально, но он отражает лишь узкий срез всей структуры.
Оглядываясь на вопрос Ли, я понял(а), что Ньютоновский протокол находится не между конфликтом и разрешением. Он стоит и до того, и до другого. Его волнует только одно: когда система действительно получает возможность превратить несколько возможностей в единый, закреплённый исход. И пока этот момент не наступил, конфликт — это не проблема; это просто знак того, что система ещё не готова доверять никакому заключению.
@NewtonProtocol $NEWT #Newt $LAB $GAIA
«Почему @NewtonProtocol выбирает конфликт вместо того, чтобы разрешить его заранее?»
Я ответил(а) не сразу. Потому что сам вопрос звучал так, будто он предполагает нечто, чего на самом деле нет внутри системы: идею о том, что конфликт — это то, что можно выбрать, чтобы сохранять или устранять. В Ньютоновском протоколе это работает не так.
В этой системе вывод не переходит напрямую к заключению. Он одновременно порождает несколько гипотез, и поначалу они пересекаются, а не существуют как отдельные возможности. То, что мы называем конфликтом, — это просто состояние неразрешённой запутанности, где ни один исход не стал достаточно различимым, чтобы существовать самостоятельно.
«Разрешить» звучит как активный шаг, но в Ньютоновском протоколе это не всегда разрешено. Это происходит только тогда, когда выбор одной ветви не искажает общую структуру, стоящую за ней. Если это условие не выполняется, то разрешение «заранее» — не «быстрее прогресс», а просто преждевременная приверженность.
Ключевой момент в том, что Ньютоновский протокол не рассматривает конфликт как то, что нужно исправить. Он рассматривает его только как сигнал: ещё не время решать. Отдельного механизма для устранения конфликта нет, потому что конфликт естественным образом исчезает, как только выполнены условия для валидного заключения.
Иными словами, этот подход выбирается потому, что он не приоритизирует скорость достижения заключения. Он приоритизирует корректность тайминга. Если разрешить слишком рано, результат может всё ещё выглядеть правильным локально, но он отражает лишь узкий срез всей структуры.
Оглядываясь на вопрос Ли, я понял(а), что Ньютоновский протокол находится не между конфликтом и разрешением. Он стоит и до того, и до другого. Его волнует только одно: когда система действительно получает возможность превратить несколько возможностей в единый, закреплённый исход. И пока этот момент не наступил, конфликт — это не проблема; это просто знак того, что система ещё не готова доверять никакому заключению.
@NewtonProtocol $NEWT #Newt $LAB $GAIA
Впервые я прочитал «предсказуемое выполнение» в @NewtonProtocol docs, и моя первая реакция была не слишком позитивной. Это звучало так, будто система пытается ограничить то, каким будущее вообще может быть. В этом ощущалась какая-то чрезмерная жесткость, словно возможность заранее пропускают через фильтр.
Но эта реакция не выдержала более внимательного прочтения. Суть Newton Protocol не в том, чтобы ограничивать исходы; она в том, чтобы изначально убрать потребность во взаимном доверии. Как только вы предполагаете, что участники друг другу не доверяют, эту нагрузку должна нести система.
В обычных системах выполнения каждое действие порождает неопределенность относительно его результата. Вы спрашиваете не только «запустится ли это», но и «могу ли я доверять тому, что я получу после запуска». Именно на втором вопросе чаще всего и ломается координация, а не на самом выполнении.
«Предсказуемое выполнение» переносит эту зависимость в структуру. Вместо того чтобы доверять актерам, вы доверяете общей прослойке правил, которая определяет, какие исходы считаются допустимыми. Если действие соответствует правилам, результат перестает быть вопросом веры — это становится вопросом проверки.
Но у этого поворота есть и собственное напряжение, и поначалу его легко не заметить. Как только всё должно проходить через общий «язык» (грамматику), всё, что нельзя в нём выразить, по умолчанию становится невидимым. Не обязательно неверным или невозможным — просто нераспознанным.
При этом я не думаю, что цель здесь — контроль или ограничение. Скорее это похоже на попытку сделать координацию возможной в средах, где доверие отсутствует структурно. Система не сужает будущее — она пытается сделать будущее коллективно читаемым.
Если посмотреть под таким углом, Newton Protocol меньше про формирование того, что может случиться, и больше про определение того, что можно согласовать как произошедшее корректно. Он снижает стоимость достижения договоренности, даже если при этом не всё новое сразу становится понятным. Вероятно, именно этот компромисс и составляет реальное пространство дизайна здесь.
@NewtonProtocol $NEWT #Newt $BAS $NEX
Но эта реакция не выдержала более внимательного прочтения. Суть Newton Protocol не в том, чтобы ограничивать исходы; она в том, чтобы изначально убрать потребность во взаимном доверии. Как только вы предполагаете, что участники друг другу не доверяют, эту нагрузку должна нести система.
В обычных системах выполнения каждое действие порождает неопределенность относительно его результата. Вы спрашиваете не только «запустится ли это», но и «могу ли я доверять тому, что я получу после запуска». Именно на втором вопросе чаще всего и ломается координация, а не на самом выполнении.
«Предсказуемое выполнение» переносит эту зависимость в структуру. Вместо того чтобы доверять актерам, вы доверяете общей прослойке правил, которая определяет, какие исходы считаются допустимыми. Если действие соответствует правилам, результат перестает быть вопросом веры — это становится вопросом проверки.
Но у этого поворота есть и собственное напряжение, и поначалу его легко не заметить. Как только всё должно проходить через общий «язык» (грамматику), всё, что нельзя в нём выразить, по умолчанию становится невидимым. Не обязательно неверным или невозможным — просто нераспознанным.
При этом я не думаю, что цель здесь — контроль или ограничение. Скорее это похоже на попытку сделать координацию возможной в средах, где доверие отсутствует структурно. Система не сужает будущее — она пытается сделать будущее коллективно читаемым.
Если посмотреть под таким углом, Newton Protocol меньше про формирование того, что может случиться, и больше про определение того, что можно согласовать как произошедшее корректно. Он снижает стоимость достижения договоренности, даже если при этом не всё новое сразу становится понятным. Вероятно, именно этот компромисс и составляет реальное пространство дизайна здесь.
@NewtonProtocol $NEWT #Newt $BAS $NEX
Войдите, чтобы посмотреть больше материала