На самом деле в этом стеке @Dusk есть две связанные, но разные книги учета: одна — журнал выполнения DuskEVM, который наружу описывается как Ethereum JSON-RPC; другая — расчетная книга Dusk L1, наружу описываемая как GraphQL / RUES. DUSK в обеих этих книгах должен читаться как одно и то же число, но их часы, единицы и количество знаков после запятой отличаются.
DuskEVM — это EVM-исполнительный слой в стиле OP Stack: он возвращает блоки, логи и receipt в стандартной форме EVM. Его окончательные расчеты и доступность данных затем через batcher, state-commitment и мостирование закрепляются в DuskDS. То есть это не адаптер «в реальном времени переводящий GraphQL в JSON-RPC», а поддержание конечной согласованности между двумя слоями за счет моста и state-commitment. Важное, на что нужно обратить внимание, — межслойные сценарии: inclusion в DuskEVM происходит быстро, но полноценный расчет и подтверждение мостом требуют еще нескольких шагов, в течение которых состояние, которое видят обе стороны, может временно различаться.
Роль $DUSK делает этот риск более конкретным. На «нативной» стороне L1 используется LUX: 1 DUSK равен 10^9 LUX; а DuskEVM, чтобы совместить инструментарий Ethereum, раскрывает DUSK с 18 десятичными знаками. При мостировании, если пересчет или обработка точности выполнены неправильно, одна и та же ценность может на короткое время не совпасть в двух книгах учета. Для обычных переводов это может быть лишь «погрешность отображения», но для расчетов под регуляторным контролем это может превратиться в окно ошибок формата «с одной стороны отображается зачисление, а с другой — еще не подтверждено окончательно».
Мой вывод после прочтения: оцените #dusk — нельзя ограничиться тем, что он «совместим с EVM»; нужно смотреть, какие гарантии согласованности есть между расчетной книгой L1 и EVM-исполнителем. Материал пока не дает достаточного описания приоритетов источников авторитетных данных, механизмов обнаружения конфликтов и их исправления, а DUSK как раз является тем числом, которое в этих двух книгах нельзя прочитать неверно. DYOR.
DuskEVM — это EVM-исполнительный слой в стиле OP Stack: он возвращает блоки, логи и receipt в стандартной форме EVM. Его окончательные расчеты и доступность данных затем через batcher, state-commitment и мостирование закрепляются в DuskDS. То есть это не адаптер «в реальном времени переводящий GraphQL в JSON-RPC», а поддержание конечной согласованности между двумя слоями за счет моста и state-commitment. Важное, на что нужно обратить внимание, — межслойные сценарии: inclusion в DuskEVM происходит быстро, но полноценный расчет и подтверждение мостом требуют еще нескольких шагов, в течение которых состояние, которое видят обе стороны, может временно различаться.
Роль $DUSK делает этот риск более конкретным. На «нативной» стороне L1 используется LUX: 1 DUSK равен 10^9 LUX; а DuskEVM, чтобы совместить инструментарий Ethereum, раскрывает DUSK с 18 десятичными знаками. При мостировании, если пересчет или обработка точности выполнены неправильно, одна и та же ценность может на короткое время не совпасть в двух книгах учета. Для обычных переводов это может быть лишь «погрешность отображения», но для расчетов под регуляторным контролем это может превратиться в окно ошибок формата «с одной стороны отображается зачисление, а с другой — еще не подтверждено окончательно».
Мой вывод после прочтения: оцените #dusk — нельзя ограничиться тем, что он «совместим с EVM»; нужно смотреть, какие гарантии согласованности есть между расчетной книгой L1 и EVM-исполнителем. Материал пока не дает достаточного описания приоритетов источников авторитетных данных, механизмов обнаружения конфликтов и их исправления, а DUSK как раз является тем числом, которое в этих двух книгах нельзя прочитать неверно. DYOR.
