智能合约设计模式--策略模式

引言

以太坊是由vitalik在2013年提出的一种公有区块链。目前，以太坊已经是继比特币之后的市值第二的加密货币项目，许多基于以太坊的Dapp项目正处于运营状态，并且全球各地的研究人员都在关注着以太坊。它之所以能够受到如此众多的区块链爱好者的关注，是因为以太坊能够在链上执行图灵完备的编程语言，因此以太坊也被称为区块链2.0。

以太坊因其具有图灵完备的编程语言而受区块链的研究人员所追捧，然而其智能合约的设计方式却存在令开发人员困扰的问题。当智能合约的开发人员将合约发布到区块链上后，将无法在修改合约的代码，特别是当用户需求增加，发开人员不得不重新部署智能合约。当项目比较庞大，涉及多个智能合约，这样的更新方法费时费力。

以太坊的智能合约代码以key-value的形式存储于账户中的codehash字段下，最终这个key会与该账户的其他属性以及其他账户中的属性共同作为默克尔树的节点生成默克尔树根存储于每一个区块中。出于数据不可篡改的目的，智能合约的代码一旦被提交到以太坊上，那么就永远无法修改。目前，以太坊DAPP相关开发人员已对此提出一些方案来处理代码提交后不可以修改的问题。本文将策略模式应用到DAPP的智能合约设计过程中，使得智能合约代码能够动态扩展所需业务逻辑算法。

背景

以太坊EVM是当前区块链行业应用最为广泛的虚拟机。其所支持的智能合约语言是图灵完备的。该语言支持各种基础类型（Booleans，Integers，Address，String，Enum，Address等)、复杂类型（Struct，Mapping，Array等）、复杂的表达式和控制结构及接口继承等面向对象的特性。正是由于强大的智能合约语言，原本在真实世界中的复杂商业逻辑和应用都能在区块链上轻松实现。由于区块链运行机制的原因，智能合约的运行即使是异常运行都会在所有区块链节点上独立重复运行。并且所提交智能合约代码难以进行更新。

智能合约与传统应用程序有一个不同的地方在于智能合约一经发布于区块链上就无法篡改，即使智能合约中有Bug需要修复或者业务逻辑变更，它也不能直接在原有的合约上直接修改再重新发布。因此在设计之初就需要结合业务场景考虑合理的升级机制。

CD模式

https://www.jianshu.com/p/9316c0715d2c

CD（controller-data）模式的设计思路是将业务控制逻辑和数据从合约代码层面做分离，使得更新业务逻辑时，能够保留用户原有数据不变。因此它的合约包含控制器合约（controller contract）和数据合约（data contract）。程序执行流程如下：

控制器合约通过访问数据合约获得数据，并对数据做逻辑处理，然后写回数据合约。它专注于对数据的逻辑处理和对外提供服务。根据处理逻辑的不同，常见的有命名空间控制器合约、代理控制器合约、业务控制器合约、工厂控制器合约等。一般情况下，控制器合约不需要存储任何数据，它完全依赖外部的输入来决定对数据合约的访问。特殊情况下，控制器合约可以存储某个固定的数据合约的地址或者命名空间（通过命名空间在运行时获得合约地址）。

数据合约专注于数据结构定义与所存储数据的读写裸接口。为了达到数据统一访问管理和数据访问权限控制的目的，最好是将数据读写接口只暴露给对应的控制器合约。禁止其他方式的读写访问。

基于这个模式，遵循从上至下的分析方式，从对外提供的服务接口开始设计各类控制器合约，再逐步过渡到服务接口所需要的数据模型和存储方式，进而设计各类数据合约，可以较为快速的完成合约架构的设计。

策略模式

策略模型是面向对象的经典软件模式设计方法[3]之一，最早在1994年提出。策略模式作为一种软件设计模式，指对象有某个行为，但是在不同的场景中，该行为有不同的实现算法。对于不同的应用场景，能够进行动态添加算法，这非常适用于具有不可篡改特性的智能合约来使用。
策略模型的结构为：
a) 策略接口角色IStrategy:用来约束一系列具体的策略算法，策略上下文角色ConcreteStrategy使用此策略接口来调用具体的策略所实现的算法。
b) 具体策略实现角色ConcreteStrategy:具体的策略实现，即具体的算法实现。
c) 策略上下文角色StrategyContext:策略上下文，负责和具体的策略实现交互，通常策略上下文对象会持有一个真正的策略实现对象，策略上下文还可以让具体的策略实现从其中获取相关数据，回调策略上下文对象的方法。

策略模式定义了一系列的算法，并将每一个算法封装起来，使每个算法可以相互替代，使算法本身和使用算法的客户端分割开来，相互独立。策略模型的UML图展示如下：