Transaction Submission

The transaction pooling/execution logic within an Ethereum node is based upon the concept of a nonce, which must be incremented exactly once each time a transaction is submitted from the same Ethereum address. There can be no gaps in the nonce values, or messages build up in the queued transaction pool waiting for the gap to be filled (which is the responsibility of the sender to fill). This allows for deterministic ordering of transactions sent by the same sender.

The management of this nonce pushes complexity back to the application tier - especially for horizontally scaled Enterprise applications sending many transactions using the same sender, potentially workload balancing that traffic across multiple Blockchain nodes.

Transaction throughput is also commonly uneven, with periods when the rate of submission of transactions exceeds the efficient transaction-per-block rate of the chain. Flooding these transactions into the Blockchain nodes often results in discarded transactions, because the transaction pools of the individual nodes reach capacity. Or it can result in packing very large numbers of transactions into blocks, resulting in long block times and low efficiency of the network - with reduced overall throughput.

Maybe, counterintuitively, the way to ensure consistent high performance of the chain is to smooth out these peaks in workload, using the tried and tested Enterprise approach of message queuing.

As the above simplified summary shows, the complexities of transaction submission and nonce management can be a significant burden on projects, and attempting to build a bespoke solution is an inefficient task.

Butane provides a built-in fully managed Kafka streaming tier, combined with our EthConnect transaction submission and throttling technology - the core of which is contributed to the community as open source.

Last updated