TradFi 含义：传统金融、运作方式及其与链上系统的连接

TradFi 的含义及该术语的来源

TradFi 是 传统金融（traditional finance）的缩写。它指的是大多数人已经在使用的常规金融体系：零售和商业银行、投资银行、经纪公司、保险公司、养老基金、股票和债券交易所、支付网络，以及监管它们的中央银行和监管机构。随着加密写作的兴起，这个术语作为“区块链出现之前就已存在的体系”的便捷标签而变得常见，主要用于与去中心化金融（DeFi）和中心化加密金融（CeFi）形成对比。

对技术读者而言，重要的一点是：TradFi 不是某个产品或协议，而是一种治理与托管模式。资金之所以流动，是因为持牌机构相互发出指令、维护账本，并在法律规则下通过清算和结算基础设施完成结算。当有人问 TradFi 是什么意思时，准确的简短回答是：受监管、以中介为基础的金融体系，与直接在公链上结算的体系相对。

• 核心机构：银行、经纪自营商、保险公司、资产管理公司、交易所、清算所、中央银行。
• 核心机制：由中介机构持有账户和账本，法定所有权在链下记录。
• 核心约束：牌照许可、KYC/AML 义务、资本规则和监管监督。
• 常见用法：在讨论 DeFi、CeFi、稳定币和代币化现实世界资产时作为对比标签。

范围、假设及本文不主张的内容

本文解释这一概念，并提供一种可复现的方法来检查与 TradFi 相邻系统的链上部分。本文不主张任何特定银行、券商或网络支持某个代币、链或集成。机构的区块链工作往往是许可制的、试点阶段的或特定司法管辖区的，公开声明很快就会过时。

请将每一项具体集成视为需要在源头核实的内容：机构自身的披露、网络的文档以及实际的链上状态。本文展示的命令是带有 RPC_URL 等占位符的模板；你需要提供自己获授权使用的端点。关于如何选择生产端点，可靠的多链 RPC 端点 上的配套 RPC Assistant 指南是合适的起点，而不是本文中任何硬编码的 URL。

TradFi 的心智模型：中介、托管与最终性

理解 TradFi 的一个有用方法是追踪一笔支付。客户向银行发出指令；银行借记内部账本，通过支付网络发送消息，收款银行再贷记自己的账本。最终结算可能稍后通过中央银行或清算所完成。在每一步中，都有一个具名机构持有权威记录并承担法律责任。所有权是对某机构的法定债权，而不是私钥。

这带来了可预测的特性。交易可以在既定规则下被撤销或提出争议。身份与账户绑定。访问取决于信用记录或最低余额等资格检查。费用是明确的，且往往经过中介。该体系在基础层速度较慢，但在某种意义上较为稳健：欺诈或错误造成的损失通常可以通过拒付、保险或监管追回。

与之相对，在公链上，权威记录是复制的账本，托管是密码学的，结算最终性是共识协议的一种属性。两种模式并非严格意义上谁更好；它们针对不同的目标进行优化。TradFi 优化法律追索权和受监管的风险；链上系统优化无需许可的访问和可组合性。

TradFi 与 DeFi、CeFi：结构性比较

这三个标签经常被混在一起，因此按托管归属和规则执行者来区分会有所帮助。下表是概念性比较，并非对任何特定服务商的主张。

• TradFi：由持牌机构托管；规则由法律和监管者执行；法币和受监管工具；需要身份；争议和撤销是可能的。
• CeFi：由加密公司（交易所或借贷机构）托管；规则由该公司条款及适用的牌照要求执行；加密资产；需要注册账户，通常需要 KYC；平台风险取代了部分银行风险。
• DeFi：由用户通过钱包自行托管；规则由公链上的智能合约执行；加密资产；无需许可的访问；交易不可逆且存在代码风险。

TradFi 机构实际如何使用区块链

机构对区块链的兴趣集中在几个具体问题上：结算速度、对账成本，以及将资产表示为可通过程序化方式转移的代币的能力。常见模式包括用于银行间结算的许可制网络、代币化政府债券和私人信贷，以及在分布式账本上代表银行负债的存款代币。

对开发者而言，实际后果是“链上的 TradFi”通常意味着两种情况之一：要么公链托管代表链下资产的代币或合约，要么许可制链在获得共享账本效率的同时镜像 TradFi 的访问控制。在这两种情况下，链上产物都是可验证的，而这正是可复现检查的价值所在。

验证与 TradFi 相邻的链上集成的前提条件

在运行任何检查之前，先收集四样东西。第一，正确网络的 RPC 端点，你可以通过 OnFinality 网络目录 或托管的 RPC 服务 选择。第二，合约地址，最好还有 ABI，或者至少是你打算调用的函数签名。第三，你关心的区块范围或部署交易。第四，一个明确的问题，例如“该代币的供应量是否与发行方的披露一致？”或“该合约是否已暂停？”

将只读检查与任何会签署交易的操作分开。切勿将真实私钥粘贴到 shell 历史记录或共享脚本中；如果必须写入，请使用环境变量和专用测试密钥。对于只读验证，你完全不需要密钥。

可运行的检查：使用 curl 和 JSON-RPC 读取链上状态

最简单的验证是原始 JSON-RPC 调用。下面的示例读取 ERC-20 风格代币的 totalSupply。将 RPC_URL 替换为正确链的端点，将 TOKEN_ADDRESS 替换为你正在检查的合约。函数选择器 0x18160ddd 是标准的 totalSupply() 选择器。

运行它并检查 result 字段。成功的响应会返回一个十六进制数量；回滚或空结果通常意味着地址错误、合约未部署在该链上，或函数不存在。在信任任何仪表盘之前，这是首先要运行的检查。

curl -s -X POST "$RPC_URL" \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "eth_call",
    "params": [
      {
        "to": "TOKEN_ADDRESS",
        "data": "0x18160ddd"
      },
      "latest"
    ]
  }'

可运行的检查：使用 JavaScript 编写脚本验证

对于可重复的检查，将调用包装在一个小脚本中，把链上数值与从发行方披露中获得的预期数字进行比较。该示例使用 ethers，同时读取 totalSupply 和 decimals，以便结果易于阅读。它会打印一行通过/失败信息，而不是静默断言。

这种模式可以推广：读取状态、归一化单位、与文档化的预期值比较，并记录区块号，以便日后结果可复现。如果你需要为许多合约提供更高的吞吐量，来自 OnFinality 专用节点服务 的专用端点可以避免与公共流量共享速率限制。

import { JsonRpcProvider, Contract, formatUnits } from "ethers";

const provider = new JsonRpcProvider(process.env.RPC_URL);
const abi = [
  "function totalSupply() view returns (uint256)",
  "function decimals() view returns (uint8)"
];

async function main() {
  const token = new Contract(process.env.TOKEN_ADDRESS, abi, provider);
  const [supply, decimals, block] = await Promise.all([
    token.totalSupply(),
    token.decimals(),
    provider.getBlockNumber()
  ]);
  const normalized = formatUnits(supply, decimals);
  const expected = process.env.EXPECTED_SUPPLY;
  console.log(`block=${block} supply=${normalized} expected=${expected}`);
  console.log(normalized === expected ? "MATCH" : "MISMATCH");
}

main().catch((err) => { console.error(err); process.exit(1); });

预期的验证结果及如何记录

一次干净的验证会产生三个产物：区块号、原始返回值，以及与文档化预期值比较后的归一化值。记录全部三项。没有区块号，后来的读者就无法判断不匹配反映的是真实差异，还是仅仅时间点不同。

当你比较多个合约或多条链时，保留一个结果表，以便证据可审计。不要填写你未测量的数字；在脚本运行之前将单元格留空。模板如下所示：

• | 合约 | 链 | 区块 | 链上值 | 文档值 | 结果 |
• | TOKEN_A | network-1 | （实测） | （实测） | （来自发行方） | MATCH/MISMATCH |
• | TOKEN_B | network-2 | （实测） | （实测） | （来自发行方） | MATCH/MISMATCH |

排查常见的验证失败

大多数失败的检查都属于少数几类。在得出集成已损坏的结论之前，请按顺序逐一排查。

如果 eth_call 返回错误，请确认链 ID 与合约的部署网络匹配。在一条链上有效的合约地址在另一条链上通常是空的。如果调用成功但返回 0x，函数选择器可能错误，或者该地址可能是外部拥有账户而非合约。如果值正确但单位看起来不对，请检查 decimals；代币小数位数各不相同，并不总是 18。

如果多次运行结果不一致，你可能在负载均衡器后面命中了处于不同链头的不同节点。在调用中固定区块号，而不是使用 latest。如果请求被限流，请迁移到有文档化速率限制的托管端点；RPC 定价概览 解释了容量如何分配。

仅凭链上数据推理的局限与权衡

链上验证告诉你合约说了什么。它不会告诉你代币背后的链下资产是否存在、发行方是否有偿付能力，或者许可制账本的参与者是否如其声称的身份。这些是需要披露、审计和监管备案的法律与会计问题。

还存在结构性不对称。TradFi 记录之所以权威，是因为机构和法院执行它们；区块链记录之所以权威，是因为共识规则执行它们。代币化债券处于两者的交汇点，其风险状况取决于你在哪个属性上信任哪一层。请将链上检查视为必要但不充分的证据。

后续步骤：从定义到可用的集成

如果你的目标是基于与 TradFi 相邻的基础设施进行构建，首先确定你实际需要哪条链和哪个合约，然后用上述只读检查验证状态。一旦数据模型清晰，就迁移到生产端点并添加监控，以便供应量变化、暂停和升级能被检测到，而不是事后才发现。

关于端点选择，请使用 RPC Assistant 关于选择区块链 RPC 提供商的指南，以及端点设置指南来配置重试和超时。如果你想更深入地比较托管模式，区块链节点托管指南解释了运行自己的节点会如何改变信任假设。TradFi 的定义很简单；工程工作在于针对你实际依赖的链验证每一项声明。