Предотвращение Непредвиденного Потребления RAM

Текст взят из англоязычного поста и переведен для русскоязычной аудитории!
Оригинал: https://medium.com/eosio/preventing-unexpected-ram-consumption-8029a9342659

Некоторые пользователи и смарт-контракты на основе EOSIO сталкиваются с ситуацией, когда невольно их RAM ресурсы (ресурсы оперативной памяти) потребляются вредоносными третьими сторонами, которые создали специализированные смарт-контракты. Это происходит из-за непонимания функции, предназначенной для того, чтобы контракты могли уведомлять другие контракты о событиях, например, входящем переводе. Вредоносные контракты используют эту функцию уведомления для заполнения оперативной памяти других людей случайными данными без информированного согласия, а затем не предоставляют никакой возможности удалить эти данные.

Обзор

Никаких токенов не было украдено
Правильно реализованные контракты не уязвимы
Процессы управления могут исправить поведение кода вопреки намерению сторон
Только для блок продюсеров существуют смягчающие опции и они доступны для защиты
Долгосрочное обновление может сделать стандартный режим более безопасным

Токены Не были Потеряны

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

Рекомендации по Предотвращению Злоупотреблений

Ожидается, что все пользователи проверят контракты, с которыми они взаимодействуют или доверят третьему лицу рассмотрение контрактов от их имени. Это означает, что обозреватели должны тщательно взаимодействовать со смарт-контрактами, использующими функцию уведомления. Одним из примеров является отправка токенов на смарт-контракты, которым они не доверяют с их CPU и RAM ресурсами.

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

Многие провайдеры кошельков уже предприняли действия для предупреждения пользователей о том, когда транзакция может использовать RAM.

Освобождение Потребляемой RAM с Помощью Процессов Управления

Я считаю, что цель кода, понятная пользователям и разработчикам, должна быть соблюдена. Если вредоносный контракт явно использует несоответствие между намерением пользователей и фактическим эффектом кода, тогда производители блоков имеют возможность внести этот контракт в черный список, в то время как через арбитраж решается спор между автором вредоносного контракта и теми, кто взаимодействовали с ним.

Если арбитраж сочтет, что поведение кода противоречит намерению сторон, которые взаимодействовали с этим кодом, тогда избранные продюсеры смогут обновить код таким образом, чтобы результат соответствовал первоначальному намерению сторон настолько близко, насколько это возможно. В этом случае код будет обновлен таким образом, чтобы освободить неожиданно использовавшуюся RAM и не потреблять RAM в будущем.

Почему это особенность EOSIO?

Существуют множество обоснованных случаев использования данной функции, которая потребляет RAM. Самый простой случай использования - это игровой контракт, который принимает депозиты пользовательских средств. Биржа применит код для обработки уведомления о передаче из токенового контракта, а затем кредитирует отправителя балансом на бирже. В этом случае биржа и пользователь, вносящий депозит, могут обоснованно разрешить биржевому контракту потреблять RAM пользователя для хранения своего баланса. Не обязательно, что биржа хотела бы хранить баланс пользователя в своей собственной RAM, потому что это могло бы привести к другой атаке, когда многие учетные записи отправляли бы даст балансы на биржу.

EOSIO имеет похожую функцию, встроенные действия, которая позволяет контракту вызывать код другого контракта как часть текущей транзакции. В отличие от функции уведомления о действиях, встроенные действия ограничиваются распределением ресурсов контракта, который генерируют встроенное действие. Уведомления о действиях передают разрешение на выделение ресурсов для исходного действия.

Предотвращение Непредвиденного Поведения в Дальнейшем

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

В будущем мы предлагаем, чтобы только обработчики уведомлений имели право использовать RAM контракта, получающего уведомление. Это сделает безопасным отправку токенов на любой контракт, не беспокоясь о том, что он сможет использовать вашу RAM неожиданным образом. Биржи смогут безопасно обрабатывать снятия, без необходимости проверять контракты, развернутые в учетной записи пользователя, перед обработкой заявки на вывод.

В соответствии с этим предлагаемым изменением, существующим контрактам придется получить прямое разрешение на потребление доступной RAM пользователя. Биржевой контракт попросит пользователя «открыть аккаунт для резервирования места для хранения своего баланса», прежде чем принимать депозиты от пользователя. Уведомление о входящем депозите затем просто добавится в предварительно выделенную RAM, а не будет занимать новую RAM.

Предлагаемый Путь Обновления
Только для продюсеров мы готовим обновление, которое изменит стандартное поведение с целью предохранить получателя уведомления о действии (например, уведомление о передаче токена) от неожиданно использования RAM отправителя. Если все производители блоков примут это обновление, тогда стратегии предотвращения злоупотреблений будут излишними. К сожалению, это смягчение может разорвать действующие контракты, пока они не будут обновлены до того, чтобы не полагаться на распределение RAM на учетных записях пользователей во время обработки уведомлений о действиях.

К счастью, процесс обновления контрактов для принятия новой передовой практики должен быть относительно прост.

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

Заключение

EOSIO ведет себя так, как было разработано, и является безопасным при правильном использовании. Мы считаем, что в большинстве случаев мы можем упростить использование EOSIO и работаем с сообществом EOS для разработки наиболее надежных общих решений.
Follow us!

Website: https://atticlab.net/eos/

Twitter: https://twitter.com/atticlab_it

Facebook: https://www.facebook.com/atticlab/

Reddit: https://www.reddit.com/r/atticlabeosb/

Steemit: https://steemit.com/eos/@attic-lab

Medium: https://medium.com/eosatticlab

Golos: https://golos.io/@atticlab

Telegram Chat: https://t.me/atticlabeosb

Telegram channel: https://t.me/eos_atticlab