1703878852
1703878853
·0xb62a11697c0f56e93f3957c088d492b505b9edd7fb6e7872a93b41cdb2020644。这是第一个主题,它用web3.sha3(“ping(string,int256,uint256,string,int256)”)生成。可以看到所有类型都采用规范格式。
1703878854
1703878855
·0x30ee7c926ebaf578d95b278d78bc0cde445887b0638870a26dcab901ba21d3f2。这是第二个主题,它用web3.sha3(“RandomString”)生成。
1703878856
1703878857
·第三个和第四个主题分别是0x000000000000000000000000000000000000000000000000000000000000000c和0x0000000000000000000000000000000000000000000000000000000000000017,即以十六进制表示的数值。它们分别用EthJS.Util.bufferToHex(EthJS.Util.setLengthLeft(12,32))和EthJS.Util.bufferToHex(EthJS.Util.setLengthLeft(23,32))计算。
1703878858
1703878859
以太坊节点将在内部使用主题创建索引,这样很容易基于签名和索引化的数值找到事件。
1703878860
1703878861
假设想获取前面事件的事件调用,其中第一个实参是Random String,第三个实参是23或者78,则可以用web3.eth.getFilter找到它们:
1703878862
1703878863
1703878864
1703878865
1703878866
1703878867
1703878868
1703878869
所以这里让节点从区块链返回0x853cdcb4af7a6995808308b08bb78a74de1ef899合约地址发出的全部事件,其第一个主题是0xb62a11697c0f56e93f3957c088d492b505b9edd7fb6e7872a93b41cdb2020644,第二个主题是0x30ee7c926ebaf578d95b278d78bc0cde445887b0638870a26dcab901ba21d3f2,第三个主题是0x0000000000000000000000000000000000000000000000000000000000000017或者0x000000000000000000000000000000000000000000000000000000000000004e。
1703878870
1703878871
1703878872
在程序代码中,注意主题数组数值的顺序。顺序很重要。
1703878873
1703878874
1703878875
1703878876
1703878878
区块链项目开发指南 8.3 开始使用truffle-contract
1703878879
1703878880
在学习truffle之前,学习truffle-contract很重要,因为truffle-contract与truffle密切相关。Truffle测试、truffle中与合约交互的代码、部署代码等都是使用truffle-contract编写的。
1703878881
1703878882
truffle-contract API是一个JavaScript和Node.js库,它使以太坊智能合约的处理变得容易。到目前为止,我们已经使用了web3.js部署和调用智能合约函数,这没问题,但是truffle-contract的目标是更容易操作以太坊智能合约。下面是truffle-contract的一些功能,这些功能使truffle-contract在处理智能合约时优于web3.js:
1703878883
1703878884
·同步交易,优化了控制流(交易在直到确定被挖出之前都不会停止)。
1703878885
1703878886
·基于约定的API。再没有“回调地狱”。在ES6和async/await上都可以用。
1703878887
1703878888
·默认交易数值,例如from address或者gas。
1703878889
1703878890
·返回每个同步的日志、交易收据和交易哈希。
1703878891
1703878892
在学习truffle-contract之前,需要知道它不允许使用存储以太坊节点之外的账户签署交易,也就是说,它没有类似于sendRawTransaction的东西。truffle-contract API假设DApp中的每个用户各自运行以太坊节点,且其账户都存储在那个节点中。事实上,DApp应该这样运行,因为如果DApp的每个客户端开始让用户创建和管理账户,那么用户管理这么多账户就成了问题。开发人员为他们创建的每个客户端每次都要开发一个钱包manager也是很痛苦的。现在的问题是客户端怎样才能知道用户在哪里以及用什么格式存储了账户。所以从概率角度出发,优选假设用户将账户存储在个人节点上,而且为了管理账户,它们使用以太坊钱包应用的东西。因为以太坊节点中存储的账户由以太坊节点自身签名,所以就不再需要sendRawTransaction了。每个用户需要有各自的节点,而不能分享节点,因为解锁一个账户时,对使用它的所有人都是开放的,这将使用户能盗窃其他人的以太币和用他人的账户进行交易。
1703878893
1703878894
1703878895
如果所使用的App要求用户包含自己的节点,并在该节点中管理账户,那就需要确保只有本地应用才能对该节点进行JSON-RPC调用,而不能让所有人都能调用。还要确保用户不会长期解锁账户,只要不需要账户,就应当立即锁定。
1703878896
1703878897
如果应用要求有创建和签署原始交易功能,则可以使用truffle-contract开发和测试智能合约。在应用中可以与合约交互,就像我们之前做的。
1703878898
1703878899
1703878900
1703878901
[
上一页 ]
[ :1.703878852e+09 ]
[
下一页 ]