W Shakespeare

Одна деталь в WebSocket-дизайне GRVT привлекла мое внимание.
sequence_number имеет смысл только в рамках одного соединения WebSocket. Если номер скачет, это говорит вашему соединению лишь о том, что были пропущены данные. Ничего не сообщается о том, что происходит с любым другим клиентом, подключенным к GRVT.
Это становится особенно интересно, когда разработчики строят поверх API GRVT исполняющие движки или количественные торговые системы.
Каждая интеграция поддерживает собственное состояние рынка. Обнаружение пропущенных обновлений, запрос свежего снимка и решение о том, когда это состояние снова считается валидным, — все эти обязанности выполняются внутри самой интеграции. GRVT распространяет события рынка, но не решает, корректно ли торговая система восстановила свое состояние рынка.
Отсюда меняется то, где «владеет» состоянием рынка.
Вместо того чтобы поддерживать единое авторитетное состояние для каждого подключенного к системе участника, GRVT перекладывает ответственность за поддержание собственного состояния на каждую интеграцию. Разные торговые системы могут потреблять одни и те же события рынка, но при этом хранить разные локальные состояния, потому что каждая использует свою политику восстановления после обнаружения разрыва.
Эта архитектура естественным образом ведет к концепции «Ownership состояния».
Владение состоянием рынка также означает владение инженерными решениями, лежащими в его основе. Каждая команда может оптимизировать синхронизацию, восстановление и валидацию под свой рабочий процесс, а не наследовать единую модель от биржи. GRVT нужно лишь доставлять согласованные события рынка. То, как эти события превращаются в доверенное состояние рынка, намеренно оставлено на усмотрение каждой интеграции.
Сделав sequence_number локальным для каждого соединения WebSocket, GRVT оставляет состояние рынка каждой API-интеграции, а не рассматривает его как часть самой биржи.
По мере того как все больше торговых систем подключаются через API GRVT, концепция Ownership состояния позволяет бирже оставаться сосредоточенной на распространении событий рынка, вместо того чтобы расширяться в область управления состоянием, специфичного для приложений. Задача — продолжать обслуживать все более разнообразные торговые сценарии, не постепенно перенимая логику приложения, которая относится к каждой интеграции.
$LAB @grvt_io #grvt

Khi deploy một Policy bằng CLI trên Newton Protocol, policy_params cuối cùng phải được chuyển thành Flat JSON đúng với params_schema.json. Nếu giữ nguyên Nested JSON, quá trình Schema Validation sẽ thất bại và Policy sẽ không thể pass evaluation.
Điều làm mình chú ý là CLI vẫn làm việc với Nested JSON trong suốt workflow. Chỉ đến khi Policy được evaluate, toàn bộ data mới buộc phải xuất hiện dưới dạng Flat JSON.
Theo mình, đây không phải là một quy định dành cho CLI. Nó là một quy định dành cho Policy layer.
Trước khi đi vào Policy, mọi representation đều phải được chuyển về cùng một hình thức. Translation cost vẫn tồn tại, nhưng chỉ xuất hiện tại boundary của system. Sau điểm đó, Policy không còn cần biết data đến từ CLI hay bất kỳ integration nào khác. Điều duy nhất còn lại là data có khớp với schema đã công bố hay không.
Đó cũng là lúc Serialization Neutrality bắt đầu hình thành.
Điều được giữ trung lập không phải cách mỗi tool serialize data, mà là cách Policy tiếp nhận data. Mọi representation differences đều phải được loại bỏ trước khi evaluation bắt đầu. Vì vậy, mỗi integration mới chỉ cần tự xử lý serialization của mình, thay vì buộc Policy layer phải thích nghi với thêm một representation mới.
Lúc này, thách thức của Newton Protocol không nằm ở việc hỗ trợ thêm nhiều tools. Thách thức nằm ở việc tiếp tục giữ được Serialization Neutrality khi ecosystem mở rộng. Chỉ cần một integration được phép vượt qua boundary với một representation riêng, Policy layer sẽ dần phải hiểu nhiều representations khác nhau và chính Serialization Neutrality cũng sẽ mất đi ý nghĩa ban đầu.
$B $BEAT $NEWT #Newt @NewtonProtocol

Несколько дней назад, я заметил интересную деталь, изучая GRVT. Разным API-ключам можно назначать разные разрешения. Одним разрешено размещать заказы. Другие могут переводить активы. Третьи ограничены доступом только для чтения. Не ожидается, что один ключ будет уметь всё.
Вместо того чтобы рассматривать разрешения как удобную функцию, GRVT использует их для разделения полномочий перед тем, как начнётся любая операция.
Каждая новая возможность на GRVT не становится автоматически доступной для каждого API-ключа. Торговля, финансирование, вывод средств и управление аккаунтом — всё это остаётся за отдельными областями разрешений. В результате у каждой учётной записи есть только те полномочия, которые ей явно предоставили, а не все возможности, прикреплённые к аккаунту.
Это меняет то, что происходит, когда учётные данные оказываются скомпрометированы.
Инцидент ограничивается областью разрешений именно этого ключа, а не распространяется на весь аккаунт. Поэтому добавление новых API-возможностей не увеличивает автоматически последствия уже существующей компрометации: вновь введённые полномочия остаются изолированными от учётных данных, которые их никогда не получали.
Именно здесь начинает проявляться подход к снижению радиуса взрыва.
Когда полномочия получают возможность расти через независимые области разрешений вместо того, чтобы накапливаться за одной и той же учётной записью, платформа может продолжать расширяться, не заставляя риск расти тем же способом. Новые возможности увеличивают то, что GRVT может делать, при этом каждая граница разрешений продолжает удерживать последствия собственной компрометации.
Если оглянуться назад, эти API-разрешения больше не кажутся просто удобством для разработчиков. Они показывают, как GRVT ожидает, что платформа будет развиваться. По мере появления всё большего числа API, продуктов и рабочих процессов полномочия не обязательно должны сходиться в одни-единственные учётные данные. Если этот принцип сохранится, снижение радиуса взрыва будет масштабироваться вместе с GRVT, позволяя @grvt_io расширяться без того, чтобы каждая новая возможность становилась ещё одним общим источником риска.
$TAG $LAB #grvt

При использовании набора Policy Pack в протоколе Newton разработчику не нужно самостоятельно собирать или развертывать Data Oracle. Data Oracle уже развернут. Осталось лишь сделать ссылку на PolicyData Address, настроить необходимые Parameters и начать писать Policy.
При таком рабочем процессе я думаю, что Newton Protocol меняет тип Cost, который должен оплачивать разработчик.
Если бы разработчику приходилось собирать весь Data Oracle целиком, то при каждом обновлении или Maintenance уходит часть времени, которое можно было бы потратить на улучшение Decision. Каждый час, потраченный на Maintenance, означает меньше времени, чтобы пробовать новые Ideas.
Policy Packs меняют это на обратное.
Когда Infrastructure уже поддерживается, Maintenance перестаёт быть бременем, которое каждый разработчик вынужден повторять. Время возвращается на проектирование Policy, настройку Business Logic и тестирование новых Decisions. Самый большой Cost больше не связан с эксплуатацией Infrastructure — он смещается в сторону поиска более удачного способа интерпретировать данные.
Именно тогда начинает меняться Opportunity Cost.
Час, который не нужно тратить на Maintenance, означает ещё один час на то, чтобы попробовать Policy, проверить Assumption или оптимизировать Decision. Ценность Policy Packs заключается не только в снижении объёма работы, а в переносе времени на те активности, которые дают гораздо больше различий.
С этой точки зрения я вижу, что Newton Protocol предоставляет не только готовые Policy Packs. Он также сдвигает Opportunity Cost разработчика от повторяющихся задач в сторону Innovation. Если всё больше builders будут начинать с общего слоя Infrastructure, то преимущество @NewtonProtocol s будет накапливаться в качестве Decision — поскольку всё больше ресурсов переводится с Maintenance на Innovation #Newt $SKL $LAB $NEWT

Изучаем Chaining Multiple Data Oracles в документации Newton Protocol; я был весьма удивлён тем, что Data Oracle никогда не делает.
Каждый Data Oracle возвращает только Facts вроде risk_score, is_collapsed или tvl_drawdown. Они не выносят заключение о том, следует Allow или Deny ту или иную транзакцию. Эта часть остаётся за Rego Policy.
Это не только разделение ответственности.
Но и демонстрация того, что Newton Protocol отделяет Fact от Judgment.
Когда Fact больше не привязан к фиксированному Judgment, один и тот же risk_score может по-разному интерпретироваться множеством Policies с совершенно разными критериями. Одна policy считает, что 60 достаточно безопасно для Allow, другая же принимает только значения от 80 и выше. Сам Fact остаётся тем же, меняется только Judgment.
Поэтому Fact больше не завершает свою роль после первого использования. Когда появляется ещё одна Policy, тот же самый Fact снова интерпретируется по новому стандарту, чтобы создать другое Decision без повторного сбора данных с нуля.
Значение Fact тоже больше не ограничивается первым применением.
Каждая новая Policy добавляет новый контекст, чтобы старый Fact продолжал приносить пользу. Именно это разделение Fact и Judgment и создало Fact Appreciation Mechanism.
Самое интересное, что я заметил: Newton Protocol не пытается заставить Data Oracles генерировать больше Facts. @NewtonProtocol делает так, что каждый Fact продолжает приносить ценность после того, как уже был создан. Когда в экосистеме появляются новые Policies, старые Facts продолжают переосмысливаться по новым стандартам. Если этот процесс будет повторяться, Fact Appreciation Mechanism приведёт к тому, что ценность данных будет расти вместе с развитием всей экосистемы, а не просто остановится на первом использовании.
#Newt $EVAA $NEWT

Перед развертыванием policy протокол Newton Protocol требует пройти три шага: unit test для Rego Policy, отдельное тестирование каждого WASM Oracle, а затем симуляцию всего policy с данными из реального мира.
Эти шаги не просто проверяют отдельные компоненты по очереди. Их последовательность устроена так, чтобы постепенно сужать круг неизвестного в отношении конкретного decision. После раундов валидации область того, что придется ждать до deployment, чтобы подтвердить, становится все меньше.
Как правило, deployment — это момент, когда становится ясно, работает ли decision так, как ожидалось. Несмотря на множество раундов тестирования, production остаётся тем местом, где многие команды учатся тому, чего они не могли знать заранее.
Но в Newton Protocol большая часть этого процесса происходит прямо в разработке. Rego Policy, WASM Oracle и данные объединяются, чтобы симулировать весь decision до того, как произойдет deployment. Это заставляет думать, что Newton Protocol стремится к архитектуре Pre-validated Deployment.
В таком случае deployment в основном превращается в шаг релиза уже валидированного decision, а не в место, где система продолжает учиться тому, верное это decision или нет.
Особенно заметно то, что Newton Protocol, похоже, меняет роль Deployment. Когда Deployment больше не является источником создания валидации, он перестает быть и тем местом, где система учится, является ли Decision правильным или ошибочным.
Возможно, именно в этом и заключается смысл архитектуры Pre-validated Deployment. Это не обязательно более полный процесс тестирования, а архитектурный принцип, который смещает валидацию из Production. Мне довольно интересно, будет ли это лишь выбором Newton Protocol или со временем станет подходом, который будет всё чаще использоваться при построении многих программных систем в будущем? $EVAA $NEWT #Newt @NewtonProtocol

На днях я смотрел раздел Writing Data Oracles в Newton Protocol и наткнулся на довольно интересную вещь: если HTTP Fetch завершается ошибкой, Data Oracle нельзя просто проигнорировать или вернуть данные по умолчанию. Вместо этого Oracle возвращает namespaced error, чтобы Rego Policy могла сразу запретить Decision.
Похоже, Newton Protocol меняет роль failure в процессе генерации Decision. Раньше ошибка была просто информацией для разработчика, которую тот читает после завершения работы системы. Теперь, как только Data Oracle возвращает namespaced error, состояние сбоя становится частью данных, которую Rego Policy должна оценить. Decision не останавливается из‑за того, что в системе произошла ошибка. Оно останавливается потому, что система только что получила новый сигнал.
И тут мне внезапно стало ясно: Newton Protocol выбирает Fail-Closed Architecture. Эта архитектура не пытается скрыть то, что еще неизвестно, чтобы продолжать выполнение. Вместо этого она расширяет само понятие Evidence. Ценность имеют не только данные, которые успешно удалось собрать. То, что Data Oracle не смог подтвердить информацию, тоже становится разновидностью Evidence, которую Rego Policy обязана оценить.
Когда failure рассматривается как Evidence, Decision больше не имеет права его игнорировать. Decision не может продолжать работу только потому, что остальные данные выглядят правдоподобно. Он должен отражать все Evidence, которыми располагает система, включая то, что невозможно подтвердить. Если Evidence недостаточно, чтобы обосновать вывод, Decision не имеет права сам «дорисовать» недостающее с помощью предположений.
Если смотреть с этой точки зрения, Fail-Closed Architecture в Newton Protocol уже не просто механизм обработки failure. Она заставляет каждое Decision быть честным по отношению к тому Evidence, которое у меня реально есть, а не к тому Evidence, которого система ожидала бы иметь. #Newt $LAB $TRIA $NEWT @NewtonProtocol

Протокол Newton был разработан Magic Labs — командой, стоящей за многими продуктами, соответствующими требованиям Enterprise Standards, таким как SOC 2 Type II и ISO 27001.
Эти Enterprise Standards требуют, чтобы организация имела достаточно строгий процесс разработки для управления изменениями, оценки рисков и гарантии того, что каждое решение можно проследить на протяжении всего жизненного цикла разработки.
Более того, этот процесс разработки должен служить не только одному релизу. Он должен быть достаточно согласованным, чтобы использоваться в течение многих релизов, независимо от того, как постоянно меняется продукт.
По моему мнению, когда команда Magic Labs годами работает в рамках одного и того же процесса разработки, этот процесс перестаёт быть просто внутренним workflow. Он становится способом по умолчанию для того, чтобы команда подходила к задачам и принимала решения. Именно поэтому я считаю, что при разработке протокола Newton Magic Labs привнёс не только Enterprise Standards, а именно Process-First Mindset (мышление, ставящее процесс во главу угла).
С таким подходом каждый релиз протокола Newton по-прежнему может быть сильно отличающимся, поскольку требуется решать новые задачи. Но все изменения исходят из одного и того же фреймворка решений, из одного и того же способа оценки рисков и из одного и того же инженерного процесса.
Эта согласованность заключается не в отдельных релизах, а в том, как именно Newton Protocol был спроектирован (Engineered). Когда @NewtonProtocol продолжит расширяться, новые функции не станут «пазлами», собранными из разных инженерных философий. Они по-прежнему будут строиться на той же ментальной основе, которая сформировала протокол с самого начала.
Наверное, самое ценное, что команда Magic Labs принесла с собой при разработке протокола Newton, — это Process-First Mindset. Он помогает протоколу Newton продолжать развиваться и расширяться, сохраняя при этом согласованность в том, как он был спроектирован.#Newt $LAB $NEWT

Прочитайте Integration Guide от Newton Protocol — есть одна деталь, которая показалась мне довольно странной: Data Oracle можно написать на JavaScript, Rust или Python. Сначала я подумал, что @NewtonProtocol просто пытается расширить выбор для builders.
Но примечательно тут не то, какой это язык программирования. А то, что независимо от языка в итоге всё компилируется в один и тот же WIT-интерфейс.
Тогда я понял: JavaScript, Rust или Python — лишь внешнее проявление. Самое быстрое изменение в каждом экосистеме ещё никогда не было связано с языком программирования — это была инновация. В Python постоянно появляются новые AI-пакеты. В Rust есть оптимизации по производительности и безопасности. JavaScript развивается очень быстро на уровне приложений и инструментов. У каждой экосистемы свой темп эволюции, и никто не знает, откуда придёт следующее прорывное решение.
Если протокол жёстко привязан к экосистеме конкретного языка программирования, он невольно ставит на то, что самые важные инновации будут продолжать появляться именно там. Всё, что приходит извне, либо придётся переносить, либо оно никогда не попадёт в систему.
Newton Protocol, похоже, выбрал позицию в стороне от этой гонки и принял стратегию Innovation Neutrality. Newton Protocol не стандартизирует, где именно создаются инновации. Единственное, что стандартизировано — это то, как инновации появляются перед протоколом через общий интерфейс.
Тогда эволюция Data Oracle не зависит от какого-то одного языка программирования или единственного сообщества разработчиков. Прорыв, появившийся в Python, Rust или JavaScript, может стать частью Newton Protocol. Это и есть преимущество позиции Innovation Neutrality. Newton Protocol не нужно ставить будущее на какую-либо одну экосистему языков программирования. #Newt $LAB $HMSTR $NEWT

Прочитав раздел Verifiable Credentials в документации Newton Protocol, я снова остановился на одной совсем маленькой детали.
Посреди множества SDK-методов, предназначенных для Identity, Verification и Credential Management, номер @NewtonProtocol по-прежнему выделяет целый метод под unlinkApp().
На первый взгляд, это просто API для отзыва связи между пользователем и приложением.
Но чем больше я об этом думаю, тем больше мне кажется, что само его наличие, вероятно, более примечательно, чем выполняемая им функция.
Система действительно нуждается в unlinkApp(), только если с самого начала команда приняла, что у пользователей всегда есть Exit Rights.
Если это предположение верно, то Newton Protocol, возможно, преследует стратегию в духе Voluntary Lock-in.
Звучит несколько противоречиво.
Обычно Lock-in создают, постепенно повышая Switching Costs, из-за чего пользователям все сложнее покинуть систему. Но при Voluntary Lock-in возможность уйти всегда остается.
Единственное, что удерживает пользователя, — это его собственное решение.
Это также означает, что Newton Protocol фактически почти отказывается от одного из самых распространенных Competitive Moats Web3-платформ.
Поскольку Exit всегда сохраняется, Newton Protocol не может полагаться на Switching Costs, чтобы удерживать Users.
По моему мнению, именно в этом и стоит поразмышлять.
Если Voluntary Lock-in действительно является вариантом в Product Design, то каждый Active User больше не просто показатель роста.
Они становятся доказательством того, что даже когда Exit всегда есть, люди все равно продолжают выбирать Stay.
Иными словами, unlinkApp() может быть не просто методом SDK.
Это может быть небольшой сигнал о том, что Newton Protocol не рассматривает Lock-in как результат барьеров, а как следствие повторяющихся со временем добровольных решений.
#Newt $MAGMA $LAB $NEWT

"Рынок действительно существует только тогда, когда обе стороны начинают находить друг друга."
Эта мысль внезапно пришла мне в голову, когда я узнал, что Newton Protocol строит Policy Marketplace.
Сначала я думал, что это просто место, где билдеры могут находить и интегрировать политики.
Но если смотреть внимательнее под углом Platform Economics, я вижу, что это больше похоже на Two-Sided Market, а не на обычный маркетплейс.
Одна сторона — Supply. Они упаковывают безопасность, соответствие требованиям (compliance) и юридическую экспертизу в Policy-as-Code, которые можно многократно использовать.
Другая сторона — Demand. Они не покупают политику просто потому, что она им нравится. Им нужны доверие и соответствие требованиям, без того чтобы каждый раз с нуля самим строить все для разработки Vault, RWA-протокола, Stablecoin или AI Agent.
В таком рынке ценность определяется не тем, сколько на нем Supply и сколько Demand.
Она определяется Matching Efficiency.
Если качественная политика не доходит до того билдерa, который в ней действительно нуждается, то эта экспертиза почти не создает экономической ценности. И наоборот: если билдер не находит подходящую политику, он возвращается к самостоятельной разработке, и тогда Demand так и не превращается в сделки.
Когда Matching Efficiency растет, меняется поведение обеих сторон. Supply получает стимул создавать больше Policy-as-Code, потому что выше вероятность использования и, как следствие, больше revenue. Demand тоже стремится приходить на маркетплейс раньше, чем начинать разрабатывать самостоятельно, поскольку стоимость поиска и интеграции становится все ниже.
Возможно, именно в этом и заключается то, что мне кажется особенно интересным в Policy Marketplace от Newton Protocol. @NewtonProtocol — это не просто связь между Supply и Demand. Это еще и попытка оптимизировать Matching Efficiency, чтобы сама способность соединять две стороны стала источником ликвидности и помогала всему Two-Sided Market работать более эффективно.
#Newt $LAB $NEWT