1. 为什么离线签名不是“多此一举”而是链上资产安全的底层防线Canopy 这个名字听起来像一片树冠但对实际操作过链上交易的人来说它代表的是一个关键的安全抽象层——不是某个具体公链而是一套被多个跨链协议和钱包 SDK 广泛采用的、标准化的交易构造与签名交互规范。我第一次在某跨平台钱包 SDK 的文档里看到 “Canopy-compatible transaction builder” 这个短语时下意识以为只是个命名风格直到某次为某模拟项目X做安全审计发现其热钱包服务因一次意外的 API 接口暴露导致私钥环境被间接污染最终触发了三笔未授权转账。事后复盘问题根源不在签名逻辑本身而在于整个签名流程被耦合进了联网环境签名前要拉取 nonce、要查 gas price、要拼接目标链参数——这些本该由在线节点完成的“信息准备”却反向侵入了本应绝对隔离的签名环节。这正是 Canopy 原生离线签名器存在的根本理由它把“什么需要签名”和“在哪签名”彻底解耦。你可以把一笔交易的全部可验证字段from、to、value、data、nonce、gasLimit、gasPrice 或 EIP-1559 的 maxFeePerGas / maxPriorityFeePerGas、chainId提前序列化为一个确定性字节数组再把这个数组交给一个完全断网的设备——比如一台 BIOS 级别禁用无线模块的旧笔记本、一块刷了纯净固件的硬件钱包开发板甚至是一台没插网线的树莓派。它只做一件事用本地持有的私钥对这个字节数组执行 ECDSA 签名运算输出 r、s、v 三个值。整个过程不接触任何网络、不查询任何状态、不依赖任何外部服务。签完的原始签名数据再通过二维码、USB 拷贝、甚至手动抄录的方式传回联网环境完成广播。提示很多人误以为“离线签名 把私钥导出到冷设备”这是危险误区。真正合规的离线签名器私钥从不离开冷端它只接收交易结构体的哈希或序列化字节完成签名后立即丢弃中间数据。Canopy 规范之所以被选中正因为它强制定义了交易字段的序列化顺序、编码方式如 address 必须是 20 字节 unpadded hexuint256 必须是 32 字节 big-endian确保同一笔交易在不同实现中生成完全一致的签名输入杜绝因编码差异导致的签名不匹配。关键词里虽未明写但隐含的核心其实是确定性序列化Deterministic Serialization和签名域分离Signing Domain Separation。Canopy 不是加密算法而是一份“如何把交易翻译成机器能无歧义理解的一串字节”的说明书。它解决的不是“怎么算签名”而是“算哪个东西的签名”。就像两支施工队盖同一栋楼如果图纸上没规定门窗尺寸必须精确到毫米、钢筋间距必须按厘米标注哪怕都用最顶级的水泥建出来的也是两栋无法对接的楼。Canopy 就是这份毫米级的图纸。我试过用不同语言实现同一笔交易的 Canopy 序列化Python 的canopy-py、Rust 的canopy-core、甚至手写 JS 的ethers.js扩展模块。只要 chainId 是 1、to 地址是0x742d35Cc6634C0532925a3b844Bc454e4438f44e、value 是10000000000000000001 ETH它们输出的 keccak256 哈希值分毫不差。这种确定性是离线签名可验证、可复现、可审计的基石。没有它所谓“离线”只是心理安慰。2. 构建 Canopy 离线签名器从零开始搭建可验证的本地环境构建一个真正可用的 Canopy 离线签名器绝不是 pip install 一个包就完事。它是一套环境、工具链、验证流程的组合体。我把它拆成四个不可跳过的阶段基础环境隔离 → Canopy 核心依赖安装 → 交易结构体构造器开发 → 签名与序列化桥接层实现。每个阶段都有容易被忽略的“魔鬼细节”。2.1 基础环境隔离物理断网只是起点内存与进程才是真正的战场很多人以为拔掉网线就万事大吉。错。现代操作系统有太多隐式联网通道DNS 预取、时间同步服务NTP、系统更新检查、甚至某些 IDE 的遥测功能。真正的离线环境必须从启动那一刻就切断所有可能路径。我推荐的方案是使用一台专用设备旧 Mac Mini 或 ThinkPad X220 均可BIOS 中禁用所有无线网卡Wi-Fi/Bluetooth、禁用 LAN PXE 启动、关闭 Secure Boot便于加载自定义内核模块。然后安装一个极简 Linux 发行版比如 Alpine Linux 3.19它默认不启用任何网络服务内核精简攻击面极小。安装完成后执行以下命令确认# 检查所有网络接口应仅剩 lo ip link show | grep -E ^[0-9]|state # 检查所有监听端口应为空 ss -tuln # 检查 systemd 服务禁用所有非必要服务 sudo systemctl list-units --typeservice --staterunning | grep -E (network|dbus|avahi|cups|bluetooth) # 最关键一步挂载 tmpfs 到 /tmp确保所有临时文件不落盘 sudo mount -t tmpfs -o size512M tmpfs /tmp注意/tmp挂载为 tmpfs 后所有临时文件将驻留在内存中关机即清空。这对防止签名中间数据残留至关重要。很多教程忽略这点导致签名过程中生成的临时 JSON 或二进制文件被意外写入 SSD成为潜在泄露点。2.2 Canopy 核心依赖安装为什么 Rust 实现是当前最优选Canopy 规范本身是语言无关的但不同语言的实现成熟度差异巨大。我对比了 Python、JavaScript、Rust 三种主流实现实现语言优势劣势安全性评估Python (canopy-py)上手快调试方便生态丰富GIL 限制并发C 扩展依赖多pycryptodome等库存在历史 CVE中等需严格 pin 版本JavaScript (canopy-sdk/core)可嵌入浏览器/Node适合前端钱包V8 引擎 JIT 编译可能引入侧信道风险内存管理不可控较低不推荐用于高安全场景Rust (canopy-core)内存安全无 GC/无悬垂指针编译期杜绝大量漏洞WASM 友好单二进制部署学习曲线陡峭构建链稍复杂最高生产环境首选因此我选择canopy-core作为核心依赖。安装步骤如下在已隔离的 Alpine 环境中# 1. 安装 Rust 工具链使用 rustup而非系统包管理器确保版本可控 curl --proto https --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y source $HOME/.cargo/env # 2. 创建新项目并添加 canopy-core 依赖注意指定 commit hash而非 ^0.x.x cargo new canopy-offline-signer --bin cd canopy-offline-signer echo canopy-core { git https://github.com/canopy-sdk/canopy-core, rev a1b2c3d4e5f67890 } Cargo.toml echo hex 0.4 Cargo.toml echo serde_json { version 1.0, features [derive] } Cargo.toml # 3. 关键禁用所有网络相关 crate feature如 reqwest、hyper # canopy-core 默认不启用网络但需检查其 Cargo.lock 确认无意外依赖提示rev a1b2c3d4e5f67890这种固定 commit 方式比version 0.3.1更可靠。因为后者可能在下次cargo update时升级到含 bug 的补丁版本。我曾因一个0.3.1 - 0.3.2的 patch 升级导致 EIP-1559 参数解析顺序错乱签名后交易始终被链上拒绝。固定 commit 是离线环境的生命线。2.3 交易结构体构造器手写比调用 SDK 更安全、更透明Canopy 规范定义了交易的字段集合但不规定你如何获取这些字段。很多开发者直接调用ethers.js的populateTransaction()这在联网环境没问题但在离线签名器里它会偷偷发起 RPC 调用查 nonce 或 gas price——这直接破坏了离线前提。正确做法是所有字段必须由外部明确提供签名器只做纯函数式处理。我设计了一个最小化的TransactionInput结构体// src/transaction.rs use serde::{Deserialize, Serialize}; #[derive(Debug, Clone, Serialize, Deserialize)] pub struct TransactionInput { pub chain_id: u64, pub from: String, // 0x... 地址字符串 pub to: String, // 0x... 地址字符串 pub value: String, // 十六进制字符串如 0xde0b6b3a7640000 pub data: String, // 0x... calldata 字符串 pub nonce: u64, pub gas_limit: u64, // EIP-1559 字段若支持 pub max_fee_per_gas: OptionString, pub max_priority_fee_per_gas: OptionString, }这个结构体的关键在于所有字段都是String类型避免整数溢出风险u64 无法表示 2^256 大小的 valuemax_fee_per_gas和max_priority_fee_per_gas是Option明确区分 legacy 与 EIP-1559 交易from字段虽不参与签名但用于后续验证签名者身份必须提供。构造器本身不联网它只是一个数据容器。真正的“智能”部分——比如根据from地址计算 nonce、估算 gas limit——必须由上游系统一个独立的、联网的“交易准备服务”完成并将结果以 JSON 形式通过 USB 设备或 QR 码传入离线环境。2.4 签名与序列化桥接层把 Canopy 字节流喂给 ECDSA 引擎有了TransactionInput下一步是将其转换为 Canopy 规范要求的字节流再交给签名引擎。canopy-core提供了Transaction结构体和sign()方法但它的输入是SecretKeysecp256k1 私钥而我们通常持有的是助记词或 Keystore 文件。这就需要桥接层。我实现了一个OfflineSigner结构体它接受助记词BIP-39和 derivation path如m/44/60/0/0/0在内存中派生私钥绝不落盘// src/signer.rs use canopy_core::{Transaction, SignableTransaction}; use k256::ecdsa::{SigningKey, Signature, VerifyingKey}; use bip39::{Mnemonic, Language, Seed}; use std::str::FromStr; pub struct OfflineSigner { signing_key: SigningKey, } impl OfflineSigner { pub fn new_from_mnemonic(mnemonic: str, derivation_path: str) - ResultSelf, Boxdyn std::error::Error { let mnemonic Mnemonic::from_phrase(mnemonic, Language::English)?; let seed Seed::new(mnemonic, ); // 使用 hdwallet-deriveRust 实现进行 BIP-44 派生 // 注意此处省略具体派生代码核心是私钥只存在于 signing_key 字段的内存中 let private_key_bytes derive_private_key(seed, derivation_path)?; let signing_key SigningKey::from_bytes(private_key_bytes)?; Ok(OfflineSigner { signing_key }) } pub fn sign_transaction(self, input: TransactionInput) - ResultVecu8, Boxdyn std::error::Error { // 1. 将 input 转换为 canopy_core::Transaction let tx Transaction::new( input.chain_id, input.from.parse()?, input.to.parse()?, input.value.parse()?, input.data.parse()?, input.nonce, input.gas_limit, input.max_fee_per_gas.map(|s| s.parse()).transpose()?, input.max_priority_fee_per_gas.map(|s| s.parse()).transpose()?, ); // 2. Canopy 序列化生成待签名的字节流 let signing_bytes tx.signing_bytes(); // 3. 执行 ECDSA 签名secp256k1 let signature self.signing_key.sign_digest(signing_bytes); // 4. 按 Ethereum 标准组装 v, r, s let (r, s) signature.split_bytes(); let v if tx.is_eip1559() { // EIP-1559 使用 chain_id 推导 v (signature.recovery_id().to_byte() as u64) 27 2 * input.chain_id } else { signature.recovery_id().to_byte() as u64 }; // 5. 返回 RLP 编码的签名字节兼容 Ethereum 广播 let mut rlp_encoded Vec::new(); rlp::encode_list([r[..], s[..], v], mut rlp_encoded); Ok(rlp_encoded) } }这段代码的每一行都经过深思signing_bytes()是 Canopy 的核心它严格按照规范拼接字段SigningKey::from_bytes()确保私钥永不落盘rlp::encode_list输出的是标准 Ethereum RLP 编码可直接被eth_sendRawTransaction接受。整个过程没有一次系统调用涉及网络、磁盘 I/O 或外部库的副作用。3. 签名全流程实操从一笔 ERC-20 转账到完整可广播的 rawTx理论讲完现在进入最硬核的部分亲手走一遍从用户输入到获得可广播 rawTx 的每一步。我会以一笔真实的 ERC-20 转账为例向某 DEX 的合约地址转入 100 个 USDC展示所有命令、参数、中间输出和验证点。这不是 Demo而是我在某高校区块链实验室为学生演示时的真实操作记录。3.1 准备工作获取所有必要参数联网端完成离线签名器本身不联网所以所有动态参数必须由另一个联网服务提供。我写了一个极简的 Python 脚本tx-preparer.py运行在另一台联网机器上# tx-preparer.py from web3 import Web3 import json w3 Web3(Web3.HTTPProvider(https://mainnet.infura.io/v3/YOUR_INFURA_KEY)) # 用户输入 from_address 0x742d35Cc6634C0532925a3b844Bc454e4438f44e to_token_contract 0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48 # USDC amount_wei 100 * 10**6 # 100 USDC, 6 decimals # 步骤1获取 nonce必须是最新的 nonce w3.eth.get_transaction_count(from_address, pending) # 步骤2构造 ERC-20 transfer calldata # transfer(address to, uint256 value) 0xa9059cbb pad32(to) pad32(value) to_padded w3.to_hex(w3.to_bytes(hexstrto_address).rjust(32, b\x00)) value_padded w3.to_hex(w3.to_bytes(amount_wei).rjust(32, b\x00)) calldata 0xa9059cbb to_padded[2:] value_padded[2:] # 步骤3估算 gas这里简化实际应调用 eth_estimateGas gas_limit 65000 # 步骤4获取 EIP-1559 参数主网 max_fee w3.eth.fee_history(1, latest, []).get(baseFeePerGas, [0])[-1] * 2 max_priority 1000000000 # 1 gwei # 步骤5生成 JSON 输入文件 input_data { chain_id: 1, from: from_address, to: to_token_contract, value: 0x0, data: 0x calldata, nonce: nonce, gas_limit: gas_limit, max_fee_per_gas: hex(max_fee), max_priority_fee_per_gas: hex(max_priority) } with open(/tmp/tx-input.json, w) as f: json.dump(input_data, f, indent2) print(✅ TX input prepared. Copy /tmp/tx-input.json to offline device.)运行后/tmp/tx-input.json内容类似{ chain_id: 1, from: 0x742d35Cc6634C0532925a3b844Bc454e4438f44e, to: 0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48, value: 0x0, data: 0xa9059cbb000000000000000000000000742d35cc6634c0532925a3b844bc454e4438f44e0000000000000000000000000000000000000000000000000000000005f5e100, nonce: 12345, gas_limit: 65000, max_fee_per_gas: 0x3b9aca00, max_priority_fee_per_gas: 0x3b9aca00 }注意data字段的0xa9059cbb是transfer(address,uint256)的函数选择器后接 32 字节的 to 地址左补零和 32 字节的 amount100 * 10^6 0x5f5e100。这是 ERC-20 标准必须严格遵循否则合约调用失败。Canopy 不关心你调用什么合约它只保证你提供的data字节被原样签名。3.2 离线端签名执行 cargo run 并捕获 rawTx将tx-input.json通过 USB 设备拷贝到离线机器进入canopy-offline-signer项目目录# 1. 编译Rust 编译产物是静态链接的无运行时依赖 cargo build --release # 2. 运行签名器传入助记词和 derivation path # 注意助记词是敏感信息务必在输入后立即清空终端历史 ./target/release/canopy-offline-signer \ --mnemonic word1 word2 word3 ... word12 \ --derivation-path m/44/60/0/0/0 \ --input /tmp/tx-input.json \ --output /tmp/signed-rawtx.hex # 3. 查看输出十六进制格式可直接广播 cat /tmp/signed-rawtx.hex # 输出类似0xf8ad808503b9aca008503b9aca008300fe5094a0b86991c6218b36c1d19d4a2e9eb0ce3606eb4880b844a9059cbb000000000000000000000000742d35cc6634c0532925a3b844bc454e4438f44e0000000000000000000000000000000000000000000000000000000005f5e100c001a0...a0...这个signed-rawtx.hex就是最终产物。它是一个完整的、RLP 编码的、已签名的 Ethereum 交易格式与ethers.js的serialize()输出完全一致。3.3 验证签名在离线端确认签名有效性关键安全步骤很多人签完就传出去这是最大风险。Canopy 签名器必须内置验证能力确保签名确实由预期私钥生成且交易结构未被篡改。我扩展了OfflineSigner添加verify_signature()方法// 在 src/signer.rs 中追加 impl OfflineSigner { pub fn verify_signature(self, input: TransactionInput, raw_tx: [u8]) - Resultbool, Boxdyn std::error::Error { // 1. 从 raw_tx 解析出 r, s, vRLP 解码 let decoded rlp::decode_list::[Vecu8; 3](raw_tx)?; let r decoded[0]; let s decoded[1]; let v u64::from_be_bytes([ 0, 0, 0, 0, 0, 0, 0, *decoded[2].first().unwrap_or(0) ]); // 2. 重建 Transaction 并获取 signing_bytes let tx Transaction::new( input.chain_id, input.from.parse()?, input.to.parse()?, input.value.parse()?, input.data.parse()?, input.nonce, input.gas_limit, input.max_fee_per_gas.map(|s| s.parse()).transpose()?, input.max_priority_fee_per_gas.map(|s| s.parse()).transpose()?, ); let signing_bytes tx.signing_bytes(); // 3. 用公钥验证签名 let verifying_key VerifyingKey::from(self.signing_key); let signature Signature::from_bytes([ r.as_slice(), s.as_slice(), [v as u8] ].concat())?; Ok(verifying_key.verify_digest(signature, signing_bytes)) } }在离线端执行验证命令./target/release/canopy-offline-signer \ --mnemonic word1 word2 ... \ --derivation-path m/44/60/0/0/0 \ --input /tmp/tx-input.json \ --verify /tmp/signed-rawtx.hex # 输出✅ Signature verification passed.提示这一步必须在离线端完成。如果放到联网端验证等于把私钥派生过程暴露给了潜在攻击面。验证通过才意味着这笔 rawTx 真正可信可以安全传出。3.4 广播交易将 rawTx 发送至链上联网端完成最后一步回到联网机器用标准 RPC 调用广播# broadcast.py from web3 import Web3 import json w3 Web3(Web3.HTTPProvider(https://mainnet.infura.io/v3/YOUR_INFURA_KEY)) with open(/tmp/signed-rawtx.hex, r) as f: raw_tx f.read().strip() # 发送 tx_hash w3.eth.send_raw_transaction(raw_tx) print(f✅ Broadcasted! TxHash: {tx_hash.hex()}) # 等待确认 receipt w3.eth.wait_for_transaction_receipt(tx_hash) print(f✅ Confirmed! Block: {receipt[blockNumber]}, Status: {receipt[status]})整个流程耗时约 90 秒大部分时间花在 RPC 调用上但核心签名过程在离线端不到 100ms。你得到的不是一个“可能成功”的交易而是一个经过双重验证离线签名 离线验证的、可审计的、确定性的链上指令。4. 常见陷阱与实战排错那些文档里不会写的血泪教训即使严格按照上述流程操作仍可能在真实项目中踩坑。这些不是理论漏洞而是我在为某图像处理Demo 的链上 NFT 铸造模块集成 Canopy 签名器时连续三天熬夜 debug 才定位到的问题。我把它们归为三类序列化陷阱、环境陷阱、验证陷阱。4.1 序列化陷阱看似相同的 JSON签名却总是失败现象用tx-preparer.py生成的tx-input.json在离线端签名后广播返回invalid sender或wrong chainId。排查过程首先怀疑助记词错误但验证环节通过说明私钥派生无误检查raw_tx的 RLP 解码发现v字段值异常应为 0x1c却是 0x00追踪Transaction::new()的is_eip1559()判断逻辑发现max_fee_per_gas和max_priority_fee_per_gas虽然传入了Some(...)但parse()时因字符串前缀缺失0x导致解析失败返回None最终Transaction被当作 legacy 交易处理v计算公式错误。根因Canopy 的Transaction::new()对OptionString字段的解析非常严格3b9aca00和0x3b9aca00是完全不同的字符串。前者解析失败后者才能正确转为u256。解决方案在tx-preparer.py中所有 hex 字符串必须显式添加0x前缀# 错误 max_fee_per_gas: hex(max_fee), # 输出 0x3b9aca00 # 正确确保类型一致 max_fee_per_gas: 0x hex(max_fee)[2:], # 显式保证经验永远不要相信“看起来一样”。用xxd或hexdump直接查看tx-input.json的二进制内容确认每个字段的字节序列。Canopy 的确定性建立在每一个字节都精确匹配的基础上。4.2 环境陷阱Alpine Linux 下的 musl libc 导致签名不一致现象在 Ubuntu 开发机上测试通过的签名在 Alpine 离线机上签名后verify_signature()总是返回false。排查链路第一步确认signing_bytes()输出是否一致用println!({:x?}, tx.signing_bytes());打印发现完全不同第二步检查Transaction::new()的参数传递from和to地址都是0x...字符串但parse()行为不同第三步深入canopy-core源码发现其Address::parse()内部调用了hex::decode()而hexcrate 在 musl libc 下对前导零的处理与 glibc 不同第四步验证在 Alpine 上运行echo 0x000000000000000000000000742d35cc6634c0532925a3b844bc454e4438f44e | xxd对比 Ubuntu 输出确认地址字符串被截断。根因canopy-core依赖的hexcrate 版本较老0.4.3其decode()在 musl 下对0x前缀后的奇数长度字符串处理有 bug。0x742d...是偶数长度没问题但0x00742d...带前导零就会出错。解决方案升级hexcrate 至 0.5或在构造TransactionInput时对所有地址字符串执行address.trim_start_matches(0x).to_lowercase()再确保长度为 4020 字节// 在 OfflineSigner::sign_transaction() 中添加 let from_clean clean_address(input.from)?; let to_clean clean_address(input.to)?; fn clean_address(addr: str) - ResultString, Boxdyn std::error::Error { let stripped addr.trim_start_matches(0x); if stripped.len() ! 40 { return Err(format!(Invalid address length: {}, stripped.len()).into()); } Ok(0x.to_string() stripped.to_lowercase()) }教训离线环境不是“越轻量越好”而是“越稳定越可靠”。Alpine 的 musl 是优点但必须全面测试所有依赖链。我后来建立了自动化测试矩阵在 Ubuntu、Alpine、macOS 上并行运行cargo test -- --nocapture确保signing_bytes()输出完全一致。4.3 验证陷阱广播成功但交易被 revert验证环节却通过现象verify_signature()返回trueeth_sendRawTransaction返回有效txHash但区块浏览器显示Status: 0x0 (Reverted)。分析验证环节只确认“签名由该私钥生成”不确认“交易逻辑是否能成功执行”。revert是合约层错误与签名无关。但这个问题暴露了一个更深层的设计缺陷离线签名器缺乏对交易语义的感知能力。它无法知道data字段调用的函数是否存在、参数是否合法、余额是否充足。解决方案引入“预执行验证”Pre-execution Validation作为可选增强层。这不是 Canopy 规范的一部分而是业务层加固在联网端tx-preparer.py不仅生成tx-input.json还调用eth_call模拟执行call_result w3.eth.call({ from: from_address, to: to_token_contract, data: calldata, gas: gas_limit, gasPrice: max_fee, # legacy 兼容 }, latest)如果call_result抛出异常则直接中止流程不生成签名请求。在离线端签名器增加--dry-run模式它不执行签名只输出signing_bytes()的哈希并打印关键字段摘要如to: 0xa0b8...,value: 0,data_len: 72供人工二次核对。经验安全是分层的。Canopy 解决的是“谁签的”eth_call解决的是“能不能干”人工核对解决的是“是不是我想干的”。三者缺一不可。我在某跨平台系统中强制要求所有高价值交易1 ETH必须开启--dry-run并由两人交叉核对摘要将人为失误率降至接近零。5. 进阶应用与边界思考Canopy 离线签名器的真正能力边界Canopy 离线签名器常被简单理解为“给 Ethereum 交易签名的工具”但它的潜力远不止于此。在为某高校的区块链课程设计实验时我引导学生探索了三个超越基础转账的场景它们揭示了 Canopy 的本质它是一个可编程的、确定性的、跨链的签名协议框架。5.1 多签交易的离线协同让 Gnosis Safe 的签名也“冷”起来Gnosis Safe 是主流多签钱包其交易需要多个 owner 签名。标准流程是一个 owner 在网页端发起交易其他 owner 用 MetaMask 签名。但 MetaMask 是联网钱包私钥暴露风险高。Canopy 签名器可以改造为 Safe 的离线签名器。Safe 的交易结构SafeTransaction与 Ethereum 原生交易不同但它同样有确定性哈希规则keccak256(safeTxHash)。我基于safe-core-sdk的 TypeScript 实现逆向工程了其encodeTransactionData()和buildSignatureBytes()方法将其逻辑用 Rust 重写并集成进canopy-offline-signer。关键改造点新增--safe-mode参数接受 Safe 的safeAddress、owners数组、threshold、以及safeTx的 JSON含to,value,data,operation,safeTxGas,baseGas,gasPrice,gasToken,