Все постоянно говорят о Ньютоне как о инструменте для соответствия требованиям. И что ж, я понимаю. Комплаенс важен, и Ньютон делает это хорошо. Но честно? Каждый раз, когда я вижу эту беседу, у меня ощущение, что люди упускают более интересную вещь, которая происходит под всем этим.
Ньютон — это не просто про соблюдение правил. Это про строительные блоки. И я думаю, что эта идея заслуживает гораздо большего внимания, чем получает.
Позвольте мне объяснить, что я имею в виду
Когда я в первый раз начал разбираться в том, как работает система политики Ньютон, то, что выделилось для меня, — это было не часть про соответствие требованиям. Меня поразило то, как всё устроено. Каждая политика в Ньютоне — это отдельный небольшой, сфокусированный модуль. Один модуль отвечает за лимиты расходов. Другой — за многофакторные подписи при одобрениях. Ещё один блокирует помеченные адреса кошельков. Другой ограничивает транзакции определёнными часами.
Каждый модуль делает одну вещь. Вот и всё. Одна задача — выполненная хорошо.
Но вот где становится интересно. Эти модули не склеены внутри одного приложения. Вы можете поднимать их, переносить, комбинировать с другими модулями и использовать в совершенно разных контекстах. Это идея «кирпичиков LEGO». Один блок сам по себе — не так уж много. Но когда вы начинаете складывать их вместе, вы можете построить настоящее.
Проблема, которую я снова и снова вижу в разработке блокчейна
Я заметил, что почти каждая команда, которая создает финансовое приложение на блокчейне, рано или поздно упирается в одну и ту же стену. Прежде чем вообще начать строить тот самый продукт, о котором они заботятся, им приходится сначала собрать целый фундамент. Лимиты расходов. Контроль доступа. Процессы подтверждения. Проверки комплаенса. Механизмы экстренной остановки.
Это не самые захватывающие функции. Никто не строит стартап только ради того, чтобы с нуля написать систему лимитов расходов. Но приходится, потому что на большинстве блокчейнов нет общего места, где можно получить эти вещи. Каждая команда пересоздает одно и то же — чуть иначе и с чуть другими багами.
И в финансовых приложениях баги — это не просто раздражение. Неправильное правило лимита расходов, сломанный процесс подтверждения — это не мелкая неудобная задержка. Это реальные деньги, уходящие туда, куда им вообще не следовало.
Это та проблема, которую Ньютон решает незаметно. Напишите модуль политики один раз. Протестируйте как следует. Затем дайте каждому приложению, которому он нужен, просто использовать его — вместо того чтобы собирать свою версию с нуля.
Как именно выглядит комбинирование модулей
Лучший способ объяснить компонуемость — на реальном примере.
Представьте: вы строите платформу корпоративных платежей. Вам нужны лимиты расходов на каждого сотрудника. Вам нужно многостороннее подтверждение (multisignature) для всего, что выше определенной суммы. Вам нужны журналы транзакций для аудита. И вам нужна возможность блокировать платежи на конкретные адреса. Четыре требования.
Без Ньютон вашей команде пришлось бы с нуля написать все четыре этих компонента. Это недели работы, прежде чем вы вообще доберетесь до реального продукта.
С Ньютон каждый из этих элементов уже является модулем. Вы соединяете их, задаете параметры — и слой авторизации готов. Вы пропустили фундаментальную работу и сразу перешли к созданию того, что делает ваш продукт уникальным.
Или подумайте о DeFi-протоколе кредитования. Возможно, ему нужен дневной лимит на снятие, механизм паузы, который срабатывает при необычной активности, и белый список одобренных адресов назначения. Три модуля. Соберите их вместе — и слой безопасности уже на месте.
Это и есть компонуемость на практике. Вы собираете приложение, а не пишете вручную каждую его часть.
Почему переиспользуемость — это на самом деле функция безопасности
Вот что, как мне кажется, люди недооценивают. Переиспользуемость — это не только удобство для разработчиков. В финансовом программном обеспечении это еще и свойство безопасности.
Давайте посмотрим на это так. Если модуль лимитов расходов используется в пятидесяти разных приложениях, его тестируют в пятидесяти разных сценариях. Выплывают крайние случаи. Находят баги. Сообщают о них. Исправления вносятся. Со временем этот модуль становится очень надежным, потому что через него прошло много всего.
Но если пятьдесят команд каждая напишут свой модуль лимитов расходов, у вас будет пятьдесят отдельных кодовых баз, у каждой — свои слепые зоны. Баг, исправленный в одном месте, все равно остается сидеть в остальных сорока девяти.
Традиционные финансы поняли это очень давно. Банки не собирают свои платежные рельсы с нуля. Они опираются на общую инфраструктуру и общие стандарты. Это снижает риск для всех, а не только для одного учреждения.
Ньютон пытается привнести ту же логику в ончейн-ауторизацию. Одна надежная база, на которую опираются все, вместо того чтобы каждый независимо строил один и тот же шаткий пол.
Любой может добавлять вклад в экосистему
Есть еще один момент, который стоит упомянуть. Ньютон — не закрытая библиотека, где вы получаете только то, что идет в комплекте. Разработчики могут писать новые модули и возвращать их обратно в проект.
Если вы работаете с токенизированной недвижимостью и создаете модуль политики, который обрабатывает что-то конкретное для этой сферы, вы можете его опубликовать. Другие разработчики, работающие в том же контексте, смогут им воспользоваться. Экосистема доступных модулей со временем растет.
Вот как это устроено на практике с LEGO. Дело не только в том, что существующие детали хороши. Дело в том, что любой может придумать новые элементы, которые при этом по-прежнему подходят ко всему остальному. Система становится полезнее по мере того, как больше людей добавляют в нее свой вклад.
Что изменится для тех, кто создает на блокчейне
Самая сложная часть разработки финансовых приложений на блокчейне всегда заключалась в том, что до старта вам приходится тащить на себе слишком много веса. Дороговато добраться до безопасной базовой основы, и большинство команд выясняют это сами.
Модули политики Ньютон меняют эту математику. Базовый уровень обходится дешевле, потому что значительная часть фундаментальной работы уже сделана. Разработчику не нужно быть экспертом по комплаенсу, чтобы построить приложение, которое корректно обрабатывает требования соответствия. Ему нужно знать, какие модули подходят под его сценарий, и как их комбинировать.
Это значит, что больше разработчиков смогут собирать серьезные финансовые приложения, а те команды, которые уже этим занимаются, смогут двигаться быстрее, не прибегая к обходным путям, о которых они потом пожалеют.
Реальная история
Ньютон описывают как слой комплаенса — и такое представление не ошибочно. Но оно несколько сужает картину.
То, что Ньютон на самом деле строит, — это общая финансовая инфраструктура. То, что веб-разработчики воспринимают как данность: общие библиотеки, общие протоколы и общие стандарты существуют десятилетиями. Тот же подход, примененный к ончейн-ауторизации, — это и есть модули политики Ньютон.
Заголовки достаются комплаенсу. Но строительные блоки под ним — это то, что, как мне кажется, будет иметь наибольшее значение в долгосрочной перспективе.
#SupremeCourtBlocksTrumpFromRemovingFed #FedCook
