Trebuchet Notes This is a bunch of unstructured notes compiled for Trebuchet. Resources MIPS64 Privileged Resource Architecture MIPS Memory Map MIPS Exceptions Overview MIPS R4000 Manual Linux Kernel Source Notes

Multi-threaded Cannon (Experimental) author: @mbaxter This document discusses the proposed approach to implementing multithreading support in the Cannon VM. The main goal here is to reduce memory requirements of the op-program by enabling Go garbage collection, which requires threading support. Secondarily, this will allow us to remove some patching we do to overwrite unsupported operations from the loaded ELF program. Thread management and scheduling are typically handled by the operating system via syscall operations that give program control over to the OS kernel. To support a minimal implementation of multithreading in the Cannon VM that specifically targets the go1.21 runtime, a few new Linux-specific syscall operations must be implemented. Additionally, the state of the threads in the system must be managed deterministically and in a provable way. Resources Multithreaded Cannon VM

Getting Devnet-3 ETH You can request devnet ETH from the deployed Multifaucet: https://eip4844-faucet.vercel.app/ Uploading Blobs Blobs can be uploaded by sending blob transactions to geth. blob-utils is a handy script that makes it easy to send blob transactions: blob-utils tx\ -rpc-url <your_geth_rpc_url>\ -blob-file <blob_file>\ -to <to_address>\

Prysm setup Clone the eip4844 branch in the Prysm repo and build the binaries $ git clone https://github.com/prysmaticlabs/prysm.git $ cd prysm $ git checkout eip4844 $ bazel build //cmd/prysmctl $ bazel build //cmd/beacon-chain $ bazel build //cmd/validator $ cd ../

[toc] What's Changed? Please read through this document carefully as there have been some changes since the first Devnet. Here's a summary: The geth and beacon clients have been updated New geth and beacon genesis Some beacon chain and execution networking parameters have changed New geth/prysm bootstrap node addresses Blob-utils has been updated to support Devnet v2

We need to tweak the way optimistic sync works. Right now, a VALID block means all of its ancestors will also become VALID blocks. This breaks with EIP-4844 when blob sidecars are introduced as an optimistcally imported block lacking its sidecar will be incorrectly promoted to VALID. This makes It then becomes easy for an attacker to trick peers into treating actual invalid blocks with missing data as valid. To fix this all we have to do is change the block used as a basis for the block status transition. When a block transitions from NOT_VALIDATED to VALID, identify the latest ancestor whereby all of its own ancestors satisfy data availability: (using the same type definitions in the optimistic sync spec) def latest_valid_candidate_block(opt_store: OptimisticStore, block: BeaconBlock) -> BeaconBlock: # Assuming the input `block` is VALID chain = [] while True: