关于唯链雷神区块链，你可能还不知道的那些事儿（六）链上治理
本文是“关于唯链雷神区块链，你可能还不知道那些事儿”系列文章的第六篇。，您可以在文末找到前几篇文章的链接。
唯链雷神区块链的链上治理，指的是对执行某些链上关键操作进行表决，并在表决通过提交提案，由链上治理机构审核后执行的过程。对于唯链主网，其治理机构就是基金会执行委员会。这些关键操作可以是授权节点参与共识以及变更区块链网络参数，也可以是任何通过智能合约实现的链上操作。
图1，链上治理流程。
正如图1所示，链上治理涉及三个阶段：决策、审核以及执行。
决策过程是链上治理的首个环节，需要通过投票完成。投票可通过链上的智能合约来进行，也可以由治理机构在链下完成。链上智能合约投票可以最大程度上保证过程的透明性，通常涉及所有利益相关方。链下投票则可以作为链上投票的补充，具有更高的效率和灵活性。
审核阶段是链上治理的第二个环节。在这个阶段，任何投票通过的链上操作都会以提案的形式提交至治理机构审核。每个提案都必须获得治理机构大多数成员认可才能通过审核。这项安全措施旨在保护链上治理不被恶意攻击。例如，攻击者可以利用投票合约的漏洞来影响投票结果，导致恶意的链上操作通过表决。
执行阶段是链上治理的最后一步。一旦某个提案经由以上程序审核通过，任何人都能触发该提案在链上执行。
实现
图2，链上治理框架。
唯链提供了一个灵活的技术框架来实现所述链上治理。如图2所示，该框架的核心是Executor合约。在唯链主网和测试网上，该合约部署在以下地址：
0x0000000000000000000000004578656375746f72
当然，在一个客制化的唯链区块链上，Executor合约可以被部署在任意地址。具体可参阅本系列文章的上一篇。
决策阶段
如上所述，决策过程可以以两种方式进行，一种是通过投票合约，进行的链上表决；另一种是由治理机构成员在链下表决。考虑到决策过程的多样性，我们没有给出其技术实现。
审核阶段
提案审核是通过调用Executor合约中的propose和approve两个方法来实现的。只有经过授权的投票合约或者治理机构成员才能通过以下语句调用propose方法：
propose(target_contract_address, encoded_data)
在图2中该方法被标注为“1”，代表着向Executor合约提交提案。该方法的两个输入定义了一个链上操作，也就是在调用一个合约方法时，系统所需要的参数输入。参数encoded_data可通过以下代码获得：
//solidity
abi.encodeWithSignature(func_signature, arg1, arg2, ...);
每一个被提交的提案，都会存储在Executor合约中。每当成功调用propose方法后，合约会生成一个唯一的propsalID赋予提案，用以在以后的操作中标识该提案。当一个提案提交到Executor合约以后，治理机构成员们必须在一周内对其进行审核。每个成员可以调用approve方法（在图2被标为“2”）来通过对提案审核。
执行阶段
最终执行阶段由Executor合约的execute方法来实现。当某个提案得到治理机构多数成员（默认多数比例为三分之二）审核通过后，任何人都能调用execute方法，来调用 EVM 底层的call方法，执行提案内定义的链上合约操作。具体调用代码如下所示：
// solidty
target_contract_address.call(encoded_data)
作为一个安全标准，我们建议在编写目标合约时，把执行提案时会调用的合约方法设置成只能由Executor合约来调用。这样我们可以保证，链上治理操作只能在经过链上治理之后才能被执行。举个例子，让我们来看一下内置Authority合约中的add方法，该方法是用来增加新的共识验证节点。以下是实现该方法的一段代码
// solidity
require(msg.sender == executor(), "builtin: executor required");
我们可以看到，以上代码保证，只有Executor合约可以调用该方法。
投票合约管理
前文已经提到，如果是通过投票合约来发起表决，并且在决策通过后向Executor合约提交提案，该合约必须得到授权。Executor合约中包含了attachVotingContract和detachVotingContract两个方法来管理被授权的投票合约清单。
值得注意的是，这两个方法都只能被Executor合约来调用。这就意味着，向清单中增减投票合约，都需要通过链上治理来实现，以此保障投票合约管理上的安全和透明。
Demos
我做了两个demo来演示如何使用唯链提供的工具进行链上治理。代码的下载地址如下：
https://github.com/zzGHzz/ThorDemo6
https://github.com/zzGHzz/ThorDemo7
以上两个demo均在定制化的唯链区块链上运行，以便我能够使用治理机构成员的账号。区块链的配置信息可在customChainConfig.json文件中找到。在第二个demo中，我在该文件中增加以下额外的配置信息：
"ForkConfig": {
"ETH_CONST": 0
}
添加这条配置是为了让克制化的区块链能够兼容以太坊君士坦丁堡版本发布的EVM。以上配置告知系统在什么区块高度切换到最新版本的EVM。
请注意，你必须用本地Thor节点的master账户地址替换掉配置文件中的authorityAddress值，才能使demo能够顺利运行。master账户地址可通过以下命令获得：
thor master-key --config-dir
启动本地节点的命令可以在nodeLaunchCmd文件中找到，详情可参考我之前关于客制化唯链区块链的系列文章。
Demo中使用的工具
connex-framework
connex.driver-nodejs
Connex
thor-devkit.js
代码中的术语
approver / approvers - 治理机构成员;
authority - 内置Authority合约 ，用以管理共识验证节点清单;
executor - 内置Executor合约;
dummyVotingContract - 投票合约;
voters - 链上投票账号。
Demo1 – 添加验证节点
Demo1模拟了增加新的共识节点的链上治理过程，并假定决策过程已由治理机构成员在链下完成。链上治理最终执行的是Authority合约中的add方法。该合约是一个内置合约，并且部署在以下地址：
// Convert "Authority" to bytes and left pad zeros
0x0000000000000000000000417574686f72697479
Demo中涉及的操作包括：
提交增加共识节点的提案；
治理机构成员审核提案；
执行提案中链上操作。
输出
0. Check existence of new validator
address: 0x2a49980921dd25babbee592a685a54cb75acea35
listed: false
endorsor: 0x0000000000000000000000000000000000000000
identity: 0x0000000000000000000000000000000000000000000000000000000000000000
active: false
I. Propose proposoal of adding validator 0x2a49980921dd25babbee592a685a54cb75acea35
Tx Sender: 0xcb43d5d874893a67d94cdb0c28e2a93285f56ff0
txid: 0xf90d9695ef8fc8cdaaa22ff962ed90ad7c6944099d245b12cf24df0ada82fed0
proposalID: 0x1596231d71a49eb11cd1ac38332ab83cb5ba22bae26810f89b9f7241aa76f379
II. Approve proposal
Approver: 0xcb43d5d874893a67d94cdb0c28e2a93285f56ff0
txid: 0x3979bb4a0d9bf595092363609d366518b57842a9b4e4ad3b062ade6a380043a7
Approver: 0x7d350a72ea46d0927139e57dfe2174d7acaa9d30
txid: 0x43f84dfc5b160e5059ecf4bb2934949fdd3c9b88b9f9631ab7222786e31b67be
Approver: 0x62fa853cefc28aca2c225e66da96a692171d86e7
txid: 0x1e2e389caa674a3ade32232574466538cd33710781d8bf75a1b744ecaec641e5
III. Execute proposal
TX Sender: 0x7d350a72ea46d0927139e57dfe2174d7acaa9d30
txid: 0x1f8a44ba88a135c8ab3de2c2acfe3678cc2e671751f2d99a29e8c80d98d56a70
IV. Check new validator status
address: 0x2a49980921dd25babbee592a685a54cb75acea35
listed: true
endorsor: 0x5e4abda5cced44f70c9d2e1be4fda08c4291945b
identity: 0x000000000000000000000000000000000000004e65772056616c696461746f72
active: true
Demo2 – 对区块奖励比率进行调整
Demo2模拟了调整区块奖励比率的链上治理过程。为了实现链上治理的三阶段，我在链上部署了一个测试用投票合约，叫DummnyVotingContract，用来实现链上决策过程。该次链上治理所要执行的操作是内置Params合约中的set方法。该内置合约被部署在以下地址：
// Convert "Params" to bytes and left pad zeros
0x0000000000000000000000000000506172616d73
Operations carried out in the demo (functions that implement the operations are listed in brackets):
Demo中涉及的操作包括：（括号中为实现操作的函数名）
在内置Executor合约中授权投票合约：
部署投票合约（deployVotingContract）
提交授权投票合约的提案(proposeAttachingVotingContract）
审核提案（approveProposal）
执行提案（executeProposal）
通过链上投票进行决策：
发起一个投票（initVote）
投票计数（tallyVote）
向Executor合约提交一个调整区块奖励比率的提案（executeVote）
审核投票合约提交之提案（approveProposal）
执行投票合约提交之提案（executeProposal）
输出
executor address: 0x0000000000000000000000004578656375746f72
0. Check current reward ratio
Reward ratio: 30%
I. Register deplyed voting contract
I.1. Deploy voting contract
TX Sender: 0xcb43d5d874893a67d94cdb0c28e2a93285f56ff0
txid: 0x4acbdb3ddf094dcaa4178c173ab4b586b688fb39a89a3dae78d627aab9c9a14a
Address:0x69da604675b7ad6249cc5e7093ced212ded74eec
I.2. Propose to attach deployed dummny voting contract
TX Sender: 0x7d350a72ea46d0927139e57dfe2174d7acaa9d30
txid: 0x70fd5498354d5b8640afbccde15f60da20559bb8e61125b2a09cd5db3c3c2419
proposalID: 0xbf04e4cf2b6e208e965007f9add1b0937b46199e033100556772ccc239ef9164
I.3. Approve proposal
Approver: 0xcb43d5d874893a67d94cdb0c28e2a93285f56ff0
txid: 0x26dde198e6eeb5fb43f4c8ce402c9e8201446853ddd3b63f7ffcf860c985b64d
Approver: 0x7d350a72ea46d0927139e57dfe2174d7acaa9d30
txid: 0xe206405d21728a67d93cfd5222770f465ceb179f21e1274fc959a5c3a94b1a46
Approver: 0x62fa853cefc28aca2c225e66da96a692171d86e7
txid: 0x8e79ece9b96d8824d3ff80ee4f91663376f32b1043a761deec7ce132b95f7a11
I.4. Execute proposal
TX Sender: 0x62fa853cefc28aca2c225e66da96a692171d86e7
txid: 0x315c8ca567b42f9bd781d16c85e7cc3c1204b95d3b43e5e34ba440c2728538be
I.5. Check whether voting contract has been attached
success
II. Make a decision through on-chain voting
II.1. Init vote to change reward ratio from 30% to 40%
TX Sender: 0xfa580a85722b39c500a514c7292e9e5710a73974
txid: 0x5ed03f252ee84f4d1c82eff4885e8be4a90b4c9d5fd9ebaad7d1a2e1257bbebf
voteID: 0xe5dd8e896836f357347fd8a0a158529f922d2ad4a8e398661cff3e2c467186e0
II.2 Tally
TX Sender: 0xfa580a85722b39c500a514c7292e9e5710a73974
txid: 0xb3808ba8882c66716085e8fa4342de69f1f780af98ed77abf107aad348c4bd1e
II.3. Submit a proposal of executing the voted action for final approval
TX Sender: 0xfa580a85722b39c500a514c7292e9e5710a73974
txid: 0x4799c33027a811fe5a5bc6f53ac521639e5e97fa2e7aa659b12116e6ebf5f918
ProposalID: 0xe3fa889f277820e9949c483d99bdd4fedd3847d02d6ba2ddcb51a966d4820503
III. Authorize voted action
Approver: 0xcb43d5d874893a67d94cdb0c28e2a93285f56ff0
txid: 0xfc392ec5549b5c90d2947a01d64376400449a2b998c0458a054751e3f9154aea
Approver: 0x7d350a72ea46d0927139e57dfe2174d7acaa9d30
txid: 0xd02115e7a5088613cf20ec8fb017c560fcc96cbd4c034b5f5d8e48cf92a16787
Approver: 0x62fa853cefc28aca2c225e66da96a692171d86e7
txid: 0x7e860c286b33ebea2347ca7359077b6419086784b77a022c322d22b91561291e
IV. Execute voted action
TX Sender: 0xfa580a85722b39c500a514c7292e9e5710a73974
txid: 0x77c7184cc19ccac557ce39ff31d4a60cb999031127b32d152d873d69ccfce30d
V. Check new reward ratio
Reward ratio: 40%
文章链接
关于唯链雷神区块链，你可能还不知道的那些事儿（第一篇）- 交易唯一性
关于唯链雷神区块链，你可能还不知道的那些事儿（第二篇）- 强制交易依赖性
关于唯链雷神区块链，你可能还不知道的那些事儿（第三篇）- 指定交易费用代付（VIP-191）
关于唯链雷神区块链，你可能还不知道的那些事儿（第四篇）- 挖矿获取额外交易Gas单价
关于唯链雷神区块链，你可能还不知道的那些事儿（第五篇）- 定制你自己的唯链雷神区块
