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