Хотите узнать больше о том, что делает Cartesi безопасным?
Это "Metering". Metering — это концепция безопасности, которую мы недавно рассмотрели в ходе нашего созвона на канале R&D, и она работает следующим образом: 👇
Обычно вы опасаетесь запускать код из ненадежных источников. Это делает вашу систему уязвимой для злоумышленников, которые могут внедрить код, использующий ваш собственный.
Но если вы предлагаете услугу, вы должны быть готовы для запуска кода обычными пользователями. Проблема в том, что злоумышленниками могут быть и обычные пользователи… 🔎
Традиционно существуют способы защиты среды выполнения, такие как:
🚧Выделенное пользовательское пространство и разрешения в ОС
🧰Аппаратные ограничения, такие как гипервизоры.
У злоумышленников есть разные способы обойти эту защиту. Они могут:
🪪Повысить свои привилегии
🛣Открыть боковые каналы
Иногда просто тормозят сервис…
В Web3 у нас немного другой сценарий. Виртуальные машины Web3 запускают код только тогда, когда транзакция отправляется в смарт-контракт, поэтому мы не подвергаемся риску заражения нашего собственного кода внешним кодом. 🦾
Но у нас есть смарт-контракты, которые могут взаимодействовать с другими смарт-контрактами. Это означает, что действия злоумышленника обычно будут заключаться в развертывании вредоносного смарт-контракта. 👾
Известным примером этой проблемы является атака повторного входа. Но часто упускаемый из виду пример — это злоумышленники, предпринимающие атаку на истощение ресурсов.
Опять же, иногда просто могут замедлить работу сервиса… 🐌
Вот тут-то и приходит на помощь metering. 📏
Обычно такие системы, как EVM, предоставляют смарт-контрактам «бюджет» на то, сколько газа они могут потратить при вызове других небольших контрактов.
Мы можем назвать это «adversarial metering».
Но здесь у нас все еще есть проблема — это очень дорого по двум причинам:
Любая операция должна быть metering.
Придется взимать плату на основе анализа «наихудшего сценария».
Cartesi изучает то, что мы бы назвали «совместным metering».
Cartesi запускает накопительные пакеты для конкретных приложений, где есть один автор кода. Это исключает возможность внедрения вредоносных смарт-контрактов кем-либо, кроме разработчика dApp. 😌
Общая картина: мы имеем ситуацию, когда доверие идет только в одном направлении:
Пользователь ➡️ Разработчик ➡️ Валидаторы
Эта установка фактически максимизирует масштабирование и может работать без наложения ограничений на газ.
Довольно аккуратно, правда?
Есть дополнительные детали реализации и подходы к тонкой настройке, которые мы обсуждали во время телеконференции по исследованиям и разработкам.
Полную запись смотрите на Youtube: