zoukankan      html  css  js  c++  java
  • Ethereum Probabilistic Micropayments

    到目前为止,大多数需要微支付的以太坊项目都聚焦于支付通道。支付通道允许发送任意数量的交易,且只需要两个链上交易:

    • 一个用于初始化支付通道
    • 另一个用于关闭通道并结算总交易金额

    在这两个交易之间,我们可以发送任何数量的链下交易。相对于常规的链上交易,这是极大的进步。因为像在线视频和能源市场这样的服务,可以为其微量的服务持续收取费用。

    由于需要两个链上交易,我们不能简单地把0.1美分发送给我们还没有建立通道的人,因为通道初始化和结算的费用将比支付款项高出许多倍。

    但如果我们可以向任意数量的接收者发送任意量的小金额,而不需要进行初始化和结算交易呢?

    以太坊概率微支付(Ethereum Probabilistic Micropayments)就可以向任意数量的接收者发送任意数额的支付款项,而不需要每一位接收者的初始化和结算交易。

    听起来难以置信吧?确实是这样的——我们总需要至少一笔链上交易进行结算,但在没有任何链上交易发生的情况下,我们也能有效地接收付款。

    在上述描述中,请注意“每一位接收者”的条件限制,这是一个微妙但重要的差别。以太坊概率微支付需要每一位发送者进行一次初始化交易,锁定一定数量的token(之后将用于发送给任意接收者)。接收者不需要处理每个发送者的支付。下面我们来看一个例子,看看它是如何操作的。

    兰花协议

    兰花实验室,我们正在研究如何通过一个新的分布式覆盖网络,在互联网中消除监控和审查。在兰花网络中,带宽的贡献者(称为节点)与接入网络的用户分享宽带并中转流量;用户则持续地向带宽贡献者支付token(客户端自动支付)。

    一个兰花节点可以服务数千个其他节点,用户也可以使用数百个节点连接不同的网站,而在每一个节点之间建立一个支付通道的交易费用高得令人望而生畏(即使是使用像雷电网络那样的通道网络)。

    取而代之的是,我们可以使用以太坊概率微支付:

    • 发送者可以把token(可以是以太币,ERC20代币或其他等价物)存入所有的发送者共享的以太坊智能合约,该智能合约为每一位发送者维护支付差额罚金托管
    • 发送者在本地创建并签署一张票据,该票据是一种包含了接收者、总额等支付数据的加密数据结构。
    • 发送者无需在以太坊网络上发布任何交易,直接将票据发送给接收者即可。
    • 接收者核实票据。如果它是有效的,那么接收者就有了加密证明他们正在收取款项。注意,即使票据没有“中奖”,接收者仍然有确凿的证据来证明他们能收到款项,因为决定票据是否“中奖”的随机性是由发送者和接收者双方决定的。这样,其中任意一方都无法一手操纵结果。
    • 一张有效的票据即是“中奖”,在这种情况下,它可以通过发布一个链上以太坊交易来获取。

    该方案在兰花草案白皮书中有详细说明(在某种程度上算是正式说明),这份白皮书讨论并参考了先前关于概率微支付以及它对区块链的适用性的研究。

    虽然我们不能将这个方案用于单一支付,因为接收者无法确保他们真的能收到付款,但我们可以把它通过加密的方式向接收者证明,他们收到的票据有产生可索取付款的可能性。

    由于随着时间的推移,我们能逐渐准确地计算出中奖概率、中奖金额以及票据的频率,我们可以将差异(交易余额)减少到可以忽略不计的程度。

    也就是说,只要所提供的服务是持续的,且颗粒度足以让概率的差异忽略不计,那么概率支付就比支付通道更高效。

    支付通道的应用场景:

    • 你是一位视频流媒体的主播,每小时收费1美元。
    • 一名新用户连接到你的服务,并对着可爱小猫观看了正好10秒钟。
    • 如果一项交易可以等待几个区块的确认的话,那么一项没有数据的交易目前的成本是0.006美元。然而,由于我们需要在观看在线视频前设置通道(以避免有人吃白食),我们可能需要更快的确认,这将花费0.026美元。建立一个支付通道将会花费更多的钱,因为它需要智能合约执行。粗略估计,价格会是上述的两倍,即0.052美元。
    • 这种情况下,支付通道的开销是你作为主机向用户收取的费用的几倍。如果用户最终看得确实很多,那么这笔开销可能是合理的,但是对于新的用户或零星的用户来说,这就会引起一些争议。

    概率支付的应用场景:

    • 你是一位在线视频的主播,每小时收费1美元。
    • 一名新用户连接到你的服务,并对着可爱小猫观看了正好10秒钟。
    • 每4秒,该用户就会给你发送一张中奖率为1/2500的链下票据,中奖金额为2.78美元。
    • 如果你没有每4秒收到付款票据(考虑到网络延迟,也可以多给些时间),你只需断开和观众的连接。
    • 如果观众没有接收到任何视频流入,他们就会立即停止发送付款票据。
    • 当你收到一张中奖的票据时,你使用一个链上交易来获取它,它就会从发送者锁定的token中把中奖金额传输给你。

    即使票据没有中奖,你仍然有加密证据证明你是要收取付款款项的。因为无论是发送者还是接收者都不能操纵决定该票据中奖的额度。有了这个证明,你会很乐意继续向观众播放视频。当成千上万的(新)观众连接到你的时候,任一观众都不会有任何开销——唯一的开销是在你获取中奖票据的时候产生。

    对于特定的“平均总付款”,中奖的几率(和票据的频率)决定了链上交易的数量。因此,中奖金额越高,随着时间的推移,接收者支付的交易费用就越少。中奖金额越低,需要被发送者锁定的token就越少,从而也降低了他们的流动性成本。

    对于在线视频来说,合理的中奖金额应该是2.78美元。对于电力或能源市场来说,可能是27美元。

    防止双重支付

    概率支付的一个至关重要的部分是确保双重支付不会发生,或者说,双重支付会让发送者将无利可图。前面提到的“罚金托管”,能让发送者无法通过双重支付获利。正确的操作方式是,发送者必须在他们能够创建票据之前锁定(提交)一定倍数量的票据中奖金额。接收者可以核实发送者不仅有足够的资金来支付中奖票据,而且他们的罚金暂交第三方托管后也有足够的余额。

    如果出现双重支付的情况,在发送者的余额不足以支付该票据之后,中奖票据的链上索取要求将导致发送者的罚款代管账户大幅减少。这就有效地刺激了发送者所需发布的小额存款,创造了发送者双重支付的经济动机。罚金代管的数目应该设置妥当,既能足以阻止双重支付的发生,又不至于给发送者带来太多的不便。

    结论

    就系统而言,以太坊概率微支付相对支付通道有几个优点,它可以为用户提供持续的、有颗粒度的服务。交易费用的减少不仅为有效的微支付,也为实际的纳米支付提供了可能。

    在线视频、电力/能源市场和带宽共享是可应用系统的优秀案例。我们不需要承担每对发送者-接收方的设置成本,也不需要使用复杂的支付通道网络,我们只要求每个接收者都有一个链上交易。服务提供者可以立即开始对用户进行服务,不存在有人吃白食的风险;而用户一旦停止接收服务,他们也可以迅速断开连接。

    这使得服务可以完全避免免费服务的成本,同时也可以立即阻止服务攻击,因为我们可以要求,甚至是第一个要求有附加的微支付服务。

    PS.感谢David Salamon,他在我们的研究期间独立得出了概率微支付模型,而后我们才意识到概率微支付的概念可以追溯到1996年的文献。(可参考我们的白皮书)。


    链接: https://medium.com/@gustav.simonsson/ethereum-probabilistic-micropayments-ae6e6cd85a06

  • 相关阅读:
    jvm 指令 invokedynamic
    go switch
    JVM指令 bytecode invokespecial
    babel插件开发
    go 循环依赖 循环引用 最佳实践
    go module 使用入门
    搞懂gopath golang go go项目结构
    SQL Server 工具
    SQLServer Management Studio登录框中的“服务器名”填写
    win2008下安装SQL SERVER 2005出现IIS功能要求 警告解决方案
  • 原文地址:https://www.cnblogs.com/hzcya1995/p/13312957.html
Copyright © 2011-2022 走看看