![](bg2.png)
Besides their typical use in programming, crypto-
graphic hashes have an important role also in some
specific smart contract patterns (e.g., commit-reveal).
This and the specific context of Ethereum where each
full node executes all confirmed transactions to verify
these makes performance a critical factor. Ethereum
node implementations currently support four types
of hashes: Keccak-256 (Bertoni et al., 2011), SHA-
256 (NIST, 2002), RIPEMD-160 (Dobbertin et al.,
1996) and Blake2b-512 (Aumasson et al., 2013)
1
.
The first three are directly callable from Solidity
in a smart contract implementation, although only
Keccak-256 has a corresponding EVM opcode and
associated cost. SHA-256 and RIPEMD-160 are im-
plemented as precompiled contracts, their cost being
defined in the Ethereum Yellow Paper.
The main component of Blake2, the compression
part, is also provided as a precompiled contract, al-
though there is no default instruction available in
Solidity for executing the complete hash function.
Blake3 (O’Connor et al., 2020) is a novel iteration
of the Blake hashing algorithm, showing also promis-
ing performance results. However, to our knowl-
edge, there is no current support for using Blake3 in
Ethereum smart contracts. In this paper we provide
an early look over an extension for supporting the
complete Blake2 function and we consider also the
integration of Blake3 with Geth (Get, 2013), the most
popular Ethereum node implementation. We provide
a performance comparison between the Blake func-
tions and the other hashes. Our evaluation is per-
formed both in respect to raw CPU performance as
well as for gas costs as defined in the Ethereum spec-
ification, revealing also valuable information on the
correspondence between the two.
In Section 2 we provide background details and
more information about the implications of enhanc-
ing hashing performance in the context of smart con-
tracts. We briefly discuss some implementation de-
tails in Section 3. We present our evaluation results
in Section 4. Finally, we conclude in Section 5 dis-
cussing future steps related to hashing support for the
Ethereum platform.
1
Keccak and Blake2 were both finalists of the SHA-3
NIST competition. Keccak was chosen as a winner due
to less similarity with SHA-2 algorithms although showing
weaker performance than Blake2.
2 BACKGROUND AND
IMPLICATIONS
The native support for Keccak-256 and inclusion of
the precompiled SHA-256 and RIPEMD-160 hashes
is present since early versions of Ethereum. Addi-
tion of the Blake2 hash was only later considered,
following the typical Ethereum standards adoption
methodology, in EIP-152 (Hess et al., 2016). The
addition was motivated by both the enhanced perfor-
mance of the hash and the interoperability in smart
contracts with Zcash (Zca, 2016), another blockchain
using Blake2. As mentioned in Section 1, only the
Blake2 main component, the compression function,
was introduced as a precompiled contract. To com-
plete a hash computation this function must be itera-
tively called for chunks of 128 bytes of the input fol-
lowed by a few other operations like padding. We
believe this part was left out of the addition for pro-
viding flexibility in the implementation depending on
need (e.g., offering optional keyed support). How-
ever, as we will discuss in Section 4, this can severely
impact the costs inflicted by adding the missing part.
Blake2 is also mentioned in another Ethereum
standard proposal, EIP-3102 (Ballet and Buterin,
2020), discussing improvements in the storage of the
blockchain which uses a Merkle-Patricia tree where
hashing is a frequent operation. The proposal consid-
ers Blake2 as the preferred choice for a hash function
to replace the currently used Keccak-256. It actually
mentions Blake3 as an even better potential candidate
in terms of performance, but reverts to Blake2 due
to lack of Blake3 Go implementations at the time of
the proposal. A precompiled contract is nothing more
than an implementation of a function integrated na-
tively in the language of the Ethereum node, i.e., Go
in the case of a Geth based node. Therefore, inte-
grating a complete Blake2 implementation or adding
Blake3 as precompiled contracts would permit the use
of the functions also in the various blockchain node
operations such as EIP-3102.
The main topic of our paper is, however, the use
of hashing in smart contracts, where the integration of
functions such as the Blake family can have an impact
both in generic programming and in established pat-
terns that require efficient hashing. For instance, we
can refer to the commit-reveal pattern, used to prevent
transaction order dependence attacks as referenced in
the Smart Contract Weakness (SWC) registry (SWC,
2020). An attacker that is able to monitor transac-
tions to a smart contract, can issue transactions of
its own, leveraging any advantage (e.g., higher pay-
ments, ownership of mining nodes) in attempt to over-
come the other transactions observed. A typical ex-
Towards Efficient Hashing in Ethereum Smart Contracts
661