Sattar Chaqer

Я просто хочу искренне поблагодарить Binance Square за эти награды 🤍

Со временем я присоединялся к разным кампаниям: проводил часы, читая, писая, редактируя, публикуя и иногда даже сомневаясь, стоит ли это усилий. Поэтому видеть, как награды приходят из кампаний вроде GENIUS OpenLedger SIGN NIGHT и XPL, — правда очень приятно.

Для меня это дело не только в самой награде. Важнее ещё и то, что чувствуешь: твою работу заметили. Каждая публикация требовала времени, каждая кампания чему-то меня учила, и каждый результат давал мне ещё одну причину продолжать.

Я благодарен Binance Square за создание этих возможностей для создателей и также благодарен всем, кто поддерживал мои посты по ходу пути. Независимо от того, понравилось ли вам читать, вы оставляли комментарии или делились — я это ценю.

Такие небольшие моменты действительно напоминают мне, что важна стабильность.

Спасибо, Binance Square. 🙏

#BinanceSquare #creatorpad #Binance @Binance Square Official

Я всё время замечаю, что блокчейны очень хорошо справляются с определением, является ли транзакция действительной, но это не означает автоматически, что транзакцию следует разрешать.

Действительность — это в основном технический вопрос. Правильна ли подпись? Есть ли у кошелька средства? Выполнится ли вызов контракта в соответствии с правилами этой сети? Если да, то блокчейн может обработать транзакцию.

Но финансовым системам обычно нужен второй тест.

Транзакция может быть полностью корректной onchain и при этом нарушать правило казначейства, мандат фонда, ограничения эмитента или политику авторизации, привязанную к этому капиталу. Именно в этом различии и построен Newton.

Для меня это один из самых ясных способов понять протокол.

Newton не заменяет расчёты блокчейна. Он добавляет слой перед расчётами, который задаёт другой вопрос — не только «может ли эта транзакция выполниться», но и «разрешена ли эта транзакция фактически в соответствии с правилами, которые к ней привязаны?»

Это гораздо более жёсткий стандарт, чем просто проверка действительности.

@NewtonProtocol $NEWT #Newt $TAC $LAB

#BinanceTurns9 Binance исполняется 9 — создавайте вместе

2,1 года на Binance, и путешествие становится только лучше. С 9-й годовщиной платформу, которая никогда не перестаёт строить!

То, что особенно выделяется во мне в Ньютоне, это то, что он рассматривает авторизацию как реальный транзакционный процесс, а не как нечто туманное вроде шага «одобрения» где-то до расчетов. В обычном ончейн-процессе пользователь подписывает транзакцию, отправляет её в блокчейн, а сеть проверяет, действительна ли она в рамках правил протокола. Если всё проходит, выполняется, а записи расчетов фиксируют результат. Основная логика сосредоточена на уровне выполнения. Ньютон добавляет ещё один слой в жизненный цикл. Транзакция не движется напрямую от пользовательского намерения к расчетам. Сначала она проходит через процесс авторизации: действие предлагается, оценивается на соответствие политике, согласованной сетью, превращается в подписанный результат и затем снова проверяется до того, как выполнение будет разрешено. Эта последовательность важна, потому что она придаёт авторизации реальную структуру. Предлагаемое действие входит как намерение (intent). Затем это намерение проходит оценку относительно соответствующих правил. Сеть достигает консенсуса относительно исхода. Результат становится подписанным подтверждением. После этого механизм принуждения (enforcement) решает, может ли транзакция быть выполнена. Интересно, что Ньютон говорит не только о том, что транзакции нужно проверять прежде чем значение начнёт двигаться. Он определяет, как именно происходит эта проверка и как выглядит результат этого процесса до того, как вообще начнутся расчеты. Благодаря этому авторизация воспринимается не просто как общий тезис о соблюдении требований (compliance), а как инфраструктура со своим собственным рабочим процессом внутри жизненного цикла транзакции.

@NewtonProtocol $NEWT #Newt $TLM $VANRY

Что Ньютон добавляет onchain?

Всем добро пожаловать

Всем добро пожаловать

Одна вещь, которая выделяется для меня в onchain-финансах, — это то, как часто комплаенс описывают как процесс, а не как доказанный результат. Платформа говорит, что она отсканировала кошелёк. Менеджер сейфа заявляет, что он выполнил мандат. Протокол утверждает, что он проверил соответствующие правила перед тем, как разрешить действие. В каждом случае пользователя всё равно просят довериться тому, что нужные контроли существовали где-то в рамках рабочего процесса. Вот к чему я снова и снова возвращаюсь. Обещание комплаенса сообщает вам о том, что говорит команда: что произошло. Оно не обязательно доказывает, что правило действительно было применено к транзакции, которая передвинула стоимость. Подход Ньютона ощущается иначе, потому что он приближает комплаенс к самой транзакции. Вместо того чтобы просто говорить, что проверки были выполнены, Newton создан так, чтобы выдать подписанный результат авторизации, привязанный к конкретному намерению транзакции до выполнения. Иными словами, система не только описывает контроли вокруг транзакции. Она создаёт верифицируемую запись того, что политика была оценена до того, как стоимость переместилась. Эта разница важнее, чем может показаться. Обычно обещание живёт в процессном документе, внутреннем рабочем процессе или на дэшборде. Чек/квитанция живёт намного ближе к реальному пути транзакции. Она становится доказательством того, что транзакцию проверили по заданной политике в заданный момент. Для меня именно это — ключевой сдвиг, который делает Newton. Он переводит комплаенс из того, что «платформа заявляет, что сделала», в то, что инфраструктура действительно может показать. И в системе, построенной вокруг перемещения стоимости без требования доверия, это выглядит как гораздо более жёсткий стандарт, чем просто «мы провели проверки».

@NewtonProtocol $NEWT #Newt $LAB $VANRY

Что важнее всего в комплаенсе?

Я всё чаще замечаю, что крипто-приложения часто рассматривают проверки пользователей как нечто, происходящее до транзакции, а не как то, что формирует саму транзакцию.

Платформа решает, может ли кошелёк получить доступ к функции, войти на рынок или пройти определённый сценарий продукта. После того как это решение об доступе принято, реальное действие в onchain обычно трактуется как отдельный шаг. Пользователь проходит через «парадную дверь», но сам маршрут транзакции продолжает вести себя так, будто эти условия больше не имеют значения.

Чем больше я смотрю на архитектуру Newton, тем больше я думаю, что такое разделение — структурная слабость.

Важно не только то, проверила ли платформа пользователя раньше по маршруту. Важно, может ли транзакция оценить релевантные условия пользователя в момент, когда она вот-вот будет выполнена. Именно этот сдвиг я вижу в Identity Oracle от Newton.

Вместо того чтобы рассматривать пользовательскую информацию как нечто, значимое лишь во время контроля доступа, Newton превращает выбранные атрибуты пользователя в входные данные для авторизации. Условия соответствия по региональному статусу и другие правила, связанные с пользователем, могут стать частью самого процесса одобрения, так что система больше не спрашивает только то, попал ли пользователь в продукт. Она может спросить, должна ли эта конкретная транзакция быть разрешена в рамках этой конкретной политики.

Это меняет роль этих проверок внутри onchain-финансов.

Они перестают быть просто «воротами» для приложения.

Они становятся частью решения по транзакции.

Для меня это — главное. Newton пытается приблизить правила, связанные с пользователем, к тому месту, где реально движется ценность, при этом сохраняя чувствительные персональные детали вне публичного слоя транзакций.

Это делает модель намного более полезной.

Не потому, что это превращает крипто в систему идентификации.

А потому, что это даёт onchain-приложениям способ рассматривать условия пользователя как программируемую логику транзакций, а не оставлять их отдельным offchain-шагом, который перестаёт иметь значение, как только приложение открыто.

@NewtonProtocol $NEWT #Newt $HMSTR $LAB

Где условия доступности пользователя должны значить больше всего в on-chain финансах?

Давай, займём его

Я всё ещё замечаю, что криптоприложения путают ограничения интерфейса с реальным исполнением. Фронтенд может скрыть кнопку, заблокировать регион или запретить кошельку использовать функцию. На поверхности это выглядит как соблюдение требований. Пользователь видит ограничение, а приложение может указать на видимый слой управления, и продукт может сказать, что у него есть проверки. Но всё это не означает, что сама по себе транзакция действительно регулируется. Если смарт-контракт всё ещё можно вызвать напрямую, то правило по сути не находится там, где движется ценность. Оно живёт на уровне приложения поверх контракта. Это может уменьшить случайные злоупотребления, но не создаёт реальное принуждение на уровне транзакций.

Это слабое место, которое пытается решить Newton. В логике Newton соответствие требованиям не должно зависеть от того, остаётся ли пользователь внутри одобренного интерфейса. Оно должно применяться до расчётов — в тот момент, когда транзакция авторизуется. Именно поэтому для меня важна интеграция Persona. Дело не только в том, чтобы подтвердить личность или место проживания. Важно взять эти атрибуты и использовать их прямо в пути авторизации, чтобы транзакцию можно было оценить до выполнения, а не просто отфильтровать на фронтенде.

И это полностью меняет стандарт. Контроль только на фронтенде говорит: «Мы попытались остановить это действие в приложении». Контроль на уровне транзакций говорит: «Это действие не может выполниться, пока не удовлетворит политике». Это гораздо более сильное утверждение.

Потому что в ончейн-финансах реальный вопрос не в том, заблокировал ли интерфейс клик. Реальный вопрос — открыт ли был путь к контракту. Если он был открыт, правило соответствия всегда можно было обойти. Именно поэтому я думаю, что архитектура Newton важна. Она переносит соблюдение требований с уровня UI ближе к тому месту, где транзакции действительно становятся реальными. В крипто смарт-контракт — это финальные ворота. Если соответствие не доходит до этого слоя, оно всё ещё находится на один шаг слишком далеко от того, что оно должно контролировать.

@NewtonProtocol $NEWT #Newt $TLM $ARPA
Где именно должно обеспечиваться соблюдение требований в крипто?

Я всё чаще замечаю, что комплаенс в крипто по-прежнему воспринимают как бумажную процедуру вокруг транзакции, а не как логику, встроенную прямо в саму транзакцию.

Эта модель имела смысл в более старых финансовых системах, где ограничения на одобрения и проверки могли находиться в отдельных операционных слоях. Но ончейн-финансы работают иначе. Смарт-контракты исполняются автоматически, ценность переводится быстро, и транзакции не «замирают», чтобы команда комплаенса вручную интерпретировала политику постфактум.

Если расчёты уже программируемы, то комплаенс, вероятно, тоже должен стать программируемым.

И именно это я нахожу особенно интересным в Newton Protocol.

Newton не рассматривает комплаенс как внешнюю чек-лист-проверку, прикреплённую к транзакции. Он превращает политику в то, что система может оценивать до исполнения. Используя policy as code с инструментами вроде Rego и Open Policy Agent, правила транзакций можно записывать как машинно-читаемую логику — вместо того, чтобы прятать их в PDF внутренних процедурах или «зашивать» в жёсткую логику продукта.

Это полностью меняет роль комплаенса.

Лимит на перевод становится программируемой логикой.

Ограничение по юрисдикции становится программируемой логикой.

Требование к допустимости инвестора становится программируемой логикой.

Проверка санкций становится программируемой логикой.

Когда эти правила выражены в виде кода, комплаенс перестаёт быть разрозненным операционным процессом и начинает вести себя как инфраструктура. Это то, что программное обеспечение может последовательно оценивать до того, как ценность начнёт перемещаться.

Для меня это и есть главный сдвиг, который продвигает Newton.

Смарт-контракты сделали расчёты программируемыми.

Newton пытается сделать то же самое для политики.

И если ончейн-финансы собираются поддерживать более серьёзные финансовые активности, то комплаенс, вероятно, не сможет навсегда оставаться бумажной процедурой, существующей вне системы.

@NewtonProtocol $NEWT #Newt $M $US

Что является самым большим узким местом для комплаентного ончейн-финансирования?

Присоединяйтесь к живому @RaDhika_08

Раньше я думал, что авторизация и расчёты — это просто два разных названия одного и того же процесса транзакций. Чем глубже я разбирался в финансовой инфраструктуре, тем больше понимал: они решают совершенно разные задачи.

Расчёты — это заключительное перемещение ценности. Они обновляют записи балансов, фиксируют изменения владения и задают транзакции её конечное состояние в блокчейне. Именно здесь публичные блокчейны годами демонстрировали свою силу.

Авторизация выполняет другую роль.

Она происходит до исполнения и сводится к одному вопросу: должна ли эта транзакция продвигаться дальше? Вместо того чтобы фиксировать результат, авторизация оценивает транзакцию ещё до того, как расчёты вообще начнутся.

Традиционные платёжные сети всегда разделяли эти обязанности. Платёжный запрос сначала авторизуют, а затем рассчитываются по нему. Каждый этап выполняет свою отдельную функцию, позволяя финансовым системам принимать решения ещё до того, как ценность перейдёт из рук в руки.

Меня особенно заинтересовало то, что Newton Protocol применяет тот же архитектурный принцип к onchain-финансам.

Вместо изменения того, как работает расчёт в блокчейне, Newton вводит выделённый слой авторизации, который оценивает намерение транзакции до исполнения. Расчёты продолжают делать то, что у них уже получается лучше всего, а авторизация становится отдельной ответственностью в рамках жизненного цикла транзакции.

Чем больше я об этом думаю, тем больше понимаю, что это разделение имеет смысл.

Расчёты отвечают на вопрос: что произошло.

Авторизация отвечает на вопрос: должно ли это произойти.

Это разные вопросы — и им нужна разная инфраструктура.

Понимание этого различия изменило мой взгляд на архитектуру блокчейна. Будущее onchain-финансов может зависеть не только от улучшения расчётов. Оно также может зависеть от признания того, что авторизация и расчёты работают лучше всего, когда они дополняют друг друга, а не пытаются выполнять одну и ту же работу.

@NewtonProtocol $NEWT #Newt

Какой слой более важен для будущего on-chain финансов?