Я предположил, что если я хочу сделать три действия в сети — одобрить, обменять, а затем застейкать, — то блокчейн будет считать это одним действием или не считать вовсе. Открытый issue в репозитории Rusk от Dusk говорит, что сегодня это работает иначе.
Транзакция Dusk сегодня несёт одну единственную необязательную операцию: один вызов контракта, один deploy или одну memo — с одним значением, одним получателем, одним nonce и одной подписью. Поэтому approve, swap и stake превращаются в три отдельных транзакции, каждая из которых независимо может быть включена или отброшена. Issue Dusk формулирует это прямо: нет гарантии атомарности между ними. Одобрил и обменял, но не застейкал — и ты остаёшься посередине процесса без отката на уровне протокола.
Проблема не только в том, что многошаговые сценарии могут оборваться на середине. Исправление этого меняет того, кто должен нести издержки совместимости.
Контракт batcher делает всю последовательность атомарной, потому что неудачный sub-call откатывает внешнюю транзакцию. Но контракт-цель, который проверяет, кто вызывает его напрямую, увидит batcher, а не тебя — если только сам этот контракт не написан так, чтобы смотреть дальше непосредственного вызывающего. Протокольная batch-транзакция сохраняет тебя как вызывающего на каждом шаге, но она не появляется без нового формата транзакций, изменений в консенсусе, хардфорка и обновлений в каждом wallet SDK.
Добавление batching не убирает компромисс. Оно решает, где лежит бремя совместимости — в авторизации приложений или в стеке протокола.
«Исправление атомарности не убирает компромисс; оно определяет, куда перемещаются бремя совместимости и граница доверия».
За чем я бы на самом деле хотел наблюдать: выбирает ли Dusk batcher на уровне приложения или транзакцию на уровне протокола, и какие существующие предположения об авторизации вынуждает сделать этот выбор разработчиков.
#dusk $DUSK @Dusk
Транзакция Dusk сегодня несёт одну единственную необязательную операцию: один вызов контракта, один deploy или одну memo — с одним значением, одним получателем, одним nonce и одной подписью. Поэтому approve, swap и stake превращаются в три отдельных транзакции, каждая из которых независимо может быть включена или отброшена. Issue Dusk формулирует это прямо: нет гарантии атомарности между ними. Одобрил и обменял, но не застейкал — и ты остаёшься посередине процесса без отката на уровне протокола.
Проблема не только в том, что многошаговые сценарии могут оборваться на середине. Исправление этого меняет того, кто должен нести издержки совместимости.
Контракт batcher делает всю последовательность атомарной, потому что неудачный sub-call откатывает внешнюю транзакцию. Но контракт-цель, который проверяет, кто вызывает его напрямую, увидит batcher, а не тебя — если только сам этот контракт не написан так, чтобы смотреть дальше непосредственного вызывающего. Протокольная batch-транзакция сохраняет тебя как вызывающего на каждом шаге, но она не появляется без нового формата транзакций, изменений в консенсусе, хардфорка и обновлений в каждом wallet SDK.
Добавление batching не убирает компромисс. Оно решает, где лежит бремя совместимости — в авторизации приложений или в стеке протокола.
«Исправление атомарности не убирает компромисс; оно определяет, куда перемещаются бремя совместимости и граница доверия».
За чем я бы на самом деле хотел наблюдать: выбирает ли Dusk batcher на уровне приложения или транзакцию на уровне протокола, и какие существующие предположения об авторизации вынуждает сделать этот выбор разработчиков.
#dusk $DUSK @Dusk
