望尘可及的秘密基地

四、issta投稿

4.1 写作思路回顾

这次的投稿文章有7个章节，abstract，introduction，background and motivation，overview，detail，evaluation，related work和conclusion。

内容较泛部分

可以一句话概括，然后用gpt进行扩写。

适用内容较泛部分，比如abstract第一段，introduction前几段，background和related work，甚至overview中解释solution的时候也可以小用一下doge。

各部分内容

abstract简要介绍背景，motivation，提出的方法思路，表现。

introduction介绍背景，现有工作不足，然后引出我们的方法，介绍我们的方法思路，最后讲评估表现。

background and motivation要先介绍研究内容的基座，然后着重介绍我们设计方法的考量，用一个motivation example来说明我们发现了什么什么情况，基于这种情况我们这样设计模型。

overview先摆我们遇到的挑战以及我们的解决方案，尽可能涉及我们用的所有部分，然后分部分说方法的整体框架。

detail无他，就是详细介绍各个部分的细节。

evaluation先介绍setup，其中包括实验环境，数据集，性能指标，RQ，参数等等。然后对应RQ开始评估，一般有对比实验，消融实验，参数实验，摆几个case study，最后可以来个limitations。表现能解释解释，不能解释就直接描述结果。case不用过于详尽，但要体现我们选他的理由。

related work略。

conclusion就是abstract- background and motivation。

4.2 标记规范

自己瞎定的。

1. 用ffoo，XXX作为占位符
2. 完成情况标记：1210todo表示1210做，doing表示正在做，todo？表示不一定做，done表示完成
3. 原文注释规范：第X章开头：ffoo、第X节开头：ffoo

4.3 碎碎念

应该用钉钉的思维导图（okr那个），可以指派任务，完成后转移指派。

写论文真得开个gpt4，神中神，写废话和写代码利器。

chatgpt翻译 < deepl翻译，gpt喜欢拽高级表述，很奇怪，会影响原文的重点，不过deepl有时候也是一坨。

画latex表格网址

excel画折线图，ppt画示意图，还可以用matlabplot画3d图和热力矩阵。

参加了一回港警招聘，记录一下相关信息。

香港警务处有在官网和公众号宣传招聘信息和宣传点信息，在广州设立了三天的宣传点，两天在SYSU，一天在暨大。

宣传点

先说宣传单上的信息吧。

督察要求本科且中英文一级，月薪5w+，警员仅要求DSE，月薪2.8w+。

督察先笔试，再两轮面试，警员无笔试仅有面试，都有体测，项目包括4x10、立定跳高、俯卧撑、800米。

在宣传点当场咨询了一个警员和督察，根据了解的情况来说，督察的面试每次一天，内容包括中英文自我介绍，小组讨论，时事分析，领导力展示等等，存在户外面试。心理测试不筛人。

PS. 确实存在中英夹杂的情况。

笔试情况

下面说说考试的情况。

在公教楼使用了D402和D401两间教室，一间进行警员面试，一间进行笔试。宣传单上表示警员无笔试，但实际上考场有看见警员笔试的信息。

督察的话两篇作文，一篇中文一篇英文，各60分钟三百字，题目分别是《你希望居住在怎样的城市？》和《view on “money is not the only answer but it makes a difference”》，注意不接受简体字qaq。

警员的话，就我所看到的，好像全是选择题，有中文有英文（maybe，仅供参考）

考试氛围的话，十分的轻松，不用摘手表，不收手机，主监考十分友善hhhh。

不知道为什么他们对信息的涂改很重视，动不动就换一张。

总体警员观感

目测大概有7个人，两个督察，五个警员。

一个女督察一个男督察貌似没笑过，男督察说实话有点像姚sw，说话风格和精神面貌像，梳个大背头，贼壮，不怎么笑。感觉在宣传点热情介绍那个的男警员有点怕男督察，有点阿谀奉承。

在宣传点的另一个是女督察，也不笑，介绍情况倒是挺详细的。

在考场的是三个警员，一个负责面试，一个负责笔试，一个两边跑。噢男督察也是宣传点考场两边跑。

两边跑的警员也不爱笑，但不凶，我一开始拿红笔填信息她也没怪我，只是帮我换了一张，最后还鼓励我说努力hhhh。

考完之后和监考姐聊了一会，她还问我为什么要当警察，理工科明明有更好的出路，当警察压力大，还要受气hhhh。我说我不会说白话，她还说我会，只不过歪音hhhh。

闲聊

在外头填信息的时候和两个等待面试的同学聊，才知道督察面试对英语要求很高qaq，要英语自我介绍回答问题啥的。

他们还问我怎么敢没准备就报督导，还劝我换去警员hhhh。

反思

从这次应聘还发现一些问题。

一个是做事态度出了问题，现在不会高中那样，一点点分解问题，尽可能去解决问题，现在是遇到问题，尝试一下，然后心里就拼命敲响退堂鼓了。

另一个是香港和内地工作氛围差异的问题，就从这次的观察来看，香港上下级之间的界限有点分明，工作氛围可能会压抑，可能存在职场霸凌？

数据集：https://xblock.pro/#/dataset/25

传统庞氏合约

目前将庞氏合约根据合约分配资金的模式分成4类：树形合约、链式合约、瀑布式合约和交接合约。

树形合约

用户之间的关系为树形结构。每当用户加入这个合约时，他必须将另一个用户指示为邀请者（父节点）。

新用户的钱在她的邀请者或邀请者的邀请者等等(即树形结构下的“祖先”)之间分配，逻辑是距离她越近邀请者获得的份额越大。

例子：Etheramid和DynamicPyramid

链式合约

用户之间的关系是线性的，每个节点都只有一个子节点。通常承诺一个常数因子（收益金额/投资金额），这个常数因子对所有用户都是相等的。合约按顺序一次性全额支付用户的收益。

所有新的投资都被收集起来，直到获得到期的金额。

例子：Doubler、dianaem和ZeroPonzi

瀑布式合约

类似于链式合约，但分配逻辑不同。分发总是从链的头部开始，按顺序支付用户的收益，直到余额耗尽。

每次分钱会跳着分。

例子：TreasureChest和PiggyBank

交接合约

类似于链式合约，用户投资金额由合约决定，每次有新的用户加入，合约就会提高投资金额。合约将新用户的资金直接支付给前一个用户，前一个用户立即获得了利润。

例子：KingOfTheEtherThrone

新发现

在数据集中发现有很多被标记为庞氏的合约是建立在自己实现的token上的，不一定符合ERC20标准。这类合约接收到新投资后，一般会增加老投资者的分红变量，而不是直接向老投资者转账。

数据集不足

现在数据集有点旧，仅截止到2019年1月生成的区块7136486。

得更新一下数据集，从中找一个新模式的庞氏合约（或者我们自己想一个hhhh有没有可能整个跨链庞氏）

亲测https://blog.csdn.net/Miracle_ps/article/details/114791335中的第二个办法可行，这里mark一下。

方法一：

1. 找到Hexo下的_config.yml里的post_asset_folder，把这个选项从false改成true
2. 在Hexo目录下打开Git Brsh，执行一个下载上传图片插件的命令npm install hexo-asset-image —save。
3. 继续在Git Brsh下利用hexo n “xxxx”来生成md的文件（””里的内容填自己的文件名），这时就会在同级的目录下生成一个同名的文件夹。
4. 在.md的文件中要插入图片时，先要把所要插入的图片放在生成的同名文件夹下。

方法二：

在source路径下新建一个文件夹，然后用md语法正常插入即可。

如新建路径source/assets，则插入![imgname](/assets/xxx.png)

Bug描述：hexo的categories和tags不对大小写进行区分，假如改变某个tag的大小写并同步到github上后将导致404。

解决方法：将.deploy_git中的categories或者tags路径删除，是不管用滴。要将.deploy_git/config中的ignorcase改为false才行。

一、论文信息

题目：《Ponzi Scheme Detection in Smart Contract via Transaction Semantic Representation Learning》

级别：IEEE Transactions on Reliability，中科院二区，CCF-C类

作者院校：扬州大学

二、论文动机

现有方法的局限性：

1. 语义不足
2. 庞氏关键语义获取
3. 未充分利用特征

提出一个基于学习交易语义的方法：用一种新的代码表示方法sTPG，将交易语义表示成一个图，然后利用gcn来学习交易模式。

设计方法的考量：

1. 为了处理复杂语义：cfg
2. 为了处理无关代码：切片
3. 状态变量的过程内数据依赖重要性

三、具体方法

文中有给一个走完了全流程的例子，各部分的最后一段是对该例子的操作。

训练阶段

简单说就是通过静态分析，程序切片和过程内状态变量依赖分析这三个步骤，从一个合约中获得一组sTPG，然后用这些sTPG作为特征进行训练。

3.1 静态分析

1. 先构建交易函数集
2. 然后用slither对每个交易函数构建cfg
3. 接着对每个cfg用forward dominance relation方法来获得控制依赖边，用变量def-use链来获得数据依赖边和数据流边
4. 构建状态变量依赖边，从read到write

至此对每个交易函数都有一个PDG图，图中有5种边，控制依赖边、数据依赖边、控制流边、数据流边和状态变量依赖边。

3.2 程序切片

对静态分析中获得的每个PDG应用以下两个切片标准：

1. 每个transfer API，后向切片
2. 切片1中存在的全部状态变量，后向前向切片

3.3 过程内状态变量依赖分析

在所有可调用的函数中，查找修改了(交易API依赖的状态变量)的语句，添加过程间状态变量依赖边，从read到write。

3.4 模型训练

初始化：

• 节点嵌入初始化：用一个开源的基于AST的模型Infercode来获得向量
• 边嵌入初始化：先合并同方向边，接着将边编码成五维的onehot形式，每一维度分别表示控制流、数据流、数据依赖、控制依赖和状态变量依赖

为了利用上边的信息，他们提出了一个relation-sensitive gcn：先用一个MLP计算边的隐藏特征，然后将节点特征和隐藏特征相拼接，用拼接后的特征进行图卷积（不太了解图卷积，这里没懂），最后用一个最大池化层和MLP进行分。

检测阶段

类似训练阶段

四、实验复现

数据集是开源的，放在了https://github.com/smartcontract-detect-yzu/PonziDataset，一部分是之前文章的开源数据集，一部分是从各个地方找合约然后人工打标签的，剩下是etherscan上标记为庞氏的。

用slither进行静态分析，然后用Networkx构建sTPG，接着用Pytorch和PYG实现RS-GCN。

硬件信息和模型参数都有交代，见EXPERIMENT章节的Implementation段

五、不足

1. 仅针对solidity
2. 识别出的交易语义源自一个交易函数——可扩展到跨函数交易语义挖掘
3. 可尝试利用更多信息，比如AST中的信息
4. 数据不平衡

一、概述

控制流图CFG、数据流图DFG、程序依赖图PDG、系统依赖图SDG

程序切片从可执行到不可执行

根据输入分类：静态切片，动态切片，有条件切片

程序切片应用之处

二、图论基础

控制流图

基本块：第一句进入，最后一句离开

控制流图以基本块为节点

控制流和数据流

控制流分析就是去发现过程内or过程间的控制流

什么是过程？~函数

控制流图表示形式：

1. AST
2. CFG
3. PDG中的控制依赖

数据流描述了变量的值从定义点如何流到使用点

数据流边表示什么？~变量和变量之间的关系

可到达定义怎么计算？~求解数据流方程

控制依赖和数据依赖

控制依赖：控制流引起的程序实体之间的关系

控制依赖定义：满足以下三个条件：

1. n1n2之间存在可执行路径
2. 对可到达路径上的其他点，n2都是它的后必经节点
3. n2不是n1的后必经节点

条件语句内部的语句控制依赖于条件部分

数据依赖：由于数据定义和使用所形成的实体之间的关系

数据依赖定义：满足以下三个条件：

1. n2定义了变量v
2. n1使用了变量v
3. n2n1存在可执行路径且变量v未重新定义

程序依赖图

这里只是简单介绍

过程内依赖图：即过程依赖图PrDG，即控制依赖图+数据依赖图

过程间依赖图：即系统依赖图，各个过程依赖图+调用边+调用引起的依赖边

三、静态程序分析

MarkWeiser程序切片

切片准则：，n表示某个语句，V表示代码中变量的子集

其实就是在简化代码，希望留下切片准则相关的代码，求切片就是求图的可达性问题

切片结果可能不符合语法

切片优化：寻找最小切片问题是不可解的

不足：只能解决简单的程序，为了解决过程和过程调用的问题提出了过程内切片和过程间切片

过程内切片

先在cfg上构建控制依赖图和数据依赖图，然后把两个图合并即可得到pdg

先构建程序依赖图pdg，再应用图可达性算法

前向后向区别：

• 后向：是指以漏洞关注点为终点，能够到达该节点的所有路径上的所有节点
• 前向：是指从关注点节点出发，能够达到达到的所有路径上的节点

过程间切片

一样的逻辑，构建系统依赖图，然后应用图可达性算法

在过程依赖图上添加调用边、参数输入边和参数输出边形成系统依赖图（根据P50，好像有更多操作）

参考资料

《程序切片技术及其应用》

【南大软件分析】lecture7 笔记-Interprocedural Analysis

Cosmos多链拆解

区块链的发展：btc，eth，cosmos(多链)

Tendermint共识机制

tendermint分为core和abci两个组件

Tendermint Core

共识算法为优化后的POS

需要使用客户端以保证安全性和一致性

tendermint core作为共识引擎，网络层使用Gossip协议，共识层使用BFT+POS共识算法

验证者获得2/3的投票即添加新的区块

节点上限100个以保证性能

ABCI接口

• CheckTx：验证交易
• DeliverTx：提交并更新状态
• BeginBlock和EndBlock：查询状态

Cosmos SDK

SDK内分成多个部分，开发者可以组合不同模块来构建DApp，也可以自行开发模块

支持WebAssembly

支持对象能力模型，将模块的运行逻辑保存在Keeper中。

IBC协议

类似TCP/IP协议

建立握手连接：

1. A链发起跨链到B链的OpenInit请求，等待Relayer接收到该请求。
2. Relayer收到OpenInit的请求之后，构造OpenTry的请求发送到B链上。
3. B链收到OpenTry请求之后，同意并确认之后生成OpenACK数据包，并由Relayer按照同样的方式发送给A链。
4. A链通过OpenACK数据包判断此次握手是否成功，成功则发送OpenConfirm并把包含信息的数据包返回B链，成功传输信息；否则握手失败。

Cosmos vs. Polkadot

• 跨链协议：IBC和Parachain
• 共识机制：Tendermint和GRANDPA（ghost协议）
• 资产管理：账户模型和链上资产模型

polkadot的中继链是平行链的唯一安全提供者，带来了一定的中心化。

疑惑

1. gossip协议是什么？
2. ABCI接口没看明白？
3. Multistore机制是什么意思？
4. 用SDK开发出的应用的运行逻辑？
5. cosmos和polkadot的资产管理分别是什么意思？

跨链是如何实现的

由于区块链可扩展性未解决

链之间的交互，数据、资产和功能的互通

一、跨链通信

主要有两类跨链通信：

1. 最小化信任跨链通信：集群内部，rollups
2. 可信任跨链通信：集群之间

常见可信任跨链通信协议

1. IBC

cosmos中的核心部分，为一种标准（链间标准ICS），由TAO层和Application层组成。

点对点连接

链之间不是直接通信，用专用通道发送信息，通道中包含一个轻客户端

2. ZK

用zkp代替原数据

步骤：

1. 决定要传递的数据
2. 获取证明数据存在EVM中的存储证明
3. 由存储证明生成ZK证明，以默克尔树的形式
4. 传递zkp
5. 展开zkp
6. 读取跨链信息

3. LayerZero

传输层协议，架构由端点、中继点和预言机组成

步骤：

1. 向communicator发送交易信息
2. communicator将交易信息以某种形式发送给validator
3. 未完，有点复杂

4. axelar

验证者网络+网关智能合约+开发者工具

非点对点，链只需要接入一次即可跨多条链

5. wormhole

POA共识机制，核心合约+守护者网络。

守护者网络有19名守护者，负责交易验证

二、跨链技术

1. 公证人机制

引入第三方来验证信息

有点像交易所

2. 哈希锁定

借助哈希的单向性实现跨链交易

3. 侧链

two-way peg，在主链锁定货币后在侧链中释放等价货币

SPV模式：simplified payment verification，通过将交易发给本链的一个特殊地址，由此会自动创建一个SPV证明给侧链上并发起一个交易在侧链上解锁对应的资产。

4. 中继机制

跨链信息通过中继链的验证者验证后发布到中继链上

5. 分布式私钥控制

lock-in，lock-out，分片密钥

三、跨链的未来展望

• 跨链桥
• OmniChain NFT
• layerzero的新应用
• chainlink作为预言机
• 整合ICS标准

疑惑

1. 跨链通信中的集群是什么意思？——同一生态，比如说polkadot中的平行链和中继链。
2. 跨链通信协议和跨链技术的区别？——跨链通信协议是一种标准化的规则和协议，用于确保区块链之间的通信。跨链技术是一组具体的技术和方法，用于实际实现区块链之间的互操作性。跨链技术依赖跨链通信协议来建立通信，以实现跨链交互。这两者共同协助解决了区块链互操作性的挑战。
3. 跨链桥是什么？——有点类似侧链

九、智能合约安全

9.3 重入

原理：调用外部fallback函数来进行转账，导致合约可重入

防范技术：

1. 用transfer()进行转账，虽然会带来额外gas
2. 使用“检查-生效-交互”模式
3. 使用互斥锁

案例：DAO攻击

9.4 算术溢出

原理：Solidity中整数存在上下限

防范技术：

1. 使用SafeMath库合约

案例：PoWHC

9.5 意外的以太币

原理：强制发送以太币导致合约无法执行，self-destruct或预先发送都可以实现

防范技术：

1. 少用this.balance，使用状态变量保存余额

9.6 delegatecall

原理：delegatecall保持上下文，状态或存储变量（可以在独立的交易之间保持其数值的变量）会按照它们被引入合约的顺序放置在存储槽中，这时我们改变的变量可能不是我们期望改变的。

防范技术：

1. 使用library关键字可以保证库合约是无状态和不会自我销毁的

案例：Parity多重签名钱包的第二次攻击

9.7 默认的可见性

原理：Solidity函数可见性默认为public，可能出现纰漏

防范技术：为每个函数都指定可见性

案例：Parity多重签名钱包的首次攻击

9.8 无序错觉

原理：为了在以太坊中引入无序性（即随机性），使用哈希值、区块号等可被操控的区块变量作为随机值

防范技术：无序性必须来自区块链外部

案例：PRNG合约

9.9 外部合约引用

原理：可以故意将地址指向错误的合约，假如引用的合约不包含要调用的函数，将执行回退函数。如果用户可以修改合约引用的合约库，那么基本上他们就可以使其他用户在不知情的情况下运行任意代码。

防范技术：

1. new一个要引用的合约
2. 对外部合约进行硬编码

一般建议将合约地址设置为public以方便用户检查引用的合约

案例：可重入的蜜罐

9.10 短地址攻击

原理：当实际发送的数据长度小于标准编码长度时，EVM将在数据末尾补0，这种操作可能影响末尾参数

防范技术：对参数进行校验

9.11 未检查的调用返回值

原理：send和call外部调用失败仅返回false，不revert

防范技术：

1. 检查返回值
2. 使用withdraw模式

9.12 预先交易

原理：gas高的优先被打包

防范技术：

1. 设置gas上限
2. 使用commit-reveal模式
3. submarine sends

案例：erc20的approve函数

9.13 拒绝服务

原理：各种原因使合约不可用，比如说事先向合约转账使合约无法通过某些限制条件

防范技术：各个情况方法不同

9.14 区块时间戳操纵

原理：区块时间戳可被矿工指定。

防范技术：不应使用区块时间戳作为随机数。

案例：GovernMental

9.15 小心使用构造函数

原理：solidity0.4.22前，构造函数和合约同名；若合约名称和构造函数名称不同，构造函数将变成一个普通函数。

防范技术：使用constructor关键字。

案例：Rubixi

9.16 未初始化的存储指针

原理：状态变量和复杂类型的局部变量都存储在storage中；状态变量按照顺序保存在storage中（存储槽），未初始化的局部变量可能指向已有的状态变量。

防范技术：用storage和memory关键字明确指定变量的存储位置。

案例：OpenAddressLottery

9.17 浮点数和精度

原理：solidity的除法会舍去小于除数的所有精度。

防范技术：先执行加法和乘法，再执行减法和除法。

案例：Ethstick

9.18 Tx.Origin验证

原理：全局变量tx.origin表示最初发起交易的账户地址；若使用tx.origin作为判定条件，合约易受到钓鱼攻击。

防范技术：少用tx.origin作为判定条件。

可用require(tx.origin == msg.sender)来拒绝外部合约调用。

9.19 合约程序库

OpenZepplin包含丰富的库合约。

ZeppelinOS使开发者更简单地发布DApp。

疑惑

1. 谁可以调用合约的self-destruct
2. 外部合约引用的防范技术没看懂