# *TokenAware: Accurate and Efficient Bookkeeping Recognition for Token Smart Contracts*

本文描述了一个新颖的在线识别token转移行为的系统TokenAware。根据这篇论文，TokenAware在token转移行为方面比当前任何识别工具都有优势。他们认为现有的解决方案由于模式不完整和设计效率低，无法准确高效地识别token转移行为。

* 即使有第三方检测恶意行为的工具，但正确率只有35.6%，因为大多数智能合约并不完全符合标准，所以本文的意义或目的是为了克服这一检测漏洞。

* 本文中TokenAware采用的解决方案克服了这个缺点:由于代币智能合约使用内部记账来记录代币持有者的信息(例如，他们的地址和代幣數量)，识别记账及其操作使第三方工具能够描述代币转移行为。请注意，计费指的是用于记录每个令牌持有者的令牌数量的变量，而计费标识指的是识别这些变量。令牌传输行为指的是一个令牌的传输，它表示为一个元组<addr, delta>。元组记录令牌持有者的地址以及令牌共享中的变化。此外，令牌转让行为必然会修改簿记，因为当令牌转让时，接收者和发送者的份额需要更新。

* TokenAware采用四种优化机制来提高性能，包括缓存、并行化、早期提取和管道。论文提供商声称，经过广泛的数据测试，TokenAware可以自动识别新的账单类型，以98.7%的准确率识别107,202个token，比当前技术好2.8倍。

## *The design purpose of TokenAware*

TokenAware的设计有两个目的，第一是准确性，第二是效率。由于合约是闭源的，因此EVM字节码是通过解编码得到的。

## *Architecture of TokenAware*


TokenAware的第一个外部和内部交易监视器用于提取智能合约的EVM字节码。TokenAware监控所有外部和内部事务。如果监视这些事务以创建契约，则TokenAware从这些新事务中提取EVM字节码。阶段1:TokenAware将提取的字节码添加到任务队列以识别记账。Worker，每个Worker都绑定到一个线程。TokenAware中的每个记账EVM字节识别都是一项任务。有4个步骤:

1. 这一阶段获取簿记标识的结果，并将其记录在缓存中，作为下一阶段的输入;
2. TokenAware将监控代币合约的执行。具体来说，当交易调用这些令牌合约时，TokenAware将分析交易是否修改了簿记;
3. TokenAware通过EVM指令序列的关系模式分析记账操作的修改
4. TokenAware将从簿记修改中推断token转移行为。

### Phase 1: Bookkeeping Recognition

记账有三种识别方法:

1. TokenAware应用一种优化技术(即O3:早期识别)在EVM执行区块中的交易之前识别记账变量。
2. TokenAware应用了另一种优化技术(O2:并行化)，它准备了一个由多个worker组成的工作池，并由worker并行执行任务。一个工人负责处理一个智能合约。
3. 缓存利用率
> Pseudocode representation

#define token_transfer_type <addr, delta>

EVM_BLOCK_TYPE evm_blocks_list = download_from_blocks_list();

vector<pair<bool, token_transfer_type>> token_list;

for (auto evm_block: evm_blocks_list) {
    if (evm_blocks_list[i].recognition_token() == true) {
        token_list.append({true, {evm_block.addr, evm_block.delta}})
    } else {
        token_list.append({false, {}})
    }
}

TokenAware查询缓存以检查智能合约的字节码是否已经被分析过，如果分析過了就不再分析。

#### Early identification 的缺陷
* 内部交易不记录在区块中

#### *Solution*
TokenAware监控所有内部交易的执行，并从每个内部交易中提取EVM字节码以部署智能合约。提取出来的字节码也被添加到任务队列中，用于簿记识别。

### Phase 2: Behavior Inference
* TokenAware提供了4个命令来操作缓存中的数据并执行分析活动。阶段2提供暂停智能合约过程的能力。

#### Commands:
1. CALL
2. DELATEGATECALL
3. CALLCODE
4. STATICCALL

将代码插入到以太坊节点中，在智能合约执行过程中获取执行机会，从而令牌感知可以监控并暂停智能合约的执行。

TokenAware应用了优化技术(即O4: pipeline)，它能够从智能合约中识别记账，并同时运行不调用合约的后续交易。因此，管道加快了标记感知，因为后续的事务可能不需要等待记账识别的结果。


它将识别当前的opcode(即opcode变量)是否是用于定位簿记项的指令序列(priorSeq变量)之一。一旦TokenAware识别出当前操作码用于定位簿记项，它就会将操作码(即opcode变量)及其操作数(即traces变量)附加到第5行的指令序列(即priorSeq变量)中。

bookkeeping is a set of tuple <addr, delta>

记账识别包括四个步骤:

1. 它们学习指令序列，以定位每个基本容器中的一个元素。($1)
2. 它们通过对定位基本容器中某一元素的指令进行组合，得到定位基本容器中某一元素的所有可能组合的指令序列。($2)
3. 他们搜索EVM字节码中的所有派生指令序列，以确定智能合约中使用的指令序列以及指令序列的组合方式。($3)
4. 最后，通过检查指令序列的组合方式来识别智能合约的记账。（$4)

## BOOKKEEPING RECOGNITION

### Bookkeeping Definition

> Pseudocode representation

// addr類型: 表示token holder's地址
// size_t: 表示token holder's 擁有多少token數量。

unordermap<addr, size_t> Bookkeeping;

Bookkeeping["0x00700721"] = 13;

### Basic Containers ($1)

Solidity只有4種基本容器，他們学习定位每个基本容器中元素的指令序列(至少有一条指令)，他们首先编写定义和初始化基本容器并修改其中一个项目的Solidity代码，然后将源代码编译为EVM字节码，最后通过对字节码的反向工程获得内存布局和指令序列。


如上圖所示，兩種基本容器結構體和一維數組的內存布局是相同的。

结构变量具有唯一的id，结构项的位置是id和从该项到结构变量开头的偏移量的总和。


树中的每个圆圈表示一条EVM指令，每个矩形表示数据。

他們忽略以下指令:PUSH用于在堆栈上压入一个数字，DUP SWAP AND MSTORE LT，因为这些指令在所有智能合约中都经常使用，它们无法区分定位记账项和其他操作。

映射变量有一个唯一的id，每个项将一个键映射到一个值。圖Fig8示出了定位映射项值的指令序列。SHA3指令用于计算哈希值，这是值的位置。SHA3的操作数由两部分组成。第一部分是键，第二部分是映射变量的id。


Fig9表示用于定位一维动态数组项的指令序列。从圆(即指令)到矩形(即数据)的边表示数据是该指令的结果。每一个一维动态数组都有一个唯一的id。数组的长度记录在位置中，该位置是SHA3的结果，其操作数为id。数组项放置在记录数组长度的位置之后。因此，数组项的位置是SHA3结果与从数组项到数组长度位置的偏移量的总和。


### Container Combinations ($2)

由于簿记也可以是基本容器的组合，我们通过合并表示定位基本容器项的指令序列的树来导出定位容器组合项的指令序列。具体而言，我们确定了两种容器组合模式(C1和C2)，并针对它们设计了不同的合并策略。


C1(可变构图模式)。在这种组合中，每个基本容器都是一个变量，一个容器变量读取另一个容器变量的值。定位变量组合项的指令序列由三步推导。首先，添加一个表示一个容器变量值的矩形和一条将容器变量的树与矩形连接起来的边。其次，添加SLOAD指令和连接第一步添加到SLOAD圆的矩形的边，表明容器变量中的值被读取为[51]。第三，添加一条连接SLOAD循环到容器树的边，表明SLOAD指令读取的值被连接的模式使用。