update DMC20 documents

Author: waterflier

doc/DMC20 经济模型.md

@@ -0,0 +1,191 @@
+# DMC20 核心经济模型设计
+
+相比DMC，DMC20的经济模型会更加简洁。希望通过一些简单的，可博弈的公式让每个人都能用自己的方式和策略，充满信心的加入到去中心存储市场中来。经济模型设计引导的博弈是阳谋，在推动整个去中心存储生态的算力规模增大的同时，推动DMC20价格的上涨。
+
+## DMC20 挖矿的基本流程
+
+### 存储交易市场挖矿
+
+1. 出售存储资源的用户被称作供应商，可以挂卖单，卖单应详细的描述其存储资源的定义和价格。约定：
+
+- 存储总大小，
+- 存储单价（定价单位从0.125到8,单位是GWT(Gb per Week Token）
+- 存储有效时间（系统规定最小有效期为24周），
+- 单次购买的最小大小(需小设置为2GB)。
+- 存储质量
+
+2. 挂卖单时矿工用GWT缴纳质量保证金，用来在存储出现问题时赔付给用户。
+
+```
+保证金总额 = 卖单总空间*有效时间*单价*质保比率
+```
+
+系统有要求最小质保比率(0.5)，用户可以根据实际的市场竞争调高该保证金。存储价格，质保比率会影响供应方在算力奖励里的比率。
+比如用户有100G空间，挂单24周，价格是2，质保比率是0.5,那么在挂单时，矿工需要准备好 100*24*2*0.5 = 2400个GWT的质保金。
+
+3. 有需求的用户（需求方）可以选择一个已挂单购买自己需要的空间
+
+```
+存储费用=需求空间*剩余有效时间*单价。
+```
+用户并不能选择有效时间。当一个存储订单的剩余有效时间小于系统的最小存储有效时间时，用户无法购买该存储订单。为了降低GAS Fee，用户在购买空间时应设置数据的MixHash.
+
+4. 已成交订单进入等待（数据）状态。数据交付的流程是需求方首先根据供应方公开的账号信息，通过链下协议将数据传输给供应商。供应商收到数据后调用合约接口确认该数据的MixHash。此后订单进入交付状态。
+
+5. 未进入交付状态的订单双方都可以随时取消。取消后，用户会立刻得到退款，矿工则是回复了该存储订单的空间。
+
+6. 订单进入交付状态12周后，可以调用“提现操作”，提现操作会让供应方得到收入+算力奖励GWT，让用户得到算力奖励GWT。此时系统会在该过程中抽取一部分交易费用GWT。
+
+7. 矿工可以随时减少卖单的有效剩余空间。有效剩余空间减少后，矿工会得到退还的质保金。
+
+8. 当矿工发现数据丢失时，可以主动声明数据丢失。此时只会赔付给用户质保金的80%，并拿回剩余的20%。
+
+9.	供应方因为正常的技术理由可以申请订单请假（请假的频率基于有效长度有最大限制），订单请假期间其无法发起存储挑战。供应方可以在主动调用合约接口将请假状态的订单恢复正常。
+
+10.	存储订单可以协议取消（一方发起，另一方同意），此时双方都会得到剩余交付时间的退款。
+
+11. 使用官方的挖矿软件不会碰到其它异常情况，因此本文不讨论存储挑战等情况下的经济模型
+
+### 公共数据挖矿
+
+我们不提供公共数据挖矿的自动挖矿程序，公共数据挖矿更像是GWT持有者参与的另一个挖矿游戏。
+
+从DApp的角度来说，公共数据挖矿的流程是：
+1. 安装DApp
+2. 在DApp的网页中配置存储空间
+3. 通过质押GWT来获得有效的公共数据存储空间，目前该值为有效空间*16*64，也就是说获得1G的有效公共数据存储空间，需要质押1024个GWT.
+4. 浏览公共数据，选中公共数据后尝试SHOW Proof来获得GWT
+5. SHOW Proof会冻结（质押）一定数量的GWT，数量和SHOW成功后的回报有关。用户可以在SHOW之前通过DAapp的界面来决定质押的数量
+    需要额外冻结的GWT一般与SHOW成功的回报有关。SHWO成功得到的回报越大，则需要冻结的GWT越多。
+6. SHOW Proof会将公共数据的MixHash加入用户的公共数据持有列表，并消耗有效公共数据存储空间。
+7. 用户可以随时释放公共数据来获得更多的有效公共数据存储空间
+8. 通过释放未使用的公共数据存储空间，用户可以拿回质押的GWT
+
+DApp提供了一系列API，可以让有技术的玩家制定更符合自己需要的策略来自动的玩公共数据存储挖矿，赢得更多的收益。
+
+## 算力奖励
+
+算力奖励的是GWT
+奖励的基本逻辑是：系统流通的GWT总量，要比系统的总存储能力略高。因此随着系统里存储能力的增加，GWT需要增发。
+
+```
+奖励 = 持有算力* 存储质量比率 * 系统挖矿难度比率 * 时长 
+```
+
+简单的说，1个100G的存储空间，1周获得的奖励是 100GWT *（存储质量比率 * 系统挖矿奖励比率）
+存储质量比率和当前订单的 质押率和单价 有关。质押率越高，单价越高，质量存储比率越高。其取值范围是：0.05-8
+系统挖矿奖励比率是系统当前的参数，与系统本周期的总算力增长率，GWT的总发行量，供需关系有关。系统算力增长越快，挖矿奖励比率越高。其取值范围是：
+两个比率函数的最后都进入了一个平滑函数，用于限制最大值和最小值。并且通过曲线，我们把最佳收益点放在了价格为1，质押率为2的状态。（假1陪2）。系统增长率
+
+系统的算力增长率每时每刻都在变化，从简化计算的逻辑来说，我们使用简单的平均数算法来得到一个近似值。
+算力增长率 = （上一次提现时的算力增长率 + 提现时的算力增长率） / 2
+长期来看，算力增长率是一个逐渐下降的函数。，因此，尽量减少提现次数能更好的吃到算力增长率早期较高的红利。
+
+核心算法如下：
+
+```python
+def reward(self, capacity, duration,is_supply,order):
+    # duration的单位是周
+    return capacity * duration * get_quality_rate(order) * get_mining_rate(is_supply)
+
+```
+
+## 挂单奖励
+
+目前的供需机制并未涉及挂单奖励。因此要的到算力奖励，核心就是要成交。（哪怕自己用小号去成交）
+
+## 提现周期
+
+提现周期是指存储订单开始后的最小周期。目前定义为12周（最小周期的一半）。
+
+## DMC20矿工的基本策略
+
+1. 根据自己的存储能力，决定存储的价格和质押率
+2. 根据对挖矿奖励的期望，决定存储的价格和质押率
+3. 适当的挂出卖单，因为每次挂单都有可能真正的锁定GWT质押，因此需要谨慎操作
+4. 手工撤回为成交的卖单，已得到质押GWT的立刻退还
+5. 自动的处理存储订单的交付，也可手工处理黑名单用户的订单。
+6. 理解挖矿规则后，从节约手续费、锁定有利的系统参数、以及及时获得流动性3个角度在合适的时候提现。
+7. 在GWT全链转换的基础上，认证思考如何在不同链上挖矿（寻找挖矿难度更低的链），以及合适转移GWT
+
+## 交易费用
+
+针对任何处于交付状态的订单进行提现，都会收取交易费用。
+
+在存储交易的过程中，合约会抽取一部分比率的交易费用。比如买家花了1000个GWT购买的空间，实际上卖家只能提现得到995个GWT，剩下的5个GWT会被合约抽取。
+
+由合约持有的GWT有两种使用方式：
+
+1. 作为分红交给DMC的持有者（这里有一个分红逻辑）
+2. 当算力不增长时，销毁GWT来减少GWT的流通
+
+## 销毁DMC20得到GWT
+
+根据上述公式可知，系统有一个最快的GWT增发速度。如果一个矿工希望在早期迅速的扩大规模，此时可以通过销毁DMC的方式来得到GWT。销毁DMC会导致DMC的发行总量的减少。
+
+销毁DMC得到的GWT的数量，与系统当前的总存储能力和当前周期的期望兑换总数有关。系统的总存储量越大，兑换得到的GWT也就越多。系统会记录一个周期内销毁DMC得到的GWT总量，销毁的DMC越多，说明得到GWT的愿望约强烈，系统会进一步提升单个DMC兑换GWT的比例以尽快满足GWT的流动性需求。
+
+
+
+## GWT/DMC 的全网兑换
+
+DMC我们选择一条链发行(ETH or X1),而GWT可以在所有的EVM兼容链上发行（依旧需要基金会部署合约）
+我们通过去中心资产桥来实现不同链之间的GWT的兑换
+DMC不支持跨链兑换。
+
+## DMC20的分红
+
+每条链上的GWT合约都会有一个分红池，通过基金会的Oracle机制同步到DMC20的发行链上，随后DMC20的有权分红者就可以通过DMC合约领取GWT分红。这意味着全网所有通过分红得到的GWT，都只会在一条链上发行。
+
+## DMC->DMC20
+
+从风险的角度考虑，我们实现的是单向转换（应该没有去中心跨链桥支持DMC1.0）。
+基本是自动化系统，平均登记到转出的时间在3天内。
+从安全的角度考虑，一个地址每天能得到DMC20的数量是有效的
+
+## 一些担忧的思考
+
+### 经济模型设计问题带来的GWT过多
+
+GWT过多，会带来GWT的价格下降。随后用户存储的成本下降，但供给端会应为收益下降而减少可用存储空间，或则提高单价。
+实际上出现了供小于求的情况：
+
+- 系统的算力进入副增长（算力增长率作为算力的导数，副增长的更快），算力奖励快速归零
+- 用户几乎不得到算力奖励，但支付同样的存储需要消耗更多的GWT了
+- 供应商的主要收入来自于用户支付的GWT，而非算力奖励
+- 系统的交易抽成增加，但因为算力并不增长，因此这部分抽成相当于销毁了
+
+### GWT全网流转是否会带来问题（DMC只在一条链上）
+
+GWT在ChainA=>ChainB之间转移,使用中心化跨链桥（最好找第三方的EVM兼容跨链桥）
+ChainA的总供应会减少，ChainB的总供应会增加。进而影响两条链上的GWT奖励模型
+跨链桥是自由的，因此任何人都可以自由的在不同链上搬运GWT，进而实现跨链价值的统一
+一旦一条链的挖矿难度低，进而获得GWT变得容易，则会有更多的用户前往该链上挖矿，进而拉平GWT的获取难度
+
+
+### 自刷挖矿的问题
+
+如果挖矿奖励 > 交易抽成(千分之3)，那么用户就有动力自己扮演供应商和需求者，进而自刷挖矿
+早期的自刷挖矿因为会锁定GWT的流动性，因此我们并不会过多担心
+自刷挖矿的风险主要在于，有的链上挖矿简单，通过该链上自刷获得了比其他矿工更大的优势
+    1. 挖矿是自由的，因此其他矿工也会前往改链自刷，来拉平优势
+    2. 对于用户来说，手续费更低的链总是会让去中心存储的成本下降，因此需求也会不断的在我们支持的链上迁移
+
+
+
+## 术语解析
+
+### 基本经济学概念
+
+- 质押率 （0.5 - 16）
+- 定价 （0.125 - 8）
+- 存储最小有效周期： 24周
+
+### 系统的关键经济学参数
+
+- 最小质押率
+- 最低价格
+- 最高价格
+- 最小挑战间隔周期 56
+- 挑战超时周期
+- 诉讼费用

doc/服务证明 通用设计.md

@@ -0,0 +1,33 @@
+# 基于后付费的服务证明的通用设计
+
+## Step1 买卖双方创建一个可公开的，双方签名的契约。
+这是一个买卖双方签名并保存在各自的磁盘上的数字合同，创建后`并不需要保存在链上`。这个数字合同的内容是“买家B 以xxx价格购买了一段时间内卖家S向C提供的服务X（X的详细内容，一般是技术指标）”。    
+注意这里有三方，会存在B购买服务给C使用的情况，但很多时候，B和C是同一个用户。       
+这个契约不保存着链上的风险在于后付费的情况下，B可能在服务结束后没有足够的余额进行支付。要不要上链取决于S对B的信用判断，如果上联的话，可能S还会需要B在契约内打入`保证金`.上链手续费由B、S协商。      
+存储类服务还要求S提供`保证金`，因为S一旦`中途违约`，丢失了保存的数据，那么可能会给B带来很大的损失。    
+建立契约的过程和建立闪电网络的支付通道类似，在有保证金的情况下，实际上创造的是一个`共享账户`。这个共享账户在确认一方违约的情况下，可以把账户余额全数转给另一方。    
+ 
+## Step2 契约建立后，S就要开始给C提供服务了。
+在提供服务的过程中，S会通过P2P Tunnel不断的问C索要`C签名`的`已服务证明`，这个服务证明是不需要上链的。索要的过程也可以是C定期提供。
+如果C不愿意提供“已服务证明”，那么S可以立刻中断服务。 如果C觉得S的服务质量很差，也可以不提供“已服务证明”。
+如果C和B是同一个人，B也可以通过直接付一个阶段性费用的方法来表达自己对服务满意。
+
+这里的主要问题是C有没有在成本范围内对S提供的服务的正确性进行验证？
+ 
+## Step3 付款
+如果B对S的服务没有意见，那么在契约时间到达的时候可以按契约约定的（价格*用量）给S付款。否则不付款。
+如果S确实提供了高质量的服务，但B迟迟不付款，S可以把`契约`和所有收到的`C签名的已服务证明`提交到链上进行仲裁。设计良好的服务证明机制可以显然的证明S的服务是高质量的，仲裁机构会扣除B的保证金，或降低B的信用，来保障S的利益。
+
+## 请假机制
+在契约约定的时间内，S/B/C 因为其它愿意不能主动履约的，可以提出暂时请假。请假条多签名后生效。
+
+## 思考
+### 优点
+服务证明的设计的优点是“链下操作”，在买卖双方互信的情况下，进行交易只有支付操作上链，对链的负载低。
+服务证明的设计并不要求100%的可靠，C愿不愿出示服务证明可以有自己的独立算法，并不要求做100%可靠的检测。
+另一个优势是提供了一定的“协商空间”，如果B、C、S对服务的质量问题能通过其他渠道达成一致，也不用设计链上机制处理
+
+### 缺点
+服务证明很多时候是基于统计的，不是100%可靠的，这里可能会系统带来整体性的风险。
+存在C和S一起串通，坑B的可能性。这需要B慎重的选择C。这需要B设计合理的机制来慎重的选择C，或则给每个C一个积分上限，防止单个C消耗太多的资源。
+