Salman49

Salman

Один пролив. Четыре рынка. Почему каждый инвестор в криптовалюты должен следить за Ормузом.

Большинство криптоинвесторов не следят за судоходными маршрутами. Обычно я тоже. Но Ормузский пролив — одно из тех мест, где события вне криптовалют могут быстро добраться до вашего портфеля.

Недавние данные показывают, что трафик судов через Ормуз сократился примерно на 52%, а Brent поднялась выше $85 за баррель на фоне опасений сбоев поставок. Одновременно сообщения о росте рыночной волатильности вызвали массовые ликвидации на рынках криптовалют, напоминая трейдерам, как быстро глобальные события способны менять настрой по отношению к риску.

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

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

Если вы торгуете криптовалютой, наблюдать только за криптовалютой больше недостаточно. Иногда первый сигнал появляется за сотни миль от любой блокчейн-платформы. NFA.DYOR.

Самый большой финансовый риск, возможно, кроется в правилах, которые никто не проверяет

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

Причем та же идея последовала за мной и в документации Newton.

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

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

Newton отделяет логику политики от конфигурации, чтобы организации могли обновлять data.params, не переписывая саму Policy. В документации также вводится --expire-after: параметры могут истекать после заданного числа блоков. Я не воспринимаю это как удобную функцию. Я вижу в этом признание того, что предположения вчерашнего дня со временем становятся риском сегодняшнего.

Чем больше я об этом думаю, тем больше это ощущается как проблема систем, а не финансов. Надежные системы не строятся, когда один раз принимают идеальные решения. Они создаются за счет пересмотра невидимых правил, которые продолжают принимать решения еще долго после того, как все забыли, что они вообще существуют.
NFA.DYOR. #newt $NEWT @NewtonProtocol

Мы создавали более быстрые финансовые системы. Возможно, мы забыли построить брандмауэры.

Несколько дней назад я делал онлайн-платёж. Сумма была небольшой, но платёж всё равно приостановился из‑за дополнительной проверки. В тот момент это показалось излишним. Приложение уже знало мой аккаунт, мой баланс и получателя. Так зачем меня останавливать?

Этот вопрос вернулся ко мне, пока я читал документацию Newton. Я дошёл до этапа, где Intent оценивается ещё до выполнения. Operator Network проверяет Policy, формирует BLS Attestation, а PolicyClient подтверждает это доказательство, прежде чем транзакция сможет продолжиться. В первый раз, когда я это прочитал, мне показалась, что это просто ещё одна система авторизации.

Затем я добрался до VaultKit и Shield Contracts, и одна деталь заставила меня остановиться и задуматься. Защищённое действие не пересылается, если операторы его отклоняют, если не набирается требуемый кворум 67%, если attestation истекает, либо если валидация Shield не проходит. Именно в этот момент моё первое впечатление изменилось.

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

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

Источник: документация протокола Newton. Технические термины, такие как Intent, Policy, Operator Network, BLS Attestation, PolicyClient, VaultKit, Shield Contracts и стандартный кворум 67%, описаны в документации. Сравнение «финансовый брандмауэр» — это мой личный анализ. #newt $NEWT @NewtonProtocol #Web3 #AI

Самое большое улучшение ИИ, возможно, — это умение понимать, когда говорить: «Я не знаю».

Большинство пользователей ИИ сталкивались с таким. Задаёшь вопрос — ответ звучит уверенно, а потом только понимаешь, что в нём есть неверные части. Из-за этого мне кажется, что главное улучшение ИИ заключается не в том, чтобы отвечать на большее число вопросов. Возможно, это умение знать, когда не отвечать.

Эта мысль вернулась, когда я читал документацию Newton про консенсус. Один нюанс особенно запомнился. Если операторы не согласны с данными, Newton не делает вид, что разногласий нет, и не идёт дальше молча. Согласно документации, значения, выходящие за пределы стандартного допуска 10%, возвращают ToleranceExceeded, и при этом операторов не исключают «тихо» из процесса. Протокол просто останавливается.

Та же схема встречается и в других частях системы. Если ни один оператор не отвечает, результат — NoResponses. Если сеть не может достичь стандартного кворума 67% с учётом веса стейка, результат — InsufficientQuorum. По документации, это не скрытые сбои. Это явные сигналы о том, что сеть не смогла прийти к доверительному решению.

Аналогия с банкоматами помогла мне понять задумку. Если банк не может подтвердить транзакцию, вам скорее покажут «Транзакция не выполнена», чем заставят банкомат угадать ваш баланс и выдать наличные. Похоже, Newton применяет ту же идею. Иногда отказ продолжать безопаснее, чем делать вид, что всё в порядке.

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

Источник: Newton Protocol Documentation (Consensus & Security). #newt $NEWT @NewtonProtocol

Лучшее время найти баг — не в продакшене

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

Документация Newton придерживается простого принципа: сначала тестировать, потом разворачивать. Разработчики могут проверить отдельные компоненты или смоделировать весь рабочий процесс до того, как что-либо попадёт в блокчейн. Последний шаг — simulatePolicy() — собирает данные оракулов, оценивает политику Rego и показывает, будет ли результат разрешать или запрещать, ещё до развертывания.

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

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

Стоит помнить одно ограничение. simulateTask() запускается локально, поэтому оно не задействует весь конвейер Operator. Разработчикам всё равно нужно simulatePolicy(), чтобы проверить полный сценарий выполнения до развертывания.

Мой вывод: надёжные системы не создаются тем, что избегают ошибок. Их создают, находя большинство ошибок ещё до того, как их увидят пользователи.

Источник: Документация протокола Newton (Тестирование и отладка, Тестирование политик и оракулов, Справочник по SDK). Личный анализ, где явно указано. NFA.DYOR. #Newt $NEWT @NewtonProtocol

Сертификаты BN254 от Newton незаметно снижают стоимость доверия при межцепочечном взаимодействии

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

Читая документацию Newton по мультилечейнам, я следую процессу сертификатов, а не потоку активов. После того как операторы оценивают запрос и формируют агрегированную подпись BLS, Newton упаковывает результат в сертификат BN254. Целевая цепочка проверяет этот сертификат, не выполняя живой запрос обратно в Ethereum.

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

Это меняет то, как я думаю о разработке мультилечейнов. Разработчикам не нужно создавать отдельную систему проверки доверия для каждой поддерживаемой цепочки. Они могут развернуть PolicyClient в другой цепочке и переиспользовать ту же модель доверия операторов вместо того, чтобы заново собирать верификацию с нуля.

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

После того как я несколько раз перечитал этот процесс, у меня остаётся другое впечатление. Интересен не сам сертификат BN254. Важно то, что Newton рассматривает доверие как то, что приложения могут переиспользовать между цепочками, а не каждый раз заново собирать заново при новом развертывании.

Источник: документация Newton Protocol (поддержка мультилечейнов, межцепочечная совместимость и аттестация BLS). Личный анализ. #newt $NEWT @NewtonProtocol