Is Ethereum centralized ? (The lifecycle of a transaction)

There are a lot of regulations going on these times…

Maybe you think that:

• “My ETH is safe, it can’t be frozen”
• “No one can prevent me from sending a transaction”
• “No one can steal my ETH, unless they have my private key”

But are these statements true ?

Is Ethereum really decentralized ? In this article we discuss that.

At first, can you answer to this question ?

▶ What EXACTLY happens when you submit a transaction ?

If you can’t answer to this question, you can’t judge by your own if Ethereum is centralized or not.

But don’t worry, I’ll show you how it works :)

Let’s say, you’re on Firefox/Chrome and you want to mint a NFTs with metamask.

Of course, you will click on the button “mint”, but what will happens next?

Let’s see :)

Step 0: JavaScript Execution

The execution, is handled by the JavaScript language.

The library web3.js or ethers.js create a transaction containing all the necessary fields to be processed:

{
     from: "",
     to: "",
     maxbasefee: "",    //EIP 1559
     maxpriorityfee: "", //EIP 1559
     value: "",
     data: "",
     chain_id: "",
     nonce: "",
     gasLimit: ""
     r: "",
     v: "",
     s: "",
}

And they ask metamask (or any other wallet) to execute the transaction.

At this point, nobody (but you) can:

• Censor your transaction
• Change the inputs

(Unless you installed a trapped metamask transaction, but we will assume that metamask is genuine.) What happens next ?

Step 1: Sending a JSON-RPC Call

You may already know that Ethereum is a decentralized peer to peer network.

It’s only composed of “computers” running the Ethereum client. There are several thousands clients in the network but not all are equal…

In fact, once you’ve clicked in the “mint” button

Metamask will send a JSON RPC call to one of these nodes.

This is the same node every time and it’s marked in the RPC URL field when you add a network.

But there is a FIRST issue, by default Metamask uses Infura, Infura can easily block you from using the network, they can refuse to process your transactions.

It’s worth noting that, this is not speculations, it already happened!!! (US pressured infura to take sanctions against separatist areas in Ukraine):

• https://decrypt.co/94315/ethereum-infura-cuts-off-users-separatist-areas-ukraine-accidentally-blocks-venezuela

Fortunately, it’s easy for you to change the default RPC provider in metamask (the node to which the transaction will be sent), or use a VPN. But for a “not technical” user, it’s somewhat cumbersome…

You can create your own RPC node too but it requires more technical knowledge.

What does contains a JSON RPC request?

Here is a simple JSON RPC request sent by metamask to an Ethereum node. (Infura in most of the cases)

{"jsonrpc":"2.0", "method":"eth_getBalance", "params":["0xca57f3b40b42fcce3c37b8d18adbca5260ca72ec","latest"], "id":1}

• jsonrpc contains the jsonrpc version.
• method contains “what you want to do”
• params contains the arguments of the methods

In our case it asks the balance of an Ethereum account (eth_getBalance) the address of the account is provided in params

There are several others JSON RPC method to query a node (or a provider)

• eth_getStorageAt (get a storage slot)
• eth_getTransactionCount (get transaction count of an address)
• eth_txpool_inspect (inspect the mempool)
• eth_sendRawTransaction (send a transaction)
• eth_call (call a smart contract)

You can see all JSON RPC methods here: https://ethereum.org/en/developers/docs/apis/json-rpc/

▶ You too, you can communicate with a node without using Geth or Metamask (or any others software)

You just need to send an HTTP request containing JSON RPC to a node, and the node will process your request without using Metamask !

Let’s try the following in the command line.

curl, for those who doesn’t know, this a software (integrated in linux and windows) which allows sending personalized requests.

curl -X POST https://mainnet.infura.io/v3/your_api_key
  -H "Content-Type: application/json" 
  --data '{"jsonrpc":"2.0", "method":"eth_getBalance", "params":["0xca57f3b40b42fcce3c37b8d18adbca5260ca72ec","latest"], "id":1}'

• -X defines the method request and the host
• Content-Type: application/json Content-Type is the header of the application (this is json)
• and --data is the JSON content

You will get the ETH balance of the supplied address, don’t forget to provide your api keys for infura (because the rate is limited for free users)

Step 2: Broadcasting

Now, let’s say that the default node received your request for sending 1 ETH to your friend address. What happens next ?

Once the node received the JSON-request, he “validate” the transaction by checking if is signature, balance and inputs are valid.

After that transaction is broadcasted to the node peers (peers = the nodes connected to the nodes) which does the same validation too and so on…

So, in a matter of seconds all the transactions of the network will know

But what if a peer don’t like you address ?

He may stop broadcasting your transaction but others peer can still broadcast your transaction, so it’s not a big issue as long as there is more than 1 peer in the node.

Step 3: Execution/Mining

In each node, there are a lot of “received” transactions like ours. (there are stored in the “mempool”)

The miner chooses the most rewarding ones to fill the block, (others are let in the mempool to be “maybe” mined in the next block)

The first miner who find a block (among thousands of miners) include the transactions he chosen on the block.

But what if the miner don’t like you ?

He can discard your transactions even if you choose enough gas…

What if 80% of the miner power don’t like you ?

Your transaction will get rejected in average 80% of time, so every time a block is mined you need to hope that this is miners in the “20%” which will miner as thus accept your transaction.

Step 4: Returning the result

Once you submitted the transaction via JSON-RPC.

The nodes will process your transaction (by executing the smart contract) and if it’s valid, it will broadcast it on the blockchain.

The original RPC node will send you back a response if all is OK, or if there is an error in the transaction.

Final Word: Ethereum node distribution

Once we know the process, we can answer if the Ethereum is centralized or not.

So, where your transaction can get stuck ?

• (1) The default RPC node can reject your transaction (by choosing to NOT broadcast it) but,you can change the default RPC provider (the node which the transaction will be sent).
• (2) A peer node may not broadcast your transaction. (usually not a problem)
• (3) A node may not include you transaction on the mempool even if there is enough gas. (So you need to wait, that a “friendly” node will mine your transaction, if 99% of nodes hate your address, the average validation time will be 20 minutes for you.)

But there is 2 other “centralization issues” (we don’t told about) :

• geth (ethereum implementation for nodes) might update his software to exclude blacklisted addresses. (as geth is used by the majority of the node validators, it may cause problems)
• The smart contract may censor you by blacklisting you. USDC and USDT are able to do this. (In the Step 1, the transaction will revert and marked as “invalid”). This is for me the most important threat to Ethereum decentralization.

But besides the last problem (with smart contracts), it’s very unlikely that your ETH may got blocked, unless there is a 51% attack where an entity with enough power/stake may able to rewrite blockchain.

How likely a is a 51% percent attack?

If a node with enough staked ETH attack the protocol, the node may loose his staked coins, so it may be risky…

As of today, there is 11M ETH staked and a good amount are belongs centralized exchanges but this is not the biggest problem…

Conclusion

If hope your learnt a lot about blockchain in this article, and see you next time :)

If you think that I forgot to talk about others attacks, you can leave a comment here :)