#dusk $DUSK @Dusk При чтении примечаний к релизу Boreas я остановился на одном небольшом изменении: DUSK больше не оценивает SHA-256, Keccak и универсальный хешинг так, как будто каждый ввод стоит одинаково.

32-байтовый хеш и хеш-вызов на несколько килобайт используют один и тот же хост-запрос, но они не требуют равных затрат труда. Boreas добавляет тарификацию по размеру для этих трех, тогда как верификация BLS-мультисиг масштабируется по количеству ключей. Проверка KZG и восстановление secp256k1 не описаны как тарифицируемые в зависимости от длины ввода. Спрашивать, какой запрос «самый дорогой», не зафиксировав длину ввода и количество ключей — почти неверный вопрос.

Сравнение сводится к плоской цене вызова API против вычислений, навязанных валидаторам. DUSK приблизился ко второму.

Есть одно осложнение. Boreas учитывает форки: историческое выполнение сохраняет прежнюю семантику до форка, в то время как текущие контракты получают новое расписание. Эквивалентные вычисления могут приводить к разным расходам газа в зависимости от контекста выполнения, необходимого для реплея — это неловко для разработчиков, прогнозирующих стоимость.

Для DUSK более точная оценка газа должна уменьшить недооценку криптографических нагрузок и сделать исполнение более согласованным между нодами. Это не доказывает, что успешные переходы состояния стали дешевле. Возможно, они стали просто честнее оцениваться, даже если цифры выросли.

Я все еще жду данные бенчмарков по корзинам входных данных. Детерминированный учет убедителен только тогда, когда начисляемый газ соответствует реальной работе CPU.
@Dusk #dusk #Dusk