Одна вещь привлекла мое внимание, когда я разбирался в Dusk: кошелек может быть корректно привязан к идентичности и при этом не пройти перевод, потому что решение о приемлемости, лежащее в основе этого перевода, больше не является актуальным.
Сначала я предположил, что это по сути один шаг валидации.
Но это не так.
Чем глубже я смотрел на архитектуру, тем больше это стало походить на проблему управления состоянием, а не на проблему кошелька.
Привязка кошелька устанавливает криптографическую связь между идентичностью и кошельком.
Эта связь может оставаться абсолютно действительной, даже если меняются внешние условия, влияющие на приемлемость перевода.
Представьте кошелек, привязанный в понедельник. Во вторник изменяется параметр соответствия вне цепочки (off-chain).
Связь с идентичностью не отозвана, кошелек не менялся, и пользователь по-прежнему может доказать контроль над ним.
Но если состояние политики, используемое при оценке транзакции, не было пересчитано, перевод может привести к совершенно другому результату. #dusk .
Эта разница легко упускается, потому что интерфейс сжимает несколько проверок в одно впечатление: «проверено» не обязательно означает «подходит прямо сейчас».
Под капотом может происходить несколько независимых переходов состояния: проверка подписи, связь с идентичностью, статус учетных данных или политики и финальное разрешение на перевод. @Dusk .
Ключевой инженерный вопрос — как изменения во внешней политике распространяются в то состояние, которое реально оценивает транзакция.
Для $DUSK это создает интересный компромисс. Сдержанное (консервативное) состояние политики может снизить риск комплаенс-экспозиции, но устаревшее состояние означает отклоненные переводы и операционные трения.
Более агрессивное обновление повышает актуальность, но добавляет вычислений, необходимость координации и зависимости от инфраструктуры.
То, что я все еще пытаюсь понять, — это слой стимулов: когда действующий кошелек превращается в устаревшее разрешение, кто несет экономическую и операционную ответственность за обновление этого состояния?
Сначала я предположил, что это по сути один шаг валидации.
Но это не так.
Чем глубже я смотрел на архитектуру, тем больше это стало походить на проблему управления состоянием, а не на проблему кошелька.
Привязка кошелька устанавливает криптографическую связь между идентичностью и кошельком.
Эта связь может оставаться абсолютно действительной, даже если меняются внешние условия, влияющие на приемлемость перевода.
Представьте кошелек, привязанный в понедельник. Во вторник изменяется параметр соответствия вне цепочки (off-chain).
Связь с идентичностью не отозвана, кошелек не менялся, и пользователь по-прежнему может доказать контроль над ним.
Но если состояние политики, используемое при оценке транзакции, не было пересчитано, перевод может привести к совершенно другому результату. #dusk .
Эта разница легко упускается, потому что интерфейс сжимает несколько проверок в одно впечатление: «проверено» не обязательно означает «подходит прямо сейчас».
Под капотом может происходить несколько независимых переходов состояния: проверка подписи, связь с идентичностью, статус учетных данных или политики и финальное разрешение на перевод. @Dusk .
Ключевой инженерный вопрос — как изменения во внешней политике распространяются в то состояние, которое реально оценивает транзакция.
Для $DUSK это создает интересный компромисс. Сдержанное (консервативное) состояние политики может снизить риск комплаенс-экспозиции, но устаревшее состояние означает отклоненные переводы и операционные трения.
Более агрессивное обновление повышает актуальность, но добавляет вычислений, необходимость координации и зависимости от инфраструктуры.
То, что я все еще пытаюсь понять, — это слой стимулов: когда действующий кошелек превращается в устаревшее разрешение, кто несет экономическую и операционную ответственность за обновление этого состояния?
