Сегодня, размышляя о спорном платеже, я заметил кое-что. Меня впечатлило не само транзакционное действие, а то решение, которое требуется после того, как система уже его зафиксировала.
Обычно я мыслю смарт-контракты через их главное преимущество — детерминизм. Чем больше я изучаю финансовую инфраструктуру, тем яснее становится: у этого преимущества есть предел. Контракт может выполнить ровно то, как он был задуманы, но при этом окружающая финансовая ситуация все равно требует интерпретации.
Для меня это различие особенно важно на регулируемых рынках. Споры, реструктуризации, решения о взыскании и исключительные корпоративные действия могут вводить факты, которых просто не существовало на момент, когда исходное правило было сформулировано. Проблема не обязательно в плохом коде. Реальность могла измениться после того, как правило было определено.
Это изменило мой взгляд на автоматизацию. Меня не интересует пытаться помещать каждое финансовое решение в код только потому, что его можно закодировать. Более полезный вопрос — где детерминированная логика должна остановиться и где должна начаться управляемая (регулируемая) оценка.
Если каждое исключение закодировать заранее, я думаю, контракты становится сложнее поддерживать, а управление — более запутанным. Если же каждое исключение остается вне протокола, слишком многое в процессе зависит от ручной координации.
Именно здесь @Dusk становится для меня интересным. Dusk разделяет выполнение и его основу для расчетов: DuskVM поддерживает Rust/WASM-контракты на L1, DuskEVM обеспечивает выполнение EVM, а DuskDS предоставляет консенсус, финальность и доступность данных.
Более важный архитектурный вопрос звучит так: можно ли границу между автоматическим исполнением и институциональным усмотрением сделать явной, управляемой и поддающейся аудиту?
Для меня цель — не максимальная автоматизация. Цель — точная автоматизация: знать, что именно должен решать код, что должны решать люди и как финансовая система фиксирует разницу. ⚖️
#dusk #BinanceSquare $DUSK $PROM $SPK @Dusk
Обычно я мыслю смарт-контракты через их главное преимущество — детерминизм. Чем больше я изучаю финансовую инфраструктуру, тем яснее становится: у этого преимущества есть предел. Контракт может выполнить ровно то, как он был задуманы, но при этом окружающая финансовая ситуация все равно требует интерпретации.
Для меня это различие особенно важно на регулируемых рынках. Споры, реструктуризации, решения о взыскании и исключительные корпоративные действия могут вводить факты, которых просто не существовало на момент, когда исходное правило было сформулировано. Проблема не обязательно в плохом коде. Реальность могла измениться после того, как правило было определено.
Это изменило мой взгляд на автоматизацию. Меня не интересует пытаться помещать каждое финансовое решение в код только потому, что его можно закодировать. Более полезный вопрос — где детерминированная логика должна остановиться и где должна начаться управляемая (регулируемая) оценка.
Если каждое исключение закодировать заранее, я думаю, контракты становится сложнее поддерживать, а управление — более запутанным. Если же каждое исключение остается вне протокола, слишком многое в процессе зависит от ручной координации.
Именно здесь @Dusk становится для меня интересным. Dusk разделяет выполнение и его основу для расчетов: DuskVM поддерживает Rust/WASM-контракты на L1, DuskEVM обеспечивает выполнение EVM, а DuskDS предоставляет консенсус, финальность и доступность данных.
Более важный архитектурный вопрос звучит так: можно ли границу между автоматическим исполнением и институциональным усмотрением сделать явной, управляемой и поддающейся аудиту?
Для меня цель — не максимальная автоматизация. Цель — точная автоматизация: знать, что именно должен решать код, что должны решать люди и как финансовая система фиксирует разницу. ⚖️
#dusk #BinanceSquare $DUSK $PROM $SPK @Dusk
