In this tutorial, we will walk through how to create your own precompile and add it to Geth.
In Geth, precompiles are a set of stateless contracts. But unlike Solidity code, their logic isn't in the smart contract code itself—they are part of the Geth client. You can think of a precompile as an interface that can execute Go code that resides within the Geth client.
The logic for precompiles in Geth is located in the core/vm/contracts.go file.
| // SPDX-License-Identifier: UNLICENSED | |
| pragma solidity >=0.8.18; | |
| import { Test } from "forge-std/Test.sol"; | |
| import { arange } from "solidity-generators/Generators.sol"; | |
| contract MyTest is Test { | |
| function testFuzz_OrderedArr(uint256[] memory arr) internal view { | |
| vm.assume(arr.length != 0); |
| // SPDX-License-Identifier: UNLICENSED | |
| pragma solidity ^0.8.15; | |
| import "forge-std/Script.sol"; | |
| // L1 | |
| import { L1CrossDomainMessenger } from "../L1/L1CrossDomainMessenger.sol"; | |
| import { L1ERC721Bridge } from "../L1/L1ERC721Bridge.sol"; | |
| import { L1StandardBridge } from "../L1/L1StandardBridge.sol"; | |
| import { L2OutputOracle } from "../L1/L2OutputOracle.sol"; |
| async function getMappingItem(slot, contractAddress, key) { | |
| const paddedSlot = utils.hexZeroPad(slot, 32); | |
| const paddedKey = utils.hexZeroPad(key, 32); | |
| const itemSlot = utils.keccak256(paddedKey + paddedSlot.slice(2)); | |
| return await getUint256(itemSlot, contractAddress); | |
| } |
| ########### | |
| # Imports # | |
| ########### | |
| # the RPCs file should include RPC URLs and Etherscan API Keys for relevant networks | |
| # (in a separate file so they don't get committed) | |
| source "$(dirname "$0")/rpcs.sh" | |
| # any useful addresses for various networks for easy reference | |
| source "$(dirname "$0")/addresses.sh" | |
| # any useful functions and definitions for interacting with Seaport |
Reducing gas costs for L2 users by optimising calldata.
Transaction fees on L2s like Optimism and Arbitrum involve paying the calldata gas costs for the batch submission on L1. And it accounts for good amount of gas fees.
For example, breakup of $4.19 Uniswap Trade on Arbitrum (explorer):
| module Subsets | |
| ( | |
| subsets | |
| ) where | |
| subsets :: [a] -> [[a]] | |
| subsets [] = [[]] | |
| subsets (x:xs) = subsets xs ++ map (x:) (subsets xs) |
| import math | |
| import ecdsa | |
| import ecdsa.ellipticcurve as EC | |
| # | |
| # Compute the inverse mod p using the extend | |
| # euclidian algorithm. | |
| # See O. Forster, Algorithmische Zahlentheorie | |
| # | |
| def inv_mod_p(x, p): |
Why should programmers care about Monoids? Because Monoids are a common pattern that shows up over and over in programming. And when patterns show up, we can abstract them and leverage work we've done in the past. This allows us to quickly develop solutions on top of proven, stable code.
Add Commutative Property to a Monoid (Commutative Monoid) and you have something that can be executed in parallel. With the end of Moore's Law, parallelism is our only hope to increasing processing speeds.
What follows is what I've learned after studying Monoids. It is hardly complete, but hopefully will prove to be helpful as an introduction for others.
