All you need to know about transaction processing on Ethereum and Polygon🤓

Ethereum, Polygon, Solana — We’ve all heard these names either on that Whatsapp forward, from your crypto bros or on that clickbait video you saw yesterday.😬😬

But do you understand how transactions happen on these chains?🧐

What goes behind making the experience seamless for users when you mint that NFT on OpenSea or Send/Receive crypto? 🤔

Well, I’ve got you covered from here!🫡🫡

Here’s the difference between the three most popular blockchain platforms which blockchain app developers and users around the world use. The usage of all three platforms depend on the type of applications being developed👇👇

To understand these consensus mechanisms: checkout this Consensus Mechanism 101 edition from Bits n bytes — a weekly crypto newsletter I write.📝✍️

The main goal is to understand how the jump from 15 to 65K was achieved by an L2 solution like Polygon🧐

Let’s start with Ethereum

First, let’s understand how a transaction is constructed and sent to the Ethereum network? Baby steps, eh?😺

👉In layman terms, transactions are cryptographically signed instructions from accounts. An account will initiate a transaction to update the state of the Ethereum network.

👉The simplest transaction is transferring ETH from one account to another.

📍 Say you send 1 ETH to your friend Alice. When you initiate that transaction, the state of the Ethereum Virtual Machine changes.

📍 Just how that nosy relative needs to broadcast about their kid moving abroad to the entire family🤣, transactions need to broadcast the info of state change to the whole network. Any node can broadcast a request for a transaction to be executed on the EVM.

👉Post this, a validator executes the transaction and propagates the resulting state change to the rest of the network.

But wait, transactions require a fee and must be included in a validated block. Before we understand that, let’s take a closer look at the transaction structure on the Ethereum chain

A submitted transaction includes the following information:

• recipient🙍‍♀️ – the receiving address
• signature👩‍💻 – the identifier of the sender, generated when the sender’s private key signs the transaction and confirms the sender has authorized this transaction
• nonce 🤖- a sequencially incrementing counter which indicates the transaction number from the account
• value 🪙– amount of ETH to transfer from sender to recipient (in WEI)
• data ⌨️– optional field to include arbitrary data
• gasLimit 🎰– the maximum amount of gas units that can be consumed by the transaction.
• maxPriorityFeePerGas💸 – the maximum amount of gas to be included as a tip to the validator
• maxFeePerGas 💰- the maximum amount of gas willing to be paid for the transaction

The gasLimit, and maxPriorityFeePerGas determine the maximum transaction fee paid to the validator.

But how do we ensure that the transaction could only have come from the sender and was not sent fraudulently?

An Ethereum client like Geth handles the signing process using JSON-RPC API calls

Any transaction taking place on the chain requires gas,

How do we know the amount of gas used?👀👇

Simple transfer transactions require 21000 units of Gas.

So for you to send 1 ETH to Alice at a baseFeePerGas of 180 gwei and maxPriorityFeePerGas of 20 gwei, you will need to pay the following fee:

(180 + 20) * 21000 = 4,200,000 gwei

OR

0.0042 ETH

👉Your account will be debited -1.0042 ETH (1 ETH for Alice + 0.0042 ETH in gas fees)

👉Alice’s account will be credited +1.0 ETH

👉The base fee will be burned -0.00399 ETH

👉Validator keeps the tip +0.000210 ETH

To summarize for ya’ll🤓

• Once you send a transaction, cryptography generates a transaction hash: 0xc9d2d79c6253406a146bf61690d4d5184124142665dbc2dd3b4ad1c73e6d9796 (example)
• The transaction is then broadcasted to the network and included in a pool with lots of other transactions.📣
• A validator needs to pick your transaction and include it in a block in order to verify the transaction and consider it successful.✔️
• As time passes the block containing your transaction will be upgraded to justified then finalized. Once a block is finalized it could only ever be changed by an attack 🆗

To understand the TPS for Ethereum, do checkout this post to know how it’s calculated👇👇

In ETHereum, miners have to race to find the nonce to meet the target difficulty.

Every node needs to verify that the miners’ work is valid and keep an accurate copy of the current network state. 😲 It uses Proof of Work (PoW) as its consensus algorithm.

PoW requires a participant node to prove that the work done and submitted by them, qualifies them to receive the right to add new transactions to the blockchain.

This greatly limits the transaction process capability and throughput of the Ethereum blockchain network. Currently, it can only process 12–15 transactions per second.😳

Less transaction processing speed and high gas has been a bottleneck for Ethereum and that’s where Polygon — a L2 scaling solution comes into picture with multiple scaling solution to bring down the gas fees to pennies and skyrocket the TPS🥳🥳

Given the multiple scaling options on Polygon, the most popular are commit chains, plasma sidechains, proof-of-stake (PoS) blockchain bridge, zk rollups and optimistic rollups. 👀

📌Matic began with plasma sidechains⛓️, which are lighter and more secure sidechains.

📌A plasma chain is a second blockchain that coexists with the main blockchain, similar to sidechains. Ethereum is the parent or main blockchain in this scenario.

📌Plasma chains communicate and connect to the main blockchain, enabling safe asset transfers between them. Just like sidechains, plasma chains have a consensus mechanism that creates blocks. However, unlike sidechains, the root of each plasma chain block is published to Ethereum. Block roots are basically little pieces of information that users can use to prove things about the contents of those blocks.

👉 The necessity for Ethereum to independently process each file is eliminated by processing batches of transactions on its own PoS blockchain.

👉In order to make Ethereum lighter and faster, Polygon batches transactions off the main chain.🤜🤛

🟣But, what does a transaction look like in Polygon network?🟣

➡️Transactions are comprised of metadata held in contexts and messages that trigger state changes within a module, through the module’s Handler.

➡️When users want to interact with an application and make state changes (e.g. sending coins), they create transactions.

➡️Each of a transaction’s message must be signed using the private key associated with the account before the transaction is broadcasted to the network.

➡️A transaction must then be included in a block, validated, and then approved by the network through the consensus process.

What does the validation process look like in Polygon? 🤔

Is that the secret sauce that boosts the TPS by manifolds?

📌Polygon provides hybrid Proof-of-Stake and Plasma-enabled sidechains. It features a generic validation layer separated from varying execution environments like full-blown EVM sidechains and other layer 2 approaches such as zero-knowledge rollups.

Time to talk about PoS — Proof of Stake

To enable PoS on the Polygon chain, a set of staking management contracts are deployed on Ethereum, along with a set of incentivized validators running Heimdall and Bor nodes. 👀

Polygon PoS has a three-layer architecture:

1. Ethereum layer — Staking smart contracts on Ethereum
2. Heimdall layer — a set of proof-of-stake Heimdall nodes running parallel to Ethereum, monitoring the set of staking contracts deployed on the Ethereum mainnet and committing the Polygon Network checkpoints to the Ethereum mainnet. Heimdall is based on Tendermint.
3. Bor layer — it’s a set of block-producing Bor nodes shuffled by Heimdall nodes. Bor is based on Go Ethereum.

Staking Contracts🤖

As discussed above, to enable the PoS mechanism on Polygon, the system employs a set of staking management contracts on the Ethereum mainnet.

The staking contracts implements the following features:

• Anyone can stake MATIC tokens on the [staking] contracts and join the system as a validator.
• Earn staking rewards for validating state transitions on the Polygon Network.
• Save checkpoints on the Ethereum mainnet.

The PoS mechanism also acts as a mitigation to the data unavailability problem for the Polygon sidechains.

Heimdall⛓️

👉This proof of stake validation layer handles the aggregation of blocks produced by Bor into a Merkle tree and publishes the Merkle root periodically to the root chain. The periodic publishing of snapshots of the Bor sidechain is called checkpoints.

What functionality does this validation layer provide?🤔

1. It validates all the blocks since the last checkpoint.
2. Creates a Merkle tree of the block hashes.
3. Publishes the Merkle root hash to the Ethereum mainnet.

Why are checkpoints important?🤔

1. They provide finality on the root chain.
2. Provide proof of burn in withdrawal of assets.

Now that we understand the terms,

What does the process of validation look like?👀

• A subset of active validators from the pool are selected to act as block producers for a span, who are responsible for creating blocks and broadcasting the created blocks on the network.
• A checkpoint includes the Merkle root hash of all blocks created during any given interval.
• All nodes validate the Merkle root hash and attach their signature to it.
• A selected proposer from the validator set is responsible for collecting all signatures for a particular checkpoint and committing the checkpoint on the Ethereum mainnet.
• The responsibility of creating blocks and proposing checkpoints is variably dependent on a validator’s stake ratio in the overall pool.😵‍💫

Bor🔳

👉Bor the block producer layer is responsible for aggregating transactions into blocks.

Block producers are a subnet of the validators and are periodically shuffled via committee selection on Heimdall in durations termed as a span in Polygon.

Blocks produced on Bor are validated periodically by Heimdall nodes, and a checkpoint consisting of the Merkle tree hash of a set of blocks on Bor is committed to Ethereum periodically.

But is that it?😳

Well, there are other scaling solution that help reduce the finality time for a transaction. Some of which are listed below👇

📍 Zk rollups process bundles of transactions off-chain and create validity proofs, verifying that each bundle of data is accurate. These validity proofs are then sent to the main blockchain.

📍 Each validity proof acts as a proxy for the bundle it represents which reduces the amount of data on the main chain. In effect, this approach reduces the time and gas fees required to validate a block of transactions.

🔊And the story doesn’t end here, recently, Polygon PoS announced a Parallel EVM upgrade to PoS that will make the Polygon PoS chain up to twice as fast.🥳

👉 The goal of the parallelizing engine is the ability to process multiple transactions at the same time.

👉 A 1.6x increase in gas throughput, with a clear path to a 2x speed-up was noted with the adoption of parallelization.🤩

To get more insights on how transactions are processed on a non-EVM chain subscribe to Bits n Bytes — a weekly crypto newsletter serving you the best crypto snacc and check out last weeks edition😃

If you want more web3 gyan, then, be sure to follow us on Twitter (@Web3_BNB)

Adios👋

How’d you like the take on comparing transaction processing on the widely adopted L1 and L2?

Let me know in the comments!

And if you liked what you read, follow me for more such crypto bytes and snacks😁😁

Source : Polygon Medium