15-ETH-账户

学习视频来源:https://www.bilibili.com/video/BV1Vt411X7JF/?p=15
本博客除了包含自己的在学习过程中记录的笔记外,还包含少部分自己扩展的内容,如有错误,敬请指正。

文章目录

  • [1. 比特币是基于交易的账本模型](#1. 比特币是基于交易的账本模型)
  • [2. 以太坊是基于账户的账本模型](#2. 以太坊是基于账户的账本模型)
  • [3. 以太坊中的两类账户](#3. 以太坊中的两类账户)
    • [3.1 外部账户](#3.1 外部账户)
    • [3.2 合约账户](#3.2 合约账户)
  • [4. 以太坊为什么要设计一个新的模型?](#4. 以太坊为什么要设计一个新的模型?)
    • [4.1 不沿用比特币的原因](#4.1 不沿用比特币的原因)
    • [4.2 稳定身份的现实必要性](#4.2 稳定身份的现实必要性)
  • [5. 以太坊的设计取舍](#5. 以太坊的设计取舍)

1. 比特币是基于交易的账本模型

比特币系统中并没有显式地表示某个账户有多少钱。如果你想知道某个账户有多少钱,需要通过 UTXO(未花费交易输出)来计算。

  • 优点:对账号隐私有一定保护。
  • 缺点:使用不便,不符合日常金融体验。

1.1 不方便点

(1)转账时必须说明资金来源。

例如:A 转给 B 10 个比特币,需指明这 10 个 BTC 来自两个不同的交易(如 7 个 + 3 个)。这与银行完全不同,银行存钱无需说明来源,花钱时也不用追溯来源。

(2)UTXO 必须"全部花完":

  • 若A 转了10个比特币给B。B现在要转 3 个给 C。 若B不将剩余7个"转给自己"(通常用新地址), 则这 7 个会默认作为交易费送给矿工------"矿工狂喜"。现在很多钱包支持"每次交易换一个新地址",即"打一枪换一个地方",增强匿名性。

根本问题是 比特币系统没有显示的维护基于账户的交易的概念。


2. 以太坊是基于账户的账本模型

以太坊采用类似银行的账户模型,每个账户都有明确的余额记录。

2.1 基本操作更直观

  • A转给B 10个以太币,只需检查A的余额是否 ≥10,无需说明资金来源。
  • B后续转3个给C时,也不必处理"找零"------系统自动扣减余额。
  • 比特币中用于追踪来源的哈希指针在以太坊中不再需要。

2.2 安全机制设计

对双花攻击的天然防御

  • 只需检查余额:够就扣,重复花费就扣减2次。

新挑战:重放攻击

  • 攻击场景:A 转账给 B 的交易上链后,B 再次广播同一笔交易。
  • 重放攻击与双花攻击对称:
    • 双花:付款方不诚实;
    • 重放:收款方不诚实。

解决方案:Nonce 机制

  • 每个账户维护一个 nonce(计数器),表示该账户历史上已发出的交易总数。
  • 每笔交易必须包含当前 nonce,并由私钥签名。
  • 例如:第 21 笔交易必须写 nonce=21。签名保护确保 nonce 无法被篡改。
  • 节点维护状态树,其中包含: 账户余额(balance)和nonce 值
  • 执行规则:
    • 初始 nonce = 0;
    • 每成功执行一笔交易,nonce +1;
    • 若收到重复 nonce 的交易(如已执行过 nonce=21),直接拒绝。

注意:这里的 nonce 是 计数器(counter),不是比特币 PoW 中的随机数。


3. 以太坊中的两类账户

3.1 外部账户

  • 由公私钥对控制;
  • 拥有余额和 nonce;
  • 可主动发起交易。

3.2 合约账户

  • 不由私钥控制;
  • 包含4个核心要素:
    • nonce:记录该合约账户创建过的子合约数量;
    • code:部署后不可变的字节码;
    • storage:可读写的持久化存储,随执行而变化;
    • balance:该合约当前持有的 ETH 数量。可变(注意合约账户也是可以有余额的!)
  • 行为限制:
    • 不能主动发起交易(以太坊硬性规定);
    • 只能由外部账户触发;
    • 外部账户可以发起交易,交易中调用合约,合约在被调用时,可通过内部消息(message)调用其他合约。

合约创建时会返回一个固定地址,后续可通过该地址调用其功能。


4. 以太坊为什么要设计一个新的模型?

4.1 不沿用比特币的原因

  • 比特币已有成熟代码,但其 UTXO 模型不适合智能合约。
  • 比特币强调隐私(频繁换地址),但智能合约需要 稳定身份

4.2 稳定身份的现实必要性

  • 类比现实世界:
    若某人以身份 X 与你签合约,事后消失,或另一个人声称"我就是 X,只是换了身份",将导致信任崩溃。
  • 在智能合约场景中问题更严重:
    • 例如:用户投入资金参与价格预测(如期权/期货);
    • 若用户地址频繁变更,合约无法可靠返还收益给用户;
    • 如果资金投入合约中,若合约账户本身"变了"(如地址不固定),问题更严重。

5. 以太坊的设计取舍

综合权衡后,放弃 比特币基于交易的模型,采用基于账户的模型。目前来看比较适合的,因为以太坊是希望账户比较稳定。如果用户有隐私保护方面的需求,可手动创建多个账户,按不同用途或交易使用不同地址。

相关推荐
devmoon18 小时前
Polkadot SDK Pallet 单元测试完整指南:从基础到实战
单元测试·web3·区块链·模块测试·polkadot
devmoon19 小时前
为 Pallet 搭建最小化 Mock Runtime 并编写单元测试环境
开发语言·单元测试·区块链·智能合约·polkadot
晚霞的不甘20 小时前
Flutter for OpenHarmony 打造沉浸式呼吸引导应用:用动画疗愈身心
服务器·网络·flutter·架构·区块链
devmoon21 小时前
Polkadot SDK 自定义 Pallet Benchmark 指南:生成并接入 Weight
开发语言·网络·数据库·web3·区块链·波卡
综合热讯21 小时前
股票融资融券交易时间限制一览与制度说明
大数据·人工智能·区块链
暴躁小师兄数据学院1 天前
【WEB3.0零基础转行笔记】Solidity编程篇-第一讲:简易存储
web3·区块链·智能合约
devmoon1 天前
运行时(Runtime)是什么?为什么 Polkadot 的 Runtime 可以被“像搭积木一样”定制
开发语言·区块链·智能合约·polkadot·runtmie
暴躁小师兄数据学院1 天前
【WEB3.0零基础转行笔记】Rust编程篇-第一讲:课程简介
rust·web3·区块链·智能合约
devmoon1 天前
在 Paseo 测试网上获取 Coretime:On-demand 与 Bulk 的完整实操指南
开发语言·web3·区块链·测试用例·智能合约·solidity
devmoon2 天前
在 Polkadot Runtime 中添加多个 Pallet 实例实战指南
java·开发语言·数据库·web3·区块链·波卡