网站一直做竞价么,网站是com好点还是cn,旅游网站建设网,为什么最近好多网站打不开了1. 引言
前序博客有#xff1a;
基于BitVM的乐观 BTC bridgeBitVM#xff1a;Bitcoin的链下合约Bitcoin Bridge#xff1a;治愈还是诅咒#xff1f;
最初的 BitVM 设计仅限于两方设置。BitVM2结合了并行和冗余实例#xff0c;以引入基于 1-of-n 诚实假设的多方配置。这…1. 引言
前序博客有
基于BitVM的乐观 BTC bridgeBitVMBitcoin的链下合约Bitcoin Bridge治愈还是诅咒
最初的 BitVM 设计仅限于两方设置。BitVM2结合了并行和冗余实例以引入基于 1-of-n 诚实假设的多方配置。这些合约的主要限制是
所有Verifiers都必须在编译时定义。此外设置成本随着Verifiers数量的增加而增加。
这意味着
要破坏合约必须贿赂的当事人数量总是有限的。
BitVM2 是一种新颖的变体任何人都可以充当Verifier
仍需要使用 1-of-n 诚实假设进行一次性设置但在运行时任何人都可以挑战无效的断言而不必成为初始 n个联盟成员之一。 这克服了以前方案的局限性并改进了它们的信任假设。此外简化了整体设计并将trial的最大长度减少到两轮。
bridge还额外需
预定义的m个operator且至少其中一个operator必须诚实行事。然而即使所有operators都不诚实他们也无法窃取任何存款最坏的情况只是烧掉它们——即浪费资金变得不可用。
BitVM针对的问题为
对于给定的程序 f f f想要验证对于某输入 x x x和输出 y y y断言 f ( x ) y f(x) y f(x)y是否成立。如 f f f可以是某SNARK Verifier如用于 Groth16 证明系统。然后 x x x将是一个proof且 y y y是 SNARK 证明其有效性的某种输出状态。
若 f f f是 SNARK Verifier则程序太大无法用单个比特币脚本来表示。实现 Groth16 Verifier可能会产生 20MB 的脚本。然而最大脚本size是比特币区块大小 4MB。即使这样的size也可能大得不切实际。
2. 简单的解决方案
Lamport 签名提供了一种将程序拆分 f ( x ) y f(x)y f(x)y为多个步骤的方法。如 n 42 n42 n42步 f 1 ( x ) z 1 f 2 ( z 1 ) z 2 f 3 ( z 2 ) z 3 . . . f 42 ( z 41 ) z 42 f 43 ( z 42 ) y f_1(x) z_1 \\ f_2(z_1) z_2 \\ f_3(z_2) z_3 \\ ... \\ f_{42}(z_{41}) z_{42} \\ f_{43}(z_{42}) y f1(x)z1f2(z1)z2f3(z2)z3...f42(z41)z42f43(z42)y 这样 f f f的计算可分散在多个区块上执行的 43 笔交易序列上。每笔交易将前一笔交易的输出状态作为输入状态。若Prover对任何状态 z i z_i zi模棱两可那么每个人都可以使用冲突的 Lamport 签名作为fraud proof欺诈证明。
这种方法提供了一种无需许可的方式来挑战Prover。然而该解决方案的主要限制是
其沉重的链上足迹因为它仍然需要Prover来执行整个计算。还引入了通过 Lamport 签名转换状态的开销。
3. Balanced解决方案
通过将Prover的一些繁重工作转移到Verifier的fraud proof欺诈证明上可显著减少链上足迹。现在Prover只需同时承诺 x x x、 y y y和所有中间结果 z 1 , z 2 , . . . , z 42 z_1, z_2, ... , z_{42} z1,z2,...,z42。
任何Verifier都可以反驳任何错误的断言。在设置过程中定义了一个包含 43 个脚本的 Taptree以反驳 f 1 , f 2 , f 3 , . . . , f 43 f_1, f_2, f_3, ..., f_{43} f1,f2,f3,...,f43的任何计算。若某断言 f i ( z i − 1 ) z i f_i( z_{i-1} ) z_i fi(zi−1)zi不成立则任何人都可从这些脚本中的任何一个中花费。这将最坏情况的总计算减少到由Verifier执行的单个步骤 f i f_i fi。该步骤可能仍然需要大量的脚本实现。理论上只要它适合单个区块或者更好的是 400kbstandardness size。实际上对于 f f f的某些具体实现会尝试在
Prover的commitment size和 Verifier的script size
之间找到最佳平衡。
实际上这允许任何人在Prover做出任何不正确的断言时破坏Prover的output。否则如果没有人反驳计算的任何部分那么脚本就会超时并让诚实的Prover花费output。总共最多也就两轮。
该机制可以充当permissionless bridge verifier的基石。
4. BitVM2Permissionless Optimistic解决方案
以下协议改进了上述设计的happy path希望是common path但代价是在最坏的情况下引入了两轮交互
1Prover提交输出状态y2若不正确任何人都可以发起挑战3Prover承诺中间结果 z 1 , z 2 , . . . , z 42 z_1, z_2, ... ,z_{42} z1,z2,...,z424若不正确任何人都可反驳断言 f i f_i fi
为此
以上设计的主要问题在于Prover可窃取一些fees费用。在这种情况下存款仍然是安全的但Verifier失去了其抵押品。
攻击场景如下
Prover是恶意的Prover在没有有效 PegOut_Tx 的情况下执行其 KickOff_TxProver等待Verifier执行Challenge_TX支付Prover执行挑战Prover不执行挑战只是停止响应
以下修改解决了费用问题。但需要另外两个 n-of-n 预签名交易
经改进后的设计要求
至少有一个诚实的Operator
否则资金最终将变得不可用。实际上活性失败可用于通过勒索攻击窃取资金。 如只有你向我支付 50% 的赎金我才会解冻你的资金。
参考资料
[1] 2024年3月 Robin Linus gist BitVM 2: Permissionless Verification on Bitcoin [2] BitVM 2: Permissionless Verification on Bitcoin
