Уважаемые пользователи Голос!
Сайт доступен в режиме «чтение» до сентября 2020 года. Операции с токенами Golos, Cyber можно проводить, используя альтернативные клиенты или через эксплорер Cyberway. Подробности здесь: https://golos.io/@goloscore/operacii-s-tokenami-golos-cyber-1594822432061
С уважением, команда “Голос”
GOLOS
RU
EN
UA
hashgardrussian
6 лет назад

Команда разработчиков Hashgard: как совершать крупные сделки с Ethereum

Механизм обмена, который решает проблему перегруженности системы при обменах ETH

Будучи наиболее широко используемой сетью, в которой заключаются смарт-контракты, ETH подвержена системным перегрузкам из-за ограничений количества транзакций в секунду (текущая скорость производительность блока ETH составляет 14 секунд / блок, каждый блок может содержать до 140 транзакций, что равно 10 транзакциям в секунду). Поэтому разработчики, приступающие к реализации любого проекта, должны учитывать издержки, связанные с ограничением пропускной способности блоков, а также принимать во внимание комиссию за обработку транзакции.

Инициируя транзакцию c ETH, майнеры генерируют новый блок для обработки этой транзакции и получают за это вознаграждение. Чтобы лучше объяснить процесс, мы используем простые аналогии, показывающие, в чем этот процесс заключается.

Рабочая нагрузка = Стоимость топлива

Лимит газа = Количество топлива(Твёрдая величина)

Цена газа(Единица:Gwei) = Единица стоимости топлива

Майнеры = Владельцы онлайн-сервиса Gas Station 

Комиссия за транзакцию = Рабочая нагрузка (Стоимость топлива) = Лимит газа (Количество топлива) x Цена газа (Единица стоимости топлива)

Из-за ограничения количества транзакций в секунду (TPS) для каждого блока, чтобы максимизировать прибыль, майнеры будут в первоочередном порядке осуществлять транзакции, которые платят самую высокую цену за газ (внутреннюю валюту для заключения смарт-контрактов). Как правило, ETH рекомендует величину цены на газ для обеспечения разумных цен и увеличения скорости транзакции. По мере того, как в «пробке» накапливаются транзакции, ожидающие своей обработки, возникает перегрузка системы, и пользователи значительно повышают цену газа, чтобы не застрять надолго в этой «пробке» позади других транзакций. Возникает порочный круг, поскольку все больше и больше пользователей устанавливают все более высокие цены на газ. Таким образом, цена на газ продолжает расти, в результате иногда она превышает нормальную цену в 10, а иногда даже и в 100 раз.

Фотография выше отражает динамику цены на газ. Нижняя синяя линия и зеленая линия - соответственно безопасные цены и рекомендованные цены от etherscan.io. Средняя бирюзовая линия – это стандартная цена на газ, заданная нодами ETH по умолчанию. (Стандартная цена на газ — это средняя цена на газ, рассчитанная по нескольким последним блокам, умноженная на константу). Безопасная цена рассчитывается нодами на etherscan.io. При отправке транзакций не устанавливайте более низкую стоимость газа, чем безопасная цена, иначе вы временно не сможете найти подробную информацию об этой транзакции на etherscan.io. Стандартная цена на газ обычно выше, чем безопасная цена от Etherscan.io. Установка стандартной цены на газ, как правило, позволяет обработать транзакцию в течение несколько минут. Между тем, предложенная цена — это приоритетный метод определения цены на газ, обычно позволяющий принять транзакцию в обработку в нескольких блоках. 

- 02 -

«Пробки» ETH — Передача пакетов

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

Следующий параграф объясняет, что такое nonce в ETH. В соответствии с механизмом системы учета ETH транзакции, отправленные с любых адресов, содержат порядковый номер, начиная с 0. Когда следующая транзакция, отправленная с одного и того же адреса, упакована в блок, порядковый номер увеличивается на 1. Система нумерации, которая используется для записи порядка и количества истории транзакций, а также для подтверждения того, что для данного блока было выполнено достаточное количество вычислительных операций, называется nonce. Если адрес A хочет отправить 10-ю транзакцию после того, как все 9 транзакций были отправлены успешно, значение nonce будет установлено как 9 (начиная с 0). Если установить 10, то тем, кто имеет меньший номер, придется дождаться появления транзакции с nonce из 9, а тот, у кого нет 10, не сможет быть упакован в блок. В результате те, кто имеют меньший номер, должны будут обеспечить выполнение транзакций на основе численного значения nonce. Если есть две транзакции со значением nonce 9, нода будет выбирать ту из них, у которой выше транзакционные сборы, и не будет обрабатывать другую транзакцию.

Как показано на графике, когда имеются 10 транзакций, поручения об осуществлении которых даны из адреса A и упакованы в блок, значение nonce равно 9 (начиная с 0). Таким образом, транзакции со значениями nonce 10, 11, 12 будут упакованы теми, кто имеет меньшее значение nonce, по их заказам. Эти несанкционированные транзакции находятся на рассмотрении. Однако, поскольку транзакция со значением nonce 13 отсутствует, транзакция с nonce 14 временно недоступна для включения в группу потенциальных транзакций, готовых к упаковке; вместо этого он находится в состоянии ожидания. Как только транзакция со значением nonce 13 появится в торговом пуле, то значение nonce будет считаться действительным, и блок можно будет добавить в блокчейн, и транзакция со значением nonce 14, скорее всего, будет упакована.

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

- 03 -

Стратегии на случай, если возникла «пробка» 

Если в системе возникают перегрузки, то становится востребованной стратегия множества чисел и множества адресов. Сначала устанавливается «водный потолок». Когда адрес в очереди имеет 50 незавершенных транзакций в торговом пуле, он будет заблокирован для отправки транзакций до тех пор, пока эти 50 транзакций не будут упакованы теми, кто имеет меньшее значение nonce. Кроме того, для отправки транзакций будут использоваться несколько адресов – это позволит избежать поломки инструментального модуля. Поломка инструментального модуля может произойти, если какая-нибудь одна транзакция в нём «застрянет». Кроме того, если транзакция ожидает своей очереди долгое время, поручение о её совершении может быть направлено вновь с более высокой и более разумной ценой газа. Нода, в которой содержатся поручения тех, кто имеет меньшее значение nonce, заменит старые поручения о совершении транзакций новыми – это, как правило, помогает решить проблемы, связанные с перегрузкой системы. Такой механизм динамической компенсации широко используется обменными учреждениями и электронными кошельками.

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

- 04 -

Пакетная передача на уровне смарт-контракта

Если исходить из того, что токен ERC20 отправляется с одного адреса на 10 адресов, то получается, что текущий подход заключается в создании транзакции, которая предусматривает передачу для каждого адреса, генерацию 10 транзакций в пакетах и направление поручений об их проведении. Если в транзакции, такой, например, как транзакции в BTC, можно написать несколько операций переноса, то потребление газа может быть уменьшено.

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

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

Существуют и другие способы осуществления пакетной передачи на уровне контракта.

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

Адрес B — это токен-контракт, который поддерживает стандарт ERC20. Он обеспечивает метод «передачи». Мы можем использовать промежуточный контракт для реализации логики пакетного заключения контрактов. «Пакетная передача» в промежуточном контракте получает адрес контракта токена ERC20. Массиву адресов получателей криптовалюты противопоставлен массив передаваемых токенов. Для каждого получателя в акцепторном массиве функция «передача» в контракте Token (адрес B) вызывается извне, а код реализации выглядит следующим образом: «_token.call (bytes4 (keccak256 (« transfer (address, uint256) ») получатели [index], amount [index]). Так реализовано использование «вызова», что является очень простым и надежным методом включения своей транзакции в следующий блок. Но если использовать передачу ненадлежащим образом, будут возникнут риски, связанные с безопасностью транзакций. Поэтому важно понимать, как работает «вызов».

Обратите внимание, что когда «передача» токен-контракта (адрес B) инициируется за пределами промежуточного контракта (адрес A), из-за характера «вызова» отправитель сообщения будет изменяться с исходного адреса C на адрес A, который фактически выдается по адресу A. При этом, чтобы выдать токен из адреса A, мы должны сначала перенести достаточное количество токенов на адрес A. Для обеспечения наличия достаточного количества токенов на промежуточном контракте (адрес A), контракт должен быть назначен владельцу. В пакетной передаче должна быть логика, чтобы проверить, соответствует ли владельцу вызывающий адрес C. Эта логика должна обеспечивать, чтобы владельцем был адрес C; только промежуточный C может быть вызван по адресу C, а комиссия за транзакцию вычитается из адреса C.

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

Давайте посмотрим, насколько действенна программа.

На следующем рисунке показана востребованность метода передачи в токен-контракте с адреса:

Промежуточная передача BatchTransfer Caller используется для вызова передачи токен-контракта. Здесь мы передаем только одного получателя в массив параметров.

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

На данный момент, по сравнению с методом передачи, который 10 раз напрямую вызывает токен, пакетная передача через контракт BatchTransfer Caller экономит около 30% от общего потребления газа, что весьма впечатляет. 

- 05 -

Резюме

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


Ссылки

Группа телеграмм: https://t.me/hashgardeng

Reddit: https://www.reddit.com/r/Hashgard/

Канал телеграмм: https://t.me/hashgardengchannel

Medium: https://medium.com/@hashgard

Twitter: https://twitter.com/Hashgard1

Linkedin: https://www.linkedin.com/company/hashgard/

Русскоязычный чат телеграмм: https://t.me/hashgardrussian

Русскоязычный канал телеграмм: https://t.me/HashgardRussiachannel

0
0.000 GOLOS
На Golos с August 2018
Комментарии (0)
Сортировать по:
Сначала старые