builders_pubkey_to_id = { '0x978a35c39c41aadbe35ea29712bccffb117cc6ebcad4d86ea463d712af1dc80131d0c650dc29ba29ef27c881f43bd587': 'rsync', '0x83d3495a2951065cf19c4d282afca0a635a39f6504bd76282ed0138fe28680ec60fa3fd149e6d27a94a7d90e7b1fb640': 'rsync', '0x945fc51bf63613257792926c9155d7ae32db73155dc13bdfe61cd476f1fd2297b66601e8721b723cef11e4e6682e9d87': 'rsync', '0x8e6df6e0a9ca3fd89db2aa2f3daf77722dc4fbcd15e285ed7d9560fdf07b7d69ba504add4cc12ac999b8094ff30ed06c': 'rsync', '0x8dde59a0d40b9a77b901fc40bee1116acf643b2b60656ace951a5073fe317f57a086acf1eac7502ea32edcca1a900521': 'beaverbuild', '0xb5d883565500910f3f10f0a2e3a 031139d972117a3b67da191ff93ba00ba26502d9b65385b5bca5e7c587273e40f2319': 'beaverbuild', '0x96a59d355b1f65e270b29981dd113625732539e955a1beeecbc471dd0196c4804574ff871d47ed34ff6d921061e9fc27': 'beaverbuild', '0xaec4ec48c2ec03c418c599622980184e926f0de3c9ceab15fc059d617fa0eafe7a0c62126a4657faf596a1b211eec347': 'beaverbuild', '0xb5d883565500910f3f10f0a2e3a031139d972117a3b67da191ff93ba00ba26502d9b65385b5bca5e7c587273e40f2319': 'beaverbuild',

This set of notes on stuff I've learned while using for around a week while building a simplistic tx simulator. It is by no means complete and may contain errors. What it does and why it's useful The most well known, and simplest way to simulate the result of a message call is to use the standard eth_call RPC method. If all you care about is the return value of a tx or what a specific set of storage slot values might be at the end of execution, it's great! If you're building an application that needs finer-grain details around the internals of the tx (e.g. an indexer/explorer), eth_call isn't going to cut it. This is where debug_traceCall comes in. Yes it comes with your favorite eth_call features like the ability to choose which parent block to execute and state overrides. It also has its own features including the ability to toggle returning the current frame's stack, memory, storage, and returndata for every opcode during execution. Some applications might find that granularity overwhelming (e.g. an indexer that only cares about internal calls or logs that could be emitted with a specific call). Luckily, the RPC method also supports passing a custom tracer. A custom tracer

Gas on Optimism This document seeks to provide an technical overview of the components that impact transaction prices on Optimism as of February 22, 2022. Authored by Rajiv Patel-O'Connor and special thanks to Mark Tyneway for the review OVM_GasPriceOracle.sol OVM_GasPriceOracle is a predeploy (a pre-compile written in Solidity as opposed to native langauge) that exposes the L2 execution gas price as well as the associated L1 data fee. The reason there is an L1 data fee is because each transaction on Optimism is posted to mainnet for data availability purposes which naturally incurs a cost as calldata is not free. As such, the total cost of a transaction can be given as the sum of the L2 execution fee and associated L1 data fee. The L2 execution fee is gasPrice * l2_tx_gas_used and the gasPrice can be updated by the owner of the GasPriceOracle.