【摘要】 长话短说：StarkPay 是一种基于 STARK 技术的可扩展支付引擎，它可以解决第二层(Layer-2)支付解决方案闪电网络(Lightning)的许多缺点。-图片来
长话短说：StarkPay 是一种基于 STARK 技术的可扩展支付引擎，它可以解决第二层(Layer-2)支付解决方案闪电网络(Lightning)的许多缺点。
-图片来源：Unsplash，作者：Cade Roberts-StarkWare 的第一个 STARK 技术应用是一个 Layer-2 可扩展引擎。我们最近发布了 StarkDEX，一个去中心化交易所(DEX)可扩展引擎(早期成果请查看该链接)。
我们将该可扩展引擎应用于加密货币支付场景，构建了 StarkPay。稳定币的出现满足了密码学货币作为交换媒介的必要条件。然而，该生态系统依旧缺少一个可扩展支付系统。我们相信 StarkPay 能够满足这一需要。
本文将对比分析 StarkPay 与闪电网络(最著名的比特币支付可扩展性解决方案)。我们将首先回顾闪电网络的优缺点。然后，阐述 StarkPay 基础架构，并举例说明其执行流程。最后，分析 StarkPay 的优缺点，以及缺点的改进方案。
本文将不探讨两种方案隐私保护方面的内容。
闪电网络
自 Poon 与 Dryja 2016 年发布白皮书以来，闪电网络引起了公众的广泛关注。闪电网络目前拥有超过 3000 个节点，全网锁定资产价值超过 200 万美元。闪电火炬接力赛(Lightning Torch)的金额也已超过 100 美元，高科技巨头 Jack Dorsey 与 Reid Hoffman、金融巨头 Fidelity 等也都参与其中。
Lightning 是为了扩展比特币网络而提出的。作为最早一批出现的 Layer-2 解决方案之一，它天才地提议将交易转移到链下处理，而不改变区块链的安全模型。它希望不仅能够提升交易规模，还能够保证低延迟与最低交易费。闪电网络也有几个缺点：活性需求：
付款方必须在线才能完成付款——这一点没什么奇怪的。但是，与比特币不同，在闪电网络中，收款方也必须在线，以便使用双方的私钥对链下交易签名（稍后将详细阐述操作的安全考虑）。更糟糕的是，从交易双方建立链下通道开始，收款人就必须一直监测区块链状态，以确保付款人不会将他们余额的旧状态提交上链并关闭通道。路由节点也必须在上下游通道超时之前在线，以便在上游 HTLC（哈希时间锁）超时之前参与协议、履行职责（即路由支付请求）。
闪电网络试图引入瞭望塔节点来解决用户需要持续监测区块链的问题。瞭望塔节点通过向用户收取费用来提供区块链网络状态监测服务。
资金利用率低：
一般来说，为了方便使用，付款方愿意锁定一些资产(例如：使用借记卡)。但是在闪电网络中，每个用户需要在每个通道都锁定一笔资金，从而将一个用户的资金打散。
更糟糕的是，如果链下交易不是直接从付款方发送给收款方(例如：转移金额为 X)，而是通过其他路由节点转发，那么所涉及的路由节点也需要锁定数量至少为 X 的资金。
在理想情况下(从资金利用率的角度考虑)，单一中心节点的星型网络流动性上限为中心节点愿意锁定的资金量。付款方的锁定资金对于网络流动性毫无贡献。换句话说，需要路由节点来给网络带来流动性，这是一个令人有点惊讶又不合需要的特性。
要是我们再想避免形成这样的中心化网络，又会遇到什么样的问题呢?降低网络中心化水平需要增强路由路径选择的多样性。但是在一笔转账中，参与路由的节点越多，交易资金成本就会越高(这是因为用于路由的资金需要在一段时期内锁定，在锁定期间并不能产生利息)。
具体而言，如果 Alice 想通过 5 个路由节点向 Bob 发送 1 个比特币，那么总共就需要在闪电网络中锁定 5 个比特币。这种成本(以及路由节点不配合时的恶意攻击成本)必须转化为交易方所承担的费用。现在闪电网络中并向付款方未收取这部分费用，而是基于网络早期用户的利他行为来维持网络正常运转。
闪电网络生态系统的中心化趋势能够缓解资金利用率低下的问题。闪电网络中心化程度显然是一个有趣的话题。
运营安全挑战：
中心化交易所最具争议的点是，它们创造了一种蜜罐，会引来攻击者的攻击。但是，随着网络的扩大，闪电网络路由节点会创建更多临时蜜罐。设想一下热钱包中有一个私钥需要暴露的情况：中心化交易所只需要在它们选择的时间段内短暂暴露私钥。
但在闪电网络中，路由节点为了提供几乎实时的服务，必须一直暴露私钥。与此同时，为了提供稳定的路由服务，它们需要保证每个通道都有足够的资金。这就构成了一个理想的蜜罐：充足的资金与在热钱包中暴露的私钥。为了弥补保护这个蜜罐所需投入的资本，路由节点很可能将这部分投入增加到交易费当中。
交易完成率随支付金额增加而降低：
考虑到多跳支付中的每个通道都需要锁定超过支付金额的资金，这些支付在网络中可选择的路由更少，因此更高金额的交易支付完成可能性更低。由于通道路由限制了容量大小，支付金额增加可能导致交易费用也会水涨船高。理想情况下，用户当然希望交易完成率独立于交易金额。
交易完成率随方向性增强而降低：
与增加支付金额的负面影响类似，当许多付款方同时向一个收款方支付费用时(例如：真实世界中消费者向商家付款)，他们会争夺有限的(指向收款方的)路由节点资金容量。请注意，闪电火炬接力赛并没有证明闪电网络能应付这种场景。
总的来说，闪电网络总资源消耗似乎不仅仅与参与者的数量或支付金额相关，还与支付笔数成比例。这对于支付扩容方案来说显然是一种硬伤。
[插播：为了简单起见，我们假设闪电网络中路由问题已经被完美解决，并且免费提供服务。当然，有些人认为这是一个难题]
StarkPay
StarkPay 的目标是提供一种无活性需求的、可扩展、资金高效、非托管的支付解决方案。
组件
StarkPay 由链下组件与链上组件两个部分组成。
链下
支付处理者：与付款方与收款方交互。
付款方余额树：由 Prover(证人节点) 更新，并且保证可用性(后文详述)。
证人节点(Prover)：产生 STARK 证据，从而证明支付处理者传来的几批支付的有效性，以及付款方余额更新的有效性。
链上
支付合约：StarkPay 的资金入/出(锁定/解锁)站，同时存储更新付款者余额的承诺(付款者余额更新存储在链下，待验证者合约验证通过后将承诺存储在链上)。
验证者合约：验证由证人节点(Prover)产生的 STARK 证据，并将验证结果反馈给支付合约。
让我们将以上模型带入一些基本场景：
存款（“入站”）
付款者向支付合约存入密码学货币。通过 STARK 证据将存入资金转移到链下余额树。此操作类似于闪电网络通道建立过程，但有一个很重要的区别在于，StarkPay 中 “入站” 操作可以指定多个资产接收方地址。
取款（“出站”）
同样通过使用 STARK 证明证据，将链下余额树中资金转移至支付合约，之后付款方便可从支付合约中取出余额。此操作类似于闪电网络的通道关闭过程。
Alice 通过 StarkPay 向 Bob 转账
Alice 签名向 Bob 发送一笔交易，并将该交易发送给支付处理者(Alice 并没有放弃她的资金监管权)。
支付处理者将一批支付交易(包括 Alice 的支付)发送给证人节点。
证人节点生成这批支付的 STARK 证据，以证明这批支付以及账户余额更新的有效性，具体过程如下：
检验支付的数字签名;
验证付款方有充足的资金;
更新余额承诺(例如：Merkle 树根)。
证人节点向链上的验证合约发送 STARK 证明证据以及余额承诺。如果验证通过，验证者就向支付合约发送新的余额承诺，并将其存储在链上(如上文所述)。
对于证人不需要引入信任假设，恶意或粗心大意的证人无法让验证合约相信无效证明是有效的。
优势
我们相信 StarkPay 体系架构能够提供预期的优势：
可扩展性：
StarkPay 所消耗的计算资源随着付款者以及支付的数量增加而增大。更重要的是，计算资源的变化不再与流通总金额挂钩。我们已经达到了一个比较理想的结果：StarkPay 在单个区块(当前 Etherum gasLimit 限制内)内能够支持超过 10000 笔交易。
值得注意的是，STARK 适度地消耗了极为稀缺的链上计算资源：它所消耗的资源随着链下计算规模的增加以对数方式增长。具体而言：为使 StarkPay 吞吐量提升 10 倍，链上计算资源消耗仅需增加不到 50%。
插播：如果将扩容的标准设置为 金额/秒 而不是 交易量/秒，那么 StarkPay 其实是没有上限的。
资金利用率高：
就像借记卡那个比喻一样，在 StarkPay 中，除了每个付款方希望在链下用于支付的资金外，不需要锁定额外的资金。尤为重要的是，对支付处理者与证人没有流动性要求。
无活性需求：
收款方余额更新时无需其保持在线。在所有场景中(存款、取款与支付)，交易都可以离线构造并在之后发送给区块链或支付处理者。
非托管：
付款方无需将加密货币托管给 StarkPay。所有操作都需要付款方签名，即便在证人作恶或者不合作的情况下，他们也可以随时直接从支付合约(Payment contract)中取出锁定资金(后续博客将详细阐述有关安全退出的内容)。
在这方面，StarkPay 与 闪电网络的效果相同，用户仍然保留对资金的控制权。
劣势
StarkPay 有一些明显的缺点：
数据可用性：
为了充分利用 STARK 的链上对数扩展性，数据最好存储在链下，但这就会带来交易数据不可用的问题。为了去信任，并且打破可扩展性上限，数据有效性是每个基于 Plasma 的扩容方案必须解决的挑战。
改进方案：
链上分批记录交易：我们认为在这种模式下 StarkPay 能够轻松达到每秒处理几百笔交易。
未来链下数据一个可能的方向：构建数据可用性见证联盟，联盟对提交给链上验证者合约的证明签名就表示数据在链下是可用的。链上验证者合约将不接受缺少此证明的证据。值得注意的是，该联盟没有被委托保证系统状态的有效性 —— 他们不能盗窃资金，也不能将让系统状态失效。
为了支持更加去中心化的解决方案，这个联盟之后将逐步被淘汰。
中心化：
证人(Provers)节点最初将由 StarkWare 运营。这带来的中心化与审查的风险。
改进方案：
中心化：其他市场参与者(包括其他支付处理者)，自然会提供自己的证人节点(Provers)。从长远来看，证人节点可以通过共识算法在网络中竞争证据生成业务。注意，由于状态仅通过有效证明来改变，证人节点不能通过切换到无效状态来攻击网络，在这个意义上，StarkPay 的方法很像第一层(Layer-1)共识的解决方案。
审查：在 StarkPay 上，STARK 也可以用来保护隐私。具体而言，付款方可以隐藏他们的交易内容，即便是证人节点也无法获取。由证人节点生成的计算声明是它验证了从付款者收到的一批独立交易后生成的，因此他人无法从中追溯单笔交易。
延迟：
与点对点闪电通道保证的即时结算不同，目前为大批量交易生成证明所需的时间大约是几分钟。
改进方案：
证人节点可以在验证收到的一批交易之后，立即向链上的支付合约提交承诺，并同时生成证明证据。收款人有几分钟的时间需要承担证人节点会无限期扣留证据的风险。该风险可以通过持有证人节点基金来补偿。值得注意的是：StarkPay 的延迟是主链对于证据提交交易的共识延迟，而不是闪电网络中近乎即时的链下节点交易处理延迟。
同时，延迟不应该等同于吞吐量：StarkPay 能够通过提升证人节点计算资源(全部都在链下的资源)的方式，来达到更高的吞吐量水平。
没有适用于比特币的解决方案：
以目前的形式，比特币尚不能支持高效链上 STARK 验证。
缓解措施：
如果你有解决方案的话，一定要告诉我们。在此之前，我们将集中精力适配支持高效链上 STARK 验证的区块链。
本文我们介绍了一种适用于加密货币支付场景的基于 STARK 算法的可扩展引擎(StarkPay)。我们首先分析了当前最热门的比特币扩容方案 —— 闪电网络，并将其与 StarkPay 进行了比较。我们的结论是，StarkPay 提供了一种引人注目的替代方案，能够在几个值得注意的维度对闪电网络进行改进。
感谢 Vitalik Buterin, Patrick McCorry, Jim Posen 与 Dan Robinson 对本文草稿提出的意见。
(作者: Tom Brand, Uri Kolodny &Avihu Levy)