先重温一下三个基本原则:
账号的单边性----密钥持有者可以证明账户是自己的，也可以假装不是（遗弃账号）；
总体余额非负----相互绑定的账户总价值不能为负：其中可以存在负余额的账户，但总和必须为正。而不与其他账户绑定的单个账户，是不能出现负余额的。否则账号会被遗弃；
账户的非经济价值----之所以存在无抵押的纯粹信用贷，依靠的是大量“非经济”账户。一定程度上说，这些无变现价值的账户，成为了一种特殊的抵押物，
第一个模式中，借款的安全性是依靠在账号内放置抵押物的方式完成的。
基于抵押的借款
这种模式的一个明显的限制是，只能用于有明确经济价值的资产，比如各种token。
第二种模式：抵押账户的非经济价值
如果能认可账户的非经济价值，那么就有理由相信，即使账户的显性资产低于负债，只要它有足够的隐形价值，就不会违约。这也可以减轻对传统抵押物的依赖，实现“信用借款”。
第二种模式
链上的账号有哪些可能的隐形价值呢? 大概可以有这么几类
- 历史意义： 比如前N个区块的矿工账号（这甚至被认为是证明谁是中本聪的证据之一）；使用超过N年的账号（对标QQ号）；某些大型时间曾经使用的账号...因为区块链本身时间还比较早，这一块的价值才刚刚开始被大家认识。但是参考千年来对古董和收藏品的热情，相信会有越来越多的“历史意义”被挖掘出来；
- 账号特性： 比如以特殊字符开头的账号。有些人为了地址更容易被人识别，很早就开始专门生成一些这样的账号（类似QQ的生日号）。这类东西由于稀缺性也好，POW也好，应该是有一定价值的；同时，随着技术的发展和升级，可能会对某些部分做升级，可能某些feature会变成“限量”----比如以太坊未来要取消个人账户跟合约账户的区别，这会不会导致个人账户成为限量版？
- 外部权限： 以太坊的合约权限控制大部分都是按照账号来做的，也就是说，某些账号可能成为了其他项目/DAO的“owner”，“admin”，“abitrator”，“board member”，“contributor”。这给了这些账号一些普通账号不具备的权限----比如某机构的决策需要这个账号同意才能生效，更极端的例子，这个账号可以增发某token。这些权限显然有某种价值。
账号的隐形价值
以上只是目前能看到的一些例子，随着币圈的发展，应该还会有更多的隐形价值被创造出来，这些都使得了账号本身可以成为非常好的抵押物---即使它本身并不存在什么直接的显性资产。
为了完成这一点，我们可以一开始在定义账号的时候，就在里面预留一个“可抵押”接口---这种抵押并不是针对任何资产，而是针对账户本身：
- 没有抵押的情况下，账户可以像普通账户一样任意使用；
- 如果设置抵押，账户的操作就受到限制，需要抵押权人批准方可执行；
- 还款可以自动解除抵押；
- 到期不能还款，账号控制权转给抵押权人（有点类似典当）；
比如下面的合约就能实现这些简单功能（伪代码，别纠结语法）：
contract pledgable{
address owner;//控制人
address pledgee;//抵押权人
uint debtAmt;//债权金额
date deadline; // 到期时间，如果到此时还没有解除抵押，抵押权人获得账号控制权。
string status; //当前状态
//这三个变量用来对外发送任意请求；
address requestContract;
string requestFunc;
bytes requestParam;
modifier onlyOwner{//只有控制人能执行的函数
require(msg.sender==owner);
_;
}
modifier onlyOwner{//只有抵押权人能执行的函数
require(msg.sender==pledgee);
_;
}
function pledged(){ //新建
owner = msg.sender;
status="unpledged";//尚未抵押
}
function setPledgee(address _pledgee, uint _debtAmt, date _deadline) onlyOwner{ //前一次抵押解除后
//这个账户可以被再次抵押给不同的人；
require(status=="unpledged");//只有解除当前抵押以后才能修改；
pledgee=_pledgee;
debtAmt=_debtAmt;
deadline=_deadline;
}
function register() payable{//抵押权人支付一笔借款金额，这个账户被用作抵押；
require(msg.sender=pledgee);//确认抵押权人；
require(msg.value=debtAmt); //确认金额
pledgee.transfer(debtAmt);//金额转给控制人账户（其实不一定这样做）
status="pledged";
}
function funcRequest(address _requestContract, string _requestFunc, bytes _requestParam) {//抵押权人请
//求发送指令
requestContract=_requestContract;
requestFunc=_requestFunc;
requestParam=_requestParam;
if(status=="unledged") // 如果没有抵押，直接运行。否则等批准
sendRequest();
}
function approve() onlyPledgee{ //批准发送对外请求，只有抵押权人能做
sendRequest();
}
function sendRequest() internal{ //发送请求
contract.func(param);//这只是个伪代码。实际的代码比较复杂，可以参考uport的实现
requestContract=0;
requestFunc="";
requestParam=0;
}
function release() payable onlyPledger{ //抵押权人还款并解除抵押；
require(debtAmt==msg.value); //确认还款金额
pledgee.transfer(debtAmt); // 将这笔还款转给抵押权人
pledgee=0;
status="unpledged";// 改变状态
}
function foreclose() onlyPledgee{ //到期未能赎回，账号归抵押权人所有；
require(today > deadline); //确认已经到期；
owner = pledgee; // 账号变成抵押权人的了；
status="unpledged"; //因为所有权已经转移，也就不存在抵押了。
}
}
如果Alice有一个可抵押账号A，
在这一种模式是，我们实现了一个不依赖显性资产抵押的借贷模式。
账号的隐形资产成为了借贷的基础。
这种模式也有一定的局限性，最大的限制是要求一个账号拥有足够的隐形价值。
待续...
下一部分会讨论如何增加账号的隐形价值
