Subscribe to 阿5
Subscribe to 阿5
Share Dialog
Share Dialog
<100 subscribers
<100 subscribers
optimistic etherscan 29307 包含72 transactions
etherscan txHash
0x8c81f25ab1c3e9f4359f0d605a2e12a5a73cbfba6cdb340c66ccf0a5ea2439df
合约0x5e4e65926ba27467555eb562121fac00d24e9dd2 ，即layer1上的Ethereum(Optimism: Canonical Transaction Chain，权威交易链)，权威交易链是一个追加型 日志，它代表Rollup链的“正式历史”（所有交易以及其顺序），链接如图所示：
交易可以由Sequencer等提交给CTC。为了保留L1的抗审查 能力，任何人都可以将交易提交到此队列，并在一定滞后期之后将其包括在CTC中。
CTC为每批发布的L2交易提供数据可用性。可以通过两种方式创建批处理：
预计每隔几秒钟，Sequencer就会检查接收到的新交易，将它们分批汇总，以及所需的任何其他元数据。然后，他们 利用appendSequencerBatch将该数据发布到以太坊。这是由批处理提交者batch_submitter服务自动完成的。
当Sequencer审查其用户或当用户执行从L1到L2的交易，用户需要调用enqueue和appendQueueBatch，这会强制在CTC中 包含交易.
你可能会注意到，appendSequencerBatch没有任何参数。批次以紧密打包的格式提交，而使用ABI编码和解码则效率要 低得多。它使用内联汇编来对calldata进行切片，并以预期的格式将其解压缩。
一个批次由以下部分组成：
批次头
批处理上下文（> = 1，请注意：此上下文与我们在上面的“ OVM”部分中提到的消息/交易/全局上下文不同）
交易（> = 1）
批次头指定了上下文的数量，因此序列化的批处理看起来像是 [header, context1, context2, …, tx1, tx2, … ]
该函数继续执行以下两项操作：
验证所有与上下文相关的不变量是否适用
根据已发布的交易数据创建默克尔树
如果通过了上下文验证，则该批次将转换为OVM链批次头，然后将其存储在CTC中。
存储的批次头包含该批次的merkle根，这意味着证明已包含交易是提供针对针对CTC中存储的merkle根进行验证的 merkle证明的简单问题。
SCC包含状态根列表，在乐观情况下，该列表对应于 针对先前状态在CTC中应用每个交易的结果。如果不是这种情况，则欺诈验证过程将删除无效的状态根，然后删除所有 无效的状态根，以便可以为这些交易提出正确的状态根。
与CTC相反，SCC没有任何酷炫的数据表示形式。它的目的很简单：给定状态根列表，它会对其进行存储并保存批处理中 包含的中间状态根的merkle根，以供以后通过appendStateBatch用作欺诈证明。
Sequencer执行3件事：
接收用户提交的交易
批量汇总这些交易并将其发布在权威交易链中
在状态承诺链中将交易产生的中间状态根发布为状态批。Sequencer执行3件事：
接收用户提交的交易
批量汇总这些交易并将其发布在权威交易链中
在状态承诺链中将交易产生的中间状态根发布为状态批。
Goal: A sandboxed environment which guarantees deterministic smart contract execution between L1 and L2.
Optimism’s solution is the Optimistic Virtual Machine. The OVM is implemented by replacing context-dependent EVM opcodes with their OVM counterparts.
方案：修改Solidity和Vyper编译器以生成OVM字节码
optimistic etherscan 29307 包含72 transactions
etherscan txHash
0x8c81f25ab1c3e9f4359f0d605a2e12a5a73cbfba6cdb340c66ccf0a5ea2439df
合约0x5e4e65926ba27467555eb562121fac00d24e9dd2 ，即layer1上的Ethereum(Optimism: Canonical Transaction Chain，权威交易链)，权威交易链是一个追加型 日志，它代表Rollup链的“正式历史”（所有交易以及其顺序），链接如图所示：
交易可以由Sequencer等提交给CTC。为了保留L1的抗审查 能力，任何人都可以将交易提交到此队列，并在一定滞后期之后将其包括在CTC中。
CTC为每批发布的L2交易提供数据可用性。可以通过两种方式创建批处理：
预计每隔几秒钟，Sequencer就会检查接收到的新交易，将它们分批汇总，以及所需的任何其他元数据。然后，他们 利用appendSequencerBatch将该数据发布到以太坊。这是由批处理提交者batch_submitter服务自动完成的。
当Sequencer审查其用户或当用户执行从L1到L2的交易，用户需要调用enqueue和appendQueueBatch，这会强制在CTC中 包含交易.
你可能会注意到，appendSequencerBatch没有任何参数。批次以紧密打包的格式提交，而使用ABI编码和解码则效率要 低得多。它使用内联汇编来对calldata进行切片，并以预期的格式将其解压缩。
一个批次由以下部分组成：
批次头
批处理上下文（> = 1，请注意：此上下文与我们在上面的“ OVM”部分中提到的消息/交易/全局上下文不同）
交易（> = 1）
批次头指定了上下文的数量，因此序列化的批处理看起来像是 [header, context1, context2, …, tx1, tx2, … ]
该函数继续执行以下两项操作：
验证所有与上下文相关的不变量是否适用
根据已发布的交易数据创建默克尔树
如果通过了上下文验证，则该批次将转换为OVM链批次头，然后将其存储在CTC中。
存储的批次头包含该批次的merkle根，这意味着证明已包含交易是提供针对针对CTC中存储的merkle根进行验证的 merkle证明的简单问题。
SCC包含状态根列表，在乐观情况下，该列表对应于 针对先前状态在CTC中应用每个交易的结果。如果不是这种情况，则欺诈验证过程将删除无效的状态根，然后删除所有 无效的状态根，以便可以为这些交易提出正确的状态根。
与CTC相反，SCC没有任何酷炫的数据表示形式。它的目的很简单：给定状态根列表，它会对其进行存储并保存批处理中 包含的中间状态根的merkle根，以供以后通过appendStateBatch用作欺诈证明。
Sequencer执行3件事：
接收用户提交的交易
批量汇总这些交易并将其发布在权威交易链中
在状态承诺链中将交易产生的中间状态根发布为状态批。Sequencer执行3件事：
接收用户提交的交易
批量汇总这些交易并将其发布在权威交易链中
在状态承诺链中将交易产生的中间状态根发布为状态批。
Goal: A sandboxed environment which guarantees deterministic smart contract execution between L1 and L2.
Optimism’s solution is the Optimistic Virtual Machine. The OVM is implemented by replacing context-dependent EVM opcodes with their OVM counterparts.
方案：修改Solidity和Vyper编译器以生成OVM字节码
No activity yet