Я решил сэмулировать вариант, когда неделю нет доступа к серверам ЦОД платформы цифрового рубля или в районе полностью отсутствует Интернет неделю и больше.
И здесь важно разделить два сценария: отсутствие Интернета у пользователя и недоступность самой платформы ЦР — это принципиально разные вещи.
Если пропал только Интернет, потенциально работает офлайн-режим: заранее выделенные цифровые рубли перемещаются в специальный offline wallet и могут передаваться напрямую Wallet ↔ Wallet или Wallet ↔ POS.
Но если недоступны сами ЦОДы платформы, обычные онлайн-платежи останавливаются, поскольку центральный ledger является источником актуального состояния системы.
Чтобы ЦР продолжал работать неделю, нужна фактически автономная платёжная архитектура.
Например, вместо обычной цепочки Wallet → Bank → Platform → Ledger появляется Wallet → Secure Element → Offline Token → Wallet/POS.
Цифровой рубль при этом должен представляться защищённым криптографическим объектом с идентификатором, владельцем, nonce/counter, сроком действия и цифровой подписью.
Главная проблема — double spend: без ЦОД нельзя просто спросить сервер, не потратил ли пользователь эти деньги несколькими магазинами одновременно.
Поэтому нужны аппаратные ограничения Secure Element, лимит офлайн-баланса, максимальная сумма операции, ограничение количества транзакций и срок действия автономного состояния.
Например: Online balance = 150 000 ₽, но Offline allowance = 20 000 ₽, которые можно потратить только в автономном режиме.
Каждая операция записывается в защищённый локальный журнал и может быть связана с предыдущей через Hash(TX[n-1]) + Signature.
А для действительно серьёзной аварии я бы добавил резервные и региональные DR-узлы, которые временно принимают журналы операций и проверяют подписи, но не могут создавать новые цифровые рубли или самостоятельно увеличивать балансы.
Получается трёхуровневая модель: ЦОД ЦБ = источник истины, DR/Regional Node = аварийный контур, Wallet/Secure Element = автономный контур пользователя.
После восстановления инфраструктуры происходит Offline Wallet → Bank Gateway → DR/Platform → Reconciliation → Ledger ЦБ, где система сверяет накопленные операции.
То есть офлайн-режим сам по себе не означает, что ЦР сможет неделю работать при полном отключении ЦОДов — для этого нужен заранее спроектированный автономный платёжный контур с anti-double-spend, криптографическим контролем и механизмом последующей синхронизации.
И здесь важно разделить два сценария: отсутствие Интернета у пользователя и недоступность самой платформы ЦР — это принципиально разные вещи.
Если пропал только Интернет, потенциально работает офлайн-режим: заранее выделенные цифровые рубли перемещаются в специальный offline wallet и могут передаваться напрямую Wallet ↔ Wallet или Wallet ↔ POS.
Но если недоступны сами ЦОДы платформы, обычные онлайн-платежи останавливаются, поскольку центральный ledger является источником актуального состояния системы.
Чтобы ЦР продолжал работать неделю, нужна фактически автономная платёжная архитектура.
Например, вместо обычной цепочки Wallet → Bank → Platform → Ledger появляется Wallet → Secure Element → Offline Token → Wallet/POS.
Цифровой рубль при этом должен представляться защищённым криптографическим объектом с идентификатором, владельцем, nonce/counter, сроком действия и цифровой подписью.
Главная проблема — double spend: без ЦОД нельзя просто спросить сервер, не потратил ли пользователь эти деньги несколькими магазинами одновременно.
Поэтому нужны аппаратные ограничения Secure Element, лимит офлайн-баланса, максимальная сумма операции, ограничение количества транзакций и срок действия автономного состояния.
Например: Online balance = 150 000 ₽, но Offline allowance = 20 000 ₽, которые можно потратить только в автономном режиме.
Каждая операция записывается в защищённый локальный журнал и может быть связана с предыдущей через Hash(TX[n-1]) + Signature.
А для действительно серьёзной аварии я бы добавил резервные и региональные DR-узлы, которые временно принимают журналы операций и проверяют подписи, но не могут создавать новые цифровые рубли или самостоятельно увеличивать балансы.
Получается трёхуровневая модель: ЦОД ЦБ = источник истины, DR/Regional Node = аварийный контур, Wallet/Secure Element = автономный контур пользователя.
После восстановления инфраструктуры происходит Offline Wallet → Bank Gateway → DR/Platform → Reconciliation → Ledger ЦБ, где система сверяет накопленные операции.
То есть офлайн-режим сам по себе не означает, что ЦР сможет неделю работать при полном отключении ЦОДов — для этого нужен заранее спроектированный автономный платёжный контур с anti-double-spend, криптографическим контролем и механизмом последующей синхронизации.