MASARYK
U N I V E R S I T Y
FACULTY OF INFORMATICS
Ethereum: encryption and
deanonymization
Master's Thesis
ANDREJ HULINA
Brno, Fall 2022
MASARYK
U N I V E R S I T Y
FACULTY OF INFORMATICS
Ethereum: encryption and
deanonymization
Master's Thesis
ANDREJ HULINA
Advisor: RNDr. Martin Stehlik, Ph.D.
Brno, Fall 2022
Declaration
Hereby I declare that this paper is m y original authorial work, which
I have worked out o n m y o w n . A l l sources, references, and literature
used or excerpted during elaboration of this work are properly cited
and listed i n complete reference to the due source.
Andrej H u l i n a
Advisor: R N D r . Martin Stehlík, P h . D .
iii
Acknowledgements
I w o u l d like to thank m y advisor R N D r . M a r t i n Stehlík, Ph.D., for
his help, guidance, suggestions, and patience he p r o v i d e d me w i t h
during the preparation of this thesis. I w o u l d also like to express my
gratitude to m y close ones for supporting me throughout the process
of writing this thesis. Also, I am very fond of C E S N E T - MetaCentrum
for p r o v i d i n g enough computing power and virtual space and thus
helped me complete this work.
iv
Abstract
Ethereum is the largest public blockchain by usage. It applies an
account-based model, which is inferior to Bitcoin's unspent transaction
output model from a privacy perspective. A common misconception
among Ethereum users is that it guarantees p r i v a c y but the reality
is different. Every transaction is recorded on a public ledger and reveals
information about one's identity. This thesis analyzes the privacy
of Ethereum and describes several deanonymization methods from
recent years. We also proposed some additional deanonymization
techniques that can be used to reveal the user's identity or reduce
its anonymity set. The accuracy of the proposed deanonymization
attacks has been tested and evaluated on the Goerli testnet.
Keywords
Etheruem, blockchain, anonymity, encryption, deanonymization, privacy,
Metamask, Geth, Goerli
v
Contents
Introduction 2
1 Ethereum overview 3
1.1 Ethereum world state 3
1.2 Accounts 4
1.2.1 Externally owned accounts 4
1.2.2 Smart contracts 5
1.2.3 Account state 5
1.3 Transactions 6
1.3.1 Transaction fee 6
1.3.2 Transaction fields 7
1.3.3 Transaction sending 7
1.4 Blocks 7
1.4.1 Blockchain 9
1.4.2 Block explorers 9
1.5 Consensus mechanisms 9
1.5.1 Proof of work 10
1.5.2 Proof of stake 10
1.5.3 The Merge 11
1.6 Nodes 11
1.6.1 Full nodes 12
1.6.2 Archive nodes 12
1.6.3 Light nodes 12
1.7 Clients 13
1.7.1 Execution clients 13
1.7.2 Consensus clients 14
1.8 Wallets 14
2 Ethereum peer-to-peer network 15
2.1 Nodes 17
2.1.1 Multiaddr 18
2.1.2 Enode 18
2.1.3 Ethereum N o d e Record 19
2.2 Node Discovery Protocol v4 19
2.2.1 Ethereum distributed hash table 20
v i
2.2.2 Protocol messages 20
2.3 Node Discovery Protocol v5 21
2.3.1 Protocol messages 21
2.3.2 Protocol handshake 22
2.4 The R L P x Transport Protocol 24
2.4.1 Initial handshake 24
2.4.2 Elliptic Curve Integrated Encryption Scheme . . 25
2.4.3 Protocol messages 29
2.4.4 Capability messaging 30
2.5 Ethereum Wire Protocol 30
2.5.1 Status message 31
2.5.2 Transaction exchange 31
2.6 RLPx-based application-level protocols 32
2.6.1 Light Ethereum Subprotocol 32
2.6.2 Parity Light Protocol 33
2.6.3 Ethereum Witness Protocol 33
3 Anonymity in Etheruem 34
3.1 Ethereum Name Service 34
3.2 Deanonymization 35
3.3 Deanonymizing Ethereum users based on network monitoring
36
3.4 Address clustering 38
3.4.1 User habits 39
3.4.2 Deposit address reuse 41
3.4.3 A i r d r o p multi-participation 42
3.4.4 Self authorization 42
3.4.5 Smart contract code attribution 43
3.5 Privacy enhancement 44
3.6 Tornado Cash heuristics 45
3.6.1 Heuristics evaluation 47
3.7 Priority fee heuristic 49
4 Metamask 54
4.1 Functionality 54
4.2 Security and privacy 55
4.2.1 Passwords 56
4.3 Communication eavesdropping 57
vii
4.3.1 Transaction sending 57
4.3.2 Other communications 59
4.4 Possible attack 61
4.4.1 Packet analysis of eth_sendRawTransaction . . 62
4.4.2 Packet analysis of eth_getTransactionReceipt 63
4.4.3 Transaction time interval 65
4.4.4 Attack implementation 66
5 Go Ethereum 68
5.1 Dissecting Node Discovery v4 68
5.2 Light node 71
5.2.1 Packet analysis of eth_sendTransaction . . . . 73
5.2.2 Packet analysis of eth_getTransaction/Receipt 75
5.2.3 Transaction time interval 77
5.2.4 Attack implementation 79
5.2.5 Light server 80
5.3 Full node 81
6 Conclusion 83
Bibliography 85
A Attachments 93
A . l Priority fee script 93
A.2 Metamask script 93
A.3 Light node script 93
viii
List of Tables
3.1 Percentage rate of the deanonymized withdraws using
the corresponding heuristics i n each mixer contract [51] . 47
3.2 Percentage rate of the deanonymized withdraws using
the corresponding heuristics i n each mixer contract [74] . 48
ix
List of Figures
1.1 Diagram of the state transition 4
1.2 Chain of states 8
2.1 Ethereum network stack before the Merge [26] 16
2.2 Current Ethereum network stack [26] 17
2.3 Protocol handshake i n Ethereum Node Discovery v5 . . . 23
2.4 Two-phase handshake i n R L P x [27] 25
2.5 ECIES Encryption [38] 27
2.6 ECIES Decryption [38] 28
3.1 Received transaction 37
3.2 Collected transactions w i t h the same priority fee 50
3.3 Several transactions from the same accounts 50
3.4 Transactions from many accounts i n a short time 51
3.5 Transactions collected from the Etheruem mainnet . . . . 52
4.1 Metamask does not collect any data [77] 55
4.2 Start of the communication w i t h a node 61
4.3 Server name from the packet 61
4.4 Packet structure with the eth_sendRawTransact i o n request 62
4.5 Packet structure w i t h the eth_getTransactionReceipt
request 63
4.6 Decrypted part of the packet 64
4.7 Transaction shown i n Etherscan 65
4.8 Intersection of two time intervals 66
4.9 Example script results for Metamask wallet 67
5.1 Node discovery communication w i t h a bootnode 68
5.2 Ping 69
5.3 Pong 69
5.4 Neighbours 70
5.5 Transaction sent to three light servers 71
5.6 Transaction sent to our light server 72
5.7 Transaction received from our light node 72
5.8 Transaction status request sent to three light servers . . . 72
5.9 A l l packets of length 258 74
5.10 T C P stream w i t h eth_sendTransaction 75
5.11 Transaction sent to three light servers i n Wireshark . . . . 76
x
5.12 T C P stream w i t h eth_getTransact i o n 77
5.13 Communication w i t h the servers i n Wireshark 78
5.14 Example of the results of the sript for light nodes 80
5.15 Transaction sent from the full node 81
5.16 Transaction forwarding from the full node 81
xi
Introduction
Since Satoshi Nakamoto introduced the first decentralized cryptocurrency
called Bitcoin i n 2009 [1], many other blockchain-based cryptocurrencies
have been created. Currently, the second-largest cryptocurrency
by market capitalization, Ethereum, was released i n 2015
by Vitalik Buterin [2]. One of the essential features of any cryptocurrency
is anonymity. The initial white paper introducing blockchain
technology through Bitcoin promoted the concept of privacy and
anonymity. The idea was based on the fact that only two parties are
involved since cryptocurrency allows direct peer-to-peer transactions
over the Internet. However, as was later proven, Bitcoin does not provide
anonymity but only pseudonymity. The same is true for Ethereum.
The pseudonymity is broken if the account representing the user can
be linked to an actual entity, such as an IP address. There have been
several deanonymization attacks proposed on Bitcoin i n recent years.
However, only a few papers focused on deanonymization in Ethereum
[3].
The thesis aims to analyze Ethereum, focusing on its privacy aspects
and ways of possible deanonymization. The first chapter introduces
Ethereum and its most crucial parts, like accounts, transactions,
nodes, or clients. The second chapter focus on the Ethereum network.
We describe all the protocols i n the network stack. Every protocol is
described in detail, focusing on the data it transfers and the encryption
it uses.
In the third chapter, we describe deanonymization technics proposed
by other researchers. The attacks are divided based on the data
it uses for deanonymization. The data can be collected by a network
eavesdropping or directly from the transparent Ethereum Blockchain.
A t the end of the chapter, we propose a heuristic for linking the addresses
of one user. The heuristic is based on the priority fee that is
included i n the transactions.
The fourth chapter analyzes the most widely used Ethereum wallet,
Metamask, namely its security and communication w i t h the blockchain.
We set up mitmproxy to see all wallet's H T T P communication i n the
decrypted form. After the communication analysis, we proposed a
1
INTRODUCTION
deanonymization attack an eavesdropper can perform. The success of
this attack was evaluated w i t h a python script using pyshark.
Chapter five focuses on Geth, currently the most used client i m plementation.
We ran the client and analyzed its communication i n
Wireshark. We could see all the unencrypted communication of Node
Discovery Protocol v4. A l l other network communication of the node
is encrypted. Therefore we modified its code to see the network traffic
in decrypted form. We analyzed h o w the node communicates w i t h
other nodes. We focused on transaction sending, which is crucial information
for deanonymization. We proposed a deanonymization attack
on light nodes based on the information f r o m the analysis. The success
of this attack was evaluated w i t h a python script. Since a similar
attack cannot be used on full nodes, we proposed an attack specific to
this node mode. Unfortunately, the attack requires many resources.
Therefore, we could not perform and evaluate it.
2
1 Ethereum overview
In the world of cryptocurrencies, Ethereum is currently to second most
valuable one right after Bitcoin [1]. Both can be defined as decentralized,
open-source global peer-to-peer (P2P) software networks powered
by blockchain technology. However, unlike the Bitcoin blockchain,
w h i c h is used mainly for cryptocurrency, Ethereum is m u c h more
complex. The Ethereum blockchain has a built-in Turing-complete
programming language. It allows users to create smart contracts and
decentralized applications. A Turing-complete canonical computer
called the Ethereum Virtual Machine (EVM) serves as a runtime environment
for smart contracts. EVM is powered by its native cryptocurrency,
Ether (ETH), w h i c h is used to pay for certain activities on the
Ethereum network. Ethereum has a metric system of denominations
used as units of Ether. The smallest denomination is Wei. A n Ether is
defined as 1 0 - 1 8
Wei For the user or an application to interact with the
Ethereum blockchain, it must be connected to an Ethereum node. The
nodes form the P2P network, where nodes send and receive data from
other directly connected peers. Each node i n the Ethereum network
maintains an up-to-date Ethereum w o r l d state that all nodes have
agreed upon [2,4]. We w i l l describe all the crucial parts of Ethereum
in this chapter.
1.1 Ethereum world state
According to the Ethereum yellow paper [4], Ethereum is a transactionbased
state machine. The Ethereum world state consists of a key/value
m a p p i n g of account addresses and account states. It begins w i t h a
so-called genesis state, w h i c h can be seen as a blank state before anything
happens on the Ethereum network. A new transaction between
accounts changes the states of these accounts. W h e n accounts' states
transition, the global state also does. A t the most superficial level can
be the state's transition seen as a function that takes the current state
and transaction to compute the next state. A basic state transition
scheme can be seen i n Figure 1.1. A copy of the current global state,
the so-called final state, is kept i n every node i n the Ethereum P2P
network [4].
3
l . E T H E R E U M OVERVIEW
Transaction
World state (t+i)
Figure 1.1: Diagram of the state transition
1.2 Accounts
A s mentioned i n Section 1.1, Ethereum world state consists of accounts
and account states. A n Ethereum account can be seen as a n entity
storing Ether. Ethereum uses an account-based model, which is similar
to bank accounts. This model represents assets, i n this case, Ether, as
balances within accounts. Users w h o o w n an account can deposit Ether
into the account or transfer it to other accounts. There are two types of
accounts i n Ethereum, Externally owned accounts EOAs controlled by
a user and Contracts accounts, also k n o w n as Smart Contracts [2, 5].
1.2.1 Externally owned accounts
Externally owned accounts are simple accounts without any associated
code or data storage. They are controlled by users via a cryptographic
key-pair (a private and a public key). The former enables the user to
prove the account ownership and acts as a password, giving the user
control over the entire account. It is randomly generated and used for
signing transactions. The latter is derivated from the private key using
elliptic curve multiplication. Ethereum uses the Secp256kl elliptic
curve [6]. Such an account is free and can be created by anyone [2,4,
5].
Each EOA is represented w i t h an address i n the Ethereum network.
The address comprises the prefix "Ox," concatenated w i t h the last 20
bytes of the Keccak256 [7] hash of the Secp256kl public key. This
address is an identifier that is used to identify the account [2, 5].
A n EOA can send messages by creating and signing a transaction
using its private key. A transaction between two EOAs can only be
a transfer of Ether. A transaction f r o m a n EOA to a contract account
activates its code, allowing it to perform the actions of the contract [5].
4
i . E T H E R E U M OVERVIEW
1.2.2 Smart contracts
The smart contract is a computer program running o n the Ethereum
blockchain. Every smart contract is identified by its account's address,
which starts w i t h the "Ox" prefix. The smart contract is not controlled
by any user but b y its code. It cannot be deleted b y default, and its
interactions are irreversible. It represents one of the most successful
applications of blockchain technology that makes Ethereum flexible
for different applications [2,4, 5, 8].
The contract code is r u n by the Ethereum virtual machine (EVM),
w h i c h runs o n every node o n the Ethereum network. EVM is the computation
engine of the Ethereum network. It handles smart contracts
deployment and execution, where each smart contract is executed line
by line. The transactions sent from other accounts to the contract account
can trigger the contract's code. Contract accounts cannot initiate
new transactions and only trigger transactions i n response to other
transactions they have received. Therefore, only the transactions from
externally controlled accounts initiate any action o n the Ethereum
blockchain [5, 9].
1.2.3 Account state
Each account has not only a balance but also other variables that make
up its state. The account state includes details of an account during
some specified world state. A n Ethereum account state consists of four
variables:
• The nonce. A counter of the transactions sent from the account.
It ensures that transactions are only processed once. In a contract
account, this number represents the number of contracts created
by the account.
• The account's current Ether balance.
• H a s h of the account's contract code. This field is the hash of an
empty string for EOAs.
• The storage of the contract account. This field is empty for the
EOA [2,5].
5
i . E T H E R E U M OVERVIEW
1.3 Transactions
A s we have already noted, Ethereum is a transaction-based state machine.
The transaction is the primary method for accounts to interact
w i t h each other. They are cryptographically signed instructions emitted
only from EOAs. The transactions between different accounts move
the Ethereum state from one state to the next. Each transaction has one
sender and also only one recipient. Every transaction is represented
by its hash. There are three types of transactions:
• Transfer of the Ether - an EOA is able to transfer Ether to another
EOA or a contract account.
• Contract creation - an EOA can create a Smart contract w i t h an
Ether transfer. The recipient address i n the such transfer is set
to null. This transaction contains the code of the new contract
functionality, and its execution creates a bytecode of this contract.
• Contract call - an EOA can send this transaction to the contract
account address to execute the smart contract code [2,4,10].
1.3.1 Transaction fee
Each transaction requires a fee to be p a i d for the computation. The
fee is paid i n the form of gas. Gas is the unit used to measure the fees
required for a particular computation. The fees help keep the Ethereum
network secure. It prevents b a d actors from s p a m m i n g the network
by requiring a fee for every computation executed o n the network.
The transaction fee is calculated w i t h the formula, fee = gaslimit *
(basefee + priority fee). The gas limit is the m a x i m u m amount of gas
for the transaction. The regular transaction's gas limit is 21000. The
base fee is a n amount of Ether that every transaction has to pay. It is
the same for every transaction i n the block. The blockchain sets it for
every block according to the busyness of the blocks. W h e n the block is
mined, this base fee is burned. A priority fee is a value the user sets as
a tip to the validator. The sum of the base fee and priority fee makes a
gas price that is paid for each amount of gas [2,4,11].
6
i . E T H E R E U M OVERVIEW
1.3.2 Transaction fields
Each transaction is specified by several fields:
• Nonce - the number of transactions sent from the sender account.
• Gas price - the number of Ether(in Wei) to be paid for a unit of
gas.
• M a x priority fee per gas - the m a x i m u m amount of Ether (in Wei)
to be included as a tip for the validator.
• Gas limit - the m a x i m u m amount of gas used for this transaction.
• Recipient - the address of the recipient.
• Value - the amount of ETH to transfer from sender to recipient.
• Data - this field includes optional arbitrary data.
• v, r, s - three components of an ECDSA digital signature of the
sender, from w h i c h the public key can be derived [10].
1.3.3 Transaction sending
There are three ways a user can create a transaction, full node, light
node, and wallet. We w i l l discuss all three options i n Section 1.6 respectively
1.8. W h e n a new transaction is created, it is not automatically
confirmed and sent to the recipient. Instead, a node sends it to its
peers, w h o w i l l pass it to further peers, so it is propagated to every
node i n the Ethereum network. A t this time, it is a pending transaction
and is queued i n the transaction pool at each node. A transaction pool
lists all submitted transactions not yet added to the block, where they
wait to be validated. The block creators include transactions into a
block based o n a transaction fee. The higher the fee, the higher the
probability of inclusion. A l l the included transactions are executed at
once w h e n the block is validated, leading to the world state's transition.
The world state transits with every new block. A s shown i n Figure 1.2,
Ethereum can be seen as a chain of states from this viewpoint [10].
1.4 Blocks
Block is an essential concept i n Ethereum that can be seen as a container
for transactions. The size of each block is represented b y the
7
l . E T H E R E U M OVERVIEW
Transaction (tl)
Transaction {]2)
Transaction (D)
Transaction {14)
Transaction {t5)
Transaction {t6)
World state (s) World state (s+i) World state (s+2)
Figure 1.2: C h a i n of states
maximum amount of gas i n the block, which is currently eight million.
It restricts the included transactions, where each has its gas limit. The
total amount of gas spent by all transactions i n the block must be less
than the block gas limit. Each block has a parent, and it stores the
hash of the parent block i n its header. Only the first block, the Genesis
block, does not have a parent. The blocks are chained together to form
a blockchain [2,4,12].
The block w i t h the transactions must be created i n order to be
added to the blockchain. The creation process depends on the consensus
mechanism of the blockchain. Ethereum uses proof of stake;
however, until the September 2022 consensus called proof of work was
used. We w i l l discuss both consensus mechanisms i n Section 1.5. The
consensus mechanism also refers to securing the network by creating,
verifying, publishing, and propagating blocks i n the blockchain. The
created block is propagated to the rest of the network. A l l other nodes
add this block at the end of their blockchain, and creating a new block
starts over again. In Ethereum, a block consists of the following parts:
• The block header - the header consists of 15 different fields, like
the parent hash, nonce, number, difficulty, gas limit, and others.
• Set of transactions - all the transactions included i n the block.
• O m m e r block headers - a set of block headers for the current
block's ommers 1
[12].
1. A n ommer block is a block created and submitted to the ledger at roughly the
same time as another block. However, only one block can enter the ledger [13].
8
i . E T H E R E U M OVERVIEW
1.4.1 Blockchain
A blockchain is a distributed public ledger that records all transactions
or digital events between participating parties i n blocks. Blocks are
cryptographically linked. Each block contains a hash pointer of the
previous block, thus forming a chain of chronologically ordered blocks,
a blockchain. It ensures that the transactions are tamper-resistant. The
hash of every block is counted from the data included i n it, including
the previous block's hash. A n y data modification on block Bz w o u l d
change its hash, w h i c h is also included i n the next block Bj+i. Therefore,
the hash of this a n d all the following blocks w i l l also change.
The publicly accessible and traceable blockchain is replicated across
multiple nodes i n a P2P network. Therefore such a change i n one block
w o u l d create an easily detectable inconsistency i n all replicas [2,12,
14].
1.4.2 Block explorers
Block explorers are the portal to Ethereum's data. They can be used to
see real-time data on blocks, transactions, accounts, and other on-chain
activity. Ethereum is transparent by design, so everything is verifiable.
Block explorers provide an interface for getting blockchain data for
both the m a i n Ethereum network and the testnets. Such data are accounts
w i t h their balances and complete transactions history, details
of every transaction and block, or other network statistics and information.
There are several block explorers, like Etherscan, Etherchain,
Ethplorer, or Blockchair [15].
1.5 Consensus mechanisms
In distributed systems, a consensus mechanism is a method by which
the network agrees o n a single source of truth. Unlike centralized
systems, where a single controlling entity decides the source of truth,
distributed systems rely o n many autonomous parties that w o r k together
to maintain a single network. These disparate nodes must have
a computing mechanism to agree on the most recent and accurate data
record. A l l these distributed nodes must adopt the exact cryptographic
mechanism to achieve consensus to achieve the goal. In Ethereum is
9
i . E T H E R E U M OVERVIEW
such a consensus mechanism used to reach an agreement between the
nodes on the creator of the next block and Ethereum's current state.
Regarding blockchain, reaching consensus means that at least 51% of
the nodes on the network agree on the next world state [2,4,16,17].
1.5.1 Proof of work
The proof of work (PoW) consensus mechanism is currently the most
widely used and arguably the best understood. Ethereum's P o W algorithm
was called Ethash. It was used i n Ethereum until the Merge
in September 2022. The essential components of P o W are miners and
energy. Miners are individuals or entities responsible for creating new
blocks b y expending electricity i n the f o r m of computing power to
solve complex mathematical problems. Every miner goes through the
same proof of work process. A miner provides proof that it has worked
on computing the final answer that could satisfy as a solution to the
problem. The miner w h o solves the problem first w i n s the right to
add a block of transactions to the blockchain. The cost of computing
power costs money i n the form of electricity i n addition to the initial
hardware costs of setting u p a functional node. However, the block
rewards make the miner costs worthwhile. W h e n a miner successfully
mines a block, he receives a block reward i n the f o r m of ETH. A new
block is mined every 12 to 14 seconds. This period is evaluated after
each block by the mining difficulty [17,18].
1.5.2 Proof of stake
While in PoW, miners expend energy to mine blocks. In proof of stake
(PoS), validators undertake to confirm (validate) the existence of
blocks. Validators are participants i n the network w h o operate nodes
(called validator nodes) to propose and verify blocks o n the PoS
blockchain. They do so by stacking crypto on the network and making
themselves available to be randomly selected to propose block. Other
validators then "confirm" that they have seen the block. W h e n enough
attestations are collected for a proposed block, the block is added to
the blockchain. Validators receive rewards for successfully designing
blocks (just like in PoW) as well as for producing confirmations of the
blocks they have seen [17,19].
10
i . E T H E R E U M OVERVIEW
Crypto economic incentives for PoS are designed to create more
compelling rewards for good behavior and harsher penalties for harmful
behavior. The primary crypto-economic motivation lies i n requiring
validators to stake their cryptocurrencies. Instead of considering the
secondary cost of electricity to operate a P o W node. Validators i n PoS
chains are forced to deposit significant amounts of money into the
network directly. Ethereum requires validators to stake 32 ETH to r u n
a validator node [17,19].
Each time a block is set to be proposed, at least 4 to 64 r a n d o m
committees of 128 validator nodes are selected from the entire pool of
validators to validate the block. The chance an attacker controlling 1 /3
of the validators i n the network w o u l d control 2/3 of the validators i n
the committee is less than 1 i n a trillion [17,19].
1.5.3 The Merge
In December 2020, the Beacon Chain was launched, running parallel
to the Ethereum mainnet. It introduced PoS to the Ethereum ecosystem.
In September 2022, Ethereum mainnet and Beacon Chain merged.
The Merge is a technical upgrade that shifts Ethereum's existing PoW
consensus mechanism to a PoS model. Simply put, it integrates the
two existing independent chains i n the Ethereum ecosystem: the execution
layer and the consensus layer (Beacon Chain). W i t h this move,
Ethereum aims to significantly reduce its carbon footprint and lay the
groundwork for future scalability upgrades [20, 21].
1.6 Nodes
Ethereum is a distributed network of computers (known as nodes). A
node is a computer running the Ethereum client software. The client
is an implementation of Ethereum. Post-Merge Ethereum consists of
two parts: the execution layer and the consensus layer. Both layers are
run by different client software and w i l l be described i n Section 1.7. A
user must run both clients on his computer to turn it into an Ethereum
node [2, 22].
Each node stores a w o r l d state. Nodes communicate w i t h each
other to disseminate information about the world state and new state
changes. A n y user can request code execution by broadcasting a trans-
11
i . E T H E R E U M OVERVIEW
action f r o m the node. The Ethereum network is an aggregate of all
Ethereum nodes and their communications. There are three types of
nodes: full, archive, and light [2, 22].
1.6.1 Full nodes
Full nodes are necessary for r u n n i n g a n efficient blockchain. They
store a copy of the whole blockchain i n its current state. They also
participate i n block validation, state verification, and blockchain data
propagation. A l l states can be derived from the full node. Users can
turn a full node into a validator node b y staking 32 ETH. In order to
serve data to light nodes, a full node can add Light Ethereum Protocol
(les) to its capabilities and act as a light server. The Light Ethereum
Protocol is described i n 2.6.1 B y r u n n i n g a full node, have the user
direct access to the blockchain. W h e n a new transaction is initiated
through a full node, the node broadcasts the transaction straight to
the whole network [22].
1.6.2 Archive nodes
A n archive node is essentially a full node. However, it provides an
extra layer of storage and backup for the user's data by storing all the
blockchain data. It builds an archive of historical states [22].
1.6.3 Light nodes
Light nodes d o not d o w n l o a d w h o l e blocks but only block headers.
The block header contains summary information about the content of
the block. A n y other blockchain information has to be requested from
a full node acting as a light server. They enable users to participate i n
the Ethereum network without the powerful hardware required to r u n
full nodes, as they can eventually run on mobile phones or embedded
devices. The light nodes d o not participate i n consensus, but they
can access the Ethereum blockchain w i t h the same functionality as a
full node. It is also possible to send transactions from the light node.
Nevertheless, light clients are not connected directly to the Ethereum
network but to a network of light servers that connect to the Ethereum
network. A transaction submitted by a light client is received first by a
light server that then propagates it to peers o n the light client's behalf.
12
i . E T H E R E U M OVERVIEW
This reliance on honest light servers is one of the trust compromises
w i t h running a light node instead of a full node [22].
1.7 Clients
The client is an implementation of Ethereum that verifies data against
the protocol rules and keeps the network secure. A s mentioned i n
Section 1.6, Ethereum has two parts of the client software, execution
and consensus. The clients' functionality differs. Each is responsible
for different tasks, and each maintains independent networking stacks
and protocols, connecting to peers. The user needs to run both clients
in order to r u n a node. Both execution and consensus clients r u n
in parallel. They must be connected to communicate. The c o m m u nication
between the two clients can be achieved using a local R P C
connection [2, 22].
Both execution clients and consensus clients exist i n a variety of
programming languages developed by different teams. Multiple client
implementations can strengthen the network by reducing its dependency
o n a single codebase. The ideal goal is to achieve diversity
without any client dominating the network, thus eliminating a possible
single point of failure. Language diversity also invites a broader
developer community and allows them to create integrations i n their
preferred language. A l l the implementations are built to a standard
specification that ensures all the clients have the same functionality
and provide an equivalent user experience [23].
1.7.1 Execution clients
Execution clients are tasked w i t h processing and broadcasting transactions
and managing Ethereum's state. They r u n the computations
for each transaction using the EVM to ensure the protocol rules are
followed. The most used implementation of execution clients is G o
Ethereum, G e t h for short. G e t h is written i n G o and is fully open
source. According to ethernodes.org[24], more than 75% of nodes are
currently running Geth. The distribution of clients across nodes is not
equal enough to realize this network fortification to its full potential.
The other implementations like Erigon, Besu, or Nethermind do not
get more than 8% [22, 23].
13
i . E T H E R E U M OVERVIEW
1.7.2 Consensus clients
The consensus clients implement the proof of stake consensus algorithm.
It enables the network to achieve agreement based on validated
data from the execution client. Consensus clients do not participate i n
validating/broadcasting transactions or executing state transitions, as
execution clients do. The consensus clients participate i n a separate
P2P network w i t h different specifications. The usage of consensus
clients is more diverse than that of execution clients. The most commonly
used client o n the consensus layer, P r y s m , is used b y 42% of
nodes, which is not as dominant as Geth. The second one, Lighthouse,
is used b y 37% of nodes. Teku, currently the third client i n this list,
is used b y 18% of the nodes. N o other implementations are used b y
more than 4% of nodes [22, 23].
1.8 Wallets
A n Ethereum wallet is a software or hardware that allows users to manage
their accounts on the Ethereum network. The wallet can send transactions
and keep track of accounts balance with as many Ethereum accounts
as necessary. A wallet is only a tool for managing the Ethereum
account so that the wallet providers can be swapped at any time. Each
account i n the Ethereum wallet is controlled through a private key
that allows the user to move the funds. These private keys are only
supposed to be k n o w n to the wallet's creator, as anyone w h o knows
them can access their funds. There are several types of Ethereum wallets,
some held o n desktop or mobile devices and some held offline
through a piece of paper, titanium, or hardware. A transaction created
from the wallet is broadcasted to the network v i a a trusted remote
node. A wallet is usually linked to a trusted third-party node, w h i c h
the wallet provider defines. However, some wallets allow users to connect
the wallet to any other node. The wallet forwards the transaction
to the connected node, w h i c h then broadcasts the transaction to the
network. This connected node can associate the transaction initiator
IP w i t h the account. If a third-party node is used, it can expose the
user's identity. A l t h o u g h it is possible to hide the IP using Tor, the
anonymity can still be compromised to some extent [25].
14
2 Ethereum peer-to-peer network
This chapter describes the Ethereum P 2 P as it is an essential cornerstone
of Ethereum. It supports Ethereum i n achieving decentralization
and efficient circulation of information. P 2 P is a type of network i n
which interconnected peers, also called nodes, share the data without
using a centralized administrative system. The nodes forming the
network are equally privileged [2, 26].
Before the Merge, the Ethereum node ran only one client w i t h one
P2P network. The P2P network was formed by an Ethereum Discovery
Protocol a n d a network stack called DEVp2p. DEVp2p included R L P x
protocol [27], Ethereum Wire Protocol [28], a n d several subprotocols
[27]. The scheme of DEVp2p is illustrated i n Figure 2.1.
A s we already described, Ethereum currently has two parts of the
client software, execution, and consensus. Every node o n the network
has to keep running both clients. Execution clients send transactions
over the execution layer peer-to-peer network. W h e n a validator is
selected to propose a block, transactions f r o m the execution client's
transaction p o o l are passed to the consensus client v i a a local R P C
connection. These transactions are included i n the block. The consensus
client w i l l then send the block across their P 2 P network. It
requires two separate P2P networks: one connecting execution clients
for transaction-related data exchange a n d one connecting consensus
clients for block-related data exchange. Each P2P network has its o w n
distinct stack. We w i l l mainly focus o n the execution P2P network [26].
The Ethereum execution P2P network is similar to the Ethereum
P2P network before the Merge. Just minor changes were made to all
protocols i n DEVp2p. U D P - b a s e d N o d e Discovery Protocol does the
node discovery process for finding other Ethereum nodes i n a P2P
network. The former unencrypted Node Discovery version 4 (discv4)
should be already replaced by a more sophisticated version 5 (discv5).
However, as discussed i n Section 5.1, d i s c v 4 is still used [26].
After the discovery process, node interactions are formed by a network
stack called DEVp2p. DEVp2p consists of an encrypted TCP-based
R L P x Transport Protocol for communication among the Ethereum
nodes. Based o n the R L P x , Ethereum utilizes different applicationlevel
protocols for different clients a n d conditions. Ethereum Wire
15
2. E T H E R E U M PEER-TO-PEER NETWORK
New Node Node
o
Node D i s c o v e r y P r o t o c o l v4
•! Ping
Pong
FindNode
Neighbors
DEVp2p
RLPx
EncHandshake
EncHandshake
Hello/Disconnect
Hello/Disconnect
ETH
Status
GetBlockHeaders
BlockHeaders
Figure 2.1: Ethereum network stack before the Merge [26]
16
2. E T H E R E U M PEER-TO-PEER NETWORK
Protocol (eth), which facilitates the exchange of Ethereum blockchain
information between peers, is the most w i d e l y used. A l l the components
of DEVp2p are also described i n this chapter. Similar to the
execution P2P network, the consensus P2P network uses d i s c v 5 over
U D P to discover nodes. The libP2P stack, w h i c h can be subdivided
into the Gossip and Req/Resp domains, handles all post-discovery
communications on T C P [26]. The network stack of both layers is
shown i n Figure 2.2.
Ethereum Node
Execution Client
Execution P2P network
Node Discovery v4/v5
DEVp2p
RPC Consensus Client
Consensus P2P network
Node Discovery v5
libP2P
Gossip
Request - Response
Figure 2.2: Current Ethereum network stack [26]
2.1 Nodes
We have already discussed nodes i n Section 1.6. However, this section
w i l l discuss nodes as a part of the network and h o w they are
represented.
As already mentioned, the Ethereum P2P network is formed by the
nodes connected without any centralized system. In order to communicate,
nodes have to identify themselves with some basic information,
like the IP address, port number, or node ID. The node ID is used as a
global identifier. It is a 64-byte public key derivated from the private
key using an elliptic curve (Secp256kl). However, i n the Ethereum
DHT, nodes are identified by the 32-byte Keccak256 hash of the public
key. Such information is kept i n one of the three standardized formats
17
2. E T H E R E U M PEER-TO-PEER NETWORK
so that any node can interpret this information: multiaddr, enode,
or Ethereum N o d e Record ( E N R ) . E N R is the current standard for
Ethereum network addresses [29].
2.1.1 Multiaddr
Multiaddr (short for multi-addresses) was the original Ethereum node
address format. It is a universal format designed for P 2 P networks.
Addresses are represented with the human-readable representation as
key-value pairs w i t h keys and values separated w i t h a forward slash.
For an Ethereum node, the multiaddr contains the Keccak256 hash of
the node I D i n base58 encoded format [29, 30].
A n example of a multiaddr that describes a node w i t h IP address
192.168.86.67, T C P port 13000:
/ip4/192.168.86.67/tcp/13000/p2p/7y9Qv7mG2h6f
nzcDkeqVsEvW2rU9PdybSZ8yldCrB9pe
2.1.2 Enode
A n enode is a way to identify an Ethereum node using a U R L address
format. This format is specifically used i n the Ethereum protocol landscape.
The data structure is prefixed b y enode://. The hexadecimal
node public key is encoded i n the username portion of the U R L , separated
from the host using a n @ sign. The hostname can only be a n IP
address. D N S names are not allowed. The port i n the hostname section
is the T C P listening port. If the T C P and U D P (discovery) ports differ,
the U D P port is specified as a query parameter "discport." The enode
format is typically used i n the discovery process a n d for specifying
bootstrap nodes. Like the multiaddr format's node ID, the P2P node's
public key is used to authenticate the peer [29, 30].
A n example of a enode that describes a node w i t h the same p a rameters
as multiaddr described above:
enode: / / H 5 0 l b f 6f 2la04763aedb7b408cl4b5l4de6l
C29eb9bd902a0884b2f9a2653d5b49fbf0a5019aa707e
0faclefca56c2a4el4293c579eaa3f353cdbafb22d253
b(3l92.168.86.67:13000
18
2. E T H E R E U M PEER-TO-PEER NETWORK
2.1.3 Ethereum Node Record
Ethereum N o d e Record ( E N R ) is a standardized format for network
addresses o n Ethereum, w h i c h supersede multiaddr and enode. It
allows greater informational exchange between nodes. A node record
usually contains the network endpoints of a node, like a node's IP addresses
and ports. It also holds information about the node's purpose
on the network. The E N R contains three essential elements:
• cryptographic signature of record contents,
• sequence number that increases w h e n the record changes,
• a n arbitrary list of key/value pairs.
The signature serves for the verification of the authenticity of the
record. The record's sequence number allows peers to detect outdated
cached records. The keys can be any byte sequence. There are several
key names w i t h predefined meanings. The most important are
those that keep the information about IP addresses and ports. The
data structure is prefixed by E N R : followed by a base64 encoded R L P
list [29,30,31].
A n example of an E N R that describes a node w i t h the same parameters
as enode and multiaddr described above:
enr:-LK4QMer7ejH4SWXlSIdM6gOBUD6WH86M95-6ZQ04
K0rsAWaDaswyYp9hFmzRpnGVypSlHL_QB2VzNT8ATRckI
fnmosBh2F0dG5ldHOIAAAAAAAAAACEZXRoMpD9yjmwAAA
BIf gmlkgnY0gmlwhMCoVI<O:c2VjcDIlNmsx
oQMRUBv28hoEdjrtt7QIwUtRTeYcKeub2QKgiEsvmiZTl
YN0Y3CCMsiDdWRwgi7g
2.2 Node Discovery Protocol v4
N o d e discovery is the premise of all communication i n the P2P network.
This protocol aims to find other participants i n such a network
and exchange Ethereum N o d e Records between the nodes. The protocol
is implemented v i a U D P and based o n a routing algorithm,
Kademlia distributed hash table (DHT) [32]. Every participant in the
discovery protocol is expected to maintain its up-to-date E N R . The
19
2. E T H E R E U M PEER-TO-PEER NETWORK
unencrypted protocol version 4 (Discv4) is still used b y default i n
Geth, the most widely used execution client. However, Geth provides
the users a n option to use version 5 [33, 34].
2.2.1 Ethereum distributed hash table
Ethereum distributed hash table is based o n Kademlia. K a d e m l i a
is a UDP-based distributed hash table ( D H T ) for decentralized P2P
networks designed by David Mazieres and Petar Maymounkov in 2002.
It provides the infrastructure for an unspecified number of computers
to self-organize into a network and communicate w i t h each other
without needing a central server [32, 33].
Each node has its version of the routing table containing the information
required to connect to its closest peers. The closest peers are
not defined geographically but by logical distance. The table consists
of at most 255 rows, where each row contains a list w i t h at most k
peers. The N o d e Discovery Protocol uses k = 16, so every row is able
to keep information about 16 nodes. The nodes i n one row share a
logical distance. The logical distance between the two nodes is the
X O R operation of the Keccak256 hashes of the node IDs. Each r o w
(0 < i < 256) stores nodes w i t h the logical distance 21
to 21+1
from
itself. The node records i n the row are sorted b y the last seen time.
The most recently seen node is at the tail of the bucket [32, 33].
2.2.2 Protocol messages
Node Discovery Protocol v4 uses three pairs of messages:
Ping and Pong. W h e n node discovers a new node, its availability
must be checked before adding it to the corresponding r o w i n its
routing table. This pair of messages is used to verify such availability
of the nodes. A Pong is a response to the initiator's Ping. H a s h of the
initiator's Ping has to be included i n the Pong [33].
FindNode and Neighbors. FindNode requests information about
nodes close to the given target. The target is a 64-byte Secp256kl
public key. W h e n FindNode is received, the recipient should reply
with Neighbors containing the list of the closest 16 nodes to the target
found i n its local routing table. Neighbors response should only be
20
2. E T H E R E U M PEER-TO-PEER NETWORK
sent if the Ping-Pong endpoint proof procedure has verified the sender
of FindNode [33].
ENRRequest and ENRResponse. ENRRequest is a request for the most
up-to-date version of an E N R . Recipient replies with the ENRResponse
containing its current E N R and the hash of the request. The sender
of ENRRequest has to be verified, just like the FindNode sender, before
the response is sent [33].
2.3 Node Discovery Protocol v5
The purpose of the Node Discovery Protocol v5 (Discv5) is identical
to Discv4. Like its predecessor, Discv5 is based on the Kademlia D H T
and implemented via U D P Additionally, it provides communication
encryption and a pre-negotiating process of the application-level protocols.
This version of N o d e Discovery Protocol is already used by
default i n consensus clients. Geth users can switch to this version,
even though the default protocol is Disc4.
The protocol deals w i t h three different kinds of packets:
• O r d i n a r y message packet that carries an encrypted/authenticated
message.
• WHOAREYOU packet, w h i c h is sent w h e n the recipient of an ordinary
message packet cannot decrypt/authenticate the packet's
message.
• Handshake message packet, which establishes a new session and
carries handshake-related data i n addition to the encrypted/authenticated
message [34].
2.3.1 Protocol messages
The protocol messages can carried i n ordinary packets or i n Handshake
message packets. The messages are authenticated with A E S - G C M [34,
35].
Ping and Pong. The use of the messages is the same as i n Discv4.
However, i n this protocol, Pong does not include Ping's hash [34].
FindNode and Nodes. FindNode message queries for nodes at the
given logarithmic distances f r o m the recipient's node ID. W h e n distance
0 is requested, the result list should contain the recipient's cur-
21
2. E T H E R E U M PEER-TO-PEER NETWORK
rent record. The recipient should create the result list b y collecting
nodes from its local node table according to the requested distances.
The response is carried as a Nodes message. Multiple Nodes messages
may be sent as responses to a single request [34].
TalkReq and TalkResp. TalkReq sends an application-level request.
The purpose of this message is to pre-negotiating connections made
through another application-level protocol included i n the message.
The sender is querying for other nodes that use the included applicationlevel
protocol. The recipient responds w i t h TalkResp containing the
E N R of nodes w i t h the requested application-level protocol [34].
2.3.2 Protocol handshake
Discovery communication is encrypted and authenticated using the
session keys generated i n the handshake. Either side of the communication
can initiate a handshake at any time, as every node connected
to the network acts as a client and a server [34].
In the following definitions, w e assume that node A wishes to
communicate w i t h node B. N o d e A must have a copy of node B's
record to communicate w i t h it, e.g., to send a Findnode message.
Regarding the handshake process, the steps that both parties must
perform (also shown i n the Figure 2.3) are the following:
1. If node A has session keys from prior communication with node
B, it encrypts its message w i t h those keys. If no keys are known,
it initiates the handshake by sending an ordinary message packet
w i t h a random message content. We w i l l use the Findnode message
i n our example.
2. Node B receives the message packet and extracts the source node
ID. If node B has session keys from prior communication w i t h
node A , it attempts to decrypt the message data. If decryption
and authentication of the message succeed, there is no need for
a handshake, and node B can respond to the recipient. Otherwise,
w h e n node B does not k n o w the session key, it initiates a
handshake by responding w i t h a WHOAREYOU packet.
3. N o d e A receives the challenge sent by node B, w h i c h confirms
that node B is alive and is ready to perform the handshake. Node
22
2. E T H E R E U M PEER-TO-PEER NETWORK
A proceeds with the handshake by re-sending the Findnode message
i n a Handshake message packet. This packet contains three
parts besides the message:
• Id-signature - a signature created by node A , proving that it
controls the private key that signed its E N R . The signature
also prevents a replay of the handshake.
• Ephemeral-pubkey - a public key o n the Secp256kl curve corresponding
to a random ephemeral private key generated
by node A . The r a n d o m ephemeral private key is used to
perform Diffie-Hellman key agreement [36] w i t h node B's
static public key. The session keys are derivated f r o m it
using the HKDF key derivation function [37].
• Record - a record field that includes the current E N R sequence
number of node A .
The message from the first step is n o w present as a Handshake
message packet encrypted w i t h the generated session keys.
Node A NodeB
Step 2
Step 4
Figure 2.3: Protocol handshake i n Ethereum Node Discovery v5
4. N o d e B verifies the Id-signature against the public key of node
A . After that, node B performs the key derivation using its static
23
2. E T H E R E U M PEER-TO-PEER NETWORK
private key and the Ephemeral-pubkey from the Handshake packet.
Using the resulting session keys, it attempts to decrypt the message
contained i n the packet. If the message can be decrypted
and authenticated, Node B considers the new session keys valid
and responds to the message. In our example, it is a response
to the Findnode message, a Nodes message sent as a n ordinary
message packet, encrypted w i t h the session keys.
5. N o d e A receives the message packet response a n d authenticates/decrypts
it w i t h the new session keys. If it succeeds, node
B's identity is verified, and session keys are considered valid [34].
2.4 The RLPx Transport Protocol
The RLPx is a TCP-based transport protocol for communication among
the Ethereum nodes n a m e d after the R L P serialization format [31].
Based o n R L P , R L P x enables nodes to transfer encrypted, serialized
data. The protocol governs initiating, authenticating, and maintaining
sessions between nodes. It carries encrypted messages between two
nodes i n the execution layer. A l l the cryptographic operations are
based o n the Secp256kl elliptic curve. Each node has to maintain a
static Secp256kl private key[27].
A n R L P X connection between two nodes is established by creating
a T C P connection and agreeing o n an ephemeral key for further encrypted
and authenticated communication. The creation of a key is
called a n R L P x handshake and is done between the initiator and the
recipient. R L P x handshake uses an asymmetric encryption method
ECIES (Elliptic Curve Integrated Encryption Scheme) [27, 38].
2.4.1 Initial handshake
A s mentioned, a n R L P x connection starts w i t h an initial handshake
between the initiator and the recipient. It is a key-exchange process
that enables the nodes to communicate privately and securely w i t h
the generated ephemeral key w i t h a shared secret. This initial cryptographic
handshake starts w i t h the initiator generating the ephemeral
key w i t h a shared secret. The initiator then sends and auth message
containing the encrypted shared secret to the recipient. The recipi-
24
2. E T H E R E U M PEER-TO-PEER NETWORK
ent decrypts and verifies auth and generates the same ephemeral key
with the shared secret. Then it responds w i t h an auth - acknowledgment
message to the initiator [27, 39].
A l l messages following this handshake are framed. Frames are
encrypted and authenticated v i a key material generated during the
handshake. After the ephemeral key is negotiated, both nodes must
send a first encrypted frame containing the Hello message to perform
the second part of the handshake. Once they receive and verify each
other's Hello messages, the handshake is done. Alternatively, both
communicating sides can send a Disconnect message anytime to i n form
the peer that disconnection is imminent. Figure 2.4 presents an
overview of both parts of the initial handshake [27, 39].
Initiator Recipient
First part
— • of the
handshake
Figure 2.4: Two-phase handshake i n R L P x [27]
2.4.2 Elliptic Curve Integrated Encryption Scheme
Elliptic C u r v e Integrated Encryption Scheme (ECIES) is an asymmetric
encryption method used i n the R L P x handshake. This scheme
25
2. E T H E R E U M PEER-TO-PEER NETWORK
originated from the elliptic curve Diffie-Hellman ( E C D H ) for generating
and exchanging the symmetric keys. It uses the following functions
in RLPx:
• Key Agreement ( K A ) [40] - a function used to generate a shared
secret by two parties.
• The NIST SP 800-56 Concatenation K e y Derivation Function
(KDF) [41] - a mechanism that produces a set of keys f r o m
keying material and some optional parameters.
• A d v a n c e d encryption standard (AES) [42] - the AES-128 symmetric
encryption function i n C T R mode.
• Message Authentication Code ( M A C ) - data used to authenticate
messages. H M A C [43] using the SHA-256 hash function [27,44].
In order to describe the steps that must be taken to encrypt a
clear message (shown i n Figure 2.5), we w i l l follow the tradition and
assume that Alice wants to send a message to Bob, which Bob's static
private key k$ can decrypt. Alice knows Bob's static public keyKg. The
encryption steps are the following:
1. Alice generates a r a n d o m ephemeral private key r and corresponding
elliptic curve public key R, using the formula R = r-G
(G is a generator of Secp256kl elliptic curve). The key pair should
be generated pseudorandomly exclusively for the current pro-
cess.
2. After the ephemeral keys, r and R are generated, Alice w i l l use
the K A function to create a shared secret value S, w h i c h is the
result of the scalar multiplication of Alice's ephemeral private
key r and Bob's public key Kg.
S = Px/ where ( P x , P y ) = r • KB
3. Then, Alice takes the shared secret value S as input data for
the K D F . The output of this function is the concatenation of the
symmetric encryption key, kENc, a n
d the M A C key, kMA£.
K D F ( S ) = kENC || kMAC
26
2. E T H E R E U M PEER-TO-PEER N E T W O R K
4. W i t h the element ^EJVC/ the clear message, m, and newly derived
random initialization vector i v . Alice w i l l use AES's symmetric
encryption algorithm to produce the encrypted message, c.
c = AES(kENC, i v , m)
5. Taking the encrypted message c, concatenated with hashed k^AC
and i v , Alice uses the selected M A C function to produce a tag.
t a g = MAC(SHA256(kMAC),iv || c)
6. Alice sends the cryptogram (R || i v || c || tag) consisting of
those four concatenated elements to Bob [27, 38,44].
Sender's
ephemera
public key
Random
initialization
vector
Cryptogram ( 1
Encrypted
message Tag
tag
Recipient's
A private key
Message
in plaintext
AES(kEKC,\v1 c)
MAC(
SHA256(kmc),
i v l j c )
ENC key MAC key
Figure 2.5: ECIES Encryption [38]
27
2. E T H E R E U M PEER-TO-PEER N E T W O R K
Regarding the decryption process, the steps that Bob must perform
(shown i n Figure 2.6) are the following:
1. After receiving the cryptogram (R || i v || c || tag) from A l ice.
Bob must retrieve the ephemeral public key R, the tag, the
random initialization vector i v , and the encrypted message c to
deal w i t h those elements separately.
2. Using the retrieved ephemeral public key, R, and his private key,
1CB, Bob multiplies both elements to produce the shared secret
value S.
S = Px, where (Px, P y ) = R • kB
3. With the shared secret value S, Bob can compute k^AC a n
d ^ E N C K
D F ( S ) = kENC || kMAC.
Sender's
ephemeral
public key
Random
initialization
vector
Encrypted
message
Cryptogram (^1
Tag
tag
Recipient's
"\ private keyt
AES(kENC,
XV, c)
Message
in plaintext
MAC(
SHA256(kmc),
i v l l c )
\ \1 J
ENC key MAC key
Figure 2.6: ECIES Decryption [38]
28
2. E T H E R E U M PEER-TO-PEER NETWORK
4. Bob w i l l first compute the element tag w i t h the M A C key kMAC>
the encrypted message c, and the initialization vector i v . Then
he w i l l compare its value w i t h the tag he received as part of the
cryptogram. If the values differ, Bob must reject the cryptogram
due to a failure i n the M A C verification procedure.
tag == MAC(SHA256(kMAC, iv || c)
5. If the tag value generated by Bob is the correct one, he w i l l continue
the process by deciphering the encrypted message c using
the symmetric A E S algorithm and ^EJVC- Bob can access the plaintext
message at the end of the decryption process [27, 38].
m = AES(kENC, iv || c)
2.4.3 Protocol messages
R L P x contains four types of messages, H e l l o , Disconnect, Ping, and
Pong [27].
H e l l o . H e l l o is the first message sent over the encrypted connection.
It is sent once by both nodes. Until a H e l l o message is received,
no other message can be sent. In the H e l l o message, both sides send
the protocol version, the client software type, the capabilities and versions
they support, the port they are listening on, and their n o d e l D .
Capabilities are required for a successful interaction as it configures
communication. There is a subprotocol negotiation process i n the initial
handshake where the lists of subprotocols supported by each node
are compared. The ones c o m m o n to both nodes can be used i n the
session. The nodes w i l l disconnect if there is no protocol agreement
or the nodes disagree on the blockchain [27].
Disconnect. The Disconnect message informs the peer that disconnection
is imminent. It can be sent at any time of the communication.
The sender can append a reason for the disconnection. List of
disconnect reasons:
• disconnect requested,
• T C P sub-system error,
• breach of protocol, e.g., a malformed message,
29
2. E T H E R E U M PEER-TO-PEER NETWORK
• useless peer,
• too many peers,
• already connected,
• incompatible P2P protocol version,
• null node identity received - this is automatically invalid,
• client quitting,
• unexpected identity i n the handshake,
• identity is the same as this node (i.e., connected to itself),
• ping timeout,
• some other reason specific to a subprotocol [27].
P i n g and Pong. In addition to H e l l o and Disconnect messages,
RLPx uses Ping and Pong messages. Ethereum nodes periodically send
a Ping message to ensure connectivity of other nodes, and the corresponding
node should reply with a Pong. However, if the Pong message
is not received, the partner w i l l send a Disconnect message [27].
2.4.4 Capability messaging
Based on the R L P x protocol, Ethereum utilizes different capabilities
in different clients or conditions. A l l messages following the initial
handshake are associated w i t h a capability. The connections' capabilities
supported on both sides are exchanged i n the H e l l o message.
The capabilities represent the supported RLPx-based application-level
(sub)protocols and their versions. A n y number of capabilities can
be used concurrently on a single R L P x connection. Ethereum Wire
Protocol (eth), which facilitates the exchange of Ethereum blockchain
information between full nodes, is the most widely used. This protocol
and a few others w i l l be described i n the following subsections [26,
27].
2.5 Ethereum Wire Protocol
Ethereum Wire (eth) is a protocol based on the R L P x that facilitates
the exchange of Ethereum blockchain information between peers. The
30
2. E T H E R E U M PEER-TO-PEER NETWORK
current protocol version is eth/67. After establishing the connection,
both peers need to send a Status message. Following the reception
of the peer's Status message, the Ethereum session is active, and any
other message may be sent [26,28].
Initially, before the Merge, the wire protocol defined three m a i n
tasks: chain synchronization, block propagation, and transaction exchange.
However, once Ethereum switched to proof of stake, block
propagation and chain synchronization became part of the consensus
layer. Transaction exchange is the only task still i n the remit of the
execution clients. Transaction exchange refers to exchanging pending
transactions between nodes so validators can select some of them for
inclusion i n the next block [26, 28].
2.5.1 Status message
A s mentioned, the Status message should be sent just after the connection
is established and prior to any other eth protocol messages. The
message conveys the current state of a node's blockchain. It contains a
node's protocol version, network ID, and the Keccak256 hash of the
genesis block. The fundamental requirements for a node to keep the
connection w i t h peers are to have the same genesis block and network
id. If a node encounters an Ethereum peer o n a different Ethereum
network or genesis hash, it w i l l disconnect f r o m that peer w i t h the
reason message, useless peers, or incompatible protocol [28].
2.5.2 Transaction exchange
Transaction exchange refers to exchanging p e n d i n g transactions between
nodes. The nodes must exchange p e n d i n g transactions to relay
to validators, w h i c h can select some of them for inclusion i n the
blockchain. Execution client implementations keep track of pending
transactions i n a transaction p o o l [28].
Both sides need to synchronize the transaction pools w h e n a new
peer connection is established. Initially, both ends should send NewPooledTransactionHashes
messages containing all transaction hashes
in the local pool to start the exchange. U p o n receiving the NewPooledTransactionHashes
notification, the client filters the received p o o l
and collects the transaction hashes that it does not already have i n
31
2. E T H E R E U M PEER-TO-PEER NETWORK
its local pool. It can then request transactions using the GetPooledTrans
act ions message. Requested transactions are sent w i t h i n the
PooledTransactions message i n the order i n w h i c h they were requested
[28].
W h e n new transactions appear i n the client pool, it propagates
them to the network using the Transactions and NewPooledTransactionHashes
messages. The Transactions message carries complete
transaction objects and is typically sent to a small, r a n d o m subset of
connected peers. A l l other peers are notified of the transaction hash
value and can request the complete transaction object if it is u n k n o w n
to them. Spreading full transactions to a fraction of peers usually
ensures that all nodes get the transaction and do not have to request
it [28].
2.6 RLPx-based application-level protocols
Other application-level protocols are not so widely used. A few are optional
and cannot r u n without eth, as they are not complete standalone
protocols [26].
2.6.1 Light Ethereum Subprotocol
Light Ethereum Subprotocol ( l e s ) is a protocol used by light clients.
Light clients download only block headers as they appear and retrieve
other parts of the blockchain on demand from the light servers. Such
clients use l e s to communicate w i t h light servers. Since there is not
enough incentive for a full Ethereum node to serve as a light server,
only a tiny percentage of Ethereum full nodes support l e s [26, 45].
A study conducted between A p r i l and July 2018 reported that only
1.24% of Ethereum nodes supported l e s [46].
Similarly to Ethereum Wire Protocol, l e s utilizes Status messages.
It informs a peer of the sender's current state and should be sent prior
to any other l e s messages. A s light clients do not receive information
about any foreign transactions i n the network, and every transaction
that the light client is willing to send has to go through the light server,
it uses a special message for transaction sending. SendTx requires
the light server to a d d a set of transactions into its transaction p o o l
and relay them to the Ethereum network. The light server returns
32
2. E T H E R E U M PEER-TO-PEER NETWORK
a TxStatus message containing the status of the sent transactions.
TxStatus can also be requested using the GetTxStatus message [26,
45].
2.6.2 Parity Light Protocol
The Parity Light Protocol (pip) is a variation of les designed and
implemented b y Parity Tech for the Parity Ethereum client. Just like
the Light Ethereum Subprotocol, pip utilizes Status messages for
the same purposes. RelayTransactions message is a request for the
given transactions to be relayed to the Ethereum network. In order to
request information about the transactions, the light must send the
clientTransactionlndex message. It is a request-response message
[26,47].
2.6.3 Ethereum Witness Protocol
The witness protocol (wit) enables the exchange of state witnesses
between peers, helping to synchronize clients to the top of the chain.
It is an optional protocol to be r u n along w i t h the eth protocol, not
standalone. A t the time of writing, it has no Status message. H o w ever,
it is marked as a possibility i n the future. Currently, it utilizes
two types of messages, GetBlockWitnessHashes, a n d its response
BlockWitnessHashes [26,48].
33
3 Anonymity in Etheruem
A n o n y m i t y is among the essential properties of any cryptocurrency.
The initial 2008 white paper [1] introducing blockchain technology
through Bitcoin promoted the concept of privacy and anonymity. The
idea was based on the fact that only two parties are involved since cryptocurrency
allows direct P2P transactions over the Internet. Anonymity
for a particular element, be it a h u m a n or a computer, refers to the
property of that element not being identifiable within an "anonymity
set". A n anonymity set could be defined as a group where the specified
element is observed [3,49].
Every Ethereum transaction is though linked to the addresses of the
sender and receiver. A n address corresponds to a public key representing
a user. Every action the owner does with the Ethers on that address
can be linked back to the initially owned address as the blockchain is
public and w i d e l y available. A s a result, Ethereum transactions are
k n o w n as pseudonymous, meaning that the Ethereum network does
not offer anonymity, only pseudonymity. However, no one knows the
real identity of the pseudonym, which protects the user's privacy. Suppose
an Ethereum address can be linked to a real-world individual. In
that case, there is zero privacy provided by Ethereum. Therefore, all
previous or further transactions can be linked to that individual, and
the pseudonymity is broken [3,49].
3.1 Ethereum Name Service
Ethereum Name Service (ENS) [50] is a distributed, open, and extensible
n a m i n g system based on the Ethereum blockchain. L i k e D N S ,
E N S operates on a system of dot-separated hierarchical names called
domains, w i t h the owner of a d o m a i n having complete control over
subdomains. Nevertheless, i n E N S , the registry is implemented i n
Ethereum smart contracts. E N S maps human-readable names like
alice.eth to machine-readable identifiers, e.g., Ethereum addresses.
Therefore, E N S provides a user-friendly way of m o v i n g assets on
Ethereum. Users can use E N S names (alice. eth) as recipient addresses
instead of the error-prone hexadecimal Ethereum addresses [51, 52].
34
3- A N O N Y M I T Y I N E T H E R U E M
Using E N S for addresses might make them less anonymous, contradicting
Ethereum, which many people use because of its anonymity.
It is not the same as w i t h D N S , where there is a public registry and
registrars keep all personal or corporate details. However, E N S addresses
are not anonymous either. The data is there linking an address
to a person or company. M a n y E N S users post their E N S name on their
Twitter profiles to facilitate transactions for those w h o want to interact
w i t h them on the Ethereum network. Such behavior links the E N S
to Twitter profiles. A l l the subdomains w i t h i n one d o m a i n are considered
to have the same owner. Therefore all the addresses from the
subdomains can be linked. Researchers can use this approach to have
a valid ground truth for testing the address clustering methods [ 5 2 ] .
3.2 Deanonymization
The ultimate goal of deanonymization is to reveal the relationship between
cryptocurrency transactions or addresses and real-world identifiers,
such as IP addresses. Deanonymization i n cryptocurrency can
also a i m to identify addresses belonging to the same user. However,
the result without any false positives is not possible i n many cases.
Therefore such attacks often focus on reducing the anonymity set of
an account as m u c h as possible. There are several approaches to h o w
deanonymization can be performed. The data can be collected from
the network by eavesdropping or collecting data received data from
other participants i n the network. T h r o u g h the transparency of the
blockchain, data can also be collected directly from some blockchain
explorer or node. A l t h o u g h there are many deanonymization technics
on Bitcoin, the same approaches cannot be used on Ethereum, as
their blockchains differ i n many ways. The m a i n difference between
Bitcoin and Ethereum is that the Ethereum nodes' communication is
encrypted. Thus, an on-path eavesdropper cannot read the exchanged
messages, making it impossible to use several approaches. The following
sections w i l l describe several possible deanonymization technics
on the Ethereum blockchain [ 5 3 ] .
3 5
3- A N O N Y M I T Y I N E T H E R U E M
3.3 Deanonymizing Ethereum users based on network
monitoring
This attack is based on the fact that newly created transactions are
broadcasted to the network f r o m one source node. The goal of this
attack is to find such a source node. Each Ethereum node can be either
the creator, which broadcasts the transaction, or the forwarder. W h e n a
user wants to initiate a transaction, he first enters the basic information
needed, including the recipient's address, the amount of Ether, or the
gas price. Then, the transaction is signed w i t h his private key and
broadcasted to the network by a source node. A s described i n Section
1.3, there are three ways from w h i c h a user can send a transaction,
full node, light node, and wallet. The source node differs i n every
possibility. If a light node is used for transaction creation, it sends it
to a light server, w h i c h broadcasts it to the network. This light server
is a source node o n this occasion, as it is the first node propagating it
to the whole network. The server is also the only one w h o knows it
was initiated from the light node. W h e n a user uses a wallet to create
a transaction, the wallet is usually connected to a third-party trusted
node, which can be considered a source node. In both cases, the source
node is not owned by the transaction creator. Therefore they cannon
be linked. We w i l l discuss the security and privacy issues of the light
clients and wallets i n Section 5.2, respectively 4. If the user runs a full
node, it broadcasts the transactions directly into the network. The full
node itself is the source node i n this case. Therefore, such an attack
aims to identify the full node from where the transaction was sent [10].
This attack on user anonymity mainly focuses on applying P2P
network information to map transactions to their source node IP addresses.
D . Kaminsk [54] first traced Bitcoin transactions via network
timestamps. H e proposed the idea that the first node forwarding the
transaction is likely to be the node f r o m w h i c h it originated. A similar
technic can be used i n Ethereum [54]. In order to deanonymize
Ethereum users by finding an IP address of the source node, we need
to monitor the entire network by connecting to practically every node.
A t the time of writing, there are currently around 7000 active nodes
[55]. Due to the size of the network, this approach requires significant
resources. However, this attack w i l l be effective w i t h access to the
3 6
3. A N O N Y M I T Y I N E T H E R U E M
necessary resources. Each node can, b y default, maintain u p to 50
active connections for the latest version of the Geth client. To be able to
monitor the whole network by connecting to every node, it is necessary
to deploy more than a h u n d r e d nodes. The number can be reduced
by adjusting the m a x i m u m possible client connections. In addition,
each node should maintain connections w i t h non-overlapping parts
of nodes i n the entire network. Such modifications w i l l reduce the
necessary costs and resources. Besides, the connection requests are not
always accepted by nodes due to the limit of the m a x i m u m number of
connections, which causes some nodes to be temporarily unreachable.
Due to this fact, keeping an active connection w i t h every node i n the
network is almost impossible. However, the modification also includes
periodic reconnection to the nodes that disconnected because of too
many peers, reducing the number of unconnected peers [56].
As this attack requires the investigation of incoming transactions,
they must be logged. Although the transactions from the node's transaction
pool can be listed, they do not contain any information about
the senders' node. By default, Ethereum execution clients do not log
information about incoming transactions, w h i c h is crucial i n such an
attack. Therefore, it is necessary to m o d i f y the client's source code
to log each received transaction information, including timestamp,
transaction hash, sender account address, and sender node IP of the received
transactions [56]. A n example of a logged transaction is shown
in Figure 3.1.
INFO [lz-BZ|15:3S:11.22e] ETH - Hecieved Tx Ha^h=ex45c5c39772dcl57619a8104c42fQ89dl58c08b3bb7e0fa3fa8f34f36a850fd73
=enode://6368bl30cfcldaJ746e7bcZ23ab2380a8dbd2e0395e7e39e511ab98474758d6cZal60fl5£i737ff8753b6sZ4eb4eS706ac4643ca
I?1731b9d4f287b9e5S84014fl@77,161,16,186:30303
Figure 3.1: Received transaction
As mentioned, a set of nodes has to be managed to perform such
attack. Therefore, each transaction can be received by several nodes
from different possible source nodes. To our knowledge, there are two
basic estimators to infer the source node of the transaction:
First reach estimator. This estimator was proposed by D . Kaminsky.
According to this method, the source node is the one from w h i c h the
transaction was received first. Mathematically, it can be expressed as
the m i n i m u m timestamp value for a given transaction. The success
of this estimate is based on the assumption that the network delay
37
3. A N O N Y M I T Y I N E T H E R U E M
time for one-hop forwarding is always shorter than for two-hop forwarding.
However, several studies [57, 58] have s h o w n that triangle
inequality violation (TIV) i n the network is a persistent and common
phenomenon. This phenomenon means that one-hop forwarding takes
more time due to higher network delay than two-hop. Therefore, this
estimate is not always correct [56].
First sent estimator. This estimate takes into account the shortcomings
of its predecessor. Due to this, it uses the network delay between
the nodes. The delay measure highly influences its performance, as it
cannot be accurate. Mathematically expressed, the source node has
the smallest timestamp value after subtracting the measured delay [56,
59].
These two basic estimators have their imperfections. According
to researchers f r o m Beijing University [56], w h i c h used them on the
Ethereum mainnet, the success rate of the First reach estimator was
more than 78%. The success rate of the second estimator was slightly
higher as it reached 80%. W h e n the First sent estimator fails, it was
found that the First reach estimator m a y sometimes correctly infer
the source node. Inspired by this, the same researchers devised a machine
learning-based estimator combining both previous estimators.
The performance of such an estimator depends to some extent on
both underlying estimators. Nevertheless, it can infer the source node
with a higher success rate without h u m a n decision, as it reached 88%.
W i t h an assumption that transactions w i t h the same sender address
are sent f r o m the same node can be the source node deanonymized
through multiple transactions. With two sent transactions, the success
rate is 94%. W h e n three transactions are sent from the same account,
its source node can be inferred w i t h a success rate of 99%. This fact
correlates w i t h Satoshi Nakamoto's wisdom: each transaction should
be sent f r o m different accounts to keep anonymity as high as possible
[56].
3.4 Address clustering
By definition, address clustering aims to partition the set of addresses
observed i n transactions into m a x i m a l subsets of addresses. These
subsets are likely controlled b y the same entity, for example, the re-
38
3- A N O N Y M I T Y I N E T H E R U E M
identification of multiple addresses belonging to the same entity. A l though
it primarily cannot reveal the user's identity i n the real world,
m a p p i n g one account to the IP address provides an opportunity to
deanonymize all accounts clustered to this account. A s shown i n the
previous section, using a different account for every transaction i n creases
possible privacy. Users w i t h malicious intent widely use this
approach [ 6 0 ] . Besides, regular users may also create new addresses
with the consideration of privacy. Such attacks often do not link exact
accounts. However, they can reduce the anonymity set, which is harmful
to privacy. In recent history, several possible address clustering
approaches have been suggested. Nevertheless, most of them were
created for Bitcoin, where the most widespread clustering methods
are based o n the Unspent transaction output ( U T X O ) . Therefore they
cannot be used i n Ethereum, and new methods for Ethereum transactions
correlation have been designed based on user habits and specific
scenarios. A l l data are gathered from the blockchain and freely available
on the blockchain explorers. There is no need to r u n a full node
to perform such a n analysis [53, 6 1 ] .
3.4.1 User habits
Multiple accounts owned by the same user exhibit similarities i n behavioral
habits, and transactions can be correlated by extracting features
related to user habits.
The gas price distribution. Every Ethereum transaction contains the
gas price, w h i c h is usually automatically set by the owner's software
wallet. A c c o r d i n g to data from Etherscan, users rarely change this
setting manually. Most wallet user interfaces offer three tiers of gas
prices, slow, average, a n d fast. The fast gas price guarantees nearinstant
inclusion on the blockchain. Changes i n Ethereum's daily traffic
volume sometimes cause temporary network congestion, affecting gas
prices. Hence, the gas price can be normalized by the daily network
average. Users paying significantly different gas prices can be found
by comparing the normalized gas price. According to collected data,
users only occasionally pay more than three times the daily average
gas price. The combination of these gas price levels forms the so-called
gas price profile for each Ethereum user [ 5 1 ] .
3 9
3. A N O N Y M I T Y I N E T H E R U E M
Time-of-day transaction activity. Ethereum transaction timestamps
can reveal the daily activity patterns of the account owner. Users from
different time zone should have different active times [51].
Transaction graph analysis. This analysis is based on the fact that the
set of addresses used i n interactions characterizes the user. Users w i t h
multiple accounts can interact w i t h the same addresses or services
from most of them. Users may inadvertently expose their address
clusters when they move funds between their addresses. The graph is
represented by addresses as nodes and transactions as edges. N o d e
embedding methods can perform such analysis. They are network
representation learning methods that m a p graph nodes to vectors
in a low-dimensional vector space. These methods are designed to
represent vertices w i t h similar neighborhood structures b y vectors
close i n the vector space. Intuitively, addresses that interact w i t h the
same addresses i n the Ethereum transaction graph should be close i n
the embedded space [62].
Evaluation of methods. In 2021 Beres et al. [51] investigated these
three quasi-identifiers of the account owner. The methods were used
on 3321 accounts collected from Twitter and other sources. O n l y the
accounts with more than five transactions were selected. The accounts
w i t h a smaller number of transactions were discarded as do not provide
enough data for processing. The evaluation used 129 address
pairs belonging to the same E N S name. A l t h o u g h the dataset contained
E N S names w i t h more than two addresses, such addresses
were excluded to avoid possible validation bias [51].
For each account, a set of possible candidate pairs, where precisely
one account is the correct pair, was created. A simple metric, the
target's average rank, has been proposed according to the ranked list
of all sets. The results were evaluated by Area under the R O C curve
( A U C ) [63] and gained entropy [64]. A U C is the probability that a
randomly selected correct record pair is ranked higher than another
incorrect one. Entropy quantifies privacy loss by the number of bits of
additional information needed to identify a node. Entropy gained is
then the difference between the entropy without the deanonymization
method and entropy after applying the method. The second method
achieved better results, as the measured A U C reached 0.69 and entropy
gained 0.40. The gas-based method achieved results equal to 0.60 and
0.12, respectively [51].
40
3- A N O N Y M I T Y I N E T H E R U E M
Transaction graph analysis was performed using twelve different
node embedding methods created to discover address pairs that might
belong to the same user from the library of Rozenberczki et al. [65].
Methods w i t h the best results were Diff2Vec [66] and Role2Vec [67],
with both reaching more than 0.80 A U C and 1.2 entropy gained. Even
better Ethereum address linking was achieved by combining these two
methods, as it reached results equal to 0.85 for A U C , respectively 1.6 for
entropy gained. The achieved A U C denotes it can find matching pairs
of E N S addresses almost 20% more likely than the first two methods.
Also, the gained entropy yields 1.6 bits of additional information o n
account owners, w h i c h means it can reduce the anonymity set of a
particular address by a factor of 2 1 6
« 3.0314 [51].
The combination of Diff2Vec and Role2Vec can identify the correct
address pair within rank 1 with a 20% probability. The results showed
that within the same rank, there is almost a 0% chance of identifying
the correct address pair using the first two methods. The probability
that the correct pair is within the 100 selected candidates is almost 20%
using the time-of-day activity. The gas price method has this likelihood
of only around 10%. The combination of Diff2Vec and Role2Vec can
find the correct pair within the 100 candidates w i t h a 60% probability
[51].
A l t h o u g h these techniques cannot link the Ethereum addresses
of the same user w i t h a 100% probability, they provide m u c h better
results than random guessing. A s we mentioned, reducing the size of
an anonymity set is also considered a success.
3.4.2 Deposit address reuse
In order to sell Ether or other crypto assets, a user has to send them
to a n exchange. A cryptocurrency exchange is a n online marketplace
where users buy, sell, and trade cryptocurrency Exchanges typically
create so-called deposit addresses to credit the assets to the correct
account. Received funds are then forwarded from the deposit address
to the exchange's p r i m a r y address. A s these deposit addresses are
created per customer, multiple addresses that send funds to the same
deposit address are highly likely to be controlled by the same entity.
The key lies in identifying these deposit addresses. The primary function
of these addresses is to forward received amounts to a major
41
3. A N O N Y M I T Y I N E T H E R U E M
exchange account. The forwarded amount is often slightly smaller
than the received, as transaction costs are to be paid. Addresses that
send transactions to the same deposit address can be clustered. The
evaluation performed by Victor [68] showed that more than 44% of
accounts that used a deposit address used the same deposit address
w i t h more than one account and that 333,107 entities consist of more
than one address. A m o n g other things, this method can provide i n sight
into h o w large the exchange clusters are. U s i n g this heuristic,
more than 16% of newly seen EOAs can be clustered w i t h previously
seen addresses [68].
3.4.3 Airdrop multi-participation
Airdrops are a popular token distribution mechanism. O n the Ethereum
blockchain, airdrops are performed through smart contracts. The
smart contract owners choose beneficiaries based o n past activity
or ask users to register through online forms. A common practice is rewarding
users with airdrops once they have performed an activity on
social media, such as following specific users or posting articles. The
amount of tokens allocated to each user is fixed or based on existing account
balances. If the amount is fixed, the system can be cheated as one
user can perform actions w i t h multiple social media accounts. Once
the airdrop is performed, tokens are assigned to all user's registered
addresses. Since managing several addresses is impractical, tokens are
usually collected and aggregated to a single address. This pattern can
be exploited to identify single entities that receive multiple tokens. It
only identifies airdrops where a fixed number of tokens is distributed
to many recipients. The search is focused on addresses that have been
forwarded the same amount from the initial token recipients. According
to the results from Victor, 675512 addresses are controlled by 20453
entities. Overall, this heuristic can cluster many fewer addresses than
the deposit address reuse heuristic, approximately 1% of newly seen
EOAs [68].
3.4.4 Self authorization
Ethereum allows another address to spend tokens on behalf of the
actual owner, w h i c h is conditional o n the owner's approval. A n ap-
42
3. A N O N Y M I T Y I N E T H E R U E M
proval contains the owner, spender, and permitted amount. Through
such approval, the spender can access a specified amount of tokens.
This approval is mainly used for smart contracts. However, it can also
be used for regular EOAs. This heuristic is based o n the assumption
that there exist users that approve another address they o w n . This
process is called self-authorization. According to Victor, this heuristic
provides only a few results, as just 4599 entities, together w i t h 7107
addresses, were captured [68].
3.4.5 Smart contract code attribution
This method leverage a stylometry1
approach to explore the extent to
w h i c h a deployed contract's bytecode and its high-level source code
can contribute to the affiliation of account addresses. It is based o n
code authorship techniques that allow the identification of an anonymous
code author based o n unique characteristics that describe the
author's coding style and distinguish the author's code. The coding
style can be expressed through several levels, lexical (variables, function
lengths), layout (indentation, whitespace), and semantic (control
flow structure). The effectiveness of these features o n the accurate
attribution of source codes has been demonstrated i n authorship attribution
research [70].
The deployed contract contains only its bytecode a n d does not
preserve its source code. For obtaining the source code, reverse engineering
techniques can be applied to the bytecode. However, such
technics can be applied to a limited degree as the source code is affected
by the compilation process and optimization. Optimizing the
contract's bytecode for performance may change the contract's code
structure while maintaining the same functionality. For example, the
EVM does not require human-readable variable names and is encoded.
A s a result, the layout information of the source code is removed.
There were proposed tools to reverse engineer a contract's bytecode
to a human-readable source code, but they brought m i n i m a l results.
1. Stylometry is the application of the study of linguistic style, usually to written language.
Another conceptualization defines it as the linguistic discipline that evaluates
an author's style by applying statistical analysis to a body of their work. Stylometry
is often used to attribute authorship to anonymous or disputed documents. It can
be applied to music, art, or computer code [69].
43
3. A N O N Y M I T Y I N E T H E R U E M
Therefore, only verified smart contracts that provide both bytecode
and source code representations can be used for such analysis. Such
data can be retrieved from Etherscan. It enables a contract's author to
upload the source code to their platform and link it to the deployed
contract address on the blockchain. The source code is then compiled
into bytecode and compared to the bytecode of the deployed contract.
The contract source code is verified if the two are the same [71].
While the contract's source code preserves the complete stylistic
properties, including the layout and lexical properties, the contract's
bytecode preserves only some stylistic properties. A s there are standard
interfaces extensively used i n smart contracts, the source codes of
many contracts may contain similarities, such as extensive code reuse
or code length. Data has to be refined to avoid unnecessary attribution
bias and reduce the amount of shared code i n the contracts.
According to Linoy et al. [71], it is feasible to attribute Ethereum
contracts to their corresponding deployers. The results achieved 93.5%
accuracy i n attributing source codes and 80% i n attributing bytecodes.
A s expected, the results show that source code attributing accuracy is
higher than the bytecode attributing accuracy. Two commonly used
approaches i n code attribution, attribution based on n-grams and
attribution based on a state-of-the-art feature set proposed by Caliskan
et al. [70], were used i n the analysis phase [71].
3.5 Privacy enhancement
The most w i d e l y used privacy enhancement technic i n Ethereum is
coin mixing. Coin mixer hides transactions on a blockchain by mixing
them w i t h multiple other transactions, such that each transaction's
links are untraceable. C o i n mixers may be custodial or non-custodial.
In the case of custodial mixing, users send coins to a trusted third
party f r o m w h i c h , after some timeout, the coins can be w i t h d r a w n
back. Using such mixers can be dangerous as the user does not retain
ownership of the coins during the shuffle, and the trusted mixing party
might steal funds, as it already happened [72]. Non-custodial mixers
replace the trusted mixing party with a publicly verifiable transparent
smart contract or secure multi-party computation. Although there are
several Ethereum coin mixers, Tornado C a s h is the most used at the
44
3. A N O N Y M I T Y I N E T H E R U E M
time of writing. Tornado C a s h is a non-depository solution that lets
users make their ETHs or other ERC-20 tokens private by sending them
via a smart contract. First, users deposit equal amounts of Ether into a
Tornado Cash smart contract from its address. Each T C contract uses
a fixed denomination for mixed pools (e.g., 1 ETH). Otherwise, linking
deposits to withdrawals w o u l d be trivial. After a user-defined time, the
user can withdraw funds from the mixer contract w i t h a withdrawal
transaction to a freshly generated EOA. In the withdrawal transaction,
a user provides zero-knowledge proof proving that the withdrawing
user is one of the depositors. This process ensures that the withdrawn
funds can't be linked to the deposit source, thus ensuring the privacy
and anonymity of the assets. Tornado Cash uses z k S N A R K s [73] as
zero-knowledge proof [51, 74].
A user's anonymity is defined by the number of equal user deposits
in a given mixer. Cryptocurrency mixers typically provide fc-anonymity.
Generally speaking, a fc-anonymized dataset has the property that each
record is indistinguishable f r o m at least k - 1 others. Specifically, if
a mixer contract contains n deposits out of w h i c h n-k h a d already
been w i t h d r a w n , then the following withdrawal entity w i l l be indistinguishable
among at least those k users w h o have not w i t h d r a w n
from the mixer yet. Hence, each withdrawer can enhance their transaction
privacy and make their identity indistinguishable among at least
k addresses. The probability of correctly guessing the deposit/withdrawal
connection is 1 /k. The more users that deposit i n the mixer,
the greater the number of people f r o m w h o m a w i t h d r a w a l could
have come. The set containing the k indistinguishable addresses is
called the anonymity set of the user. However, there are many ways
users can compromise their privacy, w h i c h w i l l be described i n the
following section. If an attacker can link a deposit to a withdrawal,
the anonymity set decreases by one and increases the probability of
correctly guessing other deposit/withdrawal connections [51, 74].
3.6 Tornado Cash heuristics
This section provides techniques and heuristics to decrease the anonymity
achieved i n a T C mixer. Careless usage quickly reveals links between
deposits and withdrawals, affecting the anonymity of other users since
45
3- A N O N Y M I T Y I N E T H E R U E M
the deposit linked to a withdrawal no longer belongs to the anonymity
set. We list four heuristics that can be used to link deposits and w i t h drawals
[51, 74]:
The exact deposit and withdrawal address. Some users use the same
address for a deposit and also a withdrawal. These deposits and withdrawals
are considered to be linked. It is the most straightforward
careless usage [51]. This heuristic is later referred to as Heuristic 1.
Specific gas price. Before August 2021, the transaction gas price had
a different structure than now. The current structure of gas price is
described i n Section 1.3.1. The gas price was just one number specified
by the user or wallet. This heuristic is based on the older gas price
specification. M o s t wallets set the gas price automatically as multiples
of Gwei (109
Wei, i.e., Giga Wei). Such a price ends w i t h nine
zeroes. Therefore it is simple to observe gas prices whose last nine
digits are non-zero. Those gas prices are likely set by the transaction
issuer manually. The deposit and w i t h d r a w a l pair can be linked if
there is a deposit transaction and a withdrawal transaction w i t h the
same specific gas price [51, 74]. This heuristic is later referred to as
Heuristic 2.
Transaction between addresses. The most c o m m o n technique for
linking Ethereum addresses of the same user is linking two addresses
that share the transaction. It is hardly believed that these two addresses
belong to one user. People tend to forget about this, consider their
addresses clean, and use them for withdrawals. However, if the withdrawal
address can be linked to one of their deposit addresses, they
effectively lose all privacy guarantees accomplished by the new withdrawal
address. If there is a transaction between the deposit address
and the withdrawal address, the addresses consider linked [51, 74].
This heuristic is later referred to as Heuristic 3.
Multiple Denomination. Previous heuristics examine isolated pairs of
deposit and withdrawal transactions. This heuristic, however, studies
an address' history of transactions. It computes the portfolio of an
address' withdrawals across Tornado C a s h mixers. For instance, the
same address was used for withdrawal several times f r o m different
mixers, defining the address' withdrawal portfolio. If there is an address
i n which the portfolio of deposit transactions is exactly the same
as the withdrawal portfolio of the found address. A l l Tornado C a s h
4 6
3. A N O N Y M I T Y I N E T H E R U E M
transactions under the matched deposit and withdrawal address are
linked [74]. This heuristic is later referred to as Heuristic 4.
3.6.1 Heuristics evaluation
In 2020 Beres et al. applied these three heuristics to four mixer contracts,
0.1 E T H , 1 E T H , 10 E T H , and 100 E T H . The results of the heuristics
are shown i n Table 3.1.
Mixer H I H 2 H 3 Total
0.1 ETH 7.5% 6.2% 8.8% 17.1%
1 ETH 2.5% 4.8% 9% 13.2%
10 ETH 1.1% 1.2% 6.2% 8.1%
100 ETH 1.5% 3.8% 2.3% 5.3%
Table 3.1: Percentage rate of the deanonymized withdraws using the
corresponding heuristics i n each mixer contract [51]
A s the table shows, the third heuristic is the most successful i n
terms of percentage. The withdraws identified by Heuristic 2 can also
overlap w i t h those identified b y Heuristic 1 or 3. Hence, the total
linked withdraws are less than the sum of all withdraws individually
identified by each heuristic. Another interesting point from the table
is that the higher the amount i n the mixer, the lower the percentage
of successful address linking. O n l y 5.3% of withdrawals were linked
w i t h the deposit f r o m the 100 E T H mixer. O n the other hand, 17.1%
of withdrawals from the 0.1 E T H mixer were successfully linked with
the deposit. According to these results can be assumed that people
sending more E T H care more about privacy.
Researchers also provided data on address reuse. The results are
curious as more than 8% of users reused the withdrawal address
twice, and 3% of users three times. This phenomenon causes privacy
risk not just for the owner of these addresses b u t also reduces the
privacy properties of the mixer. Proper mixer usage always requires a
withdrawal to a new address [51].
In January 2022, W u et al. [74] evaluated all four heuristics on three
mixers 1 E T H , 10 E T H , and 100 E T H . The results of the heuristics are
shown i n Table 2.
47
3. A N O N Y M I T Y I N E T H E R U E M
Mixer H I H 2 H 3 H 4 M i x e d Total
1 ETH 13.6% 0.3% 2.7% 15% 5.2% 36.8%
10 ETH 7.1% 0.5% 2.3% 21% 3% 33.9%
100 ETH 21.3% 0.2% 1.2% 14.1% 6.1% 42.9%
Table 3.2: Percentage rate of the deanonymized withdraws using the
corresponding heuristics i n each mixer contract [74]
The overlapping withdrawals are displayed i n the column "Mixed."
There is a two-year gap between the researchers, so the amount of
account i n this research is much higher. The poor success of the second
heuristic is because the method was evaluated after introducing a new
representation of the gas price. Therefore, the gas price is not set just
by the user or wallet but by the base fee, w h i c h is the same for every
transaction i n one block.
Overall, these researchers' results were much more successful than
the results from 2020. We can consider people less careful when using
cryptocurrencies due to massive differences i n the results. The growing
popularity of cryptocurrencies can cause it. Nowadays, more and more
uneducated people get into the crypto world because it is popular. It
means more careless people are trying to use mixers. A c c o r d i n g to
this research, more than a third of all withdrawals can be successfully
linked to the deposit. Surprisingly, the best results are achieved by
the heuristics that count on breaking the coin mixer's rule number
one, "Do not reuse an address.", which underlines the fact that mainly
unwary users destroy the privacy that Ethereum provides.
The observation f r o m previous research that a higher amount i n
the mixer means lower heuristic success does not correlate w i t h the
result of this paper. 21.3% percent of 100 E T H mixers were pointless, as
the same address for deposits and withdrawals was used. We cannot
explain such a low success of Heuristic 3. It can be caused by the fact
that if people use mixers, they do not send a transaction without using
one [74].
4 8
3. A N O N Y M I T Y I N E T H E R U E M
3.7 Priority fee heuristic
A l l the described heuristics using the gas were based on the o l d gas
price specification. Therefore, we propose a new one that uses the
priority fee to distinguish the users. The priority fee is the only value
a user can change the fee with. It is to fee paid directly to the creator
of the block that includes this transaction. W h e n sending a transaction
f r o m the Metamask wallet, the priority fee is, by default, set to
1.5 GWei. According to Metamask, this value represents the m e d i u m
gas fee, which w i l l most often result i n a successful transaction. If the
user wants to change this " m e d i u m " value, Metamask provides two
predefined options, low and high. The low gas fee should only be used
when processing time is not critical. Lower fees make it hard to predict
w h e n (or if) the transaction w i l l be successful. The l o w priority fee
equals 1 GWei. The high gas fee is used for sensitive transactions that
must be processed as soon as possible. The h i g h priority fee equals
2 Gwei. We believe that most users use the predefined Metamask values.
Therefore we can find transactions w i t h higher priority fee than
2 GWei and consider them manually set by the user. Provided that the
user uses the same priority fee for all its transactions, we can find all
the transactions based on such a priority fee. If the user has several
accounts, we can cluster them this way.
To evaluate this heuristic, we created an account on the Goerli
testnet. We sent several transactions from this account w i t h the same
priority fee, 5 GWei. We created a python script to search through
the blocks and find all the transactions w i t h such a priority fee. It
successfully found all our transactions. Even though we have selected
only 200 blocks, we have found more than 150 other transactions w i t h
such a priority fee. The transactions were f r o m approximately 100
accounts, so we knew such a number w o u l d not help us as there were
many false positives.
W i t h more analysis, we f o u n d that all the rounded numbers are
commonly selected as a priority fee. A l l the rounded GWei values like
5, 7,15,20, or 6.5 end w i t h eight or nine zeroes. Therefore, we decided
to search for not rounded values, as they are not so commonly used.
We edited the script (see Attachment A . l ) and searched for data i n
7000 blocks, resulting i n more than 2800 transactions. Seven thousand
blocks represent data f r o m almost one day. W e sorted them by the
49
3. A N O N Y M I T Y I N E T H E R U E M
priority fee to see w h e n the exact fee is used i n different transactions.
If several transactions w i t h the same priority fee were sent from different
accounts around the same time, we manually checked them on
Etherscan.
The first suspicious transactions we found are shown i n Figure 3.2.
The first three transactions were sent from the same account to three
Transaction Hash Sender Recipient Priority Fee
0x877594f28080a95f510... 0 x d a b l a l 8 5 4 2 1 4 6 8 4 a c e 5 2 2 4 3 9 6 8 4 a l 4 5 e 6 2 5 0 5 2 3 3 0 x b 0 1 7 8 3 c d c 2 2 b l f 8 3 d d 9 7 f 6 6 9 4 8 5 f d 0 7 f 0 8 8 0 4 e 3 6 2 4 0 9 2 6 5 3 7 6
0x483cl601b9c4c04cc24... 0 x d a b l a l 8 5 4 2 1 4 6 8 4 a c e 5 2 2 4 3 9 6 8 4 a l 4 5 e 6 2 5 0 5 2 3 3 0 x f 8 e 6 0 2 6 1 d l l 2 7 9 5 7 e 5 8 b 7 8 d 7 3 9 a f d 6 9 0 d 6 9 c 3 1 4 0 2 4 0 9 2 6 5 3 7 6
0x74c4583617b92aea09... 0 x d a b l a l 8 5 4 2 1 4 6 8 4 a c e 5 2 2 4 3 9 6 8 4 a l 4 5 e 6 2 5 0 5 2 3 3 0x636fb3af4d211fa38dbb40ab735e8bdc4d4ff6f8 2 4 0 9 2 6 5 3 7 6
0x58d069592baac3f4bl3... 0x636fb3af4d211fa38dbb40ab735e8bdc4d4ff6f8 0 x 9 8 a a 4 4 2 c e f c a f 0 a 7 2 7 7 d l 0 8 8 9 d 0 7 d 0 4 e 9 0 b 3 7 e a 5 2 4 0 9 2 6 5 3 7 6
0xbl60983680b548dbf4... 0 x f 8 e 6 0 2 6 1 d l l 2 7 9 5 7 e 5 8 b 7 8 d 7 3 9 a f d 6 9 0 d 6 9 c 3 1 4 0 0 x 9 8 a a 4 4 2 c e f c a f 0 a 7 2 7 7 d l 0 8 8 9 d 0 7 d 0 4 e 9 0 b 3 7 e a 5 2 4 0 9 2 6 5 3 7 6
Figure 3.2: Collected transactions w i t h the same priority fee
different addresses. A l l three transactions were processed i n the same
block. Two transactions were sent to accounts that later, i n 24 minutes,
sent transactions to the same account. N o t only they used the same
priority fee, but they also used the same addresses. Therefore, we are
100% sure that these addresses belong to the same user.
We believe that situation shown i n Figure 3.3 shows precisely what
Transaction Hash Sender address Priority Fee
0xb0d4c62e5537253f9eab23def93910625dbdca349b8.. 0xcl2fb30cabbe5af3cl79eb5ac3e71613a956e7a4 5134698068
0x7f860ccbdde6e9a08fbcf7a65574dla9fd40ba285ecb.. 0xcl2fb30cabbe5af3cl79eb5ac3e71613a956e7a4 5134698068
0x3905dc6eaaa70elb4f6e6240a64773c2fl5597eaaa5... 0xcl2fb30cabbe5af3cl79eb5ac3e71613a956e7a4 5134698068
0x7f327d76847eed911e3396779fd267fd5a068ddle0e6. 0x0e743ale37d691d8e52f7036375f3dl48b4116ba 5134698068
0x0ca8f2ff2ad0d81ff80b7c8a2259e0bee6c7aeeeb8cl. 0x0e743ale37d691d8e52f7036375f3dl48b4116ba 5134698068
0x60481346973659el45659b7440c076a61b7e80e956... 0x0e743ale37d691d8e52f7036375f3dl48b4116ba 5134698068
0x20d45f91fc8eda2e76742f5c321dfaf987afle88bdfb... 0x0e743ale37d691d8e52f7036375f3dl48b4116ba 5134698068
0x60db319094a0dfef2327bb0flfa7044910ddd32071... 0x0e743ale37d691d8e52f7036375f3dl48b4116ba 5134698068
Figure 3.3: Several transactions from the same accounts
this attack can do. In a situation where several transactions are sent
from one address and several transactions from another, while all the
transactions share the priority fee can easily show that these addresses
have the same owner.
Later we found several transactions w i t h the same priority fee
shown i n Figure 3.4. We discovered that every transaction was sent to
one of the six smart contracts i n approximately seven minutes. The
developers of the contract were probably doing some tests. We found
such situations quite often.
50
3. A N O N Y M I T Y I N E T H E R U E M
Transaction Hash Sender address Priority Fee
0x9fl8c719e29dl608fc34170ecdc... 0xff49da25833b4b3aa0609fe6ea805841c7d68208 2750142835
0xd8bd5933a40b74d95b8f39306ca... 0xab526ed216f8be94e22ce7184a92d5fc8ecl9785 2750142835
0x6fb29fe3dcblcd9b69ba3ae413b... 0x75a4be06fal71ea71c05d06ffcf33aaf6dal3fff 2750142835
0x947b91f6ba43eb06e89cdb4572b ... 0x0a8cdaeb3ae5e53aeafef22b662b215a8f3c8806 2750142835
0xlcledd65ce099fdc91f0cbe35334... 0xl4c72a9188ealda4dl69a0d9850d714565d3b3af 2750142835
0x6d53d827ac7f33a48cc9613cbdl... 0xf5ab7b963511576a852792fdcb950c5ae614c54c 2750142835
0xc2be31838f33cc0cl87514b6d93... 0x3958535b7580229826daaacd706e38a28ba32a78 2750142835
0x768bce06aa714886a08b437168... 0xflcc274d3ecd66dedefbc6ed29blef57b3427e25 2750142835
0xf5eb0166711937b3e6f741a8c42... 0xl50b9086853bb27al931d8719ec52cl967170fc9 2750142835
0xdab0ca9ce5454d9a03a312df3c... 0x27bebe499fl7aalbflbc9bcfaflaba737e585742 2750142835
0x5da4d344deale83a9a7a2b68376... 0xe8d9620e29fb28d03fc4dl32fe786170289ca4cb 2750142835
0xl6e65a003alcdb93b08567f080c... 0x29a367a0ae0538c0431f53657ed543ab48fde5fe 2750142835
0xelala3d5726dde92a3cfl875d03... 0xla933cc05b5dc00da722717a05456b6faa621997 2750142835
0x775791a0cf8c6af2a057586afle... 0x7bf903a7b2fc562e0487ff5f0cf94f446e092306 2750142835
0x6c71e985a01d48fal99b67e8dd2... 0x95524a207e96d6adbeea5bde6125f9d84c0bf56f 2750142835
0x3d80968e603d96175fd507facc4... 0xlc60a2cc2bdc94d001229a6ec34b350cc61f21c2 2750142835
0x5ae2el8e082373f8c7757392e8f... 0xe83b512alad48a603df972c74b22cb325f2683e7 2750142835
0xba0979469ef6b6d8b40e3fca92... 0xd698db27e4fl642239b58d9ac5f8e223592ffbf8 2750142835
0xc551de397c0f34ddfc7f89b97d00... 0x22bb8b9e32d0af8c774ba43e27b3567ad6947499 2750142835
0x0d651712c4db5acca70d74c34ef... 0x656fllfc4cd0818cb31el661e5e5ca80134b5e9f 2750142835
0x67ea9f3d59924005a70e01b7d25.. 0x6338fa4588a5b203218ba49ed5300a099fbed25f 2750142835
0x4584bccd6694836b713321f5dde... 0x2cb972e8f73a6218b91178612b7eldb09d261442 2750142835
0x692542b0d012150c8314b03dcb... 0x3d4e4dbf99af9aa68943ddb5ab4e38f97eef6163 2750142835
0x2b87d58cl20d7cf71c80f01296f... 0x7859ff009a5645al960d725649da732d3217bbd2 2750142835
0x7592d35a334e2567a3cf67945e4.. 0xd9727827751534d93f2588b4039a02ada6906a6f 2750142835
0x6a347ffddcd84cb5edf8079004f.. 0xfc8adb833aa3020004c59f322e3c7b89e5ee3a64 2750142835
Figure 3.4: Transactions from many accounts i n a short time
5 1
3. A N O N Y M I T Y I N E T H E R U E M
The evaluation performed o n the Goerli testnet showed that such
an attack can be successful. Therefore, we collected transactions w i t h
the suspicious priority fees from 200 blocks on the Ethereum mainnet.
The script found more than 1300 transactions. The results were much
better than we expected. A t the beginning of the sorted file, we could
easily find several cases with the transactions having the same priority
fee (see Figure 3.5). Mainnet provides more such transactions than
Transaction Hash Sender addreBB Priority Fee
Oxefl l b a b05 8b e d 7 069 d 89 8a b b d 7 f062d cf8a 367a... C:.:=2_';=7-5=7-_5i2';5Ccl2c5 5"5 551i;i
C-s7-i
c7 21120CCCCC
0xc4b0d4221c9104185684e 3d4096a4386094e 80b... 0xl51b381C5Sf9:cfS7:.57.5a:.5e83c45326f61e96d 2112000000
Oxe d c32a 1 if445a a d c7 Scl 3 3 c42c0b a 847 9 2d 2281... Ox 15 lb 3 8105 8f9 lcf871e 7e a l e e 83 c45 3 26f 61e 9 6d 2112CCCCCC
0x34861d Ofccf2027 6aOfd c2c6a 634df2d d [O6b05.... Ox 9 63 73 7c5 5 C e 7C ffe4d 5 9464542a 2S604e d b 2e f9 a 2112000000
0x4b43d9432f020a9bd239951b0838a7f5279Sa90... 0x8216874887415 e 265 0dl2d5 3 ff5 3516f04a74fd 7 2121000000
0xlc42b Oa 114c03 7 7 c64b4b 9 ffb b 25 3 siod 1817 8a... 0xl51b3ElC5Ef91cfE71*7*aliiE3c-5 326f61e96d 21270CCCCC
Oxblcc792328f2e cc4a d 20580d 3 a 19 9 d 5 6b07 6f 2c... 0xl4-98ca59a2olCClddCoaCS2c9ci3foa75f2CC5a4 213400CCCC
Ox6f4Sfdabcc7ljce067ccc323 339:3 3S41059 346a9... 0xf3f917f»66fi;C»7;;:»«T*;;*eirc;eSrS;ic:S 2143604399
0x5 lb d9bOdb50afSc54dSb41f7119f iff 53d 646a d i... 0x33adc71343c2ad b836cd835C96385034ba 333033 2143604399
0x565be d4f bbd d 6c2b2a c7bc4cf7f 6d 22d 1715811... 0x7058b690aa202aa40e 7c6089a 314dfb3 31feS3ee 2143604399
0xl58b9b3ad5alefdf; '26da97... Dx949e0c39f2«^c«>:«CcSc:C:CcCoc'««2a31D5122 2143604399
0x7251059919312a 57a4fa ef a910b87896cd 6d 6f 5 ... 2143604399
... 0x73 Saf6903e6c4e699d lC2dd9B bSb67fcd b3121e a 2144512204
... Ox f 16e9bOd0347O827a9Ocdfd0cb8aSa3b46969b91 2144512204
... Ox f 16e9bOd03470827a9ScdfdOcbSaSa3b46969b91 2144512204
0x3549fbdO3a4B8beO04cf4d 371d 3d087206c83e 6... Ox f 16e9bOd03470827aSScdfdOcb8a8a3b4e969b91 2144512204
... 0xcad621da75a66c7a Sf4ff86d30a2bf981bfc8fd d 2144512204
... 0xec3OdO2flO353f8efc96O13 71f56e80S751f3 96f 2144512204
OxOcd 3198119 7c9d af6bcce a dSS975be 6blc7 e a 7 9... 0xfl6e9b0d03470827a95cdfd0cb8a8a3b46969b91 2148974581
0xcb6c46cbf7603b8e d 14C9 71500fl7a0652ee773... 0xfl6e9b0d03470827a95cdfd0cb8aSa3b46969b91 2148974581
Ox4b4a330ac31c5f25 3d471a59e06f69902f05ed8 ... 0xfl6e9b0d03470S27a95cdfd0cbSaSa3b46969b91 2148974581
0xa831774f4d97 ca93fbbdl9 d04e0f6a d9a biffc7 c... 0xfl6e9b0d03470S27a95cdfd0cbSaSa3b46969b91 2148974581
Oxd 73d ca l e 6e d a04b340e Ofcff9 3 d 2013 lb S6d d4b... 0xcad621da75a66c7a3f4ff36d30a2bf981bfc8fdd 2148974581
Oxlb8f8c44d761bc5S029acccfl7bdf2cc28c45de... Dxcad621da75a66c7a3f4ff36d3Ca2bf981bfcSfdd 2148974581
0x9 b d 9 2f 2d e b 59 Id 17 IdSle e e9 d023 e a4862b 05 c ... 0xe5Se5ed4544f5BB31aS4clE17E0911a5957adaCE 2159228237
Oxf 9 S626e e459 5 5 3 6e la8a af C62b4bl9 5 3 70e 5 6b 1... 0x75bcd3c99d9i:*S*a5i:3b0298cf2db409c8a9790a 2159228237
Figure 3.5: Transactions collected from the Etheruem mainnet
Goerli testnet. We believe that the best results are shown i n the transactions
collected from a short time period, at a m a x i m u m of one day.
When several transactions are sent from one account and then several
more from another w i t h the same priority fee i n a a short time, such
as 2 hours. We can be almost 100% sure that these accounts have the
same owner w h o just changed them while keeping the same priority
fee. However, w h e n there are transactions from one account and later
in the week more transactions from another account. W e cannot say
these accounts have the same owner; someone else could choose the
same priority charge. Unfortunately, we cannot provide exact results
for this heuristic because we need to know the ground truth. Although
we can create accounts and send transactions on the testnet, this data
52
3- A N O N Y M I T Y I N E T H E R U E M
is skewed and does not represent real-world data. Nevertheless, we
believe such a heuristic can easily link accounts of the same user.
53
4 Metamask
In this section, we w i l l focus on the Ethereum digital wallet Metamask,
w h i c h is currently the most w i d e l y used Ethereum wallet. We w i l l
briefly describe its functionality, security and privacy concerns, and
communication w i t h a node. We also propose a deanonymization
attack.
4.1 Functionality
Metamask is a non-custodial Ethereum hot wallet1
currently available
as a browser extension and mobile app. Non-custodial, meaning data
is not stored on a central database, and the company does not collect
user information from wallet use. It is compatible with Chrome, Brave,
Firefox browsers, and iOS and A n d r o i d phones. It allows users to
store and transact Ether and Ethereum tokens like U S D C o i n and
Dai. MetaMask also supports the Binance B N B blockchain, Avalanche,
Polygon, and various other test networks. Users can connect to many
d A p p s , marketplaces, and exchanges v i a Metamask. A c c o r d i n g to
the newest data [76], there are more than 21 million monthly active
users of Metamask. Its popularity is achieved by easy availability and
usability. It can be easily installed in any of the supported browsers as
an extension. Once installed, the user can import any existing wallet
using the 12-word seed phrase or create a n e w one. Creating a n e w
wallet account is straightforward. The user chooses at least an eight
characters long password, w h i c h is used for wallet unlocking. Then
the system provides a 12-word secret recovery phrase that can be used
for wallet restoration i n case the password is lost or for importing
Metamask wallet on another device. A new account is automatically
created in the wallet. However, the user can create a new one, as there
are no limitations for m a x i m u m accounts i n one wallet. A n already
existing account can also be added to the wallet w i t h the account's
private key. Funds i n the wallet can be quickly sent to any Ethereum
address. Metamask also provides functionality for transfer between
the accounts i n the wallet [77].
1. A hot wallet is a wallet connected to the Internet. O n the other hand, a wallet
that is kept offline is a cold wallet [75].
5 4
4- M E T A M A S K
4.2 Security and privacy
Web-based wallets are assumed to be unsafe compared to other crypto
wallets. The security of cryptocurrencies in such a wallet can therefore
be questioned. However, since MetaMask's inception in 2016, the wallet
has yet to witness any significant setbacks or hacks. In many ways,
MetaMask's approach to security is through user anonymity rather
than traditional security measures. M e t a M a s k takes the topic of privacy
very seriously. Unlike a cryptocurrency exchange, the wallet does
not require users to submit any personally identifiable information to
get started. Because the software is non-custodial, MetaMask does not
keep any user data [78]. U p o n the wallet creation process, Metamask
ensures its users that no personal information is being collected [77].
The message is s h o w n i n Figure 4.1. Nevertheless, according to the
Help us improve MetaMask
Meta Mask would like to gather usage data to better understand hiow our users interact with the
extension. This data will be used to continually improve the usability and user experience of our
productond the Ethereum ecosystem.
MetaMask will..
^ Always allow you to opt-out via Settings
Send anonymized click & pageview everts
* Never collect keys, addresses, transactions, balances, hashes, or any personal information
* Never collect yourfull IP address
X Never sell date for profit. Ever!
Figure 4.1: Metamask does not collect any data [77]
Metamask privacy policy, this statement is not wholly accurate. The
latest version of the privacy policy from 23.11.2022 raised concerns in
the community. It states, " W h e n y o u use Infura as your default R P C
provider i n MetaMask, Infura w i l l collect your IP address and your
Ethereum wallet address when you send a transaction [79]. A s Infura
is Metamask's default R P C provider, it significantly interferes w i t h
users' anonymity. Infura is one of the biggest node providers owned
by ConsenSys, Metamask's parent company. Metamask wallet has to
be connected to an R P C node since it is not directly connected to the
blockchain. Therefore, the wallet cannot send a transaction straight to
5 5
4- M E T A M A S K
the network. A transaction created i n the wallet is forwarded to the
connected node, w h i c h then broadcasts it to the network. Metamask
allows users to connect the wallet to other node providers or a node
running on localhost [77]. However, such a corresponding node can
also associate the transaction initiator IP w i t h the account. If a thirdparty
node is used, it can expose the user's identity, just like Infura.
Although it is possible to hide the IP using Tor or V P N , anonymity can
still be compromised. A l s o , installing additional add-ons to the Tor
Browser is not recommended for security reasons. W h e n the default
Infura nodes are used, the wallet automatically connects to one of the
available provider's nodes. It is a client-server TLS connection. It starts
with a T C P handshake followed by a TLS handshake. A l l the possible
attacks on the client-server T L S communication are also applicable
here. A n attacker can possibly impersonate a server, i.e., an R P C node.
Therefore, he receives all the requests f r o m the wallet. Nevertheless,
all the private keys are stored i n the wallet, and the node has no access.
For that reason, it cannot steal the resources stored i n the wallet [78].
4.2.1 Passwords
A user-generated password protects a wallet on a single device. A
12-word secret recovery phrase can be used for importing a wallet
to another device without k n o w i n g the password. Once the wallet
is imported w i t h the seed phrase, the user chooses a n e w password.
Technical support cannot help users recover their seed phrases. If a
user loses their password and seed phrase, they risk losing access to
their wallet forever. Metamask suggests the user keep the phrase i n a
password manager or on a piece of paper i n a secure location. Because
there is only one way to recover a single wallet across multiple devices,
it also makes M e t a M a s k susceptible to hacks, malware like banker
Trojans, social engineering attacks, and other cryptocurrency scams.
The seed phrase can also be brute-forced. If the attacker knows all
12 words but does not k n o w their order, he w o u l d need to perform
12! = 479001600 permutations to find the correct order. However, the
attacker should not be able to k n o w a single w o r d . Metamask uses
BIP39, the current industry best practice for generating seed phrases.
It contains 2048 words, and the number of possible combinations
is 20481 2
= 2 1 3 2
. Therefore, the phrase has 132 bits of security. It is
56
4- M E T A M A S K
approximately the same strength as all Bitcoin private keys, so experts
consider it sufficiently secure. Nevertheless, every wallet seed phrase
can be brute-forced i n some time. The attackers d o not a i m for a
concrete wallet. The goal is to try every combination of the words and
find any wallet w i t h Ether [77, 80].
4.3 Communication eavesdropping
A s mentioned, Metamask is not directly connected to the blockchain.
Therefore, any transaction is broadcasted f r o m the connected node.
Wallet communicates with the node via H T T P - R P C . Therefore, such a
node is often called a n R P C node. The connection between the node
and wallet is encrypted [77]. However, as w e are the device communicating
w i t h the node, w e can collect the S S L keys. W e set u p
mitmproxy [81], which collects SSL keys and provides U I to see inside
each H T T P request. These keys can also be imported to Wireshark
[82]. Wireshark enables us to see the difference between encrypted
and unencrypted H T T P communication. It also provides a detailed
structure of the captured packets. A l l the transactions and c o m m u nication
monitoring were performed o n the Goerli testnet. Testnets
provide Ethereum functionality without spending real money [83].
Goerli blockchain data can be seen i n Etherscan, currently, the most
widely used blockchain explorer [55].
4.3.1 Transaction sending
W h e n w e sent the transaction, the wallet called a method
eth_sendRawTransaction. This method submits a pre-signed transaction
for broadcast to the Ethereum network. The transaction is
signed o n the device b y the locally stored sender's private key. It
includes the signed transaction data such as sender, recipient, or
amount of Ether [84]. The request for this method is shown i n Listing
1. W h e n the R P C node contains the sender's private key, the
eth_sendTransaction method is used for transaction sending. Metamask
does not support this method because Infura does not store the
user's private key required to sign the transaction [85]. The response
of eth_sendRawTransaction, s h o w n i n Listing 2, includes a hash of
the created transaction.
57
4. M E T A M A S K
1 {
2 " i d " : 5841716388031,
3 "jsonrpc": "2.0",
4 "method": "eth_sendRawTransaction",
5 "params": [
6 "0x02f87005028459682f0084596a89e782520894edl890fb09f02c9a84
7 006493fc20af134d9d7252861b48eb57e00080c080a0f2a9d7e92del459
8 C50e0a6bc8887al0c255f51ee63edf2640bl5543a419f40d5a01f97f3bl
9 18de6el9cd5c559d74ada4a9cbbb82f5456f826c974dc6239c7dcd57"
10 ]
11 >
Listing 1: eth_sendRawTransaction request
1 {
2 " i d " : 5841716388031,
3 "jsonrpc": "2.0",
4 " r e s u l t " : "Oxdalefef977a05dlccd49349c9914604920cl7e0602eb4cl0
5 60e38a8d35444eb8"
6 }
Listing 2: eth_sendRawTransaction response
Once the transaction is sent, it must be included i n the block to
become valid. The wallet has to call the eth_getTransactionReceipt
method to see if the transaction is already valid. A s shown
i n Listing 3, the request contains the transaction hash f r o m the
eth_sendRawTransaction response. The method returns the receipt
of a transaction or n u l l for still pending transactions [86]. According
1 {
2 " i d " : 949096228969,
3 "jsonrpc": "2.0",
4 "method": "eth_getTransactionReceipt",
5 "params": [
6 "Oxdalefef977a05dlccd49349c9914604920cl7e0602eb4cl060e38a8d
7 35444eb8"
8 ]
9 }
Listing 3: eth_getTransactionReceipt request
58
4. M E T A M A S K
to the intercepted communication, the method is called every 20 seconds
until the response contains a transaction receipt. W h e n the wallet
receives a transaction confirmation, the transaction is complete. The
wallet no longer sends any transaction-related requests.
In our first transaction, the first call of this method was just one
second after eth_sendRawTransaction. However, our transaction still
needed to be included i n the block. Therefore, it responded w i t h
null. The second call response, shown i n Listing 4, already included a
transaction receipt object. Our other transactions showed that the time
distance between eth_sendRawTransaction a n d the first calling of
eth_getTransactionReceipt is not always one second. Nevertheless,
the time distance was always between 1 and 20 seconds. We could not
find any information about the timing i n the code. W h e n the method
responds w i t h n u l l , the next call is always after 20 seconds. Such
knowledge can be used i n eavesdropping described i n Section 4.4.3.
4.3.2 Other communications
In addition to transaction-related requests, Metamask can call a few
other methods. Since w e unlocked the wallet, it started regularly
calling four methods. Namely eth_getBalance, eth_getBlockNumber,
eth_getBlockByNumber, and e t h _ c a l l . The purpose of these methods
is not important. The important thing is that they are called even if no
transaction is sent. Therefore, w e were able to monitor this network
communication on the Ethereum mainnet. We collected approximately
500 calls of these methods i n 20 minutes. The IP address of the Infura
node was different every time w e opened the browser. W e collected
several nodes' IP addresses. A l l these addresses belong to the A m a z o n
Web Service (AWS) [87]. It does not surprise us, as Infura is estimated
to r u n between 25% and 50% of its nodes o n A W S . Currently,
around 67% of Ethereum nodes are hosted o n cloud services. 57% of
those hosted nodes use A W S [24]. There is one website for finding an
Ethereum node by IP address. Unfortunately, this site only contains
some nodes. Therefore we were not successful i n finding more information
about the collected nodes. Nevertheless, we found other nodes
probably from the same subnets. For example, we could not find any
info about a node w i t h the IP address 54.221.95.219. However, w e
found one w i t h the IP address 54.221.95.53. A s mentioned, we could
59
09
asuodsaj q.dieoeauoiq.o-BSUBJíq.eS Tiq.9 ß u j i s n
{ l £
{ 0£
„2xo„ : „ 9 d Á q „ 6z
' I I 0 T x
0 I I : „xapninoTq.o'BSTiBiq.,, 8z
' „ s q s ť ť ť g s p s ^ s e s o g o i s ť q s s o g o s a
ZT^OSôí'O^Teeaeí'Seí'PaaTPgO'BZZejsjsT'BPXOh :
„tis-BHtioTq.o-BstrBj:q.„ 9z
\s9szP6Pfreij*0S3je6fr900fr8*6320J60qj068ipsx0i. : „ o q „ sz
'nTx
0n :„STiqi2qs„ fz
' „000000000000000 K
000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000 K
000000000000000000000000000000000000000000000000000000000 oz
000000000000000000000000000000000000000000000000000000000 si
000000000000000000000000000000000000000000000000000000000 si
000000000000000000000000000000000000000000000000000000000 n
000000000000000000000000000000000000000000000000000000000 9i
000000000000000000000000000000000000000000000000000000000 si
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 X 0 „ : „niooiasSoi,, n
' [] :„sSoi„ a
'„80S9X0,, : „ p 9 S f i s T i S „ zi
'„=l
SP86^Pq88Zí'T^SJ0í'PSPZ99J6ZP9í'STJí'^0990X0h = »moji,, n
' l,Iťťq6969X0„ : „90TJc JS-B39ATq.09JJ9„ 01
'„popog^xo,, : „p9Sfis-B39ATq.-BxrLumo„ 6
'||nu : „ss9jppvq.o-Bjq.uoo,, 8
' „goTig-e^xo,, : „jaqnmippoT.q,, z
'„9OS08ZT89PS0Z98TJ3ZZ3 9
6J^J^Pq0Z990í'T9SST9ZS93q98qqS9Z3í'309Zq09Pí'X0„ : „qsBH^ooiq,, s
} : „ q x r L S 9 j „ »
'i,0"Sh :„odjtiosC„ £
'6968229606*6 :..PT.. z
>
1
4. M E T A M A S K
see all the communication also i n Wireshark i n unencrypted form.
However, we could not see any private keys or the wallet password.
4.4 Possible attack
A n eavesdropper without the SSL keys can see only the encrypted
communication. Provided he has the knowledge of Infura nodes' IP addresses.
Then, he can quickly notice ongoing communication between
the user's wallet and Infura.
Another more accessible option to detect communication w i t h an
Infura node is to check the server name i n the Client Hello packet.
The communication w i t h the node always starts the same (see 4.2).
Metamask begins the T C P handshake, after which it sends Client Hello
Time Source Destination Protocol Length Info
1 7 : 4 7 : 55, 4 9 4 8 3 8 1 9 2 . I B S . 0 . 1 3 5 2 . 7 1 . 1 4 0 . 1 9 TCP 86 5 2 5 9 4 -+ 4 4 3 [ S Y N ] Seq =2
1 7 : 4 7 : 35, 513913 5 2 . 7 1 . 1 4 & . 1 9 1 9 2 . I B B . 0 . 1 3 TCP 86 4 4 3 •* 5 2 5 9 4 ; S Y N , ACK]
1 7 : 4 7 : 33, 513973 1 9 2 . I B S . 0 . 1 3 5 2 . 7 1 , 1 4 9 , 1 9 TCP 3^ 5 2 5 9 4 -» 4 4 3 [ACK] Seq =1
1 7 : 4 7 : 33, 5 3 1 3 1 S 1 9 2 . I B S . 0 . 1 3 5 2 . 7 1 , 1 4 9 , 1 9 T L S v l . 2 332 C l i e n t Hello
1 7 : 4 7 : 33, 6 4 1 3 3 5 5 2 . 7 1 . 1 4 9 . 1 9 1 9 2 . I B B . 0 . 1 3 TCP 36 4 4 3 •+ 5 2 5 9 4 [ACK] Seq =1
1 7 : 4 7 : 33, 6 4 4 2 4 1 5 2 . 7 1 . 1 4 9 , 1 9 1 9 2 . 1 8 8 . 9 . 1 3 T _ S v l . 2 2 8 9 4 Server Hello
Figure 4.2: Start of the communication w i t h a node
to the Infura node. This packet contains the server name s h o w n i n
Figure 4.3. The server then responds with a Server Hello packet. W h e n
v
E x t e n s i o n : server_name (len=21)
T y p e : s e r v e r _ n a n e (&)
Length: 21
v
S e r v e r Name I n d i c a t i o n e x t e n s i o n
S e r v e r Name l i s t l e n g t h : 19
S e r v e r Name Type: host_name (9)
S e r v e r Name l e n g t h : 16
S e r v e r Name: g o e r l i . i n f u r a , i o
Figure 4.3: Server name from the packet
Metamask connects to the Ethereum mainnet, the server name is mainnet.infura.io.
Knowing there is such communication w i t h the node's IP
address, a deanonymization attack based on packet eavesdropping
can be performed.
61
4. M E T A M A S K
4.4.1 Packet analysis of eth_sendRawTransaction
We executed several transactions to capture a representative set of
packets w i t h this request. The complete packet that carries this request
is shown i n Figure 4.4. The red rectangle represents data everyone
Frame 417: 446 bytes on wire (3568 b i t s ) , 446 bytes captured (3568 bits)
or interface \Device\NPF_{B4503C7B-ACB6-49B3-B8C6-CCEE3E011701}, i d 0
> Ethernet I I , Src: HonHaiPr_6f:7S:f7 (40:49:0f:6f:78:f7), Dst: CompalBr_al:6S:be (ac:22:05:al:6S:be)
Internet Protocol Version 4, Src: 192.16S.0.13, Dst: 52.71.140.19
> Transmission Control Protocol, Src Port: 52594, Dst Port: 443, Seq: 59S0, Ack: 13488, Len: 392
^ Transport Layer Security
v TLSvl.2 Record Layer: Application Data Protocol: http2
Content Type: Application Data (23)
Version: TLS 1.2 (0x0303)
Length: 349
Encrypted Application Data : 698d87a8180d6817666d5550e657cb665be6d05f223de7fc6bf39269d250e8cf...
[Application Data Protocol: http2]
v TLSvl.2 Record Layer: Application Data Protocol: http2
Content Type: Application Data (23)
Version: TLS 1.2 (BxB3B3)
Length: 33
Encrypted Application Data: 698d87a8189d6818af368c74385179895e53b386aB211aaa287c8e2c8f48b6c59f
^ ^ ^ ^ ^ ^ ^ g g l ^ a ^ ^ n ^ a ^ a ^ r ^ o c o l ^ T ^ D ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
v
HyperText Transfer Protocol 2
S--ear: CAT A, S--ear ID: 35, _ength 316 rpa^-iaL entity body)
v
HyperText Transfer Protocol 2
> Stream: DATA, Stream ID: 35, Length 0
v
JavaScript Object Notation: application/json
v object
> Member: i d
> Member: jsonrpc
v
Member: method
[Path with value: /method:eth_sendRawTransaction]
[Member with value: method:eth_sendRawTransaction]
String value: eth_sendRawTransaction
Key: nethcd
[Path: /method]
> Member: params
Figure 4.4: Packet structure with the eth_sendRawTransaction request
without the SSL keys can see. Every captured packet has the same
structure. It contains two T L S v l . 2 records. In 90% of the packets, both
records carry HTTP2. In the rest, HTTP-over-TLS (HTTPS). The length
of the first record is mostly 349. Approximately 20% of our captured
records had a length of 347. In any case, all possible lengths must be
taken into account. The second record always has a length of 33. We
discovered that every record that carries J S O N with an eth method has
such a length. We found several other packets with the same structure.
Nevertheless, none of them have a similar size of the first T L S v l . 2
record. For example, the record size i n a packet w i t h the method
eth_getBlockNumber is around 111. We believe that the structure w i t h
62
4. M E T A M A S K
the length of the records is sufficient to distinguish this packet i n the
Metamask communication.
4.4.2 Packet analysis of eth_getTransactionReceipt
We used the same communications to capture packets with this request.
The part of the packet visible for everyone is shown i n 4.5. The part of
Frame 662: 518 bytes on wire (4144 bits), 518 bytes captured (4144 bits)
on interface \Dei/ice\MPF {B4593C7B-ACB6-49B3-B8C6-CCEE3E911791}, i d 9
> Ethernet I I , Src: HonHaiPrSf:7B:f7 (40:49:0f:6f:7S:f7), Dst: CompalBr_al:68:be (ac:22:05:al:6B:be)
> Internet Protocol Version 4, Src: 192.168.0.13, Dst: 5Z.71.140.19
Transmission Control Protocol, Src Port: 52594, Dst Port: 443, Seq : 9253, Ack: 2S520, Len: 464
v
Transport Layer Security
v TLSvl.2 Record Layer: Application Data Protocol: http2
Content Type: Application Data (23)
Version: TLS 1.2 (0x0303)
Length: 132
Encrypted Application Data: 69SdS7a8180d6S3b9S1699aefeda97c9371b9cc233f54cdc35925aaeb7f61935c33f267c...
[Application Data Protocol: http2]
v TLSvl.2 Record Layer: Application Data Protocol: http2
Content Type: Application Data (23)
Version: TLS 1.2 (0x0303)
Length: 33
Encrypted Application Data: 698d87a8180d683cd843d29edec6c9bl2d35907843476b3b48349eB7f3323731df
[Application Data Protocol: http2]
v TLSvl.2 Record Layer: Application Data Protocol: http2
Content Type: Application Data (23)
Version: TLS 1.2 (0x0303)
Length: 56
Encrypted Application Data: 698d87a8180d683deb2df53ba7690dal59fdb381587c33dl4fb99c28b8dl8057fd053777...
[Application Data Protocol: http2]
v TLSvl.2 Record Layer: Application Data Protocol: http2
Content Type: Application Data (23)
Version: TLS 1.2 (0x0303)
Length: 185
Encrypted Application Data: 698d87a8189d683e7e9d635939b21694d964a45ab97c519c36c94d513d6c792741del269...
[Application Data Protocol: http2]
v TLSvl.2 Record Layer: Application Data Protocol: http2
Content Type: Application Data (23)
Version: TLS 1.2 (0x0303)
Length: 33
Encrypted Application Data: 698d87a8189d683fb9b48f7d563fCacc961d9c99645e9a3a9fabl39e79596bffbl
[Application Data Protocol: http21
Figure 4.5: Packet structure w i t h the eth_getTransactionReceipt re-
quest
the packet visible only w i t h the SSL keys is shown i n Figure 4.6.
Every captured packet has the same structure. It contains five
TLSvl.2 records. A s for eth_sendRawTransaction, 90% of the packets,
the records carry H T T P 2 . This packet always carries two requests,
eth_getBlockByNumber, a n d eth_getTransactionReceipt. The former
is included i n the second record, the latter i n the last one. Therefore
both records have the same length, 33. We found several packets with
this structure. For that reason, we must distinguish this packet according
to the remaining three records. The third record always carries
63
4. M E T A M A S K
headers w h e n there are five records i n the packet. Its length is not
related to the methods. Hence, this record does not help us. The first
v
HyperText Transfer P r o t o c o l 2
> Stream: DATA., Stream ID: S9, Length 99 ( p a r t i a l e n t i t y body)
v
HyperText Transfer P r o t o c o l 2
Stream: DATA, Stream ID: *9a
Length 9
v
J a v a S c r i p t Object Notation: a p p l i c a t i o n / j s o n
v Object
> Member: i d
> Member: jsonrpc
v
Member: method
[Path ivith value: /method:eth_getBlockByNumber]
[Member with value: method:eth_getBlockByNumber]
S t r i n g value: eth_getBlockByNuiriber
Key: method
[Path: /method]
> Member: params
v
HyperText Transfer P r o t o c o l 2.
> Stream: HEADERS, Stream ID: 61, Length 23, POST /v3/9aa3d95b3bc44&faSSeal2eaa4456161
v
HyperText Transfer P r o t o c o l 2.
Stream: DATA, Stream ID: 61, Length 152 ( p a r t i a l e n t i t y body)
v
HyperText Transfer P r o t o c o l 2
> Stream: DATA., Stream ID: 61, Length &
v
J a v a S c r i p t Object Notation: a p p l i c a t i o n / j s o n
v
Object
> Member: i d
> Member: jsonrpc
v
."-".eiTbe': frethcd
[Path tvith value: /method: eth_get Trans act ion Receipt ]
[Member with value: method:eth_getTransactionReceipt]
S t r i n g value: eth_getTransactionReceipt
Key: method
[Path: /method]
> Member: params
Figure 4.6: Decrypted part of the packet
record is correlated w i t h the second one. W h e n the second contains
eth_getBlockByNumber. The length of the first is always 132. W e d i d
not find a record where it was different. O n the other hand, if there is
another method i n the second record. The length of the first one is entirely
different. According to the first two records, we can be sure that
eth_getBlockByNumber is i n the packet. Still, this request can be i n the
packet w i t h any other request, not just eth_getTransactionReceipt.
We discovered that the length of the fourth record is always 186 or
185. N o other packet contains a record w i t h such length. Hence, w e
can believe this packet contains eth_getTransactionReceipt.
64
4- M E T A M A S K
4.4.3 Transaction time interval
Although the attacker cannot decrypt the communication i n such an attack,
the packets containing eth_sendRawTransaction or
eth_getTransactionReceipt requests can be distinguished from the
rest. If the attacker knows the timestamps of both requests, he also
knows the time interval when the transaction was added to the blockchain.
In our captured communication, the timestamp of the
eth_sendRawTransaction request is 17:48:20. The timestamp of the
first eth_getTransactionReceipt request is 17:48:22. However, at this
time, the transaction still needed to be validated. For that reason, the
transaction validation must be after 17:48:22. The second request for
transaction receipt happened at 17:48:42. This was the last transactionrelated
request. Therefore, the transaction was added to the blockchain
before 17:48:42. These two timestamps create a 20-second interval of
the transaction validation. 20-second time interval is the longest possible.
O u r transaction is s h o w n i n Figure 4.7. A s w e can see, it was
processed at 16:48:36. The transaction's timestamp is i n the U T C timezone.
Therefore it is an hour earlier. A n attacker k n o w i n g this time
[This is a Goerli Testnettransaction only ]
J_ Transaction Hash: Oxdal efef977a05d 1 Ccd49349c9914604920C17e0602eb4c1060e3Sa8<135444eb8 ID
© Status: O Success
© Block: Q 8010627 31096 Slock Confirmations
© Timestamp: © 13 days 2 hrs ago (Nov-25-2022 04:48:36 PIA +UTC)
© From 0x0e60aa4f1245d79f6e7d2d40f2a14788bda98d2c IP
©To: 0xed1890fS09f02c9a84006493rc20af134d9d7252 (D
© Value: 0.00003 Etrier ($0.00)
© Transaction Fee: 0.000031502092629 Etiier (JO.00)
© Gas Price: 0.000000001500099649 Ether (1.500099549 Gwei)
Figure 4.7: Transaction shown i n Etherscan
interval, can search for all transactions performed i n these 20 seconds.
The anonymity set is equal to the number of transactions i n the such interval.
A new block is created every 12 seconds. Maximally, two blocks
65
4- M E T A M A S K
can be added to the blockchain i n 20 seconds. Each block contains
a m a x i m u m of 380 transactions. Therefore a 20-second interval can
include at most 760 transactions. However, each block can contain also
contract internal transactions that can be excluded [12]. According to
Ether scan, a block rarely contains more than 200 transactions. For that
reason, the anonymity set usually equals approximately 400.
A l t h o u g h such a n attack does not show w h i c h transaction was
sent from our IP address, it massively reduces the anonymity set. The
block w i t h our transaction contains only 46 transactions. The block
before had only 12 transactions. Therefore, the anonymity set is equal
to 58. It can be reduced even more when another transaction from the
same account and IP address is sent. The n e w anonymity set is an
intersection of all sender accounts from two captured time intervals
(see Figure 4.8). Ideally, the intersection is just one account. In such
Figure 4.8: Intersection of two time intervals
a case, the account is w h o l l y deanonymized. This fact confirms the
rule of reusing the same account. The key to such an attack lies i n
identifying these two requests i n the network communication.
4.4.4 Attack implementation
We created a short python script using pyshark to evaluate the success
of our analysis (see Attachment A.2). The script loads the pcap file
66
4. M E T A M A S K
and searches for packets containing Client Hello. If the server name
in this packet is goerli.infura.io, it stores the IP addresses of the client
and server. If not, it ends w i t h the message that n o T L S handshake
was f o u n d between the Metamask and Infura node. If yes, it filters
only the T L S communication between these two IP addresses. The
script searches for packets w i t h two T L S layers, w h i c h is significant
for a packet w i t h the eth_sendRawTransaction method. It checks the
length of both TLS layers. If the lengths match our analysis (see Figure
4.4), the script considers it a packet w i t h eth_sendRawTransaction
and stores its timestamp.
Then it searches for packets w i t h five T L S layers, w h i c h is significant
for a packet w i t h the eth_getTransactionReceipt method. It
checks the length of each T L S layer. If the lengths match
our analysis (see Figure 4.5), the script considers it a packet w i t h
eth_getTransactionReceipt and stores its timestamp. There can be
several packets w i t h this method. The script then calculates the 20second
time interval using the captured timestamps. The results for
our analysis are listed (see Figure 4.9).
Communication with Irrfura nods, IP: 5 2 . 7 1 . 1 4 3 . 1 9
Found transaction time: 2322-11-25 1 7 : 4 8 : 2 3 . 9 3 2 7 3 3
1 Found Receipt time: 2322-11-25 1 7 : 4 3 : 2 2 . 3 2 4 3 5 7
2 Found Receipt time: 2322-11-25 1 7 : 4 3 : 4 2 . 4 1 6 5 7 7
The interval of the transaction - Start: 2322-11-25 1 7 : 4 3 : 2 2 . 3 2 4 3 5 7 End: 2322-11-25 1 7 : 4 3 : 4 2 . 4 1 6 5 7 7
Figure 4.9: Example script results for Metamask wallet
We r a n the script o n 20 pcap files, each having one call of
eth_sendRawTransaction a n d one or more calls of
eth_getTransactionReceipt. O u r script successfully f o u n d all the
packets that include one of the methods. It has 100% accuracy w i t h
no false positives and false negatives. Using the packets' timestamps,
we created a 20 seconds interval for every transaction. A l l the transactions
were sent f r o m the same account. The intersection of every
two intervals was always only our account. We got lucky, as no other
sender account was i n our intervals more than once. A l t h o u g h this
script is simple, it provides enough information that a similar attack
is possible. The script can be improved i n many ways. W i t h minor
changes can such a script monitor live communication.
67
5 Go Ethereum
G o Ethereum (Geth) is currently the most w i d e l y used execution
client. M o r e than 77% of Ethereum nodes use this client [24]. It is
suitable for running full and also light nodes. In this chapter, we w i l l
work on a network interception to see what anonymity disclosure can
be seen i n communication between the nodes.
5.1 Dissecting Node Discovery v4
Although the encrypted Node Discovery v5 is already i n use i n the consensus
clients, the older version is still used i n Geth. A s we described
in Section 2.2, this version is unencrypted. Therefore, an eavesdropper
can easily read all the communication. We used a dissector created
by Consensys [88] to see the packets i n the human-readable form. It
parses all the messages. The discovery process of the execution client
is the same for light and full nodes. By default, this protocol runs on
port 30303. Geth uses a bootstrapping mechanism to connect to a small
set of bootnodes, w h i c h are hardcoded into the code. Once the client
starts, it automatically begins the connection w i t h these bootnodes.
The whole Node discovery communication with a bootnode is shown
in Figure 5.1. Bootnode's only responsibility is introducing a new node
12? 16: 33 22,866363 192.168.9.13 52.187.2B7.27 DEVP2P 176 3B393 -> 39393 Len-134 [PING)
133 16: 33 : 23,13147252.187.297.27 192.168.9.13 DEVP2P 199 3B383 -> 39393 Len=157 (PONG)
133 16:53::23,652783 192.168.9.13 52.187.287.27 DEVP2P 213 3B3B3 -» 39393 Len=171 (FindNode)
133 16: 33 23,933897 52.187.297.27 192.16S.9.13 DEVP2P 1999 3B383 -> 39393 Len=1957 (Neighbors)
186 16: 33 23,933897 52.187.297.27 192.16S.9.13 DEVP2P 467 3B3B3 + 39393 Len=425 (Neighbors)
Figure 5.1: Node discovery communication w i t h a bootnode
to a set of peers. It is used only when the client is spun up for the first
time. The list of the bootnodes can be found i n the G i t H u b of Geth
[33, 89].
O u r node starts b y sending Ping to all the bootnodes. The Ping
packet is s h o w n i n Figure 5.2. W e can see that a Ping is sent f r o m
our node to the bootnode 52.182.207.27. It includes hashed information
about our node, the bootnode, and an expiry timestamp. The
contacted bootnode replies w i t h a Pong (see Figure 5.3). It includes a
hash of the Ping to w h i c h it replies. Since the Ping and Pong hashes
68
5. G o E T H E R E U M
> I n t e r n e t P r o t o c o l V e r s i o n 4, S r c : 192.168.8.13., Dst: 52,1S7,287.27
> Llser Datagram Protocol., S r c P o r t : 38383, Dst P o r t : 38383
v
Ethereum devp2p P r o t o c o l (PING)
Hash: 6elafbd5e5bale451956beS5d943fl57671Scbced3549962d2S9b41fc52fdS2c
Sign: 2d3352S4bcla668385d2S886S489c65f9134164e2&ecaf&13ba81fd37Scle5ca623ab5a3...
Type: PING (1)
Payload: e384cb847f99988182765fS2765fc9S434bbcflbS2765fS8846388ce96S68184ce647b39
v PING 52.1.87.287.27:38383
V e r s i o n : 64
From: "7f898881" 38383 38383
To: 52.187.287.27:38383
E x p i r a t i o n : 63S8ce86", "91S4ce647b39
Figure 5.2: Ping
match, the connection between our node and peer is verified. The
nodes are so-called bonded. Once bonded, our node sends a FindNode
> Internet P r o t o c o l Version 4, Src: 52.1S7.287.27, D s t : 192.16B.0.13
> J s e r Datagram P r o t o c o l j Src P o r t : 39383., Dst Port: 38393
v
Ethereum devp2p P r o t o c o l (PONG)
Hash: b278eb48113583c8d9799Ge94c25eal83b285cfcca62f7a9dfe9cfaeb4fb8273
Sign: 5Sf49c646aee39cdf7edabld9eac621cSfS94953aff9S18a7bafc29753cl4e7965672933„.
Type: PONS (2)
Payload: f839cbS459G6cf5982765f82765fa86elafbd5e5bale45195Gbe85d943fl576718cbced3.,.
v POMS 89.182.287.88:38383/38383
To: 89.192.297.89 39393 39393
Hash: 6elafbd5e5bale451956beS5d943fl576718cbced3549962d2S9b41fc52fdS2c
E x p i r a t i o n : 6388ce97", "91848624e822
Figure 5.3: Pong
request. To w h i c h the bootnode replies w i t h a Neighbours. It should
contain a list of 16 nodes. However, packets have a fixed size limit
of 1280 bytes m a x i m u m . For that reason, data is truncated into two
U D P packets [33]. A s s h o w n i n Figure 5.4, the first packet contains
information about 12 nodes. Our node then sends Ping to all the nodes
from Neighbours and repeat the same process w i t h each node. Once
bonded w i t h a n e w node, it starts a T C P connection, w h i c h includes
the R L P x handshake. W h e n the handshake is successfully done, the
nodes start exchanging blockchain data. The T C P connection is already
encrypted. Each node periodically sends Ping to their peers to see if
they are still active. A l t h o u g h this protocol does not serve for crucial
data exchange, it can help the attacker to get information about the
node's peers.
69
5. G o E T H E R E U M
Internet Protocol Version 4, Src: 52.1S7.207.27., Dst: 192.168.9.13
> User Datagram Protocol, Src Port: 36393., Dst Port: 30303
v
Ethereum aWp2p Protocol (Neighbors)
Hash: 72897747d72932f3eb59c34fd7e47415fc9c839bl6al79f9f4f76dee2b228c96
Sign: 3bae9fd82299892c9ffaflde7b79955e4c368d8bledbc887573c5f7d32e9141c785fc9d4...
Type: Neighbors (4)
Payload: f993bcf993b4fS4d844832c2c9827aacS27aacb84991125dl4e44f7dc22[:98f 14d484fe3...
v
Neighbors (12)
72.59.194.291:31494 31494
0U25dl4e44f7dc22c98fl4d484fe3cl679eeea2abdl99a99c989af694f6b212c9bl6322b4393c66d
d7a2749697eb992c6b6693657f3b99e43cc049f95962998
162.55.3.214:39304 39394
4999a349c6a7ca6645e2cb6985d4257c3S18a4cb56ed4al995512e32c9ac5a9da6ed3216933dl51e45a
9dc4ea93927fab9e795927683394d65ff7bf566d825f3
98.51.108.125:39393 39393
bc981fa462e96b4d9b93caf4e8d6e339alf7273c5e53f9fel645d96d7b48fffb97aa9a09d942ce5f78d85
a29d9694afleba4c7f355787b9f7f95c58fd57ble53
64.227.178.163:39393 39393
b45f51b49ee3d0965ba728Sle3c2522f289969e9bb2d44498b9a55e567826e64dll21aad429fd99acda5274
Iaf2231911a425ef5498afal6eefe483a69cell83
296,189,47,240:39393 39303
153466dda8f9e753b4aba467cfa64bcda4a71e54313979a2ec88e8854flefbc9734e2638916297a62699b22
932e27all54bb5cb3f5d369331461e93d887e399a
72.134.249.197:39303 39303
b9cc3a6fd7al9382bdce7e795fc69e4393b4a59493dl990eecalb373843d96e89ab2S8d79a37d48Se97475el849
72cd7893f4ab61a6c5e084clda64493532119
79.22.168.111:39493 39403
8bc72cclaab313fe48e5efb83fb5a832bc984acf8f76b4dde6c4349e94ac92984c2ale2c7f9997dc9179f25132d9
f949dld94el67S3979fbblaa619bS92cfe8a
118.299.239.133:39393 39393
C 9 e 4 6 d a b 8 4 4 1 b 0 7 9 1 9 b 6 6 9 7 4 6 c 4 9 c a f 5 e 9 c b d 3 9 5 1 f 3 3 4 5 e b 7 b 4 6 9 4 a 5 1 1 4 7 4 9 a c d l 8 9 6 9 e d a b 5 f c 9 9 f 3 c 5 7 d 3 1 b f c 2 a 2
97757a59d89bb7bll9b9b95992fe779fe9c
54.243.198.56:39393 39393
9cccbaae792d477c5fd4d794a2d6f92a99995f62de989bllb9d942877bf759774cf 7d68d35Sc59427622e87538bc
46afall95d6acl2cbl53d6771461cl839dlb
31.19.151.215:11235 39493
95692a67bd491aa87b7289fefc98989c074644929584b7b8abc5a5a728514ael6e9fl9997f3c3e3flea89aa2807e
e376cee493fc9alacca9926fcde3f9948f9b
64.25.199.144:39393
blf49ae5e7284e3cd9491ddbad932474e885a5dlc542959ecc379d3259fl692aab94f99c74839ed5b6cbc786439
629b272731dblac6b25c4293db492af
37.251.4.154:39393 39393
3d9afa843be99dfa682c94e94c447Sd5539cb0f9d894d931fc3c5c96bld9e9727bea924396d0f6ef2b7f6925ee81c
6fd6b3b93d4199239bd278a96381e8bl91e
Expiration: 388ce9
Figure 5.4: Neighbours
70
5- G o E T H E R E U M
5.2 Light node
As described i n Section 1.6.3, the light node is not directly connected to
the Ethereum blockchain. Instead, it is connected to the light servers.
Every communication with the blockchain, like transaction sending or
information about the last block, comes from such servers. Therefore,
the user has to rely on a third-party light server. This reliance is one
of the trust compromises that come with running a light node instead
of a full node. W h e n a new transaction is sent from the light node, it
sends a request to the light server via the l e s protocol. The light server
knowing the IP address and all the information about the transaction
can easily deanonymize the sender. Therefore, the light nodes do
not provide any anonymity. One w a y to increase privacy is to use a
V P N or Tor to mask the IP address. A s Tor is TCP-based, the node
discovery r u n n i n g on U D P cannot work. A user can solve this issue
by manually adding peers, w h i c h is allowed i n Geth. The light node
can be connected maximally to 50 light servers by default. Still, Geth
provides a function to change this value.
We ran a light node to see h o w it communicates w i t h the light
servers. To send the transaction without spending money, we ran it on
the Goerli testnet. Geth does not log any communication w i t h other
nodes. Therefore, we modified the Geth client to see w i t h w h o m our
light node communicates. We created a transaction f r o m our light
node using the R P C method, eth_sendTransactiori. According to the
logs (see Figure 5.5), the light node sends the transaction v i a l e s
INFO [12-B2116:39:26.853] Submitted t r a n s a c t i o n f rc[n=8xBe6BAA4fl245d79f6e7d2D40f2A14788bda98d2C
nonce=26 recip-leTt=Bx9c8297C688655859e6540Cdc526C629F26434a9E =58200
hash=0x7f6bcedd84aa41c40bdf678161e98ffB2dBdf72Bcca9a45491aeb4641b8e0478
INFO [12-02|16:39:26.857] LES - Sending t r a n s a c t i o n t o I==95.217.284.216
node=enr:-Kn4QElJFHSpZqesw_9RYjgXAcL-SVlGb9P8J^rCr6Zytu5EBTUW3TaLMmyH86K4ICT V3q
JUsol77AMb0rZPn2iFo2GAYLwAdn5g2V0aMfGhLjGKZ2AgrilkgnY0grilwhF_ZzNiDb&VzwQGJc2VjcDIl
NnsxoQKPHHbvZlBTnzwCJyKflnVpAU9oFBlgDfG5uwb95VGGRoRzbnFwwIN0Y3CCdnGDdWRwgnZh
INFO [12-B2116:39:20.858] LES - Sending t r a n s a c t i o n to I==65.1B8.132.230
node=enr: -Km4QHBoAjoiJY0ClyD0PlCr5l7EDXKg_lZyV9LpB3lMT8WAN0YvsJrMQpzzvDEM0vBJGey
Bgt5pWwo0ic3zCKFrt0z6GAYLv6WZpg2V0aMfGhLjGKZ2AgnlkgnY0gnlwhEFsh0aDbGVzwQGJc2VicDIl
NmsxoQLlsdux781g06t0Npxze07_CKe6IlHAKMRx3t5FrqzvFoRzbmFwwIN0Y3CCdriCDdMRwgnZg
INFO [12-B2|16:39:20.858] LES - Sending t r a n s a c t i o n t o I==64.71.153.62
Tode=enr:-Kri4()IhDc_T6AH72nYYre0PXZpkCNCwKnAnXYnztBfmc01NiZr_r2DeFfTGLP6Ylilx4Y3M
fXB8NxDSHYJ35Vn4oiaMGAYGCS5B9g2V0aMfGhLjGKZ2AgmlkgnY0gmlwhEBHmT6DbGVzwQG3c2VjcDI
lNnsxoQNFtVwHtQpgCdMp7G4nn-My-zWnaiT12RPFa7dOP4HSMIRzbmFwwINBY3CCdl-DdWRwgnZf
Figure 5.5: Transaction sent to three light servers
protocol to three light servers to be broadcasted. Three servers are
chosen to increase robustness. However, it threatens anonymity even
71
5. G o E T H E R E U M
more. The light servers are randomly chosen from the node's peers. If
the node is connected to fewer than four peers, it sends the transaction
to its only peers.
We also ran a light server on a different machine to see the communication
f r o m the other site. To make sure that the transaction is
sent to our light server. We manually removed all other connected
peers of our light node. Then we created a new transaction. In Figure
5.6, we can see that this transaction is sent only to one light server.
INFO [12-32|16:48:42.699] Submitted t r a n s a c t i o n =3x0e60AA4f1245d79f6e7d2D49f2A14788bda98d2C
nonce=33 rectpient=Bx9c8297C6B8655859e6540Cdc526C629F26434a9E value=15533
nas -I=0xd0eed85dfc99af633b5643acaa46b73244de9383379d8fb2172a83e43f63955c
[12-92 116:48:42.699] LES - Sending t r a n s a c t i o n to node=enode://206af6c963afe3707c76979bl63
88407ee456e9904abe98cb7e5a8af15f66be2eb88d9f3bl5bl922e8769e993blf73438b24759bf4973893e245b
a827dl86e8d@147.2S1.21.165:30333
Figure 5.6: Transaction sent to our light server
We edited the light server's source code to be able to see incoming
transactions. A s shown in Figure 5.7, the log entry contains the enode
of the light node, together with the transaction hash. This way, a light
server can easily link every incoming transaction to the IP address.
The transaction is then forwarded to the network.
" [12-92|15:48:42.708] L i g h t S e r v e r - R e l i e v e d t r a n s a c t i o n = 9 x d O e e d 8 5 d f c 9 9 a f 6 3 0 b 5 6 4 3 a c a a 4 6 b 7 3 2 4 4 d e 9 3 8 0 0 7 9 d 8 f b 2 1 7 2 a 8 0 e 4 3 f 6 0 9 5 5 c
from N o d e = e n o d e : / / d 5 b 2 8 1 e 2 1 e 2 8 3 1 6 3 2 e c 9 9 3 9 b 3 5 9 5 d 9 9 7 9 8 S 2 1 e l 5 f 2 b l b 6 4 2 f 9 1 1 c b 7 f f 1 8 c a 9 2 7 5 8 f b 3 8 c 9 8 9 b 0 4 9 8 9 f e 4 7 2 9 b 3 4 d 8 6 a c f e c 5 & f 4 e 6 5 S
4 e c 9 4 3 1 9 f 7 5 1 f c a e 4 2 e f f d a 5 @ 8 9 . 1 0 2 . 2 0 7 . 8 9
Figure 5.7: Transaction received from our light node
The light node, by default, does not send any requests to see if is
transaction already added to the block. The user can check the transaction's
status through any blockchain explorer, such as Etherscan.
Alternatively, by using the R P C methods eth_getTransact i o n or
eth_getTransactionReceipt. A c c o r d i n g to our logs s h o w n i n Figure
5.8, the requests are sent via the l e s protocol to three light servers.
INFO [12-04|11:92:50.155] LES - Requesting t r a n s a c t i o n s t a t u s T>. Has =[flxfa84aaf5497cd9c7eaf45791e09001fb7e5bc3e6a0977b7bb2e778097ef8cc42]
from Node=enr:-Kn4QD9rDgS_4WLMF0lk7xRgJt9bB7B5-ot^
gnYOgnlwhF. ZxnGDbGVzwCJGJc2VjcDIlNmsxoQIIrJzmEzYy-JTsUS5v03ukKKD2T9Ibe2dfJWDzAgulJDW4RzbmFwwIN9Y3CCdmKDdWRwgnZi I3
=95.217.198.113
INFO [12-64|11:82:50.209] LES - Requesting t r a n s a c t i o n s t a t u s T x Hash=[9xfa84aaf5497cd9c7eaf45791e99091fb7e5bc3e6a9977b7bb2e778097ef8cc42]
from Node=enr:-Kn4QF7hk4WsB9FD9v9pivu-IQA5eqJVabc9akq8M
gnY0gntwhF_Z5hSDbGVzwQGJe2VjcDIlNnsxoQNEjazxQw =95.217,230.20
INFD [12-04|ll:92:50.2491 LES - Reouestino t r a n s a c t i o n s t a t u s Tx Has =r9xfa84aaf5497cd9c7eaf45791e99091fb7e5bc3e6a9977b7bb2e778097ef8cc421
f r o n Node=enr:-Km4QACelZggoAzca9d9_VxRMYALrb27FCnxDyXBsQw^
gnY9gnlwhIelFCSDbGVzvjQGJc2VjcDIlNnsxoQPJQlzSDjWiyiM-X6GrladiFndfS5ecr7en5oRJnEK3rnIRzbnFwwIN9Y3CCdnKDdWRwgnZi I-=135.181.29.36
Figure 5.8: Transaction status request sent to three light servers
We have found that all requests from the light node are sent to three
72
5. G o E T H E R E U M
light servers. O n one side, it can decrease privacy. O n the other side,
it increases security as one of the servers can be corrupted.
We captured all the communication of our light node i n Wireshark
and performed a packet analysis to see if an attack similar to the one
described i n Section 4.4.3 is possible. A l s o , to see what information
an eavesdropper could obtain when a light node calls any of the mentioned
methods. We know the IP addresses of the sender and receiver
and the time w h e n we called the methods. We can locate the packets
w i t h such methods i n the captured communication w i t h such information.
However, we want to determine if an eavesdropper can locate
the packets without knowing w h e n the methods were called.
5.2.1 Packet analysis of eth_sendTransaction
A s described, a transaction from the light node can be sent at a maxim
u m of three light servers. W e wanted to k n o w if the packet differs
w h e n the transaction is sent to a different number of servers. For
that reason, we manually removed the light node's peers, so it sends
the transaction to one, respectively two servers. We found that every
packet carrying transaction from the light node has the same length,
258 bytes. The number of light servers does not make any difference.
Figure 5.9 shows all the packets captured i n 8 minutes w i t h such a
length. Unfortunately, more packets w i t h the same length are sent
from the light node. W e marked the packets w i t h the transactions
as black. W e do not k n o w the purpose of the remaining packets. A l though
there are many packets w i t h such lengths, the transaction
packets can be distinguished. W e noticed that if the transaction is
sent to two or three light servers. A l l the packets are immediately
behind, for example, packets w i t h numbers 36550, 36551, and 36522.
Focussing o n one T C P stream containing communication with a light
server w h i c h is shown i n Figure 5.10. We found that the ACK packet
from the light server always follows the node's request. The length of
every ACK packet is 66 bytes. Straight after the ACK packet, the server
sends the response w i t h a packet length of 162 bytes. The light node
then sends an ACK packet to confirm receipt of the response. We can
see that these four packets are immediately consecutive, and no other
packet is sent between them i n such a T C P stream.
73
5. G o E T H E R E U M
No. Time Source Destination Protocol Length Info
5582 16 3? 12 2510SSS77 19. 168 e 13 147.251.21.155 TCP 258 52634 PSH ACK]
11431 _6 iS 35,865663995 _9J£ _ b 3 0 13 65.103.132.23E TCP 47710 30307 PSH ACK]
11531 16 38 37,46933B055 192 168 e 13 147.251.21.165 TCP 258 52634 30303 PSH ACK]
11532 IS 38 37,469470598 192 168 e 13 65.108.132.230 TCP 258 47710 30307 PSH ACK]
1:, ;.S li; iS ^4. "-i^ ?,' .-'13ij19^ li;i3 3 13 65 .108.132.23G TCP 48238 — 3O304 PSH AoK]
19564 16 38 49,832757815 192 168 3 13 65.21.196.47 TCP 258 382B6
- 30305 PSH ACK]
2 052 2 1'; 38 52,771536956 192 168 3 13 144.76.236.199 TSP 258 57502
- 40303 PSH ACK]
24121 IS 39 02,19926B271 192 168 3 13 64.71.153.62 TSP :?s 40554
- 30303 PSH ACK]
24927 IS 39 82.34^255986 192 168 3 13 95.217.284.216 TCP 258 57940 - 30305 PSH ACK]
36550 IS 39 29,858367937 192 268 3 13 95.217.284.216 TCP 258 57i;43
- 30305 PSH ACK]
36551 IS 39 20,858655266 192 168 e 13 65.108.132.238 TCP 258 48238 30304 PSH ACK]
36552 IS 39 29,858898618 192 168 8 13 64.71.153.62 TCP 258 49654 30303 PSH ACK]
3 r; -.1 Is iS 2;. t'38955720 19 j _;
:i 3 0 13 65.21.73.183 TsF j-8 :::S - 30305 PSH A^K]
38676 IS 39 26,898542699 192 168 3 13 65.21.196.48 TCP 258 34972
- 30305 PSH ACK]
39275 16 39 27,900545424 192 168 3 13 135.181.2H.36 TCP 258 51488
- 30307 PSH ACK]
39609 16 39 28,851745377 192 168 3 13 135.181.28.39 TCP 258 50268
- 30304 PSH ACK]
39615 IS 39 28,864557117 192 168 3 13 95.217.284.216 TCP 258 60260
- 30304 PSH ACK]
39620 IS 39 28,865991164 192 168 3 13 95.217.224.92 TSP 258 463B4
- 30304 PSH ACK]
IS 39 29,901795815 192 168 3 13 95.217.1S8.113 TSP 258 491B6
- 30305 PSH ACK]
40016 IS 39 29,919492227 192 168 3 13 95.217.238.20 TSP 258 44506
- 30307 PSH ACK]
40215 IS 39 39,909481992 192 168 3 13 135.181.20.36 TSP 258 53714
- 30305 PSH ACK]
55185 IS 39 46,496141344 192 168 3 13 64.71.153.62 TCP 258 34B70 30303 PSH ACK]
56065 IS 39 48,299363255 192 163 3 13 147.251.21.165 TCP 258 52634 -* 30303 PSH ACK]
56066 IS 39 48,299392754 192 168 8 13 64.71.153.62 TCP 258 34870 -» 30303 PSH ACK]
c
- IS 43 SI.* 553-5511 It"1
J 103 3 13 95.217.230.29 TSF 258 3- ^43 - 30305 PSH ACK]
59388 16 43 02,854533744 192 168 3 13 95.217.284.216 TCP 258 58268
- 30305 PSH ACK]
60264 16 43 03,804873486 192 168 3 13 144.76.236.199 TCP 25B 40274
- 40303 PSH ACK]
61759 16 43 05,859062406 192 168 3 13 65.21.196.47 TCP 258 55202
- 30305 PSH ACK]
62168 IS 43 99,8591S42S'; 192 168 3 13 65.108.132.230 TCP 258 419B4 30307 PSH ACK]
62311 IS 46 11,502812391 192 163 3 13 95.217.284.219 TCP 258 58268 — 30305 PSH ACK]
62312 IS 46 11,503005097 192 168 8 13 64.71.153.62 TCP 258 34B70
- 30303 PSH ACK]
62313 IS 46 11,503245689 192 168 8 13 95.217.238.28 TCP 258 34940
- 30305 PSH ACK]
63074 IS 46 15,419795843 192 168 3 13 95.217.224.92 TCP 258 --153
- 30307 PSH ACK]
66082 IS 43 29,357399191 192 168 3 13 65.21.196.48 TSP 258 56068 30306 PSH ACK]
69628 IS 43 23,365378994 192 168 3 13 65.108.132.230 TSP 258 53896 30304 PSH ACK]
72110 IS 43 36,407363798 192 168 3 13 95.217.224.92 TSP 258 33620 - 30305 PSH ACK]
73488 IS 43 42,386688064 192 168 3 13 65.21.196.48 TSP 258 48604 - 30304 PSH ACK]
73862 16 43 47,385599056 192 168 3 13 95.217.230.20 TCP 258 53716
- 30306 PSH ACK]
77381 16 43 53,277556366 192 168 3 13 144.76.236.199 TCP 25B 44418
- 40303 PSH ACK]
77489 16 43 55,339204553 192 168 3 13 65.21.196.47 TCP 258 49562
- 30305 PSH ACK]
77858 IS 46 59,402786147 192 168 3 13 95.217.224.92 TSP 258 51454
- 30309 PSH ACK]
85143 IS 41 14,630976846 192 168 3 13 65.108.189.5 SlEl 258 13900
- 9000 [PSH, ACK]
89562 IS 41 25,641945373 192 168 3 13 65.21.73.183 TSP 258 53708
- 30305 PSH ACK]
89646 IS 41 25,642134396 192 168 3 13 65.21.196.48 TSP 258 51B96
- 30305 PSH ACK]
89751 IS 41 27,634879099 192 168 3 13 135.181.20.36 TSP 258 35B46
- 30307 PSH ACK]
89764 IS 41 27,652258222 192 168 3 13 135.181.20.36 TSP 258 58192 30304 PSH ACK]
90227 IS 41 28,649150958 192 168 3 13 95.217.224.92 TSP 258 58836 30304 PSH ACK]
90471 IS 41 29,656888793 192 168 3 13 135.181.20.36 TSP 258 59264 - 30305 PSH ACK]
94363 16 41 31,645530347 192 168 3 13 95.217.284.216 TCP 258 33318
- 30304 PSH ACK]
97618 16 41 33,589509735 192 168 3 13 144.76.236.199 TCP 258 597B4
- 40303 PSH ACK]
102856 16 41 49,678136721 192 168 3 13 65.21.196.47 TCP 258 41066 - 30305 PSH ACK]
117967 IS 42 15,289151544 192 163 8 13 65.108.132.230 TCP 258 419B4
- 30307 PSH ACK]
117968 IS 42 15,289392319 192 168 8 13 95.217.230.20 TCP 258 34940
- 30305 PSH ACK]
117969 IS 42 15,289510795 192 168 8 13 95.217.284.219 TCP 258 58268 30305 PSH ACK]
l2_148 IS 42 17,726738865 192 _D8 3 13 65.21.196.47 TsF _ j3 56934
- 30306 PSH A^K]
123863 IS 42 21,619341322 192 168 3 13 144.76.236.199 TSP 258 52032
- 40303 PSH ACK]
131870 IS 42 43,212986356 192 168 3 13 95.217.230.20 TSP 258 42918
- 30304 PSH ACK]
134844 IS 42 48,168877837 192 168 3 13 65.21.196.47 TSP 258 455B8 30305 PSH ACK]
143848 IS 43 93,492764737 192 168 3 13 64.71.153.62 TSP 258 43956 - 30303 PSH ACK]
143956 IS 43 93,979893557 192 168 3 13 95.217.230.20 TSP 258 56626 - 30305 PSH ACK]
144275 16 43 96,975125881 192 168 3 13 95.217.284.216 TCP 258 53892
- 30305 PSH ACK]
153046 16 43 15,91015>191 192 168 3 13 144.76.236.199 TCP 258 54200 - 40303 PSH ACK]
153783 16 43 21,454171591 192 163 e 13 95.217.284.216 TCP 258 53392 — 30305 PSH ACK]
153784 IS 43 21,454405009 192 168 e 13 147.251.21.195 TCP 25B 52934
- 30303 PSH ACK]
153785 IS 43 21,454599318 192 163 8 13 64.71.153.62 TCP 258 43956
- 30303 PSH ACK]
IS'; 241 IS 43 42,017743434 192 168 3 13 65.21.196.47 TSF 2 j8 -H :42
- 30305 PSH ACK]
159884 IS 43 42,562907499 192 168 3 13 65.108.132.230 TSP 258 38912
- 30307 PSH ACK]
165985 IS 44 01,447956554 192 168 3 13 144.76.236.199 TSP 258 46504
- 40303 PSH ACK]
166055 IS 44 02,007023115 192 168 3 13 65.108.132.230 TSP 258 33i32
- 30304 PSH ACK]
174514 IS 44 35,013599662 192 168 3 13 65.21.196.47 TSP 258 49566 30305 PSH ACK]
194500 IS 45 17,976511020 192 168 3 13 144.76.236.199 TSP 258 52818 - 40303 PSH ACK]
197670 IS 45 23,049353049 192 168 3 13 65.21.196.47 TSP 258 45998 - 30305 PSH ACK]
202868 IS 45 37,106229842 192 168 3 13 65.21.73.183 TCP 258 42232
- 30305 PSH ACK]
203080 16 45 38, 064871730 192 168 3 13 135.181.20.36 TCP 25B 46194
- 30307 PSH ACK]
2E3323 16 45 38,117193572 192 168 3 13 95.217.198.113 TCP 258 45142
- 30305 PSH ACK]
203073 IS 45 39,059712551 192 168 3 13 95.217.224.92 TSP 258 53292
- 30304 PSH ACK]
203266 IS 45 49,06499B068 192 168 3 13 135.181.20.39 TSP 258 38956
- 30304 PSH ACK]
203410 IS 45 41,073536958 192 168 3 13 65.21.196.48 TSP 258 473B8
- 30305 PSH ACK]
203433 IS 45 41,127894362 192 168 3 13 95.217.230.20 TSP 258 49116
- 30307 PSH ACK]
203563 IS 45 42,113552493 192 168 3 13 135.181.20.36 TSP 258 597B8
- 30305 PSH ACK]
203748 IS 45 43,073951768 192 168 3 13 95.217.204.216 TSP 258 58854 30304 PSH ACK]
209589 IS 45 58,145590870 192 168 3 13 95.217.224.92 TSP 258 41462 30307 PSH ACK]
213050 IS 46 93,49341B591 192 168 3 13 65.21.196.48 TSP 258 43392 - 30306 PSH ACK]
218684 IS 46 19,425991247 192 168 3 13 144.76.236.199 TCP 258 55426
- 40303 PSH ACK]
219337 IS 46 16,516414387 192 168 3 13 65.21.196.47 TCP 258 398B0 30305 PSH ACK]
2201S8 IS 46 21,108740463 192 IBS B 13 65.108 .132. 230 TCP 258 33SH2 -« 30304 PSH ACK]
220199 16 46 21,108842959 292 168 e 13 65.108.132.230 TCP 258 38912 30307 PSH ACK]
220280 IS 46 21,108921379 192 168 8 13 65.21.73.183 TCP 258 42232 30305 PSH ACK]
Figure 5.9: A l l packets of length 258
74
5. G o E T H E R E U M
35762 16 39 14,875340149 65.108.132.230 192.168.0.13 TCP 130 30304
-
48238 [PSH, ACK]
35763 16 39 14,917114766 65.108.132.230 192.168.B.13 TCP 66 30304
-
48238 [ACK]
35764 16 39 14,917912115 192.168.8.13 65.1B8 132.230 TCP 66 4823B 30304 [ACK]
36551 16 39 20,85B655266 192,168.0.13 65.1B8.132.23B TCP 258 48238 30304 [PSH, ACK]
36556 16 39 20,907941335 65.1B8.132.23B 192.168.0.13 TCP 66 30304 -4823B [ACK]
36557 16 39 2B,9B7941417 65.1B8.132.23B 192.168.0.13 TCP 162 30304 4823B [PSH, ACK]
3655B 16 39 20,907953454 192.168.0.13 65.138.132.230 TCP 66 4823B -30304 [ACK]
39955 16 39 29,829806516 192.168.8.13 65.1B8.132.230 TCP 138 48238
-
30304 [PSH, ACK]
3999B 16 39 29,873370130 65.108.132.230 192.168.0.13 TCP 130 30304
-
4823B [PSH, ACK]
39999 16 39 29,873380664 192 168.B.13 65.108,132.230 TCP 66 4823B
-
30304 [ACK]
Figure 5.10: T C P stream w i t h eth_sendTransaction
By z o o m i n g out and seeing the whole T C P communication (see
Figure 5.11), w e can see that this process is done w i t h every light
server. The colors separate communication w i t h individual servers.
Considering that every node tries to keep active connections w i t h
as many peers as possible. We believe that majority of the light nodes
send the transaction to at least two light servers. The user w o u l d have
to set the option maxpeers to one i n order to send the transaction
to only one server. A l t h o u g h , there are more packets w i t h such a
length, w e believe that an eavesdropper can distinguish the method
call. Nevertheless, our approach is based only o n the packet lengths
and can have false positives. A machine learning analysis using more
packet characteristics w o u l d definitely be more accurate. The timestamp
knowledge gives the attacker the beginning of the time interval
necessary for our deanonymization attack.
5.2.2 Packet analysis of eth_getTransaction/Receipt
According to our packet analysis i n Wireshark, both methods behave
the same. Therefore, w e analyzed them as one. A s mentioned, each
request is sent at m a x i m u m to three light servers. However, unlike
for eth_sendTrasaction, the requests are sent gradually, not all at
once. The light node sends the request to the first light server. The
length of the packet carrying one of these requests is 162 i n 90% of
packets. The packet length for the rest was 164. We could not find the
reason for the length differences. A s we d i d not find any other packet
w i t h this length being sent f r o m the light nodes, this packet can be
distinguished easily. W h e n the server receives the request, it responds
w i t h an ACK packet, w h i c h length is always 66 bytes. Straight after
the ACK packet, the server sends the response w i t h a packet length of
146 bytes. The light node then sends an ACK packet to confirm receipt
75
5. G o E T H E R E U M
3 6 5 5 0 1 6 3 9 20 8 5 8 3 6 7 0 3 7 1 9 2 . 1 6 8 . 0 . 1 3 9 5 . 2 1 7 . 2 0 4 . 2 1 6 TCP 2 5 8 5 7 0 4 0 - 3 0 3 0 5 [PSH, A C K ]
3 6 5 5 1 1 6 3 9 20 B 5 8 6 5 5 2 6 6 1 9 2 . 1 6 8 . 0 . 1 3 6 5 . 1 B 8 . 1 3 2 . 2 3 B TCP 2 5 8 4 8 2 3 8 - 3 0 3 0 4 [PSH, A C K ]
3 6 5 5 2 1 6 3 9 20 B 5 6 6 9 0 6 1 B 1 9 2 , 1 6 6 . 0 . 1 3 6 4 , 7 1 . 1 5 3 , 6 2 TCP 2 5 6 4 0 6 5 4 - 3 0 3 0 3 [PSH, A C K ]
3 6 5 5 3 1 6 3 9 20 B 7 B 3 6 9 4 3 5 1 9 2 . 1 6 8 . 0 . 1 3 6 5 . 1 B 8 . 1 3 2 . 2 3 B TCP 1 3 0 4 7 7 1 0 - 3 0 3 0 7 [PSH, A C K ]
3 6 5 5 4 1 6 3 9 28 9 0 4 6 3 1 6 1 2 9 5 . 2 1 7 . 2 0 4 . 2 1 6 1 9 2 . 1 6 8 . 0 . 1 3 TCP 66 3 0 3 0 5 - 5 7 0 4 0 [ACK;
3 6 5 5 5 1 6 3 9 20 9 0 6 7 0 4 5 4 7 9 5 . 2 1 7 . 2 0 4 . 2 1 6 1 9 2 . 1 6 6 . 0 . 1 3 TCP 1 6 2 3O305 - 5 7 0 4 0 [PSH, A C K ]
3 6 5 5 6 1 6 3 9 20 9 0 7 9 4 1 3 3 5 6 5 . 1 0 6 . 1 3 2 . 2 3 0 1 9 2 . 1 6 6 . 0 . 1 3 TCP 66 3O304 - 4 8 2 3 8 [ACK;
3 6 5 5 7 1 6 3 9 2B 9 0 7 9 4 1 4 1 7 6 5 . 1 0 8 . 1 3 2 . 2 3 0 1 9 2 . 1 6 8 . 0 . 1 3 TCP 1 6 2 3 0 3 0 4 - 4 8 2 3 8 [PSH, A C K ]
3 6 5 5 B 1 6 3 9 20 9 0 7 9 5 3 4 5 4 1 9 2 . 1 6 8 . 0 . 1 3 6 5 . 1 0 8 . 1 3 2 . 2 3 0 TCP 66 4 8 2 3 B - 3 0 3 0 4 [ACK;
3 6 5 5 9 1 6 3 9 20 9 1 5 9 1 6 4 4 8 6 5 . I B S . 1 3 2 . 2 3 0 1 9 2 . 1 6 8 . 0 . 1 3 TCP 1 3 0 3 0 3 0 7 - 4 7 7 1 B [PSH, A C K ]
3 6 5 6 0 16 3 9 20 9 1 5 9 2 1 9 B 4 1 9 2 . 1 6 8 . 0 . 1 3 6 5 . 1 0 8 . 1 3 2 . 2 3 0 TCP 36 4 7 7 1 0 3 0 3 0 7 [ACK;
3 6 5 6 1 16 3 9 20 9 1 6 O 0 1 5 B 3 1 9 2 , 1 6 6 . 0 . 1 3 6 5 . 1 0 6 . 1 3 2 . 2 3 0 TCP 1 3 0 4 7 7 1 0 - 3 0 3 0 7 [PSH, ACK]
3 6 5 6 2 16 3 9 28 9 1 8 1 7 9 4 7 6 6 5 . 1 0 8 . 1 3 2 . 2 3 0 1 9 2 . 1 6 8 . 0 . 1 3 TCP 55 3 0 3 0 7 - 4 7 7 1 0 [ACK;
3 6 5 6 3 1 6 3 9 20 9 1 8 1 7 9 5 5 6 6 5 . I B S . 1 3 2 . 2 3 0 1 9 2 . 1 6 8 . 0 . 1 3 TCP 1 3 0 3 0 3 0 7 - 4 7 7 1 0 [PSH, A C K ]
3 6 5 6 4 1 6 3 9 2B 5 5 3 8 8 9 6 4 S 1 9 2 . 1 6 8 . 0 . 1 3 95 2 1 7 . 2 0 4 . 2 1 6 TCP 66 5 7 0 4 0 - 3 0 3 0 5 [ACK;
3 6 5 6 5 1 6 3 9 20 9 6 1 8 8 5 8 6 7 1 9 2 . 1 6 8 . 0 . 1 3 6 5 . 1 0 8 . 1 3 2 . 2 3 0 TCP 66 4 7 7 1 0 - 3 0 3 0 7 [ACK;
3 6 5 6 6 16 3 9 20 9 6 4 5 7 6 2 1 1 6 5 , 1 0 6 . 1 3 2 . 2 3 0 1 9 2 . 1 6 8 . 0 , 1 3 TCP 56 3O307 - 4 7 7 1 0 [ACK;
3 6 5 6 7 16 3 9 20 9 7 1 3 9 0 5 1 B I B . 1 4 3 . 1 7 3 . 1 2 1 9 2 . 1 6 8 . 0 . 1 3 TCP 56 9 8 0 0 - 1 3 0 0 0 A C K ]
3 6 5 6 9 16 3 9 20 9 7 1 3 9 0 6 3 7 1 8 . 1 4 3 . 1 7 3 . 1 2 1 9 2 . 1 6 8 . 0 . 1 3 S 1 0 1 34 9 0 0 0 - 1 3 0 0 0 PSH, ACK]
3 6 5 7 0 16 3 9 20 9 7 1 4 2 1 6 9 6 1 9 2 . 1 6 8 . B . 1 3 1 8 . 1 4 3 . 1 7 3 . 1 2 TCP 36 - 9 0 0 0 A C K ]
3 6 5 7 1 16 3 9 20 9 B 5 3 3 4 B 4 9 3 4 . 2 2 2 . 1 3 9 . 3 4 1 9 2 . 1 6 8 . 0 , 1 3 TCP 56 9O00 - 1 3 0 0 0 A C K ]
3 6 5 7 3 16 3 9 20 9 6 5 3 3 4 9 7 9 3 4 . 2 2 2 . 1 3 9 . 3 4 1 9 2 . 1 6 8 . 0 , 1 3 5 1 0 1 104 9 0 0 0 - 1 3 0 0 0 PSH, ACK]
3 6 5 7 4 16 3 9 20 9 8 5 3 8 5 0 2 2 3 4 . 2 2 2 . 1 8 9 . 3 4 1 9 2 . 1 6 8 . 0 . 1 3 S 1 0 1 206 9 0 0 0 - 1 3 0 0 0 PSH, ACK]
3 6 5 7 6 16 3 9 20 9 8 5 3 3 5 1 1 2 3 4 . 2 2 2 . 1 3 9 . 3 4 1 9 2 . 1 6 8 . 0 . 1 3 S 1 0 1 188 9 0 0 0 - 1 3 0 0 0 PSH, ACK]
3 6 5 7 B 16 3 9 20 9 8 5 3 8 5 2 0 1 3 4 . 2 2 2 . 1 8 9 . 3 4 1 9 2 . 1 6 8 . 0 . 1 3 E 1 0 1 84 9 0 0 0 - 1 3 0 0 0 PSH, ACK]
3 6 5 7 9 16 3 9 20 9 B 5 4 2 5 9 9 B 1 9 2 , 1 6 6 . 0 . 1 3 3 4 . 2 2 2 . 1 8 9 . 3 4 TCP 56 1 3 0 0 0 - 9 0 0 0 A C K ]
3 6 5 8 0 16 3 9 20 9 8 5 6 3 2 5 2 E 1 9 2 . 1 6 8 . B . 1 3 3 4 . 2 2 2 . 1 8 9 . 3 4 5 1 0 1 87 1 3 0 0 0 - 9 0 0 0 PSH, ACK]
3 6 5 8 1 16 3 9 20 9 8 5 6 4 7 9 0 9 1 9 2 . 1 6 8 . 0 . 1 3 3 4 . 2 2 2 . 1 8 9 . 3 4 S 1 0 1 149 1 3 0 0 0 - 9 0 0 0 PSH, ACK]
3 6 5 8 2 16 3 9 20 9 8 6 5 0 9 9 2 E 1 8 1 4 3 . 1 7 3 . 1 2 1 9 2 . 1 6 8 . 0 1 3 TCP 56 9 0 0 0 - 1 3 0 0 0 A C K ]
3 6 5 8 4 16 3 9 20 9 6 6 5 1 0 0 4 1 1 8 1 4 3 . 1 7 3 . 1 2 1 9 2 . 1 6 8 . 0 1 3 S 1 0 1 104 9 0 0 0 - 1 3 0 0 0 PSH, ACK]
3 6 5 8 6 16 3 9 20 9 8 6 5 1 0 1 3 0 I B 1 4 3 . 1 7 3 . 1 2 1 9 2 . 1 6 8 . 0 1 3 5 1 0 1 100 9 0 0 0 - 1 3 0 0 0 PSH, ACK]
3 6 5 8 8 16 3 9 20 9 8 6 5 1 0 2 1 6 I B 1 4 3 . 1 7 3 . 1 2 1 9 2 . 1 6 8 . 0 1 3 S 1 0 1 104 9 0 0 0 - 1 3 0 0 0 PSH, ACK]
3 6 5 9 0 16 3 9 20 9 8 6 5 4 7 5 3 3 I B 1 4 3 . 1 7 3 . 1 2 1 9 2 . 1 6 8 . 0 1 3 S 1 0 1 128 9 0 0 0 - 1 3 0 0 0 PSH, ACK]
3 6 5 9 2 16 3 9 20 9 8 6 5 4 7 6 1 9 1 8 1 4 3 . 1 7 3 . 1 2 1 9 2 . 1 6 8 . 0 1 3 E 1 0 1 188 9 0 0 0 - 1 3 0 0 0 PSH, ACK]
3 6 5 9 4 16 3 9 20 9 6 6 5 4 7 7 1 3 I B 1 4 3 . 1 7 3 . 1 2 1 9 2 . 1 6 8 . 0 1 3 S 1 0 1 84 9 0 0 0 - 1 3 0 0 0 PSH, ACK]
3 6 5 9 5 16 3 9 20 9 6 6 5 6 9 9 7 3 192 1 6 8 . 0 . 1 3 I B 1 4 3 . 1 7 3 12 TCP 56 1 3 0 0 0 - 9 0 0 0 A C K ]
3 6 5 9 6 16 3 9 20 9 8 6 6 9 2 9 5 B 192 1 6 8 . 0 . 1 3 I B 1 4 3 . 1 7 3 12 S 1 0 1 37 1 3 0 0 0 9 0 0 0 PSH, ACK]
3 6 5 9 7 16 3 9 20 9 8 6 7 0 6 3 1 2 192 1 6 8 . 0 . 1 3 I B 1 4 3 . 1 7 3 12 E 1 0 1 149 1 3 0 0 0 - 9 0 0 0 PSH, ACK]
3 6 5 9 E 16 3 9 20 9 6 6 9 2 0 3 7 3 192 1 6 6 . 0 . 1 3 34 2 2 2 . 1 B 9 34 S 1 0 1 152 1 3 0 0 0 9 0 0 0 PSH, ACK]
3 6 5 9 9 1 6 3 9 20 9 8 8 2 9 5 0 1 2 1 9 2 1 6 6 . 0 . 1 3 I B 1 4 3 . 1 7 3 1 2 S 1 0 1 1 5 2 1 3 0 0 0 9 0 0 0 PSH, ACK]
3 6 6 0 0 1 6 3 9 2 1 0 2 5 6 2 9 2 5 9 6 4 . 7 1 . 1 5 3 . 6 2 1 9 2 . 1 6 8 . 0 . 1 3 TCP 66 3 0 3 0 3 - 4 0 6 5 4 [ACK;
3 6 6 0 1 1 6 3 9 2 1 0 3 1 6 5 0 9 7 6 3 . 1 1 3 . 0 . 1 9 6 1 9 2 . 1 6 8 . 0 1 3 TCP 66 9 0 0 0 - 1 3 0 0 0 A C K ]
3 6 6 0 3 16 3 9 2 1 0 3 1 6 5 1 0 9 1 3 . 1 1 3 . 0 . 1 9 6 1 9 2 . 1 6 8 . 0 1 3 E 1 0 1 84 9 0 0 0 - 1 3 0 0 0 PSH, ACK]
3 6 6 0 5 16 3 9 2 1 0 3 1 6 5 1 1 B 0 3 . 1 1 3 . 0 . 1 9 6 1 9 2 . 1 6 6 . 0 1 3 S 1 0 1 402 9 0 0 0 - 1 3 0 0 0 PSH, ACK]
3 6 6 0 7 16 3 9 2 1 0 3 1 6 5 1 2 6 E 3 . 1 1 3 . 0 . 1 9 6 1 9 2 . 1 6 8 . 0 1 3 S 1 0 1 84 9 0 0 0 - 1 3 0 0 0 PSH, ACK]
3 6 6 0 9 16 3 9 2 1 0 3 1 6 B 9 3 5 2 3 . 1 1 3 . 0 . 1 9 6 1 9 2 . 1 6 8 . 0 1 3 S 1 0 1 104 9 0 0 0 - 1 3 0 0 0 PSH, ACK]
3 6 6 1 1 16 3 9 2 1 0 3 1 6 8 9 4 3 E 3 . 1 1 3 . 0 . 1 9 6 1 9 2 . 1 6 8 . 0 1 3 E 1 0 1 100 9 0 0 0 - 1 3 0 0 0 PSH, ACK]
3 6 6 1 3 16 3 9 2 1 0 3 1 6 3 9 5 3 4 3 . 1 1 3 . 0 . 1 9 6 1 9 2 . 1 6 8 . 0 1 3 S 1 0 1 748 9 0 0 0 - 1 3 0 0 0 PSH, ACK]
3 6 6 1 5 16 3 9 2 1 0 3 1 6 3 9 6 3 2 3 . 1 1 3 . 0 . 1 9 6 1 9 2 . 1 6 8 . 0 1 3 S 1 0 1 84 9 0 0 0 - 1 3 0 0 0 PSH, ACK]
3 6 6 1 6 16 3 9 2 1 0 3 1 7 0 0 6 7 9 192 1 6 8 . 0 . 1 3 3 1 1 3 . 0 . 1 9 6 TCP 56 1 3 0 0 0 - 9 0 0 0 A C K ]
3 6 6 1 7 16 3 9 2 1 0 3 1 7 2 6 3 4 1 192 1 6 8 . 0 . 1 3 3 1 1 3 . 0 . 1 9 6 TCP 35 1 3 0 0 0 - 9 0 0 0 A C K ]
3 6 6 1 E 16 3 9 2 1 0 3 2 1 5 0 7 4 9 192 1 6 8 . 0 . 1 3 3 1 1 3 . 0 . 1 9 6 E 1 0 1 86 1 3 0 0 0 - 9 0 0 0 PSH, ACK]
3 6 6 1 9 16 3 9 2 1 0 3 2 2 4 4 0 4 6 192 1 6 6 . 0 . 1 3 3 1 1 3 . 0 . 1 9 6 S 1 0 1 1 5 1 1 3 0 0 0 9 0 0 0 PSH, ACK]
3 6 6 2 0 1 6 3 9 2 1 0 3 3 2 1 3 0 3 2 1 9 2 1 6 8 . 0 . 1 3 3 1 1 3 . 0 . 1 9 6 S 1 B 1 2 4 0 1 3 0 0 0 - 9 0 0 0 PSH, ACK]
3 6 6 2 1 1 6 3 9 2 1 0 4 3 9 3 2 4 3 0 6 4 , 7 1 . 1 5 3 . 6 2 1 9 2 . 1 6 8 . 0 , 1 3 TCP 1 6 2 3 0 3 0 3 - 4 0 6 5 4 [PSH, A C K ]
3 6 6 2 2 1 6 3 9 2 1 0 8 5 8 8 6 7 8 6 1 9 2 . 1 6 8 . 0 . 1 3 6 4 . 7 1 . 1 5 3 . 6 2 TCP 66 4 0 6 5 4 3 0 3 0 3 [ACK;
3 6 6 2 4 1 6 3 9 2 1 1 0 6 9 4 2 1 1 0 3 4 , 2 2 2 . 1 8 9 . 3 4 1 9 2 . 1 6 8 . 0 , 1 3 8 1 0 1 1 2 2 9 0 0 0 - 1 3 0 0 0 PSH, ACK]
3 6 6 2 5 16 3 9 2 1 1 0 6 9 7 0 2 7 4 1 9 2 , 1 6 6 . 0 . 1 3 3 4 , 2 2 2 . 1 8 9 , 3 4 TCP 56 1 3 0 0 0 - 9 0 0 0 A C K ]
Figure 5.11: Transaction sent to three light servers i n Wireshark
76
5- G o E T H E R E U M
of the response. The T C P stream that includes such communication is
shown i n Figure 5.12. These four packets are immediately consecutive,
- Time Source Destination Protocol Length Info
3870 11 02 48 9849 . 192.168.8.13 95.217.198.113 TCP 13 S 45406
- 30306 [PSH, ACK]
3882 11 02 49 0280,,. 35.217.IBB.113 192,168.0.13 TCP 130 30306 • 45406 [PSH, ACK]
3884 11 02 49 0280,,. 192.168.B.13 95.217.198,113 TCP 65 45406 • 30306 [ACK]
3885 11 02 49 0282„. 192.168.B.13 95.217.198,113 TCP 130 45406 • 30306 [PSH, ACK]
3886 11 02 49 0389,,. 95 217.198.113 192 168.B.13 TCP 13 B 30306
-
45406 [PSH, ACK]
3899 11 02 49 0819,,. 192.168.B.13 95.217.198.113 TCP 66 45406
-
30306 [ACK]
3902 11 02 49 1361 . 95,217.198.113 192,168.0.13 TCP 66 30306
- 45406 [ACK]
4483 11 02 50 1560,,. 192.168.B.13 95.217.198.113 TCP 162 45406
- 30306 [PSH, ACK]
4513 11 82 56 1984... 95,217.198.113 192,168.0.13 TCP 66 30306 — 45406 [ACK]
4514 11 92 5B 1995... 95.217.198.113 192,168.0.13 TCP 146 30306
-
45406 [PSH, ACK]
4515 11 02 50 1995... 192.168.B.13 95.217.198 113 TCP 66 45406
-
30306 [ACK]
8598 11 03 03 9852,,. 192.168,0,13 95.217.198.113 TCP 130 45406
- 30306 [PSH, ACK]
8604 11 03 04 0309,,. 95,217.198.113 192 168.0.13 TCP 130 30306
- 45406 [PSH, ACK]
8605 11 03 B4 0310,,. 192.168,0,13 95.217.198,113 TCP 66 45406 • 30306 [ACK]
B606 11 03 04 0311,. 192.168,0,13 95.217.198,113 TCP 130 45406 • 30306 [PSH, ACK]
B609 11 03 04 0321... 95,217.198.113 192 168.B.13 TCP 130 30306 • 45406 [PSH, ACK]
B617 11 03 B4 0738,,. 192.168.B.13 95.217.198,113 TCP 66 45406
-
30306 [ACK]
Figure 5.12: T C P stream w i t h eth_getTransaction
and no other packet is sent between them i n such a T C P stream. After
the light node sends the ACK packet to the first light server, it sends the
request to the second light server. Once the process described above is
done w i t h the second server, it sends the request to the third one. The
communication w i t h the servers is s h o w n i n Figure 5.13. The colors
separate communication w i t h individual servers. Since the network is
noisy, we could only fit the first packet from the communication with
the third server.
A s for eth_sendTrasaction, our approach is based only o n the
packet lengths and can have false positives. A machine learning analysis
using more packet characteristics w o u l d definitely be more accu-
rate.
5.2.3 Transaction time interval
We believe that the success of this attack is much smaller than i n Metamask.
The key to such a n attack lies i n identifying the requests i n the
network communication. C o m p a r e d to the user sending the transaction
from the Metamask, is the network communication w h e n a node
runs on the machine very noisy. Therefore it is much harder for eavesdroppers
to perform analysis. Since the method eth_sendTransaction
is called only once, it gives the attacker the exact timestamp and beginning
of the time interval. However, getting the end of the interval
is m u c h more complicated. Even though a n eavesdropper can find
77
5- G o E T H E R E U M
No. Tíme Source Destination Protocol Length Info
4483 11 02 50 1560... 192.16B.0 13 95.217 198 .113 TCP 162 45406 - 30306 [PSH, ACK]
4484 11 02 50 1561 . 192.168.0. 13 54.242.57. 222 TCP 66 13000 - 9000 ACK]
44B5 11 02 50 1564,,. 54.242.57. 222 192 168.0 13 S101 11502 9000 - 13000 PSH, ACK]
4486 11 02 50 1564,,. 192.168.0. 13 54.242.57. 222 TCP 56 13000 - 9000 ACK]
4487 11 02 50 1785 . 54.242.57. 222 192 168.0 13 TCP S3 9000 - 13000 PSH, ACK]
4488 11 02 50 1785... 54.242.57. 222 192 168.0 13 S101 14146 9000 - 13000 ACK]
4489 11 02 50 1786,,. 192.168.0. 13 54.242.57. 222 TCP 56 13000 - 9000 ACK]
449B 11 02 50 1792... 54.242.57. 222 192 168.0 13 S101 12738 9000 - 13000 ACK]
4491 11 02 50 1792... 192.168.0. 13 54.242.57. 222 TCP 56 _30Qn - 9000 ACK]
4492 11 82 50 1600 . 54.242.57. 222 192.168.B. 13 S101 21995 90B0 - 13080 PSH, ACK]
4493 11 02 50 1800 . 192.168.0. 13 54.242.57. 222 TCP 56 13000 - 9000 ACK]
4494 11 02 50 1918,,. 194.242.57 .118 192.168 E 13 S101 28B2 9000 - 13000 PSH, ACK]
4495 11 02 50 1918,,. 194.242.57 .118 192 168.0 13 S101 28B2 9000 - 13O0O PSH, ACK]
4496 11 02 50 1918,,. 194.242.57 .118 192 168.0 13 S101 28B2 9000 - 13000 PSH, ACK]
4497 11 02 50 1918,,. 194.242.57 .118 192 168.0 13 S101 28B2 9000 - 13000 PSH, ACK]
449B 11 02 50 1919,,. 192.168.B. 13 194.242.57 .118 TCP 66 13000 - 9000 ACK]
4499 11 02 50 1919,,. 192.168.B. 13 194.242.5í .118 TCP 66 13000 • 9000 ACK]
45BS 11 02 50 1919,,. 192.16B.0. 13 194.242.57 .118 TCP 56 13000 • 9000 ACK]
4581 11 02 50 1920,,. 192.168.0. 13 194.242.57 .118 TCP 56 13000 - 9000 ACK]
4582 11 02 50 1920,,. 194.242.57 .118 192 168.0 13 S101 1474 9000 - 13000 ACK]
4503 11 02 50 1928,,. 194.242.57 .118 192 168.0 13 S101 1474 9000 - 13000 PSH, ACK]
4584 11 02 50 1928,,. 194.242.57 .118 192 168.0 13 S101 28B2 9000 - 13000 PSH, ACK]
4585 11 02 50 1928,,. 194.242.57 n a 192 168.0 13 S101 28B2 9000 - 13000 PSH, ACK]
4586 11 02 50 1928,,. 194.242.57 n a 192 168.0 13 S101 28B2 9000 - 13000 PSH, ACK]
4587 11 82 50 1928,,. 194.242.57 .118 192.168.B. 13 S101 1398 9000 - 13O0O PSH, ACK]
4588 11 02 50 1928,,. 192.168.0. 13 194.242.57 .118 TCP 56 130OO - 9000 ACK]
4589 11 02 50 1928,,. 192.168.0. 13 194.242.57 .118 TCP 56 130OO • 9000 ACK]
4518 11 02 50 1928,,. 192.168.0. 13 194.242.57 .118 TCP 56 130OO • 9000 ACK]
4511 11 02 50 1929,,. 192.168.B, 13 194.242.57 .118 TCP 86 13000 - 9000 ACK]
4512 11 02 50 1980,,. CompalBr_al:68: Broadcast ARP 56 Who has 192.168.0.179?
4513 11 02 50 1984,,. 95,217,198 .113 192.168.0 13 TCP 66 30306 - 45406 [ACK]
4514 11 82 50 1995,,. 95.217 198 .113 192 168.0 13 TCP 146 30306 - 45406 [PSH, ACK]
4515 11 82 50 1995,,. 192.168.0. 13 95.217.19E . 113 TCP 66 45406 - 30306 [ACK]
4516 11 82 50 2009,,. 192.168.0. 13 95.217.23E . 20 TCP 162 38816 - 30305 [PSH, ACK]
4517 11 02 50 2234,,. 54,242,57. 222 192 168.0 13 TCP 68 9000 - 13000 PSH, ACK]
4518 11 02 50 2234,,. 54.242.57. 222 192 168.0 13 S101 14146 9000 - 13000 ACK]
4519 11 02 50 2235,,. 192.168.0. 13 54.242.57. 222 TCP 66 13000 - 9000 ACK]
452B 11 02 50 2239... 54.242.57. 222 192 168.0 13 S101 9922 9000 - 13000 ACK]
4521 11 82 50 2239... 192.168.0. 13 54.242.57. 222 TCP 56 130OB - 9000 ACK]
4522 11 02 50 2246,,. 54.242.57. 222 192.168 B 13 S101 14146 9000 - 13000 ACK]
4523 11 02 50 2246,,. 192.168.0. 13 54.242.57. 222 TCP 56 130OO • 9000 ACK]
4524 11 02 50 2256,,. 54.242.57. 222 192 168.S 13 S101 22594 9000 - 13000 ACK]
4525 11 02 50 2256,,. 192.168.B, 13 54.242.57. 222 TCP 86 13000 - 9000 ACK]
4526 11 02 50 2260,,. 54.242.57. 222 192 168.0 13 S101 4049 9000 - 13000 PSH, ACK]
4527 11 02 50 2260,,. 54.242.57. 222 192 168.0 13 TCP 66 9000 - 13000 PSH, ACK]
452B 11 02 50 2260,,. 54.242.57. 222 192 168.0 13 S101 15554 9000 - 13000 ACK]
452S 11 02 50 2260,,. 192.168.0. 13 54.242.57. 222 TCP 56 13000 - 9000 ACK]
453B 11 02 50 2260,,. 192.168.0. 13 54.242.57. 222 TCP 56 13000 - 9000 ACK]
4531 11 02 50 2260,,. 54.242.57. 222 192 168.0 13 S101 1474 9000 - 13000 ACK]
4532 11 02 50 2268,,. 54.242.57. 222 192 168.0 13 S101 22594 9000 - 13000 ACK]
4533 11 02 50 2269,,. 192.168.0. 13 54.242.57. 222 TCP 66 13000 - 9000 ACK]
4534 11 02 50 2269,,. 54.242.57. 222 192 168.0 13 S101 28B2 9000 - 13000 ACK]
4535 11 02 50 2269,,. 192.168.0. 13 54.242.57. 222 TCP 66 _300n - 9000 ACK]
4536 11 82 50 2280,,. 54.242.57. 222 192.168.B. 13 S101 211B6 90B0 - 130B0 ACK]
4537 11 02 50 2281... 192.168.0. 13 54.242.57. 222 TCP 56 13000 - 9000 ACK]
4538 11 02 50 2290,,. 54.242.57. 222 192.168 B 13 S101 1233 9000 - 13000 PSH, ACK]
4539 11 02 50 2290,,. 54.242.57. 222 192 168.S 13 TCP 58 9000 - 13000 PSH, ACK]
454B 11 02 50 2290,,. 54.242.57. 222 192 168.0 13 S101 7706 9000 - 13000 PSH, ACK]
4541 11 02 50 2291 . 192.168.B, 13 54.242.57. 222 TCP 66 13000 - 9000 ACK]
4542 11 02 50 2339,,. 192.168.0. 13 194.242.57 .118 TCP 66 13000 - 9000 ACK]
4543 11 02 50 2466.. 95.217.23C 20 192.168,0 13 TCP 66 30305 - 3B816 LACK]
4544 11 82 50 2486.. 95.217.23C 20 192.168,0 13 TCP 146 30305 - 38816 [PSH ACK]
4545 11 02 50, 248B.. 192.168.0 13 95.217.230.20 TCP 66 38B16 - 30305 [ACK]
4546 11: 02 : 50, 2500,,. 192 .168 . 0 .13
4547 11:02:50,2518...
454B 11:02:50,2518...
54,242,57.222
54.242,57.222
135,181.20.36
192 168.0.13
192 168.B.13
TCP
S101
162 44490 - 30306 [PSH, ACK]
68 9000 - 13000 [PSH, ACK]
148 9000 - 13000 [PSH, ACK]
Figure 5.13: Communication w i t h the servers i n Wireshark
78
5. G o E T H E R E U M
approximately w h e n the user requests the transaction information,
there is no certainty that the user w i l l stop sending the requests once
the transaction is processed. A l s o , there is no surety that the user
requests the same transaction he created. The user does not have to
send any of these requests at all and can use the blockchain explorer.
Therefore, i n many cases, the attacker only knows the beginning of
the interval. It makes it m u c h harder to perform the attack. A s w e
know, a transaction can be added to the block anytime after it is sent.
Everything depends on the fee. The attacker cannot k n o w the fee by
simply eavesdropping on the victim's communication. For that reason,
he can only guess w h e n the transaction w i l l be added to the block.
5.2.4 Attack implementation
We created a short python script using pyshark to evaluate the success
of our analysis (see Attachment A.3). The script loads the pcap file
and filters the packets. Only the T C P packets w i t h the ports commonly
used i n Geth are selected. The ports are 30303,30304,30305,30306, and
30307. In our communication, w e f o u n d that some nodes are using
port 40303. Therefore we also included ports 40304,40305,40306, and
40307.
The script then searches for packets w i t h length 258, w h i c h is, as
we found, typical for eth_sendTransaction. Then it checks if the two
following packets have the same length. If yes, the packet was sent
to more light servers. Therefore, the script considers it a packet w i t h
eth_sendTransaction and stores its timestamp. If not, w e check the
three following packets i n its T C P stream. These three packets should
have lengths shown i n Figure 5.10. If the packets' lengths match, the
script considers it a packet w i t h eth_sendTransaction and stores its
timestamp.
In the same loop, the script is also looking for packets w i t h a length
of 162. This length is typical for a packet w i t h eth_getTransaction.
Then it checks the three following packets i n its T C P stream. These
three packets should have lengths shown i n Figure 5.12. If the packets'
lengths match, the script considers it a packet with eth_get Trans act i o n
and stores its timestamp. A l l the captured timestamps are stored i n
the lists that are listed at the end (see Figure 5.14). In our analysis,
we successfully filtered all the eth_sendTransaction followed by one
79
5. G o E T H E R E U M
Found 2 packets with eth_getTransaction and 3 packets with eth_getTransaction.
Timestamp of 1 captured transaction: 2322-12-32 16:39:43.293363
Timestamp of 2 captured transaction: 2322-12-32 16:43:11.532312
Figure 5.14: Example of the results of the sript for light nodes
or two packets w i t h the same length. If there was only one packet,
approximately 15% of it h a d a different size than the third packet i n
its T C P stream. We could not find the reason for these different sizes.
Therefore, we d i d not include them i n the script. Since we believe that
most of the eth_sendTransaction is sent to two or three light servers,
we can consider this filter highly accurate.
The results showed that approximately 70% of all captured
e t h _ g e t l r a n s a c t i o n were f o u n d w i t h this script. 30% of the packets
were not selected because of their different sizes. W e c o u l d not
find the reason for these different sizes. Overall, w e d i d not capture
any packet that d i d not include these methods. Therefore, there were
no false positives.
5.2.5 Light server
The easiest w a y to deanonymize the light node's user is to be the
light server receiving the request. W h e n the eth_sendTransaction
is received, the light server can be sure w h o created the transaction.
Also, w h e n the server receives a transaction status request. The user
probably asks about his transaction. We assume that the majority of
the users ask only about their transactions. Still, there may be cases
w h e n the user inquires about the transaction of others.
A s w e know, the light node sends the request to three randomly
chosen peers. Therefore, w h e n there are 50 peers, the probability that
the node requests our server is low. W e need more light servers to
increase the chances. The higher the number of servers, the higher the
probability. Geth provides two methods to a d d peers, admin_addPeer
and admin_addlrustedPeer. The former requests connection to a remote
node specified by its enode. It also maintains the new connection
at all times, even reconnecting if lost. The latter allows the remote node
always to connect, even if the peer slots are full. Although, our node
tries to connect to the remote one, the connection might not be successful
w h e n it has all peer slots occupied. Even if we have enough servers,
80
5. G o E T H E R E U M
Geth does not provide the possibility to force a remote node to keep
a connection w i t h our nodes. This type of deanonymization attack
requires running many light servers. Therefore, it is highly demanding
on resources. Nevertheless, it can be focused o n many light nodes.
One light server can connect w i t h as many nodes as the resources
allow. For that reason, it can be such an attack highly successful.
5.3 Full node
Running the full node is the best possible w a y to keep privacy and
anonymity o n Ethereum. The user does not rely o n any other node.
A l l the created transactions are directly forwarded to the network
without any middle node (see Figure 5.15). The node does not make
II.FO \12 05|12:15:58.563] Submitted transaction =9x9c8297C688655859e6549Cdc526C629F26434a9E nonce=2
reciptent^Bxee69Afl4fiZ45d79f6e7d2D40f2Ai4788bda98dzc value=iee
hash=0x579f99a949995adfbd8c24ee535982d2292938c9a3f9fa6e7fIfIf4fe6330eb9
INFO [12-05|12:15:58.5G4] ETH - SendingTX Ha5n=Bx579f90a949995adfbd8c24ee535982d2292938c9a3f9fa6e7fIfIf4fe6339eb9
Tc=enodei//2b240f6927c589baa743d2b98e44ffdl4ae444099288d6bd253936b75b39af219e2e7f7a5 532996c9d39ead2 57799f68cb
67724f597f9943f13 598a57aedac7e015.294.141.11:39393
Figure 5.15: Transaction sent from the full node
any difference i n forwarding o w n a n d foreign transactions to other
nodes. A s shown in Figure 5.16, the received transaction is immediately
sent to its peers. The same goes for the transaction originating from
the node shown i n Figure 5.15. The created transaction is straight
away sent to the peers i n the same form as every other transaction.
For that reason, the attacker cannot know the creator of the captured
transaction by simple eavesdropping. Therefore, the deanonymization
attack described i n Section 4.4.3 is impossible for the full nodes.
INFO ri2-e2|15:38:11.2^e1 ETH - Recieved - =ex45c5c39772dcl57619a8ie4c42f989dl58c08b3bb7e0fa8faBf34f8Ga850fd73
fron-enode://636SblaOcfclda3746e7bc223ab2380a8dbd2e0395e7e39e511ab9S47475Sd6c23l60fl5fl737ff8753b6a24eb4e57O6ac
4643cai2173lb9d4f287b9e5584014O@77.161.16.136:30303
INFO [12-e2|l5:3S:ll.22l] ETH - Sending =0x4Sc5c39772dcl576l9a8104c42fge9dl5Sc09b3bb7e0fasfaBf34fasaaSQfd?3
-enode://a31e7dacff49fdadc597Se648d27b885aa6eSd2f&6edd34ble78Sb8ed9cc4bb8781e7dcafcb068B5e9ea8fc&b2d33baea0
6fd4932226bd2578488da49f8bl41e@88.198.45.152:33658
INFO [12-62|IS:38:11.221] ETH - SendingTX Hash=ex45c5c39772dclS7&i9a8104c-42fge9dlS8c08b3bb?e0fa8fa8f34f86a850fd73
Tn^enode://421df6a436f9c2bb4b90elaO8&404f481dOb0c41c2Ofbcd8c2d5529f8afS69a293149310989f5f05d58d8blaale3&llbd5
9Qd59lba0d5f94dec089e2582f4b25@3.38.44.21B:S6218
Figure 5.16: Transaction forwarding from the full node
81
5- G o E T H E R E U M
One of the possible ways to deanonymize a user is to monitor all
incoming and outcoming communication i n decrypted form. However,
all the network traffic, except the N o d e Discovery v4, is encrypted.
Therefore, the monitoring has to be done through the connected peers.
Such peers are able to see what transaction was sent f r o m the node.
We already describe such an attack o n the whole Ethereum network
in Section 3.3. That attack is highly d e m a n d i n g o n resources. Still,
a similar attack can be used to deanonymize one specific node. A n
adversary w h o aims to identify an account address w h e n given a
particular node IP address w i l l require fewer resources. In this case,
the adversary can find the node w i t h the given IP address i n the P2P
network and attempt to monitor all its connections. This approach is
less impacted by the scale of the network and depends only on the
number of peers to w h i c h the specific node is connected.
One of the approaches is ensuring that all the node's connected
nodes belong to the attacker. It can be seen as a modification of an
Eclipse attack. A l l the transactions the victim sends are created by
h i m or previously received f r o m one of the attacker's nodes. Therefore,
there is no doubt about w h o the creator is w h e n a transaction
originates from the victim.
Another approach, less harmful to the victim, is based on connecting
only w i t h the victim and all his peers. W h e n a connection is not
created by the victim, the victim receives it from one of his peers. A s
the attacker is connected to all the peers, it receives it also. W h e n a
connection originates f r o m the victim, the victim sends it to all his
peers, which also means to the attacker. Therefore, such a transaction
should come to the attacker first f r o m the victim and not f r o m some
other peer. However, as we know from the attack described i n Section
3.3, we must remember T I V i n the network. The crucial part of this
attack is to keep connections w i t h the victim's peers. There is no way
to find the victim's peers other than intercepting his communication.
W h e n there is noisy communication between the victim and other
Ethereum nodes, these nodes are considered the victim's peers. We
could not analyze this attack because we d i d not have the necessary
resources. Nevertheless, since this attack is successful o n the whole
Ethereum network, we assume that it can also be successful o n only
one node. A n d that w i t h m u c h smaller resource requirements.
82
6 Conclusion
In this work, we have analyzed possible deanonymization technics
that an attacker can use on Ethereum. Currently, only a tiny amount
of deanonymization attacks exist compared to Bitcoin. A l t h o u g h the
researchers tried to use the attacks suitable for Bitcoin on Ethereum,
most were not applicable. Most Ethereum deanonymization attacks
are based on address clustering heuristics that determine a one-tomany
m a p p i n g of entities to addresses. We proposed a heuristic for
linking the addresses of one user. The heuristic is based on the priority
fee that is included i n the transactions. We found that w h e n selecting
only the not c o m m o n l y used values, we can successfully link more
accounts of one user. The overall problem of a lack of ground truth i n
Ethereum caused many methods being not appropriately evaluated.
Therefore, the results d i d not provide accurate success numbers for
the method, such as false positives. Nevertheless, most attacks showed
that the anonymity of Ethereum is limited, and suitable clustering
methods can massively reduce the user's anonymity set. The m a i n
factor for the success of the attacks is always the users' behavior. Several
deanonymization techniques have shown that users are ruining
their o w n privacy. One of the most common user mistakes is reusing
the same address. It is caused by the fact that Ethereum transactions
always have only one recipient. Even though people try to hide the
transactions and connections between the accounts i n the mixers, such
mistakes reveal the relationships between all their addresses.
A l l the deanonymization attacks based on address clustering use
the free accessible data from the blockchain. The other, less commonly
used attack type collect data f r o m the network eavesdropping. The
most successful attack w i t h this approach is based o n monitoring
the whole network by connecting to every node. There are currently
around 7000 nodes. The results show that even the most secure and
privacy-protective method for Ethereum usage, a full node, does not
prevent the attackers w i t h enough resources from performing a successful
deanonymization attack. Such an attack can link the transaction
and the sender to its source node w i t h 88% accuracy. We proposed an
attack on one exact full node based on this attack. Such an attack requires
massively fewer resources. It needs to be connected to all peers
83
6. C O N C L U S I O N
of the v i c t i m and the v i c t i m node itself, usually 51 nodes. However,
we could not perform and evaluate such an attack due to a lack of
resources.
We monitored and analyzed network communication of the most
used Ethereum wallet, Metamask. We found that the connection with
the remote Infura node always starts w i t h a T C P handshake. Then
the wallet sends a Client Hello packet to the Infura node. This packet
includes the name of the server, which is Infura. With this information,
an eavesdropper can perform a deanonymization attack. Such an
attack uses the timestamps from captured packets to get the 20-second
time interval when the transaction was processed. We implemented a
python script to perform this attack. We discovered that it can find the
necessary packets w i t h 100% accuracy. However, the evaluation was
performed on the Goerli tesnet, and the results may be different on the
mainnet. We showed that the eavesdropper can massively decrease
the accounts' anonymity set.
We used a similar approach in the deanonymization of light nodes.
We found this attack not as successful as for Metamask. The network
traffic from the light node is noisier. Therefore, it is more complex to
distinguish necessary packets. Our script captured approximately 75%
of all packets it should w i t h no false positives. The method is based
only on the length of the packets. A technique using machine learning
w o u l d provide better results.
84
Bibliography
1. N A K A M O T O , Satoshi. Bitcoin: A peer-to-peer electronic cash
system. Decentralized Business Review. 2008, p. 21260.
2. E T H E R E U M , W . Ethereum Whitepaper. Ethereum. URL: https://ethereum.
org. 2014.
3. Is Cryptocurrency Anonymous ? The Myth of Anonymity Debunked.
U l a m , 2022. Available also from: h t t p s : //www. ulam. i o / b l o g /
i s - c r y p t o currency-anonymous.
4. W O O D , G a v i n et al. Ethereum: A secure decentralised generalised
transaction ledger. Ethereum project yellow paper. 2014, vol. 151,
no. 2014, p p . 1-32.
5. Ethereum accounts. Ethereum, 2022. Available also from: h t t p s :
//ethereum.org/en/developers/docs/accounts/.
6. Q U , M i n g h u a . Sec 2: Recommended elliptic curve d o m a i n p a rameters.
Certicom Res., Mississauga, ON, Canada, Tech. Rep. SEC2-
Ver-0.6.1999.
7. Keccak. Cryptopp. Available also from: https : //www. cryptopp.
com/wiki/Keccak.
8. Introduction to smart contracts. Ethereum, 2022. Available also
from: https : / /ethereum . o r g / e n / d e v e l o p e r s / d o c s / smartc
o n t r a c t s / .
9. Contract Interactions on the Chain. Ethereum, 2022. Available also
from: h t t p s : / / i n f o . e t h e r s c a n . c o m / c o n t r a c t - i n t e r a c t i o n s o
n - t h e - c h a i n / .
10. Transactions. Ethereum, 2022. Available also from: h t t p s : / /
e t h e r e u m . o r g / e n / d e v e l o p e r s / d o c s / t r a n s a c t i o n s / .
11. Gas. Ethereum, 2022. Available also from: h t t p s : / /ethereum.
org/en/developers/docs/gas/.
12. Blocks. Ethereum, 2022. Available also from: h t t p s : //ethereum.
o r g / e n / d e v e l o p e r s / d o c s / b l o c k s / .
13. Ommer blocks. Investopedia. Available also from: https : //www.
investopedia . c o m / t e r m s / u / u n c l e - b l o c k - cryptocurrency .
asp.
85
B I B L I O G R A P H Y
14. Intro to Ethereum. Ethereum, 2022. Available also from: https :
/ / e t h e r e u m . o r g / e n / d e v e l o p e r s / d o c s / i n t r o - t o - e t h e r e u m / .
15. Block Explorers. Ethereum, 2022. Available also from: h t t p s : / /
ethereum . o r g / e n / d e v e l o p e r s / docs / data - and - a n a l y t i c s /
b l o c k - e x p l o r e r s / .
16. Consensus. Ethereum, 2022. Available also from: https : //ethereum.
org/en/developers/docs/consensus-mechanisms/.
17. Consensys-Consensus. Consensys, 2022. Available also from: h t t p s :
/ / consensys . net / b l o g / b l o c k c h a i n - e x p l a i n e d / what - i s proof
- o f - stake/.
18. Proof of Work. Ethereum, 2022. Available also from: https : / /
ethereum.org/en/developers/docs/consensus-mechanisms/
pow/.
19. Proof of Stake. Ethereum, 2022. Available also from: h t t p s : / /
ethereum.org/en/developers/docs/consensus-mechanisms/
pos/.
20. The Merge. Ethereum, 2022. Available also from: h t t p s : //ethereum.
org/en/upgrades/merge/.
21. Beacon Chain. Ethereum, 2022. Available also from: https : / /
ethereum.org/en/upgrades/beacon-chain/.
22. Nodes and Clients. Ethereum, 2022. Available also from: h t t p s :
/ / e t h e r e u m . o r g / e n / d e v e l o p e r s / d o c s / n o d e s - a n d - c l i e n t s / .
23. Client diversity. Ethereum, 2022. Available also from: h t t p s : / /
ethereum . org / en / developers / docs / nodes - and - c l i e n t s /
c l i e n t - d i v e r s i t y / .
24. Ethernodes. Ethernodes. Available also from: h t t p s : //ethernodes.
org/.
25. Ethereum Wallets. Coin Telegraph, 2022. Available also from: h t t p s :
/ / c o i n t e l e g r a p h . com / ethereum - f o r - beginners / ethereumw
a l l e t s - a - b e g i n n e r s - g u i d e - t o - s t o r i n g - e t h .
26. Networking layer. Ethereum, 2022. Available also from: https :
/ / e t h e r e u m . o r g / e n / d e v e l o p e r s / d o c s / n e t w o r k i n g - l a y e r .
27. RLPx. Ethereum, 2022. Available also from: h t t p s : / / g i t h u b .
com/ethereum/devp2p/blob/master/rlpx.md.
86
B I B L I O G R A P H Y
28. Ethereum Wire Protocol (eth). Ethereum, 2022. Available also from:
https : / / g i t h u b . com/ethereum/devp2p/blob/master/caps/
eth.md.
29. Network addresses. Ethereum, 2022. Available also from: https :
//ethereum . o r g / e n / d e v e l o p e r s / d o c s / n e t w o r k i n g - l a y e r /
network-addresses/.
30. LibP2P: Multiaddr - Enode - ENR ?! Consensys, 2022. Available
also from: https : //consensys . n e t / d i l i g e n c e / b l o g / 2 0 2 0 / 0 9 /
l i b p 2 p - m u l t i a d d r - e n o d e - e n r / .
31. RLP. Ethereum, 2022. Available also from: https : / /ethereum.
o r g / e n / d e v e l o p e r s / d o c s / d a t a - s t r u c t u r e s - a n d - e n c o d i n g /
r i p / .
32. M A Y M O U N K O V , Petar; M A Z I E R E S , David. Kademlia: A peer-topeer
information system based on the xor metric. In: International
Workshop on Peer-to-Peer Systems. Springer, 2002, pp. 53-65.
33. Node Discovery v4. Ethereum, 2022. Available also from: h t t p s :
//github.com/ethereum/devp2p/blob/master/discv4.md.
34. Node Discovery v5. Ethereum, 2022. Available also from: h t t p s : / /
g i t h u b . c o m / e t h e r e u m / d e v p 2 p / b l o b / m a s t e r / d i s c v 5 / d i s c v 5 .
md.
35. D W O R K I N , Morris. Recommendation for Block Cipher Modes of
Operation: Galois/Counter Mode ( G C M ) and GMAC. Special Publication
(NIST SP), National Institute of Standards and Technology,
Gaithersburg, M D , 2007. Available also from: https : / / t s a p p s .
nist.gov/publication/get_pdf.cfm?pub_id=51288.
36. J A B L O N , D a v i d P. Strong password-only authenticated key exchange.
Comput. Commun. Rev. 1996, vol. 26, pp. 5-26.
37. K R A W C Z Y K , H u g o ; E R O N E N , Pasi. HMAC-based extract-andexpand
key derivation function (HKDF). 2010. Tech. rep.
38. G A Y O S O M A R T I N E Z , Victor; H E R N A N D E Z E N C I N A S , Luis;
S A N C H E Z A V I L A , Carmen. A survey of the elliptic curve integrated
encryption scheme. 2010.
87
B I B L I O G R A P H Y
39. C H E N , Xuan; N G U Y E N , Kien; S E K I Y A , Hiroo. Characterizing
latency performance i n private blockchain network. In: International
Conference on Mobile Networks and Management. Springer,
2020, pp. 238-255.
40. B L A K E - W I L S O N , Simon; J O H N S O N , D o n ; M E N E Z E S , Alfred.
Key agreement protocols a n d their security analysis. In: IMA
international conference on cryptography and coding. Springer, 1997,
pp. 30-45.
41. G A Y O S O M A R T I N E Z , Victor; H E R N A N D E Z E N C I N A S , Luis;
S A N C H E Z A V I L A , Carmen. A survey of the elliptic curve integrated
encryption scheme. 2010.
42. D A E M E N , Joan; R I J M E N , Vincent. Reijndael: The advanced encryption
standard. Dr. Dobb's Journal: Software Toolsfor the Professional
Programmer. 2001, vol. 26, no. 3, pp. 137-139.
43. E A S T L A K E 3 R D , D ; H A N S E N , Tony. US secure hash algorithms
(SHA and HMAC-SHA). 2006. Tech. rep.
44. V E R I A H O S E I N I , Seied; N I E M I , Valtteri. Mathematics and Data
structures i n Blockchain & Ethereum. 2018.
45. Light Ethereum Subprotocol. Ethereum, 2022. Available also from:
https : / / g i t h u b . com/ethereum/devp2p/blob/master/caps/
les .md.
46. K I M , Seoung K y u n ; M A , Zane; M U R A L I , Siddharth; M A S O N ,
Joshua; M I L L E R , Andrew; BAILEY, Michael. Measuring ethereum
network peers. In: Proceedings of the Internet Measurement Conference
2018. 2018, pp. 91-104.
47. Parity Light Protocol (PIP). Ethereum, 2022. Available also from:
https : / / g i t h u b . com/ethereum/devp2p/blob/master/caps/
p i p .md.
48. Ethereum Witness Protocol (wit). Ethereum, 2022. Available also
from: https : / / g i t h u b . com/ethereum/devp2p/blob/master/
caps/wit.md.
49. Z H O U , Yitao; W U , Judong; Z H A N G , Shengxin. Anonymity A n a l ysis
of Bitcoin, Zcash and Ethereum. In: 2021 IEEE 2nd International
Conference on Big Data, Artificial Intelligence and Internet of
Things Engineering (ICBAIE). IEEE, 2021, pp. 45-48.
88
B I B L I O G R A P H Y
50. ENS. Available also from: https : //ens . domains/.
51. BERES, Ferenc; SERES, Istvan A ; B E N C Z U R , Andras A ; Q U I N T Y N E C
O L L I N S , Mikerah. Blockchain is watching you: Profiling a n d
deanonymizing ethereum users. In: 2021 IEEE International Conference
on Decentralized Applications and Infrastructures (DAPPS).
IEEE, 2021, pp. 69-78.
52. X I A , Pengcheng; W A N G , H a o y u ; Y U , Z h o u ; L I U , X i n y u ; L U O ,
X i a p u ; X U , Guoai. Ethereum name service: the good, the b a d ,
and the ugly. arXiv preprint arXiv:2104.05185. 2021.
53. K L U S M A N , Robin; D I J K H U I Z E N , Tim. Deanonymisation in ethereum
using existing methods for bitcoin. 2018.
54. Dan Kaminsky blog. D a n Kaminsky. Available also from: h t t p s :
//dankaminsky.com/2011/08/05/bo2kll/.
55. Etherscan. Etherscan. Available also from: h t t p s : / / e t h e r s c a n .
i o / .
56. G A O , Yue; SHI, Jinqiao; W A N G , Xuebin; S H I , Ruisheng; Y I N ,
Zelin; Y A N G , Yanyan. Practical Deanonymization Attack in Ethereum
Based on P2P Network Analysis. In: 2021 IEEE Intl Confon Parallel
& Distributed Processing with Applications, Big Data & Cloud Computing,
Sustainable Computing & Communications, Social Computing
& Networking (ISPA/BDCloud/SocialCom/SustainCom). IEEE,
2021, pp. 1402-1409.
57. L U M E Z A N U , Cristian; B A D E N , Randy; S P R I N G , N e i l ; B H A T T
A C H A R J E E , Bobby. Triangle inequality variations i n the internet.
In: Proceedings of the 9th ACM SIGCOMM conference on Internet
measurement. 2009, pp. 177-183.
58. W A N G , G u o h u i ; Z H A N G , Bo; N G , TS Eugene. Towards network
triangle inequality violation aware distributed systems. In:
Proceedings of the 7th ACM SIGCOMM conference on Internet measurement.
2007, pp. 175-188.
59. Y U , Congcong; Y A N G , Chen; C H E , Zheng; Z H U , Liehuang. Robust
clustering of ethereum transactions using time leakage from
fixed nodes. Blockchain: Research and Applications. 2022, p. 100112.
89
B I B L I O G R A P H Y
60. P O U R S A F A E I , Farimah; H A M A D , Ghaith; Z I L I C , Zeljko. Detecting
Malicious Ethereum Entities via Application of Machine
Learning Classification. In: 2020, pp. 120-127. Available from DOI:
10.1109/BRAINS49436.2020.9223304.
61. E R M I L O V , D m i t r y ; P A N O V , M a x i m ; Y A N O V I C H , Yury. Automatic
bitcoin address clustering. In: 2017 16th IEEE International
Conference on Machine Learning and Applications (ICMLA). IEEE,
2017, pp. 461-466.
62. F L E D E R , Michael; KESTER, Michael S; P I L L A I , Sudeep. Bitcoin
transaction graph analysis. arXiv preprint arXiv:1502.01657. 2015.
63. L I N G , Charles X ; H U A N G , Jin; Z H A N G , H a r r y , et al. A U C : a
statistically consistent a n d more discriminating measure than
accuracy. In: Ijcai. 2003, vol. 3, pp. 519-524.
64. S I N G H , Chetana; G H O R A I , Pradip K ; H O R S C H , M a r k A ; JACKS
O N , Alicia M ; L A R S O N , Ronald G ; S T E L L A C C I , Francesco;
G L O T Z E R , Sharon C. Entropy-mediated patterning of surfactantcoated
nanoparticles a n d surfaces. Physical Review Letters. 2007,
vol. 99, no. 22, p. 226106.
65. R O Z E M B E R C Z K I , Benedek; KISS, Oliver; S A R K A R , Rik. Karate
Club: an A P I oriented open-source p y t h o n framework for u n supervised
learning o n graphs. In: Proceedings of the 29th ACM
international conference on information & knowledge management.
2020, pp. 3125-3132.
66. R O Z E M B E R C Z K I , Benedek; S A R K A R , Rik. Fast sequence-based
embedding w i t h diffusion graphs. In: International Workshop on
Complex Networks. Springer, 2018, pp. 99-107.
67. A H M E D , Nesreen K ; ROSSI, Ryan; L E E , John Boaz; W I L L K E ,
Theodore L ; Z H O U , Rong; K O N G , Xiangnan; ELDARDIRY, Hoda.
Learning role-based graph embeddings. arXiv preprint arXiv:1802.02896.
2018.
68. V I C T O R , Friedhelm. Address clustering heuristics for Ethereum.
In: International conference on financial cryptography and data security.
Springer, 2020, pp. 617-633.
69. Stylometry. Wikipedia, 2022. Available also from: https : / / e n .
w i k i p e d i a . o r g / w i k i / S t y l o m e t r y .
90
B I B L I O G R A P H Y
70. C A L I S K A N - I S L A M , A y l i n ; H A R A N G , Richard; L I U , A n d r e w ;
N A R A Y A N A N , A r v i n d ; V O S S , Clare; Y A M A G U C H I , Fabian;
G R E E N S T A D T , Rachel. De-anonymizing programmers via code
stylometry. In: 24th USENIX security symposium (USENIX Security
25). 2015, pp. 255-270.
71. LINOY, Shlomi; S T A K H A N O V A , Natalia; M A T Y U K H I N A , Alina.
Exploring Ethereum's blockchain anonymity using smart contract
code attribution. In: 2019 15th International Conference on
Network and Service Management (CNSM). IEEE, 2019, pp. 1-9.
72. M E I K L E J O H N , Sarah; P O M A R O L E , Marjori; J O R D A N , Grant;
L E V C H E N K O , Kirill; M C C O Y , D a m o n ; V O E L K E R , Geoffrey M ;
S A V A G E , Stefan. A fistful of bitcoins: characterizing payments
among men w i t h no names. In: Proceedings of the 2013 conference
on Internet measurement conference. 2013, pp. 127-140.
73. P E T K U S , M a k s y m . W h y and how zk-snark works. arXiv preprint
arXiv.1906.07221. 2019.
74. W U , Mike; M C T I G H E , Will; W A N G , Kaili; SERES, Istvan A ; B A X ,
Nick; P U E B L A , M a n u e l ; M E N D E Z , Mariano; C A R R O N E , Federico;
D E M A T T E Y , Tomas; D E M A E S T R I , Herman O , et al. Tutela:
A n Open-Source Tool for Assessing User-Privacy o n Ethereum
and Tornado Cash. arXiv preprint arXiv.2201.06811. 2022.
75. Hot Wallet. Coin Gate, 2022. Available also from: h t t p s : / / c o i n g a t e .
c o m / b l o g / p o s t / w a l l e t - h o t - c o l d - m e a n i n g .
76. Ethereum Wallet MetaMask Reports 21 Million Users. Decrypt. Available
also from: https : / / d e c r y p t . co/86263/ethereum-walletm
e t a m a s k - r e p o r t s - 2 1 - m i l l i o n - u s e r s .
77. MetaMask. MetaMask. Available also from: https : //metamask.
i o / .
78. MetaMask review. Investopedia. Available also from: https : / /
www . i n v e s t o p e d i a . com / metamask - crypto c u r r e n c y - w a l l e t -
review-5235562.
79. Privacy Policy. Consensys. Available also from: h t t p s : //consensys.
n e t / p r i v a c y - p o l i c y / .
91
B I B L I O G R A P H Y
80. Secret Recovery Phrase. Metamask. Available also from: h t t p s :
//metamask.zendesk.com/hc/en-us/articles/360060826432What
- i s - a - Secret - Recovery - Phrase - and - how - t o - keep y
o u r - c r y p t o - w a l l e t - s e c u r e .
81. Mitmproxy. Mitmproxy. Available also from: https : //mitmproxy.
org/.
82. Wireshark. Wireshark. Available also from: https : //www. wireshark.
org/.
83. Ethereum Networks. Ethereum. Available also from: https : / /
ethereum.org/en/developers/docs/networks/.
84. Eth_sendRawTransaction. Infura. Available also from: h t t p s : / /
docs . i n f u r a . i o / i n f u r a / networks / ethereum / j son - rpc -
methods/eth_sendrawtransaction.
85. Eth_sendTransaction. Infura. Available also from: h t t p s : / / d o c s .
i n f u r a . i o / i n f u r a / n e t w o r k s / e t h e r e u m / j s o n - r p c - m e t h o d s /
eth_sendtransaction.
86. Eth_getTransactionReceipt. Infura. Available also from: h t t p s : / /
docs . i n f u r a . i o / i n f u r a / networks / ethereum / j son - rpc -
methods/eth_gettransactionreceipt.
87. Amazon Web Service. Amazon. Available also from: h t t p s : //aws.
amazon.com/.
88. Ethereum dissector. ConsenSys, 2022. Available also from: h t t p s :
//github.com/ConsenSys/ethereum-dissectors.
89. Geth bootnodes. G o Ethereum. Available also from: https : / /
github . com/ethereum/go-ethereum/blob/master/params /
bootnodes.go.
92
A Attachments
A.1 Priority fee script
The zip file PriorityFee.zip contains a script to search for the specific
priority fee i n transactions. The specification of h o w to r u n the script
is included i n the README.txt. The file also includes two excel files
w i t h the data used i n our analysis i n Section 3.7.
A.2 Metamask script
The zip file Metamask.zip contains a script to search the specific packets
in the Metamask communication. The specification of h o w to r u n the
script is included in the README.txt. The zip also includes a pcap file
w i t h the captured communication used i n our analysis i n Section 4.4.
A.3 Light node script
The zip file LightNode.zip contains a script to search the specific packets
in the light node communication. The specification of h o w to r u n the
script is included i n the README.txt. The zip file also includes two
pcap files w i t h the captured communication used i n our analysis i n
Section 5.2.
93