Интересные новости: новый стандарт ERC-3475

Вчера в новостях была новость, что Ethereum Foundation приняли  новый стандарт ERC-3475 для введения облигаций в экосистему Ethereum.

ERC-3475 позволит каждому создавать облигации, это то, что нужно DeFi прямо сейчас.

В 2015 году Виталик Бутерин ввел стандарт токенов ERC-20 благодаря которому позже произошел бум токенов, развитие DeFi и DAO.

Позже был стандарт ERC-721, который позволил создавать NFT. И это изменила крипто мир и позволило появиться гигантам вроде OpenSea.

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

И все это работает на языке Solidity! Эта профессия точно будет востребована в ближайшие 5-10 лет.

Вы большие молодцы, что начали учить этот язык вместе со мной!

#новости

Урок 19 - MultiSig и Timelock

Прошли выходные, началась новая трудовая неделя и она же последняя этого лета.

Очень надеюсь, что у вас было время посидеть с двумя последними контрактами и разобраться, в чем там дело. Последующие две недели будут чуть легче в плане обучения, так как мы будем разбирать паттерны контрактов, а уже после мы рассмотрим ERC721, на базе которого создаются NFT.

В сегодняшнем уроке не одно, а сразу два видео, так как они, по своей сути, взаимосвязаны.

Видео урок про Timelock и урок про MultiSig
(тут две ссылки!)

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

Приятного просмотра и легкого понимания.

#урок #timelock #multisig

Концепция Timelock

Для начала попробуем разобраться, что такое timelock.

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

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

При этом сам контракт timelock довольно простой: всего пара функций: добавление в очередь, удаления и исполнения.

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

При добавлении в очередь нам нужно проверить соответствует ли метка времени минимальному и максимальному отсрочиванию транзакции, а также хешируем информацию через keccak256 и abi.encode(). После чего ставим в очередь.

При удалении - просто находим данную транзакцию в очереди и удаляем ее.

Тут интерес представляет именно функция выполнения транзакции.

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

Далее нам следует узнать, нужно ли передавать какую-либо функцию в транзакции. И так как в нашем случае функция выступает в роли string, мы переводим ее в байты и там проверяем длину. Если длина будет больше "0", то значит, что функция для передачи существует.

В этом случае мы создаем новую переменную data, помещаем туда наши данные, которые уже в формате bytes, и кодируем информацию о функции через bytes4(keccak256(bytes())).

Именно с этим и возникают часто проблемы.

Поэтому тут нужно запомнить, чтобы передать функцию в низкоуровневом вызове, нам нужно string перевести в bytes, закодировать через keccak256 и взять первые 4 байта, где и содержится название функции.

Я сам еще осваиваю работу с памятью в Solidity, поэтому не могу расписать ее еще более простым языком.

Так или иначе, это и есть паттерн timelock: хешируем информацию, задаем временные рамки и проводим транзакцию, когда это возможно.

#timelock

Концепция MultiSig

MultiSig, или multi signature, это такой подход в реализации смарт-контрактов, когда для выполнения какой-либо транзакции требуется ее одобрене нескольких пользователей.

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

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

Затем для простоты работы с транзакциями, мы создаем структуру transactions.

В функции подтверждения мы проверяем голосовал ли ранее данный адрес и есть ли вообще данная транзакция в списке. Если все ок, то добавляем голос "за".

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

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

#multisig

Урок 20 - Паттерн commit/reveal

Продолжаем наше обучение по паттернам смарт-контрактов, и сегодня рассмотрим commit\reveal.

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

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

После всех уроков с YouTube от Ильи, я скину на канал несколько интересных ссылок. В одной из них будут прикольные упражнения на создание смарт-контрактов. Там вы сможете на практике попытаться самостоятельно реализовать контракты.

А пока, новый видео урок.

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

Всем хорошего дня и легкого обучения!

#урок #commit #reveal

Паттерн commit/reveal

Для начала давайте расшифруем, что такое commit и reveal для тех, кто только начал свой путь в программировании.

По сути, commit - это добавление какой-либо информации куда-либо. Коммитом можно назвать, когда вы отдаете свой голос за кандидата на сайте (отправляете лайк за него в базу данных портала), или вносите правки в код на GitHub (отправляете обновленный код в файл текущего кода программы). Пример довольно грубый, но должен быть понятен.

А reveal - это раскрытие данных. Как, например, в покере, когда в конце раунда все раскрывают свои карты.

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

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

Мы же помним, что с помощью keccak256 можно только закодировать данные в формате bytes32, но раскодировать обратно их не получится?

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

Если хоть одна часть, один символ в отсылаемых данных будет изменен, то система выдаст ошибку. Именно поэтому обмануть ее не получится.

Ну вот и весь смысл паттерна commit\reveal. Все довольно просто.

#commit #reveal

Урок 21 - DAO и Governance

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

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

Видео урок про DAO и Governance

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

Приятного дня и легкого обучения!

#урок #dao #governance

Подробнее о DAO

Для начала нам нужно понять, а что такое DAO вообще?

DAO или Decentralized Autonomous Organization (Децентрализованная автономная организация) - это такой тип смарт-контрактов, который позиционирует себя, как отдельное лицо (организация), через которое происходит управление другим смарт-контрактом.

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

Каждый пользователь, у которого есть токен этого DAO - может принимать участие в голосовании и управлении контрактами.

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

Так вот, мы пишем еще один контракт (governance) для управление первым контрактом и выпускаем специальные токены на базе ERC20, которые распределяем между участниками.

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

В управляющем контракте создается голосование, по итогам которого принимается решение. 

Также в governance можно прописать дополнительные правила для участников, чтобы сделать голосование еще более прозрачным и равноправным. Например, что решение может быть принято, если 51% голосующих одобрит его. Или 1 токен будет равен 1 голосу. Или еще что-либо.

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

#dao #governance

В двух словах о Governance

Governance - это смарт-контракт, который управляет другим контрактом через голосование его участников при помощи токенов ERC20.

#dao #governance

Описание контракта Governance из урока. Часть 1

Для начала обратите внимание, что было создано 4 контракта и 1 интерфейс.

Контракты ERC20 и IERC20 мы уже разбирали ранее, поэтому мы должны уже знать, что они отвечают за выпуск токенов.

Контракт MyToken - выпускает токены для наших пользователей, которые будут создавать голосования и принимать участие в них.

В контракте Demo, над которым мы и будет брать управление, стоит обратить внимание на функцию transferOwnership(). Именно через нее, при деплое контрактов, мы будем передавать владение от пользователя, развернувшего его, к контракту Governance.

Далее идет Governance контракт.

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

Создаем две структуры: proposalVote и Proposals, где ведем подсчет голосов, а также время голосования и исполнения. Это можно было объединить и в одну структуру, но по словам лектора, через два struct достигается большая гибкость в работе с функциями в дальнейшем.

Затем создаем enum для описания статуса голосования, а также два mapping, которые содержат в себе адреса, как ключи, и структуры, как значения. Это нужно для того, чтобы по id предложения можно было легко ориентироваться в его статусах и находить значения.

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

Далее переходим к функциям.

#dao #governance

Описание контракта Governance из урока. Часть 2

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

Также создаем функцию для определения состояния (enum) предложения. Для этого берем из storage (так как предложение уже находится там после своего создания) и проверяем значения, в соответствии с которыми выставляем статус состояния.

Затем можно написать функции создания, исполнения и голосования.

В функции создания предложения мы принимаем необходимую информацию, создаем уникальный id через generateProposalId() и сохраняем в mapping структуру. При этом не забываем выполнить проверку на наличие токенов у пользователя, для создания предложения. И в конце возвращаем id.

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

В функции исполнения голосования мы принимаем все те же данные, что и в предыдущих функциях. Генерируем id и проверяем его статусы и наличие в базе.

Затем определяем его статус, как исполненный и через низкоуровневый вызов отправляем данные в контракт, которым управляем. 

#dao #governance

Деплой и тесты контрактов из урока. Часть 3

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

В этом уроке лектор использовал typenoscript и typechain, с которыми я ранее не сталкивался в этой реализации. Поэтому, если вы также ничего не поняли, есть два варианта:

1. Вы можете сами поискать информацию об этом в сети, сделать пост или поскидывать материал в чат канала;

2. Немного подождать. Про typechain есть отдельный урок у лектора, который мы будем проходить послезавтра. А по деплою контрактов я планирую выделить день-два на следующей неделе. Там я постараюсь найти информацию о плагинах, библиотеках, функциях и т.д. по этой теме, и написать разборы.

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

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

Мы учим язык всего 1,5 месяца. И если вы занимаетесь вместе со мной, то уже знаете столько, сколько другой ученик получает за пол-года или даже больше! И этим точно можно гордиться!

#dao #governance

Урок 22 - Паттерн Proxy/Upgradeable: Transparent, UUPS

Сегодня у нас очень интересный урок, особенно для новичков в Solidity.

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

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

Видео урок о proxy.

Что нужно взять из этого урока?

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

Во-вторых, из этого урока можно разобраться, как работать с openzeppelin, таким хранилищем смарт-контрактов, откуда можно брать примеры или создавать наследования.

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

Приятного дня и легкого обучения!

#урок #proxy #upgradeable #transparent #uups

Паттерн Proxy

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

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

С этими проблемами и призван бороться прокси паттерн. Так как он работает?

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

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

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

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

#proxy

Паттерн Transparent Proxy

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

Однако остается вопрос, а что делать, если у нас две одинаковые функции, два одинаковых селектора, и в прокси и в контракте исполнения?

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

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

#proxy #transparent

Паттерн UUPS Proxy

UUPS или Universal Upgradeable Proxy Standard (Универсальный Обновляемых Прокси Стандарт) - более новый и легковесный прокси контракт.

В случае UUPS все админские функции находятся в контракте исполнения, а не в самом прокси. По сути, тут нет ничего, за исключением логики перенаправления в другой контракт.

#proxy #uups

Паттерн Diamond Proxy

Есть еще один вид прокси контрактов под названием Diamond. В этом уроке мы его не рассматриваем, но упомянуть стоит.

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

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

#proxy #diamond

Простая идея реализации прокси контракта

В начале урока лектор приводит пример простой реализации прокси контракта. Так вот, его использовать не надо! Он показал его просто для того, чтобы вы поняли основную суть данного паттерна.

Я просто повторю основные моменты тут.

Есть контракт Proxy, в котором всего три функции: setImplementation(), _delegate() и fallback().

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

В _delegate() как раз прописывается логика отправки запроса и получения ответа в исполняемый контракт при помощи delegatecall.

Тут интересно то, что написана она с помощью assembly. Мы принимает селектор функции из исполняемого контракта (берем его из памяти), затем передаем через delegatecall в другой контракт и принимаем оттуда ответ. Если приходит "0", то показываем ошибку, так как данных нет, а значит в другом контракте что-то пошло не так. Если данные получены, то показываем их.

Также интерес представляет функция fallback(). Как мы помним, она вызывается в том случае, когда в контракте нет функции с таким именем, которую пытаются тут вызвать. Следовательно, в этом случае вызывается fallback, которая в свою очередь вызывает _delegate.

И вот по этой цепочке и происходит работа прокси. При этом все данные остаются тут, а не в исполняемом контракте.

Это самый простой способ работы с прокси, поэтому еще раз повторяю, что его не следует использовать в реальных проектах!

#proxy #upgradeable #transparent #uups

Наследование из openzeppelin

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

Сделать это можно двумя способами. И так как тема у нас про обновляемые контракты, то сразу покажу установку для них.

1. Вам необходимо прописать следующие строки в консоли:

npm install @openzeppelin/contracts
npm install --save-dev @openzeppelin/hardhat-upgrades
npm install --save-dev @nomiclabs/hardhat-ethers ethers # peer dependencies

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

2. Можно также зайти в файл package.json в папке своего проекта, и в блоке dependencies прописать:

"@openzeppelin/contracts": "^4.7.2",
"@openzeppelin/contracts-upgradeable": "^4.7.2"

Затем зайти в консоль и выполнить команду:

npm install

После чего у вас установятся все необходимые пакеты.

При этом после добавления openzeppelin/contracts-upgradeable вам следует открыть файл hardhat.config.json в своем проекте и добавить строки в начале:

import "@openzeppelin/hardhat-upgrades";
(если вы используете typenoscript)

или

require('@openzeppelin/hardhat-upgrades');
(если используете javanoscript)

После этого уже в файле своего контракта вы сможете импортировать контракты openzeppelin и наследовать от них. Для этого нужно будет добавлять следующие строки (как в примере урока):

import "@openzeppelin/contracts-upgradeable/token/ERC721/ERC721Upgradeable.sol";
import "@openzeppelin/contracts-upgradeable/token/ERC721/extensions/ERC721URIStorageUpgradeable.sol";

и т.д.

#proxy #upgradeable #npm #openzeppelin

Upgradeable ERC721. Часть 1

Отдельный урок про ERC721 у нас будет на следующей неделе, так как потребуется пара дней, чтобы научиться работать с ним. А сейчас мы, на его примере, рассмотрим, как работают обновляемые контракты.

Для начала нам нужно импортировать все необходимые обновляемые контракты с openzeppelin, а также прокси контракт Initializable.

Коммит по уроку можно посмотреть тут.

Так как конструкторы, как я понял из урока, в обновляемых контракта могут работать некорректно, было принято решение заменить его новой функцией initialize() с модификатором initializer. По правилам она вызывается только один раз при разворачивании контракта, поэтому ее можно как бы назвать неким конструктором обновляемых контрактов.

И уже в этой функции мы можем другие функции, с помощью которых можно установить владельца контракта или передать данные о токене, например, в ERC721.

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

#proxy #upgradeable #transparent