Описание стандарта ERC20. Часть 1
Когда я смотрел видео, мне казался сложным не столько сам контракт ERC20, сколько контракт магазина и сама идея разрешений на продажу токенов.
Постараюсь делать описания контрактов, как я сам их понял. Понятно, не претендую на 100% правильность, но, уверен, вы сможете найти для себя точки для старта.
Итак, для начала нам нужно создать переменные для токена: общее количество для ведения учета, имя токена и его символ, а также decimals.
Decimals я понимаю, но сложно переложить в текст мысли.
Вот представьте 1 Эфир. Когда он стал стоить слишком много, то транзакции нуждались в более мелких цифрах. Поэтому он как бы дробился, появлялись "нули" после запятой.
Стоимость газа определяется в gwei - 9 нулей, а минимальная величина wei - 18 нулей. Очень грубо говоря, это как в 1 рубле - 100 копеек.
И вот этот decimals определяет стоимость нашего токена в количестве нулей после запятой. И вот когда лектор определил число "18" в одноименной функции, он фактически приравнял стоимость своего токена к 1 wei.
Полагаю, это также было сделано для простоты расчетов в дальнейшем, чтобы не приходилось делать дополнительные математические операции для расчета количества токенов после получения денег на счет.
Помимо переменных нам потребуется два mapping: для учета количества токенов на различных адресах, а также разрешения на переводы наших токенов другими адресами.
В mapping allowances есть свой вложенный mapping, в котором uint и отображает количество токенов, которые он может перечислять. Соответственно, если значение "0", то разрешения нет.
#erc20
Когда я смотрел видео, мне казался сложным не столько сам контракт ERC20, сколько контракт магазина и сама идея разрешений на продажу токенов.
Постараюсь делать описания контрактов, как я сам их понял. Понятно, не претендую на 100% правильность, но, уверен, вы сможете найти для себя точки для старта.
Итак, для начала нам нужно создать переменные для токена: общее количество для ведения учета, имя токена и его символ, а также decimals.
Decimals я понимаю, но сложно переложить в текст мысли.
Вот представьте 1 Эфир. Когда он стал стоить слишком много, то транзакции нуждались в более мелких цифрах. Поэтому он как бы дробился, появлялись "нули" после запятой.
Стоимость газа определяется в gwei - 9 нулей, а минимальная величина wei - 18 нулей. Очень грубо говоря, это как в 1 рубле - 100 копеек.
И вот этот decimals определяет стоимость нашего токена в количестве нулей после запятой. И вот когда лектор определил число "18" в одноименной функции, он фактически приравнял стоимость своего токена к 1 wei.
Полагаю, это также было сделано для простоты расчетов в дальнейшем, чтобы не приходилось делать дополнительные математические операции для расчета количества токенов после получения денег на счет.
Помимо переменных нам потребуется два mapping: для учета количества токенов на различных адресах, а также разрешения на переводы наших токенов другими адресами.
В mapping allowances есть свой вложенный mapping, в котором uint и отображает количество токенов, которые он может перечислять. Соответственно, если значение "0", то разрешения нет.
#erc20
🔥2👍1
Описание стандарта ERC20. Часть 2
Пройдемся по функциям.
Ну, с первыми функциями name(), symbol(), decimals(), totalSupply(), balanceOf() - все просто, они возвращают только то, что чего предназначены, не выполняя никаких дополнительных действий внутри себя.
Дальше два модификатора на проверку владельца и количества токенов на каком-либо адресе.
Затем вызывается конструктор, чтобы создать токен. В него как раз и нужно передать название и символ токена, а также владельца. После чего запустить чеканку (mint) токена.
В mint() создаются токены и отправляются на адрес магазина.
В burn() они уничтожаются, отправляясь на нулевой адрес.
С transfer() и fransferFrom() у меня были некоторые пролемы та тему, зачем их два. Потом я понял, что transfer() вызываем мы сами, по сути как владелец всех токенов, а transferFrom() - вызывают другие продавцы для перевода токенов.
Это типа того, как если мы отгружаем в магазин свой товар и нам не нужно никакие дополнительные разрешение на это действие. А вот если подрядчик захочет взять у нас со склада немного товара и отправить своему покупателю, то ему нужно сначала спросить разрешение у нас.
Далее идет функция allowance(), которая возвращает uint. И как я выше писал, если количество "0" - то разрешения нет.
И две функции approve, одна из которых вызывает другую, служебную.
Это немного сложная реализация, то они, по словам автора часто встречается в подобных контрактах.
По сути, она всего лишь разрешает какому-то аккаунту передавать наши токены.
В самом конце, лектор создает еще один контракт, который, с помощью конструктора, и отвечает за создание нашего токена, для которого передаются название, символ и магазин.
#erc20
Пройдемся по функциям.
Ну, с первыми функциями name(), symbol(), decimals(), totalSupply(), balanceOf() - все просто, они возвращают только то, что чего предназначены, не выполняя никаких дополнительных действий внутри себя.
Дальше два модификатора на проверку владельца и количества токенов на каком-либо адресе.
Затем вызывается конструктор, чтобы создать токен. В него как раз и нужно передать название и символ токена, а также владельца. После чего запустить чеканку (mint) токена.
В mint() создаются токены и отправляются на адрес магазина.
В burn() они уничтожаются, отправляясь на нулевой адрес.
С transfer() и fransferFrom() у меня были некоторые пролемы та тему, зачем их два. Потом я понял, что transfer() вызываем мы сами, по сути как владелец всех токенов, а transferFrom() - вызывают другие продавцы для перевода токенов.
Это типа того, как если мы отгружаем в магазин свой товар и нам не нужно никакие дополнительные разрешение на это действие. А вот если подрядчик захочет взять у нас со склада немного товара и отправить своему покупателю, то ему нужно сначала спросить разрешение у нас.
Далее идет функция allowance(), которая возвращает uint. И как я выше писал, если количество "0" - то разрешения нет.
И две функции approve, одна из которых вызывает другую, служебную.
Это немного сложная реализация, то они, по словам автора часто встречается в подобных контрактах.
По сути, она всего лишь разрешает какому-то аккаунту передавать наши токены.
В самом конце, лектор создает еще один контракт, который, с помощью конструктора, и отвечает за создание нашего токена, для которого передаются название, символ и магазин.
#erc20
🔥2
Описание стандарта ERC20. Часть 3
А теперь попытаемся расписать контракт магазина для продажи наших токенов.
Прежде всего нам нужно создать специальный объект токена, чтобы в дальнейшем мы могли вызывать функции из контракта ERC20, а также создать переменную владельца контракта.
Далее, в конструкторе, мы через объект токена, с помощью функции "new MCSToken(address(this))", разворачиваем смарт-контракт нашего токена MCSToken, который в свою очередь при помощи наследования разворачивает ERC20.
Образно говоря, сначала мы создали некий объект, назвав его token для простоты, а затем наполнили его через контракт токена.
Благодаря этому действию, мы можем создать функцию tokenBalance(), которая возвращает нам количество токенов на каком-либо адресе, используя объект token и функцию из ERC20 balanceOf().
Далее, если кто-то захочет купить несколько токенов, он может отправить на данный контракт некоторую сумму, которая, в нашем случае, будет равна количеству токенов.
Тут мы делаем пару проверок на присланную сумму и количество токенов для перевода, и затем, с помощь объекта token вызываем функцию перевода - transfer().
Также тут представлена функция sell(), которая позволяем нашему магазину продавать токены с одного аккаунта на другой.
Здесь мы также проверяем наличие необходимого числа токенов для продажи, а также разрешение первого аккаунта для нашего магазина списывать токены оттуда.
Именно поэтому мы вызываем дальше функцию не просто transfer(), а transferFrom().
Ну, и в завершении перечисляем деньги продавцу токена.
Вот и вся реализация контрактов для создания и перевода токенов. Надеюсь, у меня получилось понятно расписать всю процедуру.
В случае каких-либо вопросов, можете смело писать их в комментариях.
#erc20
А теперь попытаемся расписать контракт магазина для продажи наших токенов.
Прежде всего нам нужно создать специальный объект токена, чтобы в дальнейшем мы могли вызывать функции из контракта ERC20, а также создать переменную владельца контракта.
Далее, в конструкторе, мы через объект токена, с помощью функции "new MCSToken(address(this))", разворачиваем смарт-контракт нашего токена MCSToken, который в свою очередь при помощи наследования разворачивает ERC20.
Образно говоря, сначала мы создали некий объект, назвав его token для простоты, а затем наполнили его через контракт токена.
Благодаря этому действию, мы можем создать функцию tokenBalance(), которая возвращает нам количество токенов на каком-либо адресе, используя объект token и функцию из ERC20 balanceOf().
Далее, если кто-то захочет купить несколько токенов, он может отправить на данный контракт некоторую сумму, которая, в нашем случае, будет равна количеству токенов.
Тут мы делаем пару проверок на присланную сумму и количество токенов для перевода, и затем, с помощь объекта token вызываем функцию перевода - transfer().
Также тут представлена функция sell(), которая позволяем нашему магазину продавать токены с одного аккаунта на другой.
Здесь мы также проверяем наличие необходимого числа токенов для продажи, а также разрешение первого аккаунта для нашего магазина списывать токены оттуда.
Именно поэтому мы вызываем дальше функцию не просто transfer(), а transferFrom().
Ну, и в завершении перечисляем деньги продавцу токена.
Вот и вся реализация контрактов для создания и перевода токенов. Надеюсь, у меня получилось понятно расписать всю процедуру.
В случае каких-либо вопросов, можете смело писать их в комментариях.
#erc20
🔥2
Описание стандарта 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
И последние пара моментов, которые следует добавить про сегодняшний урок.
Во-первых, в нем был показан деплой контракта в локальную сеть 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
👍1
Интересные новости: новый стандарт ERC-3475
Вчера в новостях была новость, что Ethereum Foundation приняли новый стандарт ERC-3475 для введения облигаций в экосистему Ethereum.
ERC-3475 позволит каждому создавать облигации, это то, что нужно DeFi прямо сейчас.
В 2015 году Виталик Бутерин ввел стандарт токенов ERC-20 благодаря которому позже произошел бум токенов, развитие DeFi и DAO.
Позже был стандарт ERC-721, который позволил создавать NFT. И это изменила крипто мир и позволило появиться гигантам вроде OpenSea.
Вместе с ERC-3475 ожидаем новой волны интересных проектов и компаний-единорогов.
И все это работает на языке Solidity! Эта профессия точно будет востребована в ближайшие 5-10 лет.
Вы большие молодцы, что начали учить этот язык вместе со мной!
#новости
Вчера в новостях была новость, что Ethereum Foundation приняли новый стандарт ERC-3475 для введения облигаций в экосистему Ethereum.
ERC-3475 позволит каждому создавать облигации, это то, что нужно DeFi прямо сейчас.
В 2015 году Виталик Бутерин ввел стандарт токенов ERC-20 благодаря которому позже произошел бум токенов, развитие DeFi и DAO.
Позже был стандарт ERC-721, который позволил создавать NFT. И это изменила крипто мир и позволило появиться гигантам вроде OpenSea.
Вместе с ERC-3475 ожидаем новой волны интересных проектов и компаний-единорогов.
И все это работает на языке Solidity! Эта профессия точно будет востребована в ближайшие 5-10 лет.
Вы большие молодцы, что начали учить этот язык вместе со мной!
#новости
👍1🔥1
Урок 19 - MultiSig и Timelock
Прошли выходные, началась новая трудовая неделя и она же последняя этого лета.
Очень надеюсь, что у вас было время посидеть с двумя последними контрактами и разобраться, в чем там дело. Последующие две недели будут чуть легче в плане обучения, так как мы будем разбирать паттерны контрактов, а уже после мы рассмотрим ERC721, на базе которого создаются NFT.
В сегодняшнем уроке не одно, а сразу два видео, так как они, по своей сути, взаимосвязаны.
Видео урок про Timelock и урок про MultiSig
(тут две ссылки!)
В подобных уроках вам нужно не столько копировать контракты и записывать за лектором, хоть это и крутой способ обучения, сколько освоить для себя принципы, которые можно будет переносить в свои контракты.
Приятного просмотра и легкого понимания.
#урок #timelock #multisig
Прошли выходные, началась новая трудовая неделя и она же последняя этого лета.
Очень надеюсь, что у вас было время посидеть с двумя последними контрактами и разобраться, в чем там дело. Последующие две недели будут чуть легче в плане обучения, так как мы будем разбирать паттерны контрактов, а уже после мы рассмотрим ERC721, на базе которого создаются NFT.
В сегодняшнем уроке не одно, а сразу два видео, так как они, по своей сути, взаимосвязаны.
Видео урок про Timelock и урок про MultiSig
(тут две ссылки!)
В подобных уроках вам нужно не столько копировать контракты и записывать за лектором, хоть это и крутой способ обучения, сколько освоить для себя принципы, которые можно будет переносить в свои контракты.
Приятного просмотра и легкого понимания.
#урок #timelock #multisig
YouTube
Solidity и смарт-контракты Ethereum, урок #23 | Timelock: ставим транзакции в очередь на выполнение
ХОТИТЕ СТАТЬ РАЗРАБОТЧИКОМ Solidity, узнать об Ethereum, блокчейне и многом другом ещё больше?!
Мои друзья из GUIDE DAO (бывшая школа MCS) предлагают скидку 0,1 ETH на ВСЕ СВОИ БУТКЕМЫ ПО КРИПТЕ! Материалы этих буткемов подготовлены мной и другими специалистами:…
Мои друзья из GUIDE DAO (бывшая школа MCS) предлагают скидку 0,1 ETH на ВСЕ СВОИ БУТКЕМЫ ПО КРИПТЕ! Материалы этих буткемов подготовлены мной и другими специалистами:…
👍1
Концепция Timelock
Для начала попробуем разобраться, что такое timelock.
Лектор в видео приводит довольно долгое и подробное описание, и в двух словах можно сказать, что timelock позволяет запланировать транзакцию в определенные временные рамки.
На сколько я понимаю, блокчейн позволяет фиксировать данные сроки выполнения транзакции, и они не могут быть изменены в будущем. Ни один пользователь не сможет их продлить или сократить, иначе это будет уже считаться другой транзакцией.
При этом сам контракт timelock довольно простой: всего пара функций: добавление в очередь, удаления и исполнения.
В уроке лектор предлагает несколько входящих параметров для транзакции: адрес, вызываемую функцию, какие-либо данные, сумма перевода и метка времени.
При добавлении в очередь нам нужно проверить соответствует ли метка времени минимальному и максимальному отсрочиванию транзакции, а также хешируем информацию через keccak256 и abi.encode(). После чего ставим в очередь.
При удалении - просто находим данную транзакцию в очереди и удаляем ее.
Тут интерес представляет именно функция выполнения транзакции.
Для начала мы проверяем наличие данной транзакции в очереди, а также сроки ее исполнения.
Далее нам следует узнать, нужно ли передавать какую-либо функцию в транзакции. И так как в нашем случае функция выступает в роли string, мы переводим ее в байты и там проверяем длину. Если длина будет больше "0", то значит, что функция для передачи существует.
В этом случае мы создаем новую переменную data, помещаем туда наши данные, которые уже в формате bytes, и кодируем информацию о функции через bytes4(keccak256(bytes())).
Именно с этим и возникают часто проблемы.
Поэтому тут нужно запомнить, чтобы передать функцию в низкоуровневом вызове, нам нужно string перевести в bytes, закодировать через keccak256 и взять первые 4 байта, где и содержится название функции.
Я сам еще осваиваю работу с памятью в Solidity, поэтому не могу расписать ее еще более простым языком.
Так или иначе, это и есть паттерн timelock: хешируем информацию, задаем временные рамки и проводим транзакцию, когда это возможно.
#timelock
Для начала попробуем разобраться, что такое timelock.
Лектор в видео приводит довольно долгое и подробное описание, и в двух словах можно сказать, что timelock позволяет запланировать транзакцию в определенные временные рамки.
На сколько я понимаю, блокчейн позволяет фиксировать данные сроки выполнения транзакции, и они не могут быть изменены в будущем. Ни один пользователь не сможет их продлить или сократить, иначе это будет уже считаться другой транзакцией.
При этом сам контракт timelock довольно простой: всего пара функций: добавление в очередь, удаления и исполнения.
В уроке лектор предлагает несколько входящих параметров для транзакции: адрес, вызываемую функцию, какие-либо данные, сумма перевода и метка времени.
При добавлении в очередь нам нужно проверить соответствует ли метка времени минимальному и максимальному отсрочиванию транзакции, а также хешируем информацию через keccak256 и abi.encode(). После чего ставим в очередь.
При удалении - просто находим данную транзакцию в очереди и удаляем ее.
Тут интерес представляет именно функция выполнения транзакции.
Для начала мы проверяем наличие данной транзакции в очереди, а также сроки ее исполнения.
Далее нам следует узнать, нужно ли передавать какую-либо функцию в транзакции. И так как в нашем случае функция выступает в роли string, мы переводим ее в байты и там проверяем длину. Если длина будет больше "0", то значит, что функция для передачи существует.
В этом случае мы создаем новую переменную data, помещаем туда наши данные, которые уже в формате bytes, и кодируем информацию о функции через bytes4(keccak256(bytes())).
Именно с этим и возникают часто проблемы.
Поэтому тут нужно запомнить, чтобы передать функцию в низкоуровневом вызове, нам нужно string перевести в bytes, закодировать через keccak256 и взять первые 4 байта, где и содержится название функции.
Я сам еще осваиваю работу с памятью в Solidity, поэтому не могу расписать ее еще более простым языком.
Так или иначе, это и есть паттерн timelock: хешируем информацию, задаем временные рамки и проводим транзакцию, когда это возможно.
#timelock
👍1
Концепция MultiSig
MultiSig, или multi signature, это такой подход в реализации смарт-контрактов, когда для выполнения какой-либо транзакции требуется ее одобрене нескольких пользователей.
Например, когда встает вопрос о выпуске новых токенов и размытии доли текущих участников, вам может потребоваться одобрение хотя бы 51% пользователей.
Итак, в этом случае нам потребуется принимать массив адресов в конструкторе, который мы через цикл сохраняем в mapping, и уже в модификаторе добавляем проверку на наличие адреса в списке.
Затем для простоты работы с транзакциями, мы создаем структуру transactions.
В функции подтверждения мы проверяем голосовал ли ранее данный адрес и есть ли вообще данная транзакция в списке. Если все ок, то добавляем голос "за".
В функции отмены подтверждения делаем те же проверки, но отнимаем голос пользователя.
Скорее всего, данные подтверждения\отмены реализуются кнопками на фронтенде, иногда с подключением кошелька, типа MetaMask, поэтому в контракте нам требуется прописать только функции.
#multisig
MultiSig, или multi signature, это такой подход в реализации смарт-контрактов, когда для выполнения какой-либо транзакции требуется ее одобрене нескольких пользователей.
Например, когда встает вопрос о выпуске новых токенов и размытии доли текущих участников, вам может потребоваться одобрение хотя бы 51% пользователей.
Итак, в этом случае нам потребуется принимать массив адресов в конструкторе, который мы через цикл сохраняем в mapping, и уже в модификаторе добавляем проверку на наличие адреса в списке.
Затем для простоты работы с транзакциями, мы создаем структуру transactions.
В функции подтверждения мы проверяем голосовал ли ранее данный адрес и есть ли вообще данная транзакция в списке. Если все ок, то добавляем голос "за".
В функции отмены подтверждения делаем те же проверки, но отнимаем голос пользователя.
Скорее всего, данные подтверждения\отмены реализуются кнопками на фронтенде, иногда с подключением кошелька, типа MetaMask, поэтому в контракте нам требуется прописать только функции.
#multisig
👍1
Урок 20 - Паттерн commit/reveal
Продолжаем наше обучение по паттернам смарт-контрактов, и сегодня рассмотрим commit\reveal.
Как я уже говорил ранее, что в изучении паттернов главное понять основную идею и реализацию на практике. Вы будете знать, что существует такая штука, как ее написать или где найти ответы на свои вопросы.
К слову, из своего личного опыта я могу порекомендовать вам не заучивать на 100% каждую функцию, метод или что-то еще по Solidity. Каждый ваш смарт-контракт будет индивидуален, и для хорошего разработчика основным навыком является правильно задавать вопросы и уметь гуглить.
После всех уроков с YouTube от Ильи, я скину на канал несколько интересных ссылок. В одной из них будут прикольные упражнения на создание смарт-контрактов. Там вы сможете на практике попытаться самостоятельно реализовать контракты.
А пока, новый видео урок.
Также я планирую на этой неделе выпускать уроки по паттерны каждый день, чтобы на следующей неделе можно было рассказать про ERC721, деплой контрактов в различные сети, подключение МетаМаск и наконец, закончить львиную долю нашего обучения.
Всем хорошего дня и легкого обучения!
#урок #commit #reveal
Продолжаем наше обучение по паттернам смарт-контрактов, и сегодня рассмотрим commit\reveal.
Как я уже говорил ранее, что в изучении паттернов главное понять основную идею и реализацию на практике. Вы будете знать, что существует такая штука, как ее написать или где найти ответы на свои вопросы.
К слову, из своего личного опыта я могу порекомендовать вам не заучивать на 100% каждую функцию, метод или что-то еще по Solidity. Каждый ваш смарт-контракт будет индивидуален, и для хорошего разработчика основным навыком является правильно задавать вопросы и уметь гуглить.
После всех уроков с YouTube от Ильи, я скину на канал несколько интересных ссылок. В одной из них будут прикольные упражнения на создание смарт-контрактов. Там вы сможете на практике попытаться самостоятельно реализовать контракты.
А пока, новый видео урок.
Также я планирую на этой неделе выпускать уроки по паттерны каждый день, чтобы на следующей неделе можно было рассказать про ERC721, деплой контрактов в различные сети, подключение МетаМаск и наконец, закончить львиную долю нашего обучения.
Всем хорошего дня и легкого обучения!
#урок #commit #reveal
YouTube
Solidity и смарт-контракты Ethereum, урок #25 | Паттерн commit/reveal
ХОТИТЕ СТАТЬ РАЗРАБОТЧИКОМ Solidity, узнать об Ethereum, блокчейне и многом другом ещё больше?!
Мои друзья из GUIDE DAO (бывшая школа MCS) предлагают скидку 0,1 ETH на ВСЕ СВОИ БУТКЕМЫ ПО КРИПТЕ! Материалы этих буткемов подготовлены мной и другими специалистами:…
Мои друзья из GUIDE DAO (бывшая школа MCS) предлагают скидку 0,1 ETH на ВСЕ СВОИ БУТКЕМЫ ПО КРИПТЕ! Материалы этих буткемов подготовлены мной и другими специалистами:…
👍1
Паттерн commit/reveal
Для начала давайте расшифруем, что такое commit и reveal для тех, кто только начал свой путь в программировании.
По сути, commit - это добавление какой-либо информации куда-либо. Коммитом можно назвать, когда вы отдаете свой голос за кандидата на сайте (отправляете лайк за него в базу данных портала), или вносите правки в код на GitHub (отправляете обновленный код в файл текущего кода программы). Пример довольно грубый, но должен быть понятен.
А reveal - это раскрытие данных. Как, например, в покере, когда в конце раунда все раскрывают свои карты.
Вот и текущий паттерн позволяет сохранить закодированные данные в блокчейне, чтобы позже можно было раскрыть их. Хотя и это грубое описание, так как в реальности происходит обычное сравнение захешированных данных и если они одинаковы, то система подтверждает их.
Хеширование данных происходит на стороне клиента, в браузере, для большей безопасности и конфиденциальности данных, затем они сохраняются в блокчейне.
Мы же помним, что с помощью keccak256 можно только закодировать данные в формате bytes32, но раскодировать обратно их не получится?
И вот когда мы делаем reveal, мы отправляем еще раз наши закодированные данные в блокчейн, там они сравниваются с теми, что уже хранятся от нашего имени и выдается подтверждение.
Если хоть одна часть, один символ в отсылаемых данных будет изменен, то система выдаст ошибку. Именно поэтому обмануть ее не получится.
Ну вот и весь смысл паттерна commit\reveal. Все довольно просто.
#commit #reveal
Для начала давайте расшифруем, что такое commit и reveal для тех, кто только начал свой путь в программировании.
По сути, commit - это добавление какой-либо информации куда-либо. Коммитом можно назвать, когда вы отдаете свой голос за кандидата на сайте (отправляете лайк за него в базу данных портала), или вносите правки в код на GitHub (отправляете обновленный код в файл текущего кода программы). Пример довольно грубый, но должен быть понятен.
А reveal - это раскрытие данных. Как, например, в покере, когда в конце раунда все раскрывают свои карты.
Вот и текущий паттерн позволяет сохранить закодированные данные в блокчейне, чтобы позже можно было раскрыть их. Хотя и это грубое описание, так как в реальности происходит обычное сравнение захешированных данных и если они одинаковы, то система подтверждает их.
Хеширование данных происходит на стороне клиента, в браузере, для большей безопасности и конфиденциальности данных, затем они сохраняются в блокчейне.
Мы же помним, что с помощью keccak256 можно только закодировать данные в формате bytes32, но раскодировать обратно их не получится?
И вот когда мы делаем reveal, мы отправляем еще раз наши закодированные данные в блокчейн, там они сравниваются с теми, что уже хранятся от нашего имени и выдается подтверждение.
Если хоть одна часть, один символ в отсылаемых данных будет изменен, то система выдаст ошибку. Именно поэтому обмануть ее не получится.
Ну вот и весь смысл паттерна commit\reveal. Все довольно просто.
#commit #reveal
Урок 21 - DAO и Governance
В последний день лета мы переходим к уже серьезным темам, которые обязательно нужно понимать разработчику смарт-контрактов.
Последующие три урока будут как бы вводными в тему, и дополнительно мы будем возвращаться к этим темам уже в рамках других уроков и мастер-классов.
Видео урок про DAO и Governance
По сути, это тоже легкая тема, однако нужно немного посидеть с ней и разобраться что к чему. Я же, со своей стороны, постараюсь расписать основы и основную идею максимально просто и понятно.
Приятного дня и легкого обучения!
#урок #dao #governance
В последний день лета мы переходим к уже серьезным темам, которые обязательно нужно понимать разработчику смарт-контрактов.
Последующие три урока будут как бы вводными в тему, и дополнительно мы будем возвращаться к этим темам уже в рамках других уроков и мастер-классов.
Видео урок про DAO и Governance
По сути, это тоже легкая тема, однако нужно немного посидеть с ней и разобраться что к чему. Я же, со своей стороны, постараюсь расписать основы и основную идею максимально просто и понятно.
Приятного дня и легкого обучения!
#урок #dao #governance
YouTube
Solidity и смарт-контракты Ethereum, урок #26 | DAO и Governance - пишем сами (АПДЕЙТ В ЗАКРЕПЕ!!!)
ХОТИТЕ СТАТЬ РАЗРАБОТЧИКОМ Solidity, узнать об Ethereum, блокчейне и многом другом ещё больше?!
Мои друзья из GUIDE DAO (бывшая школа MCS) предлагают скидку 0,1 ETH на ВСЕ СВОИ БУТКЕМЫ ПО КРИПТЕ! Материалы этих буткемов подготовлены мной и другими специалистами:…
Мои друзья из GUIDE DAO (бывшая школа MCS) предлагают скидку 0,1 ETH на ВСЕ СВОИ БУТКЕМЫ ПО КРИПТЕ! Материалы этих буткемов подготовлены мной и другими специалистами:…
Подробнее о DAO
Для начала нам нужно понять, а что такое DAO вообще?
DAO или Decentralized Autonomous Organization (Децентрализованная автономная организация) - это такой тип смарт-контрактов, который позиционирует себя, как отдельное лицо (организация), через которое происходит управление другим смарт-контрактом.
В DAO нет какого-либо пользователя, который принимает решения в одиночку. Нет даже отдельной группы лиц, по типу совета директоров обычной компании, которые принимают решения за всех.
Каждый пользователь, у которого есть токен этого DAO - может принимать участие в голосовании и управлении контрактами.
Грубый пример. Представьте, что есть некий контракт, который может покупать и продавать криптовалюту на бирже, и затем распределять прибыль между его участниками.
Так вот, мы пишем еще один контракт (governance) для управление первым контрактом и выпускаем специальные токены на базе ERC20, которые распределяем между участниками.
Участники с токенами могут создавать предложения по тем или иным действиям с первым контрактом: докупить еще валюты, продать ее или распределить прибыль.
В управляющем контракте создается голосование, по итогам которого принимается решение.
Также в governance можно прописать дополнительные правила для участников, чтобы сделать голосование еще более прозрачным и равноправным. Например, что решение может быть принято, если 51% голосующих одобрит его. Или 1 токен будет равен 1 голосу. Или еще что-либо.
Именно из-за прозрачности и явной децентрализации DAO так полюбился многим крипто энтузиастам. На мой взгляд, DAO отличный пример демократии и реальной власти народа.
#dao #governance
Для начала нам нужно понять, а что такое DAO вообще?
DAO или Decentralized Autonomous Organization (Децентрализованная автономная организация) - это такой тип смарт-контрактов, который позиционирует себя, как отдельное лицо (организация), через которое происходит управление другим смарт-контрактом.
В DAO нет какого-либо пользователя, который принимает решения в одиночку. Нет даже отдельной группы лиц, по типу совета директоров обычной компании, которые принимают решения за всех.
Каждый пользователь, у которого есть токен этого DAO - может принимать участие в голосовании и управлении контрактами.
Грубый пример. Представьте, что есть некий контракт, который может покупать и продавать криптовалюту на бирже, и затем распределять прибыль между его участниками.
Так вот, мы пишем еще один контракт (governance) для управление первым контрактом и выпускаем специальные токены на базе ERC20, которые распределяем между участниками.
Участники с токенами могут создавать предложения по тем или иным действиям с первым контрактом: докупить еще валюты, продать ее или распределить прибыль.
В управляющем контракте создается голосование, по итогам которого принимается решение.
Также в governance можно прописать дополнительные правила для участников, чтобы сделать голосование еще более прозрачным и равноправным. Например, что решение может быть принято, если 51% голосующих одобрит его. Или 1 токен будет равен 1 голосу. Или еще что-либо.
Именно из-за прозрачности и явной децентрализации DAO так полюбился многим крипто энтузиастам. На мой взгляд, DAO отличный пример демократии и реальной власти народа.
#dao #governance
👍1
В двух словах о Governance
Governance - это смарт-контракт, который управляет другим контрактом через голосование его участников при помощи токенов ERC20.
#dao #governance
Governance - это смарт-контракт, который управляет другим контрактом через голосование его участников при помощи токенов ERC20.
#dao #governance
👍1
Описание контракта Governance из урока. Часть 1
Для начала обратите внимание, что было создано 4 контракта и 1 интерфейс.
Контракты ERC20 и IERC20 мы уже разбирали ранее, поэтому мы должны уже знать, что они отвечают за выпуск токенов.
Контракт MyToken - выпускает токены для наших пользователей, которые будут создавать голосования и принимать участие в них.
В контракте Demo, над которым мы и будет брать управление, стоит обратить внимание на функцию transferOwnership(). Именно через нее, при деплое контрактов, мы будем передавать владение от пользователя, развернувшего его, к контракту Governance.
Далее идет Governance контракт.
Для начала мы импортируем интерфейс IERC20, чтобы можно было вызывать функции оттуда, в частности запрашивать баланс токенов на конкретном адресе.
Создаем две структуры: proposalVote и Proposals, где ведем подсчет голосов, а также время голосования и исполнения. Это можно было объединить и в одну структуру, но по словам лектора, через два struct достигается большая гибкость в работе с функциями в дальнейшем.
Затем создаем enum для описания статуса голосования, а также два mapping, которые содержат в себе адреса, как ключи, и структуры, как значения. Это нужно для того, чтобы по id предложения можно было легко ориентироваться в его статусах и находить значения.
Также нам потребуется создать объект токена IERC20, который мы инициализируем в конструкторе.
Далее переходим к функциям.
#dao #governance
Для начала обратите внимание, что было создано 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
Для начала нам потребуется функция для создания уникального id предложения. Поэтому создаем generateProposalId(), куда передаем информацию о самом предложении (адрес, сумму, функцию для вызова, данные, и захешированное описание), и через знакомый нам keccak256 кодируем все и возвращаем.
Также создаем функцию для определения состояния (enum) предложения. Для этого берем из storage (так как предложение уже находится там после своего создания) и проверяем значения, в соответствии с которыми выставляем статус состояния.
Затем можно написать функции создания, исполнения и голосования.
В функции создания предложения мы принимаем необходимую информацию, создаем уникальный id через generateProposalId() и сохраняем в mapping структуру. При этом не забываем выполнить проверку на наличие токенов у пользователя, для создания предложения. И в конце возвращаем id.
В функции голосования мы делаем проверки на наличие токенов у пользователя, статуса предложения (ведь он не должен быть уже состоявшемся), а также голосовал ли ранее этот пользователь по данному предложению. В зависимости от его выбора, добавляем голос в значения "за", "против" или "воздержался". Ну, и выставляем статус, что данный пользователь успешно проголосовал.
В функции исполнения голосования мы принимаем все те же данные, что и в предыдущих функциях. Генерируем id и проверяем его статусы и наличие в базе.
Затем определяем его статус, как исполненный и через низкоуровневый вызов отправляем данные в контракт, которым управляем.
#dao #governance
Деплой и тесты контрактов из урока. Часть 3
В конце хочу сказать пару слов о деплое и тестах в данном уроке: я ничего не понял.
В этом уроке лектор использовал typenoscript и typechain, с которыми я ранее не сталкивался в этой реализации. Поэтому, если вы также ничего не поняли, есть два варианта:
1. Вы можете сами поискать информацию об этом в сети, сделать пост или поскидывать материал в чат канала;
2. Немного подождать. Про typechain есть отдельный урок у лектора, который мы будем проходить послезавтра. А по деплою контрактов я планирую выделить день-два на следующей неделе. Там я постараюсь найти информацию о плагинах, библиотеках, функциях и т.д. по этой теме, и написать разборы.
Вообще не переживайте, если не понимаете объяснения лектора или информацию из моих постов. Я сам возвращаюсь к прошлым урокам довольно часто, так как многое забывается через день-два.
В Solidity, как и в изучении любого другого языка, главное практика. Выделяйте час-два на занятия в день, на повторение материала, но поиск другой информации - и все это постепенно уложится в голове.
Мы учим язык всего 1,5 месяца. И если вы занимаетесь вместе со мной, то уже знаете столько, сколько другой ученик получает за пол-года или даже больше! И этим точно можно гордиться!
#dao #governance
В конце хочу сказать пару слов о деплое и тестах в данном уроке: я ничего не понял.
В этом уроке лектор использовал typenoscript и typechain, с которыми я ранее не сталкивался в этой реализации. Поэтому, если вы также ничего не поняли, есть два варианта:
1. Вы можете сами поискать информацию об этом в сети, сделать пост или поскидывать материал в чат канала;
2. Немного подождать. Про typechain есть отдельный урок у лектора, который мы будем проходить послезавтра. А по деплою контрактов я планирую выделить день-два на следующей неделе. Там я постараюсь найти информацию о плагинах, библиотеках, функциях и т.д. по этой теме, и написать разборы.
Вообще не переживайте, если не понимаете объяснения лектора или информацию из моих постов. Я сам возвращаюсь к прошлым урокам довольно часто, так как многое забывается через день-два.
В Solidity, как и в изучении любого другого языка, главное практика. Выделяйте час-два на занятия в день, на повторение материала, но поиск другой информации - и все это постепенно уложится в голове.
Мы учим язык всего 1,5 месяца. И если вы занимаетесь вместе со мной, то уже знаете столько, сколько другой ученик получает за пол-года или даже больше! И этим точно можно гордиться!
#dao #governance
Урок 22 - Паттерн Proxy/Upgradeable: Transparent, UUPS
Сегодня у нас очень интересный урок, особенно для новичков в Solidity.
Как известно, загрузив смарт-контракт в майннет, его уже никак нельзя изменять или удалять. Однако, если действовать не напрямую, все же есть один способ делать обновления.
Для начинающих разработчиков этот паттерн является достаточно сложным для понимания и написания своего решения, при этом уже есть готовые контракты, основываясь на которых, можно делать обновления в своих. Именно это и рассматривается в уроке.
Видео урок о proxy.
Что нужно взять из этого урока?
Во-первых, конечно, можно попрактиковаться в написании своих прокси контрактов, чтобы понять как они работают, но на данном этапе обучения лучше понять как использовать готовые решения.
Во-вторых, из этого урока можно разобраться, как работать с openzeppelin, таким хранилищем смарт-контрактов, откуда можно брать примеры или создавать наследования.
Я же постараюсь также расписать все нюансы, чтобы в любой момент можно было по тега найти подсказку.
Приятного дня и легкого обучения!
#урок #proxy #upgradeable #transparent #uups
Сегодня у нас очень интересный урок, особенно для новичков в Solidity.
Как известно, загрузив смарт-контракт в майннет, его уже никак нельзя изменять или удалять. Однако, если действовать не напрямую, все же есть один способ делать обновления.
Для начинающих разработчиков этот паттерн является достаточно сложным для понимания и написания своего решения, при этом уже есть готовые контракты, основываясь на которых, можно делать обновления в своих. Именно это и рассматривается в уроке.
Видео урок о proxy.
Что нужно взять из этого урока?
Во-первых, конечно, можно попрактиковаться в написании своих прокси контрактов, чтобы понять как они работают, но на данном этапе обучения лучше понять как использовать готовые решения.
Во-вторых, из этого урока можно разобраться, как работать с openzeppelin, таким хранилищем смарт-контрактов, откуда можно брать примеры или создавать наследования.
Я же постараюсь также расписать все нюансы, чтобы в любой момент можно было по тега найти подсказку.
Приятного дня и легкого обучения!
#урок #proxy #upgradeable #transparent #uups
YouTube
Solidity и смарт-контракты Ethereum, урок #28 | Паттерн Proxy/Upgradeable: Transparent, UUPS
ХОТИТЕ СТАТЬ РАЗРАБОТЧИКОМ Solidity, узнать об Ethereum, блокчейне и многом другом ещё больше?!
Мои друзья из GUIDE DAO (бывшая школа MCS) предлагают скидку 0,1 ETH на ВСЕ СВОИ БУТКЕМЫ ПО КРИПТЕ! Материалы этих буткемов подготовлены мной и другими специалистами:…
Мои друзья из GUIDE DAO (бывшая школа MCS) предлагают скидку 0,1 ETH на ВСЕ СВОИ БУТКЕМЫ ПО КРИПТЕ! Материалы этих буткемов подготовлены мной и другими специалистами:…
👍2
Паттерн Proxy
Основная проблема смарт-контрактов заключается в том, что после деплоя в блокчейн их нельзя изменить или удалить.
И в случае, если мы создали крутой проект, которым пользуются много человек, и в какой-то момент нужно добавить новые функции или другие фишки, мы должны будем переписать наш контракт, загрузить его в сеть и сказать пользователям, что теперь они должны отправлять все свои транзакции туда. Более того, встает вопрос, как перебросить данные из старого контракта в новый.
С этими проблемами и призван бороться прокси паттерн. Так как он работает?
Когда пользователь отправляет транзакцию, он делает это не в смарт-контракт напрямую, а в прокси-контракт, который уже после отправляет данную транзакцию в нужный контракт.
По факту прокси будет выполнять функционал нашего смарт-контракта, но в своем контексте за счет такой штуки, как delegatecall.
Этот подход позволяет разделить логику работы смарт-контракта и данные, с которыми мы работаем. Получается, что логика лежит в нашем СК, а данные - в прокси.
И когда нам потребуется обновить логику работы СК, то мы просто загрузим в блокчейн новый контракт и как бы скажем прокси, что теперь нужно выполнять функции из обновленного контракта. При этом данные никуда не потеряются, так как они находятся в прокси.
#proxy
Основная проблема смарт-контрактов заключается в том, что после деплоя в блокчейн их нельзя изменить или удалить.
И в случае, если мы создали крутой проект, которым пользуются много человек, и в какой-то момент нужно добавить новые функции или другие фишки, мы должны будем переписать наш контракт, загрузить его в сеть и сказать пользователям, что теперь они должны отправлять все свои транзакции туда. Более того, встает вопрос, как перебросить данные из старого контракта в новый.
С этими проблемами и призван бороться прокси паттерн. Так как он работает?
Когда пользователь отправляет транзакцию, он делает это не в смарт-контракт напрямую, а в прокси-контракт, который уже после отправляет данную транзакцию в нужный контракт.
По факту прокси будет выполнять функционал нашего смарт-контракта, но в своем контексте за счет такой штуки, как delegatecall.
Этот подход позволяет разделить логику работы смарт-контракта и данные, с которыми мы работаем. Получается, что логика лежит в нашем СК, а данные - в прокси.
И когда нам потребуется обновить логику работы СК, то мы просто загрузим в блокчейн новый контракт и как бы скажем прокси, что теперь нужно выполнять функции из обновленного контракта. При этом данные никуда не потеряются, так как они находятся в прокси.
#proxy
👍1🔥1
Паттерн Transparent Proxy
Transparent Proxy более старая версия прокси, суть которой заключается в том, что тут есть специальные админские функции для указания на контракт исполнения.
Однако остается вопрос, а что делать, если у нас две одинаковые функции, два одинаковых селектора, и в прокси и в контракте исполнения?
Но все оказывается достаточно просто. Если функции вызываются администратором, то их выполнение идет только в прокси. Если же данную функцию вызывает обычный пользователь, то выполнение происходит в другом контракте.
При этом, если вдруг администратору все таки нужно вызвать функцию в исполняемом контракте, то ему придется делать это из под аккаунта (адреса) обычного пользователя.
#proxy #transparent
Transparent Proxy более старая версия прокси, суть которой заключается в том, что тут есть специальные админские функции для указания на контракт исполнения.
Однако остается вопрос, а что делать, если у нас две одинаковые функции, два одинаковых селектора, и в прокси и в контракте исполнения?
Но все оказывается достаточно просто. Если функции вызываются администратором, то их выполнение идет только в прокси. Если же данную функцию вызывает обычный пользователь, то выполнение происходит в другом контракте.
При этом, если вдруг администратору все таки нужно вызвать функцию в исполняемом контракте, то ему придется делать это из под аккаунта (адреса) обычного пользователя.
#proxy #transparent
👍1
Паттерн UUPS Proxy
UUPS или Universal Upgradeable Proxy Standard (Универсальный Обновляемых Прокси Стандарт) - более новый и легковесный прокси контракт.
В случае UUPS все админские функции находятся в контракте исполнения, а не в самом прокси. По сути, тут нет ничего, за исключением логики перенаправления в другой контракт.
#proxy #uups
UUPS или Universal Upgradeable Proxy Standard (Универсальный Обновляемых Прокси Стандарт) - более новый и легковесный прокси контракт.
В случае UUPS все админские функции находятся в контракте исполнения, а не в самом прокси. По сути, тут нет ничего, за исключением логики перенаправления в другой контракт.
#proxy #uups
👍2