基础组件 APEC

基于Solidity语言的APEC平台是DeFi协议的主要基础组件,APEC即Assets Protected Elastic Contracts,资产安全的弹性智能合约。

1.设计理念

APEC作为链上(On-Chain)核心架构,基于Solidity智能合约,并且在坚守去中心化和资产所有权的前提下,对合约开发中的不便之处进行了调整和优化。

APEC 的核心理念是资产安全和组件弹性,主要包括以下3个方面的特性:

Ÿ 资产安全,Assets Protected

Ÿ 逻辑可升级,Logic Upgradable

Ÿ 数据可扩展,Data Extensible

2.架构图

APEC技术架构图

3.技术构架

APEC 在整体上可分为3大模块:

数据(Data):把经典合约结构的数据部分独立出来,做成一个或一组数据合约,用于存储数据,对外只暴露必要的读写接口。

Ÿ逻辑(Logic):逻辑合约负责纯粹的业务逻辑,不含业务数据。

Ÿ路由(Router):业务逻辑所需要读写的字段数据,可根据数据模块和字段名称从路由表中查询,再根据定位结果进行访问。

路由表

路由表是一个独立合约,内含一个路由对照表,存储逻辑合约和数据合约地址的路由映射,可随系统升级持续更新。

合约系统在整个部署后,各个逻辑合约的地址就会被存储到路由表中,外部请求可访问路由表,获取逻辑合约的地址映射并调用其接口。数据合约也可以通过查询路由表获取逻辑合约地址,进行业务逻辑的调用或回调。

对于每组数据,都会有一个属于自己的独立的数据合约,数据合约的地址将会在创建时被自动存储到路由表中。逻辑合约在访问指定的数据之前,也会首先从路由表中获取数据合约地址,再通过地址读写数据合约。

逻辑可升级

逻辑合约不存储资产,不含业务数据,因此就不存在资产安全和数据迁移等问题,所以它是可升级和可插拔的。逻辑合约的新版本在经过测试和审计后,即可部署到链上。

部署新合约时会同时更新路由表合约中的映射表数据,更改路由表中该逻辑合约的地址映射指向,以供其它合约或应用前端查询和调用。

数据可扩展

作为一个可迭代升级的应用,它的数据结构往往也要求是可迭代的。但出于数据所有权和资产安全的考虑,数据合约不可升级。我们采用的解决方案是扩展。如果业务上需要添加新字段,这些字段会被存储到一个全新的数据合约中。同时,这个新数据合约的地址和内含的字段名称,会被添加和更新到路由表中,业务逻辑通过查询路由表,获取新字段的地址路由进行读写。

数据合约的扩展,应该是节制和有限度的。一味地增加新的数据合约,会提升整个系统的复杂度和运行效率。数据扩展机制只是把数据结构迭代的需求从不可能变为可能,不鼓励频繁和随意地使用这个机制。

我们在设计和使用数据结构时,仍然需要遵循合约的经典设计原则和最佳实践,设计充足和弹性的数据结构。对于数据的扩展,应始终保持克制的态度,非必要时不使用数据扩展机制。

4.资产安全

如果逻辑合约可升级,数据合约可扩展,那么随之而来的问题就是,用户的数据所有权和资产安全是否能得到保障。

众所周知,对于传统DeFi 应用而言,用户的所有资产都被锁定在合约里。智能合约,特别是代码开源的合约,通过代码公开的形式向用户保证,除了用户自己,没有其它任何人或程序可以染指用户锁定在合约中的资产。更进一步地,合约的不可修改性使得合约一旦部署就不会有代码的变动。

APEC 采用了职责分离的方式解决了在可升级架构下的合约资产安全问题。

业务合约是可修改和升级的,数据合约则秉承经典合约的理念,不可修改升级。在初始化时,每份数据集合会自动生成一份初始数据合约,这个合约一旦部署到链上就不可再修改其代码逻辑。

Ÿ 数据合约会在内部维护一个用户地址和资产详情的映射表。该映射表在数据合约内部,只提供用户资产的入账和出账两个接口,其它任何接口都无权写入和更新该资产表。

Ÿ 用户入账交易,直接发往数据合约地址,调用其入账接口。用户资产锁入合约后,在资产映射表中记录该用户的地址和其资产详情。然后再调用逻辑合约,处理和记录业务逻辑。

Ÿ 用户在出账交易时,仍然是直接调用数据合约上的出账接口,合约将校验用户的地址是否存在于资产映射表中,然后调用逻辑合约,计算出账数额,最后把资产直接转账给用户的请求地址。

Ÿ 任何不在资产映射表中的地址,出账接口将不响应其资产请求。在逻辑上保证了任何一份出账的资产,都属于当初投资入账的原始地址,确保了用户对投资资产的所有权和用户资产的安全。即使是运营团队自己,也无法篡改和冒领用户的任何锁定资产。

通过数据合约严格的所有权约束,保证了用户资产的所有权和安全性,使得APEC的安全哲学秉承了智能合约的一贯理念:超越了“不要作恶”(Don't Be Evil),实现了“无法作恶”(Can't Be Evil)。