paradigmxyz / alphanet Goto Github PK
View Code? Open in Web Editor NEWReth AlphaNet is a testnet OP Stack-compatible rollup aimed at enabling experimentation of bleeding edge Ethereum Research.
License: Apache License 2.0
Reth AlphaNet is a testnet OP Stack-compatible rollup aimed at enabling experimentation of bleeding edge Ethereum Research.
License: Apache License 2.0
From EIP 3074:
authority
is the address of the account which generated the signature. IfEXTCODESIZE
ofauthority
is not zero, consider the operation unsuccessful and unsetauthorized
.
What I understand from this:
authorized
, push 0, stop executing the logic of AUTH
and continue the execution of the current frame.Which means that here we should add something like (pseudocode)
if acc.code.len() != 0 {
push_stack(0);
ctx.remove(AUTHORIZED_VAR_NAME);
return;
}
alphanet/crates/instructions/src/eip3074.rs
Lines 170 to 176 in 008524c
I'd be glad to PR this if approved :)
EIP-3074 is another account abstraction-related EIP that would be interesting to have on AlphaNet.
This involves adding two new instructions, in the existing custom evm config.
This will require at least adding an entry to an instruction table, and using that instruction table in a custom revm Handler
:
https://github.com/bluealloy/revm/blob/0d42796362c9f90d44f902e99417f570c16b4901/crates/interpreter/src/instructions/opcode.rs#L31
The spec:
https://eips.ethereum.org/EIPS/eip-3074
There are already solc and foundry implementations, although not using the evm builder:
https://github.com/clabby/eip-3074-foundry
also:
https://github.com/anna-carroll/3074
Now that we have an implementation of EIP-2537 in revm, we should import that code now instead. There were also many bug fixes for EIP-2537 included in revm which should apply here as well.
AUTHCALL
Sending non-zero value with CALL increases its cost by 9,000. Of that, 6,700 covers the increased overhead of the balance transfer and 2,300 is used as a stipend into the subcall to seed its gas counter. AUTHCALL does not provide a stipend and thus only charges the base 6,700.
AUTHCALL
opcode to take 7 values from the stack, not 8. Following this update, AUTHCALL behaves like CALL, a few exceptions aside.What needs to be changed :
value
is deducted from the balance of authorized
We'll want to implement, test, and integrate EIP-7212 (secp256r1 precompile) in the alphanet EVM config.
This will require porting this over:
https://github.com/alessandromazza98/revm/tree/eip-7212
We should also have some basic unit tests for the precompile
There's a recent PR in revm for EIP-5806: bluealloy/revm#1184
The EIP spec:
https://eips.ethereum.org/EIPS/eip-5806
EIP-5806 essentially allows EOAs to execute arbitrary code, one of the benefits is allowing for easier tx batching if used with a multicall contract.
This introduces a new transaction type, which would be difficult for us to fully support with the current reth API, so this one seems lower priority.
to, data
is not checked against the signed commit
, so if a user signs any commit
, a caller can pass in / execute arbitrary calls
Note: i'm assuming this wasn't built to be deployed, just heads up
blst
is likely faster than the bls12_381
crate, and has been audited, so we should migrate to using that for the bsl precompile.
We should add EIP-2537, spec here:
https://eips.ethereum.org/EIPS/eip-2537
The precompile has ABIs for the following operations:
There are also some test vectors, although this will need to be tested more than with just these:
https://eips.ethereum.org/assets/eip-2537/bench_vectors
We use blst
in c-kzg-4844
, and it has rust bindings, so that could be used here as well:
https://github.com/supranational/blst
EIP-3074 should be extracted to a separate repo so it can be decoupled from this codebase and potentially more easily removed once alphanet can support 7702 more easily.
Right now the alphanet
binary just runs the node, with no help options, options for overriding the discovery port, etc:
dan@Dans-MacBook-Pro-4 ~/p/alphanet (main) [101]> ./target/debug/alphanet --help
2024-03-21T19:55:55.396789Z INFO Configuration loaded path="/var/folders/65/m26_cf0d1lbdnp4dvzztr0th0000gn/T/reth-test-MouAvtXj/reth.toml"
2024-03-21T19:55:55.397075Z INFO Database opened
2024-03-21T19:55:55.413599Z INFO Pre-merge hard forks (block based):
- Frontier @0
- Homestead @0
- Tangerine @0
- SpuriousDragon @0
- Byzantium @0
- Constantinople @0
- Petersburg @0
- Istanbul @0
- Berlin @0
- London @0
Merge hard forks:
- Paris @0 (network is not known to be merged)
Post-merge hard forks (timestamp based):
- Shanghai @0
- Cancun @0
2024-03-21T19:55:55.470785Z INFO Transaction pool initialized
2024-03-21T19:55:55.470874Z INFO Connecting to P2P network
2024-03-21T19:55:55.474633Z INFO StaticFileProducer initialized
2024-03-21T19:55:55.475025Z INFO Pruner initialized prune_config=PruneConfig { block_interval: 5, segments: PruneModes { sender_recovery: None, transaction_lookup: None, receipts: None, account_history: None, storage_history: None, receipts_log_filter: ReceiptsLogPruneConfig({}) } }
2024-03-21T19:55:55.475238Z INFO Consensus engine initialized
2024-03-21T19:55:55.475336Z INFO Engine API handler initialized
We should add most of the reth CLI commands, as well as the help menu.
We should do something similar to how op-reth is built and launched:
https://github.com/paradigmxyz/reth/blob/6eb7397aa2c49c90922691cb0e176d973bbb441a/bin/reth/src/optimism.rs#L26
The multiexp precompiles were recently renamed to multi-scalar multiplication precompiles, for consistency w.r.t naming and additive notation.
Spec PR: ethereum/EIPs#8393
Trying to run 3074-invokers's sendEth
forge script example with this Docker build of foundry but I'm running into a Transaction failure
error.
It shows a successful test simulation before broadcasting, but when it broadcasts to AlphaNet, the transaction fails. My thought is that there is a discrepancy between the way 3074 is implemented in the simulation build which is passing and AlphaNet which is failing. This error did not occur until after 3074-invokers
's repo got updated to use foundry-alphanet
for foundry things. Weirdly enough though, when running the sendEth
forge script with the current version of foundry-alphanet
on the Otim Devnet, it works...
Here is the output for reference:
julrach@julrach-s-mac 3074-invokers % make cmd="forge script Executor --sig sendEth(address,address,uint256) $INVOKER_ADDRESS 0x3074ca113074ca113074ca113074ca113074ca11 0.01ether --rpc-url $RPC_URL --broadcast -vvvv"
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
Compiling 26 files with 0.8.24
Solc 0.8.24 finished in 1.77s
Compiler run successful with warnings:
Warning (3805): This is a pre-release compiler version, please do not use it in production.
Warning (2018): Function state mutability can be restricted to pure
--> src/Auth.sol:43:5:
|
43 | function auth(bytes32 commit, Signature memory signature) public returns (bool success) {
| ^ (Relevant source part starts here and spans across multiple lines).
Warning (2018): Function state mutability can be restricted to pure
--> src/Auth.sol:56:5:
|
56 | function authcall(address to, bytes memory data, uint256 value, uint256 gasLimit) public returns (bool success) {
| ^ (Relevant source part starts here and spans across multiple lines).
Traces:
[54098] Executor::sendEth(0x5FbDB2315678afecb367f032d93F642f64180aa3, 0x3074Ca113074ca113074CA113074CA113074CA11, 10000000000000000 [1e16])
├─ [0] VM::addr(<pk>) [staticcall]
│ └─ ← [Return] 0x29b7D9C8f9c4e158AeDC2bfC31D1931A519682Ed
├─ [2512] 0x5FbDB2315678afecb367f032d93F642f64180aa3::nextNonce(0x29b7D9C8f9c4e158AeDC2bfC31D1931A519682Ed) [staticcall]
│ └─ ← [Return] 0
├─ [0] VM::addr(<pk>) [staticcall]
│ └─ ← [Return] 0x29b7D9C8f9c4e158AeDC2bfC31D1931A519682Ed
├─ [0] VM::getNonce(0x29b7D9C8f9c4e158AeDC2bfC31D1931A519682Ed) [staticcall]
│ └─ ← [Return] 0
├─ [1177] 0x5FbDB2315678afecb367f032d93F642f64180aa3::getDigest(0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000055023074ca113074ca113074ca113074ca113074ca11000000000000000000000000000000000000000000000000002386f26fc1000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, 0) [staticcall]
│ └─ ← [Return] 0xa5dde2dde74c211c6e9f4858203ea6c212807ecc05bfe495df0c20dd8bd64e22
├─ [0] VM::sign("<pk>", 0xa5dde2dde74c211c6e9f4858203ea6c212807ecc05bfe495df0c20dd8bd64e22) [staticcall]
│ └─ ← [Return] 28, 0xa7d19736b0c8d7c143bc5ebb9f676c5207043ea918f78fcc339e5496ed3c285a, 0x0f86e650a01a9a6555917fc44ec3a87a3f53dc471fb63ec6dc94efc1d6b3b78e
├─ [0] VM::startBroadcast(<pk>)
│ └─ ← [Return]
├─ [0] VM::addr(<pk>) [staticcall]
│ └─ ← [Return] 0x29b7D9C8f9c4e158AeDC2bfC31D1931A519682Ed
├─ [30539] 0x5FbDB2315678afecb367f032d93F642f64180aa3::execute(0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000055023074ca113074ca113074ca113074ca113074ca11000000000000000000000000000000000000000000000000002386f26fc1000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Signature({ signer: 0x29b7D9C8f9c4e158AeDC2bfC31D1931A519682Ed, yParity: 1, r: 0xa7d19736b0c8d7c143bc5ebb9f676c5207043ea918f78fcc339e5496ed3c285a, s: 0x0f86e650a01a9a6555917fc44ec3a87a3f53dc471fb63ec6dc94efc1d6b3b78e }))
│ ├─ [0] 0x3074Ca113074ca113074CA113074CA113074CA11::fallback{value: 10000000000000000}()
│ │ └─ ← [Stop]
│ └─ ← [Stop]
├─ [0] VM::stopBroadcast()
│ └─ ← [Return]
└─ ← [Stop]
Script ran successfully.
## Setting up 1 EVM.
==========================
Simulated On-chain Traces:
[35039] 0x5FbDB2315678afecb367f032d93F642f64180aa3::execute(0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000055023074ca113074ca113074ca113074ca113074ca11000000000000000000000000000000000000000000000000002386f26fc1000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Signature({ signer: 0x29b7D9C8f9c4e158AeDC2bfC31D1931A519682Ed, yParity: 1, r: 0xa7d19736b0c8d7c143bc5ebb9f676c5207043ea918f78fcc339e5496ed3c285a, s: 0x0f86e650a01a9a6555917fc44ec3a87a3f53dc471fb63ec6dc94efc1d6b3b78e }))
├─ [0] 0x3074Ca113074ca113074CA113074CA113074CA11::fallback{value: 10000000000000000}()
│ └─ ← [Stop]
└─ ← [Stop]
==========================
Chain 41144114
Estimated gas price: 0.081543882 gwei
Estimated total gas used for script: 86314
Estimated amount required: 0.000007038378630948 ETH
==========================
##
Sending transactions [0 - 0].
##
Waiting for receipts.
Transactions saved to: /app/foundry/broadcast/Execute.s.sol/41144114/sendEth-latest.json
Sensitive values saved to: /app/foundry/cache/Execute.s.sol/41144114/sendEth-latest.json
Error:
Transaction Failure: 0x9d7edbd23db203be0a7dda87f7785f7848da051eaf4fe4a52517ac6374c1a3d9
make: *** [foundry] Error 1
I've been researching Reth AlphaNet a bit. Thanks for the effort so far!
alphanet
command somehow planned to also spawn one? In this documentation paragraph it's marked with TODO
:
alphanet node
--chain etc/alphanet-genesis.json \
--rollup.sequencer-http <TODO> \
...
Sorry if this is not the right place to ask, I thought I'd get the quickest answer here.
This issue tracks the existing EIPs we want to include in alphanet. This will grow over time
These can be implemented solely in the EVM trait implementation, following this example:
https://github.com/paradigmxyz/reth/blob/main/examples/custom-evm/src/main.rs
Spec: https://eips.ethereum.org/EIPS/eip-7212
Example implementation:
https://github.com/alessandromazza98/revm/tree/eip-7212
This is a single precompile, so it will be used in the EVM config implementation
Spec: https://eips.ethereum.org/EIPS/eip-3074
Implementation as foundry project with revm patches: https://github.com/anna-carroll/3074
This consists of two instructions, AUTH
and AUTHCALL
, also to be set in the EVM config implementation
This involves an alt mempool, requires extra infrastructure, and new RPC endpoints.
Alchemy has a reth-based bundler here: https://github.com/alchemyplatform/rundler
We will want to add support for new instructions, for example AUTH
and AUTHCALL
from 3074: #5. To properly integration test these, we'll need some human readable example code that can be:
This is a chicken-and-egg problem: any new upgrade needs support in both the interpreter and the compiler to be properly integration tested.
One idea is extending eas
(ethereum assembler) from etk
:
https://github.com/quilt/etk
This is probably the quickest way to generating bytecode that can be deployed.
We could also look at past modifications to solc, and the 3074 fork of solc if we really want to fork solc:
EIP-3074: ethereum/solidity@develop...GregTheGreek:solidity:3074
EIP-7516 (BLOBBASEFEE
): https://github.com/ethereum/solidity/pull/14755/files
The ideal compiler would allow us to:
BLOBBASEFEE
AUTH
/ AUTHCALL
extensionwithout forking the compiler.
We'll need some test utils for generating bytecode, to make the unit tests relatively human-readable and concise.
RIP-7560 is described as a combination of EIP-2938 and ERC-4337, meant to be backwards compatible with ERC-4337.
The spec: ethereum/RIPs#3
This overview is split up into sections outlining either:
The proposal is complex and would require many changes, some of which are currently not possible with the reth node builder.
A new EIP-2718 transaction type is introduced. This would be difficult to support with the current node builder API.
The new transaction type is encoded like this:
0x04 || 0x00 || rlp([
chainId, sender, nonce, builderFee,
callData, paymasterData, deployerData,
maxPriorityFeePerGas, maxFeePerGas,
validationGasLimit, paymasterGasLimit, callGasLimit,
accessList, signature
])
This also adds a "transaction counter header" which adds more encoding / decoding complexity. Discussion here on whether or not this should be included in the block:
ethereum/RIPs#3 (comment)
Transaction nonces for AA_TYPE
transactions are now not necessarily sequential, see the "Non-sequential nonce support" section.
Nonce management and validation are proposed as a pre-deployed contract. There is no bytecode yet.
AA transactions are validated and executed in a specific order, similar to ERC-4337:
nonce
validation and increment frame (required, uses predeployed contract)sender
deployment frame (once per account)sender
validation frame (required)paymaster
validation frame (optional)sender
execution frame (required)paymaster
post-transaction frame (optional)These steps could be implemented with the validation and execution handlers in the EVM builder.
Mempool DoS prevention rules are shared between ERC-4337 and RIP-7560, located here:
https://eips.ethereum.org/EIPS/eip-7562
EIP-7562 would need its own issue and scope
This is included as a reference:
Opcode Name | Solidity Equivalent | Value |
---|---|---|
CALLER |
msg.sender |
The AA_ENTRY_POINT address. AA_SENDER_CREATOR for the "deployment frame". |
ORIGIN |
tx.origin |
The transaction sender address |
CALLDATA* |
msg.data |
The transaction data is set to inputs of the corresponding frame |
There is a penalty for unused gas, discussion on why this is included here:
ethereum/RIPs#3 (comment)
The new transaction type is suggested to be propagated in a 4337 style alt mempool:
Such transactions MUST NOT be propagated through the default transaction mempool as they will be rejected by the nodes and the sending node will be blocked as a spammer. They may be propagated in the alternative mempool that allows them explicitly as defined in ERC-7562.
Block validation is extended with calls to the AA predeployed contract. This logic would be possible to implement if the reth processor / executor were configurable.
This requires changes to:
eth_call
eth_getTransactionReceipt
eth_sendTransaction
eth_sendRawTransaction
This is very complex and requires more time to understand fully - this issue is here for now, and the fact that this RIP is so complex motivates some things to add to the node builder. It's also possible that the spec could be made simpler, and some of the quirks could be removed with more thought.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.