金色观察 | 编程语言如何推动DeFi成为主流？

金色财经 区块链11月27日讯 随着DeFi的快速增长，提供DeFi服务的平台和产品也如雨后春笋般纷纷冒头。作为衡量DeFi协议管理资金规模的标准之一，DeFi“总锁仓量”在过去两年一路从100亿美元增长到超400亿美元，期间更是一度冲上1800亿美元的巅峰。但直到今天，智能合约编程语言功能并没有足够完善到可以安全地创建和管理资产。面对这头“房间里的大象”，我们无法选择视而不见，因为DeFi要想称为主流，编程语言就必须要具备“资产导向”功能，只有这样DeFi智能合约的开发才能更加安全和直观。

截至 2022 年 11 月，DeFi 的总锁仓量。数据来源： DefiLlama

DeFi编程语言尚未融入“资产”概念

要想解决DeFi常年遭受黑客攻击的问题，编写“审计代码”就是一个很好的方法。如果细数历史上规模最大的十次DeFi黑客攻击，那么你会发现其中有9次都是由“未审计”惹的祸。所以从某种程度上来说，审计的确是一种避免攻击非常有效的方法。假如没有审计，那么即便在黑客攻击问题上投入再多的资源也无济于事。这就好比为了解决一辆方形轮胎汽车的性能问题而安装大量发动机一样，这样做虽然可以让它跑得更快一些，但是没有找到突破性能的关键点。

同理，如今的DeFi编程语言，比如Solidity，并没有融入“资产”这个概念。代币、NFT这类资产仅仅只是智能合约中的一个变量（可以被更改的数字，如以太坊的ERC-20），而至于这些变量该如何被保护以及被验证则需要开发人员对每个智能合约进行重新定义。比如，该变量不应被使用两次；不应被未经授权用户耗尽；转移时应该始终保持平衡且净值为零。。。。。。

随着智能合约变得越来越复杂，所需的保护和验证也正在变得越来越复杂。然而，人无完人，金无赤足，发生错误在所难免，资产也会因此而丢失。就连DeFi领域最佳蓝筹协议之一的Compound也无法幸免于难。2021年9月，Compound智能合约中的一个Bug导致其错误分发了8000万美元代币，原本应通过该合约缓慢分发给所有流动性提供者的COMP代币被错误释放，部分用户收到了远高于正常数量的代币。

连锁反应

智能合约之间的交互（如代币之间的交换）是通过发送消息到各合约来实现的。智能合约在收到消息之后会更新其内部变量列表，而结果则反映出了一个较为复杂的平衡过程。至于智能合约之间的所有交互是否能正确处理则完全取决于DeFi开发人员。由于Solidity和以太坊虚拟机（EVM）在设计初期没有考虑到防护问题，因此DeFi 开发人员必须在后期通过一定的设计来确保必需的防护和验证。

为了降低安全风险，DeFi 开发人员几乎将所有时间都花在了确保代码安全上。那些开发人员表示，他们在写完代码后一定会进行反复仔细检查，甚至不惜花费高达90%的时间进行验证和测试，而只留下10%的时间在构建产品性能和功能上。令人费解的是，开发人员将自己的大部分时间都花在了与不安全代码作斗争上，再加之开发人员短缺，DeFi为何还能发展得如此之快？

很显然，尽管当今的可编程化货币存在着风险和挑战，但这种能够实现自我主权、无需许可以及自动化的可编程化货币仍然是无法阻挡的大趋势。我们可以想象一下，假如DeFi开发人员能够将他们的生产力集中在开发产品功能性方面而不是整天忙于处理各种漏洞，那么该有多少创新力量可以被释放出来。这种创新很可能会带来一个惊人的结果，那就是使一个刚刚起步的460亿美元行业颠覆一个468万亿美元的全球金融大行业。

2002年至2020年全球金融机构总资产。资料来源：Statista

创新与安全

DeFi要想做到既创新又安全，关键一点在于要为开发人员提供一种简单的方法来创建资产并与其进行交互，与此同时将基本功能转换为编程语言的原生功能。最重要的是，创建的任何资产都应始终具有可预测性并符合常识性财务原则。

其实，在以资产为导向的编程范例中，创建资产就像调用原生功能一样简单。平台知道什么是资产，比如 .initial_supply_fungible（1000）创建了一个固定供应量为1000的同质化代币（除了供应之外，还有更多的代币配置选项可用），而.take和.put等功能则从某个地方获取到代币后再将它们放置在其他地方。

在以资产为导向的的编程中，任何人都会很自然地期望有关DeFi的基础操作已包含进了该语言的原生功能，而不是开发人员通过编写复杂的程序来指示智能合约用错误检查来更新变量列表。在这种情况下，有了以资产为导向的编程来做保证，代币就不会丢失或被耗尽。

以上就是在DeFi领域获得创新和安全性的方法。只有一切以资产为导向，来自主流的看法才会又所改变，人们也才会从远远观望这个令人生畏的DeFi转变为争先恐后地要将自己的资产投入其中。不然，你就输了。

本文部分内容编译自cointelgraph