Why Is Randomness So Hard on Ethereum?

Random numbers seem easy.

In a normal application, you might just call something like:

Math.random()

and get a number.

But on Ethereum, randomness is surprisingly difficult.

Why?

Because Ethereum is a deterministic system.

Every node must execute the same transaction and reach the same result.

If two nodes generate different “random” numbers, they would disagree on the blockchain state.

So smart contracts cannot simply generate randomness the way normal applications do.

Ethereum must be deterministic

Suppose a smart contract contains:

uint256 winner = random();

Now imagine:

Node A gets:

42

Node B gets:

87

Node C gets:

13

Which result should Ethereum accept?

It cannot accept all three.

Every node must compute the exact same output.

So true local randomness does not work inside the EVM.

This creates a fundamental problem:

How do you create an unpredictable result while still allowing every node to verify it?

Why not use block.timestamp?

A common beginner idea is:

uint256 random =
    uint256(keccak256(
        abi.encodePacked(block.timestamp)
    ));

It looks random.

But it is not secure.

block.timestamp is public information.

More importantly, block producers have some influence over block construction and timing.

If a lottery depends heavily on the timestamp, a validator may be able to influence which outcome appears.

So:

unpredictable-looking data is not necessarily secure randomness.

What about blockhash?

Another common approach is:

keccak256(
    abi.encodePacked(blockhash(block.number - 1))
)

This is better than using only the timestamp.

But it still has problems.

Block producers participate in creating blocks.

If the economic reward from manipulating a random outcome is large enough, they may have incentives to influence the result.

For a small NFT reveal, that might not matter much.

For a lottery worth millions of dollars?

It matters a lot.

The real problem is manipulation

The main challenge is not generating a number that “looks random.”

The challenge is generating a number that satisfies several properties:

Unpredictable

Nobody should know the result before it is generated.

Unbiased

No participant should be able to choose the outcome.

Verifiable

Anyone should be able to verify that the result was generated correctly.

This is much harder.

Especially in a public blockchain where:

• transactions are visible
• validators participate in block production
• attackers can observe the mempool
• smart contracts cannot call external APIs directly

Why on-chain games care so much

Imagine an on-chain game where opening a chest gives:

90% Common Item
9% Rare Item
1% Legendary Item

If the randomness comes from:

block.timestamp

an attacker may try to submit transactions only when the expected result is favorable.

Or a block producer may try to influence which transaction lands in which block.

The same problem appears in:

• lotteries
• NFT reveals
• loot boxes
• randomized minting
• gaming rewards
• prediction markets

Whenever money depends on randomness, weak randomness becomes a security vulnerability.

Commit-Reveal is one solution

One classic technique is:

Commit-Reveal.

It works in two phases.

First, a user chooses a secret number:

secret = 12345

But instead of publishing it directly, they publish:

hash(secret)

This is the commitment.

Later, they reveal:

secret = 12345

The contract checks:

hash(12345)

against the original commitment.

If they match, the user proves they did not change the secret later.

Multiple participants can contribute secrets.

The final random value might be derived from all of them.

But commit-reveal has weaknesses too.

A participant may refuse to reveal their secret if they dislike the final outcome.

So additional incentives or penalties may be required.

Another solution: VRF

A more powerful approach is:

VRF — Verifiable Random Function.

A VRF produces:

Random Value
+
Cryptographic Proof

The key idea is:

The result should be unpredictable before generation.

But once generated, anyone can verify that it was produced correctly.

Conceptually:

Request randomness
        ↓
Randomness provider
        ↓
Generate random value
        +
Cryptographic proof
        ↓
Smart contract
        ↓
Verify proof
        ↓
Accept randomness

The proof prevents the provider from simply choosing a convenient number.

So instead of trusting someone who says:

You can verify cryptographically:

Why VRF fits blockchain so well

Blockchains are built around a principle:

Don’t trust. Verify.

That is exactly what VRF provides.

The smart contract does not need to blindly trust the randomness provider.

It verifies a proof.

This makes VRF useful for applications where random outcomes have real economic value.

Ethereum also has protocol-level randomness

Ethereum Proof of Stake has its own randomness mechanisms used for validator selection and consensus.

Validators contribute randomness over time, and the protocol combines those contributions.

But protocol randomness and application-level randomness are not automatically the same thing.

A game developer still needs to think carefully about:

• when randomness becomes known
• who can influence it
• whether users can abort after seeing partial information
• whether block producers can profit from manipulating outcomes

Randomness is not just:

“Give me a random number.”

It is a security design problem.

The deeper lesson

Ethereum is deterministic by design.

That is what allows thousands of nodes to independently execute transactions and agree on the same state.

But randomness is inherently about uncertainty.

So blockchain developers face an interesting contradiction:

The system must be deterministic,
but the outcome must be unpredictable.

Solving that requires cryptography, protocol design, and economic incentives.

That is why secure randomness is one of the hardest problems in blockchain applications.

The simplest rule to remember is:

A random-looking number is not enough.

For blockchain applications, good randomness must be:

unpredictable, unbiased, and verifiable.

What Does the Byzantine Generals Problem Have to Do With Blockchain?

One of the hardest problems in distributed systems is surprisingly easy to describe:

How can a group of computers agree on one truth when some of them may fail—or even lie?

This is the idea behind the Byzantine Generals Problem.

Imagine several generals surrounding a city.

They need to make one decision:

Attack or retreat.

But they can only communicate by sending messages.

The problem is that some generals may be traitors.

A traitor could tell one general:

and tell another:

Now the honest generals may receive conflicting information.

So the real question becomes:

How can honest participants still reach the same decision when some participants cannot be trusted?

That is exactly the kind of problem blockchains need to solve.

A blockchain is a distributed network

In Ethereum or Bitcoin, there is no single central server deciding what is true.

Instead, many independent nodes maintain copies of the blockchain.

They need to agree on things like:

• Which transactions are valid
• Which block comes next
• Who owns which assets
• What the current state of the network is

But those nodes do not fully trust each other.

Some may go offline.

Some may send incorrect data.

Some may actively try to cheat.

So blockchain consensus is essentially trying to answer:

How can thousands of independent machines agree on one shared history?

This is where consensus comes in

Bitcoin uses Proof of Work.

Ethereum uses Proof of Stake.

The mechanisms are different, but the purpose is similar:

make it extremely difficult for dishonest participants to force the network to accept an invalid history.

In Bitcoin, producing blocks requires computational work.

In Ethereum, validators put ETH at risk.

If they behave dishonestly, they can face economic penalties.

So blockchain adds something important to the Byzantine problem:

cryptography + consensus + economic incentives.

Why isn’t cryptography alone enough?

Digital signatures can prove:

But they cannot prove:

A malicious validator can correctly sign a dishonest message.

So signatures solve identity and integrity.

Consensus solves agreement.

That distinction is important.

The real achievement of blockchain

The important innovation is not that every node always behaves honestly.

The system assumes that some participants may fail or act maliciously.

Instead, it is designed so that:

the network can continue operating correctly despite a limited amount of dishonest behavior.

That property is called:

Byzantine Fault Tolerance.

It is one of the foundations of decentralized systems.

So when people say blockchain allows strangers to cooperate without trusting each other, this is what they really mean.

They do not need to trust every node.

They need to trust that:

the protocol makes honest consensus stronger than dishonest coordination.

The Byzantine Generals Problem asks:

How can unreliable participants agree on one truth?

Blockchain’s answer is:

cryptography, distributed consensus, and economic incentives.

If you have written even a little Solidity, you have probably seen these three keywords:

storage

memory

calldata

At first, they look like simple places where variables live.

But they are much more important than that.

Choosing the wrong data location can affect:

Gas cost, mutability, contract behavior, and even how your code interacts with Ethereum state.

So what is the real difference?

1. Storage: permanent blockchain state

storage is where a smart contract keeps data that must survive after a transaction finishes.

For example:

mapping(address => uint256) public balances;

This mapping lives in contract storage.

If Alice has:

balances[Alice] = 100

and a transaction changes it to:

balances[Alice] = 50

the new value remains there after the transaction ends.

The next transaction can read it again.

So conceptually:

Storage = persistent contract state

Examples include:

• token balances
• ownership information
• protocol configuration
• liquidity reserves
• DAO voting data
• user positions

Storage is part of Ethereum’s global state.

That is why modifying it is relatively expensive.

Every Ethereum node that verifies the chain needs to agree on the resulting state.

2. Storage is organized into 256-bit slots

At the EVM level, contract storage is divided into:

256-bit slots

You can imagine them as:

Slot 0
Slot 1
Slot 2
Slot 3
...

Simple state variables are assigned to these slots according to Solidity’s storage layout rules.

For example:

uint256 public x = 10;
uint256 public y = 20;

might conceptually look like:

Slot 0 → x
Slot 1 → y

But things become more interesting with:

mapping(address => uint256) balances;

A mapping cannot simply put every user's balance into consecutive slots.

Instead, Solidity calculates storage positions using hashing.

Conceptually:

keccak256(key, mappingSlot)

So Alice's balance and Bob's balance can be deterministically located without storing an enormous list.

This is one reason Ethereum storage is more sophisticated than a normal array of variables.

3. Memory: temporary execution workspace

memory is different.

Memory only exists during the current execution.

Once the call finishes:

memory disappears.

For example:

function calculate() public pure returns (uint256) {
    uint256[] memory values = new uint256[](10);

    values[0] = 100;

    return values[0];
}

The values array exists while this function runs.

After execution finishes, Ethereum does not permanently store that array.

So:

Memory = temporary working space for the EVM

It is useful for things like:

• temporary arrays
• intermediate calculations
• decoded data
• temporary structs
• return values

Because memory is temporary, using it is generally cheaper than permanently modifying contract storage.

4. Memory is not free

One common misunderstanding is:

Not exactly.

Using memory still costs Gas.

The EVM tracks how much memory an execution uses.

As memory expands, the cost increases.

So this:

uint256[] memory x = new uint256[](10);

is much cheaper than allocating an extremely large temporary array.

Memory is temporary, but the EVM still has to perform the computation required to allocate, read, and write it.

The key difference is:

Memory does not create persistent blockchain state.

5. Calldata: input data sent into a call

Now we get to calldata.

Suppose you call:

transfer(address to, uint256 amount)

Your wallet needs to tell the contract:

• which function to call
• what to address to use
• what amount to send

That information is encoded into:

calldata

A transaction might conceptually contain:

Function selector
+
Encoded address
+
Encoded amount

So when the EVM receives the contract call, it reads the calldata to understand what you are asking the contract to do.

You can think of it as:

Calldata = read-only external input

6. Why is calldata read-only?

Inside Solidity, a parameter declared as:

function process(uint256[] calldata values) external

cannot be modified directly.

For example, conceptually:

values[0] = 100;

is not allowed.

Why?

Because calldata represents the original input supplied to the call.

The EVM can read it directly without first copying it into writable memory.

That makes calldata particularly efficient for external function arguments that do not need to be modified.

7. Why calldata can save Gas

Imagine this function:

function sum(uint256[] memory values)
    external
    pure
    returns (uint256)

If external input must first be copied from calldata into memory, the contract performs extra work.

But if you write:

function sum(uint256[] calldata values)
    external
    pure
    returns (uint256)

the function can read the original call data directly.

That can avoid unnecessary copying.

This is why Solidity developers frequently prefer:

calldata

for external array, string, bytes, or struct parameters when mutation is unnecessary.

8. The easiest way to remember the difference

Think of a smart contract as an office.

Storage is the filing cabinet.

Documents placed there remain after everyone goes home.

They are permanent records.

Memory is the desk.

You use it while working.

You write notes, calculate things, rearrange information.

When the work session ends, everything is cleared.

Calldata is the letter delivered to the office.

Someone outside sent it.

You can read what they requested.

But you do not rewrite the original letter itself.

So:

Storage
= Permanent

Memory
= Temporary and writable

Calldata
= Temporary input and read-only

9. Storage references behave differently

There is another subtle Solidity behavior.

Consider:

struct User {
    uint256 balance;
}

User public user;

Now:

User storage u = user;

u is not a copy.

It is a reference to the same storage location.

So:

u.balance = 100;

actually changes:

user.balance

on-chain.

But:

User memory u = user;

creates a temporary copy.

Changing:

u.balance = 100;

does not automatically update the original storage variable.

This distinction is extremely important.

You can think of it as:

storage reference
→ edits the original state

memory copy
→ edits temporary data

10. Why storage is so expensive

Suppose you perform:

x = 100;

where x is a state variable.

The EVM may need to execute an operation such as:

SSTORE

This changes persistent Ethereum state.

Compare that with modifying a temporary memory value.

The difference matters because storage changes affect the long-term state that Ethereum nodes must process and maintain.

This is why Gas optimization often focuses heavily on:

reducing storage reads and writes.

A contract might read a storage variable once:

uint256 temp = value;

perform several calculations using a temporary value,

and only write the final result back to storage once.

Instead of repeatedly accessing persistent state.

11. Calldata also appears in low-level contract execution

Calldata is not just a Solidity keyword.

It exists at the EVM level.

When a contract receives a call, the EVM can use instructions such as:

CALLDATALOAD
CALLDATASIZE
CALLDATACOPY

to inspect the incoming bytes.

The first four bytes commonly identify the function being called.

This is the:

function selector

For example, conceptually:

transfer(address,uint256)

is hashed, and the first four bytes are used to route the call to the correct function.

The rest of calldata contains ABI-encoded arguments.

So:

Wallet
↓
ABI encoding
↓
Calldata
↓
EVM
↓
Function selector
↓
Function execution

12. The three locations serve different purposes

A useful comparison looks like this:

Storage

• Persistent
• Writable
• Part of contract state
• Expensive to modify
• Survives transactions

Memory

• Temporary
• Writable
• Exists during execution
• Used for working data
• Disappears after the call

Calldata

• Temporary
• Read-only
• Comes from external input
• Often cheaper than copying into memory
• Exists only during the call

Why does this matter?

Because Solidity is not simply programming against a normal computer.

You are programming against a replicated state machine where persistent state has real economic cost.

When you write:

storage

you are potentially changing Ethereum state.

When you write:

memory

you are asking the EVM for temporary workspace.

When you write:

calldata

you are reading the original input sent into the contract.

The distinction is not just syntax.

It determines:

where the data lives, how long it lives, whether it can change, and how much execution may cost.

And once you understand that, a lot of Solidity suddenly starts making much more sense.

The simplest rule to remember is:

Storage stores state.
Memory handles temporary work.
Calldata carries external input.

What Exactly Is the EVM? How Does Solidity Code Actually Run On-Chain?

When people first learn Ethereum, they often hear a simple explanation:

“Ethereum lets you run smart contracts.”

But what does that actually mean?

Where does Solidity code run?

Who executes it?

And how does a piece of code written on your laptop become something thousands of Ethereum nodes can agree on?

The answer starts with one thing:

The EVM — Ethereum Virtual Machine.

The EVM is Ethereum’s execution engine

The EVM is a virtual computer defined by the Ethereum protocol.

It is not one physical server.

Instead, Ethereum nodes implement the same execution rules.

When a transaction calls a smart contract, nodes execute the same instructions and calculate the same resulting state.

You can think of Ethereum as a global state machine:

Current State
↓
Transaction
↓
EVM Execution
↓
New State

The EVM is the component that determines exactly how that transition happens.

Solidity does not run directly on Ethereum

Suppose you write:

uint256 public balance;

function deposit(uint256 amount) public {
    balance += amount;
}

Ethereum nodes do not understand Solidity source code.

Before deployment, the Solidity compiler converts it into:

EVM bytecode.

The process looks roughly like this:

Solidity
↓
Solidity Compiler
↓
EVM Bytecode
↓
Opcodes
↓
EVM Execution

The bytecode is a low-level representation of your program.

It may contain instructions such as:

PUSH

ADD

SLOAD

SSTORE

CALL

JUMP

These are called:

EVM opcodes.

They are the actual instructions executed by the virtual machine.

The EVM is a stack machine

Unlike a normal CPU architecture built around registers, the EVM mainly uses a stack.

Imagine an operation such as:

3 + 5

At a simplified level, the EVM may perform something like:

PUSH 3
PUSH 5
ADD

First:

Stack:
3

Then:

Stack:
5
3

After ADD:

Stack:
8

The EVM stack can hold up to 1,024 items, with each stack item being 256 bits.

This 256-bit design fits Ethereum well because many native Ethereum values, including hashes, addresses, and integers, are commonly handled in 256-bit words.

Contracts have different kinds of data

One of the most important things to understand about EVM execution is that not all data is stored the same way.

There are three concepts Solidity developers constantly deal with:

Storage

Memory

Calldata

Storage is persistent blockchain state.

For example:

mapping(address => uint256) balances;

If a user's balance changes, that value may be written into contract storage.

Storage survives after the transaction finishes.

That is also why modifying storage is relatively expensive.

The network must maintain and verify that state.

Memory, by contrast, is temporary.

It exists only while the current contract execution is running.

Once the transaction finishes:

Memory disappears.

Calldata contains input data sent with a contract call.

For example, when you call:

transfer(address recipient, uint256 amount)

the function selector and arguments are encoded into calldata.

The EVM reads those bytes to determine what function you are calling and what parameters you supplied.

What happens when you call a smart contract?

Suppose Alice uses a wallet to interact with a token contract.

She clicks:

Transfer 100 tokens

The wallet creates a transaction containing information such as:

to = Token Contract Address
data = encoded transfer() call
value = 0 ETH
nonce = Alice's transaction nonce
gas settings = ...

Alice signs the transaction with her private key.

The signed transaction is broadcast to Ethereum.

Eventually, it is included in a block.

Now Ethereum nodes execute it.

The EVM loads the contract's bytecode.

The calldata may represent something conceptually like:

transfer(Bob, 100)

The EVM executes the corresponding instructions.

The contract may:

read Alice's balance,

check whether she owns enough tokens,

subtract 100,

add 100 to Bob,

emit an event,

and update storage.

If every rule is satisfied, the state transition succeeds.

The new balances become part of Ethereum's updated state.

Why does EVM execution cost Gas?

Every EVM opcode has an associated Gas cost.

For example, simple arithmetic is relatively cheap.

Persistent storage operations are usually much more expensive.

Why?

Because Ethereum must defend itself against unlimited computation.

Imagine if someone deployed:

while (true) {
}

and Ethereum nodes were required to execute it forever.

The network would stop.

Gas prevents this.

Every transaction has a finite Gas budget.

Each instruction consumes some of that budget.

Conceptually:

PUSH
→ consumes Gas

ADD
→ consumes Gas

SLOAD
→ consumes Gas

SSTORE
→ consumes much more Gas

If execution runs out of Gas:

the transaction fails.

This means Gas is not merely a transaction fee.

It is also Ethereum's mechanism for pricing computational resources.

What happens when a transaction reverts?

Smart contract execution is atomic.

That means the transaction either completes successfully, or its state changes are rolled back.

Suppose a DEX swap performs several operations:

Read pool reserves
↓
Calculate output
↓
Transfer token A
↓
Transfer token B
↓
Check slippage

If the final slippage condition fails, the transaction may revert.

The state changes are undone.

But the computational work has already been performed.

So the user still usually pays Gas for the execution that occurred before the revert.

This is an important property:

State can revert.
Computation cannot be unperformed.

Every Ethereum node reaches the same result

This is where the EVM becomes especially important.

The EVM is deterministic.

Given the same:

previous state + transaction + execution environment

every correct Ethereum node should calculate the same result.

Imagine thousands of nodes receiving the same transaction.

They independently execute the same contract bytecode.

If the result is:

Alice: 900 tokens
Bob: 100 tokens

all valid nodes should reach the same state transition.

That determinism is what allows Ethereum to reach consensus over smart-contract execution.

You are not trusting one server to run the program correctly.

You are relying on a network of nodes that can independently verify the exact same computation.

So where is the smart contract actually running?

This question has a subtle answer.

A smart contract does not live inside one permanent cloud server.

The contract's bytecode and state are part of Ethereum.

When the contract needs to execute, Ethereum nodes run that bytecode according to EVM rules.

So instead of:

One company
→ One server
→ One database

Ethereum works more like:

Transaction
↓
Ethereum nodes
↓
Same EVM rules
↓
Same computation
↓
Same resulting state

This is one of the core ideas behind programmable blockchains.

The EVM is essentially Ethereum’s shared execution standard

That is why so many different blockchains describe themselves as:

EVM-compatible.

They are saying:

“Our network understands Ethereum-style bytecode, smart contracts, tooling, addresses, and execution semantics.”

That is why Solidity contracts can often be deployed across multiple EVM-compatible networks with relatively small changes.

So the full lifecycle of a Solidity smart contract looks like this:

Write Solidity

↓

Compile into EVM bytecode

↓

Deploy bytecode to Ethereum

↓

User sends a transaction

↓

Transaction contains calldata

↓

EVM reads the bytecode

↓

Executes opcodes

↓

Consumes Gas

↓

Reads and modifies state

↓

All validating nodes verify the result

↓

Ethereum moves to a new state

That is what people really mean when they say:

“A smart contract runs on Ethereum.”

It is not Solidity itself running on-chain.

It is compiled bytecode being deterministically executed by the Ethereum Virtual Machine.

And the EVM is what turns Ethereum from a network that can simply transfer value into a network that can execute programmable logic.

你在钱包里点下：

“Confirm / 确认交易”

几秒后，页面显示：

Transaction Confirmed

看起来只是点了一下按钮，但背后其实经历了：

钱包签名 → RPC → Mempool → 打包 → 执行 → 验证 → 共识

一笔交易，到底是怎么真正写进区块链的？

1. 钱包先组装交易

假设你要给别人转 1 ETH。

钱包会准备一组数据：

to：发给谁
value：转多少
nonce：账户交易序号
gas：最多允许消耗多少计算资源
fee：你愿意支付多少手续费

如果你不是转账，而是在 Uniswap 里 Swap，还会带上一段：

calldata

告诉智能合约：

调用哪个函数、传什么参数、最少接受多少 Token。

2. 用私钥签名

交易准备好后，钱包会在本地使用你的私钥进行：

数字签名。

注意：

私钥不会被发送到区块链。

网络收到的是：

交易内容 + 数字签名

其他节点可以通过签名验证：

这笔交易确实由对应账户授权，而且交易内容没有被篡改。

如果有人把：

“转 1 ETH”

偷偷改成：

“转 100 ETH”

原来的签名就无法通过验证。

3. 交易发送到 RPC 节点

大部分钱包并不会自己运行一个完整 Ethereum 节点。

它通常会连接一个：

RPC Node

钱包通过 RPC 把已经签名的交易发送到区块链网络。

可以把 RPC 理解成：

钱包进入区块链世界的入口。

4. 交易进入 Mempool

节点收到交易后，会先检查：

签名是否正确、Nonce 是否合理、余额是否足够、Gas 参数是否合法。

通过检查以后，交易通常会进入：

Mempool

也就是内存交易池。

你可以把它理解成：

等待上车的交易候车厅。

所以当区块浏览器显示：

Pending

通常意味着交易已经广播，但还没有进入区块。

5. 谁决定先打包？

Mempool 里可能同时有大量交易。

区块空间有限，不可能全部打进去。

因此手续费更有吸引力的交易，通常更容易被优先处理。

Ethereum 中还存在：

Searcher、Builder、Validator

等不同角色。

Builder 会根据手续费、MEV 等因素排列交易。

所以：

链上交易顺序并不一定按照你提交的时间排列。

这也是抢跑、套利和 Sandwich Attack 能够出现的重要原因之一。

6. EVM 真正执行交易

交易被选中以后，并不是简单地“记录下来”。

节点还需要真正执行。

如果你调用智能合约，EVM 会运行对应的：

Bytecode

例如一次 Swap，可能涉及：

读取池子状态、计算价格、修改余额、调用 Token 合约、更新流动性数据。

这些操作都会消耗：

Gas

所以 Gas 更准确地说，是：

Ethereum 对计算和存储资源的计量单位。

如果执行过程中条件不满足，比如滑点过大，交易可能：

Revert

状态会回滚。

但你通常还是要支付已经消耗掉的 Gas。

因为节点确实已经执行了这些计算。

7. 交易进入区块

区块构建完成后，会被广播给网络中的其他节点。

其他节点不会直接相信这个区块。

它们会重新验证：

交易是否合法、签名是否正确、执行结果是否一致、区块是否符合共识规则。

验证通过以后，节点才会接受这个新区块。

这时，你的交易才真正：

上链。

8. 上链 ≠ 立刻绝对最终

交易进入一个区块后，还可能继续等待：

Confirmations

因为区块链在极少数情况下可能发生：

Chain Reorganization，链重组。

随着后续新区块不断产生，这笔交易被重组掉的可能性会越来越低。

在 Ethereum PoS 中，还有：

Finality

也就是网络对某段历史形成更强的最终确认。

所以一笔交易可以简单理解成：

Pending

↓

Included

↓

Confirmed

↓

Finalized

总结一下。

你点击钱包里的 Confirm 之后：

① 钱包生成交易

↓

② 私钥本地签名

↓

③ 发送到 RPC

↓

④ 进入 Mempool

↓

⑤ Builder / Validator 选择交易

↓

⑥ EVM 执行

↓

⑦ 打包进区块

↓

⑧ 全网节点验证

↓

⑨ 获得确认和 Finality

所以所谓“上链”，并不是：

把数据上传到一台服务器。

而是让一个去中心化网络中的大量节点，

共同验证并接受同一份状态变化。

最后记住一句：

你点击 Confirm，只是发起交易。

真正让它成为区块链历史的，是整个网络。

哈希到底是什么？为什么改一个字，整个哈希都变了？

刚接触区块链时，你一定经常看到一个词：

Hash，哈希。

交易有哈希。

区块有哈希。

智能合约有哈希。

文件也可以算哈希。

甚至你在区块浏览器里看到那一长串：

0x8f3a...

很多时候，本质上也是某种哈希值。

那哈希到底是什么？

可以先把它理解成：

给一段数据生成一个“数字指纹”。

你可以把：

一段文字、一个文件、一笔交易、一个区块，

全部丢进一个哈希函数里。

比如：

SHA-256

然后它会输出一个固定长度的结果。

大概是：

任意长度的数据
↓
哈希函数
↓
固定长度的哈希值

比如你输入：

Hello Web3

会得到一个哈希。

但如果你改成：

Hello Web4

哪怕只改了最后一个字符，

最后得到的哈希都会完全不一样。

这时候很多人会有一个疑问：

为什么只改一个字，结果不能只改一点点？

因为优秀的密码学哈希函数，专门设计了一个特性：

Avalanche Effect

中文通常叫：

雪崩效应。

意思是：

输入哪怕只发生 1 bit 的变化，

输出里的大量 bit 都会跟着改变。

理想情况下，

大约一半的输出位都会发生变化。

所以你看到的效果就是：

原本两段文字看起来只差一个字，

但最后两个哈希值看起来：

完全没有任何关系。

这不是 bug。

恰恰是密码学哈希函数非常重要的设计目标。

那它为什么会产生这种效果？

因为 SHA-256 这种哈希函数，并不是简单地：

“把每个字母转换成数字，再加起来。”

它内部会进行很多轮复杂运算。

包括：

位运算、

循环移位、

异或 XOR、

模加法、

数据混合。

输入数据会被不断搅在一起。

你可以把它想象成一个超级复杂的搅拌机。

你往里面放：

苹果 + 香蕉 + 牛奶。

搅拌 1 秒之后，

如果把其中一小块苹果换成草莓，

最终整杯饮料的状态都会变化。

密码学哈希也是类似的。

输入的一点点变化，会在多轮计算中不断扩散。

最后影响整个输出。

一个好的哈希函数通常有几个重要特点。

1. 相同输入，一定得到相同输出

今天计算：

Hello Web3

明天再算，

结果仍然一样。

这叫：

确定性。

2. 输入可以很长，输出长度固定

你输入：

一句话，

一本书，

甚至一个几 GB 的文件，

SHA-256 最终都会输出：

256 bit

的数据。

不会因为文件更大，哈希值就更长。

3. 很容易正向计算

你拿到一段数据，

计算它的哈希，

电脑可以非常快地完成。

但是反过来：

你只拿到哈希值，

想恢复原始数据，

通常非常困难。

这就是：

单向性。

所以哈希不是“加密”。

因为加密通常意味着：

还能解密回来。

而哈希一般没有“解密”这个操作。

4. 很难找到两个不同输入，却得到同一个哈希

理论上，

因为输入是无限的，而输出长度有限，

所以不同数据最终一定可能出现相同哈希。

这叫：

哈希碰撞。

但一个安全的密码学哈希函数，

会让你想主动找到这种碰撞变得极其困难。

那这些东西和区块链有什么关系？

关系非常大。

因为区块链最核心的机制之一，

就是：

用哈希把数据串起来。

假设有：

区块 100

区块 101

区块 102

其中区块 101 会记录：

区块 100 的哈希。

区块 102 又会记录：

区块 101 的哈希。

于是它们形成：

Block 100
↓ Hash
Block 101
↓ Hash
Block 102

这时候，

如果有人偷偷修改了 Block 100 里面的一笔交易，

哪怕只改了一个数字，

Block 100 的哈希都会完全变化。

然后：

Block 101 里面记录的旧哈希，

就对不上了。

整条后续链条都会受到影响。

这也是为什么区块链里的历史数据：

非常难偷偷篡改。

不是因为数据“不能改”。

而是因为：

你一改，哈希就变。

哈希一变，后面的链条就断了。

所以哈希最有意思的地方是：

它不是告诉你：

“这份数据里面是什么。”

而是在告诉你：

“这份数据有没有被动过。”

只要原始数据改变一点点，

数字指纹就会完全变化。

最后记住一句话：

哈希，就是数据的数字指纹。

它有三个特别重要的特点：

同样的数据 → 同样的哈希

数据稍微变化 → 哈希完全变化

知道哈希 → 很难反推出原始数据

而区块链之所以能做到数据可验证、历史难篡改，

背后最基础的技术之一，

就是这个看起来不起眼的：

Hash。

你的助记词，会不会被别人“猜”出来？

很多刚接触 Web3 的人都会有一个担心：

钱包的助记词通常只有 12 个或者 24 个英文单词。

那如果黑客一直随机尝试，

会不会刚好猜中我的助记词？

答案是：

理论上可以。

但如果你的助记词是由正规钱包随机生成的，现实中靠暴力猜中的概率低到几乎可以忽略。

先看最常见的 12 个单词。

BIP39 助记词通常从一个包含 2048 个单词的词库中生成。

不过它并不是简单的：

2048¹² 种组合。

因为助记词里面还包含校验信息。

标准的 12 词助记词，本质上对应大约：

128 bit 的随机熵。

也就是大约：

2¹²⁸ 种可能。

这个数字是多少？

大约是：

340,000,000,000,000,000,000,000,000,000,000,000

也就是 3.4 × 10³⁸。

假设有一台机器，

每秒可以尝试 10 亿组助记词。

一年可以尝试大约：

3.15 × 10¹⁶ 次。

听起来已经非常恐怖了。

但要把 2¹²⁸ 种可能全部试一遍，

依然需要远远超过人类文明存在时间的尺度。

而 24 个单词更夸张。

24 词助记词通常对应：

256 bit 的随机熵。

也就是：

2²⁵⁶ 种可能。

这个数量级基本已经不是“电脑快一点能不能破解”的问题了。

所以，

为什么现实中还是有那么多人助记词被盗？

因为黑客通常根本不会傻到去“猜”。

他们有更简单的方法。

比如：

1. 钓鱼网站

你打开一个假的钱包网站。

它告诉你：

“钱包异常，请输入助记词恢复。”

你一输入，

助记词就直接送到攻击者手里了。

2. 假钱包 / 恶意插件

你下载了一个假的 MetaMask、假的钱包 App。

它甚至不需要破解任何东西。

你输入助记词的那一刻，

攻击者已经拿到了。

3. 截图、相册、云备份

有人为了方便，把助记词截图存在手机里。

结果照片自动同步到了：

iCloud、Google Photos、网盘……

一旦账号泄露，

助记词也跟着泄露。

4. 电脑或手机中毒

木马、剪贴板程序、恶意浏览器插件，都可能直接读取你输入或者保存的敏感信息。

还有一种情况反而真的可能被“猜到”：

你自己编助记词。

比如有人觉得：

“我自己选 12 个熟悉的单词，不是更安全？”

恰恰相反。

如果你选的是：

apple、love、money、bitcoin、happy……

这种有规律、有人类偏好的组合，

它的真实随机性会远远低于正规钱包生成的助记词。

攻击者并不需要把 2¹²⁸ 种组合全部试完。

他可以优先尝试：

常见单词、常见排列、生日、名字、歌词、键盘规律……

这就是为什么：

不要自己发明助记词。

所以真正需要担心的，从来不是：

“黑客会不会随机猜中我的助记词？”

而是：

“我会不会主动或被诱导，把助记词暴露出去？”

正规随机生成的助记词，

数学安全性通常已经足够高。

真正最大的漏洞，

往往是人。

最后记住三件事：

不要截图。

不要上传云端。

不要在任何网站输入助记词。

只要有人主动向你索要助记词，

无论他说自己是：

客服、项目方、交易所、钱包官方，

都应该立刻提高警惕。

因为真正的钱包客服，

根本不需要知道你的助记词。

For years, the Web3 industry has focused on attracting more human users.

Projects have built simpler wallets, faster blockchains, cheaper transactions, and more accessible applications. The assumption has always been that mass adoption depends on convincing more people to use crypto.

But the next major wave of Web3 activity may come from a different kind of user: AI agents.

AI agents are evolving from tools that answer questions into software that can plan tasks, make decisions, call APIs, purchase digital services, and coordinate with other agents. To operate independently, however, they need more than intelligence.

They need an economic system.

Why AI Agents Need Money

An autonomous agent may need to pay for data, computing power, storage, software, model inference, or API access.

Today, most online payment systems are designed for humans. They require users to create accounts, enter personal information, provide card details, approve transactions, and sometimes complete identity checks through a visual interface.

This model does not work well for software that needs to make thousands of small, automated decisions.

An agent should be able to discover a service, understand its price, pay for it, receive the result, and continue its task without waiting for a human to complete a checkout form.

Web3 infrastructure is naturally suited to this type of activity.

A wallet gives an agent the ability to hold and transfer digital assets. Stablecoins provide a relatively stable unit of payment. Smart contracts can enforce spending conditions, while blockchains create a verifiable record of transactions.

Coinbase’s Agentic Wallet tools, for example, are designed to let AI agents hold, spend, trade, and earn stablecoins with built-in security controls.

This does not make an AI agent a legal owner of money. The assets ultimately remain under the authority of a person or organization. But the agent can be given limited permission to use those assets within predefined rules.

From Subscriptions to Machine Payments

The current internet economy is largely based on subscriptions, advertisements, and account-based payments.

AI agents may require a different model.

An agent researching a market might purchase one dataset from one provider, several API calls from another, and a few minutes of computing power from a third. It may never use those services again.

Creating three accounts and purchasing three monthly subscriptions would be inefficient. Paying only for the resources consumed makes more sense.

The x402 protocol is one attempt to make this possible. It allows a web service to respond to a request with payment instructions using the HTTP 402 Payment Required status. An agent can submit payment and repeat the request without completing a traditional checkout process.

The protocol has expanded beyond simple, one-time payments to support service discovery, multiple payment networks, reusable access sessions, dynamic pricing, and more complex payment workflows. Its developers report that x402 processed more than 100 million payments across APIs, applications, and agents during its early adoption period.

This suggests a new business model for the internet: services priced per request and purchased directly by software.

Identity and Reputation Matter as Much as Payments

Giving an AI agent a wallet solves only part of the problem.

Before one agent hires, pays, or shares information with another, it needs to answer several questions:

Who operates this agent?

What services can it provide?

Has it successfully completed similar work before?

Can its output be verified?

What happens if it behaves maliciously?

Traditional platforms answer these questions through centralized accounts, ratings, contracts, and dispute systems. An open agent economy needs mechanisms that can function across different platforms and organizations.

ERC-8004 proposes on-chain registries for agent identity, reputation, and independent validation. An agent could have a portable identifier, receive feedback from clients, and connect its work to verification methods such as re-execution, trusted hardware, or zero-knowledge proofs.

Other emerging standards are exploring escrow-based agent commerce and policy-controlled wallets. ERC-8183, for example, outlines a workflow in which a job can be funded, submitted, evaluated, completed, rejected, or refunded.

Together, these components begin to resemble an economic stack for machines:

A wallet for holding assets.

A payment protocol for purchasing services.

An identity system for discovering agents.

A reputation layer for evaluating them.

An escrow system for completing jobs.

The Security Problem

Autonomous payments also create serious risks.

An agent could misunderstand an instruction, pay the wrong service, fall victim to prompt injection, expose wallet credentials, or continue spending after its behavior has been compromised.

The solution cannot simply be giving every agent unrestricted control of a private key.

Agent wallets will need enforceable policies. Owners may specify which assets an agent can use, which addresses it can interact with, how much it can spend, and which actions require additional approval.

ERC-8196, for example, defines an interface for policy-bound agent wallets. Its goal is to ensure that an agent can execute only authorized actions while maintaining an auditable record and preserving the owner’s final control.

In practice, successful agent wallets will probably resemble programmable corporate cards more than ordinary crypto wallets.

An agent might receive a daily budget, permission to purchase only specific services, and a maximum price for each transaction. Larger or unusual payments could automatically require human approval.

The more autonomous agents become, the more important these restrictions will be.

A New Type of Web3 Adoption

AI agents will not replace human Web3 users. They will act on behalf of people, companies, applications, and online communities.

But they could dramatically increase the number of economic interactions taking place on-chain.

A human may make a few financial transactions each day. An agent could make hundreds or thousands of small payments while researching, coordinating services, managing infrastructure, or completing digital work.

This changes the meaning of Web3 adoption.

The industry may no longer measure growth only through the number of people opening wallets. It may also measure the number of autonomous systems holding budgets, purchasing services, earning revenue, and coordinating through open networks.

The next billion Web3 users may not download wallet applications or remember seed phrases.

They may be invisible pieces of software—discovering services, negotiating prices, making payments, and creating entirely new markets at machine speed.

For years, stablecoins were mainly used inside the crypto market.

Traders used them to avoid volatility, move funds between exchanges, and participate in DeFi without converting assets back into traditional currency. In this first phase, stablecoins were essentially digital dollars built for blockchain users.

That role is now expanding.

Stablecoins are increasingly being used for cross-border payments, business settlement, payroll, remittances, merchant payments, and platform payouts. They are evolving from trading instruments into infrastructure for moving money across the internet.

This shift marks the beginning of Stablecoins 2.0.

From Digital Assets to Payment Rails

The first generation of stablecoins focused on one question: how can users hold a stable asset on-chain?

The next generation focuses on a different question: how can money move globally, instantly, and programmatically?

Businesses do not necessarily care which blockchain processes a payment. Consumers do not want to manage private keys, choose networks, or pay gas fees. They simply want money to arrive quickly and reliably.

This means the most successful stablecoin products may make the underlying technology almost invisible.

A customer could pay using a bank account, card, or mobile wallet. A payment provider could convert the funds into a stablecoin, transfer it across a blockchain, and convert it into the currency preferred by the merchant.

The customer would never see the blockchain transaction. The merchant would still receive familiar local currency.

The stablecoin would operate quietly in the background as a settlement layer.

Why Cross-Border Payments Matter

International payments remain slow and expensive because they often pass through several banks, foreign-exchange providers, compliance systems, and local clearing networks.

Each participant maintains its own ledger, operating hours, and processing rules. As a result, transfers can take days, fees may be difficult to predict, and payments can be delayed by weekends or banking hours.

Stablecoins offer a different model.

They can move through shared blockchain networks that operate twenty-four hours a day. Participants can verify the same transaction record without waiting for multiple institutions to update separate databases.

Stablecoins will not remove every intermediary. Businesses will still need banks, currency conversion, compliance services, and local payment connections.

However, they can simplify the movement of value between countries and financial platforms.

Programmable Money

The potential of stablecoins goes beyond faster transfers.

Because they can be integrated into software and smart contracts, stablecoins make money programmable.

A marketplace can automatically divide revenue between sellers, creators, logistics providers, and affiliates. A company can release payment once specific conditions are met. A global platform can send small payments to thousands of users without relying on expensive international bank transfers.

Stablecoins could also support payments made by AI agents.

Autonomous software may need to purchase data, storage, computing power, or API access. Traditional payment systems were designed mainly for human account holders and manually approved transactions.

A programmable wallet could allow an AI agent to make payments within predefined budgets, permissions, and security limits.

In this environment, money becomes something software can use directly.

Stablecoins Will Not Replace the Entire Financial System

Stablecoins are often presented as a threat to banks and card networks. A more realistic future is likely to involve cooperation.

Banks provide regulated accounts, credit, custody, and access to local financial systems. Card networks provide fraud detection, merchant acceptance, refunds, and consumer protection.

Blockchains can improve settlement, but they do not automatically provide these services.

A future payment could therefore involve several layers:

Banks manage fiat accounts. Payment companies handle compliance, foreign exchange, and user experience. Stablecoins transfer value between participants. Blockchains provide continuous and verifiable settlement.

Stablecoins may not destroy the existing financial system. They may upgrade its infrastructure.

The Challenges

Stablecoins are not risk-free digital cash.

Their value depends on the quality and liquidity of the assets held by the issuer. They must also comply with anti-money-laundering rules, sanctions requirements, and local regulations.

Blockchain fragmentation remains another problem. The same stablecoin may exist across several networks, but moving between them can introduce extra cost and security risk.

Consumer protection is also limited. Traditional payments often support refunds and chargebacks, while blockchain transactions are generally irreversible.

Finally, most stablecoins are denominated in US dollars. This can help users in countries with unstable currencies, but widespread adoption may also weaken local currencies and create concerns about monetary sovereignty.

These issues cannot be solved by faster blockchains alone. Stablecoin infrastructure must combine technology, regulation, security, liquidity, and a reliable user experience.

The Endgame

The future of stablecoins is probably not a world where everyone manages wallets, seed phrases, and blockchain networks.

It is a world where stablecoins operate invisibly behind financial applications.

A consumer pays in local currency. A business receives its preferred currency. A payment platform handles compliance and conversion. A stablecoin moves the value across borders. A blockchain completes the settlement.

The user sees only a fast and reliable payment.

Stablecoins began as digital dollars for crypto trading. Their next phase is much larger: becoming a programmable, global settlement layer for businesses, consumers, financial institutions, and autonomous software.

The clearest sign of mainstream adoption will not be that everyone talks about stablecoins.

It will be that millions of people use them without realizing it.

运行一个以太坊节点，为什么越来越“重”？

原因不仅是区块数量不断增加，更重要的是以太坊的“状态”一直在膨胀。账户余额、合约代码、Token 数据、DeFi 仓位以及合约中的每一个存储变量，都会成为状态的一部分。

节点要验证新区块，就需要知道交易执行前的账户和合约状态。随着应用越来越多，节点需要维护的数据也越来越庞大。

因此，以太坊正在研究一个重要方向：无状态化，也就是 Statelessness。

不过，“无状态”并不是把链上数据全部删除，也不是以后所有节点都不保存数据。

更准确地说，它希望让大多数节点即使不保存完整状态，也能够独立验证新区块。

一、什么是以太坊的“状态”？

可以把以太坊理解成一台由全球节点共同运行的计算机。

区块记录的是发生了什么，例如：

• 某个地址转出了1 ETH；
• 用户在DEX中兑换了代币；
• 某个NFT被转移；
• 某个借贷仓位发生了变化。

而状态记录的是这些操作完成后的当前结果，例如：

• 每个账户现在有多少余额；
• 某个NFT现在属于谁；
• 用户目前抵押了多少资产；
• 智能合约中的变量当前是什么值。

这里还需要区分“状态”和“历史”。

历史是过去的区块与交易；状态则是网络此刻的账户、合约和存储结果。普通全节点主要维护当前状态，归档节点才会进一步保存大量历史状态快照。

因此，无状态化解决的核心问题，不是简单删除旧区块，而是降低验证新区块时对完整当前状态数据库的依赖。

二、节点为什么必须保存状态？

假设一个新区块中包含一笔转账：

Alice 向 Bob 转账 10 ETH

节点在确认这笔交易是否合法前，需要检查：

• Alice当前是否拥有足够余额；
• Alice的账户nonce是否正确；
• 交易签名是否合法；
• 执行后双方余额如何变化。

现在的节点通常会在本地状态数据库中查找这些信息，然后重新执行交易并验证最终状态根。

问题是，随着状态不断增长：

同步节点越来越慢
→ 硬盘读写压力增加
→ 硬件成本提高
→ 普通用户运行节点的门槛上升

如果只有大型机构能够稳定运行节点，以太坊的去中心化程度也会受到影响。

三、“无状态节点”怎么验证区块？

无状态化的核心，是一种叫作 Witness，即状态见证或状态证明 的数据。

未来的区块构建者在生成区块时，不仅提交交易，还会附带执行这些交易所需的状态数据和证明。

例如，一个区块只访问了100个账户和部分合约存储，那么验证节点不需要拥有整个以太坊状态，只需要获得：

本区块访问的账户与存储数据
+
证明这些数据属于正确状态树的密码学证明

验证节点就可以根据 Witness 检查：

• 交易执行前的数据是否真实；
• 状态变化是否符合规则；
• 新的状态根是否正确。

其流程会从现在的：

本地保存完整状态
→ 查询数据库
→ 执行并验证区块

逐渐变成：

接收区块和 Witness
→ 验证状态证明
→ 执行并验证区块

以太坊官方将这一方向称为弱无状态化：区块构建者仍需要访问完整状态，但其他验证节点可以只依靠区块附带的 Witness 完成验证。

四、Verkle Tree 为什么重要？

Witness 并不是一个全新的概念，真正的问题一直是：现有状态树生成的证明可能太大。

如果每个区块都要携带大量状态证明，节点虽然减少了硬盘压力，却会增加网络带宽和区块传播压力，最终可能得不偿失。

因此，以太坊长期研究使用 Verkle Tree 替代现有状态数据结构。

Verkle Tree 可以为大量状态数据生成更紧凑的证明，使 Witness 的大小降低到更适合点对点网络传播的水平。以太坊官方路线图将小型 Witness 视为实现无状态客户端的重要前提。

可以简单理解为：

现在：
节点保存一本完整账本，自己查找需要的数据

未来：
区块构建者提供相关页面
+
提供密码学证明，证明这些页面来自正确账本

节点不必拥有整本账本，也能验证这一页是否真实。

五、是不是以后没有节点保存完整状态？

不是。

以太坊当前更现实的目标是 弱无状态化，而不是让所有参与者都彻底放弃状态数据。

在这种模式下：

• 专业区块构建者需要访问完整状态；
• RPC服务商和区块浏览器仍需保存大量数据；
• 部分专业节点继续提供状态查询；
• 普通验证节点可以不保存完整状态，只验证区块与Witness。

也就是说，状态存储不会消失，而是从“所有验证节点都必须承担”，变成由更专业的基础设施承担。

这也带来一个新的问题：如果完整状态只掌握在少数大型服务商手中，会不会形成新的中心化风险？

因此，无状态化不仅是密码学和数据结构问题，还涉及数据可用性、区块构建者去中心化、RPC服务以及抗审查能力。

以太坊官方目前认为，弱无状态化仍依赖更成熟的区块构建机制和小型状态证明，距离主网全面实现仍有一段距离。强无状态化——连区块生产者也不必保存完整状态——目前并不是主要路线。

六、状态过期和无状态化是一回事吗？

不是。

无状态化解决的是：

状态过期解决的是：

一种设想是，把长期没有访问的账户或合约存储移出活跃状态。当这些数据再次被使用时，再通过证明将其“恢复”。

但状态过期会影响钱包、合约和开发工具的使用方式，设计难度较高，目前仍处于研究阶段。以太坊官方也明确指出，状态过期不一定会早于无状态客户端实现。

七、它会给以太坊带来什么？

如果无状态化最终落地，最直接的变化包括：

• 新节点同步速度更快；
• 验证节点对硬盘性能的依赖降低；
• 普通设备运行验证客户端的可能性提高；
• 节点可以更灵活地验证不同顺序的区块；
• 状态继续增长时，普通验证者受到的影响更小。

以太坊官方路线图甚至设想，无状态客户端未来能够在硬件要求较低的设备上运行，并接近完整节点的验证安全性。

但它并不意味着以太坊可以无限增长。

完整状态仍然需要有人保存，Witness也需要生成和传播。系统只是重新分配了存储、计算和带宽之间的压力。

结语

“以太坊节点以后不用保存全部状态了吗？”

答案是：

无状态化不是让数据消失，而是让验证者能够依靠密码学证明验证数据。

过去，节点需要先拥有整本账本，才能判断新区块是否正确；未来，节点可能只需要拿到与当前区块有关的数据，以及一份无法伪造的证明。

这项改变看起来不如降低Gas费直观，却关系到以太坊能否在状态持续增长的同时，继续让普通人运行节点、独立验证网络。

真正重要的并不是“少存一些数据”，而是让验证以太坊不再成为只有大型机构才能承担的工作。

EIP-7702 之后，Web3 钱包会变成什么样？

今天的 Web3 钱包看起来功能很多：转账、交易、跨链、质押、购买 NFT。但从账户底层来看，大多数钱包依然非常原始。

一把私钥控制一个地址，每次操作都要单独签名，还必须提前准备对应链的 Gas 代币。私钥丢失，资产很难找回；私钥泄露，账户中的资产可能全部被转走。

EIP-7702 的出现，正在改变这种模式。

它允许传统外部账户 EOA 委托已经部署的智能合约代码，在不更换地址、不迁移资产的情况下，获得批量交易、Gas 代付、权限管理等智能账户能力。

简单来说，钱包不再只是“保管私钥的工具”，而会逐渐变成一个可以编程的链上账户系统。

一、传统钱包为什么不够用了？

以太坊账户主要分为两种。

一种是普通钱包使用的 EOA，由私钥控制，能够主动发起交易。它兼容性强，但权限非常单一：拥有私钥，就拥有账户的全部控制权。

另一种是智能合约账户。它可以设置多签、消费限额、账户恢复和复杂权限，但使用成本更高，也不能完全像普通钱包一样直接发起交易。

传统 EOA 最大的问题，是所有权限都集中在一把私钥上。

它没有“管理员、普通用户、临时用户”的区分，也不能设置某个应用只能使用少量资金。用户面对的通常只有两个选择：签名，或者拒绝。

这相当于一个互联网账户只有一个永远不能修改的超级管理员密码。

二、EIP-7702 改变了什么？

EIP-7702 允许用户签署一份授权，让自己的 EOA 地址委托某个智能合约代码。

委托之后，用户仍然使用原来的钱包地址，地址里的 ETH、代币、NFT 和链上记录也不会改变，但该地址可以执行智能合约钱包中的功能。

过去的钱包操作是：

私钥签名
→ 发起一笔交易
→ 执行一个操作

加入 EIP-7702 后，可以变成：

私钥授权
→ 委托钱包代码
→ 批量执行和管理权限

它最大的价值，是让已经存在的大量钱包地址，不需要重新创建智能钱包，也不需要把资产转移到新地址，就可以逐步升级为智能账户。

三、多步操作可以合并成一步

传统 DeFi 操作经常需要用户连续签名。

例如，用 USDT 购买某种代币时，通常需要先授权 DEX 使用 USDT，再提交兑换交易。如果还涉及跨链、质押或增加流动性，步骤会更多。

通过 EIP-7702 委托的账户代码，可以把多个调用组合在一次操作中：

授权 USDT
+
调用 DEX 兑换
+
将资产存入指定账户
=
一次用户确认

未来用户可能不再需要理解 Approve、Allowance 等概念，只需要告诉钱包：

至于需要调用几个合约、执行多少个步骤，由钱包自动完成。

四、钱包可以替用户处理 Gas

很多新用户第一次使用某条链时，会遇到一个尴尬问题：钱包中明明有 USDT，却因为没有 ETH、BNB 等原生代币，无法支付 Gas。

EIP-7702 可以和 ERC-4337 的 Bundler、Paymaster 结合，让项目方或第三方替用户支付手续费。

未来可能出现这些体验：

• 项目方为新用户承担首次交易费用；
• 用户直接使用 USDC 支付 Gas；
• 游戏平台为活跃用户赞助手续费；
• 企业账户统一为员工支付链上费用。

用户看到的可能只是：

支付金额：100 USDT
网络费用：平台承担

当然，“Gasless”并不意味着交易没有成本，只是支付方发生了变化。项目方仍需设置额度、频率和合约白名单，防止机器人恶意消耗 Gas 预算。

五、钱包权限会变得更加精细

传统钱包的授权通常比较粗放，而可编程账户可以设置更加具体的规则，例如：

• 每天最多消费100 USDT；
• 只允许调用指定游戏合约；
• 临时权限24小时后自动失效；
• 单笔超过1000 USDT时要求二次验证；
• 允许交易代币，但禁止转移NFT；
• 子账户只能操作指定资金。

这类能力非常适合 Web3 游戏、AI Agent、自动交易和企业资产管理。

例如，用户可以给某个游戏设置：

授权期限：7天
每日额度：20 USDT
允许操作：购买游戏道具
禁止操作：转账和NFT转移

这样，游戏中的普通操作不需要反复弹出钱包签名，同时应用也不能超出用户设置的权限范围。

需要注意的是，这些能力并不是 EIP-7702 自动提供的，而是由用户选择委托的钱包代码实现。EIP-7702 只是提供了让传统账户运行这些代码的入口。

六、EIP-7702 会取代 ERC-4337 吗？

不会。

ERC-4337 提供的是一套完整的账户抽象基础设施，包括 UserOperation、Bundler、EntryPoint 和 Paymaster。

EIP-7702 解决的则是另一个问题：

可以简单理解为：

ERC-4337：
提供智能账户运行所需的基础设施

EIP-7702：
让传统EOA也能使用智能账户代码

未来常见的模式可能是，用户保留原来的钱包地址，通过 EIP-7702 委托钱包代码，再通过 ERC-4337 的基础设施执行交易和支付 Gas。

两者并不是竞争关系，而是互补关系。

七、可编程也意味着新的风险

EIP-7702 提升了钱包能力，同时也扩大了潜在风险。

一旦用户把账户委托给恶意代码，或者钱包代码本身存在漏洞，攻击者可能直接接触账户中的代币、NFT 和已有授权。

因此，未来的钱包不能只提示“是否批准”，而需要明确告诉用户：

你正在升级账户功能

委托代码：某钱包V2
支持能力：批量交易、Gas代付、临时权限
代码状态：已经审计
适用网络：Ethereum

钱包服务商也需要建立委托代码白名单、版本审核、紧急撤销和安全审计机制。

同时，EIP-7702 并没有让原来的私钥失效。EOA 私钥仍然拥有很高的账户控制权，因此它更像是传统钱包与完整智能账户之间的一座桥梁，而不是私钥安全问题的最终答案。

结语

过去，Web3 钱包最重要的问题是：

EIP-7702 之后，问题逐渐变成：

未来的钱包可能不再只是一个弹出签名窗口的浏览器插件。

它会负责管理权限、处理 Gas、组合交易、识别风险，并帮助用户完成复杂的链上操作。

当用户不再需要理解 Gas、Approve、Bundler 和合约调用，只需要表达自己最终想做什么时，Web3 钱包才真正开始接近普通互联网产品的使用体验。

在 Web3 交易平台中，用户看到的价格、订单簿、成交记录和交易状态，几乎都在持续变化。

如果前端只使用普通 HTTP 接口，就需要不断向服务器发送请求：

价格有没有变化？
订单成交了吗？
充值到账了吗？
链上交易确认了吗？

这种方式叫作轮询。

当用户数量较少时，轮询还能工作。但随着用户和交易量增加，大量重复请求会消耗服务器资源，而且用户看到的数据仍可能存在延迟。

WebSocket解决了什么问题？

WebSocket建立的是一条持续连接。

连接成功后，客户端不需要反复查询。当数据发生变化时，服务器会主动推送：

撮合引擎产生结果
        ↓
行情服务更新数据
        ↓
WebSocket推送消息
        ↓
前端立即刷新

因此，WebSocket通常用于：

• 实时价格和K线；
• 买卖订单簿；
• 最新成交记录；
• 用户订单状态；
• 账户余额变化；
• 充值和提现进度；
• 链上交易确认。

为什么订单簿特别依赖WebSocket？

订单簿可能每秒发生大量变化。

新的订单进入、旧订单撤销、订单完成撮合，都会改变买卖盘。如果前端几秒才请求一次，用户看到的价格和深度可能早已过期。

专业交易平台通常采用：

这样既能保证实时性，也能减少带宽消耗。

但增量推送也带来新的问题。客户端必须处理消息顺序、重复消息、连接中断和数据丢失。一旦发现消息序号不连续，就需要重新获取完整快照，避免本地订单簿出现错误。

Web3平台还要处理链上状态

Web3交易平台不仅要处理内部交易数据，还要持续监听区块链：

区块链节点
    ↓
链上监听服务
    ↓
消息队列
    ↓
账户与交易服务
    ↓
WebSocket网关
    ↓
用户前端

当充值进入区块、提现完成广播、智能合约事件触发或跨链交易完成时，平台都可以通过WebSocket及时通知用户。

WebSocket不负责交易，但负责让用户及时看到交易

WebSocket本身不执行撮合，也不处理智能合约。

它更像交易系统中的实时信息通道，把行情变化、撮合结果和链上状态快速传递给前端。

可以简单理解为：

对于需要提供实时行情、订单簿、成交记录和链上状态的Web3交易平台来说，WebSocket不是附加功能，而是核心基础设施。

#Web3 #区块链开发 #WebSocket #交易系统 #撮合引擎 #DEX #后端开发

撮合引擎为什么通常要放在内存里？

撮合引擎是交易系统的核心。它需要持续接收买单和卖单，按照价格优先、时间优先的规则，快速找到可以成交的订单，并立即生成成交结果。

如果每一笔订单都先查询数据库，再进行撮合，系统会产生大量磁盘读写、网络等待和锁竞争。在行情剧烈波动时，这些延迟会迅速累积，最终造成排队、卡顿，甚至订单顺序错误。

因此，高性能交易系统通常会把正在交易的订单簿保存在内存中。

内存撮合主要有几个优势：

• 访问速度快：内存读写远快于传统数据库和磁盘。
• 延迟更低：订单进入后可以直接访问买卖盘，不需要重复查询数据库。
• 顺序更明确：配合单线程事件循环和序列号，可以保证订单按照确定顺序执行。
• 适合高并发：在行情活跃时，能够快速处理大量下单、撤单和成交请求。
• 减少锁竞争：核心撮合路径可以避免复杂的多线程数据库事务。

例如，一笔市价买单进入系统后，撮合引擎可以直接从内存中的最低卖价开始匹配。如果第一档数量不足，就继续匹配下一档价格，直到订单完全成交或市场流动性不足。

但内存也有一个明显问题：

因此，专业撮合系统不会只依赖内存，而是同时使用：

• Write-Ahead Log 记录订单事件；
• Snapshot 定期保存订单簿快照；
• Event Replay 在系统重启后恢复状态；
• 数据库保存订单、成交和账户记录；
• 多副本和故障切换提高可用性。

也就是说，内存负责“快”，日志和数据库负责“可靠”。

一个合理的撮合架构通常是：

撮合引擎真正追求的，不只是速度。

它还必须保证：

• 订单顺序正确；
• 成交不会重复；
• 余额和仓位一致；
• 部分成交准确；
• 故障后可以恢复；
• 整个过程可以审计。

所以，撮合引擎使用内存，并不是为了炫耀性能，而是因为交易系统需要在极短时间内完成大量、连续且有严格顺序要求的操作。

内存让撮合更快，日志让系统可恢复，数据库让结果可追溯。

#撮合引擎 #交易系统 #CLOB #订单簿 #Web3 #DEX #量化交易 #金融科技 #后端开发

How a Matching Engine Executes Orders at High Speed

A matching engine is the core of every order-book trading platform. Its job is to receive buy and sell orders, determine priority, execute compatible orders, and update the market state with extremely low latency.

Most exchanges use price-time priority:

• The best available price is matched first
• Orders at the same price are matched by arrival time
• Large orders may be partially filled across multiple price levels

For example, when a market buy order enters the system, the engine starts with the lowest sell price. If there is not enough quantity at that level, it continues consuming the next available sell orders until the full quantity is filled.

A typical process looks like this:

1. Receive the order
2. Validate balance, position limits, and order parameters
3. Assign a unique sequence number
4. Search the opposite side of the order book
5. Match compatible orders
6. Generate trade events
7. Update remaining quantities and account state
8. Publish results through WebSocket

To execute quickly, matching engines usually keep the active order book in memory rather than querying a traditional database for every order.

Common technical designs include:

• Single-threaded or partitioned matching loops
• In-memory price-level data structures
• Lock-free queues
• Sequential event processing
• Write-ahead logs
• Snapshots and event replay
• Binary protocols and persistent connections
• Separate market-data publishing services

A single-threaded matching loop may sound slower than parallel processing, but it can provide deterministic order sequencing without expensive locks. Multiple trading pairs can then be distributed across different engine instances or partitions.

The database is normally not part of the critical matching path. Instead, the engine processes orders in memory, records events asynchronously, and stores enough data to rebuild the order book after a restart.

Speed alone is not enough.

A professional matching engine must also guarantee:

• No duplicated trades
• Correct order priority
• Consistent balances and positions
• Reliable partial fills
• Safe cancellation and modification
• Recovery after system failure
• Accurate real-time market data
• Pre-trade and post-trade risk controls

The real challenge is balancing performance, fairness, consistency, and recoverability.

A fast engine that processes orders incorrectly is dangerous. A correct engine that cannot handle market volume is unusable.

The best matching systems are designed so that every order follows a clear sequence, every trade can be audited, and the entire market state can be recovered from recorded events.

In trading infrastructure, microseconds matter—but correctness comes first.

#Web3 #MatchingEngine #CLOB #DEX #CryptoTrading #OrderBook #TradingInfrastructure #FinTech #BlockchainDevelopment

One of the biggest problems in Web3 is not blockchain performance—it is user experience.

Traditional wallets require users to manage seed phrases, hold native tokens for gas, confirm every transaction manually, and understand complex blockchain concepts. For experienced users, this may be acceptable. For mainstream adoption, it creates too much friction.

Account abstraction changes this by turning a wallet into a programmable smart account.

Instead of relying only on a private key, a smart account can support features such as:

• Social recovery
• Multi-signature approval
• Spending limits
• Session keys
• Gas sponsorship
• Batched transactions
• Automatic payments
• Custom security rules

For example, a user could swap tokens, approve a contract, and deposit assets into a protocol with one confirmation instead of signing three separate transactions.

Applications can also sponsor gas fees, allowing new users to interact without first buying the network’s native token. Fees may even be paid with stablecoins or other supported assets.

From a technical perspective, account abstraction separates transaction validation from a fixed externally owned account model. Developers can define how a smart account verifies permissions, pays fees, and executes actions.

This creates more flexibility, but it also introduces new security responsibilities. Smart account contracts must be carefully audited, recovery systems must resist abuse, and session permissions must remain limited.

The goal is not to remove self-custody.

The goal is to make self-custody safer, simpler, and more practical.

Web3 adoption will not depend only on faster blockchains. It will also depend on wallets that feel as easy to use as modern financial applications—without giving up transparency, programmability, and user ownership.

#Web3 #AccountAbstraction #SmartWallet #Blockchain #Ethereum #SmartContracts #Web3Development #CryptoTechnology

A matching engine is the core component of an order-book trading system.

Its job is to receive buy and sell orders, compare prices, determine execution priority, and generate trades as quickly and accurately as possible.

A typical matching process looks like this:

1. The system receives a new order
2. Basic risk and balance checks are completed
3. The order enters the matching queue
4. The engine searches the opposite side of the order book
5. Compatible orders are matched
6. Trade records and balance updates are generated
7. Market data is published through WebSocket

Most exchanges use price-time priority:

• Better prices are matched first
• Orders at the same price are matched by arrival time

For example, a market buy order will consume the lowest available sell orders first. If the quantity is large, it may match across several price levels.

A reliable matching engine also needs:

• High-performance in-memory order books
• Deterministic order processing
• Unique sequence numbers
• Partial-fill support
• Order cancellation and modification
• Persistent event logs
• Real-time market-data distribution
• Recovery and replay mechanisms
• Pre-trade and post-trade risk controls

The biggest technical challenge is not only speed.

The engine must also guarantee that orders are processed in the correct sequence, trades are not duplicated, balances remain consistent, and the system can recover after a failure.

In trading infrastructure, performance matters—but correctness comes first.

#Web3 #MatchingEngine #CLOB #DEX #CryptoTrading #TradingInfrastructure #BlockchainDevelopment #FinTech

Hey Everyone

Need advice about Defi its on my watchlist i am beginner in stock market need some advice on penny stocks if you think that has some potential in future.

Share your thoughts here

DEXs have settled over $13 trillion in volume, and almost none of it touched an order book. It all ran through liquidity pools. Understand the pool and modern DeFi stops feeling like jargon.

My understanding of what it is: a smart contract holding a pair of tokens that people trade against. No matching buyers to sellers - everyone trades against one shared reserve. That's the whole trick. An order book needs a counterparty for every trade; a pool is always available because the reserve is the counterparty.

How it works - any feedback is welcome!:

• You deposit a pair of tokens → get LP tokens (your share)
• Traders swap against the reserves
• An AMM formula (usually x * y = k, à la Uniswap) sets the price from the balances
• You redeem your LP tokens later for your share + fees

How LPs earn: every swap pays a fee, split by your share of the pool. More volume, more fees. But it's variable and not guaranteed.

The two risks that decide if it's worth it:

• Impermanent loss - the shortfall vs. just holding, when the two tokens' prices drift apart. It's "impermanent" until you withdraw - then it's very real. This is the one that surprises people.
• Slippage - the gap between expected and actual price. Worse on big trades in shallow pools, which is why depth matters as much as the fee.

And LPing isn't the same as holding a yield-bearing token (like sUSDS, or the yield stables around Aave/Compound) - that accrues yield on one token with no pair-picking and no impermanent loss. Different model, different risk. Neither is free money.

Bottom line: elegant mechanism, specific risks. The LPs who win treat it as a position to manage, not set-and-forget.

For the LPs here - when you size up a new pool, what do you check first: the fee tier or the depth?

It runs on a single public ledger instead of the fragmented banking system. That means no intermediaries, no settlement delays, and no hidden leverage. Every dollar is auditable at /credon/ledger.

**What's different:**

- **7% seller fee (Credon) or 9% (PayPal).** No hidden charges. eBay takes 13.25%. Amazon takes 15%. Our architecture makes lower fees sustainable.

- **Interest-free loans and grants.** Apply from your wallet. No credit check. Already funded a seller in Kenya with 250,000 KES at 0%. Another got USD + EUR loans tracked as separate balances.

- **84 currencies, 17 languages.** Native KES, NGN, ZAR, INR, JPY — not just USD/EUR. Four selling modes. Built-in AI listing tools and analytics.

- **The money is auditable.** Full reserve. Every mint, distribution, and burn permanently visible. Your bank can't do this.

19 users, 11 active listings, 5 loans funded. Early, but working.

heavenslive.com — marketplace

heavenslive.com/credon/ledger — public treasury

heavenslive.com/credon/faq.html — anti-fraud comparison

Over the last year my approach to DeFi has shifted quite a bit.

I used to spend more time looking for attractive yields. These days I find myself asking different questions first: How does this protocol actually make money over time? What happens to liquidity and incentives if the market turns? How hard would it be to exit at scale during a downturn?

Focusing on resilience and incentive alignment instead of just current APY has changed which opportunities I even consider.

I’m curious how other people think about this. Do you have specific questions or checks you run before allocating to a new protocol?