作者：waxwing
一句话总结：通过与单一中心实体共同拥有的 2-of-2 合约来给 L2 注资，但无需信任这个中心实体。我用来自论文【1】的摘要以及一套 Q&A 作为总结，我觉得这是介绍这个想法的最好办法。
一种与一个中心（hub）签订的合约，让用户可以在一个 layer 2 上持有这个中心的 token，并在需要时取出成比特币，无须信任这个中心的正直（honesty）和活性（liveness）。这种 L2 token 是以 用户-中心 的多签名输出中的比特币作为担保品的，如果这个中心拒绝取款，或者无法应答（因为 TA 离线了），那么取款会在比特币区块链上强制执行。唯一的假设是，这些 layer 2 自身是与中心隔离的。无须改变比特币共识。一次取款就是一个声明，声称一个程序（取款语句）在一些输入上运行会产生一个输出：这个语句会用 RISC Zero 来证明，并用 Groth16 来封装；有争议的声明则用 BitVMX【5】在比特币区块链上裁决；BitVMX 的对一个 RISC-V 程序（在这里是一个 Groth16 验证骑）的交互式搜索，是这种设计的技术核心。取款是在通道内合作式执行的 —— 以压倒性的概率，因为声明可以在几毫秒内确定性地验证 —— 不然的话，被拒绝的取款操作就要作为 BitVMX 链上搜索而运行，每个合约都需要预先签名一次。免信任的收益的背后是流动性代价（收款能力仅仅取决于由中心提供的 “入站流动性”，跟闪电通道一样）。在正常运行期间，这个中心必须保持在线，因为离线的中心无法在超市之前解决争议（但用户不受此限）。这套设计已经在 regtest 测试网上开发好并度量过性能：取款语句的一个真实证据，在 BitVMX 的未打补丁的 Groth16 验证器上运行 4.78 亿步后被接受，意味着在争议的最坏情况下，在链上需要 22 笔到 25 笔交易的 8 元搜索。
以下是我的 “Q&A” 方法，希望能解决各位最先想到的问题。
- 一个中心非常危险！
如果这个中心消失，用户会拿到所有钱。这个中心无法通过伪造 token 来女巫攻击用户；诚实用户的钱总是有担保的。剩下的唯一风险是 L2 自身的（它是一个 “有效性 rollup” 还是一个委员会？它会从比特币继承终局性，还是其终局性会更弱？等等。）
- 桥接合约通常表示，你只能取出一个固定金额的 UTXO，也就是你需要运营者、还有依赖于互换服务。这里也一样吗？
并不。在争议情形中，取款的数额是以比特币编码，放在比特币交易的见证中的。这让用户可以通过多个特定面额的输出取出任意的数额。
- 这些构造通常需要一个签名会中有 1-of-n 诚实参与者的假设，不是吗？
也不是。在这里，我们通过 LN-GAP 的技巧规避了这一点：合约是中心和每一个用户的双向合约；预签名发生在中心与每一个用户之间，就跟闪电通道一样。
- 但如果许多用户都跟一个中心开设通道，他们 —— 本来就可以通过通道来相互支付呀？
这种批评是有道理的，有一些吧 ，如果 L2 账本只做普通的支付、别的什么也不干的话（那使用这么复杂的设计确实用处不大）。但即便如此，你也能避免需要收款方在线的要求、避免路由以及其他琐碎事情。认真的回答是：这样的 L2 可以提供更多功能。它可以使用 Zcash 那样的隐蔽票据，实现非常高的隐私性，同时保持在 L2 内。它也可以（在另一个中心的另一个 “lichen” 实力内 ）提供富状态的智能合约，等等。
- 但这是一种 IOU（借条）/中心 token，它不是真正的比特币。
不是这样的，但有一个重要提醒。先看第一点：每一聪都能通过 用户-中心 合约来赎回，无须 中心的许可，并且是一对一的，所以它们就是真正的比特币，但仅在你有收款额度时，你才能接收它们。这样的 L2 的一个新的用户，跟中心还没有合约，就没有收款额度；或者， 有可能，一个用户会在 L2 中持有大量余额，远远超过其自己合约的收款额度，这时候，超出的部分就是 积分，没有同样的保证。但这是他们自己的选择。
- 但使用一个中心感觉还是个坏设计。为什么不实用多个中心呢？
这是考虑到这些 L2 token 的行者。它们是同质化的、可以强制执行 的对中心财产的请求权；它们也可以由中心自己铸造出来，全看它们自己的医院。如果你使用了 hub 1 和 hub 2，那这些请求权就无法免信任地转移给中心自身。如果 hub 2 凭空印出了 10 亿聪、用户在 L2 上接受了、然后就能在 hub 1 上取出来，那么 hub 1 就被卖了。由此，我们看到了它跟 ecash 服务器的一个有趣对比：hub 可以随心所欲地发行 token，但它们无法 盗窃/“跑路” 。
- 好吧，那缺点是什么？
缺点有两个：其一是流动性，这也是很容易理解的，就跟闪电通道的收款额度痛点一样，因为确实两者是差不多的。中心 可能 不会给一个用户提供任何收款额度：也就是用户只拿到了 L2 tokne 来花，但无法（安全地）收款。要是收款，收到的也只是积分，其他人有可能花钱来买这些积分，但没有保证。但这套设计并没有假设中心会这样，它允许收款到一定 “限额”：用户可以在跟中心建立合约时，协商额外的潜在收款数额（收款额度）。第二个缺点是非常具体的，而且是一种设计抉择，不是一种截然的要求：我们使用 BitVMX 的二分搜索（实际上是 8 进制的，并不是二分的），以在链上要求 ZKP 是有效的。在最坏情况下，可能需要 20 到 25 笔交易来裁决争议，而且可能需要瞭望塔设计，才能让用户放心。在一个正确开发的实现中，这是非常罕见的，因为不正确的一方（很容易找出）是一定会支付所有手续费（以其储备数量为限）、并且失去钱的。
论文【1】提供了许多细节。而代码库有一个 “完整的” 概念验证样品（从整个 L2 包含证明到 STARK、到 STARK 的 Groth16 验证器；这就是要放到链上来裁决争议的 Groth16 验证器）。
我认为这个设计是非常有趣的。显然比一个完全通用的 L2 更加局促（不在功能性上，在可扩展性上），但也更容易实现（事实上，我不觉得有什么因素能阻止人们立即开发并运行 lichen 实例【2】）。我猜，看待它有许多不同的方式。欢迎反馈。
（还有一件事：为什么要使用 BitVMX 这样的多轮协议？主要是因为它真的可以开发出来。我不知道 BitVM3、BABE、Gock 以及它们的后代 PIPEs、等等方案的开发现状；当然，BABE 可能是（对 Lichen 来说）最有趣的替代品，我也不确定。）
【1】论文放在：https://github.com/AdamISZ/lichen/blob/master/papers/lichen-draft.pdf
【2】前提是必须对实现 BitVMX 争议游戏的所有细节有信心。不用说，你可以轻松让一个 LLM 给你 “做一个出来”，但它有许许多多活动的部分，需要仔细检查。我这样说是出于经验，而且我可能很快就会拥有更多这样的经验 ……
（未完）