比特币：数字黄金

比特币诞生于 2009 年，它的设计目标很纯粹：创建一种无需银行即可运作的电子现金系统。

UTXO 模型

比特币使用一种称为 UTXO（Unspent Transaction Output，未花费交易输出）的模型来追踪资产。

用现实世界的类比：想象你的钱包里有三张钞票——一张 50 元、一张 20 元、一张 10 元。你没有一个"余额数字"，你的余额是这些钞票的总和（80 元）。

当你要支付 55 元时，你不能撕开 50 元的钞票。你需要给出 50 元 + 20 元，然后收回 15 元的找零。这笔交易消耗了两张"旧钞票"（UTXO），产生了两张"新钞票"：一张 55 元给收款方，一张 15 元给自己。

交易前:
  Alice 拥有: UTXO_A (50 BTC), UTXO_B (20 BTC), UTXO_C (10 BTC)
  
交易: Alice 向 Bob 支付 55 BTC

交易后:
  UTXO_A 和 UTXO_B 被标记为"已花费"
  创建新的 UTXO_D (55 BTC) 归 Bob 所有
  创建新的 UTXO_E (15 BTC) 归 Alice 所有（找零）
  Alice 仍拥有: UTXO_C (10 BTC), UTXO_E (15 BTC)

UTXO 模型的优点是天然支持并行处理——只要不涉及相同的 UTXO，多笔交易可以同时处理。缺点是编程模型复杂，难以实现复杂的智能合约逻辑。

比特币的局限

比特币的设计是保守的、专注的。它的脚本语言故意设计得非常简单，只支持基本的条件判断，不支持循环，不是图灵完备的。这保证了安全性，但也限制了可编程性。

比特币每秒只能处理约 7 笔交易，区块确认时间约 10 分钟。对于"数字黄金"的定位来说，这足够了。但如果想构建更复杂的应用，就需要新的平台。

以太坊：可编程的区块链

以太坊由 Vitalik Buterin 在 2015 年创立，它的愿景是成为"世界计算机"——一个任何人都可以在上面部署和运行程序的全球平台。

账户模型

以太坊放弃了 UTXO，采用了更接近传统数据库的账户模型：

账户 {
  地址: 0x1234...abcd
  余额: 2.5 ETH
  nonce: 42  // 防止重放攻击的计数器
  代码: (如果是合约账户)
  存储: (如果是合约账户)
}

这看起来是不是很像 Web2 中的用户表？没错，以太坊的账户模型对开发者更加友好，大大降低了智能合约的开发门槛。

以太坊有两种账户：

• 外部账户（EOA）：由私钥控制，类似于用户账户
• 合约账户：由代码控制，类似于自动执行的程序

智能合约

智能合约是部署在区块链上的程序。它们有几个独特的特性：

1. 不可变性：一旦部署，代码无法修改（除非使用特殊的升级模式）
2. 确定性：相同的输入永远产生相同的输出
3. 透明性：任何人都可以查看合约代码和状态
4. 自动执行：满足条件时自动触发，无需人工干预

下面是一个简化的 Solidity 智能合约示例（以太坊的编程语言）：

solidity
// 一个简单的投票合约
contract Voting {
    mapping(address => bool) public hasVoted;
    mapping(string => uint) public voteCount;
    
    function vote(string memory candidate) public {
        require(!hasVoted[msg.sender], "Already voted");
        hasVoted[msg.sender] = true;
        voteCount[candidate]++;
    }
}

这个合约实现了一个简单的投票系统。每个地址只能投一次票，所有投票记录都是公开透明的，没有任何人可以篡改结果。

以太坊的局限

以太坊的 EVM（以太坊虚拟机）是单线程的。所有交易必须串行执行，就像一个只有一个收银台的超市。这导致了严重的可扩展性问题：

• 每秒约 15-30 笔交易
• 网络拥堵时，交易费可能飙升到数十甚至数百美元
• 复杂操作的确认时间可能长达数分钟

这就是为什么我们需要 Solana。

Solana：为规模化而生

Solana 由 Anatoly Yakovenko 在 2020 年推出。Yakovenko 曾在 Qualcomm 工作，拥有深厚的底层系统和电信背景。他的目标是构建一个能够与 Visa 等传统金融基础设施竞争的区块链。

设计哲学：榨干硬件性能

Solana 的设计理念是：摩尔定律会让硬件越来越强大，区块链协议应该能够充分利用这些性能提升。

传统区块链的瓶颈往往不是单机性能，而是节点之间的协调开销。Solana 的创新在于最小化这种开销。

历史证明（Proof of History）

在分布式系统中，"时间"是一个棘手的问题。不同节点的时钟可能不同步，而且我们无法信任任何单一节点报告的时间。传统区块链通过频繁的节点通信来确定事件的顺序，这很慢。

Solana 发明了"历史证明"（PoH）来解决这个问题。它的核心思想是创建一个可验证的时间流：

hash_0 = hash("genesis")
hash_1 = hash(hash_0)
hash_2 = hash(hash_1)
...
hash_n = hash(hash_{n-1})

每次哈希运算需要固定的时间，而且无法并行化。如果你看到 hash_1000000，你就知道自 hash_0 以来已经过去了至少 1,000,000 次哈希运算的时间。

当交易进入系统时，它会被"插入"到这个哈希链的特定位置：

hash_999 = hash(hash_998)
hash_1000 = hash(hash_999 + transaction_data)  // 交易被记录在这里
hash_1001 = hash(hash_1000)

这样，交易的时间顺序就被密码学证明了，无需节点之间反复确认。

并行执行

以太坊的 EVM 是单线程的，因为它无法预知两笔交易是否会访问相同的状态。

Solana 采用了不同的方法：交易必须预先声明它将读写哪些账户。

rust
// Solana 交易必须列出所有涉及的账户
let transaction = Transaction::new_with_accounts(
    &[
        AccountMeta::new(sender, true),       // 可写
        AccountMeta::new(recipient, false),   // 可写
        AccountMeta::new_readonly(system_program, false),  // 只读
    ],
    instructions,
);

有了这个信息，Solana 的运行时（称为 Sealevel）可以分析交易之间的依赖关系：

• 如果两笔交易操作不同的账户集，它们可以并行执行
• 如果它们有交集，则串行执行

这就像一个有 1000 个收银台的超市：只要顾客买的东西不一样，他们可以同时结账。

性能对比

需要注意的是，这些数字是理论峰值或典型值，实际性能会因网络状况而异。