Одна техническая деталь заставила меня по-новому взглянуть на Dusk.
Связь между DuskDS и DuskEVM не требовала создания еще одной обернутой версии нативного $DUSK
@Dusk использует нативную bridge-архитектуру между слоями.
Сначала это может звучать как небольшая деталь реализации.
Но я так не думаю.
Каждый дополнительный bridge, wrapper или внешний кастодиан может привнести в финансовую систему еще одно допущение о доверии.
Поэтому я начал смотреть на Dusk через другой вопрос:
Сколько дополнительных допущений о доверии на самом деле нужно архитектуре?
Модель Dusk сохраняет роли ясными:
DuskDS → расчеты и безопасность сети
DuskEVM → выполнение приложений
Нативный bridge → перемещение DUSK между слоями
Это особенно важно для регулируемых финансов.
Если учреждение уже занимается соблюдением требований, идентификацией, ограничениями на активы и требованиями к раскрытию информации, добавление ненужных инфраструктурных зависимостей не слишком помогает.
Именно поэтому мне нравится здесь принцип проектирования:
Не добавляйте сложности там, где протокол в них не нуждается.
Та же философия встречается и в Dusk:
приватность там, где чувствительная информация нуждается в защите,
прозрачность там, где рынку нужна видимость,
и выборочное раскрытие, когда уполномоченной стороне требуется проверка.
Для меня это куда более сильный тезис, чем просто сказать:
«У Dusk есть bridge».
Речь о том, чтобы снижать ненужные допущения о доверии по всей финансовой цепочке.
#dusk
Связь между DuskDS и DuskEVM не требовала создания еще одной обернутой версии нативного $DUSK
@Dusk использует нативную bridge-архитектуру между слоями.
Сначала это может звучать как небольшая деталь реализации.
Но я так не думаю.
Каждый дополнительный bridge, wrapper или внешний кастодиан может привнести в финансовую систему еще одно допущение о доверии.
Поэтому я начал смотреть на Dusk через другой вопрос:
Сколько дополнительных допущений о доверии на самом деле нужно архитектуре?
Модель Dusk сохраняет роли ясными:
DuskDS → расчеты и безопасность сети
DuskEVM → выполнение приложений
Нативный bridge → перемещение DUSK между слоями
Это особенно важно для регулируемых финансов.
Если учреждение уже занимается соблюдением требований, идентификацией, ограничениями на активы и требованиями к раскрытию информации, добавление ненужных инфраструктурных зависимостей не слишком помогает.
Именно поэтому мне нравится здесь принцип проектирования:
Не добавляйте сложности там, где протокол в них не нуждается.
Та же философия встречается и в Dusk:
приватность там, где чувствительная информация нуждается в защите,
прозрачность там, где рынку нужна видимость,
и выборочное раскрытие, когда уполномоченной стороне требуется проверка.
Для меня это куда более сильный тезис, чем просто сказать:
«У Dusk есть bridge».
Речь о том, чтобы снижать ненужные допущения о доверии по всей финансовой цепочке.
#dusk
