当前位置: 首页 > 工具软件 > light-rpc > 使用案例 >

nil Foundation的Solana-Ethereum Bridge Based on Light-Client State Proof Verification

谯翔
2023-12-01

1. 引言

前序博客有:

nil Foundation团队并不负责实现整个Solana-Ethereum Bridge本身,而是负责completely trustless bridge的核心部分:Solana ‘Light-Client’ state verification协议。不过nil Foundation团队也欢迎应用开发者基于其state proof verification 机制来实现完整的token transfer应用。

使用该state proof verification机制的每个应用,通常包含了以下4个核心步骤:

  • 1)Retrieve Solana的‘Light-Client’ state:要求Solana可提供相应的RPC接口,且不应是trusted RPC接口。
  • 2)生成a state proof:对于工程师来说,可将proof生成过程看成是a one-way compression preserving internal data structure knowledge。不过压缩这个词实际上并不准确。
  • 3)将proof提交到以太坊(或任何兼容EVM的链)来验证新生成的state proof的有效性:向以太坊提交state proof以供验证。由于生成的state proof没有recursive特性(即其verification不会验证all the previous state proofs submitted),因此在EVM链上需要维护the sequence of proofs。该sequence源于第一个Solana状态(即"genesis"),并验证该proof由合适的Solana cluster生成,而不是凭空生成的。所有这些都在EVM中实现相应的逻辑,因此,从应用开发者的角度来看,其仅需要向某以太坊RPC端点提交proof即可。
  • 4)以太坊认可该state proof,并将其标记为valid(而不是内部存储该proof):用户或应用开发者仅需等待验证通过即可。

以Token Bridge为例,除以上4个核心步骤之外,需要有相应的应用逻辑:

  • 1)在Solana端需要”lock“ the ”asset“ bridged。
  • 2)由于Solana的’Light-Client’ state中包含了当前validators的信息,因此需要retrieve the particular transaction you are trying to bridge and generate an additional proof for it。由于单笔Solana交易不超过1232字节,因此,生成相应的proof应该不会有任何问题。
  • 3)在以太坊端,需要验证Solana端交易的有效性——通过对比提交并在以太坊链上证明了state proof有效的Soalan Merkle hashes。
  • 4)state proof验证通过后,以太坊端的应用层可以太坊端issue the bridged asset。

最终达到的效果是,仅需要一个web浏览器即可实现跨链,无”relays“,无”tokens“,无”validators“,仅需要依赖密码学假设,而不需要依赖游戏理论(即经济模型)。仅需要a web browser。相比于Wormhole这种基于relay的方案要轻便优秀。

相关demo可参看:【在该demo中展示了以上4个核心步骤,实际应用时应该是自动化的。】

不过,目前本项目仍在开发中,详细的设计文档见:【其bridge proof system中采用了PLONK gate circuit。】

相关代码见:

未来动向为:

  • 做一个proof generation process demo。

参考资料

[1] Solana-Ethereum Bridge Based on Light-Client State Proof Verificatio

 类似资料: