访问列表:在执行交易前,通过访问列表提前确定交易将要读取和修改的存储地址。访问列表包含了每个交易需要访问的所有状态信息。 调度算法:调度算法根据访问列表将交易安排在不同的线程上执行,确保同时执行的交易不会访问相同的存储地址,从而避免冲突。 并发执行:在实际执行时,多个交易可以在不同的线程上同时进行,调度算法确保了这些交易之间没有相互依赖或冲突。
实例化多个 EVM:在一个节点上创建多个 EVM 实例,每个实例都能够独立运行并处理交易。 分配交易:将待处理的交易按照某种策略(如哈希值、时间戳等)分配给不同的 EVM 实例。 并行执行:每个 EVM 实例在自己的线程中执行分配给它的交易,多个实例可以同时运行,从而实现并行处理。
数据分片:将整个区块链状态划分为多个分片,每个分片包含一部分全局状态信息。 分片节点:在每个分片上运行多个节点,每个节点负责维护和处理该分片内的交易和状态。 跨分片通信:通过跨分片通信协议,确保不同分片之间的数据一致性和交易的全局顺序。跨分片通信可以使用跨分片消息传递和跨分片锁定机制来实现。 并行处理:每个分片内的节点可以独立处理该分片内的交易,同时多个分片也可以并行运行,从而实现整个系统的并行处理能力。
乐观执行方法:在区块中较早的交易完成之前开始执行后续交易,这有时会导致执行结果不正确。为了解决这个问题,Monad 跟踪交易执行中使用的输入,并将其与之前交易的输出进行比较。如果发现差异,表明交易需要重新执行。 静态代码分析:Monad 使用静态代码分析器在执行过程中预测交易之间的依赖关系,避免无效的并行执行。在最佳情况下,Monad 可以提前预测许多依赖关系;在最差情况下,Monad 会回退到简单的执行模式。
高效通信:采用配对的 BLS 签名来解决可扩展性问题,允许签名逐步聚合成一个签名,证明与公钥相关的共享已签署消息。 混合签名方案:BLS 签名仅用于可聚合消息类型(如投票和超时),消息的完整性和真实性仍由 ECDSA 签名提供。
更大的容错性:由于执行只需跟上共识的速度,这种方法对特定计算时间的变化更为宽容。 Merkle 根延迟:为确保状态机复制,Monad 在区块提案中包括一个延迟 d 个区块的 Merkle 根。这确保了整个网络的一致性,即使存在节点执行错误或恶意行为。
智能区块传播和乐观区块处理:通过提供所有相关交易哈希值,加速交易处理时间,并减少延迟和增加吞吐量。 本地订单匹配引擎:不同于当前常用的自动化做市商(AMM)系统,SEI 使用链上订单簿来匹配特定价格的买卖订单。所有基于 Cosmos 的去中心化应用(dApps)都可以访问 SEI 的订单簿和流动性。 频繁批量拍卖(FBA):将交易组合成批次,在每个区块内同时执行订单,以防止跑单和 MEV。
交易费: SEI 币用于支付 Sei 网络上产生的交易费。这些费用可作为验证者的激励,并有助于网络的安全。 质押:用户可以质押 SEI 币来获得奖励并增强 Sei 网络的整体安全性。 治理: SEI 代币持有者有能力积极参与 Sei 网络的治理。这种参与包括对提案进行投票和选举验证者。
技术原理:Eclipse 使用 SVM 的 Sealevel 运行时,这一运行时允许非重叠状态的交易并行执行,而不是按顺序执行。 实现方式:通过明确描述每笔交易在执行期间会读取或写入的所有状态,SVM 可以并行处理不涉及重叠状态的交易,从而显著提高吞吐量。
Neon EVM 集成:为了实现 EVM 兼容性,Eclipse 集成了 Neon EVM。这使得 Eclipse 主网能够支持以太坊字节码和 Ethereum JSON-RPC。 本地费用市场:每个 Neon EVM 实例都有自己的本地费用市场,应用可以通过部署自己的合约获得应用链的所有好处,而不会破坏用户体验、安全性或流动性。
基础设施层:Eclipse 旨在成为 Layer 3 生态系统的基础设施层,通过支持 dApp 特定的 Layer 3 Rollup 实现高性能和可扩展性。 简单来说,Eclipse 的设计逻辑是,交易执行在 Solana 的 SVM 中,交易结算仍在以太坊上。
