链上计算结果正确性

主要解决的问题是验证链上计算结果的真实性，由于联盟链本身没有PoW和PoS之类的共识算法，因此可以使用以太坊之类的公链（结点多，共识算法可靠）的智能合约去监管联盟链上合约的计算结果。

数据源

LP问题的数据来源是区块链账本，账本中的数据可以由多个结点写入，写入数据时，数据格式为{Id：data}的格式，data可以为单个整数，也可以是数组。

LP求解

求解LP问题时，第一步是从账本中取数据，然后计算LP问题和其对偶问题，然后将计算结果和使用到的数据来源上传到其他合约中，可以以json的形式传输数据，在公链的合约中可以以哈希表之类的形式存储以进行快速查找和索引，哈希表的key是唯一指定id（可以来源于时间戳或者fabric目前的区块高度，方便进行溯源），哈希表的value是序列化后的计算数据，其中要存储的关键字段有LP问题的解和对偶问题的解，LP问题的数据来源（可以只存Id，也可也Id和data一起存），其他合约需要进行监管时，可以从本地合约中存储的数据进行计算校验。
其中校验部分分为三种情况，第一种是feasible，也就是说c x严格等于b y（已完成），对于infeasible的情况，给出的proof中包含原问题辅助问题的解，如果辅助问题最优值为0，那么说明原问题有解。

实验结果

校验正确率，因为go语言的原因，对偶问题的解和原本的解有较小的误差，这个可以作为一个正确率的评判因素
对比链上计算结果耗时与校验耗时
对比直接从监管结点查询数据与直接从联盟链合约中取数据耗时
对比下主动上传数据与监管结点去取数据的复杂度
对比求解的LP问题的规模所需要的耗时，从小到大

具体步骤

云端结点主动取数据

云端区块链主动去取数据，构建图或者树，或者KV？如果以{K:timeStamp;V:Data}的格式去存储数据，当云端区块链去联盟链取数据时，可能没法知道存储数据的时间，从而没法取到数据。

另一种方案

借助一个监管结点，监管结点是位于联盟链那端的，云端区块链发出监管请求时，云端区块链的链码会去调用监管结点，从而获取到形如{K:timeStamp;V:data}的数据，然后数据传送到云端链码中进行校验，并且把校验结果写入云端的链中

一些问题

求解效率问题：因为链码实际上是一个docker的形式运行，并且docker的性能参数无法修改，因此求解速度很慢
数据解的问题:目前构造的数据，510矩阵，1000次测试中，600次是有解的，但是一旦矩阵规模10 100，就只有50组左右是有解的。

todo

求解对偶问题时，是否有计算优化空间
是否有更好的方法存储数据
更优雅的监管，比如说以代理合约的形式，这样就不需要去修改原本合约

方案 2021.11.3

1 被监管链结点将数据写入账本，格式为 id:data，id是唯一标识符
2 当需要计算时，合约从账本中取出数据，进行LP计算，并且把计算的结果以{timeStamp:data}的格式写入区块链账本，其中data包括LP问题的参数和解，（可以尝试下默克尔树，好处是可保证在传输过程中数据的安全性）
3 当监管链请求监管数据时，监管客户端收到监管请求后，通过调用嵌入的监管合约从账本中取出LP计算写入的数据，并且上传到监管链
4 监管链的合约收到数据之后，进行校验运算之后将校验结果以{timeStamp:result}的形式写入监管链账本，如果发现计算结果不正确，监管合约则会通知监管客户端

新版本架构图：

可以进行的对比实验：

监管客户端使用{timeStamp:data}备份计算数据与不备份数据直接遍历查找的对比
两种模式：监管链主动索取数据与被监管链主动调用监管链的校验合约的优缺点以及效率

2021.11.11方案

1 被监管链中由数据生成的合约将数据写入账本，格式为{id:data}，其中id是自增的唯一标识符
2 当被监管链需要计算时，会按照id从小到大的顺序，以此取出数据，用来构建出解决LP问题所需要的A，c，b，然后进求解，如果有最优值，那么则接着计算对偶问题，最终把原问题的解x和对偶问题的解y，以{timeStamp:[x,y]}的格式写入账本之中，其中x和y是含有多个0的向量，可以将x和y组成一个稀疏矩阵后压缩存储，减少存储和通信上的开销
3 在计算完成之后，会将计算的参数A,c,b数据以{timeStamp(和上面的timeStamp是同一个值):[Id(A),Id(c),Id(b)]}的格式写入账本之中做溯源用，由于A,c，b都是大小比较相近的index，可以用整体加上或者减去一个整数的方法压缩存储。
4 监管链中有监管合约，合约中有一个监管函数，当调用监管函数之后，会像监管客户端发出一个rpc请求，监管客户端收到监管请求后，通过调用嵌入被监管链的监管合约从账本中取出LP计算结果和计算所用参数的id，接着利用id去账本中溯源到原本计算的数据，然后将整体数据打包后返回给监管链
5 监管链的合约收到数据之后，进行校验运算：1 验证A x == b； 2 验证c x == b * y；之后将校验结果以{timeStamp:result}的形式写入监管链账本，如果发现计算结果不正确，监管合约则会通知监管客户端
6 其实整体提出的是一个跨链监管框架，通过在被监管链方植入监管客户端和合约，然后通过在监管客户端中嵌入rpc服务器的方式实现跨链

新版本架构图：

可以进行的对比实验：

监管客户端使用{timeStamp:data}备份计算数据与不备份数据直接遍历查找的对比
两种模式：监管链主动索取数据与被监管链主动调用监管链的校验合约的优缺点以及效率

2021.11.17方案

结果可验证的轻量级联盟链跨链框架
应该是提出一个框架性的东西，其中LP计算是一个例子或者部分。提出的应该是一种结果可验证的跨链机制。我觉得可以叫基于中继结点（公证人）的可验证跨链机制。

其中中继结点包含一个分布式kv数据库etcd和消息队列构成，同时具有RPC的功能，任何想要接入跨链框架的链第一步都是需要到中继结点中注册自己的身份信息，etcd需要存储的信息如下：

1 2	K：链的ID V：{链的名称，链的跨链路由ip地址，链的公钥，链的身份（监管者与被监管者）}

而链与链之间的通信都需要经过中继结点，所有的通信记录都会按照时间顺序存在中继节点的消息队列中，跨链路由是由接入链的SDK+RPC结点构成，同时也具有消息队列，可以存储发来的跨链调用请求，这样既实现了对接入链的信息的访问，又实现了链与链之间的互联互通。这些都是和目前现有的一些跨链框架设计理念差不多，但是中继结点更加轻量级和高效，设计思想类似于目前后端中的微服务的架构与模式。

具体的监管过程如下，以LP为例：

1 被监管链中由数据生成的合约将数据写入账本，格式为{id:data}，其中id是自增的唯一标识符
2 当被监管链需要计算时，会按照id从小到大的顺序，以此取出数据，用来构建出解决LP问题所需要的A，c，b，然后进求解，如果有最优值，那么则接着计算对偶问题，最终把原问题的解x和对偶问题的解y，以{timeStamp:[x,y]}的格式写入账本之中，其中x和y是含有多个0的向量，可以将x和y组成一个稀疏矩阵后压缩存储，减少存储和通信上的开销
3 在计算完成之后，会将计算的参数A,c,b数据以{timeStamp(和上面的timeStamp是同一个值):[Id(A),Id(c ),Id(b)]}的格式写入账本之中做溯源用，由于A,c，b都是大小比较相近的index，可以用整体加上或者减去一个整数的方法压缩存储。
4 监管链中有监管合约，合约中有一个监管函数，当调用监管函数之后，监管函数会把监管请求发送到跨链路由，跨链路由接着会构建一个监管请求：{监管链ID，被监管链的id，监管的计算类型}，同时用自己保存在跨链路由中的私钥对消息使用RSA算法签名，把签名附加在消息中，接着消息将传递到中继结点中。
5 中继结点收到跨链路由的消息之后，会将消息发送至被监管链的跨链路由中，被监管链的跨链路由会向中继结点申请监管链的公钥，用来验证消息的合法性，同时会向中继结点索要监管链的id所对应的身份信息，判断是否为监管者，通过校验之后才会进行下面的操作。
6 被监管链跨链路由通过调用嵌入被监管链的监管合约从账本中取出LP计算结果和计算所用参数的id，接着利用id去账本中溯源到原本计算的数据，然后将整体数据打包后返回给监管链，同时会用自己的私钥将消息签名发送到中继结点中,消息格式{被监管链ID，监管链ID，Proof字段（根据不同的计算类型有不同的数据，在LP中是A,b,c,X,Y）}。
7 监管链在收到数据之后，向中继结点索取被监管链的公钥之后验证消息的合法性，进行校验运算：1 验证A x == b； 2 验证c x == b * y；之后将校验结果以{timeStamp:result}的形式写入监管链账本，如果发现计算结果不正确，监管合约则会通知监管客户端

可对比的方案：

异构能源区块链的多能互补安全交易模型
适用于异构联盟链底层平台的跨链模型
wecross
这两天即将发布的陆羽跨链模型

创新点：

使用了中继结点的方式，中继结点保存所有消息记录（可以划分为公证人跨链机制）
往常跨链中各个链身份都是平等的，我们引入了监管与被监管者的概念
设计了一系列的消息协议，用来确保跨链过程中的安全
设计的协议中跨链结果中带有proof字段，用来验证跨链结果的正确性]

方案简介

在目前设计的系统中，信息巡查和数据处理结果的正确性，主要是指判断合约计算的结果是否正确，以税务系统的联盟链为例，一些税额的计算都是在智能合约中完成，因此我们需要去监管和验证智能合约计算结果的正确性，针对不同类型的运算有不同的验证机制，以线性规划问题为例，我们通过对偶问题去验证原问题是否计算正确，通过跨链技术和可验证计算技术相结合，实现跨链监管结果可溯源和不可篡改。
目前已经设计了一套轻量级的基于中继结点联盟链跨链监管框架，严格意义上可以划分于公证人跨链机制。中继节点由分布式KV数据库和消息队列组成，同时具有发起和接受RPC请求的功能，任何想要接入跨链监管框架的链第一步都是需要到中继结点中注册自己的身份信息，其中关键的身份信息有：1 自己的身份，该链在跨链系统中属于监管者还是被监管者；2 该链的公钥，私钥由区块链本身保存，公钥和私钥用于在进行跨链通信中确定和验证身份；3 该链的跨链路由的RPC地址，用于与结点之间进行互相通信。
联盟链向中继节点注册身份信息之后，需要接入特定的跨链路由，之后通过跨链路由，和设计的一套跨链监管消息通信协议，就可以实现监管链与被监管链之间的跨链通信和合约调用。

本方法优点

1 使用了中继结点的方式，中继结点保存所有消息记录，因此所有跨链操作都是可以溯源和查询的.
2 相比较于中继链的跨链机制，中继链需要将跨链操作信息经过共识打包进交易，而中继结点相对来说处理交易的速度更快，并且通过消息队列的方式也可以实现交易信息全流程的存储。
3 相较于传统的联盟链跨链框架，我们的框架有了明确的身份划分，每一条接入的链必须是监管者或者被监管者，这样严格的身份控制可以确保整个跨链监管的安全性。
4 设计的消息通信协议中，我们加入了proof字段，通过proof字段携带的信息可以对不同类型的计算进行计算结果正确性的校验。

场景变更

一共有三条链，被监管链，中继链，监管链

被监管链进行LP计算，但是计算结果可能不正确，或者在将计算结果写入数据接收链的时候不正确（返回fake value给接收链），因此需要使用监管链进行监管。

角色增加为三个，1 被监管链 2 中继链 3 监管链
等于说把中继结点改成了中继链，注册，身份校验等不变，只是写在kv数据库中改成了写入身份信息合约中。
监管步骤：

1 被监管链写入数据并且进行LP计算
2 被监管链定时将计算结果和Proof一定参数发送至接收链（根据不同的计算有不同的参数和结果，以LP为例，参数是数据的id，结果就是计算结果）
3 监管链想要进行监管时，首先需要向中继链提出监管请求，并且使用中继链的私钥对请求进行签名，接着中继链会把计算用到参数的id给监管链，监管链带着签名后的请求，可以去被监管链中取出data，和对偶问题的解
4 监管链会嵌入一个监管合约，监管合约会实时的计算原本LP问题的对偶问题，并且把