На прошлой неделе помогал клиенту с межбанковским переводом за рубеж: из‑за подтормажившего интернета запросы дважды подтверждались, а система сразу определила это как «повторную транзакцию» и заблокировала. Пролистали полдня, но никто так и не дал внятного объяснения. В цепочке блоков это, по сути, одна и та же проблема, но решение устроено совсем иначе.
Модель аккаунтов Moonlight от Dusk (то есть её прозрачная система аккаунтов) опирается на nonce против повторов — у каждого аккаунта есть счётчик, и nonce каждой транзакции должен быть ровно на 1 больше текущего значения. «На единицу больше» или «на единицу меньше» — и сеть сразу отклонит. Это не про то, что система потом «угадывает, повторили ли вы клик», а про то, что сами числа жёстко фиксируют порядок: никто не сможет свалить вину на кого-то другого, и не нужно ждать решения службы поддержки.
Подход Phoenix к защите от двойных трат вообще из другой категории — Phoenix использует nullifier: он одноразово отмечает, что конкретный UTXO уже потрачен, и повторно потратить нельзя. Moonlight же работает через nonce: порядок увеличения встаёт как замок и не даёт повторить. Две модели аккаунтов, две разные логики предотвращения повторов — в whitepaper это разложено достаточно чётко; это не «одна и та же кода, только переименовали» и переиспользовали с другой стороны.
Это проектирование решает вопрос «что делать, если одну и ту же транзакцию сеть получила дважды», но не решает «что делать, если пользователь сам по ошибке смахнул и перевёл не туда» — nonce отвечает за порядок и уникальность, а правильность содержимого транзакции не проверяет. Защита от таких ошибок всё равно должна лечиться подтверждающим взаимодействием на стороне кошелька.
$DUSK
#dusk @Dusk
Модель аккаунтов Moonlight от Dusk (то есть её прозрачная система аккаунтов) опирается на nonce против повторов — у каждого аккаунта есть счётчик, и nonce каждой транзакции должен быть ровно на 1 больше текущего значения. «На единицу больше» или «на единицу меньше» — и сеть сразу отклонит. Это не про то, что система потом «угадывает, повторили ли вы клик», а про то, что сами числа жёстко фиксируют порядок: никто не сможет свалить вину на кого-то другого, и не нужно ждать решения службы поддержки.
Подход Phoenix к защите от двойных трат вообще из другой категории — Phoenix использует nullifier: он одноразово отмечает, что конкретный UTXO уже потрачен, и повторно потратить нельзя. Moonlight же работает через nonce: порядок увеличения встаёт как замок и не даёт повторить. Две модели аккаунтов, две разные логики предотвращения повторов — в whitepaper это разложено достаточно чётко; это не «одна и та же кода, только переименовали» и переиспользовали с другой стороны.
Это проектирование решает вопрос «что делать, если одну и ту же транзакцию сеть получила дважды», но не решает «что делать, если пользователь сам по ошибке смахнул и перевёл не туда» — nonce отвечает за порядок и уникальность, а правильность содержимого транзакции не проверяет. Защита от таких ошибок всё равно должна лечиться подтверждающим взаимодействием на стороне кошелька.
$DUSK
#dusk @Dusk
