Skip to main content

Scalability Report


Many projects have been claiming to process dozens of thousands of transactions per second, even hundreds of thousands of transactions per second. We do not know whether they can really process these numbers of transactions per second, but we would like to make a few comments about it.

Before going into the limit of the number of transactions per second, we think we should answer the following question: Whom are we developing Hathor to? Should it run either in a personal computer or in a data center? When one platform claims that it can process 1,000 transactions per second, what exactly do they mean? What conditions must be achieve to consider it a fair argument? We think that all of these questions are important to both understand the numbers and compare different platforms.

All platforms use some kind of digital signature as part of the verification of a transaction validity. The number of digital signature operations depends on several parameters, including whether it is a multisig wallet or not.

In Hathor, a transaction is usually made of inputs, outputs, parents, and some other fields. During the verification of a transaction, we need to verify the digital signatures of the inputs. The inputs may be spending different types of outputs. For a P2PKH output, we need to verify only one digital signature, while for a P2SH output using multisig, we need to verify n digital signatures, according to the multisig configuration. Anyway, we need to verify at least one digital signature per transaction.

A simple test can find a cap for the number of transactions per second that a CPU can verify. We can measure the number of digital signatures a single CPU is able to verify, thus, it seems reasonable to say that a Quad-Core CPU is able to verify at most four times it.


We chose to test the secp256k1, which is an Elliptic Curve Digital Signature Algorithm defined in Standards for Efficient Cryptography (SEC) used by Bitcoin and many other tokens.

The test of the secp256k1 algorithm was developed in Python 3.6, with a simple call to the libssl library, while the tests of the ecdsap256 and the rsa2048 were directly run using the openssl command-line interface.

There follows the source code of the test:

""" It measures the number of operations per second involving digital signatures.

import timeit

from cryptography.hazmat.backends import default_backend
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.asymmetric import ec

number = 20000

dt = timeit.timeit('ec.generate_private_key(ec.SECP256K1(), default_backend())', number=number, globals=globals())
print('Private key generations per second: {:.1f}'.format(number / dt))

data = bytes(32)
priv_key = ec.generate_private_key(ec.SECP256K1(), default_backend())
priv_key.sign(data, ec.ECDSA(hashes.SHA256()))
dt = timeit.timeit('priv_key.sign(data, ec.ECDSA(hashes.SHA256()))', number=number, globals=globals())
print('Generation of digital signatures per second: {:.1f}'.format(number / dt))

pub_key = priv_key.public_key()
signature = priv_key.sign(data, ec.ECDSA(hashes.SHA256()))
dt = timeit.timeit('pub_key.verify(signature, data, ec.ECDSA(hashes.SHA256()))', number=number, globals=globals())
print('Verification of digital signatures per second: {:.1f}'.format(number / dt))


We have tested this digital signature algorithms using several processors, and the 2.7 GHz Core i7 (I7-8559U) processor was the best in all cases. There follows the results:

Algorithm 1-core CPU 4-core CPU [a]
secp256k1 2,700 10,800
ecdsap256 464 1,856
esa2048 854 3,416

[a] The 4-core CPU is precisely the 1-core CPU multiplied by four. Maybe this multiplier is a little bit bigger because of the Hyper-Threading Technology, but it won't be twice it.


In 2012, Peter Wulle ran a similar test using a 2.2 GHz Core i7- (I7-670QM) and could verify 1,735 digital signatures per second per core [1]. This cap on the number of digital signatures verifications imposes a natural cap on the number of transactions per second that a single server can process.

A possibility to increase this cap is to use a better processor. Even though Xeon processors may have up to 64 cores, they seem too expensive for home users. Usually personal computers are just quad-core with Hyper-Threading.

We wonder what processors those projects are using to be able to process that high number of transactions per second. Either they are using lighter digital signatures algorithms, or they are processing the transactions in a cluster of server distributing the verifications among them.

When a new transaction arrives, the full node has to do a lot of other stuff besides validating the transaction, such as networking, disk i/o and update metadata. This reduces even more the number of transactions per second that a node can process.