Глава 2 — Безопасность: как сохранить активы в любой ситуации

CryptoLegacy сохраняет контроль владельца над активами в обычном режиме и использует модель исполнения по состояниям, когда владелец не может действовать, разрешая переводы лишь после ончейн-условий.

Алиса всегда относилась к безопасности в крипте серьёзно. Она защищала кошельки, регулярно делала безопасные бэкапы и следовала лучшим практикам. Но способы экстренного доступа, восстановления или «наследования» всё равно её напрягали:

• Мультисиг-кошельки или MPC: Сбой координации — реальный риск. Если один ключ потеряется или будет скомпрометирован, активы могут оказаться заблокированы или, наоборот, под угрозой. А зависимость от нескольких подписантов добавляет человеческие конфликты и риски доступности.

• Делиться мнемоникой (seed-фразой): Просто, но хрупко. Один утёкший или потерянный фрагмент — и можно получить мгновенную и необратимую потерю.

• Традиционное юридическое хранение (юристы, нотариусы, трастовые компании): Передача бэкапов или ключей посредникам создаёт новые поверхности атаки. Документы можно копировать, терять или использовать не по назначению, а юридические процедуры не умеют выполнять on-chain действия.

Вот почему Алиса выбрала CryptoLegacy.

С CryptoLegacy Алиса сохраняла полный контроль, пока была активна. Её активы оставались в её собственных кошельках и никогда не депонировались в сторонние контракты. Система работала как заранее заданная машина состояний: пока Алиса оставалась активной, никто другой не мог инициировать переводы или перемещать активы.

Заранее она назначила Хранителей — родственников, друзей или советников — которые могли действовать только в строгих рамках, заданных протоколом. Ни один Хранитель не мог запустить исполнение в одиночку. Требовался заранее заданный порог подтверждений, а затем — обязательный период оспаривания, прежде чем любые переводы становились возможны.

У Хранителей не было прямого доступа к средствам и не было видимости балансов. Даже если аккаунт Хранителя окажется скомпрометирован, это не приведёт к мгновенному исполнению. Их роль ограничена тем, чтобы добавить своё подтверждение для перехода системы в другое состояние — но не получить контроль.

Бенефициары тоже были ограничены по дизайну. Даже если аккаунт бенефициара будет взломан, активы нельзя будет вывести «всё сразу». Получить активы можно было только после того, как система перейдёт в состояние распределения и начнёт следовать заранее заданному графику Алисы, выдавая активы постепенно.

Когда Алиса попала в серьёзную аварию и оставалась без сознания несколько недель, вокруг неё быстро возникла неопределённость. Но её активы оставались недоступны для любых несанкционированных действий. Никто не мог обойти порог подтверждений, пропустить период оспаривания или ускорить исполнение. Только после того, как были собраны нужные подтверждения и пройдены временные проверки, система переходила в новое состояние и позволяла выполнить заранее заданные правила распределения.

Позже Алиса восстановилась. Используя заранее заданный механизм Восстановления, она вернула себе контроль над оставшимися активами, которые находились в контракте. Переводы, которые уже произошли, были окончательными — но никакие дополнительные активы не были раскрыты или перемещены раньше времени.

CryptoLegacy не убирает риск полностью. Но по дизайну он снижает самые критичные сценарии отказа:

• Активы оставались под контролем Владельца, пока не выполнены пороги подтверждений и временные условия.

• Исполнение требовало нескольких подтверждений, а не одного скомпрометированного участника.

• Период оспаривания защищал от спешки и ошибок при исполнении.

• Восстановление применялось только к оставшимся активам, без «переписывания» истории.

CryptoLegacy дал Алисе то, чего не давали другие подходы: модель безопасности, которая продолжает работать корректно даже тогда, когда Владелец не может действовать.

Твои ключи. Твоя крипта. Твоя безопасность.