(1/21) In 2022, @ethereum completed The Merge, fusing the Execution Chain and the Beacon Chain. But what are these two chains and how did they transition Ethereum from Proof of Work to Proof of Stake?

A deep dive on how The Merge defined the modern structure of Ethereum.

(2/21) @ethereum is the World Computer, a single, globally shared computing platform that exists in the space between a network of 1,000s of computers (nodes). 

These nodes are real computers in the real world, communicating directly from peer to peer.

https://x.com/LogarithmicRex/status/1592309373732151296

(3/21) This globally shared platform is manifested with the Ethereum Virtual Machine (EVM). Each node is running a copy of the EVM, held in perfect sync with all other nodes via Proof of Stake (PoS). 

The blockchain is an immutable record of the history of the EVM/Ethereum.

https://x.com/LogarithmicRex/status/1554633476598484993

(4/21) To truly understand how Ethereum works and the structure of the Ethereum blockchain, you need to understand a brief history of Ethereum, Bitcoin and crypto.

So, let's start at the beginning: October 2008

Specifically, the @Bitcoin whitepaper.

https://bitcoin.org/bitcoin.pdf

(5/21) While there are endless things to say about the Bitcoin whitepaper, we are going to focus the step-change innovation that it introduced: Proof of Work (PoW).

PoW is a consensus system, a mechanism used to ensure that all nodes agree on a single, shared state of data. 

(6/21) At genesis, Ethereum also used a PoW system (although one much more complex than the system Bitcoin uses).

However, from the nearly the very beginning, Ethereum always had plans to change its consensus system to Proof of Stake. 

https://x.com/LogarithmicRex/status/1554500348231880704

(7/21) While this thread wont address questions like "why did we want to switch from PoW to PoS," it's worth understanding the trade-offs between the two systems.

For those interested in learning more, here's a thread walking through @VitalikButerin's thoughts on the matter.

https://x.com/LogarithmicRex/status/1578941538607845376

(8/21) In September 2022, after years of hard work (including a complete redesign), Ethereum finally achieved the switch from PoW to PoS.

We call this event "The Merge."

(the actual moment of The Merge happens at 2:59:13 in the video below)

https://www.youtube.com/live/Nx-jYgI0QVI?si=VElglb3xfURGQBBU&t=10753

(9/21) Now let's pause for a moment and ask ourselves: "why was this event called 'The Merge?'" The purpose was to switch the consensus system; why not call it "The Swap?" 

Well in answering this question we can draw deep insight into how Ethereum works today!

(10/21) In the early years of Ethereum, there was a single blockchain. In order to participate in the network, you simply downloaded software that would 1) create a local copy of the EVM and 2) participate in PoW.

And then, in December 2020, the Beacon Chain was launched.

(11/21) The Beacon Chain is an independent blockchain, secured by PoS, that existed in parallel to the Ethereum blockchain. 

Unlike Ethereum, the Beacon Chain did not have a virtual machine and did not process user txns or smart contracts. It simply performed PoS consensus.

(12/21) From Dec 2020 until Sept 2022, the Beacon Chain chugged along, going through the motions of PoS without securing any actual assets or computation.

But during that time, we researched tested, optimized, fixed and tweaked the Beacon Chain to ensure PoS worked flawlessly.

(13/21) Also during this time, we onboarded about 400k validators (13MM $ETH, billions of $) onto the Beacon Chain.

This not only gave the Beacon Chain a credible testing period, it meant that when it came time to switch to PoS, there was already a huge amount of staked $ETH.

(14/21) While the Beacon Chain was coming online, Ethereum blockchain continued operating using PoW. 

Soon these two chains would come together. The original Ethereum blockchain would still operate the execution of the EVM, and the Beacon Chain would take over consensus.

(15/21) And then on September 15th, 2022 it finally happened. The Beacon Chain merged with Ethereum's execution chain.

We'll dive a little deeper shortly, but tl;dr the execution chain stopped using PoW and instead outsourced consensus to the PoS Beacon Chain.

(16/21) Post-The Merge, the Execution Chain and the Beacon Chain ceased to exist as independent chains and instead just form Ethereum.

And yet, understanding this history is incredibly useful for understanding how Ethereum works today.

(17/21) Before The Merge, each node would run one piece of software (execution client). This software managed the EVM and participated in consensus.

Post Merge, the execution client only manages the state of the EVM. Now a new piece of software (consensus client) manages PoS.

(18/21) Under the hood, the remnants of the two-chain structure and The Merge are obvious.

For example, an Ethereum node must run two pieces of software. A consensus client, corresponding to the beacon chain, and an execution client, corresponding to the execution chain.

https://x.com/LogarithmicRex/status/1589807499804176384

(19/21) Although the execution and consensus clients do communicate with each other often, they are both completely independent pieces of software (created by different groups of people).

And so even post-Merge, you can still see how two chains became one inside of a node.

(20/21) You can even see it in the structure of the blocks/blockchain itself. 

Each block is really made up of a block from the beacon chain that encases a block from the execution chain. 

Almost like Russian nesting dolls.

https://x.com/LogarithmicRex/status/1568365818509139968

(21/21) Understanding the history of Ethereum/The Merge illuminate what Ethereum is today.

And while the concepts of a "Beacon Chain" and "Execution Chain" are out of date (Ethereum is just one chain again), they are helpful in understanding the layers of Ethereum.

How The Merge Defines Ethereum Architecture

(1/26) Upgrading the World Computer: EIPs, ERCs and the @ethereum Upgrade Process

Have you ever wondered how a decentralized, credibly neutral blockchain is upgraded? How Ethereum decides on new features? The difference between an EIP and ERC?

All these answers, and more!

(2/26) Ethereum is the World Computer, a single, globally shared computing platform that exists in the space between a network of 1,000s of computers (nodes). 

These nodes are real computers in the real world, communicating directly from peer to peer. 

https://x.com/LogarithmicRex/status/1592309373732151296

(3/26) The endgame vision of the World Computer: to be the credibly neutral property layer of the internet.

The current reality of Ethereum: we just aren't there yet.

(4/26) Today and forever, one of the core pillars of the World Computer is decentralization.

Decentralization guarantees that each individual user is sovereign; no president, corporation, dictator or cabal has the ability to take their property or stop them from using it. 

https://x.com/LogarithmicRex/status/1618083118195568640

(5/26) When we invoke decentralization, we are usually referencing the number of nodes/computers that make up a blockchain system.

But this is just one leg of decentralization. Just as important as "who is running the blockchain" is "who is controlling the code?"

(6/26) Just to drive this point home, it doesn't matter how many entities are operating nodes if a centralized entity single-handedly controls the code.

That entity could push an update that changes the rules and unilaterally revokes a user's sovereignty over their own assets.  

(7/26) And so, while it's important to decentralize the operation of the World Computer, it's just as important to decentralize control of the code and functionality of Ethereum.

But before we talk about how code changes, let's talk about what Ethereum really is.

(8/26) Remember, Ethereum is made up of 1000s of computers that are all running two pieces of software:

The execution client houses Ethereum's shared computing platform (EVM). 

The consensus client ensures each node is perfectly in sync with every other node (via PoS).

https://x.com/LogarithmicRex/status/1589807499804176384

(9/26) So you may think: "well if you want to be specific about it, Ethereum is really just these two pieces of software" and even "whoever wrote that software is ultimately in control."

If this were true, it would make it much more difficult to achieve true decentralization.

(10/26) The truth: today there are 6 consensus (1 in beta) and 8 execution clients (3 in alpha/beta).

Ethereum exists because 6 independent consensus teams and 8 independent execution teams have agreed to and implemented the same rules that define Ethereum.

(11/26) Pretend you have an new feature that you want implemented. To realize this goal, you need to convince every team that this is not only going to make Ethereum a better platform, but that your change is worth the developer resources, complexity and implementation costs.

(12/26) Fortunately, we have a channel for this! Held (usually) biweekly, the All Core Devs (ACD) Call is a regular meeting where core devs discuss updates, proposals, and issues related to Ethereum.

Typically the meeting alternates between the consensus and execution layers.

(13/26) While the ACD is an important coordinating function for Ethereum, it does not represent ownership and/or control of Ethereum.

Upgrades and code changes must achieve consensus amongst researchers, client developers and community members. There is no forcing function. 

(14/26) To really grasp the upgrade process, we need to dive deeper and discuss how individual improvements are communicated and implemented.

Specifically, we need to understand:

1) hard forks
2) Ethereum Improvement Proposals (EIPs)
3) Ethereum Requests for Comment (ERCs)

(15/26) A hard fork is a backward-incompatible change to a blockchain's protocol that requires all nodes to upgrade to the new rules. 

If some participants don't upgrade, the blockchain splits into two separate networks, one following the old rules and one following the new.

(16/26) In general, hard forks are achieved with very little conflict; by the time they are deployed everyone is already aligned on the "correct" fork.

However, this isn't always the case (eg the DAO Hack, brilliantly told by @thegrifft on @BanklessHQ).

https://www.youtube.com/watch?v=cVC9SbTmfSg

(17/26) Hard forks are made up of one or more EIPs. EIPs propose changes to the protocol or its core standards.

EIPs are a big deal; they define how Ethereum itself is going to change and imply actual code changes in consensus and/or execution clients.

(18/26) EIPs are generally instantiated by formally writing out the motivations and specific changes and then posting them to the Ethereum @github repository.

After much research and discussion, they might eventually be candidates for a hard fork.

https://github.com/ethereum/EIPs

(19/26) In general, EIPs are structural changes and require not only the consensus of the community but actual implementation of the client teams.

However, not every feature requires such a fundamental impact. Often functionality can be achieved without changing Ethereum's code.

(20/26) An ERC is a specific type of EIP that defines standards for applications running on Ethereum, such as token standards, APIs, or contract interfaces.

ERCs shape how devs interact with Ethereum but don't require changes to the underlying protocol.

(21/26) Let's look at perhaps the most famous ERC: ERC-20.

ERC-20 defines what functionality a smart contract needs to support in order to be considered a "token." This doesn't require any changes to Ethereum, just sets the standards for what gets deployed on-chain.

https://x.com/LogarithmicRex/status/1860021980373876809

(22/26) In short, EIPs focus on Ethereum's infrastructure (actual code changes to Ethereum), while ERCs focus on applications and tools (optional for devs, but widely followed for convenience and interoperability).

Hard forks are made up of EIPs and (generally) not ERCs.

(23/26) And thus concludes our survey of the Ethereum upgrade process... but before we close out, let me drop a few jumping off points for learning more!

First, if you are interested in watching ACD calls, the @ethereum foundation posts them on YouTube.

https://www.youtube.com/@EthereumFoundation

(24/26) Being honest, these calls can be highly technical and difficult to follow. Fortunately, we are blessed with @christine_dkim!

Christine is the best person to follow to help understand how Ethereum is changing. Also make sure to check out her podcast "Infinite Jungle."

https://x.com/StrangeH2OPod/status/1778400018153574705

(25/26) And if you ever want to dive deep on a specific EIP, there is nowhere better to look than @poojaranjan19 and the @EthCatHerders.

While the Cat Herders are responsible for so much more, the best place to start is with their podcast/show PEEPanEIP.

https://www.youtube.com/@ethcatherders

(26/26) In summary, Ethereum upgrades via hard forks, which are made up of one or more EIPs. EIPs change the rules and code of Ethereum, and so require strong consensus.

ERCs are standards that do not require changes to the core protocol, and are optional but widely adopted.

The Ethereum Upgrade Process

(1/24) Ever wondered how @ethereum tokens work? Why is $ETH different from all other tokens? Where does your $USDC really exist?

Let's dive deep on ERC-20 and, through it, understand how tokens work on the World Computer!

(2/24) @ethereum is the World Computer, a single, globally shared computing platform that exists in the space between a network of 1,000s of computers (nodes). 

These nodes are real computers in the real world, communicating directly from peer to peer.

https://x.com/LogarithmicRex/status/1592309373732151296

(3/24) This globally shared computing platform is manifested with the Ethereum Virtual Machine (EVM). Each node is running a copy of the EVM, held in perfect sync with all other nodes via Proof of Stake. 

The state of the EVM is the state of the World Computer.

https://x.com/LogarithmicRex/status/1574618174879735808

(4/24) Within the EVM, there are two types of entities: externally owned accounts (EOAs) and smart contract accounts.

At a high level, think of EOAs like users, smart contracts like applications and transactions as instructions.

https://x.com/LogarithmicRex/status/1859629927265599989

(5/24) Now let's dive in a little deeper into EOAs and look at what kind of data they can store... or more specifically what kind of data they can't.

Put simply, an EOA can only store an $ETH balance - it cannot store a $USDC, $CRV or any token balance.

https://x.com/LogarithmicRex/status/1859273274406076489

(6/24) So what does it mean to "own" a token? If I were to send you 100 $USDT, where is the $USDT that I have, and where does it go when I send it? How does Ethereum know who owns what?

The answer lies in the other kind of account: smart contracts.

(7/24) Here's the tl;dr on smart contracts: they are controlled by code and have the ability to store long term data.

What if we kept the ownership of tokens using the storage capabilities of smart contracts?

https://x.com/LogarithmicRex/status/1859379177662841074

(8/24) Here's how the paradigm works: a smart contract is deployed, representing a token. In the smart contract, there is a database of the current balance of everyone who owns the token. 

Ownership of the token is reflected in the smart contract, not the account that owns it.

(9/24) In order to transfer a token, the smart contract simply updates its database to reflect the transfer.

The token is never "in" any account, it only ever exists within the smart contract. 

(10/24) Now let's discuss ownership. What does it mean to "own" a token if it only exists as a database entry within a specific smart contract.

Simply put, the tokens smart contract will only accept a transaction if the party affected by that transaction signs it.

(11/24) Looking at our example, the transaction is a transfer of 25 newUSD from Vitalik to Bob. Because Vitalik is the owner of the token, the smart contract will verify Vitalik's signature before updating its database.

(12/24) Not all commands sent to a token's smart contract require the signature of the token's owner - only ones that affect the ownership of the token.

Transferring assets requires the signature of the owner, but anyone can check the balance of an address.

(13/24) This last concept should trigger a thought: how do you know which commands (or functions) require a signature and which ones don't?

But let's generalize the problem... how do you know what functions a smart contract representing a token even has?

(14/24) Here is where token standards come in! Token standards are a set of rules and technical specs that define how tokens operate on Ethereum. 

Token standards define which functions the smart contract needs to support in order to be considered a token!

(15/24) As promised, let's deep dive on the most common, simple token standard: ERC-20.

Across crypto, most tokens conform to the ERC-20 standard (or their equivalent in non-EVM systems).  

(16/24) If a Smart contract implements the following methods and events it can be called an ERC-20 token contract and, once deployed, it will be responsible for keeping track of the created tokens on Ethereum.

Let's take a look at an example!

(17/24) Let's look at the smart contract that represents @LiquityProtocol's $LUSD. Here is the @etherscan link to the contract. 

Etherscan is an incredibly useful tool, but it is very dense. Let's unpack what we've got here.

https://etherscan.io/address/0x5f98805a4e8be255a32880fdec7f6728c6568ba0


(18/24) Here's what you'll see when you click on the link. Here important details in the metadata section:

Blue box - contract address
Green box - the EOA who deployed this smart contract (including its code)
Yellow box - the txn when the contract was deployed

(19/24) In the "Contract" tab you can see the actual code that controls the $LUSD smart contract.

In general, this code is uploaded to Ethereum in a non-human readable form (bytecode). However, most (legitimate) contracts also upload the human readable version to Etherscan.

(20/24) Next to the code tab, you'll see "Read Contract" and "Write Contract." These tabs will give us a list of all the functions this smart contract supports. 

Between the two tabs, you can see all of the functions described in the ERC-20 standards!

(21/24) If you look close enough, you'll see that $LUSD supports more functions that just those outlined in the ERC-20 standard. 

All ERCs just define the minimum functionality that needs to be supported, not the maximum. Many projects build more features (or danger) into tokens.

(22/24) ERC-20 are just the first of the Ethereum token standards. There are many more in use, and many more being proposed. 

Across all token standards, the principle is the same: to be that kind of token, a smart contract must implement all the functions in the standard.

https://x.com/LogarithmicRex/status/1553982842232717313

(23/24) If you want to dig even deeper on ERC, may I recommend this podcast episode.

Last year I had the honor of interviewing @joeysantoro_eth on ERC-4626 and how ERCs come to life. Very much worth your time!

https://x.com/StrangeH2OPod/status/1720060253364961449

(24/24) To summarize, tokens do not exists in Ethereum accounts, rather they exist within a smart contract that creates the token and internally manages it. 

 There are many token standards that define a token; a smart contract must conform to a standard be a token.

Understanding Ethereum Tokens

(1/13) Ethereum Precompiles

At the core of @ethereum are precompiled contracts - smart contracts built directly into the Ethereum protocol.  

(2/13) @ethereum is the World Computer, a single, globally shared computing platform that exists in the space between a network of 1,000s of computers (nodes). 

These nodes are real computers in the real world, communicating directly from peer to peer.

https://x.com/LogarithmicRex/status/1592309373732151296

(3/13) This globally shared computing platform is manifested with the Ethereum Virtual Machine (EVM). Each node is running a copy of the EVM, held in perfect sync with all other nodes via Proof of Stake. 

The state of the EVM is the state of the World Computer.

https://x.com/LogarithmicRex/status/1574618174879735808

(4/13) Just like you run programs on your computer, programs run on the World Computer.

Within the EVM, these programs are called smart contracts. Smart contracts deterministically give you the result dictated by its code.

https://x.com/LogarithmicRex/status/1859379177662841074

(5/13) Precompiles are a type of smart contract. But whereas smart contracts are Turing complete (roughly: capable of solving any problem that any other computer can), precompiles are very specific.

Each precompile is created and hyper optimized to perform a specific action.

(6/13) And when I say specific I mean SPECIFIC. They are cryptographic and mathematical operations that would be too costly or slow if written as standard smart contracts. 

So specific and low level that everyday devs don't often deal with them (if ever). 

(7/13) Precompiles are usually used under-the-hood to allow functions that are important for cryptography and security, but would otherwise be too expensive in the EVM.

Indirectly, devs interact with them all the time, for example whenever you are verifying a signed message.

(8/13) With hyper specialization, comes hyper optimization. The implication of hyper optimization is a massive reduction in gas costs.

Gas is the resource that the EVM uses to charge smart contracts for the computational resources they need to execute. 

https://x.com/LogarithmicRex/status/1858932051598336322

(9/13) At this point I wanted to give you a sense of the differences if gas cost between a precompile vs the same functionality deployed as a regular smart contract. However, I must admit that I could not find good numbers. 

Even @ChatGPTapp hedged its answer.

(10/13) Suffice to say that it's much cheaper to use a precompile. Now let's explore why.

To understand, you must first remember the real-world side of Ethereum. Each participant runs a computer; each computer runs two pieces of software (an execution and consensus client).

https://x.com/LogarithmicRex/status/1589807499804176384

(11/13) The EVM exists within the execution client, so that's where we will find our precompiles.

They achieve such efficient performance because they are optimized for and implemented directly in the code of the execution client. They bypass most of the overhead of the EVM.

(12/13) The implication is that the teams who build Ethereum execution clients are forced to implement specific functionality into the EVM.

And so the questions around new precompiles are always about balancing performance vs developer constraints and code bloat.

(13/13) In summary: precompiles are smart contracts that are built into the EVM that are tailor-made and hyper-optimized to a very specific cryptographic and/or mathematical operation. 

They typically operate behind the scenes (even to devs), enabling cryptographic operations.


Ethereum Precompiles

(1/11) Introduction to @ethereum Accounts

What are accounts? How do accounts relate to Ethereum's computation platform? What are the different types of accounts how do they differ?

A thread on what happens inside the EVM.

(2/11) Ethereum is the World Computer, a single, globally shared computing platform that exists in the space between a network of 1,000s of computers (nodes). 

These nodes are real computers in the real world, communicating directly from peer to peer.

https://x.com/LogarithmicRex/status/1592309373732151296

(3/11) This globally shared computing platform is manifested with the Ethereum Virtual Machine (EVM). Each node is running a copy of the EVM, held in perfect sync with all other nodes via Proof of Stake. 

The state of the EVM is the state of the World Computer.

https://x.com/LogarithmicRex/status/1574618174879735808

(4/11) Within the EVM, there are two types of entities: externally owned accounts (EOAs) and smart contracts. Transactions are cryptographically signed messages that contain instructions to update the state of the EVM.

Let's walk through all of these concepts one at a time.

(5/11) First, EOAs. The best way to understand an EOA is that it represents an Ethereum user (human or bot). It is controlled by a private key, and is able to hold/transfer $ETH and trigger smart contracts.

EOAs = blockchain users

https://x.com/LogarithmicRex/status/1859273274406076489

(6/11) Next, smart contracts. The best way to understand a smart contract is to think of them as programs or applications that exist within Ethereum's virtual machine. Unlike EOAs, they are controlled by code and can store arbitrary data.

Smart contracts = blockchain programs

https://x.com/LogarithmicRex/status/1859379177662841074

(7/11) Tl;dr: EOAs are controlled by a private key and can initiate transactions (either transferring $ETH or triggering a smart contract). Smart contracts are controlled by code and can store persistent data.

(8/11) To change something within the EVM, a user (a human or bot), controlling an EOA needs to bundle together a set of instructions and then cryptographically sign it.

These instructions can be as simple as transferring $ETH to triggering a complex smart contract.

https://x.com/LogarithmicRex/status/1568092433803808770

(9/11) If you are technically inclined and want to dive deeper on how Ethereum accounts work and the nuanced differences between EOAs and smart contracts, I recommend this thread.

https://x.com/LogarithmicRex/status/1612265449923956737

(10/11) And if you're looking forward and want to understand one of the major upcoming upgrades to Ethereum and the EVM, make sure you look into account abstraction.

Tl;dr EOAs and smart contracts will collapse into one kind of entity, looking much more like smart contracts

https://x.com/LogarithmicRex/status/1612587312638234626

(11/11) So let's summarize: EOAs are like users, smart contracts are like applications, and transactions are the instructions that facilitate interactions between them on the Ethereum network.

Ethereum Accounts

(1/11) @ethereum 101: Smart Contracts

Your guide to the programs that run on the World Computer.

(4/11) What makes up the EVM's state? First, a definition:

In comp sci, state refers to the stored information at a particular moment that reflects the current condition of a system. For blockchain, blocks represent a snapshot of state; the blockchain is its history.

https://x.com/LogarithmicRex/status/1858551510218789294

(5/11) Within the EVM, there are two major types of entities: EOAs and smart contracts. 

EOAs (Externally Owned Accounts) represent private keys that exists outside of the EVM. In general, we think of these as the human users of Ethereum (although they are often bots). 

(6/11) Smart contracts are programs that live within Ethereum. While there are nuances that separate a generic computer program and a smart contract, at this level we don't need to worry about them.

For now: the EVM is a computing platform, smart contracts are applications.

(7/11) With the correct permissions (eg you cannot withdraw another users @aave deposit) and inputs (eg the tokens you're trying to sell on @Uniswap), a smart contract will deterministically give you the result dictated by its code.

In the EVM, code is law.

(8/11) Under the hood, both EOAs and smart contracts represent two different kinds of accounts within the EVM.

I've linked a technical deep dive here, but we'll through the important takeaways in the next tweet.

https://x.com/LogarithmicRex/status/1612265449923956737

(9/11) Tl;dr: EOAs are controlled by a private key and can initiate transactions (either transferring $ETH or triggering a smart contract). Smart contracts are controlled by code and can store persistent data.

(* EOAs also store a nonce, but that can be safely ignored)

(10/11) An important aspect to understanding the dynamics of the EVM and smart contracts is gas. Gas is a used to price how much it costs to execute a smart contracts code and to store the data it generates.

However, this is out of scope for this thread; deep dive below.

https://x.com/LogarithmicRex/status/1858932051598336322

(11/11) In summary, the best way to understand what a smart contract is to think of them as programs or applications that exist within Ethereum's virtual machine. Unlike EOAs, they are controlled by code and can store arbitrary data.

Smart contracts = blockchain programs

Smart Contracts

(1/14) @ethereum 101: Externally Owned Accounts (EOAs)

A primer on what EOAs represent and how users interact with the World Computer.

(2/14) Ethereum is the World Computer, a single, globally shared computing platform that exists in the space between a network of 1,000s of computers (nodes). 

These nodes are real computers in the real world, communicating directly from peer to peer.

https://x.com/LogarithmicRex/status/1592309373732151296

(3/14) This globally shared computing platform is manifested with the Ethereum Virtual Machine (EVM). Each node is running a copy of the EVM, held in perfect sync with all other nodes via Proof of Stake. 

The state of the EVM is the state of the World Computer.

https://x.com/LogarithmicRex/status/1574618174879735808

(4/14) What makes up the EVM's state? First, a definition:

In comp sci, state refers to the stored information at a particular moment that reflects the current condition of a system. For blockchain, blocks represent a snapshot of state; the blockchain is its history.

https://x.com/LogarithmicRex/status/1858551510218789294

(5/14) Within the EVM, there are two major types of entities: EOAs and smart contracts. 

EOAs (Externally Owned Accounts) represent private keys that exists outside of the EVM. In general, we think of these as the human users of Ethereum (although they are often bots). 

(6/14) Smart contracts are programs that live within Ethereum. While there are nuances that separate a generic computer program and a smart contract, at this level we don't need to worry about them.

For now: the EVM is a computing platform, smart contracts are applications.

(7/14) Under the hood, both EOAs and smart contracts represent two different kinds of accounts within the EVM.

I've linked a technical deep dive here, but we'll through the important takeaways in the next tweet.

https://x.com/LogarithmicRex/status/1612265449923956737

(8/14) Tl;dr: EOAs are controlled by a private key and can initiate transactions (either transferring $ETH or triggering a smart contract). Smart contracts are controlled by code and can store persistent data.

(9/14) *Technically, an EOA stores one more piece of data other than just $ETH balance - the nonce. This is a number that increments every time you execute an Ethereum transaction. 

A fresh EOA will have a nonce of 0. An EOA that's done 10 transactions will have a nonce of 9.

(10/14) The nonce is a counter that ensures Ethereum can determine which txns are valid. Ethereum will reject a txn if its submitted with a nonce lower than a previously accepted txn.

But, tbh, the nonce is a very technical, minor detail. You can safely ignore it.

(11/14) Now you might be noticing something unexpected. If an EOA can only store an $ETH balance, what does it mean for an EOA to "have" a token?

Well that, my friends, requires its own thread. But I'll leave you with a little teaser...

(12/14) An EOA doesn't ever "hold" a token. A token is really a smart contract that tracks its own balances for every EOA that has interacted with the asset.

Eg the $USDC contract has a database of every EOA and records their balance. A transfer just updates this database.

(13/14) Before we go, I'd be remiss not to mention the future of EOAs... or more precisely the fact that they probably wont exist.

In the Ethereum endgame we will have account abstraction, where all accounts will become smart contracts.

But that's a topic for another thread!

https://x.com/LogarithmicRex/status/1612587312638234626

(14/14) In summary, the best way to understand an EOA is that it represents an Ethereum user (human or bot). It is controlled by a private key, and is able to hold/transfer $ETH and trigger smart contracts.

EOAs = blockchain users

Externally Owned Accounts (EOAs)

(1/13) Cryptography Basics: Bits of Security

All cryptography systems are not created equal; some are more efficient and some are quicker, but all need measure how secure they actually are. 

A guide to the unit by which cryptographic security is evaluated.

(2/13) Let's start at the very beginning: the definition of cryptography.

Cryptography is the practice of using mathematical techniques to secure communication/data from unauthorized parties.

While there are many ways to encrypt data, not all methods are equally secure.

(3/13) When designing a cryptographic system, the primary question is "how secure is this system."

We measure the strength of a cryptographic system with a metric called "bits of security." Specifically, it indicates the amount of computation required to break the system.

(4/13) Let's look at perhaps the most simple form of cryptography, a shift cipher (aka a Caeser cipher).

As fans of The Da Vinci Code already know, involves replacing each letter in the original data by a letter some fixed number of positions down the alphabet.

(5/13) For example, let's say you are encrypting a message with a shift cipher with a left shift of 3. If your message has a D, it would be replaced with an A. 

So the message "Ethereum" would encrypt to "Bqebobrj."

(6/13) Obviously "Bqebobrj" is nonsense, and if someone got a hold of it they wouldn't understand what we are talking about... at least, at first.

But cracking this encryption wouldn't be tricky. Especially if the attacker had access to a computer.

(7/13) In the English alphabet, there are only 25 possible shifts (a shift of 0 or 26 leaves the text unchanged). 

In order to crack this code, an attacker can just attempt every possible shift. When the message suddenly makes sense, they know they've cracked the encryption.

(8/13) We call this type of attack a "brute-force attack," which entails systematically trying every possible decryption key (in a shift cipher, the decryption key is the size of the shift - in our example: 3). 

A brute-force attack relies on raw computational power.

(9/13) So, let's evaluate how many bits of security a shift cypher has.

Bits of security are based on the number of possible keys. As mentioned above, for a shift cipher there are 25 possible keys. Converted to binary: log_2 (25) = 4.6439.

Answer: less than 5 bits of security.

(10/13) 5 bits of security isn't much, much more often we are working with 128 or 256.

This chart will give you a rough estimate, in practice attacks would happen much quicker. In particular, parallel processing deployed across huge computing networks.

(11/13) Strictly speaking, bits of security reflect the effort needed to break a system using the best-known attack (not just brute-force).

It can also account for the difficulty of breaking the system via mathematical vulnerabilities or advanced cryptanalysis techniques.

(12/13) As always in life, it's important to think about trade-offs. Bits of security can impact the time to encrypt and decrypt data.

However, the impact is heavily dependent on the encryption system - especially how the underlying algorithm handles larger key sizes.

(13/13) In summary, bits of security measure of the strength of a cryptographic system; they represent the amount of computation needed to break the system.

In general, more bits of security imply longer encrypt/decrypt times, but impacts are highly dependent on the system.

Cryptography Basics: Bits of Security

(1/23) @ethereum Gas and Gas Markets (EIP-1559)

Gas is the mechanism by which (most) blockchains manage computational resources and drive revenue to node operators. Let's dive deep on blockchain fees and the gas market that underpin Ethereum.

(2/23) @ethereum is the World Computer, a single, globally shared computing platform that exists in the space between a network of 1,000s of computers (nodes). 

These nodes are real computers in the real world, communicating directly from peer to peer.

https://x.com/LogarithmicRex/status/1592309373732151296

(3/23) Computation on the World Computer is a globally shared, scare resource. Ethereum must limit the amount of computation possible within a single block in order to maintain decentralization. 

Gas is how we divide up the computational units of the EVM; $ETH is how we price it.

https://x.com/LogarithmicRex/status/1858674708633579806

(4/23) While the thread linked in the tweet above gives you a good understand of what gas is, what is conspicuously absent is any discussion on the market dynamics of gas. So let's dive in.

The Ethereum gas market needs to be split into two eras: before EIP-1559 and after.

(5/23) We'll get to EIP-1559 shortly, but it's worth spending a few moments thinking about how Ethereum worked from genesis (July 2015) until the hard-fork that brought us EIP-1559 (August 2021).

During this first era, while Ethereum gas was simple, it was problematic.

(6/23) Pre EIP-1559, when a user wanted to make a transaction, they would specify the price per gas they were willing to pay.

As this fee was paid directly to the miner (block proposer), who would select txns with the highest gas prices and incorporate them into blocks first.

(7/23) Because users were bidding against each other, gas prices were very unpredictable and fluctuated wildly. Users had to guess how much to pay, risking overpaying or setting a fee too low.

Not only did this lead to incredible volatility, it was just a poor experience.

(8/23) Which brings us to EIP-1559! Delivered via the London hard fork in August 2021, EIP reshaped how Ethereum gas works.

Here is a link to the official specs of the upgrade, but don't worry, we are about to walk through the big changes.

https://eips.ethereum.org/EIPS/eip-1559

(9/23) The most important change that EIP-1559 brought was a restructuring of the gas market. Remember: previously the market was a first-price auction (aka a blind auction). All of the fees were paid directly to the miner.

EIP-1559 created a dual-fee system.

(10/23) Here's how the dual-fee model works:

Base Fee: a mandatory fee, set directly by the EVM based on current market demand. All base fees are burned.
Priority Fee: an optional tip users can add to incentivize block proposers. All priority fees are paid to the proposer.

(11/23) Remember how we mentioned that the pre-EIP-1559 was problematic because it was extremely unpredictable (especially when there was lots of congestion/high demand for the EVM)?

The base fee fixes this by providing a transparent, algorithmically determined price. 

(12/23) If a block is more than 50% full, Ethereum will increase the base fee for the next block. If the block is less than 50% full, Ethereum will decrease the base fee for the next block.

This allows Ethereum to price its computational resources based on real-time demand.

(13/23) Pre-EIP-1559, we talked about how the entire gas fee was given to the miner/block proposer. 

Under EIP-1559, the base fee doesn't go to the miner/proposer; instead it is "burnt." Burning permanently removes it from circulation. Once burnt, it can never be recovered.

(14/23) Understanding the full implication of burning the base fee is a little out of scope for this thread.

Suffice to say that the purpose of the burn is to make $ETH deflationary (increasing the unit price of $ETH) in times of high demand.

(15/23) Let's pause and summarize: the first major change of EIP-1559 was introducing the base fee. The base fee is set by Ethereum based on the current demand for block space. 

The base fee is always burned, removing that $ETH from circulation.

(16/23) Fun fact: before EIP-1559, there was nothing within the protocol that forced gas fees to be paid in $ETH - it was just custom. A user could offer a miner/proposer $USDC (or even something off-chain).

The base fee changed that and formally bound $ETH to Ethereum.

(17/23) Just like EIP-1559 created the base fee, it also created the priority fee. 

The priority fee is very similar to the entire pre-EIP-1559 gas market. Its purpose is to incentivize proposers to include transactions and is paid entirely to them. 

(18/23) Increasing the amount you’re willing to pay for the priority fee makes it more likely that a proposer will include your txn. 

This gives users the flexibility to pay more for faster inclusion and ensures proposers continue to receive compensation (despite the burn). 

(19/23) The last change that EIP-1559 introduced was elastic block sizes. This allows the gas limit of the next block fluctuate based on market demand. 

If there is more demand, the blocks can grow bigger to accommodate.

(20/23) Before EIP-1559, the gas limit was set slowly over time by the block proposers. Each block proposer could adjust the limit by a very small percentage (~.1% per block). 

This is how we grew from a gas limit of 5k (genesis) to ~15MM (at the time of the switch to EIP-1559).

(21/23) The EIP-1559 system set the target gas limit to 15MM gas. When the network is congested, blocks can expand up to 2x (30MM gas). 

When congestion dies down, Ethereum gradually reduces the gas limit until they once again reach the target gas limit.

(22/23) This gives Ethereum the flexibility to surge resources when demand is high without committing to unbounded growth.

And remember, keeping the size of blocks under control is the key to maintaining decentralization and, through it, credible neutrality. 

(23/23) So here are your main takeaways: EIP-1559 introduced the base fee (making gas more predictable and responsive to demand and introducing the burn), the priority fee (tips to incentivize inclusion) and dynamic block sizes (to surge resources in times of high demand).

Ethereum Gas and EIP-1559 Gas Markets

(1/24) @ethereum 101: Gas

Just like the IRL liquid it shares a name with, gas is the fuel that makes the World Computer run. But what really is gas? How does it help regulate computational resources? What are you paying for with every transaction?

Ethereum's energy, explained.

(4/24) Every 12 seconds, Ethereum generates a new block. This block contains a list of all the transactions (computation) that have happened since the last block.

Every node needs to read all of these transactions and mimic the computation to keep its copy of the EVM in sync.

(5/24) And so, it is incredibly important to limit the amount of computation that happens in every block. The more computation per block, the more expensive the computers needed to participate.

The more expensive the computers, the less decentralized Ethereum will be.

(6/24) Now this thread is not the time to dive deep on the important of decentralization (for more info, check the thread at tweet 2). Let's just say it's critically important.

Let's focus on the question at hand: how does Ethereum enforce these limitations?

(7/24) When you are interacting with Ethereum, you are asking the EVM to do computation for you. 

This computation could be simple (send $ETH to @VitalikButerin's account) or complicated (deposit $USDC into @aave, borrow $ETH, deposit into @GMX_IO, buy a 2x $BTC perp, etc).

(8/24) The more complicated the computation, the more real world resources (eg processing power, memory, etc) needed to execute it. And real world resources are finite.

In order to regulate these resources, Ethereum uses a concept called "gas."

(9/24) Here's a simple example: 

Integer addition is easy, while elliptic curve operations are difficult. The former may take 2 processor cycles, while the later might take 2000 cycles. 

And so, we might price addition at 5 gas and an elliptic curve operation at 5000 gas.

(10/24) Side note: in our example, I picked gas costs that roughly matched the resources needed.

That's also how it works in Ethereum (with much more research and precision). Gas costs are decided through social consensus and hardcoded directly into the EVM (execution clients).

(11/24) When you are generating a transaction, you are estimating the amount of computation you need. This will result in a gas price.

For example: an $ETH transfer might cost 21k gas; a @Uniswap swap might cost 230k gas; deploying a @reserveprotocol rToken might cost 9MM gas.

(12/24) Now let's circle back to early in this thread when we spoke about limiting the amount of computation possible in a single block.

Because we've assessed all possible computation within the EVM and assigned a gas price, it becomes pretty simple to limit computation.

(13/24) Ethereum imposes a gas limit, representing the total amount of computation that can fit into each block. 

Block builders can keep adding more transactions to a block until the limit is reached. If the limit is reached, additional txns must be pushed to the next block.

(14/24) Let's refer to our example ($ETH transfer: 21k gas, Uniswap swap: 230k gas, rToken deployment: 9MM gas), and let's say the gas limit is 10MM gas.

A block could contain ~475 $ETH transfers, ~40 swaps, 1 rToken deployment or any combo (as long as the total gas is <10MM).

(15/24) This history of Ethereum's gas limit is pretty interesting. At genesis in 2015, the gas limit was a mere 5k gas. Between 2015 and 2021, the gas limit rose all the way to 15MM.

In August 2021, the entire gas market was completely redesigned with EIP-1559.

(16/24) In fact, EIP-1559 was so transformational to how gas functions on Ethereum that it requires its own dedicated thread. 

Instead, let's turn our attention away from limits and connect gas back to $ETH.

(17/24) Throughout this thread you may have been thinking "I understand that gas is used to regulate the amount of computation that happens within the EVM, but how does it manifest to the users of Ethereum?"

Put simply, computation has a gas price... and gas has an $ETH price.

(18/24) Under the hood, when you send a transaction to Ethereum you are sending two additional pieces of information:

1) the maximum gas you are willing to pay for
2) the amount of $ETH you are willing to pay per unit of gas

(19/24) 

1) max gas

A transaction will fail if it does not have enough gas to cover all the necessary computation. If it runs out of gas, the whole txn reverts.

The txn's maximum gas value is important because estimating the amount of gas a txn needs is not an exact science.

(20/24) 

2) $ETH per gas

While gas isn't a physical object, it's useful to imagine it like gasoline for a car. Just like a car consumes gasoline, the EVM consumes gas to operate.

And just like you buy gasoline from the pump, you are essentially buying gas from Ethereum.

(21/24) This dynamic between gas and $ETH is critically important, but can be hard to understand. There are 2 markets you need to follow when making a txn: $ETH (priced in $) and gas (priced in $ETH). 

Fortunately, wallets like @Rabby_io take care of this behind the scenes.

(22/24) We've spoke a lot about the nature of gas, but let's walk out with some of the benefits. Most importantly, gas is how we meter the computational resources of the EVM.

Also important, gas is incredibly effective at limiting computational waste.

(23/24) Sometimes this waste is accidental or otherwise benign (eg an infinite loop); sometimes it is intentional (eg spam or a DOS attack).

Either way, by requiring a fee proportional to the computation for every txn, computational waste quickly burns itself out. 

(24/24) In summary: Ethereum is a globally shared, scare resource. It must limit the amount of computation possible within a single block in order to maintain decentralization. 

Gas is how we divide up the computational units of the EVM, and $ETH is how we price it.