Eip7702 update #40
Eip7702 update #40
Conversation
WalkthroughThis update introduces support for EIP-3074 style authorization lists in transaction data and queries. New data structures for authorizations and their selection criteria are added in both Python and Rust code. The transaction query and data models are extended to include and filter by authorization lists. A new example script demonstrates usage of these features. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant ExampleScript
participant HypersyncClient
participant Server
User->>ExampleScript: Run eip7702.py
ExampleScript->>HypersyncClient: Initialize client
ExampleScript->>HypersyncClient: Query transactions with authorization filter
HypersyncClient->>Server: Send query with authorization selection
Server-->>HypersyncClient: Return transactions with authorization_list
HypersyncClient-->>ExampleScript: Provide results
ExampleScript->>User: Print transaction hashes and authorization data
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (6)
🚧 Files skipped from review as they are similar to previous changes (6)
✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (4)
examples/eip7702.py (3)
5-5: Remove unused imports.Static analysis correctly identified unused imports that should be removed to clean up the code.
-from hypersync import BlockField, JoinMode, TransactionField, LogField, ClientConfig +from hypersync import TransactionField, ClientConfig🧰 Tools
🪛 Ruff (0.11.9)
5-5:
hypersync.BlockFieldimported but unusedRemove unused import
(F401)
5-5:
hypersync.JoinModeimported but unusedRemove unused import
(F401)
5-5:
hypersync.LogFieldimported but unusedRemove unused import
(F401)
16-16: Consider implementing the chain_id example.The TODO comment suggests this feature is incomplete. Consider either implementing the chain_id filtering example or removing the TODO if it's not feasible yet.
Would you like me to help implement a chain_id filtering example or should this TODO be converted to a future enhancement issue?
44-44: Consider explaining the logs output.Since this example focuses on authorization lists in transactions, the logs count output at the end might be confusing. Consider adding a comment explaining why logs are included or remove this line if it's not relevant.
- print(len(res.data.logs)) + print("Number of logs returned:", len(res.data.logs))hypersync/__init__.py (1)
392-394: Clarify the EIP reference in the comment.The comment mentions "EIP-3074 transactions" but the PR title refers to "EIP-7702 update". Please clarify which EIP this implementation follows.
- # The authorization list specifies a list of addresses and their associated authorization data - # for EIP-3074 transactions. + # The authorization list specifies a list of addresses and their associated authorization data + # for EIP-7702 transactions.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (6)
Cargo.toml(2 hunks)examples/block-data.py(1 hunks)examples/eip7702.py(1 hunks)hypersync/__init__.py(5 hunks)src/query.rs(2 hunks)src/types.rs(3 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (2)
src/query.rs (1)
hypersync/__init__.py (1)
AuthorizationSelection(545-550)
src/types.rs (1)
hypersync/__init__.py (1)
Authorization(34-50)
🪛 Ruff (0.11.9)
examples/eip7702.py
5-5: hypersync.BlockField imported but unused
Remove unused import
(F401)
5-5: hypersync.JoinMode imported but unused
Remove unused import
(F401)
5-5: hypersync.LogField imported but unused
Remove unused import
(F401)
🔇 Additional comments (15)
Cargo.toml (2)
3-3: Verify the major version bump is appropriate.The package version increased from 0.8.5 to 0.9.0, indicating new features. Ensure this aligns with the EIP-7702 authorization list functionality being added.
20-23:❓ Verification inconclusive
Verify compatibility with major dependency updates.
Multiple dependencies have significant version updates:
- alloy libraries jumped from 0.8 to 1.1 (major versions)
- hypersync-client updated from 0.17 to 0.18.2
These major version updates may introduce breaking changes that could affect the codebase.
🏁 Script executed:
#!/bin/bash # Description: Check for compilation errors and breaking changes with new dependencies # Expected: Clean compilation without errors # Check if the project compiles with new dependencies cargo check --all-features 2>&1 | head -20 # Look for any deprecation warnings or breaking changes cargo build 2>&1 | grep -i "warning\|error\|deprecated" | head -10Length of output: 199
Action Required: Manually verify compatibility of major version bumps
The following dependencies were bumped to new major releases in
Cargo.toml(lines 20–23):
alloy-json-abifrom 0.8 → 1.1alloy-dyn-abifrom 0.8 → 1.1alloy-primitivesfrom 0.8 → 1.1hypersync-clientfrom 0.17 → 0.18.2These upgrades may introduce breaking changes. Please:
- Run
cargo check --all-featuresandcargo buildlocally to ensure clean compilation.- Execute the full test suite (
cargo test) and any integration or benchmark tests.- Review each crate’s changelog or release notes for breaking changes or altered APIs.
Confirm that all code paths depending on these crates still compile, behave as expected, and pass tests before merging.
examples/block-data.py (1)
54-55: Good formatting improvement.Adding a newline at the end of the file follows standard conventions and improves code formatting.
src/query.rs (2)
46-54: Well-implemented authorization selection structure.The
AuthorizationSelectionstruct is properly implemented with:
- Appropriate serialization attributes (
skip_serializing_if)- Clear documentation for each field
- Consistent with existing code patterns in the file
- Matches the Python equivalent structure
The field types (
i64for chain_id,Vec<String>for address) are appropriate for the use case.
74-76: Proper integration of authorization list filtering.The addition of the
authorization_listfield toTransactionSelectionis well-implemented:
- Uses the same optional pattern as other selection fields
- Includes clear documentation explaining the OR logic for matching
- Properly configured for conditional serialization
This enables filtering transactions based on authorization criteria as intended.
examples/eip7702.py (3)
1-2: Helpful note about data availability.The note about data availability across different hypersync sources is valuable for users and sets appropriate expectations.
11-24: Excellent demonstration of authorization list functionality.The query construction properly demonstrates:
- Using
AuthorizationSelectionwith address filtering- Selecting the new
AUTHORIZATION_LISTfield- Targeting a specific block range for testing
The example effectively showcases the new EIP-7702 authorization features.
33-42: Comprehensive authorization data display.The output loop effectively demonstrates all available authorization fields:
- chain_id, address, nonce
- Cryptographic signature components (y_parity, r, s)
This provides users with a complete view of the authorization data structure.
src/types.rs (3)
68-68: LGTM! Authorization list field properly integrated.The new
authorization_listfield is correctly added to theTransactionstruct with appropriate optional typing.
383-386: LGTM! Authorization list conversion properly implemented.The mapping of the authorization list in the Transaction conversion is correctly implemented, using the new Authorization conversion.
133-146:❓ Verification inconclusive
Review type consistency with Python interface.
The
Authorizationstruct is well-defined, but there's a type inconsistency with the Python interface. Thechain_idfield usesBigUinthere but is typed asintin the Python interface.# From hypersync/__init__.py class Authorization(object): # uint256 chain_id: Optional[int] # <-- int typeThis could cause issues if Python consumers expect regular integers but receive large BigUint values.
Consider using
i64forchain_idto match the Python interface, or update the Python typing to handle large integers appropriately.
🏁 Script executed:
#!/bin/bash set -e echo "=== Rust BigUint usage in src/types.rs ===" rg "BigUint" -n src/types.rs || true echo -e "\n=== num_bigint import in src/types.rs ===" rg "num_bigint" -n src/types.rs || true echo -e "\n=== Python Authorization class definition ===" rg -n "class Authorization" -A3 -n . echo -e "\n=== Python chain_id annotation ===" rg -n "chain_id" -n .Length of output: 2914
🏁 Script executed:
#!/bin/bash set -e echo "=== Search for BigUint conversion to Python ===" rg "BigUint" -n src echo -e "\n=== Search for IntoPyObject or ToPyObject impls ===" rg -n "impl.*BigUint" -n src || true rg -n "impl.*IntoPyObject" -n src || true rg -n "impl.*ToPyObject" -n src || true echo -e "\n=== Search for pyo3 conversion traits for BigUint ===" rg -n "FromPyObject" -n src || true rg -n "ToPyObject" -n src || true rg -n "PyLong" -n src || trueLength of output: 1674
Confirm BigUint ↔ Python int conversions & update stubs if needed
- In Rust (
src/types.rs:140), you’ve switchedchain_idon the#[pyclass] AuthorizationtoOption<BigUint>.- In the Python stub (
hypersync/__init__.pyat lines 40 and 71),chain_id: Optional[int]is still correct since Python’sintis unlimited precision.- Action items:
- Verify that you have
IntoPyObject(and, for inputs,FromPyObject) implementations forBigUint(andOption<BigUint>). Pyo3 will need these to convert between Rust’sBigUintand Python’sPyLong.- If no conversion exists, add something like:
use pyo3::prelude::*; use pyo3::types::PyLong; use num_bigint::BigUint; impl IntoPy<PyObject> for BigUint { fn into_py(self, py: Python<'_>) -> PyObject { PyLong::new(py, &self.to_string()).into() } } // And similarly for FromPyObject<Option<BigUint>> if you need Python → Rust.- Optionally update the Python stub’s docstring to note that
chain_idmay exceed 64-bit values but is still returned as a Pythonint.- There’s no need to revert the Rust type back to
i64unless you can guarantee all chain IDs will always fit within 2⁶³–1.hypersync/__init__.py (4)
34-51: Well-structured Authorization class with clear documentation.The
Authorizationclass is properly defined with appropriate type hints and comprehensive documentation referencing the Ethereum RPC spec. The field types align with the documented bit sizes.
73-73: LGTM! Authorization list field properly added to Transaction.The
authorization_listfield is correctly integrated into theTransactionclass with proper typing.
544-551: Well-designed AuthorizationSelection for filtering.The
AuthorizationSelectiondataclass provides appropriate filtering capabilities for authorization lists with clear documentation and proper field types.
574-575: LGTM! Authorization filtering properly integrated.The
authorization_listfield inTransactionSelectioncorrectly enables filtering transactions by authorization criteria.
| impl From<&format::Authorization> for Authorization { | ||
| fn from(a: &format::Authorization) -> Self { | ||
| Self { | ||
| chain_id: Some(convert_bigint_unsigned( | ||
| ruint::aliases::U256::try_from_be_slice(&a.chain_id) | ||
| .expect("convert chain_id bytes to U256"), | ||
| )), | ||
| address: Some(a.address.encode_hex()), | ||
| nonce: Some( | ||
| alloy_primitives::I64::try_from_be_slice(&a.nonce) | ||
| .expect("convert nonce bytes to I64") | ||
| .as_i64(), | ||
| ), | ||
| y_parity: Some( | ||
| alloy_primitives::I64::try_from_be_slice(&a.y_parity) | ||
| .expect("convert y_parity bytes to I64") | ||
| .as_i64(), | ||
| ), | ||
| r: Some(a.r.encode_hex()), | ||
| s: Some(a.s.encode_hex()), | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
Address error handling in conversion implementation.
The conversion implementation has several potential panic points with .expect() calls that could cause runtime failures if the byte slice conversions fail.
Consider improving error handling:
impl From<&format::Authorization> for Authorization {
fn from(a: &format::Authorization) -> Self {
Self {
- chain_id: Some(convert_bigint_unsigned(
- ruint::aliases::U256::try_from_be_slice(&a.chain_id)
- .expect("convert chain_id bytes to U256"),
- )),
+ chain_id: ruint::aliases::U256::try_from_be_slice(&a.chain_id)
+ .ok()
+ .map(convert_bigint_unsigned),
address: Some(a.address.encode_hex()),
- nonce: Some(
- alloy_primitives::I64::try_from_be_slice(&a.nonce)
- .expect("convert nonce bytes to I64")
- .as_i64(),
- ),
+ nonce: alloy_primitives::I64::try_from_be_slice(&a.nonce)
+ .ok()
+ .map(|v| v.as_i64()),
- y_parity: Some(
- alloy_primitives::I64::try_from_be_slice(&a.y_parity)
- .expect("convert y_parity bytes to I64")
- .as_i64(),
- ),
+ y_parity: alloy_primitives::I64::try_from_be_slice(&a.y_parity)
+ .ok()
+ .map(|v| v.as_i64()),
r: Some(a.r.encode_hex()),
s: Some(a.s.encode_hex()),
}
}
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| impl From<&format::Authorization> for Authorization { | |
| fn from(a: &format::Authorization) -> Self { | |
| Self { | |
| chain_id: Some(convert_bigint_unsigned( | |
| ruint::aliases::U256::try_from_be_slice(&a.chain_id) | |
| .expect("convert chain_id bytes to U256"), | |
| )), | |
| address: Some(a.address.encode_hex()), | |
| nonce: Some( | |
| alloy_primitives::I64::try_from_be_slice(&a.nonce) | |
| .expect("convert nonce bytes to I64") | |
| .as_i64(), | |
| ), | |
| y_parity: Some( | |
| alloy_primitives::I64::try_from_be_slice(&a.y_parity) | |
| .expect("convert y_parity bytes to I64") | |
| .as_i64(), | |
| ), | |
| r: Some(a.r.encode_hex()), | |
| s: Some(a.s.encode_hex()), | |
| } | |
| } | |
| } | |
| impl From<&format::Authorization> for Authorization { | |
| fn from(a: &format::Authorization) -> Self { | |
| Self { | |
| chain_id: ruint::aliases::U256::try_from_be_slice(&a.chain_id) | |
| .ok() | |
| .map(convert_bigint_unsigned), | |
| address: Some(a.address.encode_hex()), | |
| nonce: alloy_primitives::I64::try_from_be_slice(&a.nonce) | |
| .ok() | |
| .map(|v| v.as_i64()), | |
| y_parity: alloy_primitives::I64::try_from_be_slice(&a.y_parity) | |
| .ok() | |
| .map(|v| v.as_i64()), | |
| r: Some(a.r.encode_hex()), | |
| s: Some(a.s.encode_hex()), | |
| } | |
| } | |
| } |
🤖 Prompt for AI Agents
In src/types.rs between lines 148 and 170, the From implementation for
Authorization uses multiple .expect() calls that can cause panics if byte slice
conversions fail. Refactor this code to handle errors gracefully by replacing
.expect() with proper error handling, such as returning a Result type or using a
custom error type. Modify the function signature to return Result<Self, Error>
and propagate errors from the conversion attempts instead of panicking.
A lot more fiddling than I anticipated, but overall straightforward once I worked out what is going on...
Summary by CodeRabbit
New Features
Chores
Style