共享证明服务是什么？StarkEx 怎么把 ZK 证明交给公共 prover

一个应用要给自己的 Layer2 配证明系统，最重的一笔开销往往不是写电路，而是养 prover：专门的证明机器、专门的工程团队、证明积压时还要临时扩容。StarkEx 走的是另一条路——把证明这件事外包给一个所有应用共用的证明服务，官方文档叫它 SHARP，一个面向 Cairo 程序的共享证明服务。本文按 StarkWare 官方文档拆解这个角色在整条状态更新链路里站哪个位置、共享体现在哪一环、以及它如何影响应用侧的资产与状态边界。

先看整条链路的分工

官方文档把 StarkEx 系统拆成链下与链上两半。链下一侧，应用承接用户请求并定义业务逻辑，把交易汇给 StarkEx Service；这个服务负责批处理与协调，为每一批操作生成执行轨迹，并把轨迹发给 SHARP 请求证明。链上一侧，链上组件持有状态承诺与系统资产，用 STARK Verifier 验证证明；只有验证通过，StarkEx Contract 才接受新的状态更新。也就是说， deposits 与 withdrawals 由合约以非托管方式管理，任何情况下用户都能在链上取回自己的资金，而状态能不能推进，决定权在证明是否验证通过这一关。

共享具体共享在哪

文档给 SHARP 的定位是”共享的证明服务”：它接收来自不同应用的证明请求，输出证明以担保这些 Cairo 执行的有效性，并且同一份输出证明可以在多个证明请求之间共享。这句话是理解整个经济模型的关键。独立的 ZK 系统每批都要为单条链单独生成一份证明，而共享证明服务把多个应用的执行合并到同一套证明工作里摊销：一笔证明成本可以同时服务于多个状态更新请求。对应用方而言，这意味着不必自建 prover 集群，也不必关心证明生成的硬件与积压问题；代价则是证明的节奏与容量不完全由单一应用说了算。

链下这一侧还有一个常被略过的角色：Operator，即拥有并负责应用的实体。用户提交的转账与限价单先交给应用，再由应用转交 StarkEx Service 排队成批。这个链条说明系统里并不存在一个中立的公共排序者，交易何时进批、状态何时推进，节奏由运营方与服务决定，而证明只是给结果盖上数学印章。理解了这一点，才能理解为什么文档把”共享”限定在证明环节——批处理、业务逻辑与运营责任并没有被共享掉。

数据可用性另有一档开关

值得分清的是，SHARP 管的是”执行是否有效”，不管”数据存在哪”。同一份文档列出 StarkEx 的三种数据可用性模式：把数据放链上的 ZK Rollup 模式、放链下的 Validium 模式，以及允许用户逐笔在两者之间挑的 Volition 模式。证明系统与数据可用性解耦，意味着同一个共享证明体系可以对接不同的数据存放策略，用户要评估提款风险时应当看自己所选模式，而不是笼统地问”这条链安不安全”。

用户侧的核验视角

对普通用户，这套机制落到日常有三个可观察点。其一，充值走链上交易进 StarkEx Contract，提现则先以链下请求提交，等包含这笔提现的状态更新被链上接受后才能动资金；其二，如果应用方不处理提现请求，用户可以通过强制交易路径把执行推上链，这是文档写明的防审查通道；其三，判断某个应用状态是否被”承认”，看的是链上状态更新交易与验证器结果，而不是应用界面的提示。共享证明服务提升了效率，但也提醒用户：链上合约才是资产账本，应用层只是代理入口。

本文只作机制解释，不构成任何投资建议；各模式的费用、证明节奏与参数以官方文档与链上合约为准。判断一条 StarkEx 应用链的成熟度，可以沿一条简单的检查线走：状态更新是否持续上链、验证合约是否公开可查、当前运行在哪种数据可用性模式，三项都应当能从链上与官方文档各自独立确认，而不是只来自应用前端的展示。