← 全部文章

阅读约 7 分钟

如何不打开网站使用 CardanoWall

网站只是一个界面，而非整个产品。你可以通过 CLI、SDK、网关 API、桌面应用，或你自建的服务来发布和验证 Label 309 记录。

你完全可以不打开网站使用 CardanoWall。同样的存在性证明（Proof of Existence）记录，可以从命令行工具、嵌入你应用代码的 SDK、网关 API、桌面应用，或你自己运行的服务中创建、发布和验证。网站只是面向一项开放标准——Label 309——的一个前端，真正重要的是这项标准本身。

这个区分正是关键所在。存在性证明往往不是一次性的人工操作。它属于构建流水线、合规流程、AI 来源溯源系统、法律证据工作流，或别人构建的产品。这些场景都不应该要求有人去逐步点击同一个 Web 界面。

网站到底做了什么？

网站让存在性证明变得易于上手。它为你提供可视化编辑器、账户与余额视图、记录页面、身份管理、上传流程，以及引导式发布。对大多数人来说，从这里入门是正确的选择。

但它不应该是使用这项标准的「唯一」方式。如果一份证明只有在人去逐步点击某个界面时才能生成，它就无法成为基础设施。企业需要自动化。开发者需要 API 和 SDK。运维与安全团队需要可重复、可脚本化的工作流。有些用户希望把记录和文件放在自己的机器上。有些运营者则希望自己运行整条流水线。

Web 应用是前门，而不是整栋楼。

还有哪些使用方式？

方式有好几种，而它们最终都汇聚到同一个产物——一条锚定在 Cardano 上、任何人都能独立验证的标准 Label 309 记录：

  • CardanoWall Web 应用
  • 开源的 cardanowall 命令行工具
  • 面向应用代码的官方 SDK（TypeScript、Python、Rust）
  • 用按账户令牌访问的 Label 309 网关 API
  • CardanoWall Desktop，开源的本地优先客户端
  • 你自托管的网关
  • 你在网关之上构建的自有产品

界面可以变，证明格式不会变。所有这些代码都在 github.com/cardanowall 下开源，采用 Apache-2.0 许可，规范文本则采用 CC-BY-4.0 许可。

我应该在什么时候使用网关 API？

当发布或读取证明需要成为一个系统的一部分、而不是手动步骤时，就使用 API。例如：

  • 一款 SaaS 产品为每份客户文档生成一份证明
  • 一条构建流水线在每次构建后发布版本证据
  • 一个 AI 平台批量锚定生成的输出
  • 一套合规系统每天发布一份控制快照
  • 一个工作流为特定接收方封存证据
  • 一个内部仪表盘读取发布状态和账户余额
  • 一个合作方集成在不接触 CardanoWall UI 的情况下提交记录

API 路径让你的软件直接调用网关，同时你保留自己的用户体验。CardanoWall 自己的 Web 应用和 worker 也正是通过这些相同的公开端点访问网关——这里没有任何私有通道，所以参考产品能做的一切，你同样能做。如果想在这方面深入了解，请参阅在 CardanoWall API 上构建。

API 令牌和作用域是怎么工作的？

网关区分两类凭证，而把它们分开正是最需要做对的一件事。

「账户令牌」的行为「相当于你的某个用户」。你的后端为特定账户铸造一个短期令牌，调用便以该账户的身份进行：请求报价、上传内容、发布、读取该账户的余额。这些令牌——以及基于同一模型构建的 API 密钥——正是适合放进脚本、CI 任务和集成中的那一类。它们是刻意收窄的。当前的作用域集合很小，且各有明确用途：

  • poe:create——请求报价、上传内容、发布记录
  • poe:read——读取记录和发布状态
  • inbox:read——读取加密的收件箱同步书签
  • account:read——读取账户余额

这就是全部可编程接口面，而且它是被刻意收窄作用域的。一个只读的仪表盘小组件只需要 account:read。一个发布任务需要 poe:create。两者互不需要对方。这里刻意「没有」服务端解密作用域：封存与解封都是客户端操作，因此接收方私钥永远不会到达网关，也没有任何 API 密钥能授权服务器替你读取封存内容。同理，CI 任务也绝不应该持有用户的身份种子，除非本地签名是你自己设计中刻意安排的一环、并处在你自己的管控之下——按照设计，种子和私钥始终留在客户端，网关从不接触它们。

「运营者凭证」是第二类，而它「不是」 API 密钥。它授权控制平面——开通账户、在你的计费系统收款后调整余额、设置利润率、铸造上面那些账户令牌。它们只能存在于受信任的后端，绝不能放进浏览器、移动应用或脚本。账户令牌泄露应该只是一时的小麻烦；而运营者凭证泄露则会是一起真正的安全事件。

经验法则是：把客户端所需的那个窄作用域账户令牌交给客户端，把运营者权限留在你自己的后端背后。

我应该在什么时候使用 CLI？

当一份证明属于某个脚本时，就使用命令行工具。cardanowall 二进制文件不绑定特定网关、且以原始种子为先，这让它天然适合：

  • 在本地验证一条记录，无需打开任何网站
  • 在大量文件上构建并核对 Merkle 证明
  • 为记录签名
  • 从自动化流程提交记录
  • 在终端里做收件箱同步和试探性解密

CLI 之所以重要，最主要的原因是它让存在性证明紧贴生成产物的那些系统。一条构建流水线可以对其输出计算哈希，并把发布一条记录作为发布流程的一部分。一个合规任务可以每天提交一份清单。一个本地用户可以离线验证一条记录。网站对人很友好；CLI 对可重复的操作很在行。关于具体模式和示例，请参阅在自动化中使用 CLI。

我应该在什么时候使用 SDK？

当 Label 309 应该成为你应用的一部分时，就使用 SDK。TypeScript、Python 和 Rust 这三个 SDK 可以帮你构造记录、对内容计算哈希、验证交易、在主机外签名、封存与解密载荷、从种子派生身份，以及与任意网关通信。

拥有三个 SDK 的意义不在于便利，而在于互操作性。它们是字节级一致的孪生实现，针对同一套规范测试向量做过校验，因此由其中一个发布或签名的记录，在其他几个之下会得到完全一致的验证结果。一项开放标准正是这样才得以保持开放，而不至于碎裂成彼此互不兼容的所谓「兼容」格式。有一个值得强调的好特性：独立验证器只需要交易元数据、可选的内容字节，以及一个公开的 Cardano 浏览器——信任路径上不存在任何签发方服务器。

我应该在什么时候用桌面应用而非网站？

当本地拥有权很重要时，就使用桌面应用。CardanoWall Desktop 是一个开源、跨平台、离线优先的客户端，用 Rust 搭配 Tauri、在 Rust SDK 之上构建，它的工作方式像一个邮件客户端，为你提供

  • 本地、加密的身份保险库
  • 对一切已同步内容的离线访问
  • 在你自己机器上进行封存收件箱发现并缓存密文
  • 在公开记录索引上的本地搜索
  • 多个身份，以及由你选择的网关提供方

网站依旧快捷便利，而当你希望让记录、身份和缓存文件留在本地、并在没有网络的情况下继续运转时，桌面应用是更好的归宿。对许多人来说，答案会是两者兼用。关于这套设计，更多内容见 CardanoWall Desktop 和离线证明。

我应该在什么时候自托管网关？

当你想自己运营发布流水线时就自托管——出于合规、成本结构、规模、数据处理政策、基础设施控制，或产品策略的考量。

自托管的网关依旧发布标准的 Label 309 记录；区别在于，由你来运行那个负责报价、上传、提交、确认、建立索引并为发布记账的服务。网关是一个开源的 Rust 单一二进制文件加 Postgres，自带 Cardano 交易构建器，负责构建、提交、确认、处理链重组，并在永久性失败时自动退款。

自托管并不「免费」。你仍要支付底层的 Cardano 和 Arweave 成本，并承担运行它的运营责任。你去掉的，是发布对某个托管 CardanoWall 网关的任何依赖。请参阅运行你自己的网关和什么是 Label 309 网关？。

我能在网关之上构建自己的产品吗？

可以——而这种分离，恰恰是网关之所以自成一层、与 Web 应用相区分的原因。你可以在 Label 309 网关之上构建公证产品、证据门户、合规归档、发布工具、AI 来源溯源服务，或内部仪表盘。

网关掌握基础平面：链、存储、定价、共享的链上记录索引、余额，以及发布状态。你的产品掌握厂商平面：用户、计费、UI、工作流、通知、支持，以及你在记录之上赋予的任何产品专属含义。这让更多产品能共享同一个证明标准，而不必让每个团队都去当 Cardano 交易和存储运营者。完整的演示见在 Label 309 网关上构建。

我能完全不用 CardanoWall 来验证吗？

这正是目标所在，也是其余一切之所以存在的最有力理由。验证绝不能依赖 CardanoWall 网站。任何人都应该能够读取交易元数据、重建 Label 309 记录、校验其结构、核对任何记录签名、重新计算内容哈希，并且——在持有正确密钥的情况下——在本地解密一条封存记录。

一份只有某一个网站能验证的证明，是一份弱证明。开放的 SDK、开放的 CLI 和一份开放的规范，正是让一份 Label 309 证明可被任何人验证的原因，包括那些从不接触 CardanoWall 的第三方。如果你想亲自动手，请从验证一条 Label 309 记录开始。

价格方面呢？

换一个界面，并不会消除底层成本。无论你是从网站、桌面应用、CLI、API，还是你自己的产品发布，都仍然有人要支付真实的 Cardano 交易费用，外加文件或密文所占用的存储费用。一个托管网关会在此之上叠加一层利润率，用于覆盖运营、资金、基础设施和支持，因此价格是成本透传加上那层利润率。

如果你使用 CardanoWall 的托管网关，你用的就是它的预付余额和定价模型。如果你自托管，你就直接运营并为自己的网关注资。无论哪种方式，标准让「记录」具备可移植性——它并不能让区块链或存储变得免费。其中的道理在为什么发布要收费里讲得很清楚。

一个重要的边界

一份 Label 309 证明表明：特定字节在某个特定的公开时间之前就已存在，且此后未曾改变。它并不能证明谁创作了这份内容、谁拥有它、它是否属实，或是否有人对它享有权利。一份封存记录会让其明文只对目标密钥持有者可读，但它无法保证匿名性，也无法阻止接收方在解密之后泄露明文。无论你从哪个界面发布，都请记住这条边界。

一句话总结

CardanoWall 不只是一个网站。网站是最易上手的人工界面；网关是发布层；CLI 和 SDK 是开发者接口；桌面应用是本地的、离线优先的客户端；自托管是运营者路径。它们产出的都是同一样东西：一条标准的 Label 309 记录，可以在创建它的那个界面之外得到验证。

选择与工作相匹配的界面。给人用网站，给脚本用 CLI，给产品用 SDK，给系统用 API，而当你需要的是厂商独立性或运营控制权时，就用自托管网关。

延伸阅读

developersapigatewayself-hosting