🚀 Part 2 | Journey of 1 USDC: Propagating Ethereum Transactions 🪙
The journey continues: Delving deeper into Ethereum transaction execution and propagation.
Gm gm,
This is Bits n Bytes, the only newsletter that is as valuable as the tokens in your wallet. 💰
Well, what does it take for a transaction to conclude on Ethereum? If you haven’t checked out the previous week’s edition, to get all the details on how transactions are built and propagated, go take a quick look to get a quick refresher.🤩
We are now 1 step closer to understanding What really happens when you hit the send button to transfer 1 USDC or USDT to a wallet address? 🚀
TLDR; 👇
What next after receiving serialized signed transaction? 🛅
Transaction propagation. ⛓️
How and when our transaction is picked up from the mempool?🪙
When exactly does the transaction's execution start? 💱
Last week, we sent a serialized signed transaction to the network, what next? 🤔
📌 The receiving node will validate the transaction, propagate it to other nodes in the network, and eventually add it to a block on the blockchain.
📌 But that's not all there is to it! Let’s dive deeper into the transaction lifecycle on the Ethereum network. 👇
How should we go about figuring out what happens when an Ethereum node receives the serialized signed transaction? 👀
Some might hit up Twitter for answers, some might consult Medium articles, but let's be real - that's just not cool enough for us tech-savvy folks!
We're going straight to the source - the go-Ethereum (Geth) client. When a node receives a JSON-RPC call on its eth_sendRawTransaction endpoint, it gets down to business by deserializing the transaction. This makes it easier for the node to access the transaction's juicy details.😁
The node then validates the transaction by making sure the fee doesn't exceed its maximum (1 ether by default), and checking if it's replay-protected (thanks to EIP-155). After that, it's off to the transaction pool (aka the mempool) where the node keeps track of all known transactions that haven't made it onto the blockchain yet.🤯
But wait, there's more!
Before including the transaction in the pool, the node double-checks that it hasn't seen it before and that its ECDSA signature is legit. Otherwise, it's game over for that transaction. 😵
Hold on tight, because now we're getting into the heavy mempool stuff. There's a whole bunch of important validations going on here to make sure the transaction pool is healthy and happy.👀
We're talking gas limits, block limits, nonces, and making sure the sender has enough funds to cover all the potential costs. But don't worry, we're not here to turn you into a mempool expert. Each node operator can have their own unique approach to managing the mempool, so let's just think of it as a group of transactions eagerly waiting to be included in a block.😎
Once our transaction has made it into the pool, the node does some internal logging stuff and spits out a transaction hash. It's exactly what we saw in the JSON-RPC response earlier. Pretty cool, huh? 😎
Diving into the Mempool: Where Transactions Swim and Play 🏊♂️🌊
📌 When you send the transaction via Metamask or any similar wallet that is by default connected to traditional nodes, at some point it will land on public nodes' mempools.🌊
📌 We can peek into the mempool using a nifty endpoint called eth_newPendingTransactionFilter, which is not only useful for frontrunning bots but also for observing your transaction's journey before being included in the chain. ⛓️
📌 With just a bit of Javascript code, you can periodically query this endpoint and watch your 1 USDC transaction walk its way into the mempool of a local test node. So go ahead and put on your detective hats, because we're about to dive into the exciting world of mempool inspection! 🔍
It’s as simple as this 👇
const ethers = require("ethers");
(async () => {
const provider = new ethers.providers.JsonRpcProvider(ENDPOINT_API_URL);
const filterId = await provider.send("eth_newPendingTransactionFilter");
console.log(filterId);
/*
check for any new events that have occurred on the blockchain since the last time you checked
*/
const logs = await provider.send("eth_getFilterChanges", [filterId]);
console.log(logs);
})();
As we poll changes in the mempool, after 1 point we would be receiving the transaction, and the node responds with the txn hash that you use to check on Etherscan 🔍
Imagine you are sending your crypto transaction through a crowded room full of people. Everyone can see what you're doing and potentially interfere with your transaction. 🤯 But what if you had a secret tunnel that only you and your trusted friend knew about? You could safely transport your transaction without anyone else knowing.💯
Some specialized nodes in the Ethereum network have these secret tunnels, called private mempools, which allow users to "hide" their transactions from the public until they are included in a block. One example is the Flashbots Protect service. This means that even if you're monitoring the mempool with a tool like eth_newPendingTransactionFilter, you won't be able to see transactions that go through these private channels.🧐
However, let's assume that the transaction you're sending, like our 1 USDC example, is submitted through common channels without leveraging these private services.🫡
To have your transaction included in a block, it needs to make its way to the nodes that can create and propose the block.🚀💨
Time to look at the transaction’s propagation 🚀
In Ethereum, the ones who make the blocks are called miners or validators depending on the network's consensus algorithm. But don't worry, you don't need to find them yourself! You can just send your transaction to any regular node, and it will spread to the network like a happy virus.
There are various peer-to-peer protocols connecting these nodes, and they're always exchanging transactions with their peers. But here's the catch: to save resources, not all nodes receive every transaction in full. Instead, a random subset of nodes gets the full version, and the rest gets only the hash.
But just because a transaction enters a node's mempool, doesn't mean it stays there forever. If it's not picked up by a block builder, it might get removed from the pool after a certain period.🤨🤨
Block builders use a list of pending transactions to select which ones to include in the next block. And if you're curious, the default time a transaction can hang out in the mempool is three hours. So send your transaction on its merry way and let the network take care of the rest!
What’s next after navigating mempools?🙄
The transaction should reach a mining node.
We need to understand how our transaction gets picked up from the mempool and when it starts getting processed. 🛠️
The node's mining component is like a Swiss army knife, with different loops and functions that come into play.🗡️
When the node starts mining, it listens for new transactions and starts some fundamental loops. This "committing work" loop is what triggers the actual process of building a block with transactions and sealing it.⚒️
Once the loop is triggered, the node starts preparing the block's header. This includes setting important details like the block number, gas limit, and all-important details like coinbase address.
Then, the consensus engine kicks in to calculate the block's difficulty. This is where the infamous "difficulty bomb" comes into play.
The node then fetches the last known state and starts filling the block with transactions. And finally, our pending transaction is picked up from the mempool and executed along with the others in the block.🏃♀️
So, even though Ethereum nodes may seem like they're working in a complicated and non-linear fashion, it's really just a series of loops and processes that eventually lead to the execution of our transaction.
And we finally come to executing the transactions!
📌 Think of an Ethereum transaction as a magical potion that transforms the state of the blockchain. It's like you and Vitalik are wizards with their own stash of gold coins.
💬 State 0: You have 100 gold coins🪙 in your pot, and your friend Sam has 100 🪙 as well.
🧷 Transaction: You throw in a spider leg and chant some incantations, and voila! You send 1 gold coin to Sam. 🪙
💬 State 1: Your pot now has 99 gold coins 🪙, and Sam's has 101 🪙🪙.
Executing a transaction means unleashing your inner wizard and casting a series of spells on the current state of the blockchain. These spells create a new enchanted state, different from the previous one. This new state will be the current state until another wizard comes along with a new potion.🧙🪄
But, the magic of Ethereum is not for the faint-hearted. It's a thrilling and intricate world of spell-casting, where each transaction is like a new adventure waiting to be discovered.✨
So there you have it - the technical nitty-gritty of what happens when an Ethereum node receives a signed transaction. 💯💯
Stay tuned for the next part in the journey of 1 USDC on Ethereum series, where we explore the execution of transactions - everything from committing transactions to state changes.👀
Thanks for tuning in to the latest edition of Web3 Bits N Bytes! We had a blast putting it together and we hope you had just as much fun reading it.🤩
As a member of our Web3 tribe, we want to keep the good vibes rolling and watch this community thrive! So, don't be shy, share this 🔥 newsletter with your fellow decentralized tech enthusiasts, and let's spread the word together. And don't forget to give us a follow on Twitter for some fun interaction.🤗
If you're not already subscribed, make sure to sign up so you never miss a beat. We promise to keep delivering the latest insights and perspectives on the amazing world of Web3 and the decentralized future.🤝
Thanks for being a part of our awesome community and for your support. We can't wait to catch you at the next edition of Web3 Bits N Bytes! 🍩
Let's keep the party going 🎉🎉
