Я снова рассматривал модульную архитектуру Dusk, и диаграмма становится гораздо понятнее, если перестать воспринимать её как три отдельные цепочки.
По сути это три разных задачи, разделённые по уровням стека.
1. DuskDS — базовый слой
Это основа.
DuskDS отвечает за базовые сетевые функции вокруг:
* консенсуса
* доступности данных
* расчётов
То есть вместо того чтобы закладывать в базовый слой абсолютно все обязанности выполнения, DuskDS сосредоточен на том, чтобы лежащая в основе система оставалась согласованной и доведённой до расчёта.
2. DuskEVM — слой совместимости
Здесь появляется выполнение в стиле EVM.
Самое интересное не в том, что “Dusk поддерживает EVM”.
А в том, что выполнение EVM получает собственный слой внутри модульной архитектуры — это даёт разработчикам более привычную среду, при этом сохраняя слой базовой DuskDS отдельно.
Такое разделение может снизить объём работ по интеграции, необходимых при создании приложений.
3. DuskVM — слой выполнения с фокусом на приватность
Затем идёт DuskVM.
Его роль снова иная: выполнение, ориентированное на приватность.
То есть архитектура не заставляет публично-ориентированное выполнение в стиле EVM и приватностно-ориентированное выполнение происходить в строго одной и той же среде.
Они разделяются на собственные пути выполнения.
А затем есть две части, которые связывают воедино всю конструкцию.
4. Один DUSK на всём стеке
Архитектура сохраняет единый токен DUSK на всех уровнях.
Это важно, потому что модульное выполнение не означает автоматически фрагментацию экономики.
Среды выполнения можно разделить, сохранив при этом единую токеномику.
5. Нативный мост между DuskDS и DuskEVM
Кроме того, слои не должны вести себя как изолированные острова.
Архитектура описывает концепцию нативного моста между DuskDS и DuskEVM, давая слою выполнения обратный путь к базовой системе Dusk.
И именно это, как мне кажется, интереснее самой диаграммы.
Архитектура по сути говорит:
DuskDS отвечает за фундамент.
DuskEVM отвечает за выполнение в EVM.
DuskVM отвечает за выполнение с фокусом на приватность.
$DUSK #dusk @Dusk
По сути это три разных задачи, разделённые по уровням стека.
1. DuskDS — базовый слой
Это основа.
DuskDS отвечает за базовые сетевые функции вокруг:
* консенсуса
* доступности данных
* расчётов
То есть вместо того чтобы закладывать в базовый слой абсолютно все обязанности выполнения, DuskDS сосредоточен на том, чтобы лежащая в основе система оставалась согласованной и доведённой до расчёта.
2. DuskEVM — слой совместимости
Здесь появляется выполнение в стиле EVM.
Самое интересное не в том, что “Dusk поддерживает EVM”.
А в том, что выполнение EVM получает собственный слой внутри модульной архитектуры — это даёт разработчикам более привычную среду, при этом сохраняя слой базовой DuskDS отдельно.
Такое разделение может снизить объём работ по интеграции, необходимых при создании приложений.
3. DuskVM — слой выполнения с фокусом на приватность
Затем идёт DuskVM.
Его роль снова иная: выполнение, ориентированное на приватность.
То есть архитектура не заставляет публично-ориентированное выполнение в стиле EVM и приватностно-ориентированное выполнение происходить в строго одной и той же среде.
Они разделяются на собственные пути выполнения.
А затем есть две части, которые связывают воедино всю конструкцию.
4. Один DUSK на всём стеке
Архитектура сохраняет единый токен DUSK на всех уровнях.
Это важно, потому что модульное выполнение не означает автоматически фрагментацию экономики.
Среды выполнения можно разделить, сохранив при этом единую токеномику.
5. Нативный мост между DuskDS и DuskEVM
Кроме того, слои не должны вести себя как изолированные острова.
Архитектура описывает концепцию нативного моста между DuskDS и DuskEVM, давая слою выполнения обратный путь к базовой системе Dusk.
И именно это, как мне кажется, интереснее самой диаграммы.
Архитектура по сути говорит:
DuskDS отвечает за фундамент.
DuskEVM отвечает за выполнение в EVM.
DuskVM отвечает за выполнение с фокусом на приватность.
$DUSK #dusk @Dusk