Описание стандарта ERC20. Часть 2

Пройдемся по функциям.

Ну, с первыми функциями name(), symbol(), decimals(), totalSupply(), balanceOf() - все просто, они возвращают только то, что чего предназначены, не выполняя никаких дополнительных действий внутри себя.

Дальше два модификатора на проверку владельца и количества токенов на каком-либо адресе.

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

В mint() создаются токены и отправляются на адрес магазина.

В burn() они уничтожаются, отправляясь на нулевой адрес.

С transfer() и fransferFrom() у меня были некоторые пролемы та тему, зачем их два. Потом я понял, что transfer() вызываем мы сами, по сути как владелец всех токенов, а transferFrom() - вызывают другие продавцы для перевода токенов.

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

Далее идет функция allowance(), которая возвращает uint. И как я выше писал, если количество "0" - то разрешения нет.

И две функции approve, одна из которых вызывает другую, служебную.

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

По сути, она всего лишь разрешает какому-то аккаунту передавать наши токены.

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

#erc20

Описание стандарта ERC20. Часть 3

А теперь попытаемся расписать контракт магазина для продажи наших токенов.

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

Далее, в конструкторе, мы через объект токена, с помощью функции "new MCSToken(address(this))", разворачиваем смарт-контракт нашего токена MCSToken, который в свою очередь при помощи наследования разворачивает ERC20.

Образно говоря, сначала мы создали некий объект, назвав его token для простоты, а затем наполнили его через контракт токена.

Благодаря этому действию, мы можем создать функцию tokenBalance(), которая возвращает нам количество токенов на каком-либо адресе, используя объект token и функцию из ERC20 balanceOf().

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

Тут мы делаем пару проверок на присланную сумму и количество токенов для перевода, и затем, с помощь объекта token вызываем функцию перевода - transfer().

Также тут представлена функция sell(), которая позволяем нашему магазину продавать токены с одного аккаунта на другой.

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

Именно поэтому мы вызываем дальше функцию не просто transfer(), а transferFrom().

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

Вот и вся реализация контрактов для создания и перевода токенов. Надеюсь, у меня получилось понятно расписать всю процедуру.

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

#erc20

Описание стандарта ERC20. Часть 4

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

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

Эти две темы мы оставим на потом. Думаю, нам стоит сделать отдельный день-урок для обучения деплоя контракта не только в локалку hardhat, но и другие сети, типа rinkeby.

Также и с подключением к Метамаск. Там есть несколько своих нюансов, которые стоят отдельного поста. Поэтому мы немного подождем и будем учиться подключать его для тестов с токенами и nft.

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

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

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

И вот с помощью abi (Application Binary Interface) контракта, мы можем подключиться к нему.

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

Для начала создадим переменную и поместим в нее json от нашего развернутого контракта магазина. В уроке было так:

const tokenJSON = require("../artifacts/contracts/Erc.sol/MCSToken.json")

Затем, при деплое, нам нужно подключаться к abi контракта

let erc20 = new ethers.Contract(await shop.token(), tokenJSON.abi, owner)

где shop.token() - адрес нашего токена, который мы продаем,
tokenJSON.abi - сам abi,
owner - от имени кого мы подключаемся.

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

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

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

#erc20 #abi

Интересные новости: новый стандарт 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