前两篇文章中,我们讲到如何创建和解锁以太坊钱包.本章我们将讲解转账相关的内容.
为了良好的阅读体验, 请阅读原文
我们先说明下整体的流程.
首先是钱包本地将转账信息进行离线签名,然后通过以太坊JSON-RPC方法发送到以太坊节点,其中以太坊和其他ERC20代币的签名是不同的.
转账
ETH转账签名
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
|
public String signedEthTransactionData(String to, BigInteger nonce, BigInteger gasPrice, BigInteger gasLimit, BigDecimal amount, HLWallet wallet, String password) throws Exception { BigDecimal amountInWei = Convert.toWei(amount.toString(), Convert.Unit.ETHER); RawTransaction rawTransaction = RawTransaction.createEtherTransaction(nonce, gasPrice, gasLimit, to, amountInWei.toBigInteger()); return signData(rawTransaction,wallet,password); }
private String signData(RawTransaction rawTransaction, HLWallet wallet, String password) throws Exception { Credentials credentials = Credentials.create(LWallet.decrypt(password, wallet.walletFile)); byte[] signMessage = TransactionEncoder.signMessage(rawTransaction, ChainId.MAINNET, credentials); return Numeric.toHexString(signMessage);
}
|
nonce
为了防止交易的重播攻击,每笔交易必须有一个nonce随机数,针对每一个账户nonce都是从0开始,当nonce为0的交易处理完之后,才会处理nonce为1的交易,并依次加1的交易才会被处理.以下是nonce使用的几条规则:
- 当nonce太小,交易会被直接拒绝。
- 当nonce太大,交易会一直处于队列之中,这也就是导致我们上面描述的问题的原因;
- 当发送一个比较大的nonce值,然后补齐开始nonce到那个值之间的nonce,那么交易依旧可以被执行。
- 当交易处于queue中时停止geth客户端,那么交易queue中的交易会被清除掉。
我们可通过以太坊JSON-RPC方法eth_gettransactioncount 获取nonce
ERC-20代币转账签名
ERC-20代币与以太坊转账是不同的,需要走智能合约.
以下是手动拼接的方式
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
| public String signedContractTransactionData(String contractAddress, String to, BigInteger nonce, BigInteger gasPrice, BigInteger gasLimit, BigDecimal amount, BigDecimal decimal, HLWallet wallet, String password) throws Exception { BigDecimal realValue = amount.multiply(decimal); String data = Params.Abi.transfer + Numeric.toHexStringNoPrefixZeroPadded(Numeric.toBigInt(to), 64) + Numeric.toHexStringNoPrefixZeroPadded(realValue.toBigInteger(), 64);
RawTransaction rawTransaction = RawTransaction.createTransaction( nonce, gasPrice, gasLimit, contractAddress, data); return signData(rawTransaction, wallet, password); }
|
此时我们需要将转账的指令信息通过签名时的data
发送出去.代币转账的data
组成部分有三个.
- 首先是固定头
0xa9059cbb
- 然后是转入钱包地址
- 再是转账的数量,以wei作为单位
这里我们说明下,为什么固定头是0xa9059cbb
.是因为它是函数原型transfer(address,uint256)
的MethodId,相当于以太坊用来分辨指令的标识,具体转换方法为
1 2 3 4 5 6 7
|
String transfer = "transfer(address,uint256)"; byte[] bytes = transfer.getBytes(); byte[] bytes1 = org.web3j.crypto.Hash.sha3(bytes); String hex = Numeric.toHexString(bytes1, 0, 4, true); ShadowLog.i("transfer", hex);
|
然后对于转入地址及转账数量,我们是将其转化为16进制,然后左边补0至64位.三个参数字符串拼接在一起即为最后签名时用到的data
. 那么可能有人会问,是不是其他指令参数都是这么拼接? 当然不是,这里涉及到以太坊合约ABI,有兴趣的童鞋可以看看.这里因为转入地址的类型address
和转账数量的类型uint256
都是__静态__的,因此是上述的拼接方式,如果是动态的则不一样了,具体可以参考ABI文档.
这里我们提供另外一种web3j
既有的封装实现,不用关心内部参数是如何拼接的.(推荐)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
| public String signContractTransaction(String contractAddress, String to, BigInteger nonce, BigInteger gasPrice, BigInteger gasLimit, BigDecimal amount, BigDecimal decimal, HLWallet wallet, String password) throws IOException, CipherException { BigDecimal realValue = amount.multiply(decimal); Function function = new Function("transfer", Arrays.asList(new Address(to), new Uint256(realValue.toBigInteger())), Collections.emptyList()); String data = FunctionEncoder.encode(function); RawTransaction rawTransaction = RawTransaction.createTransaction( nonce, gasPrice, gasLimit, contractAddress, data); return signData(rawTransaction, wallet, password); }
|
发送请求
签名完后,通过以太坊的JSON-RPC发送出去.eth_sendrawtransaction
ETH转账最终在以太坊浏览器上的转账结果 link ,可在页面最下方查看__Input Data__
代币转账最终在以太坊浏览器上的转账结果 link,__Input Data__为
1 2 3 4 5
| Function: transfer(address _to, uint256 _value)
MethodID: 0xa9059cbb [0]: 000000000000000000000000b7bb6c45800f4531cc1581637868373a06367b48 [1]: 000000000000000000000000000000000000000000000002d1a51c7e00500000
|
FAQ
Q: 为什么调用sendRawTransaction接口后,转账记录在以太坊浏览器或者其他钱包查询不到?
A: 接口调用后会返回一个字符串hash,我们通常称为txHash
.此时是不知道结果的,因为拥堵或者其他原因以太坊不一定确认,因此查不到是正常的.在app中,一种做法是在发送请求后,主动通知自己的中继relay,在中继relay中维护这个txHash
状态,以__处理中__的状态呈现给用户.
Q:sendRawTransaction后接口报错’invalid sender’
A: 这个报错是以太坊环境错误导致的,代码上表现为chainId没对应.
1 2 3 4 5 6 7 8 9
| private String signData(byte chainId, RawTransaction rawTransaction, HDWallet wallet, String password) throws Exception { Credentials credentials; credentials = Credentials.create(Wallet.decrypt(password, wallet.getWalletFile())); byte[] signMessage = TransactionEncoder.signMessage(rawTransaction, chainId, credentials); return Numeric.toHexString(signMessage); }
|
签名需要制定环境chainId,若使用不带chainId的方法,则默认是主网.
友链:
- https://www.i7play.com/
参考:
- https://blog.csdn.net/wo541075754/article/details/77975335