概要
在 2024 年 6 月，我们发布了 Alloy 0.1 作为 ethers-rs 的继任者，旨在为 Ethereum 开发提供一个强大、高性能的 Rust 工具包。自那时以来，Alloy 已经成长为[跨工具](https://sourcegraph.com/search?q=context:global+file:Cargo.toml+alloy+-repo: alloy-rs+-repo:foundry-rs+-repo:paradigmxyz&patternType=standard&sm=1&groupBy=repo)和基础设施领域的主干，Reth、Foundry、Revm和SP1 zkVM等项目都将其作为核心依赖。
今天，我们很高兴发布 Alloy v1.0，我们的第一个稳定版本，重申我们对性能、稳定性和出色开发者体验的承诺。Alloy 是 ethers-rs 的完全重写，并建立在多年为 Rust Ethereum 生态系统交付成功工具的经验之上。
请继续阅读，了解为什么业内最好的团队都在使用 Alloy。
https://x.com/gakonst/status/1905661358739521792
立即试用 Alloy v1.0
cargo add alloy查看我们完善的 文档 和 示例仓库 以获得灵感。
改进的文档
编写高性能和最先进的代码是不够的。文档应该同样出色。鉴于此，我们通过放弃 mdbook 转而使用 vocs， 对 alloy 文档 进行了全面改进。
alloy.rs
关于 Alloy 的所有资源：
请针对我们遗漏的任何内容提出 issue。
稳定性和可靠性
通过 v1.0，我们致力于提供稳定、可靠且可用于生产的 API，你可以长期项目中使用。
Alloy 是在 Ethereum 和其他 EVM 链上构建高性能应用程序的 Rust 工具包。对于即将到来的协议升级（如新的 EIP），我们将随着规范的发展继续发布更新。这些更新将遵循语义版本控制，并且可能包括必要的重大更改，以与核心协议更改保持一致。这确保了 Alloy 始终反映最新的网络行为，而不会落后。
为什么你应该使用 Alloy？直观的智能合约交互
借助 Alloy v1.0，与 Solidity 智能合约的交互比以往任何时候都更容易、更快、更安全。
这方面的核心是 sol! 宏，它是一个编译时 Solidity 解析器，可从 Solidity 代码或工件生成类型安全的 Rust 绑定。这实现了与强类型的无缝合约交互，并消除了手动 ABI 处理的需要。我们已经全面改进了 sol! 绑定，以提高 Rust 表示和易用性。此次改进包括针对高级别合约交互和低级别绑定使用的改进。
以前，开发人员经常需要使用 ._0 符号来访问函数调用的实际结果，这使得简单的合约交互不太直观。通过此更新，无需使用 ._0。请参阅下面改进的用户体验示例。
sol! 宏直接支持 Rust、Solidity 文件或 JSON ABI 工件中的 Solidity 语法。这使你可以通过一个宏调用将经过验证的合约接口引入到代码库中。
你可以使用原生 Rust 类型调用合约上的任何函数，Alloy 会在内部处理 ABI 编码和解码。
无论你是部署合约还是模拟低级 calldata，sol! 宏都能使智能合约交互快速而可靠。
极速的原始类型
Alloy 附带了一组原始类型，包括 U256、I256、Address 和 Bytes —— 它们比 ethers-rs 中的等效类型更快且更符合人体工程学。
这些类型是整个堆栈的基础：它们用于余额计算、calldata 编码、交易模拟等等。如果你正在构建机器人、索引器或任何计算密集型服务，切换到 Alloy 的原始类型可以立即提升性能。
更快的 U256 算术
Alloy 的 U256 构建在 ruint crate 之上，在常见的 DeFi 计算（如 AMM 数学和套利）中提供快 35-60% 的算术运算速度。我们对 UniswapV2 套利机器人中的两个核心方法 get_amount_in 和 get_amount_out 进行了基准测试，以比较 ethers-rs 和 Alloy 类型：
这些方法用于 MEV 机器人来计算套利交换的最佳输入量。如果你想了解有关使用 Alloy 的 Primitive 类型构建快速 MEV 机器人的更多信息，请阅读我们的指南。
快 10 倍的 ABI 编码
Alloy 生成直接编码 Solidity 调用的 Rust 类型。这消除了对运行时 JSON ABI 解析的需要，并避免了编码错误。Alloy 中的静态 ABI 编码速度提高了 10 倍，而动态 ABI 编码速度提高了约 10%。
对于仅在运行时可用的 ABI 信息（例如，钱包前端或 ABI 获取器），Alloy 通过 DynSolValue 提供动态 ABI 编码。你可以在中阅读有关动态 ABI 编码的更多信息。
这些基准测试使用 Criterion，并且可以在 Alloy 示例仓库 中找到。
简化 RPC Provider 的使用
Alloy 的 RPC provider 在 Ethereum RPC 端点上提供了一个干净、模块化的抽象，内置支持 HTTP、WebSocket 和 IPC，以及 provider 分层、传输包装和中间件组合等高级模式。我们的目标是消除样板代码，让开发人员只需几行代码即可连接到链。
其核心是 ProviderBuilder，它简化了连接设置并隐藏了底层传输的复杂性：
Alloy 通过将 provider 包装在你自己的类型中，可以轻松构建更高级别的抽象。这有助于隔离逻辑、减少重复并为特定任务（如部署、数据获取或交易模拟）创建直观的工作流程。
有两种主要方法可以包装 provider，具体取决于你是想保留类型信息还是优先考虑简单性。
使用泛型 (P: Provider)
当你想要静态分发、完全类型安全和最佳运行时性能时，请使用泛型。这非常适合库代码或你想要保留精确类型信息的场景。
这已通过从 provider 中删除 T: Transport 泛型来实现。这些更改也已传播到 sol! 宏绑定，从而更容易使用包装 provider 的类型。
现在，你可以包装 provider，而无需处理复杂的泛型类型：
这种方法允许你构建易于测试和优化的紧密耦合组件，同时保持接口对不同传输或层的通用性。
使用 DynProvider (类型消除)
当你想要简化类型并避免处理泛型时，请使用 DynProvider —— 这在应用程序、脚本或动态设置中特别有用。
DynProvider 消除了 provider 的具体类型，同时保留了全部功能，包括分层和中间件。这简化了签名并减小了二进制大小，但会产生较小的运行时开销。当你使用异构 provider 或想要在高级代码中获得更快的编译时间和更简洁的接口时，请使用此选项。你可以在文档中阅读有关包装 provider 的最佳实践的更多信息。
网络抽象
Alloy 的 provider 被设计为适用于多链世界，因为它对 Network trait 是通用的。Network trait 定义了网络及其 RPC 类型的结构，这些类型由 provider 使用。默认情况下，ProviderBuilder 为 Ethereum 网络创建一个 provider。可以使用 .network() 方法来更改它。例如，我们可以使用来自 op-alloy 的 Optimism 网络类型来实例化一个 provider，以便与 OP-stack 链（如 Base）进行交互。
这使 provider 能够反序列化 OP 特定类型，例如 Deposit 交易。
通过 Multicall 改善用户体验
Alloy 可以使用 Multicall 轻松地批量处理多个只读合约调用，Multicall 是一种智能合约和设计模式，用于将调用聚合到单个 RPC 请求中。Multicall 聚合合约的读取和写入。这对于减少你发出的 RPC 请求数量并通过保证多个状态读取/写入在同一区块中原子执行调用非常有用。Alloy 提供了一流的支持，以两种方式利用 Multicall3：
Multicall 构建器：手动构建批量调用Multicall 批量处理层——被动地对并行发出的调用进行分组Multicall 构建器
provider 上的 .multicall() 方法使你可以完全控制哪些调用可以批量处理在一起。它直接与 sol! 宏生成的合约绑定一起使用，以提供一个直观而简单的 API 来批量处理和执行调用，同时还处理响应的解码。一个简单的 multicall 如下所示：
