Аудиторы

Аудит безопасности смарт-контракта McAfeeDEX проводился отделом безопасности Callisto Network. 5 аудиторов безопасности (включая меня) проверили контракт независимо. Затем менеджер по безопасности сравнил наши аудиторские отчеты и резюмировал описанные результаты.

Копии каждого аудиторского отчета и окончательное резюме можно найти здесь. С кратким изложением аудита безопасности можно ознакомиться здесь.

Обратите внимание, что наша процедура определения степени серьезности подразумевает, что разработчик контракта несет ответственность только за контракт, который мы проверили. Это означает, что некоторым проблемам, которые не имеют прямого отношения к проверяемому смарт-контракту, назначается «заметная» или «низкая» серьезность, но они все равно могут привести к финансовым потерям клиентов DEX, и это настоятельно рекомендуется. что разработчик контракта устранил эти проблемы до использования контракта.

Ниже я выделю наиболее важные вопросы.

Полученные результаты

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

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

Описанные проблемы, которые могут привести к финансовым потерям, не являются ошибками проверенного смарт-контракта, которые можно использовать напрямую. Эти проблемы являются недостатками архитектуры и экосистемы Ethereum, которые влияют на работоспособность McAfeeDEX.

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

Выводы

1. Проблемы с вводом / выводом токенов ERC20. Отсутствие функции извлечения ERC20.

Эта проблема может привести к финансовым потерям для клиентов McAfeeDEX.

Эта проблема не является ошибкой смарт-контракта McAfeeDEX, но она по-прежнему будет влиять на пользователей DEX. Эта проблема связана с проблемами стандарта токенов Ethereum.

У стандарта токенов ERC20 есть критическая проблема: в нем отсутствует обработка / отправка событий. Проблема описана здесь и здесь.

Есть два метода передачи токенов ERC20.

  1. передача функция (используется для обычных переводов)
  2. одобрить + передать по шаблону

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

В нормальной ситуации «событие» (в данном случае транзакция) обрабатывается получателем (в данном случае смарт-контрактом). Так работает передача эфира (ETH). Так работают банковские переводы. Всякий раз, когда отправляется недействительная транзакция, получатель отклоняет ее, и ничего плохого не происходит.

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

Следует отметить, что обработка событий - очень распространенная, широко распространенная и широко используемая практика в программировании. Отсутствие этой функции является серьезным недостатком, который может привести к финансовым потерям для конечных пользователей. Эта проблема уже привела к серьезным финансовым потерям для всей экосистемы Ethereum. По состоянию на 27 декабря 2017 года было потеряно примерно 3 200 000 долларов в токенах ERC20 из топ-7.

Хотя это в основном проблема стандарта токенов ERC20, проблема затрагивает смарт-контракт McAfeeDEX, поскольку он предназначен для работы с токенами ERC20. Для конечных пользователей это означает, что биржа не сможет зачислить депонированные токены, если пользователи выберут неправильный метод внесения токенов.

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

Ошибочно предполагать, что пользователи никогда не совершат эту ошибку. Пользователи совершат эту ошибку, и это приведет к финансовым потерям для них, как это было показано в приведенном выше примере убытков в размере 3 миллионов долларов.

Предположение, что пользователи несут ответственность за такие решения, также неверно, и это описано в параграфе Уязвимости программного обеспечения на странице Уязвимости в вычислениях в Википедии как Обвинение жертвы .

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

Пользователи должны использовать функцию передачи на большинстве бирж. Однако в случае с McAfeeDEX они никогда не должны использовать эту функцию и выбирать метод одобрить + transferFrom. Обычный пользователь не может принимать такого рода решения, потому что обычный пользователь может не иметь глубоких знаний о Solidity и внутренней логике смарт-контракта.

Контракт, прошедший аудит, является финансовой системой и должен быть отказоустойчивым. McAfeeDEX разработан для поддержки нескольких порталов, то есть нескольких вариантов пользовательского интерфейса. Джон Макафи поощряет людей создавать собственные порталы. Это означает, что разработчик смарт-контракта никогда не знает, что такое UI и как он будет выглядеть / работать. Будет несколько вариантов пользовательского интерфейса, и разработчик смарт-контракта не может гарантировать, что разработчики пользовательского интерфейса никогда не совершат ошибку.

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

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

Реальный пример того, как эта проблема уже привела к финансовым потерям

  1. Убытки в размере 3 200 000 долларов США описаны в разделе« Мотивация предложения ERC223».
  2. 77 000 долларов потеряно в смарт-контракте GNOSIS (220 000 долларов потеряно в других описанных контрактах).
  3. Пользователь непреднамеренно потерял $ 130 000 по контрактам SALT и ZRX.
  4. Смарт-контракт ENS вызвал финансовые потери пользователей из-за отсутствия функций обработки и извлечения транзакций ERC20.
  5. 22 марта 2019 года реализация токена BNB привела к убытку в размере $ 357 000.
  6. Сейчас (29.10.2019) в смарт-контракте BNB потеряно 480 000 долларов.
  7. Два пользователя потеряли токены USDC на смарт-контракте LINK. Перенос произошел 11.10.2019 - проблема крайне актуальная.
  8. Смарт-контракт MKR владеет токенами на сумму $ 400 000 (29 октября 2019 г.), хотя он не предназначен для получения / владения токенами. Все эти токены потеряны безвозвратно.
  9. $ 73 000 потеряно из-за смарт-контракта BAT (29.10.2019).
  10. 32 805 долларов потеряли из-за смарт-контракта Dai (29.10.2019).
  11. $ 31 000 потеряно из-за смарт-контракта MANA (29.10.2019).
  12. Смарт-контракту ENJ принадлежат еще 40 токенов. Все эти жетоны потеряны.

Рекомендация по решению вопроса №1

Есть несколько возможных решений.

  1. Используйте альтернативные стандарты токенов. ERC20 широко распространен, но это не единственный стандарт токенов в Ethereum. Существует Стандарт токенов ERC223, специально разработанный для решения описанной проблемы. Если вам не нравится ERC223, то ERC777 тоже подойдет.
  2. Вы не можете правильно обрабатывать переводы ERC20, но можете устранить последствия. Можно реализовать «функцию экстренного извлечения», которая будет служить для извлечения «застрявших» токенов из контракта. Затем вы можете отправить эти токены обратно пользователям, потому что относительно легко распознать, кому принадлежат эти токены, с использованием истории транзакций.
  3. Ethereum - не единственная платформа для разработки смарт-контрактов. Если будет другая платформа, не подверженная описанным проблемам, вы можете использовать ее вместо нее. Может оказаться невозможным построить БЕЗОПАСНЫЙ и ДЕЦЕНТРАЛИЗОВАННЫЙ обмен на Ethereum. Обмен либо небезопасен (т.е. подвержен проблеме ERC20), либо частично централизован, если вы реализуете функцию, которая извлекает застрявшие токены (потому что в какой-то момент вы будете владеть этими токенами). Однако это не создает риска потери средств для клиентов биржи, если они будут правильно использовать функции токенов.

2. Проблема коллизии кроссчейнов.

Теоретически эта проблема может привести к финансовым потерям для клиентов McAfeeDEX.

Эта проблема не является ошибкой смарт-контракта McAfeeDEX, но она по-прежнему будет влиять на пользователей DEX. Эта проблема связана с архитектурой Ethereum.

Метод генерации адреса Ethereum предполагает, что адрес действителен для каждой цепи, совместимой с Ethereum. В настоящее время существует большое количество сетей на основе кода Ethereum, в которых схема генерации адресов идентична. Лучший пример - Ethereum Classic.

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

Это не прямая проблема смарт-контракта McAfeeDEX, а недостаток архитектуры Ethereum. Ethereum никогда не предназначался для обработки взаимодействий между блокчейнами. Однако это реальная проблема, которую необходимо решить, и только создатель контракта может решить эту проблему. У нас уже есть реальный пример того, как 58 000 долларов были потеряны из-за контракта GNT в сети ETC.

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

Рекомендации по решению вопроса №2

  1. Адрес вновь развернутого контракта назначается на основе адреса создателя контракта и одноразового номера транзакции. Это означает, что создатель контракта может развернуть контракт по тому же адресу в любой из альтернативных цепочек на основе Ethereum. Рекомендуется развернуть версию вашей биржи или фиктивного контракта, которая предотвратит случайные депозиты (имейте в виду, что вам нужно убедиться, что вы можете извлечь застрявшие токены ERC20 из фиктивного контракта, как это описано в проблеме № 1) на любая из альтернативных цепочек.
  2. Рассмотрите возможность использования платформы разработки смарт-контрактов, которая была разработана с учетом межблочной работы.

3. Отсутствие возможности обновления и зависания.

Иногда может потребоваться обновить или отладить контракт. Это даже более важно, потому что проблема, требующая обновления контракта, уже обнаружена (см. Вывод №1: отсутствие функции извлечения ERC20).

Рекомендация по решению вопроса №3

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

2. Рассмотрите возможность использования платформы разработки смарт-контрактов, которая имеет встроенные функции обновления смарт-контрактов.

4. Проблемы соответствия ERC20.

Эта проблема может сбить с толку сторонних разработчиков смарт-контрактов, которые работают со смарт-контрактами McAfeeDEX.

В исходном коде проверенного смарт-контракта представлены токен-коды.

Описанный обмен предназначен для работы и с токенами ESH.

Токен, код которого представлен в аудируемом контракте, имеет некоторые несоответствия с определением стандарта токена ERC20. Хотя это не может вызвать никаких проблем для смарт-контракта McAfeeDEX, оно все же может вызвать проблемы для контрактов с третьими сторонами, которые будут зависеть от правильной работы смарт-контракта McAfeeDEX. Рекомендуется придерживаться определения стандарта ERC20, чтобы предотвратить подобные проблемы.

5. Test Trade не учитывает комиссии.

Эта проблема может сбить с толку сторонних разработчиков интерфейса.

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

Обращение к команде McAfeeDEX [субъективное мнение]

Все, что описано ниже, является личным мнением Dexaran и не отражает официальную позицию Callisto Network или объективные результаты аудита безопасности.

Ethereum не подходит для создания БЕЗОПАСНОЙ децентрализованной биржи. Вы должны рассмотреть возможность использования EOS в качестве лучшей платформы для разработки смарт-контрактов.

Описанные проблемы в основном относятся к экосистеме и архитектуре Ethereum. Вы можете возразить, что недостатки конструкции ERC20 - не ваша проблема. Вы можете возразить, что недостатки дизайна Ethereum - не ваша проблема. Однако команда McAfeeDEX несет полную ответственность за выбор Ethereum в качестве базовой платформы для развития этой биржи. McAfeeDEX несет полную ответственность за выбор стандарта ERC20 для работы с токенами.

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

Заявлено, что основная цель McAfeeDEX - помочь криптоиндустрии расти и развиваться. Централизованные обмены фиатной валюты на криптовалюту - одна из самых важных проблем, и я согласен с этим.

Любая система, в которой задействованы люди, подвержена человеческим ошибкам, и мы должны понимать это и относиться к этому серьезно. Ежедневно банки и банковские переводы обрабатывают тысячи ошибок. Использование токенов ERC20 не предполагает обработки ошибок - вместо этого все эти средства просто сжигаются. Как мы можем построить лучшую систему, если мы не можем служить настоящим людям? Даже если ваше программное обеспечение безопасно само по себе, оно все равно может привести к потере средств для ваших клиентов, потому что вы выбрали платформу, которая имеет серьезные недостатки в безопасности.

Хотя вы МОЖЕТЕ решить описанные проблемы с помощью некоторых исправлений, которые я описал, я настоятельно рекомендую не продвигать токены ERC20. Поддерживая токены ERC20, вы способствуете разработке небезопасных стандартов. Это побуждает разработчиков токенов использовать этот стандарт для разработки своих токенов. Даже если вы сможете реализовать решение для своего обмена - далеко не гарантировано, что любой другой разработчик любого другого программного обеспечения будет делать то же самое.

Вот пример того, как ведут себя разработчики токенов. Я процитирую соучредителя STORJ здесь:

Мы решили ошибиться на стороне хорошо протестированного кода.

© Соучредитель STORJ [знает, что это приведет к финансовым потерям для его клиентов]

Они знают, что их реализация содержит критические недостатки. Они знают, что это ПРИВЕДЕТ к финансовым потерям для их клиентов. Они знают, что могут это исправить, но все еще используют стандарт ERC20.

Токены ERC20 приводят к огромным финансовым потерям для всей экосистемы Ethereum, и это большая, ужасающая и катастрофическая проблема, и для криптоиндустрии невыгодно, если кто-то будет способствовать росту этой проблемы.

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

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