想必CN社区很多小伙伴对HP委派 (HP delegation，有时候也会被翻译成HP代理)都不陌生，并且知道如何操作HP委派，但是也有一些小伙伴知其然不知其所以然，甚至还可能操作出错。
(图源 ：pixabay)
先来定义一下这个概念，HP委派 (HP delegation)简单地讲就是:
委托人(delegator)将股权(vesting_shares)委派给受托人(delegatee)，股权(vesting shares)仍由原始账户（委托人）所有，但是投票权(点赞)、投票收益以及资源(RC)分配等权益被转移(委派)给受托者。
需要额外强调一下的是，治理票的权益不因HP委派而转移，转移治理票权的操作叫做设置投票代理(Set Voting Proxy)，这里的投票指的是治理票(见证人投票、提案投票)，所以也常被称作见证人代理。
接下来，我和大家一起学习一下HP委派 (HP delegation)的操作、取回、调整数额，并通过分析代码，了解一下HF20后HP委派的取回时间，最后再分享给大家一则小故事(事故）。
我们可以在网页钱包、命令行钱包或者编写代码通过程序进行HP委派：
网页钱包为例：
命令行钱包示例如下：
delegate_vesting_shares oflyhigh.test oflyhigh.demo "2000.000000 VESTS" true
我们会注意到网页钱包以及命令行钱包操作对象上的区别，其实本质上它们操作的都是股权(vesting_shares)，网页钱包用HIVE(实则应是HP)，是为了让操作看起来更直观一些。
另外需要注意的是，HP委派有最小值要求，代码中提现如下：
这是个问号表达式，你能读懂嘛？简单来讲，HF20以后，HP代理可操作的最小数值是账户创建费的三分之一，以当前为例，就是1HP哦。
低于这个数值，就会引发如下错误信息：
"Assert Exception:op.vesting_shares >= min_delegation: Account must delegate a minimum of {"amount":"1731604612","precision":6,"nai":"@@000000037"}"
之前我们通过命令行从
所以，我们可以通过点击REVOKE来取消HP委派：
看图可知，其实取消HP委派，就是将委派股权的数值调整为0。
命令行钱包中操作如下：
delegate_vesting_shares oflyhigh.test oflyhigh.demo "0.000000 VESTS" true
除了全部取消以外，我们还可以部分取消，详情见下边HP委派的数额的调整。
很多新老朋友容易犯的一个错误就是在调整数额的过程中，以为使用差值就可以。
比如之前
很多朋友可能会觉得，已经委派过去2000 VESTS，那么再委派过去3000 VESTS，不就完结了嘛？
所以命令行钱包会写出如下指令：
delegate_vesting_shares oflyhigh.test oflyhigh.demo "3000.000000 VESTS" true
但是使用我的HP委派检查工具检查一下，就会发现我们只委派过去3000 VESTS：
所以需要注意，命令行钱包也好，HIVE.BLOG的网页钱包也罢，委派操作都是指要委派的数值，而不是差值哦，千万别搞错了。（其它钱包以钱包实际情况为准）
另外需要补充的是，相对于HP委派数额增加，这个数额也可以减少，所谓的减少其实就是部分取消（减少至0就是全部取消啦）。
前边我们学习了如何取消HP委派，那么取消后，HP(以及相应权益)是不是马上回到自己的账户呢？答案是否定的！
HP委派的取回时间由如下代码决定(在HP委派数额减少的对应逻辑中）：
_db.create< vesting_delegation_expiration_object >( delegator, delta,
std::max( now + gpo.delegation_return_period, delegation->get_min_delegation_time() ) );
也就是当前时间+ gpo.delegation_return_period，delegation->get_min_delegation_time()两者之间的最大值。
而关于delegation->get_min_delegation_time()有两种情况：
一种是创建账户时委派HP(account_create_with_delegation_operation):
_db.create< vesting_delegation_object >( creator, new_account, o.delegation,
_db.head_block_time() + HIVE_CREATE_ACCOUNT_DELEGATION_TIME );
因为这个操作现在已经很少被使用，而且也不是我们主要要讲解的，所以姑且先不去讨论。
另一种就是普通的HP委派（delegate_vesting_shares_operation）：
_db.create< vesting_delegation_object >( delegator, delegatee, op.vesting_shares, now );
不难看出，这里的min_delegation_time就是创建HP委派的时间点，所以普通HP委派取消后的取回时间就是 now + gpo.delegation_return_period
而这个时间在HF20后为：
gpo.delegation_return_period = HIVE_DELEGATION_RETURN_PERIOD_HF20;
相关数值定义为：
#define HIVE_VOTING_MANA_REGENERATION_SECONDS (5*60*60*24) // 5 day
#define HIVE_DELEGATION_RETURN_PERIOD_HF20 (HIVE_VOTING_MANA_REGENERATION_SECONDS)
综上所述，HP委派取消后回归账户的时间为5天（我没记错的话，HF20之前，HP代理取回时间为7天呢）
假设你有101W HP想委派给A账户，你先委派了100W HP到A账户，后来发现自己账户上还剩1W HP，所以又委派了1WHP到A账户。
按照我们之前讨论的结论，想到达上述目的，正确的操作应该是委派101W HP到A账户，而上述错误的操作实际效果就是将99W HP委派取消，只保留1W，和设想大相径庭。
当你意识到这个错误，想纠正时，发现HP代理取回要5天才能到账，也就是说，有99W HP白白地在路上卡五天，不产生任何收益哦。
而当前行情下，100W HP的满赞大概会有约$10的点赞收益，每天就是$100，卡在路上5天，可就是白白损失了500美元哦。这损失可是不小呢。这是故事还是真实发生的事故呢？你们猜猜看。