Контрактные адреса етн что это

Адреса в Ethereum

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

Адрес

Адрес идентифицирует аккаунт в сети Ethereum и имеет следующий вид:

160 бит | 20 байт | 40 символов (hexadecimal)

Для шестнадцатеричного представления (далее hexadecimal) каждый байт кодируется двумя символами, поэтому для определения длины в байтах нужно количество символов в строке поделить на два. При подсчёте длины строки мы не учитываем префикс 0х перед адресом, так как он несёт лишь информацию о том, что строка справа представляет собой hexadecimal-последовательность.

Кстати, адрес в примере выше, это реальный адрес из главной сети Ethereum. На момент написания статьи стостояние его аккаунта выглядело так:

Перейдём к описанию процесса формирования адреса.

Формирование адреса

Прежде чем приступить к рассмотрению процесса формирования адреса, необходимо уточнить, что в сети Ethereum существуют два типа аккаунта:

Externally-owned account (EOA)

Поскольку назначение этих аккаунтов отличается, то и адреса к ним формируются по-разному. Приведу основные различия этих аккаунтов:

Externally-owned account (EOA)

Contract account

Только EOA обладает приватным ключом. EOA управляется тем, кто владеет приватным ключом.

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

Инициатором транзакций в сети Ethereum может быть только EOA.

Контракты тоже могут осуществлять транзакции, но первоначальным инициатором всё равно будет EOA.

Создание EOA абсолютно бесплатное.

Списывается пошлина в виде Gas за storage, которое используется контрактом.

Далее мы рассмотрим отдельно как формируется адрес для Externally-owned account и для Contract account.

A. Формирование адреса для EOA

Процесс формирования выглядит следующим образом: сперва генерируется приватный ключ, затем на основании приватного ключа генерируется публичный ключ, далее вычисляется хэш публичного ключа и берутся последние 20 байт от вычисленного хэша — это и будет адрес EOA.

Разберём процесс более детально.

Шаг 1. Генерация приватного ключа.

Пример приватного ключа:

Длина приватного ключа:

256 бит | 32 байта | 64 символа (hexadecimal)

Шаг 2. Генерация публичного ключа.

На основании приватного ключа при помощи алгоритма ECDSA (Elliptic Curve Digital Signature Algorithm) генерируется публичный ключ.

Пример публичного ключа:

Длина публичного ключа:

512 бит | 64 байта | 128 символов (hexadecimal)

Шаг 3. Вычисляем хэш публичного ключа

Используя хэш-функцию Keccak-256 получаем хэш публичного ключа:

256 бит | 32 байта | 64 символа (hexadecimal)

Шаг 4. Берём последние 20 байт от хэша публичного ключа

Отсчитываем последние 40 символов от хэша, который был получен на предыдущем шаге:

Эти 20 байт и будут нашим адресом.

После рассмотрения всех шагов, попробуем сгенерировать адрес самостоятельно.

Практический пример получения адреса для EOA

Для генерации адреса EOA я воспользуюсь библиотекой helpeth. Команда keyGenerate сгенерирует приватный и публичный ключ, а также сам адрес:

Готово. Мы получили как ключи, так и сам адрес. Единственное, вызов команды keyGenerate не отображает хэш публичного ключа, так как хэш является промежуточным шагом для получения адреса. Но для наглядности я покажу как мы можем вычислить хэш самостоятельно командой keccak256 на вход которой мы подадим публичный ключ:

Видим, что последние 40 символов хэша действительно отражают адрес нашего аккаунта:

Подытожив, можно прийти к выводу, что в EOA аккаунте, и публичный ключ и адрес производны от приватного ключа. Вы спокойно можете забыть адрес аккаунта и его публичный ключ. Чтобы восстановить эти данные вам достаточно иметь приватный ключ. Путём математических преобразований вы снова можете получить тот же публичный ключ и тот же адрес. Однако потеряв приватный ключ, вы утратите доступ к аккаунту, а средства на его балансе будут навсегда заморожены в сети Ethereum, либо будут присвоены злоумышленником, который завладел вашим приватным ключом.

Отлично, мы познакомились с получением адреса для Externally-owned account, и теперь пришло время взглянуть на получение адреса для Contract account.

B. Формирование адреса для Contract account

Как было отмечено выше, у Contract account нет приватного ключа, поэтому его адрес формируется из адреса EOA-аккаунта, с которого он был создан, и поля nonce этого аккаунта. Про поле nonce я рассказывал в одной из своих предыдущих статей.

Если изобразить функцию создания адреса на псевдокоде, то она будет выглядеть следующим образом:

Разберём детально по шагам, что же здесь происходит:

Берется адреc EOA аккаунта, который отправил транзакцию на создание контракта

Берётся поле nonce из транзакции на создание контракта

Адрес отправителя и nonce сериализуются при помощи RLP-кодека

Вычисляется Keccak-256 хэш от сериализованного значения

Последние 160 бит хэша и будут адресом нашего контракта

Таким образом, адрес одного и того же контракта, повторно созданного с одного и того же аккаунта будет всегда различаться, так как с каждой новой транзакцией поле nonce увеличивается на 1 и меняет хэш адреса-отправителя.

Одно важное уточнение. У созданного аккаунта смарт-контракта тоже есть поле nonce , но в отличие от EOA аккаунта, оно инициализируется единицей, тогда как у EOA поле nonce инициализируется нулём. Изначально у обеих типов аккаунтов поле nonce инициализировалось нулём, но затем были внесены правки.

Помимо адресов, созданных участниками блокчейна, существуют ещё и служебные адреса, которые принадлежат самому блокчейну. Давайте рассмотрим парочку таких адресов.

Служебные адреса

Нулевой адрес 0x0000000000000000000000000000000000000000

Выше я упомянул, что контракт создаётся при помощи транзакции. У любой транзакции должен быть отправитель и получатель, и если с отправителем всё более менее понятно, то не совсем понятен адрес получателя при создании контракта. Если вдуматься, то на момент отправки такой транзакции блокчейн ещё ничего не знает о новом контракте, а соответсвенно в сети нет его адреса. На какой же адрес отправляется эта транзакция? Ответ прост — мы либо вообще не указываем в транзакции поле отправителя, либо явно указываем to: null

Пока я писал статью, то обнаружил, что в сети есть путаница относительно того, что для создания контракта можно указать адрес состоящий из всех нулей. Видимо путаница возникла из-за того, что в разных версиях документации к Solidity по-разному писали про адрес создания контракта, а официальная спецификация Ethereum не совсем точно отражала значение этого адреса в транзакции на создание контракта.

Из ранней документации Solidity:

If the target account is the zero-account (the account with the address 0 ), the transaction creates a new contract.

После версии v0.5.0 Solidity:

If the target account is not set (the transaction does not have a recipient or the recipient is set to null ), the transaction creates a new contract.

В официальной спецификации Ethereum, так называемой Yellow Paper, просто говорится про RLP empty byte sequence:

The address hash Tt is slightly different: it is either a 20-byte address hash or, in the case of being a contract creation transaction (and thus formally equal to ∅), it is the RLP empty byte sequence and thus the member of B0

Примечательно, что Gavin Wood, который собственно и написал Yellow Paper, в своей книге Mastering Ethereum указал адрес создания контракта как 0x0 :

Contract creation transactions are sent to a special destination address called the zero address; the to field in a contract registration transaction contains the address 0x0.

После обсуждений со @splix я решил самостоятельно вручную создать тело транзакции с контрактом в поле data и отправить её сначала на адрес со всеми нулями, а затем на адрес null . Так вот контракт создался именно когда в поле to был null , или поля to вообще не было. В случае с нулями, транзакция просто уйдёт на нулевой адрес, а контракт не будет создан. Если в поле value при создании контракта ещё и были Ether, то они просто пополнят баланс нулевого адреса.

Вот так выглядит нулевой адрес:

Если присмотреться, то можно обнаружить, что на нулевом адресе лежит довольно крупная сумма Ether. На момент написания статьи, сумма была эквивалентна 21 миллионам долларов США. Откуда на нулевом адреса эти средства? Как ни странно, это навсегда замороженные средства, которые были намеренно или по ошибке отправлены на нулевой адрес. Ошибиться мог как человек, забывший указать поле адреса-получателя, и оно было интерпретировано как нулевой адрес, так и программист, который неверно инициализировал адрес получателя. Выше мы и сами видели один из примеров ошибочной отправки Ether на нулевой адрес при попытке создания смарт-контракта. Почитать подробнее про причину появления средств на нулевом адресе можно здесь и здесь. Так же нулевой адрес можно использовать и для намеренного уничтожения Ether, и таких адресов достаточно много.

Адреса для уничтожения Ether

Если вы немерено решили уничтожить свои средства, то для этого в сети Ethereum существуют специальные Burn адреса. Судя по их капитализации, на данный момент основным адресом для этих целей выступает dEaD адрес.

Окончание адреса говорит само за себя. Средства, отправленные на этот адрес будут навсегда утеряны. На самом деле токены и Ether уничтожаются не просто так, для этого есть множество экономических причин, одна из которых — сократить общее предложение, тем самым повысив спрос.

Кстати, у нулевого и dEaD аккаунтов, а так же у других Burn адресов, нет приватного ключа, поэтому никто не имеет к ним доступ. Если же вам всё же удастся подобрать приватный ключ к ним, то технически вам ничто не мешает распоряжаться средствами на этих аккаунтах.

В заключение я бы хотел коснуться хэш-функции Keccak-256 в Ethereum.

Keccak-256 vs SHA-3

Стандарт SHA-3 реализован по алгоритму хэширования Keccak-256. Но между реализацией алгоритма Keccak-256 в стандарте SHA-3 и в сети Ethereum есть различия.

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

Чтобы точно определить какая перед вами реализация, есть эталонные хэши от пустой строки:

Почему команда Ethereum решила написать свою реализацию алгоритма Keccak-256? Для этого обратимся к истории создания этих двух реализаций.

Алгоритм хэширования Keccak-256 стал победителем среди алгоритмов претендующих на стандарт семейства Secure Hash Algorithm (SHA), и был стандартизован как FIPS-202 SHA-3 standard в 2015 году. Уже после завершения процесса стандартизации, и перед самым опубликованием стандарта, National Institute of Standards and Technology (NIST) решил скорректировать некоторые параметры алгоритма, предположительно для улучшения его эффективности.

Всё это произошло в то же самое время, когда Эдвард Сноуден обнародовал документы, которые пролили свет на тот факт, что National Security Agency (NSA) могло повлиять на NIST, чтобы намеренно ослабить стандарт генератора случайных чисел Dual_EC_DRBG, фактически поместив бэкдор в стандартный генератор случайных чисел.

После огласки, выход реализации стандарта SHA-3 пришлось отложить. Ethereum в этот момент был ещё на стадии разработки. Чтобы не останавливать разработку, а так же иметь более прозрачную реализацию алгоритма, команда Ethereum решила самостоятельно реализовать оригинальный алгоритм Keccak-256.

Более подробно про SHA3 и Keccak-256 можно почитать здесь.

На этом пожалуй всё. В этот раз мы познакомились со всеми этапами формирования адреса в сети Ethereum, а заодно затронули такие важные понятия, как приватный и публичный ключ, хэш-функцию и служебные адреса.

В статье была допущена ошибка при описании адреса создания контракта. Статья была обновлена. Спасибо пользователю @splix за то что обратил на это внимание.

Что такое контрактный адрес ETH и как он работает

Контрактный адрес eth — это уникальный идентификатор, который используется в блокчейне Ethereum для определения места, где хранится и выполняется смарт-контракт. Смарт-контракт — это программа, записанная на языке Solidity, которая автоматически исполняется при выполнении определенных условий.

Использование контрактного адреса eth важно для взаимодействия с смарт-контрактами на Ethereum. Чтобы обратиться к контрактному адресу eth, нужно знать его точный адрес, который состоит из 40-значной шестнадцатеричной строки.

Контрактные адреса eth могут использоваться в различных случаях, например, при разработке децентрализованных приложений (dApps), создании токенов на базе Ethereum или в смарт-контрактах для реализации условий выполнения кода.

Для использования контрактного адреса eth необходимо использовать специальные программные клиенты, такие как Mist или Metamask, которые позволяют взаимодействовать с блокчейном Ethereum. Через эти клиенты можно отправлять транзакции на контрактные адреса eth, вызывать функции смарт-контрактов и получать результаты выполнения кода.

Таким образом, контрактный адрес eth — это важный элемент инфраструктуры Ethereum, который позволяет разработчикам создавать и взаимодействовать с смарт-контрактами на блокчейне Ethereum.

Что такое контрактный адрес eth и как его использовать?

Контрактные адреса ETH имеют следующие особенности:

• Контрактные адреса имеют длину 40 символов.
• Они начинаются с префикса «0x», который обозначает, что это адрес в шестнадцатеричной системе.
• Адреса создаются с помощью вычислительного алгоритма, который уникальным образом генерирует новые адреса на основе исходных данных.

Для использования контрактного адреса ETH вам потребуется кошелек Ethereum, который поддерживает взаимодействие с смарт-контрактами. Вы можете использовать такие кошельки, как MetaMask, MyEtherWallet или любой другой кошелек, который поддерживает Web3 API.

Чтобы использовать контрактный адрес ETH, вы должны знать точный адрес смарт-контракта, с которым вы хотите взаимодействовать. Вы можете найти контрактный адрес в блокчейн-эксплорере Ethereum, где выделенный контракт будет иметь свой отдельный адрес. После получения контрактного адреса вы можете использовать его в своем кошельке Ethereum для взаимодействия со смарт-контрактом.

Взаимодействие с смарт-контрактом по контрактному адресу ETH может включать отправку транзакций, вызов функций контракта, чтение данных контракта и т. д. Эти действия могут выполняться с помощью веб-интерфейса вашего кошелька Ethereum или с помощью программного кода, использующего Web3 API.

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

Контрактный адрес eth: понятие и спецификации

Контрактный адрес eth можно использовать для:

• Отправки эфира (ETH) на контрактный адрес — это позволяет активировать и запустить функции смарт-контракта;
• Чтения данных с контрактного адреса — это позволяет получить информацию о состоянии и параметрах смарт-контракта;
• Использования функций, определенных в смарт-контракте — это позволяет выполнить операции, определенные разработчиком смарт-контракта.

Контрактный адрес eth имеет следующие особенности и спецификации:

Спецификации	Описание
Уникальность	Каждый контрактный адрес eth является уникальным и не может быть использован дважды.
Автоматическая генерация	Контрактный адрес eth генерируется автоматически при развертывании смарт-контракта на блокчейне Ethereum.
Публичность	Контрактный адрес eth является публично доступным и может быть использован для взаимодействия с смарт-контрактом.
Безопасность	Контрактный адрес eth не может быть изменен или удален без согласия владельца смарт-контракта и обеспечивает безопасность его использования.

Использование контрактного адреса eth позволяет значительно расширить возможности блокчейна Ethereum и создать различные децентрализованные приложения и сервисы.

Как получить контрактный адрес eth?

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

Создание умного контракта на Ethereum может быть выполнено с помощью специальных языков программирования, таких как Solidity. Код умного контракта должен быть скомпилирован в байт-код и размещен в блокчейне.

После создания умного контракта, вы получите его адрес. Контрактный адрес представляет собой уникальную комбинацию символов и цифр (например, 0x2B5AD5c4795c026514f8317c7a215E218DcCD6cF), который идентифицирует ваш умный контракт на блокчейне Ethereum.

Для получения контрактного адреса eth также можно использовать специальные онлайн-сервисы или программы, написанные на языках программирования, поддерживающих работу с Ethereum, например, на языке Python с использованием библиотеки Web3.py.

В целом, чтобы получить контрактный адрес eth, вам необходимо создать умный контракт на Ethereum и получить его адрес. Контрактный адрес будет использоваться для вызова функций и взаимодействия с вашим умным контрактом на блокчейне Ethereum.

Различные способы использования контрактного адреса eth

1. Направление транзакций: Пользователи могут отправлять ETH или другие токены на контрактный адрес, чтобы взаимодействовать с контрактом или выполнить определенные действия, заданные контрактом. Например, контракт может реализовывать функцию перевода токенов или проводить иные операции средств.

2. Проверка состояния контракта: Контрактный адрес может быть использован для проверки текущего состояния контракта. Пользователи могут получить информацию о балансе контракта или о других параметрах, доступных для публичного просмотра.

3. Взаимодействие с контрактом через смарт-контрактные функции: Контрактный адрес может быть использован в других смарт-контрактах для вызова функций, определенных в данном контракте. Например, смарт-контракт может вызвать функцию контракта для проверки прав доступа или для выполнения бизнес-логики, реализованной в контракте.

4. Хранение токенов или других активов: Контрактный адрес может быть использован для хранения токенов или других активов. Например, смарт-контракт может хранить баланс токенов для каждого пользователя и обрабатывать операции перевода и проверки баланса.

5. Аутентификация: Контрактный адрес может служить в качестве идентификатора для аутентификации пользователей или сервисов. Например, пользователи могут использовать контрактный адрес для авторизации доступа к определенным функциям или ресурсам.

В целом, контрактный адрес eth предоставляет гибкую инфраструктуру для взаимодействия с контрактами на блокчейне Ethereum и реализации различных сценариев использования.

Преимущества использования контрактного адреса eth

• Уникальность: Каждый контракт в Ethereum имеет уникальный контрактный адрес. Это позволяет однозначно идентифицировать контракт среди множества других контрактов в сети.
• Отслеживаемость: Контрактный адрес eth может быть использован для отслеживания действий, совершаемых контрактом. Это позволяет проводить аудит контрактов и убедиться в их правильной работе.
• Гибкость: Контрактный адрес eth может быть использован для взаимодействия с контрактом из различных приложений и услуг. Это позволяет создавать разнообразные смарт-контракты и интегрировать их в различные системы.
• Безопасность: Использование контрактного адреса eth позволяет улучшить безопасность контракта. Транзакции, отправляемые на контрактный адрес eth, проверяются сетью Ethereum и должны соответствовать предварительно заданным правилам контракта.

В целом, использование контрактного адреса eth является важным аспектом разработки и взаимодействия с контрактами в сети Ethereum.

Генерируем красивые адреса в ETH

С вами @danoneo и сегодня я расскажу вам как генерировать красивые и ЭФФЕКТИВНЫЕ адреса для любой EVM сети.

1. Зачем это надо?

Во первых, это удобно — можно сгенерировать адрес с определенной комбинацией символов в начале, например с годом рождения, или почтить память почившего деда (0xDeadDed. ).

Во вторых — так можно сделать "энергоэффективные" адреса и контракты, которые потребляют меньше газа, а следовательно экономят вам бутериумы.

Чем больше нулей в начале адреса — тем дешевле обходятся контрактные взаимодействия! За каждый "нулевой" байт (2 нуля подряд) вы экономите 64 газа. Вот прекрасная статья , которая объясняет этот феномен.

2. Генерируем кошельки

Для генерации красивого кошелька нам понадобится profanity.
Это GPU генератор, который работает в сотни раз быстрее любых CPU-скриптов.

2. Достаем файлы из архива в папку, нас интересуют два файла. Для Windows это profanity.exe, для unix-систем — profanity.x64.

3. Открываем консоль (командную строку), перетягиваем туда мышкой файл profanity.exe, и дописываем —benchmark. Лично у меня на Windows скрипт отказался работать, зато прекрасно завёлся на WSL .

4. Определяемся с тем, что будем генерировать — все возможные настройки можете глянуть в репозитории profanity.

5. Запускаем скрипт, в данном случае я хочу много нулей (аргумент —leading 0). Как видите, для генерации 8 нулей подряд (4 нулевых байта, экономия 256 газа) понадобилось всего 46 секунд. Мне удалось найти адрес с 12 нулями за 10 часов на старенькой GTX 1060 6GB.

Можете сами проверить, вот приватный ключ: 0x331c97251c204feed2e52f156c59530f9c8d82b69ad6a9443be91a68f623850c

6. Попробуем получить адрес DA707E0 (типа DANONEO, поняли??). Использую аргумент —matching DA707E0 , кошелек был найден через 12 секунд:

Но это всё цветочки, перейдем к ягодкам!

3. Генерируем контракты

Взгляните на адреса Opensea Seaport , GasToken , MEV бота .

Я уже рассказывал про это — каждый нулевой байт экономит газ. Это хорошо использовать для контрактов с огромным количеством пользователей (OpenSea), и просто необходимо если вы хотите быть конкурентоспособным MEV-игроком. Ведь там битва идет за каждый наногазик, и побеждает самый дешевый контракт.

Генерировать адрес для контракта можно двумя способами:
Первый — с помощью старины profanity . Адрес контракта можно "предугадать" если известен sender (кошелек-деплоер), и его nonce (кол-во совершенных транзакций). Profanity генерирует кошельки с nonce=0, и смотрит, какой контракт может из них родиться. Это лоховской способ, т.к. у нас есть EIP-1014 и CREATE2 .

Второй — с помощью ERADICATE2 от того же разработчика. Здесь используется CREATE2, который генерирует контракт исходя из: sender(адрес деплоера), salt(рандомные 32 байта), bytecode(байткод создаваемого контракта).

Попробуем сгенерировать контракт с помощью ERADICATE2:

1. Повторяем те же действия, что делали с profanity.

2. Выбираем аргументы для запуска. После -A пишем адрес контракта, с которого будем деплоить целевой контракт. Вместо -I (init-code) лучше выбирать -i (init-code-file), и указывать путь к файлу с байткодом целевого контракта.

3. Добываем байткод — для этого можно использовать Remix, либо взять его на Etherscan во вкладке Contract. Вот байткод для Opensea Seaport :

4. Копируем байткод в файл initcode.txt, добавляем в начало 0x. Ракета заряжена, можем запускать скрипт:

./ERADICATE2.exe -A 0x7f9a26980b0Ecd2F79Af99a18A191e2Aa051aeFc -i ./initcode.txt —leading 0

Чуть больше минуты — и получаем salt для генерации контракта с 10 нулями. Сверяем в Remix:

Сработало! Осталось только задеплоить. Код для контракта-деплоера можно подсмотреть здесь .

4. Что делать если нет видеокарты

Если вы хотите МНОГО нулей, но у вас нету хорошей GPU — можно арендовать GPU ферму . Совершенно точно не стоит использовать это для генерации приватников, т.к. это просто небезопасно.

Зато сервис отлично подходит для генерации salt для контрактов.

5. Бонус

С помощью данных фишек также можно организовать себе удобную работу с большим массивом контрактов. Мне понадобилось сделать сотни прокси-контрактов, и я предварительно сгенерировал salt для контрактов с порядковыми номерами, в диапазоне 0x000-0x999. Это сильно облегчает жизнь, когда надо найти конкретный контракт для одиночного взаимодействия.

Адреса контрактов ETH

Давайте ознакомимся со аккаунтами Ethereum, а именно с их типами. В Ethereum существует два типа аккаунтов:

• Внешние аккаунты
• Контрактные аккаунты

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

Внешний аккаунт (EOAs) контролируется приватным ключом, и если вы владеете приватным ключом, связанным с EOA, вы можете отправлять ether и его сообщения.

Кошельки на контрактной основе являются более надежными и могут быть более безопасными. Например, может быть заключен контракт, в соответствии с которым переводы, превышающие определенный порог, должны утверждаться несколькими лицами. Если все эти ключи находятся на Вашем локальном компьютере, при необходимости раскрытия даже немного улучшенных ключей, 2 из 3-х могут обеспечить гораздо большую безопасность, чем только один ключ.

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