LOREWORD

Ethereum learning path
第十二章 · 第一课 / 12.01

Ethereum learning path · 12.01

当金融规则，变成公开程序。Banks · Smart Contracts · Trust

DeFi 的起点，不是先学会点击某个交易按钮，而是先看清： 银行原本替我们做了什么；当规则搬到以太坊上，我们又开始依赖什么。

PDF syllabus / 正式目录主题从依赖银行到依赖公开智能合约

  • 零基础可读
  • 约 45 分钟
  • 2 个互动实验
  • 6 题校准
Trust topology / 信任拓扑redistributed
DeFi 没有把信任删除；它把一整块机构信任拆成多项技术与治理假设。

01 / Unbundle

“银行”不是一个动作，而是一组角色。

托管、记账、准入、风控、执行、结算与纠纷处理，必须先拆开，才能判断合约究竟替代了哪一部分。

02 / Program

合约替代的是可编码规则，不是整个制度。

它能确定性地检查条件和更新链上状态，却不能自己判断现实世界的真伪，也不会自动提供法律救济。

03 / Trust

更准确的词是“减少并重分配信任”。

代码、升级权限、预言机、代币、前端、RPC 与私钥仍然构成信任面，只是现在可以逐项列出。

01

余额是谁说了算？

你打开银行 App，看见“余额 10,000 元”；你打开钱包，看见“余额 3 ETH”。 两个数字看起来相似，但它们背后的权威来源完全不同。

银行余额通常是机构内部账本对你的一项负债记录。你相信银行正确维护数据库、 执行转账指令、保护账户，并在发生错误时按照法律、监管与内部流程处理。 你并不逐笔验证数据库；你依赖的是机构能力 + 法律关系 + 监督体系。

钱包展示的 ETH 或代币余额，则来自以太坊公共状态。这里还有一个重要区别： ETH 余额是账户状态本身的字段；ERC-20 余额是代币合约依据自身状态返回的结果， 常见实现会把它记录在合约存储的地址映射中，但 ERC-20 标准只规定接口与行为，并不强制 某一种存储布局。[11][12] 节点按照同一协议规则验证交易，合约代码按照输入更新状态；任何人都能从节点读取同一结果。 你不必让某一家机构替你“认证余额”，但你必须依赖另一组条件：密钥没有泄露、客户端遵循协议、 合约逻辑正确、你读取的是正确网络与正确地址。

先记住这句

传统金融主要把账本权威放在机构内部；DeFi 把可结算的资产与规则， 放进多人共同验证的公共状态。

这并不自动说明后一种“更安全”或“更公平”。它只说明验证结构不同： 一边主要问“这家机构是否可信、是否受约束”；另一边还要问 “这段代码、这些权限、这份数据与这把密钥是否可信”。

状态，不是网页

钱包和 DeFi 网页只是读取、解释并发起对链上状态的操作。即使某个网页停止服务， 合约与状态也可能仍在链上；反过来，一个精美网页也不证明它连接的是正确合约。 [4]

02

先把“银行”拆成六项职能

“智能合约替代银行”是一句有方向感、却不够精确的话。银行不是一个按钮； 它是很多职能叠在一起的制度。

Institution bundle

一家机构，六种角色

DeFi 只把其中可被数字化、可由链上状态表达的部分交给程序。

银行同时承担六项彼此不同的金融与制度职能。

合约能搬走什么？

公开智能合约最擅长的是：读取链上可用输入，按确定规则判断条件，随后转移数字资产或 更新合约状态。于是记账、部分托管逻辑、规则执行与链上结算可以合并 在同一次状态转换中完成。

但身份审查、现实资产追索、欺诈调查、争议裁判和法律赔偿，并不会因为部署一段代码而 自动出现。若协议需要房价、天气、公司信用或现实资产所有权，它还必须借助链下机构与 预言机把事实带入链上。

机构式金融
授权
登录、身份验证、内部风控与人工审批。
规则
合同文本、内部系统、运营流程与法律解释共同执行。
账本
机构数据库为主，跨机构结算需要对账和协调。
纠错
可能冻结、撤销、申诉或通过法律程序救济。
合约式金融
授权
私钥签名表达对特定消息或交易的授权。
规则
合约读取当前状态与输入，按代码确定性执行。
账本
资产与协议状态在同一公共系统中更新并由节点验证。
纠错
已最终确定的交易通常难以撤回；是否可暂停或升级取决于预先设计。

不要把“难以撤回”误写成“永远不能改变”

单个已部署合约的字节码不可直接改写，但代理、治理、暂停开关、迁移与协议升级都可能 改变用户最终执行到的逻辑。判断“不可变”时，必须沿着调用链检查权限。 [9]

03

DeFi 到底是什么？

它不是“所有加密货币”，也不是“一个没有公司的金融网页”。DeFi 首先是一套 以公共区块链为结算层的金融协议。

Working definition / 本课定义

DeFi 是以链上资产为对象、以智能合约表达规则、 以公共区块链记录并结算状态、通常由钱包与应用访问的一组金融协议。 [1]

这个定义故意用了“通常”，因为不同项目的去中心化程度差异很大：

协议可能开放

任何地址都能直接调用合约；但某个官方网页仍可能限制地域或停止服务。

资产可能受控

合约本身无需许可，不代表它使用的稳定币或现实资产代币不能被冻结。

规则可能升级

地址长期不变，也可能通过代理把调用转向由治理或管理员选择的新逻辑。

所以，“去中心化”不是贴在产品名字上的二元标签，而是一组可以逐层测量的问题： 谁能调用？谁能升级？谁提供价格？谁发行资产？谁控制界面？谁能暂停？谁承担最终损失？

“无需中介”不等于“没有中间组件”

钱包、RPC 服务、前端、索引器、预言机、治理多签与稳定币发行方都可能参与一笔 DeFi 操作。区别在于：核心资产变动是否必须由某家机构在内部账本上批准，还是任何人都能向 公共合约提交符合规则的交易，并由网络验证结果。

本课建议使用的措辞

与其说“DeFi 消除了信任”，不如说：DeFi 尝试把部分机构信任， 转换为更少、可枚举、可公开检查的技术与治理假设。

04

一笔 DeFi 操作如何发生？

“点击确认”只是入口。真正改变资产状态的，是一条被私钥授权、被网络收录、 被 EVM 执行并被节点验证的交易。[5]

Transaction path / 交易路径

钱包不替你“完成交易”；它帮助你构造并签署一条网络能够验证的指令。

连接、签名、交易、授权：四件不同的事

connect

连接钱包

通常只是让网页知道你的公开地址与所选网络；它本身不等于资产转移。

sign

签署消息

一般不直接改变链上状态，但签名可能成为订单、许可或其他授权凭证，仍需读清内容。

send

发送交易

请求改变链上状态，需要 Gas；成功、失败与实际结果取决于执行时的状态和合约逻辑。

代币授权是一条持续存在的链上状态

ERC-20 的 approve 允许某个 spender 在额度内调用 transferFrom。关闭网页或断开钱包通常不会撤销这项授权； 撤销需要另发一笔改变 allowance 的交易。 [11]

“签名即同意”是自托管的力量，也是责任。银行登录通常授权机构在其系统内执行请求； 私钥签名则直接构成密码学授权。网络只验证签名与规则是否有效，不会判断你是否被钓鱼， 也不会因为交易不划算就替你拒绝。

05

信任没有消失，它去了哪里？

同一个“DeFi”标签下，可以藏着完全不同的控制结构。最有用的分析不是问 “它去中心化吗”，而是把每项依赖画出来。

Interactive lab · Trust surface

切换三种协议结构

固定规则：依赖较少，但如果代码有缺陷，也更难修复。

Assumption map

最小信任表面

规则固定、输入只来自链上；可变性较低，错误的永久性更高。

  • 代码部署后固定
  • 外部数据不依赖预言机
  • 治理权限无升级管理员
  • 使用入口可替换前端或直接调用

Relative exposure

逻辑可变性15
数据依赖10
权限集中10
入口依赖25

上面的数字不是安全评分，只是在表达一个关键事实：减少一种信任，可能增加另一种风险。 不可升级能降低管理员作恶面，却让漏洞难以修补；紧急暂停能限制攻击扩散，却引入谁能按下暂停键的问题； 预言机让合约使用价格，却把数据正确性与及时性带进系统。

从“信任一家银行”到“检查一组假设”

一份严谨的信任清单至少要回答：

代码

源码是否验证？是否审计？调用路径里是否还有未检查的合约？

权限

谁能升级、暂停、改参数、提取费用或更换预言机？是否有多签与时间锁？

数据

价格与现实事实从哪里来？多久更新？异常或停更时系统怎么处理？

资产

代币由谁发行？能否冻结、增发或赎回？其价值依赖什么抵押与法律承诺？

入口

前端、域名与 RPC 是否可能被替换或误导？能否独立核对目标合约？

自己

密钥、签名、授权额度、网络与地址是否正确？最坏情况下愿意损失多少？

06

把 DeFi 看成五层协议栈

“协议还在运行”与“我能安全使用它”不是同一句话。一次操作要穿过多个层次； 每一层都有不同的控制者与故障方式。

DeFi stack / 从入口到结算

上层可以替换，底层提供共同结算；但上层的错误仍能让用户损失资产。

协议、应用与资产不要画等号

协议是链上合约及其状态；应用是帮助人使用协议的界面；资产是被协议处理的代币。 一个协议可以有多个前端，一个前端可以聚合多个协议，一个协议也可以同时依赖多种资产。 判断风险时，必须先说清楚你讨论的是哪一层。

例如，官方网页不可访问不一定意味着协议停止；但普通用户可能因此失去安全、可读的操作入口。 反过来，前端正常加载也不说明底层预言机正在更新，更不说明资产发行方没有冻结权限。

“自托管”也要说完整

自托管通常表示你用自己的密钥发起授权，而不是把账户密码交给平台。但当你把代币存入 协议后，资产可能已经转入合约地址；此后能否取回，取决于合约规则、状态与权限。

07

“公开”究竟公开了什么？

公开智能合约的力量来自可观察、可调用与可组合；但每个“可”字都附带条件。

常见说法真正成立的部分仍需核对的边界
代码公开链上字节码与状态可读取，经过验证的源码可与字节码对应。源码未必验证；验证也不等于审计，更不等于无漏洞。
任何人可用没有访问控制的公共函数可由任意地址提交调用。合约可以有白名单、地域化前端、受控资产或暂停状态。
规则不可改某地址上的已部署字节码不能被直接覆盖。代理可转向新实现；参数、外部模块和治理仍可能变化。
账本透明交易、事件、余额与公开存储可被查询和复算。原始数据不等于人能理解；复杂头寸还需索引、解码与上下文。
无需托管用户可以用自己的密钥授权，不必先把账户交给中心化平台。存入后资产可能由合约控制；授权也可能允许 spender 转移代币。
自动执行一旦被调用，合约会按规则确定性运行。合约不会自己“醒来”；需要交易、其他合约或自动化服务触发。

可验证，不等于已经被你验证

公开系统把验证的可能性给了每个人，却没有把验证成本降为零。字节码、代理槽位、多签门限、 时间锁、预言机更新频率与代币权限都需要工具和知识解释。多数用户仍依赖钱包提示、区块浏览器、 审计报告与专业研究者。

因此，透明度不是安全证书，而是一种更强的问责与独立核验条件。 它能让错误更容易被发现，也能让同一错误被更多组合协议同时继承。

三条不能互相推出的结论

源码已验证 ≠ 代码安全；通过审计 ≠ 没有漏洞；长期运行 ≠ 未来不会失败。

08

可组合性：公开合约像开放 API

当资产和规则都处在同一执行环境里，一个合约可以直接调用另一个合约， 不必先签商业合作协议，也不必让两家机构夜间对账。

开发者可以把兑换、抵押、借贷、份额凭证与资金库等协议当作构件。用户的一笔交易， 也可以连续执行多个步骤。这种“金融乐高”降低了创新门槛，并把不同协议的流动性与功能连接起来。 [6]

Interactive lab · Atomic composition

同一笔交易里的三次调用

三步都成功：整笔交易提交新的最终状态。

上面的失败场景假设第二步的错误向外传播，外层合约没有捕获它：于是整笔交易的状态变更回滚， 但执行消耗的 Gas 仍然支付。现实中，合约可以通过特定写法捕获外部调用失败并继续， 所以“是否全部回滚”最终仍由调用结构与代码决定。

组合能力也会组合风险

如果协议 C 把协议 B 的份额代币当作抵押，B 又依赖协议 A 的价格，那么 A 的数据异常可能 沿组合关系传播到 B 和 C。开放 API 带来正向网络效应，也形成共享依赖与连锁清算。

可组合性的两面

创新速度：无需重新建设全部金融基础设施。
故障半径：上游协议、资产或预言机的错误可以被下游继承。

09

正确执行，也可能正确地让你亏损

区块链能证明一条交易按规则执行，却不能证明规则合理、价格公平、资产可靠， 更不能保证这笔操作适合你。

合约逻辑

CODE

重入、精度、权限、会计或边界条件错误可能让资金被盗、锁死或错误分配。

问：调用链审计了哪些合约？是否有已知限制与漏洞赏金？

升级与治理

CONTROL

代理管理员、治理投票、多签或暂停者可能改变逻辑、参数与可用性。

问：谁能做什么？门限、时间锁和退出窗口是多少？

预言机与数据

DATA

价格偏离、操纵、停更或更新延迟可能触发错误借贷、清算或兑换。

问：数据源、更新条件、异常保护与备用方案是什么？

代币与发行方

ASSET

稳定币脱锚、抵押不足、冻结、增发或赎回失败会传导到使用它的协议。

问：价值来自哪里？谁拥有冻结、铸造与升级权？

市场与流动性

MARKET

价格波动、滑点、挤兑、清算与交易排序会让“代码正确”仍产生糟糕成交。

问：极端行情下的退出深度和最大可接受损失是多少？

前端与节点入口

ACCESS

域名劫持、恶意界面、错误网络或节点返回的误导数据会改变你看到和签署的内容。

问：目标地址能否独立核对？钱包展示是否与意图一致？

密钥与授权

USER

助记词泄露、盲签、无限授权与钓鱼签名可以绕过协议本身的安全设计。

问：spender、额度、期限、收款方和调用函数分别是什么？

底层网络

SETTLEMENT

Gas 暴涨、拥堵、短时重组、客户端故障或扩展层差异会影响可用性与最终性。

问：交易在哪条链结算？紧急时能否及时补仓或退出？

这八层风险可以归入四类：技术风险、经济风险、治理风险、操作风险。 “审计过”主要覆盖技术的一部分；“TVL 很高”只是使用规模；“去中心化”也不会自动解决 市场波动、错误签名或资产发行方风险。

本课不是投资建议

所有数字与场景只用于建立概念。理解协议不等于预测收益；任何链上操作都可能造成 不可逆损失，尤其不要用不理解的签名和授权在真实资产上试验。

10

签名前，用四遍检查代替一次相信

面对任何 DeFi 产品，不需要立刻读完整份源码。先用一套固定顺序，把最危险的混淆排除。

确认你在哪里

  • 域名、网络、链 ID、协议名称是否一致。
  • 合约与代币地址是否来自多个可信来源。
  • 网页连接的是协议本身，还是第三方封装或聚合器。

确认谁能改规则

  • 源码是否验证，入口是否为代理，当前实现地址是什么。
  • 谁能升级、暂停、改费率、更换预言机或提取资产。
  • 多签门限、时间锁、治理投票与紧急权限是否公开。

确认你在授权什么

  • 这是连接、消息签名、代币授权，还是状态交易。
  • 目标合约、函数、金额、收款方、spender、额度和期限。
  • 钱包无法解释的 calldata，不要因为网页文案好看就盲签。

确认最坏结果

  • 价格、流动性、预言机或稳定币异常时会发生什么。
  • 能否退出，退出依赖谁，拥堵时是否来得及。
  • 从小额、独立钱包和有限授权开始，把单次损失限制在可承受范围。

一条可重复的分析句式

Trust statement

“只要 代码 X 正确、权限 Y 不作恶、 数据 Z 及时准确，并且我妥善保管密钥，这项操作就会按所读规则结算。”

如果你无法把 X、Y、Z 具体写出来，就还没有真正理解这个协议的信任边界。 下一课进入 DEX、借贷、稳定币与流动性时，我们会反复使用这条句式。

11

把整课压缩成一条因果链

DeFi 不是从一个网页开始，而是从“谁有权授权、谁执行规则、谁确认状态”开始。

One sentence / 一句话总结

DeFi 把部分金融职能从机构内部流程迁移到公开可执行规则； 它没有让信任消失，而是让信任被拆解、暴露并更容易逐项验证。

六题校准

1. 下列哪项最准确地描述 DeFi 前端与协议的关系？

请选择一个答案。

2. 一段已部署的普通智能合约怎样开始执行？

请选择一个答案。

3. 区块浏览器显示“源码已验证”，能直接推出什么？

请选择一个答案。

4. 为什么“合约地址没变”仍不能证明业务逻辑完全不变？

请选择一个答案。

5. 你给某合约设置代币 allowance 后断开钱包，授权会怎样？

请选择一个答案。

6. 借贷合约需要 ETH 的现实市场价格，哪句话正确？

请选择一个答案。

12

术语与一手资料

先用下面的定义固定语言，再沿官方原文继续深挖。资料链接用于核对机制， 不是为任何协议背书。

核心术语

Custody / 托管
谁实际控制转移资产所需的密钥或合约权限。
Settlement / 结算
资产归属与债权债务在账本中形成最终有效状态的过程。
Permissionless / 无需许可
不经某个管理员逐一批准，符合协议条件的地址即可调用。
Composability / 可组合性
合约可以把其他公开合约作为构件调用或集成。
Oracle / 预言机
把链外数据提交到链上，供合约在共识环境中读取的系统。
Allowance / 授权额度
代币持有人允许 spender 通过 transferFrom 转移的最大额度。
Proxy / 代理
保存入口或状态，并把调用委托给另一份可替换逻辑的合约模式。
Trust-minimized / 最小化信任
减少必须无条件相信的主体，并让剩余假设可检查、可约束。

官方与标准原文

  1. 01ethereum.org · Decentralized finance

    DeFi 的工作方式、分层模型、公开性、非托管与智能合约角色。

  2. 02ethereum.org · Smart contracts

    公开记录、可见条款、确定性，以及原始链上数据仍需工具解释的边界。

  3. 03Introduction to smart contracts

    智能合约作为运行在以太坊上的程序、公开 API 与合约账户。

  4. 04Technical introduction to dapps

    Dapp 由智能合约后端与前端界面组合而成，二者不应画等号。

  5. 05Ethereum transactions

    签名交易、广播、区块收录、EVM 执行与最终性的基本生命周期。

  6. 06Smart contract composability

    合约作为公开 API 被复用和集成，“金融乐高”的技术基础。

  7. 07Ethereum oracles

    合约为何默认无法访问链外信息，以及预言机引入的正确性与可用性问题。

  8. 08Smart contract security

    访问控制、预言机、合约交互与安全开发的主要风险面。

  9. 09Upgrading smart contracts

    代理与其他升级模式如何改变“不可变”的实际含义，以及权限与时间锁的权衡。

  10. 10Introduction to the Ethereum stack

    从 EVM、合约到前端的技术栈，以及公开合约作为持续可用服务的组合方式。

  11. 11EIP-20 · Token Standard

    ERC-20 的 balanceOf、approve、allowance 与 transferFrom 标准语义。

  12. 12ethereum.org · Ethereum accounts

    EOA 与合约账户、ETH 余额、nonce、codeHash 与 storageRoot 等账户状态字段。

Lesson 12.01 / Complete

DeFi 没有把信任归零，它把信任拆开了。