目录

1. 本学期科研规划
2. 第一周 2021/11/01 – 2021/11/07
   1. 本周工作情况和进展
   2. 存在的问题
   3. 下周工作计划
   4. 个人反思
3. 第二周 2021/11/08 – 2021/11/14
   1. 本周工作情况和进展
   2. 存在的问题
   3. 下周工作计划
4. 第三周 2021/11/15 – 2021/11/21
   1. 本周工作情况和进展
   2. 存在的问题
   3. 下周工作计划
5. 第四周 2021/11/22 – 2021/11/28
   1. 本周工作情况和进展
   2. 下周工作计划

本学期科研规划

  在fabric区块链中使用sgx技术，将chaincode放入enclave中运行，保护智能合约运行安全。

第一周 2021/11/01 – 2021/11/07

本周工作情况和进展

  本周在上周的基础上，实现ego启动chaincode，让chaincode在enclave中运行。

1. Fabric链码关键命令

   1 2 3 4 5

   peer lifecycle chaincode package mycc.tar.gz --path abstore --lang golang --label mycc peer lifecycle chaincode install mycc.tar.gz peer lifecycle chaincode approveformyorg peer lifecycle chaincode commit peer chaincode invoke

     fabric2.0使用lifecycle生命周期，命令和fabric1.0差距很大，下图为二者的区别：

   

2. 链码打包

   1	peer lifecycle chaincode package mycc.tar.gz --path abstore --lang golang --label mycc

     链码打包命令如上图，mycc.tar.gz是打包后的的压缩包，path指明链码路径，lang指明链码语言，lable即链码标签。压缩包内容如下：

   
   
     以go语言为例，压缩包中有code.tar.gz，就是go语言的源码，metadata.json记录链码的语言等信息，内容如下：

   1	{"path":"github.com/hyperledger/fabric-samples/chaincode/abstore","type":"golang","label":"mycc"}

3. 链码安装、编译、运行

   1	peer lifecycle chaincode install mycc.tar.gz

     上述命令会安装链码、编译并运行。安装过程会将链码包复制重命名，将mycc.tar.gz重命名，放入peer容器的/var/hyperledger/production/lifecycle/chaincodes路径下：

   
   
     编译过程首先使用第一个镜像，peer会运行hyperledger/fabric-ccenv:latest镜像，启动一个容器编译链码工程，编译后的可执行文件都命名为chaincode，编译脚本如下：

   1 2	cd chaincode/input/src GO111MODULE=on go build -v -mod=vendor -ldflags "-linkmode external -extldflags '-static'" -o chaincode/output/chaincode github.com/archive/chaincode-go

     因此需要在fabric-ccenv镜像中集成ego编译器，使用ego编译，使可执行程序适配enclave。
     然后使用第二个镜像，通过hyperledger/fabric-baseos:latest构建以dev开头的镜像，将可执行程序放入/usr/local/bin下
     Dockerfile如下：

   1 2 3 4 5

   FROM hyperledger/fabric-baseos:latest ADD binpackage.tar /usr/local/bin LABEL org.hyperledger.fabric.chaincode.type="GOLANG" \ org.hyperledger.fabric.version="latest" ENV CORE_CHAINCODE_BUILDLEVEL=latest

     最后peer在dev镜像的基础上创建容器，设置环境变量，运行chaincode：

   1	chaincode -peer.address=peer0.org1.example.com:7052

     运行后链码会注册到peer上，并建立grpc通信，流程如下图：
   

   
   
     因此我将该运行指令进行扩展，先使用ego签名，再ego run运行chaincode。编写如下脚本：
   
   
   
   
   
   
     重要的一点是，由于enclave中的环境变量和文件与外界不通用，所以需要使用配置文件将密钥文件进行挂载，将环境变量传递到enclave中。

存在的问题

  由于在自己虚拟机上没有sgx，使用仿真模式运行的，镜像中都没有安装sgx，所以可以成功。但在装配sgx的实机运行时发现镜像中也要安装sgx，运行失败。所以需要再挑选一个配备sgx的镜像或者在镜像中安装sgx，再进行运行测试。
  在dockerhub上，有许多配备sgx的ubuntu镜像，单独运行sgx实例可以成功，但在安装ego后便报错，因此需要解决。
  在单独的ubuntu镜像上安装sgx驱动时，linux-header中缺少一些文件，导致安装失败。

下周工作计划

1. 在docker镜像池中挑选sgx的镜像，或者在ubuntu镜像中安装sgx
2. 根据fabric框架和ego框架，画出本工程的框架图
3. 对该工程进行性能测试

个人反思

  到现在项目终于快完成了，接下来就是评估测试和调研攻击方法，写一篇完整的论文。时间也比较紧，要在12月底前将论文完成。
  能够完成到这一步真的让我很开心，我马上联系了导师，希望能和她汇报一下。导师肯定了我的成果，提出了很多建议，导师也愿意把共同一作或者共同通讯作者给我。能得到赞赏总归是开心的，每次在和导师沟通后我都能开心很久，也有了继续的动力，尤其是这一切都是我踏踏实实做出来的，是我自己的努力。希望接下来能继续完成吧

第二周 2021/11/08 – 2021/11/14

本周工作情况和进展

  上周提出的镜像问题已经解决，在docker镜像池中找到了安装sgx的镜像，镜像中不能安装sgx驱动设备，需要将本机的sgx驱动传递到运行的镜像中。

  本周简单画了几个原理图，还需要后续完善：

fabric原理图 项目运行架构图 静态原理图   静态原理图太过于简单，直接就是在chaincode上套上chaincode，后续还需要重新改进。因为程序运行时会创建容器，所以运行图会凸显出容器之间的交互，更为详细，后续需要再添加一些细节。   本周对fabric的运行进行了简单评估。hyperledger下有一个caliper项目，专门用来测试区块链的性能，如延迟Latency、吞吐率Throughput、CPU占用率、内存等，如下：

存在的问题

  该评估需要编写脚本来测试，因此后续可以测试创建、查询、修改账本的各种性能。
  程序运行时间可以通过/usr/bin/time来获取链码安装、调用的时间信息。

下周工作计划

  学习caliper使用方法，完善fabric性能测试。

第三周 2021/11/15 – 2021/11/21

本周工作情况和进展

1. 改进框架图

   
   

2. 评估问题解决
     上周提到修改的区块数目过大时，出现读写冲突。该问题与fabric机制和链码编写有关，fabric会汇总一定数量的区块再一起提交，当多个区块键值状态相同时，就会出现冲突。因此fabric官方提供了一个高吞吐率的链码，使用该链码就不会有读写冲突。

3. 评估结果
     评估对象是随着客户端数目的增加Latency延迟、Throughput吞吐率的变化。
     使用fabric官方的高吞吐率链码和caliper工具，编写读取和修改两种脚本。读取调用链码后直接返回结果，不经过orderer节点分发，不写入账本。修改数据时要调用链码，由orderer节点广播，写入到各peer节点的账本中。因此读取的效率明显高一些，吞吐率高于写入，延迟低于写入操作。
     这里从一个客户端开始，以倍数增加，最多128个客户端，对比fabric原网络和使用sgx的网络。在测试时有一个现象，如果在一个持续的网络中测试，客户端数目不变时，吞吐率会持续下降，因此每次修改客户端数目时，我会将网络重启，保证得到最优的吞吐率。结果如下图：（读取使用左纵坐标轴，写入使用右纵坐标轴）

   
   
     综合上图所知，两种网络的趋势是相同的，延迟和吞吐率相差不大。因为每一次测试数据都有波动，所以看不出明显的区分关系。但这个结果和预想的有一些差距，随着客户端数目增加，延迟应该是逐步增加的，而第一个图128个客户端读取时延迟骤降，比较反常。吞吐率应该先增加，达到最优值后降低，读取测试满足，但写入测试时有一个先降再升再降的过程，也不符合。   下图是另一篇论文中作者的测试图，也是客户端由1增加到128，整体规律就很明了，并且明显有sgx的效率会低一些，而我的测试关系不明显。
   

存在的问题

  测试图规律不明显，并且不能很好地展现出结果，需要进一步测试修改。

下周工作计划

  继续使用caliper测试结果

第四周 2021/11/22 – 2021/11/28

本周工作情况和进展

1. 扩大测试组数，修改绘图
     上周各组数据均测试一次，因此数据浮动较大，为减少误差，随着客户端倍数增加，每次测试四组数据，取平均值，减少数据浮动误差。
     针对ppt绘图不美观的问题，本次使用python绘图，并将query和update分别绘图，如下：

   
   
   
   

2. 攻击方向调研
     SGUARD: Towards Fixing Vulnerable Smart Contracts Automatically
     EOSAFE: Security Analysis of EOSIO Smart Contracts
     老师发的两篇文章均是针对代码的，检测代码漏洞或者执行漏洞，如缓冲区溢出等，然后对代码或者二进制程序进行补丁修改。我们的工作是直接将链码放入enclave中运行，因此针对链码自身的漏洞应该是无法防御的。但两篇论文提了一个很好的思路，在原架构的基础上，可以在enclave中嵌入修复模块，对链码本身先检测修复，然后再运行，对链码进行两层保护。
     目前针对智能合约的攻击大多是从代码层面，如伪随机数发生器、查询、全局变量漏洞等。enclave只能保护运行时安全，防止运行程序的状态、功能被窃取，因此不知道能否防御代码层面的攻击。针对enclave的这一特点，我的想法是寻找窃取chaincode信息或攻击运行时程序的攻击来调研。
     其次，很多论文也有针对账本（ledger）来保护，将数据放入enclave中保护完整性，项目后续也可以考虑该方法。

下周工作计划

  以针对窃取链码各种信息、状态的攻击或者针对账本的攻击来调研。