Chainlink Data Feeds. Часть 7
Забыл еще сказать одну штуку.
Если вы хотите подключать интерфейсы в своем контракте из редакторов кода, типа VS Code, то можно добавить пакет chainlink в свой проект, выполнив команду в консоли
npm install @chainlink/contracts --save
После этого можно использовать import.
#chainlink #datafeeds #feeds
Забыл еще сказать одну штуку.
Если вы хотите подключать интерфейсы в своем контракте из редакторов кода, типа VS Code, то можно добавить пакет chainlink в свой проект, выполнив команду в консоли
npm install @chainlink/contracts --save
После этого можно использовать import.
#chainlink #datafeeds #feeds
Chainlink VRF. Часть 1
Следующие несколько постов будут про Chainlink VRF или про то, как сервис помогает сгенерировать случайное число.
Как вы знаете в блокчейне существует большая проблема с этой задачей. И все простые решения так или иначе можно предсказать, особенно если вы опытный разработчик. Более подробно об это писать я не буду, так как нужно будет приводить много вычислений и формул, поэтому, если интересно, просто погуглите.
Chainlink решает эту проблему по своему. Он использует несколько контрактов, которые через оракулов не только генерируют случайное число, но и могут дать подтверждение этому, записанное в блокчейн. Поэтому вы в любой момент можете убедиться, что данное число действительно рандомное.
Сервис предоставляет два метода генерации чисел: Подписной и По запросу.
Первое подходит для разработчиков, например, игр, которые хотят автоматизировать процесс генерации и не делать все в ручном режиме.
Второй же способ подходит для тех, кому нужно получить число разово или по требованию. Другими словами, каждый раз придется отправлять запрос в chainlink вручную.
В данный момент генерация случайных чисел доступна для сети Эфира, BNB, Polygon, Avalanche и Fantom.
#chainlink #vrf #random
Следующие несколько постов будут про Chainlink VRF или про то, как сервис помогает сгенерировать случайное число.
Как вы знаете в блокчейне существует большая проблема с этой задачей. И все простые решения так или иначе можно предсказать, особенно если вы опытный разработчик. Более подробно об это писать я не буду, так как нужно будет приводить много вычислений и формул, поэтому, если интересно, просто погуглите.
Chainlink решает эту проблему по своему. Он использует несколько контрактов, которые через оракулов не только генерируют случайное число, но и могут дать подтверждение этому, записанное в блокчейн. Поэтому вы в любой момент можете убедиться, что данное число действительно рандомное.
Сервис предоставляет два метода генерации чисел: Подписной и По запросу.
Первое подходит для разработчиков, например, игр, которые хотят автоматизировать процесс генерации и не делать все в ручном режиме.
Второй же способ подходит для тех, кому нужно получить число разово или по требованию. Другими словами, каждый раз придется отправлять запрос в chainlink вручную.
В данный момент генерация случайных чисел доступна для сети Эфира, BNB, Polygon, Avalanche и Fantom.
#chainlink #vrf #random
👍1
Chainlink VRF. Часть 2
Прежде всего стоит немного пояснить, как работает связка контрактов для генерации случайных чисел.
В chainlink vrf помимо нашего контракта существуют еще два контракта: VRF Координатор и VRF Сервис.
Первый, будучи блокчейн компонентом, порождает событие, когда мы отправляем запрос на генерацию числа из нашего контракта. И после верифицирует от Сервиса сгенерированное число и доказательство этого.
Второй, внесетевой компонент, слушает события от Координатора и генерирует случайное число основанное на хеше блока и времени. После этого он отправляет данное число и доказательство, что число действительно было сгенерировано случайно, в Координатора.
Эту цепь можно представить так:
Наш контракт (отправляет запрос на число) => Координатор (порождает событие, отправляет в Сервис) => Сервис (создает число и доказательство случайности, отправляет в Координатор) => Координатор (подтверждает число и доказательство, отправляет в наш Контракт) => Наш контракт
В нашем контракте сгенерированное число записывается либо в переменную, либо в mapping.
#chainlink #vrf #random
Прежде всего стоит немного пояснить, как работает связка контрактов для генерации случайных чисел.
В chainlink vrf помимо нашего контракта существуют еще два контракта: VRF Координатор и VRF Сервис.
Первый, будучи блокчейн компонентом, порождает событие, когда мы отправляем запрос на генерацию числа из нашего контракта. И после верифицирует от Сервиса сгенерированное число и доказательство этого.
Второй, внесетевой компонент, слушает события от Координатора и генерирует случайное число основанное на хеше блока и времени. После этого он отправляет данное число и доказательство, что число действительно было сгенерировано случайно, в Координатора.
Эту цепь можно представить так:
Наш контракт (отправляет запрос на число) => Координатор (порождает событие, отправляет в Сервис) => Сервис (создает число и доказательство случайности, отправляет в Координатор) => Координатор (подтверждает число и доказательство, отправляет в наш Контракт) => Наш контракт
В нашем контракте сгенерированное число записывается либо в переменную, либо в mapping.
#chainlink #vrf #random
👍1
Chainlink VRF. Часть 3
Как создать Подписной метод генерации случайных чисел?
1. Для начала нужно зарегистрироваться на сервисе по этой ссылке, нажав "Create Subnoscription" и подключив кошелек.
Обратите внимание, что для проведения тестов, кошелек должен быть настроен на тестовую сеть, в нашем случае goerly.
2. Затем требуется добавить Link на счет только что созданного аккаунта. Это можно сделать и позже, если вы не запросили их на chainlink до сих пор.
3. Добавление Consumers (пользователей, от которых будут поступать запросы на генерацию чисел). Сюда добавляются адреса контрактов, откуда будут идти запросы. Мы сделаем это чуть позже.
Создание аккаунта, добавление Link - все это требует наличие Эфира на счету! Добавьте его через faucets, как было написано в предыдущих постах.
Если вы все сделали правильно, то откроется ваш личный кабинет на chainlink.
Кстати, там указан ваш ID, который нам понадобится для написания смарт контракта.
#chainlink #vrf #random
Как создать Подписной метод генерации случайных чисел?
1. Для начала нужно зарегистрироваться на сервисе по этой ссылке, нажав "Create Subnoscription" и подключив кошелек.
Обратите внимание, что для проведения тестов, кошелек должен быть настроен на тестовую сеть, в нашем случае goerly.
2. Затем требуется добавить Link на счет только что созданного аккаунта. Это можно сделать и позже, если вы не запросили их на chainlink до сих пор.
3. Добавление Consumers (пользователей, от которых будут поступать запросы на генерацию чисел). Сюда добавляются адреса контрактов, откуда будут идти запросы. Мы сделаем это чуть позже.
Создание аккаунта, добавление Link - все это требует наличие Эфира на счету! Добавьте его через faucets, как было написано в предыдущих постах.
Если вы все сделали правильно, то откроется ваш личный кабинет на chainlink.
Кстати, там указан ваш ID, который нам понадобится для написания смарт контракта.
#chainlink #vrf #random
👍1
Chainlink VRF. Часть 4.1
Каких-то особенных функций при генерации случайных чисел в документации я не нашел. Их там по сути всего две-три основные. Поэтому я решил использовать код представленный на сайте по ссылке. Вы также можете открыть его в Ремиксе онлайн и изучить.
Давайте пройдемся по коду.
Итак, в начале импортируются три контракта: ConfirmedOwner устанавливает нас (msg.sender), как владельца, VRFCoordinatorV2Interface - контракт Координатор для данной сети, VRFConsumerBaseV2 - обрабатывает ответ от Координатора.
Далее порождаются два event, чтобы в личном кабинете мы видели транзакции, создается структура RequestStatus, отвечающая за статусы запросов, mapping для хранения полученных чисел, а также несколько переменных для нашего ID, id последнего запроса.
Обратите внимание на keyhash, для разных сетей он будет отличаться. Посмотреть keyhash для своего проекта можно по этой ссылке.
Вообще keyhash отвечает за то, сколько газа в wei вы готовы заплатить за транзакцию. Чем больше это число, тем быстрее пройдет транзакция.
callbackGasLimit - отвечает за вызов callback функции в нашем контракте fulfillRandomWords(). Она должна быть меньше MaxGasLimit в контракте Координатора. Если указать ее слишком маленькой, то полученные сгенерированные числа просто не сохранятся в нашем контракте.
requestConfirmations - сколько подтверждений узел Chainlink должен подождать прежде чем ответить. Он должен быть в пределах Minimum и Maximum конфигурации.
numWords - сколько случайных чисел нам нужно получить. Их количество влияет на количество газа в callbackGasLimit. Будьте тут внимательны. Также это значение не должно превышать значение VRFCoordinatorV2.MAX_NUM_WORDS.
#chainlink #vrf #random
Каких-то особенных функций при генерации случайных чисел в документации я не нашел. Их там по сути всего две-три основные. Поэтому я решил использовать код представленный на сайте по ссылке. Вы также можете открыть его в Ремиксе онлайн и изучить.
Давайте пройдемся по коду.
Итак, в начале импортируются три контракта: ConfirmedOwner устанавливает нас (msg.sender), как владельца, VRFCoordinatorV2Interface - контракт Координатор для данной сети, VRFConsumerBaseV2 - обрабатывает ответ от Координатора.
Далее порождаются два event, чтобы в личном кабинете мы видели транзакции, создается структура RequestStatus, отвечающая за статусы запросов, mapping для хранения полученных чисел, а также несколько переменных для нашего ID, id последнего запроса.
Обратите внимание на keyhash, для разных сетей он будет отличаться. Посмотреть keyhash для своего проекта можно по этой ссылке.
Вообще keyhash отвечает за то, сколько газа в wei вы готовы заплатить за транзакцию. Чем больше это число, тем быстрее пройдет транзакция.
callbackGasLimit - отвечает за вызов callback функции в нашем контракте fulfillRandomWords(). Она должна быть меньше MaxGasLimit в контракте Координатора. Если указать ее слишком маленькой, то полученные сгенерированные числа просто не сохранятся в нашем контракте.
requestConfirmations - сколько подтверждений узел Chainlink должен подождать прежде чем ответить. Он должен быть в пределах Minimum и Maximum конфигурации.
numWords - сколько случайных чисел нам нужно получить. Их количество влияет на количество газа в callbackGasLimit. Будьте тут внимательны. Также это значение не должно превышать значение VRFCoordinatorV2.MAX_NUM_WORDS.
#chainlink #vrf #random
👍1
Chainlink VRF. Часть 4.2
Далее в конструкторе устанавливается владелец контракта и передается контракт Координатор.
Также тут представлены всего три функции.
requestRandomWords() - основная функция, которая отправляет запросы на генерацию случайных чисел в контракт Координатор, создает новую запись struct в mapping, устанавливает id последнего запроса и порождает событие.
fulfillRandomWords() - это функция, которую в нашем контракте вызывает контракт Координатор, когда получает сгенерированное число. Она добавляет числа в массив и порождает событие.
getRequestStatus() - служебная функция, которая позволяет нам проверять статус того или иного запроса.
Деплой можно также сделать из Ремикса, указав наш ID личного кабинета.
После деплоя контракта, нам нужно вернуться в личный кабинет и добавить в Consumers адрес нашего только что созданного контракта, иначе постоянно будет возникать ошибка, при попытке вызвать функцию генерации числа.
Для запроса случайного числа вызываем функциюrequest RandomWords(), ждем немного пока вернется ответ, и проверяем значения в requestIds.
В личном кабинете можно увидеть информацию по транзакции.
#chainlink #vrf #random
Далее в конструкторе устанавливается владелец контракта и передается контракт Координатор.
Также тут представлены всего три функции.
requestRandomWords() - основная функция, которая отправляет запросы на генерацию случайных чисел в контракт Координатор, создает новую запись struct в mapping, устанавливает id последнего запроса и порождает событие.
fulfillRandomWords() - это функция, которую в нашем контракте вызывает контракт Координатор, когда получает сгенерированное число. Она добавляет числа в массив и порождает событие.
getRequestStatus() - служебная функция, которая позволяет нам проверять статус того или иного запроса.
Деплой можно также сделать из Ремикса, указав наш ID личного кабинета.
После деплоя контракта, нам нужно вернуться в личный кабинет и добавить в Consumers адрес нашего только что созданного контракта, иначе постоянно будет возникать ошибка, при попытке вызвать функцию генерации числа.
Для запроса случайного числа вызываем функциюrequest RandomWords(), ждем немного пока вернется ответ, и проверяем значения в requestIds.
В личном кабинете можно увидеть информацию по транзакции.
#chainlink #vrf #random
👍1
Chainlink VRF. Часть 5
Пара слов о Link токенах во всем этом деле.
На первый взгляд может показаться, что Link вообще не участвует в наших видимых транзакциях. МЫ платим за разворачивание аккаунта, за перевод этих самых Link, за деплой контракта, за вызов функций в нем и т.д.
И за все это время ни разу не проскальзывает Link!
А его работа заключается в другом.
Помните описание цепи работы контрактов, что я делал выше? Так вот, когда в дело вступают Координатор и Сервис, то в транзакциях между собой также используют газ: для генерации числа, записи доказательства в блокчейн, проверку доказательства и числа, и, наконец, вызов callback функции в нашем контракте.
Сервис собирает количество газа, потребовавшееся для всего этого, переводит в стоимость Wei, пересчитывает его в свои Link и снимает их с вашего аккаунта в счет этих действий.
И, да, Link - это своего рода тоже криптовалюта, которой торгуют на бирже.
#chainlink #vrf #random
Пара слов о Link токенах во всем этом деле.
На первый взгляд может показаться, что Link вообще не участвует в наших видимых транзакциях. МЫ платим за разворачивание аккаунта, за перевод этих самых Link, за деплой контракта, за вызов функций в нем и т.д.
И за все это время ни разу не проскальзывает Link!
А его работа заключается в другом.
Помните описание цепи работы контрактов, что я делал выше? Так вот, когда в дело вступают Координатор и Сервис, то в транзакциях между собой также используют газ: для генерации числа, записи доказательства в блокчейн, проверку доказательства и числа, и, наконец, вызов callback функции в нашем контракте.
Сервис собирает количество газа, потребовавшееся для всего этого, переводит в стоимость Wei, пересчитывает его в свои Link и снимает их с вашего аккаунта в счет этих действий.
И, да, Link - это своего рода тоже криптовалюта, которой торгуют на бирже.
#chainlink #vrf #random
👍1
Chainlink VRF. Часть 6
Далее рассмотрим контракт для разового получения случайного числа без создания личного кабинета и регистрации на сервисе.
Идем по этой ссылке и также открываем код в Ремиксе.
Прежде всего нужно отметить, что помимо контракта Координатора, нам нужно указывать контракт Wrapper, которого нет в Подписной модели.
Конфигурации сетей для разовых запросов можно посмотреть тут.
В целом логика контракта схожа с контрактом, который я разбирал для Подписной модели, поэтому тут буду обращать внимание только на различия.
Итак, в данном коде появляются новые переменные: linkAddress и wrapperAddress, куда записываются адреса контрактов токена и wrapper. Их все можно найти в конфигурации.
Функции requestRandomWords(), fulfillRandomWords() и getRequestStatus() делают все то же, что и описанные ранее.
И добавляется функция withdrawLink(). Сейчас объясню зачем она нужна.
Помните, при создании личного кабинета мы зачисляли на его счет некоторую сумму Link? Так вот, в разовом контракте, нам нужно перечислить туда токены после деплоя напрямую из нашего кошелька. Без этого мы не сможем вызывать функции генерации номеров.
И функция withdrawLink() нужна для того чтобы вернуть неиспользованные Link обратно на кошелек с контракта, если таковые будут после запроса.
#chainlink #vrf #random
Далее рассмотрим контракт для разового получения случайного числа без создания личного кабинета и регистрации на сервисе.
Идем по этой ссылке и также открываем код в Ремиксе.
Прежде всего нужно отметить, что помимо контракта Координатора, нам нужно указывать контракт Wrapper, которого нет в Подписной модели.
Конфигурации сетей для разовых запросов можно посмотреть тут.
В целом логика контракта схожа с контрактом, который я разбирал для Подписной модели, поэтому тут буду обращать внимание только на различия.
Итак, в данном коде появляются новые переменные: linkAddress и wrapperAddress, куда записываются адреса контрактов токена и wrapper. Их все можно найти в конфигурации.
Функции requestRandomWords(), fulfillRandomWords() и getRequestStatus() делают все то же, что и описанные ранее.
И добавляется функция withdrawLink(). Сейчас объясню зачем она нужна.
Помните, при создании личного кабинета мы зачисляли на его счет некоторую сумму Link? Так вот, в разовом контракте, нам нужно перечислить туда токены после деплоя напрямую из нашего кошелька. Без этого мы не сможем вызывать функции генерации номеров.
И функция withdrawLink() нужна для того чтобы вернуть неиспользованные Link обратно на кошелек с контракта, если таковые будут после запроса.
#chainlink #vrf #random
👍1
Chainlink VRF. Часть 7
В завершении темы VRF стоит упомянуть еще несколько моментов.
1. В Подписной модели вы можете создать отдельный контракт, который будет управлять Consumers. Вам больше не придется заходить в личный кабинет и вручную добавлять каждый адрес контракта. Все это можно автоматизировать.
По большому счету, если вы разобрались с кодом первых двух методов, от создание контракта, тем более, что пример представлен тут, не должно вызвать никаких трудностей у вас.
2. В контракте можно запрашивать число "между % и %", например, между 1 и 50. Для этого потребуется добавить следующую строку в функцию fulfillRandomWords():
s_randomRange = (randomWords[0] % 50) + 1;
Однако, как я понял, это работает в случае единичного запроса. Для нескольких чисел придется писать цикл.
3. Можно получать от 1 до 200-500 случайных чисел за раз, в зависимости от конфигураций сети.
4. Если вы позволяете делать запросы на случайное число другим контрактам, то можно отслеживать этот процесс с помощью добавление нового mapping, куда будут записываться id запроса и адрес контракта.
5. Если вы хотите, чтобы в зависимости от полученного числа или других условий, происходили какие-то дополнительные действия, то можно ввести enum в контракт, и направлять выполнение функции в нужное русло.
Конечно, можно придумать и множество других условий выполнения контракта, но это, наверное, самые популярные способы.
Далее мы переходим к теме подключение к API через Chainlink.
#chainlink #vrf #random
В завершении темы VRF стоит упомянуть еще несколько моментов.
1. В Подписной модели вы можете создать отдельный контракт, который будет управлять Consumers. Вам больше не придется заходить в личный кабинет и вручную добавлять каждый адрес контракта. Все это можно автоматизировать.
По большому счету, если вы разобрались с кодом первых двух методов, от создание контракта, тем более, что пример представлен тут, не должно вызвать никаких трудностей у вас.
2. В контракте можно запрашивать число "между % и %", например, между 1 и 50. Для этого потребуется добавить следующую строку в функцию fulfillRandomWords():
s_randomRange = (randomWords[0] % 50) + 1;
Однако, как я понял, это работает в случае единичного запроса. Для нескольких чисел придется писать цикл.
3. Можно получать от 1 до 200-500 случайных чисел за раз, в зависимости от конфигураций сети.
4. Если вы позволяете делать запросы на случайное число другим контрактам, то можно отслеживать этот процесс с помощью добавление нового mapping, куда будут записываться id запроса и адрес контракта.
5. Если вы хотите, чтобы в зависимости от полученного числа или других условий, происходили какие-то дополнительные действия, то можно ввести enum в контракт, и направлять выполнение функции в нужное русло.
Конечно, можно придумать и множество других условий выполнения контракта, но это, наверное, самые популярные способы.
Далее мы переходим к теме подключение к API через Chainlink.
#chainlink #vrf #random
👍1
Chainlink Connect to API. Интро
С сегодняшнего дня мы будем учиться использовать сервис Chainlink, чтобы подключаться к разным API и передавать данные с внешнего мира к себе в контракт.
Возможно, сам процесс займет пару дней и вот почему.
Хоть документация на сайте chainlink написана достаточно хорошо, но все же вопросы возникают в большом количестве. Я раньше никогда не работал с API, тем более на стыке с блокчейном, поэтому техническая часть вгоняет меня в депрессию.
Я пробовал поискать видео объяснения на эту тему. Однако они лекторы берут пример с документации и просто его воспроизводят, другие, с официального канала сервиса, слегка устаревшие.
Не, с кодом там все достаточно просто. Если вы со мной изучали предыдущие темы VRF и Data Feeds, то с ним проблем возникнуть не должно.
Вопросы представляют для меня сейчас узлы, к которым идет подключение, сами оракулы, и так называемые jobs, услуги, которые эти оракулы обрабатывают.
Года два назад у chainlink был хороший маркет, где можно было быстро найти узел для подключения. Но сейчас они переработали его, и указали в документации только тестовые ноды. Короче, пока еще разбираюсь.
Также вызывает вопросы процесс создания и подключения своего оракула. Тема такая, что нужно сначала найти сторонний сервис, API которого нам интересен для своего контракта, создать шаблон \ оракул, и каким-то образом поместить его на узел, чтобы тот начал с ним работать.
В общем и тут разбираюсь. Как только что-либо будет понятно, сразу напишу посты.
С сегодняшнего дня мы будем учиться использовать сервис Chainlink, чтобы подключаться к разным API и передавать данные с внешнего мира к себе в контракт.
Возможно, сам процесс займет пару дней и вот почему.
Хоть документация на сайте chainlink написана достаточно хорошо, но все же вопросы возникают в большом количестве. Я раньше никогда не работал с API, тем более на стыке с блокчейном, поэтому техническая часть вгоняет меня в депрессию.
Я пробовал поискать видео объяснения на эту тему. Однако они лекторы берут пример с документации и просто его воспроизводят, другие, с официального канала сервиса, слегка устаревшие.
Не, с кодом там все достаточно просто. Если вы со мной изучали предыдущие темы VRF и Data Feeds, то с ним проблем возникнуть не должно.
Вопросы представляют для меня сейчас узлы, к которым идет подключение, сами оракулы, и так называемые jobs, услуги, которые эти оракулы обрабатывают.
Года два назад у chainlink был хороший маркет, где можно было быстро найти узел для подключения. Но сейчас они переработали его, и указали в документации только тестовые ноды. Короче, пока еще разбираюсь.
Также вызывает вопросы процесс создания и подключения своего оракула. Тема такая, что нужно сначала найти сторонний сервис, API которого нам интересен для своего контракта, создать шаблон \ оракул, и каким-то образом поместить его на узел, чтобы тот начал с ним работать.
В общем и тут разбираюсь. Как только что-либо будет понятно, сразу напишу посты.
Chainlink Connect to API. Часть 1
Сначала немного истории, почему эта часть обучения вызвала некоторую проблему у меня.
Я смотрел несколько обучающих видео по этой теме, и информация в них оказалась слегка устаревшей. В них показана навигация по документации chainlink, их маркет для узлов и выполнения задач, примеры кода - все это уже переделано и обновлено. И все соотнести с новыми примерами было прям задачей для меня.
Как это все работает на chainlink?
Сейчас есть два способа работы с API:
1) Создать свой external adapter (далее Внешний Адаптер), куда определить нужное вам API. И уже оттуда получать информацию в свой смарт контракт;
2) Использовать доступные Адаптеры на узлах Chainlink, которые, при подключении вашего контракта, могут выдать информацию, на которую они преднастроены. Другими словами, вам нужно узнать узел, понять, что он отдает и нужно ли это, и тогда подключать его.
К слову сказать, раньше там был поиск по, так называемым, шаблонам работ на различных узлах. Вы могли в своем контракте прописать любую ссылку API стороннего ресурса и отправить ее на выполнение запроса на понравившейся узел. Так... это сложно звучит... Попробую схематически объяснить.
У вас есть смарт контракт, и вы хотите получать в него текущий курс биткойна. Далее вам нужно найти сторонний ресурс, например, биржу обмена валют, у которого на сайте есть API.
Грубо говоря, API это, чаще всего, обычный json файл с необходимой информацией, который можно посмотреть по ссылке. Вот пример по ссылке.
Как было раньше:
Вы заходите на маркет chainlink, выбираете узел, в своем контракте указываете параметры этого узла (токен, оракул и тип работы), вставляете ссылку и деплоите. После этого, вы можете вызвать функцию в своем контракте и получить данные с API ссылки.
Как сейчас:
Первый вариант.
Лавочку прикрыли. На маркете теперь есть официальные узлы, которые могут предоставить вам данные с API, которые уже установлены в них. Доступные узлы и информацию можно посмотреть тут.
Если хотите найти другой узел для выполнения вашего API, chainlink говорит, что можно зайти на их Дискорд канал и попросить кого-нибудь из сообщества сделать это.
Я зашел на этот канал, но выглядит он как-то глухо. Не, люди там есть, но в основном просто висят вопросы или новости.
Второй вариант.
Вы пишите свой адаптер, где указываете API ссылку и информацию, которую хотите получить. Далее, вам нужно развернуть и настроить свой узел на chainlink для обработки этого адаптера. И уже там появится вся необходимая информация для контракта, типа jobId, oracle, tokenId и т.д.
Мы разберем код и контракта для отправки запроса и пример создания адаптера. Но уходить в разработку узла и его настройку я просто не хочу. Тут уже нужны знания не сколько разработчика смарт контрактов, сколько каких-то инженерных, и копаться в этом пока не вижу смысла. Но видео по этой теме скину, на случай, если сами захотите разобраться.
#chainlink #api #adapter
Сначала немного истории, почему эта часть обучения вызвала некоторую проблему у меня.
Я смотрел несколько обучающих видео по этой теме, и информация в них оказалась слегка устаревшей. В них показана навигация по документации chainlink, их маркет для узлов и выполнения задач, примеры кода - все это уже переделано и обновлено. И все соотнести с новыми примерами было прям задачей для меня.
Как это все работает на chainlink?
Сейчас есть два способа работы с API:
1) Создать свой external adapter (далее Внешний Адаптер), куда определить нужное вам API. И уже оттуда получать информацию в свой смарт контракт;
2) Использовать доступные Адаптеры на узлах Chainlink, которые, при подключении вашего контракта, могут выдать информацию, на которую они преднастроены. Другими словами, вам нужно узнать узел, понять, что он отдает и нужно ли это, и тогда подключать его.
К слову сказать, раньше там был поиск по, так называемым, шаблонам работ на различных узлах. Вы могли в своем контракте прописать любую ссылку API стороннего ресурса и отправить ее на выполнение запроса на понравившейся узел. Так... это сложно звучит... Попробую схематически объяснить.
У вас есть смарт контракт, и вы хотите получать в него текущий курс биткойна. Далее вам нужно найти сторонний ресурс, например, биржу обмена валют, у которого на сайте есть API.
Грубо говоря, API это, чаще всего, обычный json файл с необходимой информацией, который можно посмотреть по ссылке. Вот пример по ссылке.
Как было раньше:
Вы заходите на маркет chainlink, выбираете узел, в своем контракте указываете параметры этого узла (токен, оракул и тип работы), вставляете ссылку и деплоите. После этого, вы можете вызвать функцию в своем контракте и получить данные с API ссылки.
Как сейчас:
Первый вариант.
Лавочку прикрыли. На маркете теперь есть официальные узлы, которые могут предоставить вам данные с API, которые уже установлены в них. Доступные узлы и информацию можно посмотреть тут.
Если хотите найти другой узел для выполнения вашего API, chainlink говорит, что можно зайти на их Дискорд канал и попросить кого-нибудь из сообщества сделать это.
Я зашел на этот канал, но выглядит он как-то глухо. Не, люди там есть, но в основном просто висят вопросы или новости.
Второй вариант.
Вы пишите свой адаптер, где указываете API ссылку и информацию, которую хотите получить. Далее, вам нужно развернуть и настроить свой узел на chainlink для обработки этого адаптера. И уже там появится вся необходимая информация для контракта, типа jobId, oracle, tokenId и т.д.
Мы разберем код и контракта для отправки запроса и пример создания адаптера. Но уходить в разработку узла и его настройку я просто не хочу. Тут уже нужны знания не сколько разработчика смарт контрактов, сколько каких-то инженерных, и копаться в этом пока не вижу смысла. Но видео по этой теме скину, на случай, если сами захотите разобраться.
#chainlink #api #adapter
Chainlink Connect to API. Часть 2
Для начала разберем несколько HTTP Get запросов, которые представлены в chainlink. В некотором роде, разделение запросов на различные типы служат еще и для экономии газа транзакций, так как в получаемом ответе содержится только конкретная информация.
Single Word Response
Результатом такого запроса будет всего одна единица данных: одно число uint или int, булево значение, строка или bytes32. Например, как в этой ссылке мы получаем только значение USD числом.
Multi-Variable Responses
Результатом этого запроса будет несколько значений одной единицы данных. Представьте себе, как если бы в рамках одного контракта и одной функции мы отправляли бы несколько Single Word Response.
Array Response
В результате такого запросы мы получим какое-либо значение из массива. Допустим по ссылке API мы получаем такой вывод данных, и из него нам нужно получить определенное значение.
Large Responses
В этом случае мы сможем получить большие по объему данные, в рамках блокчейна, как например, такой.
В документации я не нашел дополнительных примеров, кроме ссылки IPFS, о том, что еще Chainlink подразумевают по "большие данные".
С учетом того, что именно вам нужно получить из API запроса и должна строиться работа по настройке своего узла или создания задач для других узлов.
Далее перейдем к коду.
#chainlink #api #adapter
Для начала разберем несколько HTTP Get запросов, которые представлены в chainlink. В некотором роде, разделение запросов на различные типы служат еще и для экономии газа транзакций, так как в получаемом ответе содержится только конкретная информация.
Single Word Response
Результатом такого запроса будет всего одна единица данных: одно число uint или int, булево значение, строка или bytes32. Например, как в этой ссылке мы получаем только значение USD числом.
Multi-Variable Responses
Результатом этого запроса будет несколько значений одной единицы данных. Представьте себе, как если бы в рамках одного контракта и одной функции мы отправляли бы несколько Single Word Response.
Array Response
В результате такого запросы мы получим какое-либо значение из массива. Допустим по ссылке API мы получаем такой вывод данных, и из него нам нужно получить определенное значение.
Large Responses
В этом случае мы сможем получить большие по объему данные, в рамках блокчейна, как например, такой.
В документации я не нашел дополнительных примеров, кроме ссылки IPFS, о том, что еще Chainlink подразумевают по "большие данные".
С учетом того, что именно вам нужно получить из API запроса и должна строиться работа по настройке своего узла или создания задач для других узлов.
Далее перейдем к коду.
#chainlink #api #adapter
Chainlink Connect to API. Часть 3
Пройдемся по коду, представленному в актуальной документации chainlink.
В целом код у всех видов запросов очень похож.
В самом начале подключаются два контракта, от которых наследуется наш:
import '@chainlink/contracts/src/v0.8/ChainlinkClient.sol';
import '@chainlink/contracts/src/v0.8/ConfirmedOwner.sol';
Далее подключается библиотека для запросов:
using Chainlink for Chainlink.Request;
Создаются обязательные переменные jobId и fee, а также пользовательские, где будут храниться данные после запросов.
Определяется событие для учета запросов.
Далее в конструкторе устанавливается владелец, а также передаются контракты токена, оракула, jobId и fee.
Fee - это стоимость выполнения запроса адаптером.
JobId - это уникальный идентификатор узла, по которому он выполняет данный запрос.
Позже я покажу, где их можно найти, и как они появляются.
Так же тут есть одинаковая для всех функция withdrawLink() для возврата неиспользованных Link.
Переходим к интересному.
Функция fulfill(). Она вызывается извне, когда адаптер готов прислать нам ответ на запрос. Типа как fallback функция. Она может принимать различные аргументы на входе для фиксирования событий (event). И возвращает результат запроса в нужном типе данных: uint, int, bool, bytes или string.
Далее функция request(). Более точное название меняется от контракта к контракту, но это скорее сделано, чтобы назвать функцию в зависимости от данных, которая она будет запрашивать.
Идем построчно.
Chainlink.Request memory req = buildChainlinkRequest(jobId, address(this), this.fulfill.selector);
Создаем временную переменную на основе ранее подключенной библиотеки, куда передаем jobId, адрес нашего контракта, а также this.funcName.selector - где funcName - это имя callback функции, которая будет принимать ответ в нашем контракте.
В данных примерах это fulfil, а так может быть любой, как, например, fulfilResult.
req.add('get', 'httpLink');
Здесь указывается API ссылка.
req.add('path', 'name');
Далее указываем ключ в json, значение которого мы хотим получить. Например, в "image: 'http://'", image - это ключ.
sendChainlinkRequest(req, fee);
В конце вызываем функцию из подключенного контракта, куда передаем параметры запроса и fee.
В следующем посте расскажу, где взять jobId, оракул и как работать с предустановленными API на узлах.
#chainlink #api #adapter
Пройдемся по коду, представленному в актуальной документации chainlink.
В целом код у всех видов запросов очень похож.
В самом начале подключаются два контракта, от которых наследуется наш:
import '@chainlink/contracts/src/v0.8/ChainlinkClient.sol';
import '@chainlink/contracts/src/v0.8/ConfirmedOwner.sol';
Далее подключается библиотека для запросов:
using Chainlink for Chainlink.Request;
Создаются обязательные переменные jobId и fee, а также пользовательские, где будут храниться данные после запросов.
Определяется событие для учета запросов.
Далее в конструкторе устанавливается владелец, а также передаются контракты токена, оракула, jobId и fee.
Fee - это стоимость выполнения запроса адаптером.
JobId - это уникальный идентификатор узла, по которому он выполняет данный запрос.
Позже я покажу, где их можно найти, и как они появляются.
Так же тут есть одинаковая для всех функция withdrawLink() для возврата неиспользованных Link.
Переходим к интересному.
Функция fulfill(). Она вызывается извне, когда адаптер готов прислать нам ответ на запрос. Типа как fallback функция. Она может принимать различные аргументы на входе для фиксирования событий (event). И возвращает результат запроса в нужном типе данных: uint, int, bool, bytes или string.
Далее функция request(). Более точное название меняется от контракта к контракту, но это скорее сделано, чтобы назвать функцию в зависимости от данных, которая она будет запрашивать.
Идем построчно.
Chainlink.Request memory req = buildChainlinkRequest(jobId, address(this), this.fulfill.selector);
Создаем временную переменную на основе ранее подключенной библиотеки, куда передаем jobId, адрес нашего контракта, а также this.funcName.selector - где funcName - это имя callback функции, которая будет принимать ответ в нашем контракте.
В данных примерах это fulfil, а так может быть любой, как, например, fulfilResult.
req.add('get', 'httpLink');
Здесь указывается API ссылка.
req.add('path', 'name');
Далее указываем ключ в json, значение которого мы хотим получить. Например, в "image: 'http://'", image - это ключ.
sendChainlinkRequest(req, fee);
В конце вызываем функцию из подключенного контракта, куда передаем параметры запроса и fee.
В следующем посте расскажу, где взять jobId, оракул и как работать с предустановленными API на узлах.
#chainlink #api #adapter
Chainlink Connect to API. Часть 4
Давайте для начала поговорим о предустановленных API на узлах.
Я уже ранее давал ссылку на маркет chainlink, а теперь поговорим чуть конкретнее и возьмем, к примеру, узел Tiingo.
Это сторонний сервис, предоставляющих информацию о крипто финансах.
Перейдя по ссылке, и открыв вкладку "Integrations", вы найдете всю необходимую информацию по подключению: ссылку на контракт токена, оракула и jobid.
Именно эти параметры и нужно указывать в своем контракте в конструкторе.
При этом, в функции request() уже не нужно давать API ссылку, так как она вшита в Адаптер узла.
Ах, да, все контракты токена Link для различных сетей можно посмотреть тут.
В случае, когда мы пишем свой Внешний Адаптер, то нам приходится запускать свой собственный узел на chainlink. А уже там создается этот самый jobId.
В последующих постах я расскажу как написать свой Адаптер, но про создание узла больше вы можете узнать тут.
#chainlink #api #adapter
Давайте для начала поговорим о предустановленных API на узлах.
Я уже ранее давал ссылку на маркет chainlink, а теперь поговорим чуть конкретнее и возьмем, к примеру, узел Tiingo.
Это сторонний сервис, предоставляющих информацию о крипто финансах.
Перейдя по ссылке, и открыв вкладку "Integrations", вы найдете всю необходимую информацию по подключению: ссылку на контракт токена, оракула и jobid.
Именно эти параметры и нужно указывать в своем контракте в конструкторе.
При этом, в функции request() уже не нужно давать API ссылку, так как она вшита в Адаптер узла.
Ах, да, все контракты токена Link для различных сетей можно посмотреть тут.
В случае, когда мы пишем свой Внешний Адаптер, то нам приходится запускать свой собственный узел на chainlink. А уже там создается этот самый jobId.
В последующих постах я расскажу как написать свой Адаптер, но про создание узла больше вы можете узнать тут.
#chainlink #api #adapter
Новости о Chainlink
Вчера в Твиттере или местных каналах о криптовалюте проскочила новость:
"Chainlink поможет SWIFT с разработкой системы для криптотранзакций для традиционных финансовых учреждений".
Это еще один плюс в сторону детального изучения сервисов Chainlink. Другими словами, это не какой-либо сайт однодневка, который создает удобства для работы с блокчейном, но что-то более крупное и готовое выйти на международную арену финансовых услуг.
Вполне возможно, что в скором времени знания работы с ним будут обязательны во многих компаниях.
Вчера в Твиттере или местных каналах о криптовалюте проскочила новость:
"Chainlink поможет SWIFT с разработкой системы для криптотранзакций для традиционных финансовых учреждений".
Это еще один плюс в сторону детального изучения сервисов Chainlink. Другими словами, это не какой-либо сайт однодневка, который создает удобства для работы с блокчейном, но что-то более крупное и готовое выйти на международную арену финансовых услуг.
Вполне возможно, что в скором времени знания работы с ним будут обязательны во многих компаниях.
Chainlink Connect to API. Часть 5
Давайте, наконец, рассмотрим процесс создания своего собственного Внешнего Адаптера. Напомню, с помощью него можно подключать API с любого сайта и передавать данные в смарт контракт.
К данному моменту у вас уже должен быть узел на chainlink, который будет обрабатывать Адптер, или вы можете создать и настроить его самостоятельно. Ссылка на видео об этом была в прошлом посте.
Поэтому тут я просто разберу код.
Итак, для начала клонируем данный репозитарий с GitHub к себе в папку проекта с помощью команды:
git clone https://github.com/thodges-gh/CL-EA-NodeJS-Template.git ExternalAdapterProject
Chainlink специально создал этот шаблон, чтобы пользователям было легче создавать свои адаптеры. Использование данного репозитария бесплатное.
После это, на всякий случай, выполняем команду "npm install" для загрузки пакетов для работы проекта. Мало ли, их не окажется у вас.
После этого проект будет готов к работе.
По сути, мы будем редактировать только два файла: index.js и .env. Остальные могут потребоваться для настройки работы с узлом.
#chainlink #api #adapter
Давайте, наконец, рассмотрим процесс создания своего собственного Внешнего Адаптера. Напомню, с помощью него можно подключать API с любого сайта и передавать данные в смарт контракт.
К данному моменту у вас уже должен быть узел на chainlink, который будет обрабатывать Адптер, или вы можете создать и настроить его самостоятельно. Ссылка на видео об этом была в прошлом посте.
Поэтому тут я просто разберу код.
Итак, для начала клонируем данный репозитарий с GitHub к себе в папку проекта с помощью команды:
git clone https://github.com/thodges-gh/CL-EA-NodeJS-Template.git ExternalAdapterProject
Chainlink специально создал этот шаблон, чтобы пользователям было легче создавать свои адаптеры. Использование данного репозитария бесплатное.
После это, на всякий случай, выполняем команду "npm install" для загрузки пакетов для работы проекта. Мало ли, их не окажется у вас.
После этого проект будет готов к работе.
По сути, мы будем редактировать только два файла: index.js и .env. Остальные могут потребоваться для настройки работы с узлом.
#chainlink #api #adapter
Chainlink Connect to API. Часть 6
Открываем index.js.
const { Requester, Validator } = require('@chainlink/external-adapter')
Обязательный пакет для подключения, он помогает отправлять запросы и обрабатывать их.
Дальше в customError вы можете настроить обработку пользовательских ошибок, но можно и оставить без изменений.
В customParams мы записываем все параметры, которые можно будет запрашивать в смарт контракте.
Например в шаблоне есть строка:
base: ['base', 'from', 'coin']
которую можно заменить на
city: ['city', 'town']
если мы хотим, например, запрашивать температуру в определенном городе. Тогда в смарт контракте потребуется прописать строку запроса:
req.add("city", "boston");
Так же тут можно указать необязательные параметры, которые, возможно, будут в API ссылке, как, например, тут:
https://api.openweathermap.org/data/2.5/weather?q=<CITY_NAME>&appid=<YOUR_API_KEY>
где weather - и есть endpoint.
Endpoint, грубо говоря, это некая точка запроса на стороне сервера, которая выдает определенные параметры. В случае с weather она может отдавать температуру в int, а, например, с storm - есть ли угроза торнадо в регионе в булевом значении.
Иногда эти endpoint нужны в ссылке API, а иногда можно обойтись и без них. Поэтому этот параметр не обязателен.
Далее идет функция создания запроса createRequest. И тут обратим внимание на код внутри:
const validator = new Validator(callback, input, customParams)
создает объект Валидатора, куда передается callback (об этом позже), input от пользователя в контракте, параметры, которые мы прописали выше.
const jobRunID = validator.validated.id
Здесь функция получает jobId. Если забыли, что это такое, то прочитайте посты выше.
const endpoint = validator.validated.data.endpoint || 'price'
еще раз проверяем endpoint и через символ "||" указываем значение по умолчанию,
const url = `https://min-api.cryptocompare.com/data/${endpoint}`
и передаем ссылку API.
const appid = prosess.anv.API_KEY;
Некоторые API для подключения требуют регистрации на сервисе и получения уникального ключа доступа API_KEY, его можно хранить, как переменную среды в файле .env.
В конце мы создаем переменную, куда помещаем данные о параметрах запроса, в нашем случае это city:
const cityData = validator.validated.data.city.toUpperCase()
Приведение к одному регистру нужно для дополнительной корректности передачи значений.
Далее в const params мы передаем cityData и appid.
Переменная const config будет работать типа axios, это такой способ передачи данный через url. И тут не нужно указывать дополнительные значения типа "get" или "headers".
После подготовки запроса мы создаем функции отправки запроса - Requester.request(), где в качестве аргументов передаются config и customErros.
response.data.result = Requester.validateResultNumber(response.data, ["path", "data"])
В этой строке особое внимание заслуживает ["path", "data"] - где определяется путь в json файле по ссылке до нужной нам информации. Например:
Из файла {"region": {"city":"boston"} - нужно будет передать ['region', 'city']
И затем вызывается callback функция:
callback(response.status, Requester.success(jobRunID, response))
В принципе, это все. Дальше код нам не интересен, так как он выполняет скорее служебные функции.
Как я уже говорил, после написания Адаптера, нам нужно подключить его к узлу, настроить Bridge и jobId, и запустить на нем Адаптер. После всех этих манипуляций вы можете написать смарт контракт, сделать деплой и запрашивать информацию с нужного API.
#chainlink #api #adapter
Открываем index.js.
const { Requester, Validator } = require('@chainlink/external-adapter')
Обязательный пакет для подключения, он помогает отправлять запросы и обрабатывать их.
Дальше в customError вы можете настроить обработку пользовательских ошибок, но можно и оставить без изменений.
В customParams мы записываем все параметры, которые можно будет запрашивать в смарт контракте.
Например в шаблоне есть строка:
base: ['base', 'from', 'coin']
которую можно заменить на
city: ['city', 'town']
если мы хотим, например, запрашивать температуру в определенном городе. Тогда в смарт контракте потребуется прописать строку запроса:
req.add("city", "boston");
Так же тут можно указать необязательные параметры, которые, возможно, будут в API ссылке, как, например, тут:
https://api.openweathermap.org/data/2.5/weather?q=<CITY_NAME>&appid=<YOUR_API_KEY>
где weather - и есть endpoint.
Endpoint, грубо говоря, это некая точка запроса на стороне сервера, которая выдает определенные параметры. В случае с weather она может отдавать температуру в int, а, например, с storm - есть ли угроза торнадо в регионе в булевом значении.
Иногда эти endpoint нужны в ссылке API, а иногда можно обойтись и без них. Поэтому этот параметр не обязателен.
Далее идет функция создания запроса createRequest. И тут обратим внимание на код внутри:
const validator = new Validator(callback, input, customParams)
создает объект Валидатора, куда передается callback (об этом позже), input от пользователя в контракте, параметры, которые мы прописали выше.
const jobRunID = validator.validated.id
Здесь функция получает jobId. Если забыли, что это такое, то прочитайте посты выше.
const endpoint = validator.validated.data.endpoint || 'price'
еще раз проверяем endpoint и через символ "||" указываем значение по умолчанию,
const url = `https://min-api.cryptocompare.com/data/${endpoint}`
и передаем ссылку API.
const appid = prosess.anv.API_KEY;
Некоторые API для подключения требуют регистрации на сервисе и получения уникального ключа доступа API_KEY, его можно хранить, как переменную среды в файле .env.
В конце мы создаем переменную, куда помещаем данные о параметрах запроса, в нашем случае это city:
const cityData = validator.validated.data.city.toUpperCase()
Приведение к одному регистру нужно для дополнительной корректности передачи значений.
Далее в const params мы передаем cityData и appid.
Переменная const config будет работать типа axios, это такой способ передачи данный через url. И тут не нужно указывать дополнительные значения типа "get" или "headers".
После подготовки запроса мы создаем функции отправки запроса - Requester.request(), где в качестве аргументов передаются config и customErros.
response.data.result = Requester.validateResultNumber(response.data, ["path", "data"])
В этой строке особое внимание заслуживает ["path", "data"] - где определяется путь в json файле по ссылке до нужной нам информации. Например:
Из файла {"region": {"city":"boston"} - нужно будет передать ['region', 'city']
И затем вызывается callback функция:
callback(response.status, Requester.success(jobRunID, response))
В принципе, это все. Дальше код нам не интересен, так как он выполняет скорее служебные функции.
Как я уже говорил, после написания Адаптера, нам нужно подключить его к узлу, настроить Bridge и jobId, и запустить на нем Адаптер. После всех этих манипуляций вы можете написать смарт контракт, сделать деплой и запрашивать информацию с нужного API.
#chainlink #api #adapter
Chainlink NodeJS IPFS External Adapter
Кстати, в одном из официальных видео chainlink один из его разработчиков упоминал, что работает над своим собственным шаблоном передачи и получения данных с хранилища IPFS в смарт контракт.
На данной этапе я еще не разбирал его, и боюсь, что потом потеряю ссылку на его репозитарий. Поэтому оставляю ссылку тут.
Если кому будет интересно, то все это бесплатно. Скачайте к себе и смело экспериментируйте!
#chainlink #api #ipfs #adapter
Кстати, в одном из официальных видео chainlink один из его разработчиков упоминал, что работает над своим собственным шаблоном передачи и получения данных с хранилища IPFS в смарт контракт.
На данной этапе я еще не разбирал его, и боюсь, что потом потеряю ссылку на его репозитарий. Поэтому оставляю ссылку тут.
Если кому будет интересно, то все это бесплатно. Скачайте к себе и смело экспериментируйте!
#chainlink #api #ipfs #adapter
Перевод bytes32 в string
В некоторых случаях, после получения данных с оракула или откуда-нибудь еще в формате bytes32, нам требуется перевести их в читаемый строковый вид.
Для этого делюсь тут хорошей библиотекой, которую можно скачать в свою папку с проектом и подключить в контракт.
Ссылка на GitHub тут.
#library #bytes32 #string
В некоторых случаях, после получения данных с оракула или откуда-нибудь еще в формате bytes32, нам требуется перевести их в читаемый строковый вид.
Для этого делюсь тут хорошей библиотекой, которую можно скачать в свою папку с проектом и подключить в контракт.
Ссылка на GitHub тут.
#library #bytes32 #string
Планы на неделю
Хочу поделиться с вами планами на неделю по постам канала.
Прежде всего мы закончим разбирать последнюю часть chainlink. На прошлой неделе после первых трех разделом у меня голова лопалась от количество информации, и я взял пару дней на разгрузку. Надеюсь, что и у вас они прошли превосходно.
Я также давно писал, что после chainlink мы перейдем к разбору uniswap, но с этим чуть повременим. Во-первых, я хочу еще раз попрактиковаться с chainlink на неделе, и во-вторых, по ходу разбора уроков, я встречал сервисы, стандарты и определения, о которых ничего не знаю.
Поэтому на этой неделе мы поговорим о таких сервисах как Gnosis и Ankr, узнаем о многих других стандартах ERC, попробую найти информацию о популярных ошибках в коде Solidity и их причину, а также чуть подробнее рассмотрим xNFT, ETF и flashloan.
Прекрасно понимаю, что некоторые уже могли продвинуться дальше и знают большую часть предлагаемого к рассмотрению материала, но, наверняка, многие встретятся с этим впервые.
Продолжаем учиться!
Хочу поделиться с вами планами на неделю по постам канала.
Прежде всего мы закончим разбирать последнюю часть chainlink. На прошлой неделе после первых трех разделом у меня голова лопалась от количество информации, и я взял пару дней на разгрузку. Надеюсь, что и у вас они прошли превосходно.
Я также давно писал, что после chainlink мы перейдем к разбору uniswap, но с этим чуть повременим. Во-первых, я хочу еще раз попрактиковаться с chainlink на неделе, и во-вторых, по ходу разбора уроков, я встречал сервисы, стандарты и определения, о которых ничего не знаю.
Поэтому на этой неделе мы поговорим о таких сервисах как Gnosis и Ankr, узнаем о многих других стандартах ERC, попробую найти информацию о популярных ошибках в коде Solidity и их причину, а также чуть подробнее рассмотрим xNFT, ETF и flashloan.
Прекрасно понимаю, что некоторые уже могли продвинуться дальше и знают большую часть предлагаемого к рассмотрению материала, но, наверняка, многие встретятся с этим впервые.
Продолжаем учиться!
Chainlink Automation / Keeper. Часть 1
В начале важно сказать, что chainlink, с одним из последних обновлений сервиса, переименовали Keepers в Automation. Поэтому, если будете искать дополнительную информацию об этом, то все видео и статьи с Keepers уже слегка устаревшие.
Также хорошая новость заключается в том, что на данный момент не требуется писать какой-то сложный код, чтобы автоматизировать свой контракт. А, в случае с Time-base контрактом, или контрактом определяющего выполнения своих функций по прошествии определенного времени, так вообще ничего не нужно прописывать или наследовать дополнительно.
Вообще, на данный момент, Chainlink Automation показался мне самым автоматизированным из всех других частей сервиса.
И для начала поговорим про Time-base контракты.
#chainlink #keeper #automation
В начале важно сказать, что chainlink, с одним из последних обновлений сервиса, переименовали Keepers в Automation. Поэтому, если будете искать дополнительную информацию об этом, то все видео и статьи с Keepers уже слегка устаревшие.
Также хорошая новость заключается в том, что на данный момент не требуется писать какой-то сложный код, чтобы автоматизировать свой контракт. А, в случае с Time-base контрактом, или контрактом определяющего выполнения своих функций по прошествии определенного времени, так вообще ничего не нужно прописывать или наследовать дополнительно.
Вообще, на данный момент, Chainlink Automation показался мне самым автоматизированным из всех других частей сервиса.
И для начала поговорим про Time-base контракты.
#chainlink #keeper #automation