Руководство по использованию функции разрешения стейблкоина DAI

Вы уже знаете, что для выполнения транзакций в сети Ethereum (включая Polygon, Arbitrum и Optimism) требуется комиссия #Gas.

Теперь, когда цена нативного токена «доступна», вокруг платы за газ не так много шума; однако, как только цена Native Token начнет расти, ваши ленты в Твиттере наполнятся шумом и криком о высокой плате за газ. По понятным причинам.

Добавим к вышесказанному, что при взаимодействии с некоторыми смарт-контрактами, например, контрактом маршрутизатора Uniswap (приложение Uniswap), пользователь должен совершить 2 транзакции:

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

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

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

Если вы разрабатываете свои смарт-контракты, которые потребуют выпуска и управления токенами ERC20, в ваших интересах разработать смарт-контракт с токеном ERC20 с этой функцией.

Хотя теоретически мы могли бы написать намного больше, вместо этого мы делаем быструю демонстрацию варианта использования Permit function в смарт-контракте для DAI Stablecoin.

Давайте запачкаем руки

(A) Локальная настройка

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

(Б) Установка

После того, как код настроен в вашей локальной системе, вам необходимо убедиться, что вы установили все зависимости, используя npm i или yarn install в зависимости от ваших личных предпочтений. .

(C) Что происходит в коде

Строки с 1 по 17 прямые; как и строки с 19 по 21.

Строки 18: nonce

Это НЕ одноразовый номер любого адреса кошелька. Это одноразовый номер, который независимо поддерживается контрактом DAI. Причина: представьте, если бы я предоставил подписанное сообщение, одобряя ваш адрес для использования моего DAI. Это сообщение используется вами, но не один раз, а дважды → технически это можно квалифицировать как «Двойное расходование» и, следовательно, поддержание независимого nonce в смарт-контракте DAI

Строка 63: Подписание сообщения. Тип: _signTypedData

Теперь DAI следует стандарту EIP712 для подписания типизированных сообщений. Не буду это усложнять (если кому-то очень хочется, то просто упомяну об этом в комментарии ниже). Проще говоря, это стандарт, который необходимо принять для подписания сообщения, которое может быть приведено в исполнение с помощью смарт-контракта, а в данном случае — смарт-контракта DAI.

Как видите, _signTypedData требует 3 параметра:

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

Видеть вышеописанное в действии

(a) Запустите скрипт: node scripts/sign.js

• Да, я не использую каску, потому что мне это не нужно. Вы можете выполнить работу, используя только эфиры. Он просто генерирует подпись.
• Для удобства я установил значение nonce, возвращаемое контрактом. То есть он автоматически извлечет правильный одноразовый номер на основе значения, хранящегося в контракте.
• В целях безопасности я устанавливаю крайний срок на 15 секунд от текущей метки времени block.timestamp. То есть эта подпись должна быть отправлена ​​со смарт-контрактом в течение 15 секунд генерации. Тогда я намеренно не зарегистрирую эту подпись за 15 секунд и не проведу транзакцию. Это должно потерпеть неудачу

(b) Как только он будет запущен после использования в вашей среде переменных, вы получите что-то похожее на изображение ниже в вашей консоли:

(c) Проверка того, прошло ли утверждение:

— создание приватной тестовой сети на buildbear.io, ответвления от основной сети Ethereum

— сначала получить несколько токенов на другую учетную запись из сборщика BuildBear:

— просмотр смарт-контракта DAI в моем обозревателе частных тестовых сетей:

— Использование функции разрешения (в части записи контракта): 📝

— Выполнение транзакции (очевидно, неудачная транзакция): ❌

— проверка причины сбоя путем посещения трассировки tx: 🤯

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

Попытка запустить тот же скрипт, но на этот раз с истечением 2 минут и повторным выполнением всего для успешного tx приведет к:

Очевидно, если вы заметили, что я провел вышеуказанную транзакцию с совершенно другого счета, что иначе будет известен как «ретранслятор». Эта учетная запись заплатила цену газа за отправку в блокчейн, что учетная запись 0xD31950cD762281b9849c33bfa5CE9A42B756155 имеет разрешение на передачу моих токенов DAI.

Доказательство:

И это все, что касается использования Функции разрешения в контракте DAI.

О BuildBear

BuildBear предоставляет вам частную тестовую ноду, что делает процесс тестирования плавным и эффективным.

• Чтобы узнать больше о BuildBear, прочитайте здесь документы
• Загрузите указанный выше код Github здесь. 👈

н

:::информация Также опубликовано здесь. р>

:::