一个例子是运行系统使用风险更高的资产和提高整个系统的债务上限。Cream Finance 是 Compound 的一个复制品，它加入了许多低成长的 DeFi 代币，而且不设债务上限，来吸引用户和体量。但是，FTT 代币存款最终构成了 Cream 内存款的 40%，大幅提高了这个协议的风险。如果 FTT 价格暴跌，Cream 上的出借人可能会损失资产。解决 GEV在传统公司里面，GEV 的预防机制有保守派势力，还有监管者和集体诉讼，作为遏止爆破行为的大棒。但这些可没法翻译成智能合约（其逻辑都是提前编程好的）。在一个链上世界，治理程序必须预先编程好，并且有遏制作恶的激励机制，因为我们都 知道，没有中心化的机构能在爆破后为我们主持正义。分散权力 —— 多签名和代币投票在安排谁来治理协议这件事情上，有很多考量。仅安排一个所有权账户，对开发者来说是最方便的，升级这个协议只需要一把密钥，而且也无需与其他时区的私钥持有者或无动于衷的代币持有者协调。开发过程只需单方面投入，可以很快，但用户就必须信任这个私钥的持有者。多签名控制和代币投票制对于更成熟的协议来说是更好的选择，可以获得更广泛的共识。虽然在现实中，如果开发团队自己控制了对大部分投票代币，系统还是会回到独裁模式或者联盟模式中。不设或者有限的合约可升级性早期的智能合约都尝试取得字面意义的 “不可更改性”。

　　对合约的改变和升级是不可能的。如果合约出现了 bug，或者是让智能合约的开发变成像是在设计不可改进的硬件一样，都是很可怕的，就像没法修复的火星探测器一样。在不可升级的合约里加入新功能能需要用户自己迁移资金。从某个角度来看，这是一种特性（可以想象代码是不会变的），但也可以看成是一种可怕的用户体验黑洞（YAM 的用户不得不两次迁移他们的 token）。最直接的改进方法是设计一个最小化的升级空间，比如暂停功能，在 bug 被发现的时候是非常实用的，还有一些非常有限的参数。最灵活的设计是使用可升级的合约（组合），一个核心（代理）合约存储所有的数据，并引用一个可替换的合约来装载所有的业务逻辑。用户甚至不知道底层的合约被升级过，因此用户体验很丝滑（当然跑路也很丝滑）。时间锁治理程序的时间锁设计是为了给用户适应升级的调整时间。假设流动性很充分，时间锁可以让用户离开协议（假设他们不喜欢即将激活的变更）。出于这种利用，用户会希望设计更长的时间锁，这样他们既有时间了解变更，也有时间来反应，但更长的时间锁也会降低协议的灵活性。MakerDAO 就在很长时间里出于这个理由而拒绝加入时间锁。但时间锁也不是万能的：用户仅仅是在理论上能这么做，但不意味着市场上有这个流动性，让他们可以这么做。如果 Maker 的治理程序尝试剥夺 CDP 中所有的担保品，而 DAI 的流动性很低 —— 那想要获得 DAI 来关闭 CDP 的人就要自求多福了。而且，这还假设了所有用户都会一直监视着时间锁来防范恶意行为（ Compounder 说的就是你）。乐观许可作为时间锁的升级版，乐观许可让协议可以快速通过提案，除非有人发起否决。否决功能让协议的散户，即，使用这个协议但并不能参与治理程序的人，比如 DAI 的持有者、CDP 的持有者和 Uniswap 的流动性提供者，能够拒绝治理程序的提议。如果有足够数量的用户发起否决，那么时间锁就会延长，以让更多用户来支持或拒绝这个否决。结果是开发者也可以快速应变，但用户也有保护自己的办法。支持追索 —— 如果只有时间锁，恶意升级会导致大家挤兑、踩踏。现在用户用不着立即退出了。 (责任编辑：admin)