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