随着去中心化金融（DeFi）基础设施的成熟与稳定币（尤其是USDT）在跨境支付中的主导地位日益增强，去中心化支付网关已成为连接Web2商业逻辑与Web3价值结算的关键中间件。本报告旨在针对三种主流的开源自托管支付网关解决方案——TokenPay（LightCountry实现版）、BEpusdt、以及Bitcart（前BitcartCC）——进行详尽的技术审计与架构比较。
本研究深入剖析了这三者在实现原理上的根本差异：从TokenPay的API轮询模型，到BEpusdt的RPC底层区块扫描，再到Bitcart基于**SPV（简单支付验证）**的微服务架构。通过对源代码逻辑、依赖关系及运行机制的解构，报告揭示了它们在带宽消耗、CPU占用率及内存驻留方面的性能特征。研究发现，虽然TokenPay在部署便捷性上占优，但其API依赖性导致了系统的脆弱性；BEpusdt凭借Go语言的高并发特性与无数据库设计，在资源受限环境下展现了卓越的性能功耗比；而Bitcart虽然资源开销最大，但通过SPV协议提供了最为平衡的去中心化信任模型与功能扩展性。
在传统的加密货币支付流程中，商家往往依赖Coinbase Commerce或BitPay等托管型服务。然而，这种模式违背了加密货币“去信任化”的核心通过，并引入了单点故障风险、资金冻结风险以及隐私数据泄露的隐患 。随着监管压力的增加与商家对资金主权意识的觉醒，自托管（Self-Hosted）支付网关应运而生。这类软件允许商家在自有服务器上运行支付逻辑，直接与区块链网络交互，从而实现点对点的价值转移 。
本报告选取的三个研究对象代表了当前开源支付网关领域三种截然不同的架构流派：
TokenPay (LightCountry实现版)： 这是一个基于微软 .NET 8 框架构建的轻量级支付系统 。它并非运行全节点，而是作为一个适配器（Adapter），通过HTTP协议调用Etherscan、Tronscan等第三方区块链浏览器的API接口来获取交易数据 。其设计哲学是“极简集成”，主要服务于以太坊虚拟机（EVM）兼容链及波场（TRON）生态 。需要特别指出的是，本文讨论的TokenPay是指GitHub上LightCountry组织维护的支付网关项目，而非2017年的同名代币项目 。
BEpusdt： 这是一个专为USDT（Tether）支付场景优化的垂直解决方案，采用 Go (Golang) 语言编写 。其核心特征是“去数据库化”与“底层扫描”。它不依赖MySQL或Redis，而是直接通过JSON-RPC协议与区块链节点通信，实时解析区块数据 。BEpusdt代表了追求极致性能与极低资源占用的工程方向。
Bitcart (BitcartCC)： 这是一个基于 Python 的全栈开发平台，采用Docker容器化的微服务架构 。它继承了 Electrum 钱包的SPV（Simple Payment Verification）协议，通过连接公网上的Electrum服务器网络来验证交易，无需下载全量区块数据，也无需信任单一的API提供商 。Bitcart旨在提供一个功能完备的生态系统，包括后台管理、发票系统及多币种支持。
为了提供具有工程参考价值的对比，本报告将重点关注以下两个维度：
实现原理（Implementation Principles）：代码层面的架构设计、数据获取方式、交易验证逻辑及信任模型。
资源消耗（Resource Consumption）：在不同负载下的CPU计算开销、内存占用特征及网络带宽吞吐模型。
TokenPay 的技术栈构建在 .NET 8（早期版本为.NET 6/7）之上 。选择.NET 意味着该系统运行在公共语言运行时（CLR）环境中，利用 JIT（即时编译）技术将中间语言（IL）转换为机器码。这种架构使得 TokenPay 具备了跨平台能力，同时也引入了 CLR 的内存管理和垃圾回收（GC）机制。
TokenPay 的核心运作逻辑可以被定义为“API 轮询器”。与传统的区块链节点交互不同，TokenPay 本身不具备解析区块头或默克尔树的能力。
数据源：它完全依赖于第三方区块链浏览器提供的 HTTP API 接口，如 Etherscan API、BscScan API 和 Tronscan API 。
工作流：当系统生成一个收款订单时，它会将目标钱包地址加入监控队列。系统内部的一个定时任务（通过 C# 的 Task 或 BackgroundService 实现）会按照预设的频率（例如每 5 秒）向外部 API 发起 GET 请求，查询该地址的最新交易记录 。
数据解析：获取到的 JSON 格式响应被反序列化为 C# 对象（如 TokenPay.Models.EthModel.ERC20Transaction），系统随后比对交易金额、发送方和时间戳，以确认支付是否完成 。
这种架构极其轻量，因为它通过外包“账本索引”这一最繁重的计算任务，规避了运行区块链节点所需的高昂硬件成本。然而，这种设计也引入了显著的外部依赖风险，即所谓的“预言机风险”（Oracle Risk）。如果 Etherscan 宕机或对 API 调用频率实施限制（Rate Limiting），TokenPay 将立即瘫痪 。
在代码组织上，TokenPay 采用了典型的 MVC（模型-视图-控制器）架构，并深度集成了 Swagger UI 以方便开发者调试 。
异步处理：利用 C# 的 async/await 关键字，TokenPay 能够在单线程内高效处理大量的网络 I/O 等待，这对于 API 密集型应用至关重要。这意味着在等待 Etherscan 响应的几百毫秒内，CPU 线程可以被释放去处理其他 HTTP 请求，从而提高了并发吞吐量。
生态适配：TokenPay 的一个显著特点是其对下游应用的适配性。它特别针对“独角数卡（Dujiaoka）”、“V2Board”等自动售货系统进行了接口对齐，使得这些平台的用户可以无缝接入 USDT 收款能力 。
消耗模型：
分析：TokenPay 的 CPU 消耗属于 低（Low） 级别。
大部分 CPU 时间片消耗在.NET 运行时的垃圾回收（GC）以及 HTTPS 连接的 SSL/TLS 握手处理上。
由于不涉及区块哈希计算或椭圆曲线签名验证（除非涉及转账），其计算密度极低。
然而，在高并发场景下，如果存在大量的挂起订单，频繁的 JSON 反序列化操作可能会导致短暂的 CPU 峰值。
消耗模型：
：活跃订单数
：轮询频率
：API 响应包大小
分析：TokenPay 的带宽消耗极具弹性且通常极低。
它只请求特定地址的交易历史，而非整个区块数据。一个典型的 JSON 响应体通常小于 5KB。即使每秒轮询一次，单订单的带宽消耗也仅为 ~400KB/天。
优势：在 4G/5G 等按流量计费的网络环境下，TokenPay 是最经济的选择。
BEpusdt 采用了 Go (Golang) 语言编写 。Go 语言的并发原语（Goroutines）和静态编译特性使其非常适合构建高性能的网络服务。与 TokenPay 不同，BEpusdt 被设计为一个独立的二进制文件，无需安装.NET Runtime 或 Python 解释器，这大大简化了在 Linux 服务器上的部署与迁移 。
BEpusdt 的核心实现原理是主动式区块扫描。它摒弃了对 Etherscan 等高级 API 的依赖，转而直接与区块链节点的 JSON-RPC 接口对话 。
RPC 交互：系统通过 eth_getBlockByNumber 或类似的 RPC 方法，按顺序请求区块链上的每一个新生成的区块。
本地解析：获取区块数据后，BEpusdt 会在本地内存中遍历区块内的所有交易（Transactions）。对于每一笔交易，它会检查 To 地址是否匹配当前系统内任何一个待支付的订单地址 。
日志过滤 (Event Logs)：对于 ERC20/TRC20 代币（如 USDT），BEpusdt 实际上是在扫描合约的 Transfer 事件日志。通过向 RPC 节点发送 eth_getLogs 请求，它可以高效地筛选出特定合约在特定区块范围内的所有转账记录 。
BEpusdt 的一个激进设计决策是移除对 MySQL、Redis 等外部数据库的强依赖 。
实现：它倾向于使用轻量级的嵌入式键值存储（如 BoltDB）或纯内存管理，并配合配置文件（config.toml）来管理系统状态 。
影响：这种设计极大地降低了 I/O 延迟（IOPS），使得 BEpusdt 能够在低性能的 VPS 甚至树莓派上流畅运行。它将状态管理的复杂性降至最低，专注于“支付检测”这一单一职责。
消耗模型：
分析：BEpusdt 的 CPU 效率极高，但其基础负载与区块链的繁忙程度成正比。
在 BSC（币安智能链）或 Polygon 这样高吞吐量的网络上，每 3 秒产生一个区块，且每个区块可能包含数千笔交易。BEpusdt 必须在下一个区块到来前处理完当前区块的数据。
Go 语言的调度器能够将这些解析任务分配到多个 CPU 核心上，实现并行处理。因此，虽然它比 TokenPay 更消耗 CPU（因为要做更多的数据解析工作），但其利用率非常高效。
空载功耗：即使没有订单，BEpusdt 也必须持续扫描新区块，因此存在一个固定的 CPU 基线负载。
消耗模型：
分析：这是 BEpusdt 架构中的主要权衡点。
远程 RPC 模式：如果连接到远程公共节点（如 Infura 或 Public Endpoint），BEpusdt 需要下载包含交易列表的区块体。对于以太坊主网，这可能意味着每天数 GB 的数据下载量，无论是否有与商家相关的交易发生。这种“由于监控而产生的流量”远高于 TokenPay 的按需请求。
本地节点模式：如果与本地运行的全节点（Localhost）通信，则不消耗外网带宽，但本地节点本身的同步会消耗巨大的带宽和存储。
Bitcart（前称 BitcartCC）不仅仅是一个网关，它是一个基于 Python 构建的完整开发平台 。其架构设计深受现代云原生理念的影响，采用 Docker Compose 进行服务编排。一个标准的 Bitcart 实例由多个相互独立的容器组成：
Bitcart Backend: 处理业务逻辑。
Worker: 处理后台任务队列。
Redis: 用于服务间消息传递和缓存 。
PostgreSQL: 存储持久化数据（发票、用户、商店信息）。
Daemons: 每种支持的币种（BTC, LTC, BCH 等）都有独立的守护进程容器 。
Bitcart 的支付验证逻辑基于 SPV（简单支付验证），具体实现上依赖于 Electrum 协议 。
去中心化信任：SPV 客户端不需要下载数百 GB 的区块链数据。它只下载区块头（Block Headers）（约 80 字节/区块），并通过连接到公网上的 Electrum 服务器网络来请求特定交易的默克尔树证明（Merkle Proofs）。
验证逻辑：当一笔交易发生时，Electrum 服务器通知 Bitcart 守护进程。Bitcart 随后通过验证默克尔路径，从密码学上确认该交易确实被包含在某个区块中，并且该区块已被累积了足够的工作量证明（PoW）。
安全性：这种模式的安全性高于 TokenPay（不信任单一 API），但略低于运行全节点（不验证交易合法性，只验证包含性）。它是“轻量级”与“去信任”之间的最佳平衡点。
消耗模型：
分析：Bitcart 是三个方案中内存占用最大的 。
启动一个完整的 Bitcart 栈至少需要 1GB RAM，建议 2GB 以上。
PostgreSQL 和 Redis 数据库本身就占用数以百兆计的内存。
每个币种的守护进程（Daemon）都是一个独立的 Python 进程。Python 解释器本身的内存开销，加上加载的库文件，使得每个新增币种都会显著增加内存压力。
相比之下，BEpusdt 可能只需要 50MB 内存即可运行。
分析：中等偏高。
Python 作为解释型语言，其执行效率天然低于 C# 和 Go。
Docker 容器之间的上下文切换、网络桥接以及 Redis 消息序列化/反序列化都会消耗 CPU 周期。
SPV 验证涉及 SHA256 哈希计算，虽然计算量不大，但在 Python 中处理大量并发请求时，全局解释器锁（GIL）可能会成为瓶颈，尽管 Bitcart 使用了 asyncio 来缓解 I/O 阻塞 。
分析：中等。
同步区块头的数据量非常小（比特币全历史区块头仅几十 MB）。
Bitcart 保持与 Electrum 服务器的长连接，仅在相关地址有变动或新区块产生时才有数据传输。其带宽效率优于全量扫描的 BEpusdt，但略逊于精准查询的 TokenPay。
为了更直观地展示三者的差异，以下将通过结构化表格进行对比分析。
| 特征维度 | TokenPay | BEpusdt | Bitcart (BitcartCC) |
|---|---|---|---|
| 开发语言 | C# /.NET 8 | Go (Golang) | Python |
| 部署形态 | 依赖运行时的应用 / Docker | 单一二进制文件 / Docker | Docker Compose (微服务集群) |
| 区块链交互 | API 轮询 (Polling) | RPC 直连扫描 (Scanning) | SPV / Electrum 协议 |
| 数据源 | Etherscan / Tronscan 等 | 本地或公共 JSON-RPC 节点 | 公共 Electrum 服务器网络 |
| 数据库依赖 | 轻量级 / 配置文件 | 无 / 内存 / BoltDB | PostgreSQL + Redis |
| 信任模型 | 弱 (信任 API 提供商) | 强 (信任 RPC 节点代码逻辑) | 中强 (密码学验证默克尔根) |
| 主要应用场景 | 个人发卡站、轻量级收款 | 垂直领域的 USDT 高频收款 | 复杂的去中心化电商平台 |
| 资源指标 | TokenPay | BEpusdt | Bitcart (BitcartCC) |
|---|---|---|---|
| CPU 空载 | 极低 (仅维持 HTTP 服务) | 低-中 (持续扫描区块头) | 中 (多容器后台进程维持) |
| CPU 负载 | 低 (主要处理 JSON 解析) | 高 (高 TPS 链下需快速解析大量交易) | 中 (Python 解释器开销 + 数据库 I/O) |
| 内存 (RAM) | 中 (~100MB - 300MB) | 极低 (< 100MB) | 高 (> 1GB) |
| 带宽 (Bandwidth) | 极低 (按需请求) | 高 (全量区块数据流，若使用远程 RPC) | 低-中 (仅同步区块头 + 相关交易) |
| 磁盘空间 | 极低 (仅代码 + 日志) | 极低 (仅二进制 + 日志) | 中 (Postgres 数据库存储) |
主权与便捷性的博弈： TokenPay 选择放弃数据主权以换取极致的便捷性。它不仅安装简单，而且对服务器要求最低。然而，这种“寄生”于 Etherscan 的模式在商业上是危险的。一旦 API 策略变更（如 Etherscan V2 升级或收费），商家的支付系统将面临中断风险 。
性能与通用性的博弈： BEpusdt 专注于 USDT 这一细分领域，通过 Go 语言的性能压榨实现了极高的吞吐量。它牺牲了通用性（不像 Bitcart 支持多种 UTXO 币种），换取了在低端硬件上处理海量交易的能力。其 RPC 扫描模式虽然消耗带宽，但通过使用内网节点或高质量的付费 RPC 服务，可以实现毫秒级的到账检测 。
系统复杂性与功能完整性的博弈： Bitcart 提供了最完整的解决方案，包括前端商店、后台管理和发票系统。但这带来了沉重的运维负担。维护 PostgreSQL、Redis 和多个 Docker 容器的健康状态，远比运行一个单一的 BEpusdt 二进制文件复杂。它是为那些希望构建完全自主、不依赖任何外部 SaaS 服务的开发者准备的 。
在选择支付网关时，决策不应仅仅基于“性能”，而应基于具体的业务场景与基础设施条件：
对于个人开发者或小型数字商品售卖（如发卡站），TokenPay 是最佳切入点。其.NET 架构在 Windows 和 Linux 上均有良好支持，且资源占用对共享主机非常友好。只要能够容忍对 Etherscan 的依赖，它是最快的上线路径。
对于高频交易、专注于 USDT 收款且拥有一定服务器资源（如 VPS）的商家，BEpusdt 是最优的技术解。其 Go 语言实现的底层扫描机制保证了即使在区块链拥堵时也能保持高效处理，且无数据库设计让运维变得异常简单。虽然带宽消耗较高，但在现代云服务器环境中通常不是瓶颈。
对于构建抗审查、多币种且具备复杂业务逻辑的电商平台，Bitcart 是唯一的选择。尽管其 Python 微服务架构消耗较多内存和 CPU，但 SPV 协议提供的去中心化信任和 Docker 提供的模块化扩展能力，使其能够支撑起企业级的支付业务，且数据完全掌握在商家自己手中。
综上所述，TokenPay 胜在轻便，BEpusdt 胜在性能，而 Bitcart 胜在主权与功能。架构的选择，本质上是对信任来源、硬件成本与运维复杂度的权衡。