Solidity *

Многим из вас, наверное, известно, что в теории, смарт-контракты в EVM-подобных системах, являются неизменяемыми (immutable), но на практике это уже давно не так. И речь даже не о таких свойствах как Pausable, то есть каких-то переменных состояния контракта, которые могут влиять на его работоспособность, а о более серьезных возможностях изменения бизнес-логики контракта. В этой статье я опишу основные приемы и остановлюсь подробнее на одном из них, на BeaconProxy.

Привет! Для меня некоторое время было удивительно, почему некоторые проекты стали выбирать ERC-721 протокол для выплаты дивидентов, неужели это дань моде? Но поразмыслив немного, я, кажется, пришел к пониманию в чем преимущества этого подхода.

В этой статье не будет деталей о самих протоколах, только мои рассуждения об их применении.

В этой статье я расскажу как с помощью микроконтроллера ESP8266 подключиться к приватной Ethereum сети и вызвать смарт-контракт.

Основная задача:

Изучить, как хранить данные IoT на комбинации on-chain (Ethereum Blockchain) и off-chain хранилищ (IPFS и Ethereum Swarm) в зашифрованном виде и использовать их в модели публикации-подписки в режиме реального времени без использования каких-либо протоколов M2M, таких как MQTT или CoAP. Оценить производительность этой системы с точки зрения количества транзакций, которые могут быть выполнены в секунду и оптимизировать ее работу.

Предыдущие части статьи:
Безопасное хранение данных IoT в частном блокчейне Ethereum. Часть 1
Безопасное хранение данных IoT в частном блокчейне Ethereum. Часть 2

В этой части статьи в главе 6 мы проводим эксперименты по хранению данных с использованием традиционных баз данных, а также предложенной системы с использованием Ethereum Blockchain, IPFS и Swarm. Чтобы понять стоимость безопасности IoT, мы проводим эксперименты по оценке производительности предложенной системы.

В главе 7 мы попытаемся обобщить выводы, сделанные в данной статье, и завершим ее ретроспективным обзором 2 измерений производительности этих систем хранения данных вместе с блокчейном.

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

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

Для измерения стоимости вызова функций смарт-контракта, а также для изучения распределения памяти подготовим стенд в виде проекта Hardhat.

Напомним про основную задачу:

Изучить, как хранить данные IoT на комбинации on-chain (Ethereum Blockchain) и off-chain хранилищ (IPFS и Ethereum Swarm) в зашифрованном виде и использовать их в модели публикации-подписки в режиме реального времени без использования каких-либо протоколов M2M, таких как MQTT или CoAP. Оценить производительность этой системы с точки зрения количества транзакций, которые могут быть выполнены в секунду и оптимизировать ее работу.

Краткое содержание данной части статьи:

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

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

Интернет вещей (IoT) — это набор технологий, которые позволяют подключенным к сети устройствам выполнять действия или обмениваться данными между несколькими подключенными устройствами или с общей базой данных. Действия могут могут быть любыми: от дистанционного включения кондиционера воздуха до включения зажигания автомобиля с помощью команды, поданной из удаленного места, или попросить Alexa или Google Assistant найти информацию о погодных условиях в том или ином районе. IoT доказал свою эффективность во многих отраслях промышленности таких как цепочки поставок, доставка и транспортировка, предоставляя информацию о состоянии грузов в режиме реального времени. Это привело к появлению огромного количества данных, создаваемых множеством таких устройств. которые необходимо обрабатывать в режиме реального времени.

В данной статье мы предлагаем метод сбора информации с датчиков устройств IoT и использования блокчейна для хранения и получения собранных данных для безопасного и децентрализованного хранения и извлечения собранных данных в рамках закрытой системы, подходящей для одного предприятия или группы компаний в таких отраслях как, например, судоходство, где требуется обмен данных друг с другом. Подобно блокчейну, мы представляем себе будущее, в котором устройства IoT смогут подключаться и отключаться к распределенным системам, не вызывая простоя в сборе и хранении данных или не полагаясь на облачные технологии хранения или полагаться на облачную систему хранения для синхронизации данных между устройствами. Мы также рассмотрим производительность некоторых из этих распределенных систем, таких как Inter Planetary File System (IPFS) и Ethereum Swarm на маломощных устройствах, таких как raspberry pi. 

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

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

Понять о чем я говорю без базового опыта в solidity будет очень сложно, но может быть эти оптимизации проявят в вас интерес в ethereum программировании.

Концепция mapping в Solidity аналогична HashMap в Java или dict в Python.

Нет ничего лучше, чем аналогия с реальным миром, чтобы понять, что такое mapping в Solidity и как он себя ведет. Следующий пример был взят из поста на Reddit:

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

Другими словами, mapping позволяет эффективно находить местоположение данных, соответствующее заданному ключу.

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

Самым известным примером этого был взлом DAO, в ходе которого был выведен эфир на сумму 70 миллионов долларов.

Так что же такое уязвимость повторного входа? Как это работает и как это предотвратить?

Механизм

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

Пример из реальной жизни - взлом DAO

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

Комментарии используются для того, чтобы объяснить что делает код. Роберт С. Мартин ("дядюшка" Боб) утверждает, что «правильное использование комментариев должно компенсировать нашу неспособность выразить что-то в коде». Поэтому комментарии делают исходный код более понятным для человека.

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

Прежде чем заняться изучением смарт-контрактов Ethereum, необходимо подготовить рабочую среду — установить операционную систему (ОС) Ubuntu, клиента Geth сети Ethereum, а также другое необходимое программное обеспечение (ПО).

Мы могли бы приступить к работе сразу в какой-либо интегрированной среде разработки (IDE, Integrated Development Environment), например, Remix. Возможно, это был бы самый быстрый путь к изучению смарт-контрактов Solidity. Однако для того, чтобы глубже разобраться в работе Ethereum, мы начнем с базовых инструментов.

Добрый день, читатели Хабра, представляю перевод статьи по разработке dApp. Приятного чтения.

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

На момент написания статьи я работаю Frontend-разработчиком в VK (Delivery Club) на Vue и плавно перехожу на iOS-разработку. Уже около 4 лет считаю себя поверхностно приближенным к сфере крипты: участвовал в разработке P2P-платформы (BTC-обменника), изучал основы и идеологию, инвестировал, терял деньги на фьючерсах — все, как надо.

Однажды, по интернету стала расходиться новость о том, что 12-летний мальчик заработал ~$350,000 на коллекции программно-сгенерированных китов, состоящей из 3350 уникальных айтемов.

Так мне пришла мысль внести свою лепту. К тому же, как показывает практика, это потенциальный способ заработка в наше время :)

Привет Хабр. 

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

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

Мы создадим типовой смарт-контракт для нашей NFT коллекции, протестируем и загрузим созданный смарт-контракт в тестовую сеть Ethereum. Но прежде, чем мы приступим к кодингу, мне хотелось бы остановиться на ERC-721 стандарте, данный стандарт описывает спецификацию NFT токенов.

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

Смарт-контракты представляют огромный потенциал преобразить то, как независимые структуры вступают в контрактные обязательства и производят платежи. Отдельно от индустрии смарт-контрактов, мы имеем огромную традиционную цифровую экономику, состоящую из множества устройств, связанных с помощью интернета, и производящих вычисления онлайн. Производный продукт такой цифровой инфраструктуры — постоянно увеличивающийся объем данных и API, который дает представление о том как все в нашем мире работает; например, результаты поиска, выдающие самые популярные темы, или сенсоры IoT (Internet of Things или Интернет Вещей) предлагающие наиболее распространенные модели трафика.

Смарт-контракты построенные на блокчейн и традиционные базы данных и API имеют огромный потенциал для объединения в гибридные смарт-контракты и создания новой архитектуры для автоматизации баз данных. Но как связать эти два мира? В этом и заключается “Проблема оракулов” — главная тема этой статьи.

Статья разделена на пять частей:

Эксперт в области информационной безопасности Гехард Вагнер получил рекордное вознаграждение в размере 2000000$ от команды блокчейн проекта Polygon. Найденная исследователем уязвимость угрожала потерей 850000000$. Вознаграждение стало рекордным в истории DeFi. Гехард Вагнер обратил внимание на баунти-программу, которую Polygon запустил сентябре. Он отметил, что Polygon использует для защиты транзакций между своими сетями и Ethereum систему защиты Plasma, которую, по его мнению, сложно надежно реализовать. Вагнер подробно рассказал о том, как обнаружил уязвимость в «мосте» Plasma Bridge. С помощью ошибки в коде злоумышленник мог бы вывести сумму, в 223 раза превышающую первоначальную стоимость токенов. Внесение каждых $200 тыс. могло бы принести потенциальному хакеру $44,6 млн. В случае эксплуатации уязвимости потери протокола могли составить $850 млн. Вагнер предположил, что проблема возникла «из-за использования стороннего кода без его полного понимания».

Вагнер отметил, что ранее уже работал над системами защиты от мошенничества, в частности над «Плазмой» и знал основные сложности, с которыми сталкиваются разработчики. Поэтому сразу начал проверять опубликованные контракты, чтобы найти тот, который блокирует средства на L1, когда пользователи переводят средства в сеть Polygon и из нее. Он быстро нашел нужный контракт Deposit Manager Proxy, и на момент написания он содержал токены стоимостью около миллиарда долларов США.

Далее разберем найденную уязвимость.

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

“Библиотеки можно рассматривать, как неявные базовые смарт-контракты для смарт-контрактов, которые их используют” из документации языка Solidity

Библиотека в Solidity - это тип смарт-контракта, содержащий многократно используемый код. После развертывания в блокчейне (развёртывается только один раз) ему присваивается определённый адрес, а его свойства / методы могут многократно использоваться другими смарт-контрактами в сети Ethereum.

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