Чем глубже я изучал протокол Newton, тем меньше он походил на очередной слой автоматизации и тем больше напоминал систему, предназначенную для того, чтобы ставить под сомнение каждое действие, прежде чем принять его. Большинство приложений блокчейна делают упор на скорость выполнения: как только транзакция подписана, ответственность сети сводится к тому, чтобы обработать её как можно эффективнее. Newton вводит другое допущение: выполнение должно происходить только после проверки, а не до неё.
Этот небольшой сдвиг полностью меняет роль автоматизации. Вместо вопроса: "Можно ли завершить эту транзакцию?" протокол спрашивает: "Следует ли завершить эту транзакцию?" Похоже, что это близкие по смыслу вопросы, но на самом деле это совершенно разные философии. Один оптимизирует пропускную способность; другой — уверенность.
То, что привлекло мое внимание, — это было не только само устройство политики, но и то, как политики остаются независимыми от приложений, которые их используют. Традиционные системы часто смешивают бизнес-логику и требования комплаенса в одной и той же кодовой базе. Любое изменение в регулировании грозит очередным обновлением, очередным аудитом, очередным развертыванием. Newton разделяет эти обязанности. Приложения остаются стабильными, пока политики развиваются независимо, позволяя правилам адаптироваться без перестройки инфраструктуры под ними.
Такая гибкость мощна, но она также добавляет интересный слой управления. Техническая задача смещается с написания безопасных смарт-контрактов на поддержание доверенных политик. Протокол может выполнить каждую инструкцию идеально, но итог все равно будет зависеть от того, кто определяет правила, которые должны исполняться. Поэтому прозрачность становится не менее важной, чем криптография. Подтверждаемое исполнение почти ничего не значит, если участники не могут понять, почему было принято то или иное решение.
Модель оператора сети подкрепляет эту идею. Вместо того чтобы полагаться на единственный орган власти, который одобряет активность, несколько участников оценивают условия политики и формируют подтверждения до наступления расчетов. Комплаенс становится тем, что сеть наблюдает совместно, а не тем, что какая-то одна организация заявляет в частном порядке. Теоретически это распределяет доверие. На практике это также поднимает новые вопросы — о стимулах, подотчетности и том, как следует разрешать разногласия между операторами.
Чем больше я обдумывал архитектуру Newton, тем больше казалось, что она спроектирована для предотвращения ошибок, а не для их исправления. Многие финансовые системы выявляют проблемы после того, как деньги уже переместились, заставляя расследователей распутывать транзакции или замораживать активы позже. Newton пытается перенести эти проверки в самое начало процесса. Успех измеряется не тем, насколько эффективно разрешаются споры, а тем, насколько редко недействительные транзакции вообще доходят до расчетов.
То, станет ли эта модель распространенной во децентрализованных финансах, будет зависеть не только от технической производительности. Разработчикам потребуется уверенность в том, что политики остаются адаптивными, не превращаясь в непредсказуемые. Институции захотят гарантий, что управление достаточно прозрачно, чтобы удовлетворять требованиям регуляторов, и при этом достаточно децентрализовано, чтобы сохранять доверие пользователей. Пользователи, тем временем, возможно, никогда не прочитают реестр политик и не поймут поток подтверждений, но они заметят, насколько надежно ощущаются транзакции, и сохраняются ли правила согласованными со временем.
Это, вероятно, самое интересное вклад Newton Protocol. Он подразумевает, что будущее программируемых финансов — это не просто ускорение транзакций. Речь идет о том, чтобы каждое автоматизированное решение можно было объяснить до того, как ценность перейдет из рук в руки. В финансовой системе, все чаще управляемой ПО, доверие в конечном итоге может прийти не от отмены правил, а от того, что эти правила будут видимыми, проверяемыми и подотчетными всем, кто от них зависит.
@NewtonProtocol $NEWT #newt $BNB
