Я разрабатываю автономный сервис, который обрабатывает запросы и отправляет транзакцию в блокчейн, когда каждый запрос завершен. В течение временного интервала одного блока сервис может обрабатывать множество запросов для многих пользователей. Транзакции завершения функционально независимы друг от друга, и порядок их выполнения не имеет значения. Я хочу надежно публиковать каждую транзакцию, не беспокоясь о взаимодействиях, которые могут привести к сбоям.
В разделе «Множественные транзакции с одного и того же адреса » Пол С. пишет:
Если у вас есть зависимости от транзакций в вашем приложении вне блокчейна, вам следует подождать, пока предыдущая транзакция не будет добыта, прежде чем отправлять следующую транзакцию.
У меня нет функциональных зависимостей транзакций, но все же: в качестве примера проблемы, которую я хотел бы избежать, предположим, что я одновременно отправляю N транзакций с одного и того же адреса, правильно увеличивая одноразовый номер для каждой. Если все эти транзакции должны быть включены в один и тот же блок, майнер должен убедиться, что они происходят в порядке увеличения одноразового номера, чтобы составить действительный блок. Или, если включено только подмножество из K<N транзакций, подмножество должно состоять из первых K транзакций, опять же по порядку. Учитывая то, как ожидающие транзакции вероятностно ретранслируются по сети, я обеспокоен тем, что всплеск транзакций с одного и того же адреса не может быть надежно собран в блок.
Является ли лучшим подходом использование разных адресов отправителя для каждой транзакции?
Кажется, это решает проблему пула транзакций и одноразовых номеров, но усложняет другие аспекты децентрализованного приложения, такие как управление закрытыми ключами и белые списки адресов отправителей в контрактах.
Я не уверен, что это необходимо на практике; Совет, который вы цитируете, предназначен для ситуации, когда вы делаете необработанные транзакции в автономном режиме и можете отбросить некоторые из них, но если вы просто отправляете свои транзакции через Geth, он должен обрабатывать широковещательную передачу транзакций и приращение nonce, и в целом все должно быть просто Работа. Тем не менее, это правда, по крайней мере теоретически, что отправка транзакций с одной и той же учетной записи приводит к тому, что сбои передачи каскадируются таким образом, который вам не нужен.
Если вы хотите отправлять свои транзакции с разных учетных записей, но не хотите, чтобы остальная часть вашего приложения имела дело с сотнями разных адресов учетных записей, вы можете абстрагировать эту часть: используйте один ключ, чтобы создать отдельный подпись, которую вы передаете в части данных транзакции. Отправьте это промежуточному контракту, который принимает транзакции, поступающие с любого адреса, и вместо этого проверяет, соответствует ли подпись, переданная ему в качестве параметра, вашему единственному ключу подписи. Затем пусть промежуточный контракт сделает то, что вы изначально намеревались сделать. Для любых последующих контрактов это будет выглядеть как исходящий из промежуточного контракта, поэтому у вас будет один общий msg.sender, как если бы вы отправляли все транзакции с одного и того же адреса.