Завершенный депозит DUSK автоматически безопасен для зачисления.
Завершенность еще не закончила работу
Я предположил: раз депозит Moonlight достиг завершенности, биржа может безопасно записать кредит клиента и перейти дальше.
Документация Dusk разделяет две вещи.
Сканер читает историю Moonlight, достигшую завершенности, но хранение (custody) должно одновременно создать кредит и сдвинуть его контрольную точку блока. Каждый кредит использует transaction ID транзакции Dusk как уникальный ключ, а `next_block` продвигается только после того, как кредит стал надежным (durable).
Теперь возьмем построенный пример: сканер завершает диапазон, достигший завершенности, через блок 12,000. Он записывает депозит в 5 DUSK для Алисы, затем падает до того, как выполнится `next_block`.
При перезапуске он сканирует этот диапазон снова.
Депозит все еще остается завершенным. Вторая проверка все еще безопасна. Transaction ID не позволяет тому же депозиту стать вторым кредитом.
Но поменяйте порядок.
Если `next_block` был бы продвинут до того, как кредит стал надежным, сбой мог бы привести к тому, что сканер сочтет диапазон завершенным, хотя депозит клиента так и не был записан. Документация Dusk явно предупреждает об опасности такого порядка.
Таким образом, завершенность отвечает на один вопрос: "Этот перевод DUSK завершён (settled)?"
Custody отвечает на другой: "Мы записали этот завершенный перевод ровно один раз?"
Оба должны быть верными, чтобы баланс обмена был правильным.
Сколько «безопасности депозита» дает финальность Dusk, и сколько — бухгалтерский механизм, который гарантирует, что событие, достигшее завершенности, переживает сбои, не теряясь и не будучи зачисленным дважды?
@Dusk #dusk $DUSK
Завершенность еще не закончила работу
Я предположил: раз депозит Moonlight достиг завершенности, биржа может безопасно записать кредит клиента и перейти дальше.
Документация Dusk разделяет две вещи.
Сканер читает историю Moonlight, достигшую завершенности, но хранение (custody) должно одновременно создать кредит и сдвинуть его контрольную точку блока. Каждый кредит использует transaction ID транзакции Dusk как уникальный ключ, а `next_block` продвигается только после того, как кредит стал надежным (durable).
Теперь возьмем построенный пример: сканер завершает диапазон, достигший завершенности, через блок 12,000. Он записывает депозит в 5 DUSK для Алисы, затем падает до того, как выполнится `next_block`.
При перезапуске он сканирует этот диапазон снова.
Депозит все еще остается завершенным. Вторая проверка все еще безопасна. Transaction ID не позволяет тому же депозиту стать вторым кредитом.
Но поменяйте порядок.
Если `next_block` был бы продвинут до того, как кредит стал надежным, сбой мог бы привести к тому, что сканер сочтет диапазон завершенным, хотя депозит клиента так и не был записан. Документация Dusk явно предупреждает об опасности такого порядка.
Таким образом, завершенность отвечает на один вопрос: "Этот перевод DUSK завершён (settled)?"
Custody отвечает на другой: "Мы записали этот завершенный перевод ровно один раз?"
Оба должны быть верными, чтобы баланс обмена был правильным.
Сколько «безопасности депозита» дает финальность Dusk, и сколько — бухгалтерский механизм, который гарантирует, что событие, достигшее завершенности, переживает сбои, не теряясь и не будучи зачисленным дважды?
@Dusk #dusk $DUSK
