Solidity *

Интернет вещей (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, похоже, на данный момент является ответом.
Эта статья в блоге не предназначена для освещения ноу-хау блокчейна и децентрализованных систем. Вместо этого он предназначен для тех, кто хотел бы создать онлайн-решения для пользователей, клиентов и покупателей, чтобы гарантировать им лучшую конфиденциальность и безопасность их данных.
Прояснив это, в данной статье я собираюсь показать вам азбуку того, как создать децентрализованное приложение с нуля и настроить среду разработки. Ниже перечислены некоторые темы, которые мы рассмотрим.

В этой статье хотим рассказать про протокол кроссчейн совместимости (CCIP) для децентрализованного обмена сообщениями/событиями и перемещения токенов между блокчейнами.

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

Чтобы удовлетворить растущий спрос экосистемы на кросс-чейн решения, мы рады рассказать о предстоящем запуске Cross-Chain Interoperability Protocol (CCIP) - нового стандарта с открытым исходным кодом для кросс-чейн совместимости. Цель CCIP - установить универсальную связь между сотнями сетей блокчейн, как частных, так и публичных, разблокировать изолированные токены и расширить возможности кросс-чейн приложений для всех экосистем на блокчейне.

На момент написания статьи я работаю 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.

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

Мы продолжаем создавать клон Uniswap V1!

Наша реализация почти готова: мы реализовали все основные механики смарт-контракта Биржи, включая функции ценообразования, обмена, выпуска LP-токенов и сбора комиссии. Похоже, что наш клон завершен, однако нам не хватает смарт-контракта Фабрики.

Сегодня мы реализуем его и наш клон Uniswap V1 будет завершен.

Продолжаем серию статей про язык Solidity и платформу Ethereum. В этой статье будет рассказываться про адреса в Ethereum. Статья была написана в августе 2019 года, с той порой язык изменился, поэтому несоответствия в описании автора были исправлены.

Во введении проведено сравнение Ethereum адресов с почтовыми адресами в реальном мире.

Техническая часть начинается с раздела "Что такое (технически) адрес в Ethereum?"

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

Сегодня мы собираемся закончить реализацию Uniswap V1. Хотя это не будет полная копия Uniswap V1, но она будет иметь все основные функции.

Эта часть наполнена новым кодом, поэтому давайте перейдем непосредственно к нему.

Лучший способ научиться чему-то - научить других. Второй лучший способ научиться чему-то - сделать это самому. Я решил объединить эти два способа и научить себя и вас программировать DeFi сервисы на Ethereum (и любых других блокчейнах, основанных на EVM - Ethereum Virtual Machine).

Мы сосредоточимся на том, как работают эти сервисы, попытаемся понять экономическую механику, которая делает их такими, какие они есть (а все они основаны на экономической механике). Мы будем выяснять, разбирать, изучать и создавать основные механизмы DeFi.

Давайте начнем наше путешествие с Uniswap!

В документации Solidity модификаторы определяются следующим образом:

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

Из этого определения можно понять, что модификатор направлен на изменение поведения функции, к которой он присоединен.

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

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