传统金融并非与DeFi融合，而是悄然取其精华

银行实际采用的区块链原语、背后的 Solidity 代码，以及保障其安全的安全措施。

简要版

加密领域常说 DeFi 和传统金融将融合成一个开放系统。这种说法基本是错误的。

现实是：银行并不想要 DeFi，他们想要的是区块链。他们采用那些能削减成本、加速结算的部分，并抛弃与受监管机构运营方式相冲突的部分（开放访问、匿名、不可逆的转账）。结果诞生了一个第三类别的产物：可编程金融基础设施，它建立在公共轨道上，但按照机构规则塑造。

设计的检验标准很简单：只有当某个原语能够改善成本、风险或覆盖范围，同时保持控制和问责能力时，机构才会采用它。任何仅通过消除控制来提供价值的东西都会被重塑或拒绝。

记住我以加快登录速度

下面，你将构建两个虽小却真实的合约，了解安全雷区在哪里，并看看哪些项目已经落地这些方案。前提条件：具备 Solidity 基础，熟悉 Foundry 或 Hardhat，以及 OpenZeppelin。

通过测试的原语

四个构建模块脱颖而出。原子结算（交易与支付要么一起完成，要么都不完成，消除对手方风险）。可编程货币（冻结、优惠券等功能以代码形式运行的美元）。许可型转账（资产检查谁被允许持有）。代币化抵押品（国债和基金份额作为代币，可全天候结算）。我们将编写其中最能体现机构约束的两个。

可编程货币

一个可用的机构美元不仅仅是锚定美元的 ERC-20。操作员必须能够在存款时铸造、在接到法律要求时冻结、在发生事件时暂停。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;
import {ERC20} from "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import {ERC20Pausable} from "@openzeppelin/contracts/token/ERC20/extensions/ERC20Pausable.sol";
import {AccessControl} from "@openzeppelin/contracts/access/AccessControl.sol";
contract RegulatedUSD is ERC20, ERC20Pausable, AccessControl {
    bytes32 public constant MINTER_ROLE     = keccak256("MINTER_ROLE");
    bytes32 public constant COMPLIANCE_ROLE = keccak256("COMPLIANCE_ROLE");
    mapping(address => bool) public frozen;
    constructor(address admin) ERC20("Regulated USD", "rUSD") {
        _grantRole(DEFAULT_ADMIN_ROLE, admin);
    }
    function mint(address to, uint256 amt) external onlyRole(MINTER_ROLE) { _mint(to, amt); }
    function freeze(address a) external onlyRole(COMPLIANCE_ROLE) { frozen[a] = true; }
    // 一个Hook函数，在每次转账、铸造和销毁时强制执行所有规则。
    function _update(address from, address to, uint256 value)
        internal override(ERC20, ERC20Pausable)
    {
        require(!frozen[from] && !frozen[to], "账户已冻结");
        super._update(from, to, value);
    }
}

_update Hook是关键。在 OpenZeppelin v5 中，每一次资金流动都会经过它，因此你的规则适用于所有地方，没有任何绕过的方式。注意角色的分离：负责铸造的账户不能执行冻结操作。这种分离是审计人员最常指出的问题。

许可型转账

如果将债券代币化为普通的 ERC-20，任何人都可以接收它。对于受监管的证券，这是一个法律问题，而非功能。如果代币落入未经验证的钱包，转账已经完成且无法撤销。解决方案是采用许可型代币，它在每次转账前检查身份注册表。这是 ERC-3643 背后的核心概念。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;
import {ERC20} from "@openzeppelin/contracts/token/ERC20/ERC20.sol";
interface IIdentityRegistry {
    function isVerified(address wallet) external view returns (bool);
}
contract PermissionedShare is ERC20 {
    IIdentityRegistry public registry;
    constructor(IIdentityRegistry r) ERC20("Tokenized Fund Share", "TFS") { registry = r; }
    function _update(address from, address to, uint256 value) internal override {
        if (from != address(0)) require(registry.isVerified(from), "发送方未验证");
        if (to != address(0))   require(registry.isVerified(to),   "接收方未验证");
        super._update(from, to, value);
    }
}

在生产环境中，你会使用经过审计的 ERC-3643 的 T-REX 实现，它将身份、合规性和代币分离为单独的模块。但这展示了其底层原理：资格验证在代币层面强制执行，因此一个合规资产可以存在于公共链上。

安全考量

你为合规性添加的控制措施也成为了新的攻击目标。最值得关注的故障模式包括：

• 角色混乱。 随着特权角色（铸造者、暂停者、合规者、代理）的增加，权限提升漏洞的概率增长速度快于线性增长。保持角色最小化，并将管理员权限交由多重签名和时间锁控制。
• 绕过合规检查。 攻击者通过中间合约或预先批准的 transferFrom 绕过检查。测试所有限制路径，而不仅仅是直接路径。
• 通过注册表的重入攻击。 调用外部身份合约会打开一扇门。使用“检查-效果-交互”模式和重入锁，并且只信任你所控制的注册表。
• 预言机配置错误。 2026 年 2 月的一次借贷事故分析将重大损失归因于价格公式错误，而非代码漏洞。审查价格推导过程，并强制执行时效性和偏差限制。
• 冻结和强制转账权限。 这些功能设计上可以扣押资产，因此每个控制密钥都是单点故障。用角色保护它们，要求多重签名，并在每次使用时触发事件。

在普通 DeFi 中，合约是完全去信任化的。但在这里，它故意不是去信任化的，所以你的工作是使每个必要的控制点都能被证明是安全的。

这些已经投入运营

代币化的现实世界资产（不包括稳定币）在 2026 年约为 310 亿至 360 亿美元，其中代币化的美国国债约为 120 亿至 130 亿美元。BlackRock 的 BUIDL 基金在八个网络上持有近 29 亿美元，ERC-3643 已被用于在超过 180 个司法管辖区代币化超过 320 亿美元，并得到了 DTCC 和 SEC 的认可。这些参与者都没有围绕 DeFi 的原则重建金融体系。他们正在利用区块链来优化现有业务，使用更好的底层管道。

结论

传统金融并未采纳 DeFi。它正在有选择地采纳区块链中能改善其业务的部分，并放弃其余部分。结果是在开放轨道上形成了一个真正的第三类别。

对于开发者而言，正确的做法不是追逐每一个市场，而是要明确你为哪个市场构建。如果为机构服务，则从第一行代码就开始设计合规性。如果为开放网络构建，则继续发明机构下一步将采用的原语。无论哪种方式，上述底层管道都是基础。确保安全性正确，你就是在构建一个正在悄然上线的基础设施。

• 原文链接： medium.com/@ancilartech/...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～