• 首页
  • 开发者的Python深度探索

开发者的Python深度探索

你已经掌握了区块链的阅读。你可以连接到一个节点，使用其 ABI 实例化一个合约，并随心所欲地调用公共函数。你可以获取余额、读取合约状态以及查询过去的事件。但这是一种单向的对话。你是一个被动的观察者。

当你决定采取行动——发送代币、铸造 NFT 或执行交换——你就跨越了一个门槛。你不再只是阅读；你正在尝试改变一个全球计算机的状态。这时复杂性就显现出来了。突然间，你需要处理私钥、随机数、燃料估算和十六进制数据负载。简单的 call() 被构建、签名和广播原始交易的多步骤过程所取代。

本文是跨越这一鸿沟的桥梁。我们将拆解发送写入交易的过程，从理论组件转向一个强大、适合生产的 Python 框架。我们不仅会告诉你该怎么做；还会探讨每个参数和架构选择背后的原因，使你能够构建可靠且复杂的 EVM 原生应用程序。

如何在代码中体现一个钱包？

在您可以进行链上操作之前，您需要一个身份。在EVM世界中，您的身份由一对公钥/私钥定义。您的代码需要一种方式来拥有这个身份，以便对任何状态改变操作进行加密签名——从而授权。这就是web3.py提供强大抽象的地方。

您的起点是您的私钥。通过它，您可以创建一个内存中的账户对象，作为您的链上参与者。

from web3 import Web3
from eth_account.signers.local import LocalAccount
import config # 假设您的密钥在配置文件中

# 连接到EVM网络
w3 = Web3(Web3.HTTPProvider('YOUR_RPC_URL'))

# 从私钥创建账户对象
private_key: str = config.PRIVATE_KEY
account: LocalAccount = w3.eth.account.from_key(private_key)

print(f"作为钱包操作: {account.address}")

由 w3.eth.account.from_key() 返回的对象不仅仅是您地址的容器。它是一个 LocalAccount 实例，这是一个关键细节。该对象持有签名能力。通过明确类型提示 account: LocalAccount，您可以在您的 IDE 中解锁完整的自动补全和静态分析。这不仅仅是一个风格选择；它是导航库的方法和属性（如 account.address 和 account.key）的实际必要性。高级开发者的直觉是理解他们的工具。我们如何知道返回类型是 LocalAccount？通过检查库本身。导航到 from_key 方法的源代码可以揭示其返回类型注释。这种“源代码潜水”的做法是揭开库行为神秘面纱和发现其全部潜力的宝贵技能。

为什么简单的脚本会演变成复杂的类？

使用账户对象，您可以开始构建交易。但是对于任何比一次性脚本更复杂的应用程序，这种方法很快就变得难以管理。如果您需要与多个网络交互或管理多个钱包，您会发现自己在重复连接逻辑、账户创建和发送交易的代码。

一个稳健的解决方案是将这些逻辑封装在一个类中。让我们设计一个 Client 类，它代表一个网络上一个钱包的单一、有状态的连接。

from web3 import Web3
from web3.eth import AsyncEth
from eth_account.signers.local import LocalAccount
from web3.providers.async_http import AsyncHTTPProvider

class Client:
    private_key: str
    rpc: str
    w3: Web3
    account: LocalAccount

    def __init__(self, private_key: str, rpc: str):
        self.private_key = private_key
        self.rpc = rpc
        self.w3 = Web3(
            AsyncHTTPProvider(self.rpc),
            modules={'eth': (AsyncEth,)},
            middlewares=[]
        )
        self.account = self.w3.eth.account.from_key(self.private_key)

    # 我们稍后将在这里添加交易方法

 

这种面向对象的结构提供了直接的好处：

  1. 封装：Client将连接（w3）和身份（account）结合在一起。由该客户端实例执行的所有操作都隐式地与特定的钱包和网络相关联。
  2. 可扩展性：需要管理100个钱包？只需创建100个Client实例。每个实例都是一个自包含的实体，消除了全局状态和繁琐的参数传递。
  3. 可读性：应用程序的主要逻辑变得更清晰。与一堆w3调用相比，您拥有像client.send_transaction(...)这样的表达式。将客户端类视为您的程序化 MetaMask。它持有密钥，连接到网络，并准备代表您执行操作。

交易的不可谈判要素是什么？

写入交易本质上是发送到网络的结构化消息。该消息由几个键值对组成，定义了预期的操作。让我们剖析一下您将在 Client 类中组装的最关键组件。

基础: to、value 和 data
这三个参数定义了您交易的核心内容。

  • to: 目标地址。这通常是您希望与之交互的智能合约，但也可以是另一个外部拥有账户（EOA），用于简单的本地代币转账。
  • value: 您通过交易发送的链的本地货币（ETH、MATIC、BNB 等）的数量。这是一个常见的混淆来源。心理模型很简单：value 仅在您从钱包中支出本地货币时才为非零。
  • 用 BNB 兑换 USDT？ value 是您支出的 BNB 数量。
  • 用 USDT 交换 BNB？value 是 0，因为 USDT 是通过 data 负载转移的，而不是通过 value 字段。
  • 调用 approve 函数？value 是 0。
  • 铸造一个成本为 0.1 MATIC 的 NFT？value 是 0.1 * 10**18。
  • data：指令负载。这是智能合约交互的魔法发生之处。它是一个十六进制字符串，告诉合约 要执行哪个函数以及使用什么参数。你不会手动编写这个。你使用合约的 ABI 来编码你的意图。
# 假设 'contract' 是一个 w3.eth.contract 实例
spender_address = '0x...'
amount_to_approve = 1000 * 10**18 # 以 wei 为单位的金额

# 将 'approve' 函数调用编码为十六进制数据字符串
tx_data = contract.encode_abi(
    fn_name='approve',
    args=(spender_address, amount_to_approve)
)
# tx_data 可能看起来像：'0x095ea7b3000000000000000000000000....'

 

data 字符串由两部分组成：

  1. 函数选择器（前4个字节）：函数签名的哈希值（例如，keccak256("approve(address,uint256)") 截断为4个字节）。这告诉合约要运行哪个函数。
  2. 参数（每个填充到32字节）：您在 args 中提供的值，按顺序序列化并附加。理解 data 是您函数调用的结构化、机器可读的翻译是一个关键的洞察。

协调机制：chainId 和 nonce
这些参数确保您的交易安全地执行并按正确顺序进行。

  • chainId：特定区块链的标识符（例如，1代表以太坊主网，56代表BNB链）。这是一个关键的安全特性，可以防止“重放攻击”，即在一个网络上签名的交易可能被恶意地在另一个网络上重新广播。
  • nonce：一个简单的整数，表示从您的账户发送的交易数量。如果最后一笔确认的交易的 nonce 是 10，那么您的下一笔交易必须是 nonce 11。网络在确认 nonce 11 之前不会处理 nonce 12 的交易。这个强大的机制：
    确保交易按照您发送的顺序被处理。

    • 您发送的顺序。
    • 防止来自单个账户的竞争条件和双重支付。
    • 作为您钱包中每笔交易的唯一标识符。您可以动态获取这些值：
chain_id = await self.w3.eth.chain_id
nonce = await self.w3.eth.get_transaction_count(self.account.address)
燃料：你如何为你的交易支付费用？

每个修改区块链状态的操作都会消耗计算资源，而这种消耗需要以燃料费的形式支付。你如何指定这种支付取决于网络是否支持EIP-1559标准。

传统交易（gasPrice）

这是原始模型。你指定一个单一的值，gasPrice，这是你愿意为每单位燃料支付的价格。验证者会优先处理燃料价格更高的交易。你还需要指定gas，这是你的交易可以消耗的最大燃料量（燃料限制）。

EIP-1559 交易（maxFeePerGas & maxPriorityFeePerGas）

EIP-1559引入了一种更复杂的定价机制，使费用更加可预测。总费用分为两部分：

    • 基础费用：每单位燃料的网络范围内费用，由区块拥堵情况决定。此费用会被销毁，而不是支付给验证者。
    • 优先费用（小费）：你额外包含的一笔费用，以激励验证者尽快处理你的交易。

在发送 EIP-1559 交易时，您不需要设置 gasPrice。相反，您需要设置：

  • maxPriorityFeePerGas：您愿意支付的最高小费。
  • maxFeePerGas：您愿意为每个 gas 单位支付的绝对最高总费用（基础费用 + 优先费用）。

这种模型更为优越，因为只要您的 maxFeePerGas 大于当前的 base_fee，您的交易就可以被包含，并且您只需支付必要的费用。

以下是在您的 Client 类中灵活构建交易字典（tx_params）以处理这两种类型的方法：

async def send_transaction(self, to: str, data: str, value: int = 0, is_eip1559: bool = True):
    tx_params = {
        'chainId': await self.w3.eth.chain_id,
        'nonce': await self.w3.eth.get_transaction_count(self.account.address),
        'from': self.account.address,
        'to': to,
        'value': value,
        'data': data
    }

    if is_eip1559:
        # 获取 EIP-1559 费用信息
        last_block = await self.w3.eth.get_block('latest')
        base_fee = last_block['baseFeePerGas']
        max_priority_fee = await self.w3.eth.max_priority_fee

        tx_params['maxPriorityFeePerGas'] = max_priority_fee
        tx_params['maxFeePerGas'] = base_fee + max_priority_fee
    else:
        # 使用传统的 gas 价格


tx_params['gasPrice'] = await self.w3.eth.gas_price

# 估算并设置燃气限制
tx_params['gas'] = await self.w3.eth.estimate_gas(tx_params)

# ... 签名和发送逻辑随之而来 ...

从代码到确认：您的交易发送清单

现在我们已经剖析了各个组件，让我们将完整的流程组装成一个可操作的清单。这个过程将位于我们客户端类的方法中。

  1. 实例化您的客户端：在您的主脚本中，使用您的私钥和目标网络的RPC URL创建一个Client对象。
  2. 定义目标: 获取智能合约的地址并加载其ABI。创建一个web3.py合约实例。
  3. 构造负载（data）：使用contract.encode_abi()生成您想要调用的函数的十六进制数据，并提供必要的参数。
  4. 组装并发送: 调用您的client.send_transaction()方法。该方法内部构建交易字典（tx_params），并包含正确的费用、nonce和链ID。
  5. S*签署交易*: 在send_transaction内部，使用账户对象签署组装好的tx_params。这证明您授权了该操作。
# 在send_transaction方法内部
signed_tx = self.w3.eth.account.sign_transaction(tx_params, self.private_key)

1.广播到网络：将签名的原始交易发送到RPC节点。这会立即返回交易哈希。

# 在send_transaction方法内部
tx_hash = await self.w3.eth.send_raw_transaction(signed_tx.rawTransaction)
return tx_hash

2.验证确认：不要仅仅因为你有一个哈希值就假设交易成功。创建一个 verify_tx 方法，使用 w3.eth.wait_for_transaction_receipt()。该方法将暂停执行，直到交易被挖矿，然后返回其收据，其中包含一个 status 字段（成功为1，失败为0）。

async def verify_tx(self, tx_hash: HexBytes, timeout: int = 200) -> bool:
    try:
        receipt = await self.w3.eth.wait_for_transaction_receipt(tx_hash, timeout)
        if receipt['status'] == 1:
            print(f"交易成功：{tx_hash.hex()}")
            return True
        else:
            print(f"交易失败：{tx_hash.hex()}")
            return False
    except Exception as e:
        print(f"验证交易时出错：{e}")
        return False

这种结构化的方法，将“什么”（在你的主脚本中）与“如何”（在Client类中）分开，是专业级区块链开发的标志。

最后的思考

我们从一个简单的私钥开始，经历了一个完整的、异步的EVM客户端，能够创建、签名和验证状态改变的交易。你现在明白，交易并不是一个单一的命令，而是由特定的有效载荷（data，value）、编排规则（nonce，chainId）和执行支付（燃料费）组成的结构化消息。

你已经看到，一个设计良好的Client类如何将一个混乱的脚本转变为一个可扩展和可维护的应用程序。你可以区分传统费用模型和EIP-1559费用模型，并实现逻辑以处理两者。

发送交易是参与去中心化世界的基本方式。这是将用户转变为代理、将读者转变为作者的行为。通过在这里建立的框架和深入理解，您现在具备了构建下一代自主链上代理、机器人和应用程序的能力。区块链是您的画布；去创造吧。

更多

Weibo Weixin

京ICP备17072685号-4 © 2025 QPython.