Special thanks to Mark Tyneway, Meredith Baxter, and Mofi Taiwo for feedback and review. The OP Stack is introducing native L2<->L2 interoperability in an upcoming hardfork, enabling Superchain members to communicate efficiently and securely with intra-block latency. Recently, OP Stack protocol engineers gathered to work on a design for the Superchain's new bridge proof, a key component to the secure release of this feature. During this time, we put together a working version of the proof in two implementations: op-program and kona. Interop The OP Stack's Interop feature, from the application developer's perspective, has a pretty thin overview. Within the Superchain, smart contracts can emit logs (Initiating Messages), and smart contracts on other L2 chains can optimistically relay that log via the CrossL2Inbox predeploy (Executing Messages). Logs that are relayed are guaranteed to be present in the remote chain if the block is included. Notably, intra-block cross-chain messaging is supported, meaning usecases such as cross-chain flashloans are possible with security guaranteed by the protocol. On the protocol's end, the OP Stack's flavor of interop makes use of optimistic message relay to prioritize a snappy user experience, with the sequencer instating a policy to check for message validity before signing and sending out an unsafe payload to its peers. To save you a click:

Introducing Today, @andreaslbigger and I are thrilled to announce the MVP of kona, a suite of portable, no_std Rust implementations of the OP Stack rollup state transition. Early in June, our team at OP Labs released the Stage 1 milestone on OP mainnet. This week, the kona repository includes the first alternative Fault Proof Program for the OP Stack, delivering a critical piece of redundancy in the proving system on the road to Stage 2 Decentralization of the OP Stack as a whole. How does it work? At a high-level, verifying the correctness of a claim about the state of an OP Stack L2 on the DA layer consists of bootstrapping trusted inputs, deriving the inputs for the L2 chain, executing the derived inputs statelessly, and finally asserting the correctness of the L2 claim against the produced L2 chain. The process is modeled in three separate phases, outlined below.

"Large preimage proposals" are an optimization over the original, computation-heavy solution, where instead of performing the absorption and permutation on-chain for each keccak block absorbed, the user posts commitments to the computation. The submitter of the large preimage will still need to post the full pre-image on-chain through calldata so that it is available, but rather than doing the expensive SHA3 computation on-chain, we merkleize the keccak blocks + a commitment to the internal keccak256 state matrix by adding the input to an append-only merkle tree. If there is an incorrect state matrix claimed, a challenger can provide a merkle proof for the prestate and poststate leaves, and perform a single step of the keccak permutation on-chain to disprove the claimed data. Smart Contract Semantics Merkle Tree Structure For each large preimage proposal, a tree of depth 16 is allocated. This supports preimages up to $2^{16} = 65,536$ keccak blocks in size, or ~8.91 MB. The merkleization process follows the exact same semantics as the Beacon Deposit contract, where we begin with an empty merkle tree with all leaves set to 0: image Source: https://medium.com/@josephdelong/ethereum-2-0-deposit-merkle-tree-13ec8404ca4f

"RISC architecture is going to change everything." - Angelina Jolie with Sade playing in the background (??) asterisc is a RISC-V 64 VM written by @protolambda, designed to prove correct execution of a RISC-V program with an interactive fault proof. Following its counterparts in the OP Stack ecosystem, cannon & cannon-rs, which both emulate the MIPS32rel1 ISA, it's an awesome upgrade. Though asterisc was initially designed primarily for supporting a subset of the RISC-V ISA and Linux syscalls that Golang uses, I got curious and wanted to spike out support for Rust programs on it as well. State of the World As it stands, asterisc is nearly feature complete, and supports the following extensions of the RISC-V instruction set (pulled directly from the project's README): RV32I support - 32 bit base instruction setFENCE, ECALL, EBREAK are hardwired to implement a minimal subset of systemcalls of the linux kernelWork in progress. All syscalls used by the Golang risc64 runtime. RV64I support