Solidity *

Привет Хабр. 

В прошлых статьях мы научились генерировать 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 системам. Поехали...

Гифка за 580 000$, набор пиксельных панков за 7.5mil$ и Kings of Leon выпускающие свой альбом прямо на нем. О дивный новый мир искусства и какого черта в нем вообще происходит?

В этой статье я попытаюсь максимально кратко и информативно пройтись по всем пунктам создания создания полноценного Децентрализованного приложения в сети Ethereum используя JavaScript фреймворк - Vue для создания веб-приложения и библиотеку ethers.js для общения со смарт контрактом. Также будут рассмотрены некоторые моменты о том, как установить и подключить кошелек, как задеплоить контракт в сеть используя truffle и др.

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

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

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

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

Зачем нужны стандарты