Недавно постоянно смотрю на @Dusk — чем дальше, тем больше кажется, что в этом есть что-то интересное.
Сначала про самый «цепляющий» меня жизненный цикл транзакции. Сначала меня тоже сбили с толку идея определённой окончательности: я перелопатил несколько дней документации и понял, что confirmed и finalized — это вообще разные вещи. Блок ещё не дошёл до последнего шага, и он всё ещё может revert.
Процесс такой: provisioner сначала предлагает кандидатный блок, затем случайная комиссия делает Validation, потом идёт Ratification, и только после ratify всё становится реально «на земле». Это не значит, что после предложения всё — фатально. А вот после финализации больше не нужно наращивать подтверждения.
Если это обычный перевод, можно простить, но для зачисления на бирже или расчётов по ценным бумагам так играть нельзя. Если слышишь executed, это лишь значит, что выполнение произошло — тебе ещё нужно проверить, что error пустой, и только событие finalized считается надёжным. Если вдруг приходит reverted — значит, надо слушать/перепрослушивать заново. revert на уровне контракта — это ошибка кода, а revert на уровне блока — это смена консенсуса; восстановление логики в итоге в двух противоположных направлениях. Интегратор, который принимает confirmed за finalized, может «почти наверняка» сломать определённость на уровне приложения. Сейчас сильнее всего меня волнует: биржа и Dusk Trade — они вообще используют один и тот же boundary в виде finalized? Есть ли полноценный, поддающийся аудиту replay-процесс?
Ещё про честную торговлю — меня это правда бесило. Mempool выглядит как стеклянный дом без штор: что хочешь купить — весь мир видит, роботы-«щипцы» могут в любой момент влезть. $DUSK прямо на уровне протокола устроила приватный пакетный аукцион: ставки и количество отправляются мгновенно, а ZK сразу «запирает» их. Узлы вычисляют справедливую цену так, чтобы разница между скрытым общим спросом на покупки и общим предложением на продажи была близка к нулю; и все отложенные заявки в этом блоке рассчитываются по этой цене. Ассиметрия информации была вскрыта — dark pool по сути оказался нечестным.
Про соответствие тоже без обмана. Phoenix делает приватность через ZK, Moonlight использует прозрачный бухгалтерский учёт, Citadel поддерживает выборочное раскрытие, а XSC целиком прописывает в логике контракта право, ограничения и отчётность. Полагаться не придётся только на то, что «правила где-то там вне цепочки».
Чем сложнее продукт, тем больше правил; вопрос — можно ли, чтобы всё это вместе работало стабильно в разных рабочих процессах. Вот что я дальше буду внимательно отслеживать. По-настоящему окончательность — это не термин: это когда события с нод идут в чейн без того, чтобы кто-то «побежал вперёд». #dusk $DUSK
Сначала про самый «цепляющий» меня жизненный цикл транзакции. Сначала меня тоже сбили с толку идея определённой окончательности: я перелопатил несколько дней документации и понял, что confirmed и finalized — это вообще разные вещи. Блок ещё не дошёл до последнего шага, и он всё ещё может revert.
Процесс такой: provisioner сначала предлагает кандидатный блок, затем случайная комиссия делает Validation, потом идёт Ratification, и только после ratify всё становится реально «на земле». Это не значит, что после предложения всё — фатально. А вот после финализации больше не нужно наращивать подтверждения.
Если это обычный перевод, можно простить, но для зачисления на бирже или расчётов по ценным бумагам так играть нельзя. Если слышишь executed, это лишь значит, что выполнение произошло — тебе ещё нужно проверить, что error пустой, и только событие finalized считается надёжным. Если вдруг приходит reverted — значит, надо слушать/перепрослушивать заново. revert на уровне контракта — это ошибка кода, а revert на уровне блока — это смена консенсуса; восстановление логики в итоге в двух противоположных направлениях. Интегратор, который принимает confirmed за finalized, может «почти наверняка» сломать определённость на уровне приложения. Сейчас сильнее всего меня волнует: биржа и Dusk Trade — они вообще используют один и тот же boundary в виде finalized? Есть ли полноценный, поддающийся аудиту replay-процесс?
Ещё про честную торговлю — меня это правда бесило. Mempool выглядит как стеклянный дом без штор: что хочешь купить — весь мир видит, роботы-«щипцы» могут в любой момент влезть. $DUSK прямо на уровне протокола устроила приватный пакетный аукцион: ставки и количество отправляются мгновенно, а ZK сразу «запирает» их. Узлы вычисляют справедливую цену так, чтобы разница между скрытым общим спросом на покупки и общим предложением на продажи была близка к нулю; и все отложенные заявки в этом блоке рассчитываются по этой цене. Ассиметрия информации была вскрыта — dark pool по сути оказался нечестным.
Про соответствие тоже без обмана. Phoenix делает приватность через ZK, Moonlight использует прозрачный бухгалтерский учёт, Citadel поддерживает выборочное раскрытие, а XSC целиком прописывает в логике контракта право, ограничения и отчётность. Полагаться не придётся только на то, что «правила где-то там вне цепочки».
Чем сложнее продукт, тем больше правил; вопрос — можно ли, чтобы всё это вместе работало стабильно в разных рабочих процессах. Вот что я дальше буду внимательно отслеживать. По-настоящему окончательность — это не термин: это когда события с нод идут в чейн без того, чтобы кто-то «побежал вперёд». #dusk $DUSK