По просьбам зрителей, предлагаю решить следующую задачу. Сделать контракт-аукцион (по принципу "английский аукцион", то есть когда нужно делать всё более и более высокие ставки, перебивая другие). При развёртывании контракта указываем название товара, изначальную цену и адрес продавца (кому потом деньги начислять). Продавец может быть владельцем контракта. Затем сделать функцию "ставка", которая принимает определённую сумму денег от потенциального покупателя. Ставка должна быть больше текущей цены, тк суть аукциона в том, чтобы "перебить" ставку другого. Аукцион может закончиться либо по какому-то условию, либо если продавец вызвал функцию "закончить", либо по какому-то ещё принципу. В этот момент больше ставок уже делать нельзя, а продавец получает свои деньги. Нужно подумать также о том, что люди, чьи ставки "перебили", должны иметь возможность забрать деньги обратно. В идеале, написать для этого контракта тесты. В одном из следующих уроков, возможно, посмотрим, как это сделать.
покопался в документациях, не нашёл как в тестах задеплоить контракт который принимает аргументы в конструкторе, например без аргументов это можно было сделать с помощью метода getContactFactory, но перегрузку с аргументами чёт не вижу
Илья, реально, спасибо за ваш труд, по больше бы людей, которые так объясняют! У меня есть к вам несколько вопросов. 1) если мы пройдём полностью ваш курс по солидити, то будет ли это достаточно для того, чтобы устроиться куда-то джуном в солидити? 2) что вообще нужно знать чтобы стать Junior Smart-contracts разработчиком? Можно своего рода роадмап какой-нибудь чтобы было понятней? 3) как вы сами пришли к смарт-контрактам? Вы работаете в этой сфере? 4) насколько необходимо выучить английский для удобства работы и учёбы? Мне не трудно его выучить, просто лень как то начать, но я начинаю понимать насколько сильно бы расширился бы мои границы, если бы знал 5) нужно ли знать JS для написания тестов?
Спасибо! Отвечаю: 1. Не знаю, но вероятнее всего да. Хотя нужно читать по возможности доп материалы самостоятельно - в частности, документацию 2. Solidity, основы JS, быть знакомым с инфраструктурой NPM, уместь писать тесты для контрактов, понимать принципы EVM - примерно так, я думаю 3. Очень просто: мне в один прекрасный день предложили сделать курс по теме. Ну, я просто делаю платные курсы регулярно, и вот поступил заказ. Теперь веду стримы для студентов курса. Раньше я был только программистом, а сейчас начальник отдела обучения 4. Очень желательно, на русском почти материалов нет 5. Естественно, они же на JS пишутся
Спасибо за урок. Тема очень важная и ее тематику нужно продолжать. Вопрос: Разве можно сравнивать мапинг и список? Ведь мапинг это по сути словарь и в нем хранится ключ(адрес = 80бит) и значение(сумма=100wei=3бита), а в список вы добавляете только значение, там конечно еще есть индекс, но я не знаю занимает ли он место. Т.е. вы пытаетесь сравнить разные по размеру данные. Уместен ли такой пример в сравнении?
Кому-то, мне кажется, будет проще это так понимать (пока что). Но в одном из последних уроках будет показано, как именно хранятся мэппинги. Пока можно на этот счёт не беспокоиться слишком сильно. Может, и не очень хороший пример, не знаю
Илья, большое спасибо за урок. Подскажите как запустить консоль hardhat и синхронизировать с remix - как у вас в уроке? Если я развернул hardhat в wsl в windows - это возможно? Или надо hardhat устанавливать в windows?
На здоровье. Смотрите, надо просто запустить npx hardhat node не важно где, обычно порт 8545 должен быть. Потом в Remix надо просто выбрать провайдера во вкладке Deploy and run transactions. Нужный провайдер - Dev Hardhat provider. Он напомнит, что нужно запустить узел, и потом должен его подрубить. В целом всё, если не работает, напишите мне на почту (есть в описании канала)
Такой вопрос, вот мне нужно сделать whitelist из 400 пользователей. Рационально использовать mapping для этих целей? Или лучше эти адреса занести в json и оттуда их читать?
Сложно сказать. Я бы на вашем месте примерно посчитал размер такого мэппинга, оценил сколько это будет стоить и потом уже подумал, насколько нужно хранить подобные данные on-chain
Когда вы говорите, что большие объемы данных лучше хранить не в блокчейне, а в облачных хранилищах, то о каких данных, например, идет речь? Помимо этого, данные вне блокчейна можно подменить, разве это не противоречит идее смартконтрактов?
Можно. Но если вы хотите сохранить в блокчейне пару мегабайт текста, я бы делать этого не стал, тк это будет стоить пару тысяч долларов. Да, конечно, данные в теории можно подменить, но не всегда и не во всех случаях нам нужно гарантировать 100% неизменность. В блокчейне можно хранить хэш данных, которые мы помещаем off-chain или ещё какие-то доказательства их неизменности. Есть концепция цифровой подписи. Короче, придумать что-то можно.
Спасибо за урок! Возник следующий вопрос. Как я понимаю, цену для газа мы выставляем сами, так почему бы не договориться с неким майнером, чтобы напрямую передавать ему необработанную транзацию и он обработал бы ее за 0 wei. Проблема будет в том, что нельзя утверждать, что он сможет первым решить задачу POW?
Спасибо большое за ваши уроки. Подскажите пожалуйста интересует такой вопрос, можно ли получать данные из смарт контракта в веб3джс ивентом, например, когда что то произошло в блокчейне, ну скажем chainlink стал стоить 40 дол - я хочу чтобы смарт контракт вызвал функцию когда такое произойдет. Возможно ли такое реализовать на смартах ? Фактически функция кола не требующая газа может же такое сделать ? Она же читает из блокчейна данные, ивентом выплюнет наверх в веб3джс , который в свою очерель вызовет функцию в блокчейне. Я все правильно понимаю и это так работает ?
Событие можно породить только в функции контракта, и эту функцию что-то должно запустить. При этом читать журнал событий сам контракт не может, но зато его можно читать через web3.js или ethers.js. В событии могут быть фактически любые данные. Но сам контракт на событие не может реагировать. При этом мы можем написать на ethers скрипт, который слушает событие, а потом по нему выполняет функцию на контракте
Добрый день! Это hardhat, его можно установить довольно легко, а потом подключить в remix через плагин. th-cam.com/video/GD6fz56-cEQ/w-d-xo.html - тут всё видео можно не смотреть, только установку
Спасибо большое за урок! Такой вопрос, а в solidity есть тип данных который хранит дату? Мне бы хотелось реализовать функцию заморозки средств до определенного момента
Проходил обучение, где были 3 адреса монет заданы в коде. А что делать, если нужно иметь возможность поттягивать 3 адреса из списка 100 монет наример ?
А существует ли какие-нибудь автоматические решения по проверке оптимизации кода (плагины к visual studio к примеру)? Проверять в ручную это достаточно нудное дело
Очень хорошо объясняете, спасибо! Есть вот такой вопрос по оптимизации, с которым столкнулся на практике. При осуществлении покупки (функция payable) происходит очень много считываний данных, причем чем больше пользователей в системе, тем больше считываний (связано с древовидной структурой, которую приходится обходить при каждой покупке). Причем по итогу изменяется только одно значение в маппинге. Как можно оптимизировать данный процесс? Я знаю, что есть так называемый паттерн проксирующих контрактов. Может быть, стоит вынести storage данные и функции чтения в отдельный контракт, который будет вызываться основным контрактом и получать уже посчитанный результат? Ведь функции чтения бесплатные
Сходу сказать сложно. Стоит только учитывать, что функции чтения бесплатны при непосредственном вызове. Если же эти функции вызываются в рамках платной транзакции, то они тоже становятся платными. Да, там не очень большая стоимость, но всё же. Возможно, имеет смысл вообще пересмотреть хранение данных?.. Не исключено, что можно оптимизировать сам алгоритм
@@IlyaBodrovKrukowski можно, конечно , оптимизировать алгоритм, но идея в целом общая, даже не к моей конкретно ситуации. Просто если мы имеем какой-то сложный алгоритм расчета, не меняющий данные, не рациональнее ли вынести его в отдельный смартконтракт? Таким образом, мы будем иметь отдельный смартконтракт с логикой, который будет возвращать уже вычисленную информацию. И получается, что вместо сохранения в блоке транзакций (именно transaction, а не call) всех вызовов на чтение и других штук, мы сохраняем только инфу про вызов сторонней функции (call) и изменение переменной. Мне кажется, это бы сильно оптимизировало стоимость по газу для любых контрактов. Если я правильно понимаю, такой подход называют проксирующим. Правда нигде не пишут про экономию газа
@@sadpay Такая история есть, только обычно это в другом контексте упоминается. Впрочем, последнее время я встречаю мнения, что прокси-контракты - это антипаттерн и вообще плохая идея.Оптимизаций по газу особенных я тут не вижу, если честно
@@sadpay Ну, вот просто к примеру: у нас в школе MCS как раз недавно выступал эксперт из одной компании, которая занимается криптой. И вот как раз он упоминал, что уже прокси особо не используется и вообще считаются так себе решением. Но я честно хочу сказать, что так абстрактно судить сложно. Но всё же особых бонусов я не вижу. Да, в традиционных языках имеет смысл вынести логику в другой класс, в другой метод. Но тут всё-таки история иная, и к этому надо привыкать, увы
Очень круто, что каждый пример посмотрели в стоимости газа, теперь хоть порядок чисел в оптимизации понятен! Конечно, жду урок с применением популярных библиотек (OpenZeppelin наверное?). И еще вопрос такой, можно попросить 2-3 задачи от тебя для практики? Т.к. 9 уроков просмотрено, все доступно и понятно (имея опыт на питоне и паскале), но не понятно с чего начинать практическую работу и как правильно начать "набивать руку"? я вступил в группу в ФБ солидити разработчиков, там пару раз в день кто-то спрашивает помощи по коду и в некоторых случаях я даже мог бы помочь, но думаю этой практики недостаточно :)
Да, про стандартные библиотеки тоже надо бы. Что касается задачи, пожалуйста: сделать контракт-аукцион (по принципу "английский аукцион", то есть когда нужно делать всё более и более высокие ставки, перебивая другие). При развёртывании контракта указываем название товаара, изначальную цену и адрес продавца (кому потом деньги начислять). Продавец может быть владельцем контракта. Затем сделать функцию "ставка", которая принимает определённую сумму денег от потенциального покупателя. Ставка должна быть больше текущей цены, тк суть аукциона в том, чтобы "перебить" ставку другого. Аукцион может закончиться либо по какому-то условию, либо если продавец вызвал функцию "закончить", либо по какому-то ещё принципу. В этот момент больше ставок уже делать нельзя, а продавец получает свои деньги. Нужно подумать также о том, что люди, чьи ставки "перебили", должны иметь возможность забрать деньги обратно. В идеале, написать для этого контракта тесты. В одном из следующих уроков, возможно, посмотрим, как это сделать. Текст задачи продублирую также в закреплённом комментарии.
@@korg2 Можно, но это не очень надёжно тк не очень ясно, когда это конкретно произойдёт (особенно, людям, которые не до конца знают принципы работы блокчейна) - подумайте ещё о варианте "по времени" (block.timestamp). Ну, хотя это просто вариант
Аукцион сделал. Самый простой, он просто когда получает ставку выше - предыдущую возвращает обратно. Потому на балансе контракта всегда только максимальная ставка. И вывести можно только после msg.timestamp > какого-то значения. Можно еще задачку?)
@@korg2 Тоже самое, но голландский аукцион. При создании указываем товар и МАКСИМАЛЬНУЮ цену. Каждую секунду цена должна падать, например, на 1 wei (или любое другое значение). Сделать функцию, которая возвращает актуальную цену на данный момент. А также функцию, через которую можно "купить" товар по ТЕКУЩЕЙ цене. Учесть, что пока идёт транзакция, то цена за эти 1-2 секунды ещё упадёт, поэтому разницу нужно вернуть покупателю на аккаунт. Как только вызвана функция "купить", аукцион должен закончиться.
Доброго дня, Илья. Огромное спасибо за урок, очень информативно и доходчиво получилось впитать информацию.
#смартконтракты #солидити #solidity #блокчейн #etherium #события #модификаторы #блокчейнразработка
Это лучший канал 100% Однозначно подписка!
Благодарю
Огромное спасибо за Ваш труд, больше чем уверен что это большой вклад в общественность, верю в то что вы не оставите данные серии уроков.
Большое спасибо, буду стараться
Спасибо! Всегда жду с нетерпением.
Очень полезная серия уроков, спасибо огромное, буду благодарен также за продолжение.
Обязательно! Стрим в среду вечером (см подробности в списке видео), так что присоединяйтесь
Благодарю, это было очень полезное видео!
По просьбам зрителей, предлагаю решить следующую задачу. Сделать контракт-аукцион (по принципу "английский аукцион", то есть когда нужно делать всё более и более высокие ставки, перебивая другие). При развёртывании контракта указываем название товара, изначальную цену и адрес продавца (кому потом деньги начислять). Продавец может быть владельцем контракта. Затем сделать функцию "ставка", которая принимает определённую сумму денег от потенциального покупателя. Ставка должна быть больше текущей цены, тк суть аукциона в том, чтобы "перебить" ставку другого. Аукцион может закончиться либо по какому-то условию, либо если продавец вызвал функцию "закончить", либо по какому-то ещё принципу. В этот момент больше ставок уже делать нельзя, а продавец получает свои деньги. Нужно подумать также о том, что люди, чьи ставки "перебили", должны иметь возможность забрать деньги обратно. В идеале, написать для этого контракта тесты. В одном из следующих уроков, возможно, посмотрим, как это сделать.
покупка квартиры через смарт контракт, я думаю это будет супер?
покопался в документациях, не нашёл как в тестах задеплоить контракт который принимает аргументы в конструкторе, например без аргументов это можно было сделать с помощью метода getContactFactory, но перегрузку с аргументами чёт не вижу
@@ildan6520github.com/bodrovis-learning/Solidity-YT-Series/blob/master/lesson_36_role/Demo.test.ts#L9 тут пример есть
Спасибо!
А вот этот урок придется пересмотреть сейчас подробнее по утру, много деталей, что нужно запомнить и усвоить.
Топовый урок!
thank you
классный урок
очень полезное видео!
thank you very much
Илья, реально, спасибо за ваш труд, по больше бы людей, которые так объясняют!
У меня есть к вам несколько вопросов.
1) если мы пройдём полностью ваш курс по солидити, то будет ли это достаточно для того, чтобы устроиться куда-то джуном в солидити?
2) что вообще нужно знать чтобы стать Junior Smart-contracts разработчиком? Можно своего рода роадмап какой-нибудь чтобы было понятней?
3) как вы сами пришли к смарт-контрактам? Вы работаете в этой сфере?
4) насколько необходимо выучить английский для удобства работы и учёбы? Мне не трудно его выучить, просто лень как то начать, но я начинаю понимать насколько сильно бы расширился бы мои границы, если бы знал
5) нужно ли знать JS для написания тестов?
Спасибо! Отвечаю:
1. Не знаю, но вероятнее всего да. Хотя нужно читать по возможности доп материалы самостоятельно - в частности, документацию
2. Solidity, основы JS, быть знакомым с инфраструктурой NPM, уместь писать тесты для контрактов, понимать принципы EVM - примерно так, я думаю
3. Очень просто: мне в один прекрасный день предложили сделать курс по теме. Ну, я просто делаю платные курсы регулярно, и вот поступил заказ. Теперь веду стримы для студентов курса. Раньше я был только программистом, а сейчас начальник отдела обучения
4. Очень желательно, на русском почти материалов нет
5. Естественно, они же на JS пишутся
@@IlyaBodrovKrukowski спасибо за ответ! Соглашусь что 5) вопрос звучит не корректно 😅, я имел ввиду углублённым знание JS
@@lemavisaitov6412 А, это не слишком обязательно. Главное понимать async-await тк он постоянно используется, типы данных - в таком духе
Очень полезные советы!!!! Может быть рассмотрим как писать таски в hardhat?
Надо подумать, спасибо за идею
Интересно про virtual override модификаторы узнать
Немного позднее
Спасибо за урок! Слушай может есть prettier / eslint только для смарт контрактов?
Возможно, но как-то не пробовал искать пока
Спасибо за урок. Тема очень важная и ее тематику нужно продолжать. Вопрос: Разве можно сравнивать мапинг и список? Ведь мапинг это по сути словарь и в нем хранится ключ(адрес = 80бит) и значение(сумма=100wei=3бита), а в список вы добавляете только значение, там конечно еще есть индекс, но я не знаю занимает ли он место. Т.е. вы пытаетесь сравнить разные по размеру данные. Уместен ли такой пример в сравнении?
Кому-то, мне кажется, будет проще это так понимать (пока что). Но в одном из последних уроках будет показано, как именно хранятся мэппинги. Пока можно на этот счёт не беспокоиться слишком сильно. Может, и не очень хороший пример, не знаю
Илья, большое спасибо за урок. Подскажите как запустить консоль hardhat и синхронизировать с remix - как у вас в уроке? Если я развернул hardhat в wsl в windows - это возможно? Или надо hardhat устанавливать в windows?
На здоровье. Смотрите, надо просто запустить npx hardhat node не важно где, обычно порт 8545 должен быть. Потом в Remix надо просто выбрать провайдера во вкладке Deploy and run transactions. Нужный провайдер - Dev Hardhat provider. Он напомнит, что нужно запустить узел, и потом должен его подрубить. В целом всё, если не работает, напишите мне на почту (есть в описании канала)
@@IlyaBodrovKrukowski Супер! Всё получилось!
@@pphotic
Как оптимальней распределить память:
- uint128, uint128, bytes32
- bytes32, uint128, uint128
первый или второй вариант? или одинаково?)
Это не особенно важно с точки зрения слотов
Такой вопрос, вот мне нужно сделать whitelist из 400 пользователей. Рационально использовать mapping для этих целей? Или лучше эти адреса занести в json и оттуда их читать?
Сложно сказать. Я бы на вашем месте примерно посчитал размер такого мэппинга, оценил сколько это будет стоить и потом уже подумал, насколько нужно хранить подобные данные on-chain
Когда вы говорите, что большие объемы данных лучше хранить не в блокчейне, а в облачных хранилищах, то о каких данных, например, идет речь?
Помимо этого, данные вне блокчейна можно подменить, разве это не противоречит идее смартконтрактов?
Можно. Но если вы хотите сохранить в блокчейне пару мегабайт текста, я бы делать этого не стал, тк это будет стоить пару тысяч долларов. Да, конечно, данные в теории можно подменить, но не всегда и не во всех случаях нам нужно гарантировать 100% неизменность. В блокчейне можно хранить хэш данных, которые мы помещаем off-chain или ещё какие-то доказательства их неизменности. Есть концепция цифровой подписи. Короче, придумать что-то можно.
Спасибо за урок! Возник следующий вопрос. Как я понимаю, цену для газа мы выставляем сами, так почему бы не договориться с неким майнером, чтобы напрямую передавать ему необработанную транзацию и он обработал бы ее за 0 wei. Проблема будет в том, что нельзя утверждать, что он сможет первым решить задачу POW?
Ну майнеров много, им распределяются эти транзакции сами. В теории что-то такое придумать можно, конечно, но в обще случае проблематично
Спасибо большое за ваши уроки.
Подскажите пожалуйста интересует такой вопрос, можно ли получать данные из смарт контракта в веб3джс ивентом, например, когда что то произошло в блокчейне, ну скажем chainlink стал стоить 40 дол - я хочу чтобы смарт контракт вызвал функцию когда такое произойдет. Возможно ли такое реализовать на смартах ? Фактически функция кола не требующая газа может же такое сделать ? Она же читает из блокчейна данные, ивентом выплюнет наверх в веб3джс , который в свою очерель вызовет функцию в блокчейне. Я все правильно понимаю и это так работает ?
Событие можно породить только в функции контракта, и эту функцию что-то должно запустить. При этом читать журнал событий сам контракт не может, но зато его можно читать через web3.js или ethers.js. В событии могут быть фактически любые данные. Но сам контракт на событие не может реагировать. При этом мы можем написать на ethers скрипт, который слушает событие, а потом по нему выполняет функцию на контракте
@@IlyaBodrovKrukowski Понял, я примерно так себе и представлял это. Спасибо ! С нетерпение жду видео про ивенты )
Здравствуйте! Не подскажете что за приложение справа и как его подключить?
Добрый день! Это hardhat, его можно установить довольно легко, а потом подключить в remix через плагин. th-cam.com/video/GD6fz56-cEQ/w-d-xo.html - тут всё видео можно не смотреть, только установку
Странно, что в solidity нет constexpr и inline. Кажется, что многое можно оптимизировать компилятором
Нет, ну вообще он умеет кое-чего оптимизировать. И насколько знаю модификаторы как раз inline вставляются
Спасибо большое за урок! Такой вопрос, а в solidity есть тип данных который хранит дату? Мне бы хотелось реализовать функцию заморозки средств до определенного момента
Нет, встроенного типа нет, там block.timestamp есть, но он возвращает uint, нужно как-то самостоятельно конвертировать
Проходил обучение, где были 3 адреса монет заданы в коде. А что делать, если нужно иметь возможность поттягивать 3 адреса из списка 100 монет наример ?
Подскажите, пожалуйста - что это за команда irb? Что нужно установить?
Не, это можно не ставить. Это интерпретатор Ruby
@@IlyaBodrovKrukowski Спасибо!
А существует ли какие-нибудь автоматические решения по проверке оптимизации кода (плагины к visual studio к примеру)?
Проверять в ручную это достаточно нудное дело
Про такое не слышал. Какую-то оптимизацию делает компилятор, но и нам тоже нужно об этом заботиться.
Очень хорошо объясняете, спасибо!
Есть вот такой вопрос по оптимизации, с которым столкнулся на практике. При осуществлении покупки (функция payable) происходит очень много считываний данных, причем чем больше пользователей в системе, тем больше считываний (связано с древовидной структурой, которую приходится обходить при каждой покупке). Причем по итогу изменяется только одно значение в маппинге. Как можно оптимизировать данный процесс? Я знаю, что есть так называемый паттерн проксирующих контрактов. Может быть, стоит вынести storage данные и функции чтения в отдельный контракт, который будет вызываться основным контрактом и получать уже посчитанный результат? Ведь функции чтения бесплатные
Сходу сказать сложно. Стоит только учитывать, что функции чтения бесплатны при непосредственном вызове. Если же эти функции вызываются в рамках платной транзакции, то они тоже становятся платными. Да, там не очень большая стоимость, но всё же. Возможно, имеет смысл вообще пересмотреть хранение данных?.. Не исключено, что можно оптимизировать сам алгоритм
@@IlyaBodrovKrukowski можно, конечно , оптимизировать алгоритм, но идея в целом общая, даже не к моей конкретно ситуации. Просто если мы имеем какой-то сложный алгоритм расчета, не меняющий данные, не рациональнее ли вынести его в отдельный смартконтракт? Таким образом, мы будем иметь отдельный смартконтракт с логикой, который будет возвращать уже вычисленную информацию. И получается, что вместо сохранения в блоке транзакций (именно transaction, а не call) всех вызовов на чтение и других штук, мы сохраняем только инфу про вызов сторонней функции (call) и изменение переменной. Мне кажется, это бы сильно оптимизировало стоимость по газу для любых контрактов.
Если я правильно понимаю, такой подход называют проксирующим. Правда нигде не пишут про экономию газа
@@sadpay Такая история есть, только обычно это в другом контексте упоминается. Впрочем, последнее время я встречаю мнения, что прокси-контракты - это антипаттерн и вообще плохая идея.Оптимизаций по газу особенных я тут не вижу, если честно
@@IlyaBodrovKrukowski понял. Спасибо за ответы!
@@sadpay Ну, вот просто к примеру: у нас в школе MCS как раз недавно выступал эксперт из одной компании, которая занимается криптой. И вот как раз он упоминал, что уже прокси особо не используется и вообще считаются так себе решением. Но я честно хочу сказать, что так абстрактно судить сложно. Но всё же особых бонусов я не вижу. Да, в традиционных языках имеет смысл вынести логику в другой класс, в другой метод. Но тут всё-таки история иная, и к этому надо привыкать, увы
Очень круто, что каждый пример посмотрели в стоимости газа, теперь хоть порядок чисел в оптимизации понятен!
Конечно, жду урок с применением популярных библиотек (OpenZeppelin наверное?).
И еще вопрос такой, можно попросить 2-3 задачи от тебя для практики? Т.к. 9 уроков просмотрено, все доступно и понятно (имея опыт на питоне и паскале), но не понятно с чего начинать практическую работу и как правильно начать "набивать руку"?
я вступил в группу в ФБ солидити разработчиков, там пару раз в день кто-то спрашивает помощи по коду и в некоторых случаях я даже мог бы помочь, но думаю этой практики недостаточно :)
Да, про стандартные библиотеки тоже надо бы. Что касается задачи, пожалуйста: сделать контракт-аукцион (по принципу "английский аукцион", то есть когда нужно делать всё более и более высокие ставки, перебивая другие). При развёртывании контракта указываем название товаара, изначальную цену и адрес продавца (кому потом деньги начислять). Продавец может быть владельцем контракта. Затем сделать функцию "ставка", которая принимает определённую сумму денег от потенциального покупателя. Ставка должна быть больше текущей цены, тк суть аукциона в том, чтобы "перебить" ставку другого. Аукцион может закончиться либо по какому-то условию, либо если продавец вызвал функцию "закончить", либо по какому-то ещё принципу. В этот момент больше ставок уже делать нельзя, а продавец получает свои деньги. Нужно подумать также о том, что люди, чьи ставки "перебили", должны иметь возможность забрать деньги обратно. В идеале, написать для этого контракта тесты. В одном из следующих уроков, возможно, посмотрим, как это сделать. Текст задачи продублирую также в закреплённом комментарии.
@@IlyaBodrovKrukowski спасибо, понятная задача! Окончание аукыиона можно сделать не ранее чем 100 блоков с момента последней ставки, например
@@korg2 Можно, но это не очень надёжно тк не очень ясно, когда это конкретно произойдёт (особенно, людям, которые не до конца знают принципы работы блокчейна) - подумайте ещё о варианте "по времени" (block.timestamp). Ну, хотя это просто вариант
Аукцион сделал. Самый простой, он просто когда получает ставку выше - предыдущую возвращает обратно. Потому на балансе контракта всегда только максимальная ставка. И вывести можно только после msg.timestamp > какого-то значения.
Можно еще задачку?)
@@korg2 Тоже самое, но голландский аукцион. При создании указываем товар и МАКСИМАЛЬНУЮ цену. Каждую секунду цена должна падать, например, на 1 wei (или любое другое значение). Сделать функцию, которая возвращает актуальную цену на данный момент. А также функцию, через которую можно "купить" товар по ТЕКУЩЕЙ цене. Учесть, что пока идёт транзакция, то цена за эти 1-2 секунды ещё упадёт, поэтому разницу нужно вернуть покупателю на аккаунт. Как только вызвана функция "купить", аукцион должен закончиться.
Кому мы платим газ за обработку если на эфириуме больше нет майнеров, а за развертывание узлов ничего не платят?
Майнеров нет, зато есть валидаторы, к примеру ethereum.org/en/developers/docs/consensus-mechanisms/pos/
Solidity - сплошной антипаттерн с точки зрения функционального программирования!
А это и не функциональный язык Но вообще да, тут есть свои чудеса