# 减法协议中的函数和资产

By [0xKJ](https://paragraph.com/@0xkj) · 2024-01-29

---

_减法理论_ 给我们带来了区块链认知上的极大提升，如果说智能合约是给 _比特币做加法_，那么 [铭文空间](https://mirror.xyz/0x719C8d75FAF8f1b117EA56205414892CAAb4A1b7/aqgDkgHhnJfQJj11dkwaa8wCBqpFjDDxMqKVdDWp3DI) 就是给 _比特币做减法_。对交易做排序和共识是所有区块链的必备功课，所以 _减法理论_ 可以适用于所有公链，铭文空间天然具有跨链的特性。

当我们开始思考 减法协议，它给我们带来了极大的设计空间，也让我们有机会重新思考 EVM CALLDATA 的不足以及安全隐患。首先，铭文，比如 BRC20，实际上是“明文”，而 CALLDATA 的可阅读性则差了很多。铭文协议的设计应该遵循这一原则，从协议层面让**用户知道自己在做什么**。

![明文 vs CALLDATA](https://storage.googleapis.com/papyrus_images/3671860ef96579d090e78f41e7ed6909a793c48e95db8d08af84f0886a0be684.png)

明文 vs CALLDATA

我们思考的第二点，是智能合约的范式。智能合约让每个区块链应用，拥有自己的一亩三分地，用来定义数据和代码。用户资产就是数据，代码可以操作数据，比如转账，mint 和 approve。对于那些常用的合约，比如 USDT，实际上代码经过了长时间以及无数双眼睛的验证。然而区块链上有上千种资产，即使大部分资产都遵循 ERC20 标准，但是标准实现并不是强制的。早期，很多合约因为重大安全问题直接报废。随着工程师们经验的增长，重大安全问题越来越少见，但是用户依然不可能靠自己的力量审计所有智能合约。思考这一现象背后的本质，实际上是因为智能合约允许发布者自定义合约的所有代码，很少直接重用现有代码（复用也是通过复制粘贴），造成了链上安全实际上的黑暗森林。

减法协议的设计，尝试修复这一点，我们把编程语言中的基本元素，函数 function，和区块链中的基本元素 资产 asset 概念独立出来。在智能合约中，合约代码处理合约资产，而在减法协议中，函数具有操作某个资产的权限。比如 transfer 具有操作所有资产的权限，这使得人们无需为每个资产重新编写所有代码。对于 mint 方法，则需要更高的定义自由，meme 资产的mint 逻辑与 USDT 资产的方式逻辑必然不同，需要编写特定的 \[asset\]\_mint 函数。

另外，函数还有一个 require 属性，更加静态的指定了函数依赖的其他函数，并且在调用过程中，对调用函数可以操作的资产类型做更细致的限定，以提升安全性。

第三点，我们一直很喜欢 ERC6551 的思路，但是由于 6551 的出现晚于 ERC20，所以所有的 ERC20 都无法让资产绑定在一个 NFT 上，只能由以太坊地址来持有。地址就像公钥，和私钥是一对一绑定的。假设我怀疑自己的私钥已经不安全了，当尝试更换私钥，就意味着必须同时更换地址（用户名）。在以太坊上更换地址，用户需要将所有资产转移到新地址，这需要花费一笔不小的 gas 费用。所以我们认为，用户更换私钥的安全代价会很高。

在减法协议中，我们可以从协议设计上改进，我们允许资产被一个“名字”持有，“名字”可以绑定地址。所以，更换私钥无需更换“名字”，以降低经常更换私钥的成本。

我们正在设计和实现 **减法协议**，它是一个在 _减法理论_ 指导下的跨链铭文空间。我们的进度非常乐观，从 Minus Theory 到 Minus Protocol demo 运行只花了一周时间。

近期有望在测试完运行！敬请期待。

---

*Originally published on [0xKJ](https://paragraph.com/@0xkj/F4Q4ogoGEpwNHFB9rNGV)*