了解过以太坊的同学一定对ERC20代币不陌生了, 本文主要聊聊ERC20代币的锁仓
ERC20代币锁仓现状
大部分区块链公司已经发布了数字货币，为了体现团队信心与决心，白皮书里都会提到团队所持有的代币要锁仓（给代币加上冷冻期，一般是1-4年）。
但是最后这些代币真的锁仓了么，锁仓是谁来监督呢 ?
就目前发布的ERC20来看，国内大部分ERC20代币白皮书中提到的锁仓并没有体现在智能合约中，而是团队自行约束来实现人肉锁仓，这显而易见是非常不科学的。
通过智能合约锁仓
科学的锁仓方式当然是通过智能合约来实现，这是更可信、公开、且不可串改的最佳方式
技术实现的基本思路如下
- 发布ERC20代币智能合约
- 配置锁仓合约参数, 发布锁仓的智能合约
- 把要锁仓的ERC20代币转入锁仓智能合约
1，3比较简单本文不讲了，关键是2，如何编写一个锁仓智能合约。
目前锁仓智能合约分成两种
- TimeLock
- Vesting
下面分别介绍下两种锁仓方式
1，TimeLock 锁仓方式
合约接受3个参数
- ERC20Basic _token : 锁仓的ERC20合约地址
- address _beneficiary: 受益者的合约地址
- uint256 _releaseTime: 锁仓时间（单位秒）
这种TimeLock锁仓方式简洁明了
_releaseTime 时间到了之后调用 release() 就会把token发放到_beneficiary的账户中。
不过TimeLock方式有局限性
例如需求是：锁仓4年，1年之后一次性解冻25%，后面按时间线性解冻
这样复杂的锁仓需求 TimeLock是搞不定的，这时候就要用 Vesting 方式
2，Vesting 锁仓方式
代码参考 : ERC20/TokenVesting.sol
Vesting 锁仓方式主要解决的是有断崖时间和持续锁仓时间的锁仓场景
合约初始化接受 5 个参数
- address _beneficiary : 收益者地址
- uint256 _start ： 起始时间
- uint256 _cliff ：断崖 表示 「锁仓4年，1年之后一次性解冻25%」中的一年
- uint256 _duration, 持续锁仓时间
- bool _revocable 是否可回收 （主要场景是公司给了员工A 10K 代币锁仓4年，A在工作一年的时候离职了，剩余的部分公司是否可回收）
为了更容易理解_cliff我们看下面的例子
如果 _cliff=半年 ，_duration=1年 具体解冻情况如下
- Month 1: I get 0 tokens
- Month 2: I get 0 tokens
- Month 3: I get 0 tokens
- Month 4: I get 0 tokens
- Month 5: I get 0 tokens
- Month 6: I get 0 tokens --- End of cliff
- Month 7: I get 700 tokens (7/12th)
- Month 8: I get 100 tokens (8/12th)
- Month 9: I get 100 tokens (9/12th)
- Month 10: I get 100 tokens (10/12th)
- Month 11: I get 100 tokens (11/12th)
- Month 12: I get 100 tokens (12/12th)
这样通过 _cliff 就实现了我们上面提到的需求
总结
以上是我分享的关于ERC20锁仓的实现原理，希望能帮助大家更理解ERC20代币以及以太坊的智能合约
