APEC
Last updated
Last updated
APEC (Assets Protected Elastic Contracts) platform in Solidity is the major basic component in DeFi protocol.
As the core on-chain structure,APEC iswritten in Solidity and ensures decentralization and asset ownership while making adjustmentand improvementin contract development.
The core concept of APEC lies in asset security and component elasticity. It has three characteristics:
Asset protected
Logic upgradable
Data extensible
APEC iscomposed of three modules:
Data: Data from the classic contract structureis isolatedand madeinto data contract(s) for data storage. Only necessary read and write interfacesis revealed to the public.
Logic: logical contracts only cover business logic, not business data.
Router: The field data that the business logic needs to read and writecan be queried from the routing table according tothe data module and field name, and then accessed based on thepositioning result.
Routing Table
Routing table is an independent contract, which contains a routing comparison table that stores the routing swap of logical contract and data contract addresses. The routing tablecan be updated followingthe system upgrade.
After the deployment of the entire contract system, the address of each logical contract will be stored in the routing table. External requests can be granted and access to the routing table to obtain the address swapping of the logical contract and callits interface. Data contracts can perform business logic call or callback through inquiring the routing table and obtainingthelogical contractaddress.
For each set of data, there will be an independent data contract of its own, and the address of the data contract will be automatically stored in the routing table when it is created. Before accessing the specified data, the logical contract will first obtain the data contract address from the routing table, and then read and write the data contract through the address.
Every group of data has its own independent data contract, whose address will be stored in the routing table upon creation. Before accessing certain data,thelogical contractwill first obtain the data contract address from the routing table, and then read and write the data contract viathe address.
Upgradable Logic
Logical contracts do not store assets nor business data. Hence, they do not involve asset security and data migrationissues, andtheyare upgradable and pluggable. After testing and audit, the new version of the logical contract can be deployed on-chain.
Data in swap tables of therouting table contract will be updated when deploying new contracts. The address swapping direction for the logical contract willalsobe modified for other contracts and application front-end to inquire and call.
ExpansibleData
As an upgradable application, its data structure is also required to be upgradable. However, due to data ownership and asset security requirements, data contracts cannot be upgraded. The method we adopt here is expansion. If new fields are required in a new business, the new fieldswill be stored in a brand new data contract. Meanwhile, the address and field name in this new data contract will be added into the routing table. Business logic can be read and written through the new field’s address obtained from the routing table.
The expansionof data contracts should be limited, as adding new data contracts without a limitwill increase the complication of the whole system and hence adversely affect its operating efficiency. Data expansion mechanism only makesit possible to upgrade the data structure. However, overuse of this mechanism is not encouraged.
When designing and using the data structure, we need to follow the classic contract design principlesand the best practice to come up with a sufficient and elastic data structure. In terms of data expansion, we need to exercise restraint to avoid the overusedata expansion mechanism.
Following the upgradable logical contracts and expansibledata contracts comes the issue of whether data ownership and asset security can be ensured.
It’s widely known that users’ assets are locked in contracts in traditional DeFi DApps. Smart contracts, especially those with open-source codes, guarantee that a third party is not ableto touch the assets locked in contracts. Moreover, the non-tamperability of contracts make it impossible to changethecodes once thecontract is deployed.
APEC adopts the method oftheseparation of duties to solve the asset security issue in an upgradable structure.
Business contracts can be modified and upgraded, while data contracts cannot as in classic contracts. During initialization, each data set automatically generates an initial data contract. Once this contract is deployed on the chain, its code logic cannot be modifiedanymore.
The data contract will maintain a swapping table of user addresses and asset details internally. Thisswapping table exists inthe data contract and only provides two interfaces- incoming and outgoing transactions, and other interface is not allowedto write or update this asset table.
Incoming transactions will be sent directly to data contract address and callthe incoming transactioninterface. After the users’ assets are locked into the contract, the user’s address and asset details will be recorded on the asset swapping table. And the logical contract will be called, then the business logic will be processed and recorded.
When making an outgoing transaction, the outgoing transactioninterfaceon the data contract will be calleddirectly and the contract will verify whether the user’s address exists in the asset swapping tableandthen callthelogical contract, calculate the transaction and finally make the transaction.
For any address that does not exist in the asset swapping table, the outgoing transactioninterface will notanswer itsrequest. This ensures that any asset that is going outbelongs to the original addressthatit went intofrom thelogic level, hence guarantees the ownership and security of assets. And even the operation team itself will not be able to tamper with or steal any locked asset.
It ensures users' asset ownership and security through the strict ownership constraints of data contracts, making APEC’s security philosophy adhere to the consistent concept of smart contracts, which has already exceeded “don’t be evil” and realized “can’t be evil”.
