### 背景：

先声明一下，该解决方案所针对的链下服务的特点是：服务的价值与时间成正比，服务提供方可以随时停止服务。如某软件的会员服务。

该解决方案想要解决的痛点是，在传统交易方式中，交易的成交需要依靠购买者对服务提供者的信任。因为服务提供方同时控制着**资金**和**服务的提供与否**，服务提供方完全可以携款跑路。同时，如果购买者对该服务不满意，也常常无法立即退款。

总的来说，购买者处于被动状态，该解决方案目的是去信任化，将双方放在平等的位置。这对于服务提供者来说并非是一件坏事，去信任交易可以让购买者可以大胆地购买，只要服务价值与收费标准相匹配，我认为这会加大服务提供者的收益。

<br>

### 解决思路：

用智能合约实现费用收取逻辑。

1. 服务提供者在智能合约中，设置好收费标准；
2. 用户存入资金，表明购买链下的服务；
3. 服务提供者监听到链上事件，然后链下为该用户提供服务；
4. 在服务的过程中，链上的资金会随着时间按照收费标准“流”给服务提供者；
5. 如果用户的资金不足，则服务提供方应当停止链下的服务；
6. 如果服务提供者跑路，则用户可以提取资金，不再支付更多的费用；

这是基于**博弈驱动**的方式，购买者控制着链上资金，服务提供者控制的链下服务。一方的行为受另一方的行为的影响，也能影响着另一方的行为。


<br>

### 费用曲线：

智能合约中的收费标准由“费用曲线”定义，费用曲线是一个分段的线性函数。


// feeCurve示例:
// 第一年，按$100每月算 38*30*24*60*60 = 98_496_000
// 第二年，按$80每月算 31*30*24*60*60 = 80_352_000
// 两年后，按$50每月算 20*30*24*60*60 = 51_840_000
// feeCurve[0] = FeeCurveUnit(38, 365 days); // k1=38, t1=365days
// feeCurve[1] = FeeCurveUnit(31, 2 * 365 days); // k2=31, t2=2*365days
// feeCurve[2] = FeeCurveUnit(20, type(uint256).max);// k3=20, t3=无限

<br>

合约中会维护着购买者的接受服务的总时长。

假如上次结算时，累计接受服务时长为ta。然后在本次结算时，累计接受服务时长为tb。那么本次结算服务提供者获取到的费为：$(t1-ta) * k1 + (tb-t1)*k2$


> 具体实现细节可看代码，下面会给出仓库链接

<br>

### 下一步计划：

1. 了解更多的需求，适当添加有用的功能；
2. 该解决方案比较依赖前后端，让服务提供者可以得知链上信息，以决定链下的服务行为。如果方案没问题，可以进一步考虑前后端的实现；
3. 待思路.... (好吧，对后续的发展思路还是比较模糊)

<br>

智能合约方面：

目前合约是有了基本的原型，实现必需的功能。有个修改费用曲线的功能，个人觉得挺有用的，但对于当前正在使用的用户，不知道该怎么计算费用合适。（所以目前是没有费用曲线修改逻辑的）

然后对已有的代码进行了单元测试，不过这对合约中的复杂逻辑还远远不够。目前想的是，等后面功能完善了，再进行不变测试。

> 仓库地址：https://github.com/narnona/TrustFlow

<br>

### 最后：

欢迎对这个想法感兴趣的朋友一起交流或提建议，可以直接在[X](https://x.com/0xkaka1379)私信我。

<br>