Прокси-контракты: Сравнение подходов OpenZeppelin и EVMPack

Обновление смарт-контрактов в mainnet - задача нетривиальная. Развернутый код неизменяем, и любая ошибка или необходимость добавить функционал требуют сложных и рискованных миграций. Для решения этой проблемы используется паттерн "прокси", позволяющий обновлять логику контракта, сохраняя его адрес и состояние.

Что такое прокси-контракт?

Прокси-контракт - это простой контракт-переадресатор. Он хранит адрес основного, "логического" контракта. При вызове функции на прокси, он перенаправляет вызов (через delegatecall) на контракт с логикой.

Особенность delegatecall в том, что код исполняется от имени прокси-контракта, то есть в его контексте хранилища (storage). Это позволяет менять адрес контракта с логикой, в то время как все данные (состояние) остаются на адресе прокси. Для обновления достаточно просто указать прокси новый адрес реализации.

Так получилось что этот проект внезапно родился пока я создавал другой.

В мире блокчейна, разработка под экосистему ethereum очень сильно развита, много смарт контрактов "готовых", которые прошли аудит, много разных инструментов таких как Slither, Foundry, Hardhat и т.д., с ними комфортно писать контракты и тестировать.

Что делать со всем этим дальше? Нет инструментов которые бы меня устроили, или я не нашел, все идет на откуп команды разработчиков, то как они построят процесс обновления смарт контрактов, аудит, безопасность и т.д.

Честно говоря, на мой взгляд тут просто какой то бардак. Используются подходы к сопровождению проектов из обычной сферы разработки, но мы же с вами работаем с распределенным компьютером EVM и работаем почему то напрямую, без операционной системы.

Давайте вспомним что должна делать операционная система для классической ЭВМ:

• Поддержку нормальных url типа sitename.ru
• Не редактировать /etc/hosts
• Не редактировать конфиги nginx
• Работать в локальной папке
• Удобное администрирование конфигурации сервера
• Изолированое окружение
• Поставить и забыть