Solidity *

Концепция 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.

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

Мы продолжаем создавать клон 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 модификаторы определяются следующим образом:

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

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

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

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

Часть 2. Возможное решение проблемы монетарного дефицита.

Спойлер: это IOUномика - экономика долговых обязательств.

Здесь часть 1, где ставится проблема денежного дефицита и автор пытается найти ее причины.

Как уменьшить бедность и при помощи технологий индивидуальных “прозрачных денег” и ресурсной кооперации.

Первая часть лонгрида про создание персональных денег с обратной связью в виде ERC20 токенов и как с их помощью можно порешать разные социально-экономические проблемы.

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

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

Идентификация пользователей на сайтах без "зарегистрироваться", "забыл пароль" с помощью пары кликов в браузере. Один или сто аккаунтов одного пользователя на одном или ста проектах под его собственным контролем. Так это делают в децентрализованных сетях и DeFi. Простота и доступность этого паттерна позволяет использовать для авторизации пользователей почти любой блокчейн, даже самый простой, так как абсолютно любой блокчейн использует приватные и публичные ключи для идентификации своих пользователей. Но при использовании полноценных смарт-контрактов, эта схема может быть доработана до любого уровня сложности и иметь любые административные функции, присущие централизованным identity системам. Поехали...