NestCore：关于信息流上链的思考

作者：NestCore

信息流上链有几个问题

1. 信任风险，是否依赖某个机构上传信息，即是否去中心化上链；

2. 信息验证，信息是否经过验证，验证的方法是直接的还是间接的；...

作者：NestCore **信息流上链有几个问题** 1. 信任风险，是否依赖某个机构上传信息，即是否去中心化上链； 2. 信息验证，信息是否经过验证，验证的方法是直接的还是间接的； 3. 抗攻击，信息是否因为开放性容易被任意第三方篡改或影响； 4. 信息的延时，信息是否存在延时，信息提供的及时性怎样； 5. 信息调用，是先验证再调用，还是先调用再验证； **在 NEST 上，可以明确看到** 第一，通过分布式和激励（二者缺一不可，否则不可能构成可信的自动机制）保证了信息上传的动力和去信任化； 第二，通过双向期权保证了信息在上链过程中被验证； 第三，通过信息链的设计，保证了信息总是存在，即使被验证，也会留下一个待验证的信息，保证了信息的连续性（信息链需要再仔细分析一下） 第四，beta 系数是对抗信息链被攻击、篡改、污染的算法。 **关于去中心化** 去中心化不是分布式，分布式是一种组织方式，去中心化是一种运作方式，需要激励才能自动运转，这个激励包含直接的外部激励（比如算法），也可能是内部激励（市场交易）。 **关于验证** 这里有几个问题： 1）是先验证再使用，还是先使用再验证： 考虑到完全去中心化，如果先使用再验证，那么只有下游使用者的风险规模和验证者抵押规模匹配才可以。 有人试图通过将验证者分散，并增加随机性选择，来防止验证者作恶风险，问题在于： A. 只要下游收益足够大，理性的节点存在集体作恶的动力（不需要串谋，详见矿工不打包攻击） B. 信用风险无法分散化，如果随机调用的是单个节点，可能会被垃圾节点破坏（见 EOS 黑客攻击） C. 即使多节点不作弊，也需要大量节点进行数据处理，每个节点的激励和行为都是不一致的，存在更复杂的延时和数据结构不匹配风险 2）验证的数据结构问题： 如果一个数据不是区块链可识别的数据结构，则必然存在不对等的节点进行验证，即所谓的仲裁节点，或者需要通过所谓的投票机制进行验证（这对于很多信息是不可行或者不及时的） 3）先验证再使用的核心风险： 验证周期风险，该风险可能会导致链上信息与链下信息存在一个 gap，如果是价格信息，该 gap 就是指最小套利成本。 **关于延时** 区块链的时间维度是区块序列而不是秒，延时主要体现在信息以怎样的密度出现在区块链上。以太坊按照区块作为时间间隔，即使是最密集的报价，也只是每个区块一个，这意味着按照链下时刻来讲，总是存在延时。如果报价是按照某种机制设计的，则延时是可以计算的。 **关于可计算性** DeFi 在消除了信用风险后，在风险管理上有所提升：通过算法进行风险管理变得可行。在 NEST 系统里，主要的应用风险体现在 NEST 预言机的价格偏差和价格延时两个指标上。由于这些风险因素的分布是可计算的（依据一定的假设），因此基于 NEST 预言机的 DeFi 设计，可以基于这些量化指标进行风险管理。 **量化指标及风险管理** 市场参数：波动率 验证周期：T 套利成本：gas，佣金 f，双向期权成本 v 抗攻击参数：beta 延时指标：D，由激励机制和市场价格决定 被套利概率：p，会影响延时 价格风险主要是价格偏差 g 和延时 D 共同决定，因此 R(g，D）是价格引用的风险函数 **跟同行业比较** 1. 完全去中心化，不存在不对等节点 2. 对风险收益结构进行细致的分解和管理，基于算法的风险管理函数，这个是整个行业的突破 3. 不会牺牲某个变量来控制风险（类似 Uniswap） 4. 下游 DeFi 引用可计算

作者：NestCore

信息流上链有几个问题

1. 信任风险，是否依赖某个机构上传信息，即是否去中心化上链；

2. 信息验证，信息是否经过验证，验证的方法是直接的还是间接的；

3. 抗攻击，信息是否因为开放性容易被任意第三方篡改或影响；

4. 信息的延时，信息是否存在延时，信息提供的及时性怎样；

5. 信息调用，是先验证再调用，还是先调用再验证；

在 NEST 上，可以明确看到

第一，通过分布式和激励（二者缺一不可，否则不可能构成可信的自动机制）保证了信息上传的动力和去信任化；

第二，通过双向期权保证了信息在上链过程中被验证；

第三，通过信息链的设计，保证了信息总是存在，即使被验证，也会留下一个待验证的信息，保证了信息的连续性（信息链需要再仔细分析一下）

第四，beta 系数是对抗信息链被攻击、篡改、污染的算法。

关于去中心化

去中心化不是分布式，分布式是一种组织方式，去中心化是一种运作方式，需要激励才能自动运转，这个激励包含直接的外部激励（比如算法），也可能是内部激励（市场交易）。

关于验证

这里有几个问题：

1）是先验证再使用，还是先使用再验证：

考虑到完全去中心化，如果先使用再验证，那么只有下游使用者的风险规模和验证者抵押规模匹配才可以。

有人试图通过将验证者分散，并增加随机性选择，来防止验证者作恶风险，问题在于：

A. 只要下游收益足够大，理性的节点存在集体作恶的动力（不需要串谋，详见矿工不打包攻击）

B. 信用风险无法分散化，如果随机调用的是单个节点，可能会被垃圾节点破坏（见 EOS 黑客攻击）

C. 即使多节点不作弊，也需要大量节点进行数据处理，每个节点的激励和行为都是不一致的，存在更复杂的延时和数据结构不匹配风险

2）验证的数据结构问题：

如果一个数据不是区块链可识别的数据结构，则必然存在不对等的节点进行验证，即所谓的仲裁节点，或者需要通过所谓的投票机制进行验证（这对于很多信息是不可行或者不及时的）

3）先验证再使用的核心风险：

验证周期风险，该风险可能会导致链上信息与链下信息存在一个 gap，如果是价格信息，该 gap 就是指最小套利成本。

关于延时

区块链的时间维度是区块序列而不是秒，延时主要体现在信息以怎样的密度出现在区块链上。以太坊按照区块作为时间间隔，即使是最密集的报价，也只是每个区块一个，这意味着按照链下时刻来讲，总是存在延时。如果报价是按照某种机制设计的，则延时是可以计算的。

关于可计算性

DeFi 在消除了信用风险后，在风险管理上有所提升：通过算法进行风险管理变得可行。在 NEST 系统里，主要的应用风险体现在 NEST 预言机的价格偏差和价格延时两个指标上。由于这些风险因素的分布是可计算的（依据一定的假设），因此基于 NEST 预言机的 DeFi 设计，可以基于这些量化指标进行风险管理。

量化指标及风险管理

市场参数：波动率

验证周期：T

套利成本：gas，佣金 f，双向期权成本 v

抗攻击参数：beta

延时指标：D，由激励机制和市场价格决定

被套利概率：p，会影响延时

价格风险主要是价格偏差 g 和延时 D 共同决定，因此 R(g，D）是价格引用的风险函数

跟同行业比较

1. 完全去中心化，不存在不对等节点

2. 对风险收益结构进行细致的分解和管理，基于算法的风险管理函数，这个是整个行业的突破

3. 不会牺牲某个变量来控制风险（类似 Uniswap）

4. 下游 DeFi 引用可计算

区块链技术网。

• 发表于 2020-08-28 11:38
• 阅读 ( 779 )
• 学分 ( 17 )
• 分类：NEST