第6章 创建智能合约部署平台

有些客户端可能需要在运行时编译和部署合约。在所有权证明DApp中，我们手动部署智能合约并在客户端代码中硬编码合 约地址。但是有些客户端可能需要在运行时部署智能合约。例如，如果客户端让学校在区块链中记录学生出勤情况，那么每次注册一个新学校都需要部署智能合约， 这样每个学校才能完全控制其智能合约。在本章中，我们将学习如何使用web3.js编译智能合约，并使用web3.js和EthereumJS部署智能合 约。

在本章中，我们将讲解以下内容：

·计算交易nonce。

·使用交易池JSON-RPC API。

·为合约创建和方法调用生成交易数据。

·估算交易所需的gas。

·发现账户的当前可用余额。

·使用solcjs编译智能合约。

·开发一个编写、编译和部署智能合约的平台。

6.1　计算一个地址的交易nonce

对于用geth维护的账户，不需要担心nonce计数，因为geth可以向交易添加正确的nonce并签名。如果账户不是用geth管理的，则需要自行计算nonce。

为了自行计算nonce，可以使用geth提供的getTransactionCount方法。第一个实参应当是所需 的交易数的地址，第二个实参是需要交易数的那个区块。我们可以用“pending（待定）”字符串作为区块，这个区块包括从当前挖出的区块的交易。正如此 前的章节所述，geth维护一个待定交易和排队交易的交易池。为了挖出一个区块，geth把待定交易从交易池中取出，并开始挖新的区块。在没有挖该区块之 前，待定交易一直在交易池中，一旦挖出来，该交易就从交易池中删除。在挖区块过程中接收到的新incoming交易被放入交易池，在下一个区块中被挖。所 以当调用getTransactionCount并把“pending”作为第二个实参时，它不会看交易池里面；相反，它就认为该交易在待定区块里。

所以，如果想从不被geth管理的账户发送交易，就要计算区块链中账户交易的总数，并和交易池中的待定交易相加。如果想使用来自待定区块的待定交易，则不能得到正确的nonce，因为交易被发送给geth的间隔可能只有几秒，而平均需要12秒才能在区块链中确认交易。

在前一章中，我们用Hooked-Web3-Provider向交易中添加nonce。不幸的是，Hooked- Web3-Provider尝试得到nounce的方法并不正确。它为每个账户维护一个计数器，每次从该账户发送交易就增加计数。但如果交易是非法的（例 如，如果交易尝试发送比账户内更多的以太币），它并不能减少计数。因此直到Hooked-Web3-Provider被重置（即客户端被重置），该账户的 其他交易都在排队且不会被挖。如果创建多个Hooked-Web3-Provider实例，则这些实例不能彼此同步账户的nonce，所以最终的 nonce结果可能是错的。但是在向交易添加nonce之前，Hooked-Web3-Provider得到的总是到待定区块的交易计数器，并使用与计数 器相比较大的那一个。所以如果来自于Hooked-Web3-Provider管理的一个账户的交易是网络中的另一个节点发送的，并被待定区块接纳，则 Hooked-Web3-Provider能看到它。但是不能依赖整个Hooked-Web3-Provider计算nonce。这对于客户端应用原型机 制造很有益处，并适合在如果没有向网络广播交易且Hooked-Web3-Provider经常重置用户，就可以看到和重新发送交易的应用中使用。例如， 在钱包服务中，用户将频繁地上载页面，所以经常创建新的Hooked-Web3-Provider实例。如果交易没有被广播、不合法或者没有被挖出，那么 用户可以更新页面并重新发送交易。

来源：我是码农，转载请保留出处和链接！

本文链接：http://www.54manong.com/?id=554

'); (window.slotbydup = window.slotbydup || []).push({ id: "u3646208", container: s }); })();

'); (window.slotbydup = window.slotbydup || []).push({ id: "u3646147", container: s }); })();