域修网 Web3.0元宇宙 BEVM: 如何实现去中心化的C layer2

BEVM: 如何实现去中心化的C layer2

BEVM: 如何实现去中心化的C layer2

目前市面上主流的C跨链桥

  1. WC:中心化多签托管1:1 发行在以太坊主网上的包装代币。43亿美金

  2. tC:分布式门限签名1:1 托管发行在以太坊上的C包装代币。5000万美金

  3. L-C:Liquid侧链1:1 发行的C包装代币。8000万美金

  4. 闪电**:代币锁定在主网,链下票据无需gas 点对点做支付转账。1亿美金

C 完全去中心化 Layer2 的两种思路

  1. 把闪电**这种OP Rollup的模型做拓展,不局限在做支付,可以做任意的合约操作。BitVM是这种思路。

  2. 把tC这种分布式门限签名做到链上去中心化,BEVM是这种思路。

BEVM:兼容EVM的完全去中心化的Bitcoin Layer2

BEVM是一个兼容EVM生态,并以原生C作为gas的去中心化的Bitcoin Layer2,BEVM把EVM生态引入C,让比特币生态也具备发行资产、构建应用的能力。具有以下技术特点:

  1. EVM:完全兼容EVM生态、metamask等钱包、truffle/hardhat等开发框架、solidity编程语言。

  2. C原生gas:使用原生C作为EVM的gas费。与ETH Layer2 OP/Starknet 类似,ETH用作 Layer2 的Gas 费。

  3. Taproot Threshold Signature:链上POS 节点,确保阈值签名验证者的去中心化。单一隐私通信协议,确保聚合的 schnorr 签名 pubkey/msg 的安全性。

  4. 比特币轻节点:C链上支持Wa版本(no_std)的轻节点。

  5. Signal Privacy Distributed Protocol:Signal 协议,保证 schnorr 聚合签名和 Mast 合约组合门限签名时节点间消息通信的隐私性和安全性。

  6. zkstark超轻节点:针对上述轻节点的优化,可以利用zkstark技术来实现C的超轻节点。

BEVM去中心化安全C layer2的关键:链上分布式门限签名合约托管,让分布式门限签名托管人可以做到 1000个

1.利用 Taproot(schnorr + mast 合约) 结合, 生成一个C主网上门限签名合约地址(可以设定 M/N 的门限阀值, N可以选定到 1000人,M/N 一般取值2/3)

2.让C 主网上门限合约地址的N个参与者作为 C layer2的POS验证节点, C的门限合约的N个托管人和Layer2 上的POS 验证节点完全重合,整个C托管的安全性和去中心化依赖于Layer2 POS**共识的安全性和去中心化。

3.L2/BEVM会完全实现一个C 的链上轻节点,这样可以保证C链上的数据可以实时的同步到BEVM**上。换句话说:BEVM的所有节点都有C**的数据。

4.BEVM的POS**可以做到 1000个验证人,同时这1000个验证人也是 C托管合约的 共同托管人,只有这1000个验证人 大于2/3的验证节点 在共识层签名后才能操作 C和C**上资产从 L2 跨到L1。资产从C L1跨到L2,只需要用户在C** 往这1000个验证人的门限托管地址转移token或者C,自动会在C Layer2 BEVM上收到L2 上的资产。

BEVM和其他Layer2/跨链方案对比。

虽然tC已经比wC要去中心化多了, 但BEVM 的跨链模式相比于tC的门限签名还可以有如下的优点:

  1. 无需集中初始设置。无需使用分片私钥实现分布式门限签名,避免了分片私钥带来的私钥泄露的安全问题。直接使用C原生的门限签名方案:MuSig2。

  2. 链上分布式**,更加去中心化。分布式门限**的验证者都是链上的区块验证节点,链上的**增加了信任。避免了链下分布式**不透明、易操作的缺陷。

  3. 无需许可,只需信任代码即可。C to Layer2**使用C轻节点。完全信任代码的区块链逻辑,避免了向链下分布式**提交数据预言机带来的中心化欺诈问题。

  4. 分布式**通信,完全隐私。Signal协议用于完成C主根门限签名的通信问题。解决分布式**的隐私通信问题。避免门限签名出现时数据泄露、串通或外部攻击的风险。

BEVM 和 BitVM 相比

BitVM是ZeroSync的负责人Robin Linus推出的一种表达图灵完备比特币合约的计算范式,根据***,BitVm 合约类似于以太坊上的OP Rollup。合约不是在比特币上执行计算,而是在不需要更改**共识角色的情况下进行验证。

BitVM的OP Rollup的执行VM,有三大应用推广的缺陷。

  • 局限在只能双方,而Defi基本需要三方(其中不可缺失的一方是链上合约托管账户地址)才能正常运行。

  • 双方的链下往C主网发起挑战的模式, 操作会比闪电**更复杂和困难。

  •  短时间无法做成BEVM这种成熟的通用链上Layer2平台。

本站声明:网站内容来源于**,如有侵权,请联系我们,我们将及时处理。