SQLite vs PostgreSQL
An in-depth comparison of SQLite and PostgreSQL for web development, highlighting their strengths and use cases.
Different networks work differently, but Ethereum is the core inspiration for EVM-based networks. Knowing how these work is useful if you want to work in crypto.
When you first “send” a transaction it doesn’t automatically just happen. It gets added to the mempool which, in simple terms, is a public order book of transactions waiting to be added to the blockchain. An easy way for someone that is not technical to see the mempool is to look at the etherscan txs pending page
The network operators “look” at these transactions and based on an algorithm (which can be different on different networks) pick which to include in the upcoming block. They do this primarily based on gas used & gas price. They can only pick a limited set of transactions for each block (the term “block size” refers to this).
As soon as they reached consensus on which transactions to include in the next one, they do so. And on and on with more blocks.
Sometimes blocks get reverted (and inherently the transactions in them) because nodes fall out of sync. This is an important consensus mechanism that allows the Ethereum network to retain consistency of the data across all nodes.
Obviously you’ll have to pay a transaction (gas) fee for your transaction to be included in a block. This is something you have to be aware of as a user. If your fee is too low, you may wait longer (or even indefinitely) until operators decide to add it to the blockchain.
There’s also the risk of MEV attacks. MEV is a very deep and super interesting subject and there are many angles to it.
A simple example of MEV is a front-running attack. This has been a problem in traditional finance as well (investopedia definition of frontrunning). What it means is that someone finds out about your transaction in the order book (or in this case mempool) and figures out a way that they could profit (often at your expense) if they added another transaction right before yours (or after).
There are also cases of back-running (doing a transaction right after you) or even sandwich attacks where the attacker adds two transactions, one before and one after you.
These attacks or MEV strategies require not only very careful (likely automated) timing, but also very careful tuning of the gas parameters.
There are ways to protect yourself against MEV attacks, ranging from as simple as setting a slippage (limits on how little you can receive from a swap) to more complex solutions like bundling or private networks.
An in-depth comparison of SQLite and PostgreSQL for web development, highlighting their strengths and use cases.
Cross-chain bridges are hard and complex. What if it wasn’t like that?
Serverless tends to push the 'edge' paradigm. The app server lives close to the user to save latency. But it's problematic if you have a database because, generally, you will have multiple db queries for each page / API request. Let's talk about that