获奖作品Pisa：layer2方案的补充方案。
Pisa方案专注可打造任意应用程序（支付、拍卖、董事会投票、游戏等）的通用状态通道。方案的贡献在于引入了一种第三方代理（称为“托管人”）的新协议。 托管人专门用来应对状态通道中各参与方需保持在线（与区块链同步的意思）的假前提。
简言之，比萨属于区块链三产，允许通道使用者（甲方）雇个托管人替自己看着状态通道，出了问题，可以对托管人问责。
进入Pisa方案前，先来了接下所谓的‘通用状态通道’怎么回事。
通用状态通道
状态通道的概念比较好理解，说不熟的一撮人想联合执行一个程序。这波操作有这么几个特点：
1. 程序依赖链上记录的信息，且程序的执行结果有可能影响到链上其他程序的状态。
2. 执行并不在链上，而是 ‘私（链）下’进行的。
这就要求参与各方集体就程序的每个新状态达成一致并签字，以此覆盖旧状态。 理想状态下，意思是各方都配合，所有人都在本地（链下）保持着最新的状态。但是，万一有人出于各种原因撂挑子了，则无法就新状态达成一致，那么这个“半拉状态”想名正言顺的变成新状态，就得挪到链上进行共识。 某种程度上讲，状态通道以全局区块链作为信任源，允许各方运行本地共识协议，同时保证程序执行的执行程序的现场感以及正确性。
各方都不出幺蛾子，通道中的执行操作就能流畅进行，因此有效避开了区块链网络中的延迟（即链上确认时间）及交易费用。
但是，但是，状态通道有个很大的前提，就是默认（假设）各方都会保持在线且与区块链同步的状态。
“一直在线”？
若一方长时间处于离线状态，则其他方可以串通好通过全局区块链执行分叉，意思是对职智能合约的执行进行分叉，结果就是（不可逆转地）推翻之前全部本地执行。更有甚者，还会盗取通道内全部资金。于实际使用来说这肯定是不行的，首先各方是想要有个稳定长期的通道在，但是不能保证始终在线。
斜塔出手（Pisa）
图文摘自: Pisa: Arbitration Outsourcing for State Channels
系统概述：普通通道中（顶），各方（A、B）在链下通过AuthState授权状态迁移（1），但可能出现需提交链上处理的争议情形。Pisa方案（下）中，通道内各方交互不变，但A可以使用Appoint委托第三方托管人，因此A离线时，托管人可代表A提交状态哈希。此外，Pisa方案确保若托管人未尽职履行责任，A获得公开可验证收据，并通过链上追索对托管人实施惩罚。
那么，为应对这个问题，引入了Pisa协议，允许通道用户聘用第三方代理，叫做托管人，替自己看着状态（及支付）通道。 与之前的岗楼[1]、通道监测[2]等面向支付通道的方案不同，Pisa的设计面向通用状态通道，具有以下特性：
状态隐私：托管人只接收状态的哈希，而非状态本身。只有被提交至区块链做争议处理时，托管人才有可能知道自己被雇来看着哪个状态。
O（1）存储：托管人只能存储甲给的新“活儿”。上面说过了，给过来的东西是状态的哈希和通道中各方的签名。
公开可证的‘承揽合同’：其实就是一个公平交换协议，甲方付款后托管人给个签名收据，证明托管人已经收完钱同意替甲方看着通道。
公平（实时）奖金：白话叫一码是一码，看一次付一次钱。 注意，劳务费都是先付的，不管需不需要上链执行争议处理。人家是替你看着而已。
客户追索权（托管人问责）：甲方离线时，托管人有可能不好好干活。Pisa协议对此采取的手段是财务威慑，白话叫扣钱。 甲方能证明（用收据）托管人不好好干活或者不干活时，托管人之前缴的安全保证金将自动被没收/烧毁。
总之吧，想要部署任何托管人协议，这些属性是必要条件。所谓融合了加密手段的消费者保护：花钱的有法申诉、收钱的好好干活、被逮住不好好干活就扣钱。。。
接下来呢？
Pisa论文中还提出了通用状态通道构造（受Sprites启发），能用来打造任意App。然后，托管人还能看着对使用此结构构建的App进行检测。
致谢：
感谢Lefteris Karapetsas（雷电）在Devcon3提出的监测相关问题，感谢整个雷电团队在Pisa开发时提供的各种反馈意见。
相关阅读：
[1] 岗楼
https://scalingbitcoin.org/transcript/milan2016/unlinkable-outsourced-channel-monitoring
[2]通道监测
https://scalingbitcoin.org/transcript/milan2016/unlinkable-outsourced-channel-monitoring
http://hackingdistributed.com/2018/05/22/pisa/
网友评论