第 1 讲:导论

区块链、货币与金融基础设施

  • 三条逻辑:技术机制 | 金融功能 | 监管框架
  • 三个关键词:共享账本(shared ledger)| 可验证信任(verifiable trust)| 制度创新(institutional innovation)
  • 本讲目标:建立"为什么需要区块链"的分析框架

1.1 课程定位:区块链金融的三层逻辑

  • 技术逻辑:区块链作为分布式账本(DLT),解决记账与共识的技术问题
  • 金融逻辑:聚焦支付(payment)、清算(clearing)、托管(custody)、登记(registry)等基础设施功能
  • 监管逻辑:加密资产如何被纳入法律与政策框架
  • 三条逻辑贯穿课程始终:每讲一个机制,同时追问其金融意义与监管后果
  • 本课程定位于金融视角,非纯技术课,也非纯法律课

1.2 学习目标与能力层次

  • 层次一(理解):准确描述区块链核心机制——共识、账本、智能合约
  • 层次二(分析):用金融基础设施框架拆解具体项目——改造了哪个环节、成本如何变化
  • 层次三(判断):评估区块链方案是否优于传统方案——适用性判断
  • 课堂训练方式:概念提问 + 案例讨论 + 小组展示

1.3 考核方式与本学期安排

  • 成绩构成:

    • 平时参与(讨论、提问、小组展示)约占总评40%,(一次20%,两次35%,三次40%)
    • 课程项目:60%
  • 期末项目二选一:

    • 案例分析
    • 产品/机制设计
    • 研究问题与实证分析

2.1 课程全景图:16讲知识地图

  • 主线一(技术演进):Bitcoin(PoW)-> Ethereum(智能合约)-> Rollup(扩展)-> 模块化区块链
  • 主线二(金融应用):支付与结算 -> 稳定币(stablecoin)-> DEX -> 借贷协议 -> RWA(real-world assets)
  • 主线三(制度与风险):监管合规(regulatory compliance)-> 系统性风险(systemic risk)-> 研究前沿
  • 三条主线的汇合点:机制设计改变金融"基础设施成本结构"

2.2 技术演进路线详解

  • 第1-3讲:导论 + 密码学基础 + 比特币机制(建立概念基础)
  • 第4-6讲:以太坊 + 智能合约 + DeFi(功能拓展)
  • 第7-9讲:Layer 2 + 跨链 + 模块化(扩展性方案)
  • 第10-12讲:稳定币 + CBDC + RWA(金融应用)
  • 第13-16讲:监管 + 风险 + 前沿议题(制度与展望)
  • 逻辑设计:先理解"账本"的本质,再追问"账本之上能做什么"

3.1 什么是区块链金融

  • 区块链不是单一技术,而是一种技术组合:分布式账本(distributed ledger)+ 共识机制(consensus)+ 加密验证(cryptographic verification)+ 激励设计(incentive design)
  • "上链"不是目的,关键在于重构信任与协调机制
  • 金融视角关注的核心对象未变:支付、结算、清算、托管、登记
  • 变化的只是实现方式:从中心化中介切换到协议规则

3.2 区块链金融的技术组合逻辑

  • 分布式账本:多方维护同一份数据,而非各自维护再对账
  • 共识机制:确保各方在无中心协调者的情况下达成一致
  • 加密验证:参与者可自行验证交易有效性,无需依赖中介
  • 激励设计:通过token(代币)奖励诚实行为,惩罚作恶
  • 四者缺一不可:缺少任何一个要素,都不构成"区块链金融"

3.3 界限问题:什么是区块链金融,什么不是

  • 问题:一个使用区块链技术但由单一银行控制的支付系统——算不算区块链金融?
  • 问题:一个去中心化但无金融应用的公链——算不算区块链金融?
  • 课程立场:关注"区块链是否改变了金融基础设施的信任结构",而非技术标签本身
  • 讨论:金融科技(FinTech)中的哪些应用不需要区块链也能实现?

4.1 三层概念:数字货币、加密货币、金融科技

  • 数字货币(Digital Currency):以电子形式存在的价值表征,包括央行数字货币(CBDC)、加密货币、电子货币等
  • 加密货币(Cryptocurrency):数字货币的子集,以密码学保证安全性,以去中心化为核心特征
  • 金融科技(FinTech):技术驱动的金融创新,范畴远大于加密货币——涵盖支付、借贷、保险、监管科技(RegTech)、机器人投顾(robo-advisor)等
  • 三者是同心圆(嵌套)关系,而非并列关系

4.2 交叉关系与边界模糊

  • 区块链是金融科技的重要分支,但金融科技不必然包含区块链
  • 加密货币以区块链为底层,但区块链的应用远不止加密货币
  • 央行数字货币(CBDC)可能使用区块链技术,但设计目标是中心化管控——技术上与加密货币共享工具,制度上截然不同
  • 边界模糊案例:USDT(Tether)——是稳定币(加密货币),也是支付工具(金融科技),也是数字美元(数字货币)
  • 课堂用法:对任何项目,先用三层框架定位,再进行深入分析

4.3 实例辨析:不同类型项目的定位

项目 数字货币 加密货币 金融科技
比特币(Bitcoin) 是(支付科技)
数字人民币(e-CNY)
微信支付
以太坊(Ethereum) 是(ETH) 是(智能合约)
  • 讨论:为什么有些"币"被监管归类为商品(commodity),有些被归类为证券(security)?

5.1 传统金融的记账逻辑:多账本、多中介

  • 传统金融体系依赖分层记账(layered ledger):每家机构维护自己的账本,定期进行对账
  • 一笔跨行交易涉及:客户账(银行A)-> 央行支付系统/清算所 -> 客户账(银行B)
  • 问题1——对账成本:各方账本需定期对账(reconciliation),差错需要人工干预和处理
  • 问题2——信任成本:跨机构协作依赖法律合同、担保、审计、保证金等制度安排
  • 问题3——时间成本:T+1甚至T+2结算在跨境场景中尤为突出,影响资金周转效率
  • 问题4——透明度有限:外部审计只能基于机构提供的内部报表,无法独立验证完整交易链

5.2 区块链的替代方案:共享账本

  • 共享账本(shared ledger):交易各方维护同一份账本,而非各自维护再对账
  • 三个抓手重构成本结构:
    • 可验证性(verifiability):参与者独立验证交易有效性
    • 可追溯性(traceability):从创世区块(genesis block)到最新区块,交易链条完整可查
    • 可编程性(programmability):智能合约(smart contract)自动执行条件逻辑
  • 核心权衡:共享账本降低对账与信任成本,但牺牲了单主体数据库的吞吐效率

5.3 成本结构改变:一个简化比较

成本类型 传统分层账本 区块链共享账本
对账成本 高(多方定期对账) 低(单一名义来源)
信任成本 高(依赖法律/审计) 中(依赖密码/共识)
计算成本 低(中央数据库) 高(全网冗余执行)
结算时间 T+1 ~ T+2 分钟级(区块确认)
  • 讨论:是否所有金融交易都需要共享账本?哪些场景下传统方案仍具优势?

6.1 区块链适用性判断框架

  • 核心前提:是否存在多方协作低信任环境(low-trust environment)
  • 是否需要多个主体共同维护一份不可篡改的记录?
  • 是否有外部审计(external audit)或公开验证的需求?
  • 是否愿意用效率换取去中介化(disintermediation)?

6.2 判断决策树

  • 判断步骤一:是否需要共享数据库?——否 -> 不需要区块链
  • 判断步骤二:是否有多个写者(multiple writers)?——否 -> 传统数据库更优
  • 判断步骤三:写者之间是否互不信任?——否 -> 共享数据库(如联盟链)即可
  • 判断步骤四:是否需要限制读写权限?——是 -> 许可链(permissioned blockchain);否 -> 非许可链(permissionless blockchain)
  • 逻辑来源:WEF(World Economic Forum),Blockchain Beyond the Hype

6.3 适用性讨论:两个场景

  • 场景A:某银行内部的分支机构间结算系统
    • 同一法人主体,不存在信任问题;高性能数据库即可满足需求 -> 不适用区块链
  • 场景B:多家跨境贸易企业之间的信用证(Letter of Credit)流程
    • 多方协作、互不信任、需要共享记录 -> 适用区块链
  • 讨论:供应链金融(supply chain finance)是否适合区块链?判断依据是什么?
  • 提示:适用性判断不是技术问题,而是信任结构与协调成本的经济学问题

7.1 金融基础设施四功能框架

  • 支付(Payment):价值的转移与资金交付——从付款人到收款人的流动性转移
  • 清算(Clearing):交易各方之间债权债务的确认、轧差(netting)与最终结算安排
  • 托管(Custody):资产的保管、权限控制与操作安全管理
  • 登记(Registry):权属确认、变更记录与可追溯链条
  • 这四个功能是拆解任何区块链金融应用的"分析手术刀"

7.2 四功能之间的关系

  • 支付与清算并非同一概念:支付是资金转移行为,清算是结算前的账务确认与风险控制
  • 托管与登记往往绑定:资产需要确认权属(登记)后,才能安全保管(托管)
  • 传统金融中四功能常由不同机构承担:
    • 支付:商业银行
    • 清算:中央对手方(CCP)/ 清算所
    • 托管:托管银行
    • 登记:登记结算机构(如中国结算)
  • 区块链的冲击:一个协议层可以同时实现四功能——这是效率提升的来源,也是风险集中的隐患

7.3 用四功能框架拆解比特币

功能 比特币的实现方式
支付 交易转账——地址到地址的BTC转移
清算 UTXO模型——交易即清算(transaction-is-clearing)
托管 私钥控制(private key custody)——用户自行保管或委托托管商
登记 链上账本——从创世区块到最新区块的完整交易历史
  • 课堂练习:用四功能框架拆解一个你熟悉的区块链项目
  • 关键问题:当所有功能由同一个协议完成,系统性风险如何评估?

8.1 Bitcoin:制度创新的起点

  • 目标:peer-to-peer electronic cash(点对点电子现金)
  • 核心突破:在开放网络中实现无需中心机构的共享记账
  • 白皮书提出的问题:纯点对点支付能否绕过金融机构?
  • 回答:通过密码学证明(proof)与激励机制(incentive)取代中介信任
  • 资料来源:Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System

8.2 核心机制组合

  • PoW(Proof of Work):竞争性记账权——矿工消耗算力求解哈希难题,获胜者获得记账权与区块奖励
  • 链式区块结构(chain of blocks):每个区块引用前一区块的哈希,形成不可篡改的时间序列
  • 激励相容设计(incentive compatibility):诚实记账的收益 > 作恶的收益,使自利行为导向系统安全
  • UTXO模型:交易以UTXO(Unspent Transaction Output)为基本单位,输入必须引用之前未被花费的输出,确保双花攻击(double-spending)不可行
  • 这四者的组合不是技术发明,而是机制设计的制度创新

8.3 比特币的方法论意义

  • 比特币证明了一件事:规则执行可以外包给机制,而非依赖机构
  • 传统金融中,"谁有权记账"由法律授权决定;比特币中,"谁有权记账"由算力竞争决定
  • 这一转变改变了"信任"的定义:从对人的信任(trust in people/institutions)转向对规则的信任(trust in rules/math)
  • 讨论:机器规则的信任是否真的优于制度信任?当规则有漏洞或需要升级时,谁来仲裁?
  • 与课程主线连接:比特币是第3-4讲深度分析的前奏,也是后续智能合约讨论的参照系

9.1 区块链产业版图总览

  • 基础层(Infrastructure Layer):公链(public blockchain)| 联盟链(consortium blockchain)| Layer 2
  • 应用层(Application Layer):支付 | 交易 | 借贷 | RWA | NFT
  • 支撑层(Supporting Layer):钱包(wallet)| 托管(custody)| 审计(audit)| 预言机(oracle)| 数据服务(data service)
  • 三层架构不是固定不变的——Layer 2既是基础层的一部分,也是扩展方案

9.2 层级间的依赖关系与风险传导

  • 依赖关系一:应用层依赖基础层的安全性与去中心化程度
    • 例:DeFi应用的安全上限不超过底层公链的安全边界
  • 依赖关系二:支撑层的服务质量影响应用层的可用性
    • 例:预言机(oracle)提供错误数据会导致智能合约执行错误
  • 风险传导路径:基础层攻击(如51%攻击)-> 应用层资产损失 -> 支撑层信任崩塌
  • 阅读产业结构的方式:不只看赛道名词,更要看"依赖关系"(dependency)与"风险传导路径"(risk transmission)

9.3 产业版图的变化趋势

  • 趋势一:模块化(modular)取代单链整合理念——基础层开始分层
  • 趋势二:传统金融机构入场——托管、ETF、合规服务成为新增长点
  • 趋势三:链上数据服务(如Dune Analytics、Glassnode)从工具属性转向基础设施属性
  • 讨论:产业版图中的哪个环节最有可能被传统金融"接管"而非被颠覆?
  • 提示:产业版图是动态的——今天的结构明年可能完全不同

10.1 主流金融为何重新关注加密资产

  • 第一阶段(2009-2016):被边缘化——支付实验与极客社区,比特币被视为"互联网上的实验货币"
  • 第二阶段(2017-2021):投机泡沫——ICO(Initial Coin Offering)狂热与散户炒作,大量项目缺乏基本面支撑
  • 第三阶段(2022-至今):制度化进入——机构通过合规渠道入场,ETF获批、银行托管、资管产品化
  • 分水岭事件:2024年美国SEC批准比特币现货ETF,标志加密资产正式进入主流金融视野
  • 关注点迁移:从"加密资产是什么"到"如何将其纳入现有金融与监管框架"

10.2 制度化路径:ETF、托管与代币化

  • ETF(Exchange-Traded Fund):比特币现货ETF获批(2024年美国SEC)打开机构合规敞口
  • 托管(Custody):传统托管银行(如BNY Mellon、State Street)开始提供加密资产托管
  • 代币化(Tokenization):RWA(real-world assets)——将传统金融资产(债券、基金、私募股权)以token形式发行和交易
  • 制度化的后果:加密资产市场从一个"平行金融系统"逐步与主流金融基础设施连接
  • 这种连接改善了流动性(liquidity)和合法性(legitimacy),但也引入了传染风险(contagion risk)

10.3 制度化议题讨论

  • 实例1:贝莱德(BlackRock)的比特币ETF(IBIT)——从最大资管公司的视角看加密资产
  • 实例2:摩根大通(JPMorgan)的Onyx网络——用许可链做银行间结算,而非投机
  • 讨论方向:
    • 制度化是加密资产的"成人礼"还是"招安"?
    • 当华尔街控制了比特币的ETF、托管和交易,去中心化还剩多少?
  • 本课程的立场:制度化的后果是开放的学术问题,而非定论

11.1 课程项目类型概述

  • 路径一:案例分析(Case Study)
    • 选取一个区块链金融项目,系统拆解其机制、市场结构、风险与监管
  • 路径二:产品/机制设计(Mechanism Design)
    • 设定目标和约束,设计一个区块链金融产品或机制,并论证可行性
  • 路径三:研究问题与实证分析(Empirical Research)
    • 提出可检验假设,收集数据,进行实证分析并得出结论
  • 三条路径对应三种能力:分析能力、设计能力、研究能力

11.2 各路径的具体要求

  • 案例分析结构:
    • 项目背景与技术架构
    • 市场表现与竞争格局
    • 风险事件与监管回应
    • 评价与讨论(用课程框架)
  • 产品设计结构:
    • 问题定义与目标函数
    • 设计方案(含激励结构)
    • 与现有方案的优劣比较
    • 可行性分析与潜在风险
  • 实证研究结构:
    • 研究问题与假设
    • 数据来源与变量设计
    • 方法与识别策略
    • 结果与讨论

11.3 选题标准与示例

  • 选题标准:
    • 问题清晰 —— 能用一句话说清楚要研究什么
    • 资料可得 —— 有足够的数据或材料支撑分析
    • 结构完整 —— 能形成闭环论证,而非简单描述
  • 本学期可选方向示例:
    • 案例分析:Uniswap的AMM机制 vs 传统订单簿交易所
    • 产品设计:设计一个基于信用评级的DeFi借贷协议
    • 实证研究:ETF获批前后比特币市场波动性与流动性的变化
  • 讨论:选你最感兴趣的区块链金融项目,用一分钟向同学说明你的研究思路

12.1 本讲知识框架回顾

  • 三个关键词:
    • 金融基础设施(financial infrastructure):支付、清算、托管、登记四功能框架
    • 共享账本(shared ledger):降低对账与信任成本的核心手段
    • 制度创新(institutional innovation):区块链是用机制设计替代机构信任的尝试
  • 三个判断问题:
    • 什么情况下需要区块链?-> 多方协作 + 低信任环境 + 共享记录需求
    • 什么情况下不需要?-> 单主体数据库 + 无需外部共识
    • 区块链金融是"技术驱动"还是"制度驱动"?-> 两者兼有
  • 一个分析工具:用"四功能框架"(支付-清算-托管-登记)拆解任何区块链金融项目
  • 一个判断框架:适用性决策树(是否需要共享账本 -> 是否需要多个写者 -> 写者是否互不信任)

12.2 课堂活动:用四功能框架分析一个项目

任务:选择一个你熟悉的区块链金融项目,用"支付—清算—托管—登记"四功能框架分析它改造了哪个环节。

参考案例框架

项目 支付 清算 托管 登记 核心改造
Uniswap 代币兑换 AMM 链上自动清算 用户自托管 链上 LP 凭证 砍掉撮合中介
MakerDAO DAI 转账 CDP 链上清算 用户自托管 链上抵押记录 信用创造去中介
BlackRock BUIDL 代币化份额转让 TA 链上登记 传统托管银行 链上份额登记 缩短结算周期

讨论

  • 有没有一个项目的改造覆盖了全部四个功能?这样的项目风险和优势各是什么?
  • 如果让你从零设计一个区块链金融产品,你优先改造哪个功能?为什么?

12.3 期末项目:从第一周开始的准备建议

三个路径如何起步

路径 本周可做的事 关键问题
案例分析 选定 2-3 个候选项目,用四功能框架初步拆解 这个项目的"改造"是否真的需要区块链?
产品设计 提出一个金融痛点,描述目标函数 现有的中心化方案为何无法解决这个痛点?
实证研究 确定研究问题,开始搜索数据来源 你需要的变量在链上是否可观测?

常见选题陷阱(提前预警)

  • ✗ "区块链在XX中的应用"——过于宽泛,没有具体问题
  • ✗ "DeFi 的未来发展"——无法形成闭环论证
  • ✓ "Uniswap v3 流动性提供者收益的实证分析"——问题清晰、数据可得
  • ✓ "设计一个面向中小企业应收款的代币化融资协议"——目标明确、约束清楚

12.4 阅读建议

  • 必读:Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System
    • 阅读重点:理解问题导向——为什么需要点对点电子现金?解决方案的关键组件是什么?
    • 避免只关注技术细节,要追问"为什么这样设计"
  • 推荐:Narayanan et al., Bitcoin and Cryptocurrency Technologies(导论与制度背景章节)
    • 阅读重点:加密货币的技术基础与经济学逻辑
  • 推荐:Burniske & Tatar, Cryptoassets(2008金融危机背景与叙事框架)
    • 阅读重点:加密资产诞生的制度背景

12.5 下讲预习与课堂讨论

  • 下讲主题:密码学基础与密钥体系(Cryptography & Key Management)
    • 预习问题1:哈希函数(hash function)有哪些性质?为什么它们在区块链中至关重要?
    • 预习问题2:公钥密码学(public key cryptography)如何实现"无需信任的验证"?
    • 预习问题3:如果私钥丢失,资产是否永久损失?有没有恢复机制?
  • 本讲开放讨论
    • 你认为区块链金融是"增量创新"(改善现有)还是"颠覆性创新"(替代现有)?判断依据是什么?

概念解释

深入分析

- 资料来源:原版PPT(旧)p.15(培养目标)

案例/讨论

概念解释

深入分析

## 2.3 知识地图的课堂用法 案例/讨论 - 每讲新主题时,先定位它在16讲地图中的位置 - 三条主线的交叉点往往是重要的研究问题 - 课堂练习:用一个项目(如Uniswap)同时回答三个问题—— - 技术机制是什么? - 实现了什么金融功能? - 面临什么监管问题? - 讨论:如果你只能推荐一讲课程给金融从业者,选哪一讲?为什么? ---

概念解释

- 资料来源:原版PPT(旧)p.20、p.22(区块链技术及其金融应用)

深入分析

案例/讨论

- 资料来源:原版PPT(旧)p.2、p.20(FinTech定义与区块链定位)

概念解释

- 资料来源:原版PPT(旧)p.2(内容概要)

深入分析

案例/讨论

概念解释

深入分析

案例/讨论

概念解释

- 资料来源:原版PPT(旧)p.171(Decision Tree / 适用性判断)

深入分析

- 资料来源:原版PPT(旧)p.172(决策树示意图)

案例/讨论

概念解释

深入分析

案例/讨论

概念解释

- 资料来源:原版PPT(旧)p.150(比特币平台)

深入分析

- 资料来源:原版PPT(旧)p.100(UTXO模型)

案例/讨论

概念解释

- 资料来源:原版PPT(旧)p.170(产业版图)

深入分析

案例/讨论

概念解释

深入分析

案例/讨论

概念解释

- 资料来源:原版PPT(旧)p.16、p.17、p.18(项目类型)

- 资料来源:原版PPT(旧)p.16、p.17、p.18(各类型结构)

案例/讨论

深入分析

案例/讨论