Мы работаем над крупномасштабным приложением, которое выполняет множество транзакций, и мы не уверены, какие именно гарантии дает нам Ethereum/Geth.
В тестовой сети Ropsten мы пытаемся выполнить 100 транзакций одновременно, но добывается только часть. Похоже, что некоторые транзакции отбрасываются пулом транзакций и, следовательно, искажают последующие транзакции из-за одноразового номера транзакции.
Я посмотрел код здесь: https://github.com/ethereum/go-ethereum/blob/master/core/tx_pool.go#L80-L83 .
Вот как вы решаете эту проблему на практике и проверенным способом.
Во-первых, прежде чем планировать, что ваша организация будет слишком крупной, ознакомьтесь с характеристиками блокчейна Ethereum. Количество транзакций в секунду — плохой показатель, поскольку критическая часть здесь — это блок и время, необходимое для его майнинга. Также обратите внимание на лимит газа в блоке, который сейчас составляет около 4,7 миллионов газа. В зависимости от стоимости газа ваших транзакций и даже без учета всех других пользователей, количество транзакций, которые вы можете поместить в блок, ограничено — остальные должны подождать. И здесь в игру вступает техника параллелизма.
Поскольку здесь мы имеем дело с асинхронными вычислениями, простой запуск сотен транзакций приведет к тому, что большинство из них просто потерпит неудачу, как вы правильно заметили. Поэтому вы устанавливаете ограничение на количество генерируемых промисов транзакций и не создаете еще один, пока хотя бы один не разрешится. Сравните это с жонглированием: не более X мячей одновременно в воздухе, иначе все закончится беспорядком. Технически это делается с помощью concurrencyфункции Promise.mapв Bluebird Promise Library . Число, которое вы устанавливаете для ограничения параллелизма, зависит от многих факторов, будьте готовы сделать его переменным и настроить его в соответствии с состоянием сети.
Веселиться.
Я предполагаю, что вы хотите работать с общедоступной сетью Эфириума (основной сетью). Я игнорирую точный ответ, но я читал, что это около 40 транзакций в секунду для всей сети , включая ваши транзакции и любые другие транзакции. А поскольку количество пользователей, использующих общедоступную сеть, увеличивается, количество tx/sec на пользователя уменьшается. Согласно теореме/проблеме CAP ( https://en.wikipedia.org/wiki/CAP_theorem) блокчейн очень хорош в согласованности и устойчивости к разделам и очень плох в доступности. То есть для общедоступной сети эфириума подходит только низкая частота/высокое значение. Для других сценариев необходимо использовать «боковые цепи» или любой другой механизм. Для контролируемых сетей (например, блокчейна консорциума ethereum) производительность может быть настроена по желанию, настраивая алгоритм консула (в этом смысле четность намного лучше, чем geth, что позволяет использовать разные подключаемые системы консенсуса с разными алгоритмами).
Бадр Беллай
ухо
Ричард Хоррокс
ухо