一、设计目的
基于状态通道的链下支付特点，进一步扩展通道的功能，使状态通道更具通用性，包括：支持多个token的应用场景、支持通道内token互换的应用场景、支付跨链token链下互换的场景等，真正构建链下价值连接的纽带。
二、设计要求
2.1、通用通道的多token支持
现有通道只可以进行单一token的支付需求，通用通道要求能够在通道内支持多token的支付需求。包括：多token存款、多token取款、 多token直接转账、多token间接转账、多token的结算等，实现多token支付功能。
2.2、通道内token互换的支持
现有通道tokenswap是通过HTLC在两个不同通道内进行，通用通道要求在同一通道内支持tokenswap的请求,包括:直接通道tokenswap、间接通道tokenswap功能，并且要求tokenswap时具有原子性。
2.3、跨链token互换的支持
通用通道根据条件符合状态，将支持两种类型的跨链需求：一是两条公链上各自的通用通道之间满足原子性的跨链token 互换；二是在侧链支持下的多链token映射后的跨链token互换。
2.4、兼容性支持
通用通道将支持现有的ERC20 token标准，并延伸支持ERC20 扩展 ApproveAndCall和ERC223 token。在跨链场景下，延伸支持BTC、LTC等token协议。
三、通用通道设计方案
3.1多ERC20token支持设计
多token通用通道设计示意图
通用通道功能需要通道具备通用支付的能力，如上图所示，A→B之间的通道内，可进行TokenA、TokenB、TokenC、TokenD四种token的通用转账支付。通用支付可用于诸多场景，用户不用为每一种token建立单独通道，如A向B发送转账，A→B之间如果待支付的token类型是A和B之间的通道支持的token类型，通过通用通道可以实现多种token的支付需求。
3.1.1合约模型设计
与现有的支付通道原理相同，通用通道安全性依赖于公链上的智能合约。为支持多token的功能需求，需要在原有合约的基础上进行扩展，构建支持抵押多个token的智能合约。我们将多token合约设计为两种模式：一种为单链应用的多token合约，一种为跨链应用的多token合约。相应的通用通道定义为狭义通用通道和广义通用通道。
单链应用的多token智能合约相对跨链应用的合约较为简单，复杂度和难度相对较低，更容易实现，因此本节先简要介绍单链合约的设计思路。当前，photon状态通道合约的类型分为两种：一种是一个通道一个合约（0.3版），另一种是一个token一个合约(0.8版),这两种合约均不能支持同一通道多种token的支付需求。新设计的多token智能合约不再基于单个的token网络或通道，而是以账户为单元，把拟包含的token类型纳入账户合约，构建账户之间的通用通道。账户合约允许保存多种token类型，每一种token类型在账户合约中预留一个slot,各个slot之间相互不重叠，可以独立使用。当发生不同token的链上合约事件（交易）时，合约对事件的处理结果保存在对应的slot存储单元中，并提供相应接口供用户查询和调用。多token合约作为链下多种token资产的锚定，对资产安全性的要求更高，出于谨慎考虑，先设计常规应用场景功能，扩展和延伸需求待合约升级时再进一步支持。
3.1.2主要功能设计
单链多token通用通道具备现有状态通道的主要功能,以photon0.8版合约为参考，在此基础上新版智能合约中需要具备以下主要功能。
（1）多token通道打开
合约设计时，可明确支持的token数量和类型。多token通道创建时，默认支持合约中规定的token类型及数量。由于通用通道的使用需要向合约中抵押token，并且合约内预设的多token存储容量过多需要花费较多成本，因此从成本和效益的因素考虑，可以根据常用token选择限定几种token作为默认设定，特殊需求时，作为参数引入作为补充。
（2）多token通道存款
存款功能用于在通道某种token容量不足时补充其相应的通道余额。多token存款与现有存款功能实现原理相似，用户可以通过合约调用进行多种token的存款，用户进行某种token存款时，通过映射存入对应的token slot中。存款完成后，相应的token slot中的对应的token余额增加，其余token slot中余额不变。
（3）多token通道取款
取款功能用于在通道容量较大时不关闭通道取现。多token取款与现有取款机制相同，要求取款的token类型链下无锁定转账，取款后相关token历史信息清零，以防止重放攻击；在满足条件情况下，支持合约调用从token slot中对多种token进行取款,取款完成后，通用通道对应token slot中token余额减少，相关参数清零，其余token slot中余额不变。
（4）多token链下转账
链下转账是通用通道的核心功能。包括直接通道转账和间接通道转账。多token转账与现有的token转账模式相同。如Alice想发送tokenA给Bob，如果Alice和Bob之间有直接通道相连，因为通用通道内Alice存有tokenA，所以Alice可以直接将tokenA转账给Bob；如果Alice和Bob之间没有直接通道，但Alice和Charlie，Charlie和Bob之间有通用通道，可以通过Charile中转实现链下支付。同理，如Alice想发送tokenB给Bob，仍然使用她们之间的直接通用通道或间接通用通道进行转账。考虑到目前并发场景应用需求不明确，因并发间接转账对中间节点的要求较高（为了保证通用通道转账支付的整体性，功能设计中要求原子性，如一次性并发tokenA和tokenB转账，中间节点Charlie和Bob之间的通用通道中需要tokenA和tokenB的余额均充足才能转账成功，否则两笔转账都失败），为简化设计复杂度，本版本中暂不支持并发转账，待需求确认后版本升级时再引入。
（5）多token通道关闭与结算
多token通道关闭和通道结算，保证账户节点可以最终拿回自己应得的token。通道一方可以只关闭某种token slot，提交该token slot中交易的余额证明进行结算；结算后，该token slot将不能继续使用，通道中未关闭的token slot中的token仍然可以继续交易。如果不再使用这条通用通道，需要将通道中所有的token slot均关闭。多token slot依次结算后，通用通道结算完成，结算后在链上从合约中获得应得的所有类型的token，该通用通道被销毁。
3.1.3适配性设计
当前以太坊和Spectrum均支持ERC20token,多token意味着该区块链上发行的多种token可以被链上的智能合约同时容纳。当某种token的条件触发时，根据合约中预设的操作进行处理，相对单一的token类型，通用通道的兼容性更强，但设计模式仍然基于以太坊和Spectrum的共识机制，因此，在开发和使用上与现有的智能合约保持一致。
通用通道的链下处理流程中，对事件的解析方式将保持不变，但对原有功能的数据模型需要进行重新构建，新数据模型将支持多种token的业务逻辑需求；在收发消息的处理流程上需要更加细化，区别不同slot token请求、事件及状态改变产生的本地行为处理；通信机制上，继续采用Matrix集群管理方案以支持多token并发状态下的通信需求；路由设计上将构建多token通道拓朴和单token slot拓朴延展模型，对整体token事件和不同slot token事件产生的拓扑变化进行关联处理；在安全防护设计上，为保证交易节点状态数据的同步，要求保证节点意外掉线或退出情况下，节点重新启动后，节点不会丢钱，通道slot可以继续使用; 无网和移动适配方面，相应增加多token功能接口支持，并对移动设备的性能和体验需求提供特殊处理机制；第三方服务对相应接口进行更新，以支持多token提交证明及收费的扩展。
3.2通道内token互换的支持设计
通用通道内可以同时容纳多种token,因此，除了正常的通道打开、存款、取款、转账、关闭和结算功能之外，在同一个通道内的按照原子性的设计，可以实现token互换功能。
3.2.1直接通道token互换
通用通道是建立在两个账户之间的通道，通道的双方各自存有多种token类型。如果进行token互换的账户节点之间有直接通道，各自都有对方需要的token类型及token数量，并且双方在链下达到了交换的比例与意见，则可以使用通用通道，实现两种或多种token互换。为保证交易的原子性，通道双方的互换交易需要进行HTLC设定，Bob给Alice发tokenB,Alice给Bob发tokenA,需要保证Alice收到tokenB后一定会给Bob发tokenA,并且互换的两笔转账要么都成功，要么都失败。
举例如下：
设通用通道智能合约ContractU,默认支持tokenA 和tokenB。则Alice和Bob使用ContractU，构建了通用通道ChannelU。以下为交易过程（图中MTR为带secret和时间的转账交易）：
以Photon为例：
Bob生成X的哈希值R(X)
Bob用R(x) 48小时内发送MTR2给Alice
Alice用R(x) 24小时内发送MTR1给Bob
Bob给Alice X，Alice 48小时内拿到tokenB.
Alice给 Bob X, Bob 24小时拿到token A.
通过HTLC原子交换，可以在同一个通用通道内实现两种token的交易。当然，如果Alice和Bob在其他token slot余额充足的情况下，Alice仍然可以使用TokenA换取Bob的TokenC、TokenD等，反之，Bob也可以进行同样的互换处理。
3.2.2间接通道token互换
Alice和Bob之间如果没有直接通用通道，需要通过中间节点才能建立链下支付时，只要双方通过的中间节点能够在通道网络中将这两种token的中转转账形成环路，并且中转节点拥有足够数量的两种token，也能实现token的原子互换。如上图，Bob将tokenB的中转转账发送给Charlie,通过Charlie将这个token的互换交易发给Alice,而后，Alice再通过Charlie再TokenA的互换交易发送给Bob。这个过程中，因为Charie拥有tokenA和tokenB两种token,并且余额充足，Charlie将两种token环接了起来，保证了HTLC的正常实施。实施流程如下：
以Photon为例：
Bob生成X的哈希值R(X)
Bob用R(x) 48小时内发送MTR2给Charlie
Charlie用R(x) 48小时内发送MTR2给Alice
Alice用R(x) 24小时内发送MTR1给Charlie
Charlie用R(x) 24小时内发送MTR1给Bob
Bob给Alice X，Alice 48小时内拿到tokenB.
Alice给 Bob X, Bob 24小时拿到token A.
借助中间节点和HTLC，Alice和Bob可以在通用通道中实现token互换。
3.2.3适配性设计
通用通道的token互换，建立在互换的两种(或多种)token余额充足以及HTLC可以正确实施的基础上，另外就是双方对换token的比率需要预先商议。鉴于上述条件，为使多token互换成为通用通道的一个常用场景，在tokenswap链下设计时，提供token汇率接口，合约token锚定主链token，通过主链token的价格自动生成相应的兑换价格和数量，用户可以即时和准确的根据及时汇率和自设定汇率进行token互换；由于间接通道token互换需要对中间节点的token种类和数量有一定要求，因此，在通用通道网络中，设定部分超级节点，拥有较多的token类型和数量，并和相对多的账户节点建立通用通道，对间接通道token互换提供路由支持。
3.3跨链token通用通道互换的支持设计
token互换支持同一公链上的token进行交易，对于不同区块链上的通用通道token互换，有两种方式可以实现。
3.3.1 HTLC跨链token互换及支付
与单链上 tokenswap原理相同，在两条支持通用通道的公链之间，可以通过HTLC实现token的原子互换。
假设Alice在以太坊上有账户CA1，存有10tokenA和20tokenB，在光谱上有账户CA2,存有20tokenA’和10tokenB’。Bob在以太坊上有账户CB1,存有20tokenA和10tokenB，在光谱上有账户CB2,存有10tokenA’和20tokenB’。Alice 在去中心化交易所上发布信息,希望用10个tokenA置换10个 tokenA’; Bob 看到以后,和 Alice 进行沟通,达成交换意见。Alice在以太坊上通过photon向Bob发送（10tokenA）,换取Bob在光谱上的(10tokenA’)。Bob收到转账请求后，在光谱上通过Photon向Alice发送（10tokenA’）。通过双方钱包的接口调用（支持HTLC），实现跨链token原子交换。交换后，Alice CA1账户为（0tokenA,20tokenB）,CA2账户为（30tokenA’,10tokenB’）,Bob CB1账户为（30tokenA,10tokenB）,CB2账户为（0tokenA’,20tokenB’），双方原子互换完成。
HTLC跨链互换同样存在直接通道和间接通道互换的情况，但不需要对中间节点有过多设定；另外，对于跨链支付情况，只要中间节点在两个区块链上都有互换的token，可以进行跨链支付。
假设Alice在以太坊上有账户CA1，存有10tokenA和20tokenB。Bob在光谱上有账户CB1,存有20tokenA’和10tokenB’，Charile在以太坊上有账户CC1,存有10tokenA和20tokenB,在光谱上有账户CC2,存有10tokenA’和20tokenB’。
Alice和Charlie在photon上有通用通道，Charile和Bob在Photon上有通用通道。Alice和Bob约定，由Alice向Bob支付5tokenA’,但Alice没有tokenA’,在与Charile商议的基础上，可以通过通用通道使用photon 将5token发送给Charlie,Charile在收到支付请求后，通过通用通道使用Photon将5tokenA’发送给Bob,支付过程使用HTLC设定，保证支付交易的原子性。
以上HTLC设计需要通过Atmosphere跨链服务支持，并在跨链原子交换接口中提供多token支付。
3.3.2侧链映射跨链token互换
HTLC跨链支持的token互换有一定的适用范围，要求token互换的公链必须有支持HTLC的layer2存在，且互换的token种类有限。如果要进行多条公链上的token互换，可以借助侧链的思想，由一条侧链挂钩多条公链，将多链的token资产映射到侧链上，在侧链上构建通用通道互换后，再根据需要解锁回原链，可实现跨链的多种token的互换。
应用场景：假定比特币、以太坊、光谱、莱特币需要通过通用通道进行token互换，可以通过（lock-in的方式锁定）映射在侧链上生成对应的tokenA,tokenB,tokenC,tokenD。生成的token与锁定token比例为1比1(具体比例可以额外设定)。在侧链上的TokenA,TokenB,TokenC,TokenD可以继续构建多token合约，在合约的基础上构建多token通用通道。拥有多种token的账户节点既可以在侧链上通过合约进行交易或互换，也可以在链下通过通用通道进行交易或互换。待多次互换完成后，如果用户想换回对应数量的原token，可以通过（lock-out的方式解锁）将侧链token解映射回原链token。解锁原锁定token后，生成的侧链token自动销毁（由合约自动完成）。
3.3.3适配性设计
（1）支持多链的侧链（UTC）设计
侧链共识基于POS机制，可以读取挂钩的多条主链的区块头部信息，获得多条挂钩主链上发生事件信息。在此基础上，侧链可以采取分布式密钥与智能合约相结合的形式实现多链资产的映射。以BTC和UTC(侧链)跨链为例，跨链思路如下：假设用户Alice想将1BTC兑换100MMC(侧链上的一种token)，她需要发一份转账请求给UTC侧链（通过lock-in合约），UTC侧链通过分布式密钥计算出比特币上的一个特定地址X，Alice将1BTC发送到地址X； UTC侧链得知1BTC交易确认完成后，在UTC上给Alice的在UTC链上账户UAlice释放100MMC。Alice在UTC侧链上通过链上或链下通用通道给Bob转账50MMC。如果，Bob想将MMC换回BTC,他可以向UTC发送一笔向外交易BTC的请求（通过智能合约lock-out）给自己的BTC地址Y;UTC合约锁定Bob50MMC，触发所拥有的BTC存量，在阈值签名认证基础上通过比特币网络给Bob的比特币地址Y发送0.5比特币，完成MMC向BTC的转换,交易被确认后，合约锁定的50MMC被销毁。其中，侧链对BTC交易的确认通过智能合约调用的形式实现，采用SPV模式确认交易的完成并实施相应的token映射。
节点组示意图
为了实现分布式密钥的计算和验证，侧链由多个物理节点的节点组组成。每一组的节点将联合处理分配给他们的交易，不同组之间的工作相互不重叠。记账节点通过POS共识产生，从网络中所有节点中选举出参与计算物理节点，获胜的节点（节点集合中的一个节点）赢得交易打包的权利。多个记账节点根据算法动态组成节点组，用于分布式密钥的计算、存储、阈值签名等工作。节点组的生成算法如下：首先每一个智能合约将设定处理自己的组数字。例如，智能合约ABC设定组数字为X,并采用来决定组的成员。其中，输入参数y来自于前一个区块的hash,我们将它设为。条件设定为z（预设函数生成的输入值），公共地址设定为。那么，通过公式,每一个记账节点可以确认自己的组。上面的算法也用来决定哪一组将计算哪个交易，例如智能合约ABC定义X组将进行交易计算，节点组和对应交易的关系因此被建立起来。每一个节点组将决定一个节点成为代表,节点组的代表竞争打包权，建立新块。
（2）分布式秘钥方案设计
为了保证跨链映射数字资产的安全性，跨链通用通道模型采用分布式密钥方案对私钥进行分片及分布式存储。侧链UTC上分布式密钥的产生和使用如下：
- 分布式密钥产生
UTC上的多个组节点通过分布式的方式产生分布式密钥。每一个节点只产生和存储私钥的一部分，不传递和组装私钥。在这个过程中，使用密钥分片算法确定分片数量，根据分片的数量形成多个记账节点组来确定私钥片。为了保证私钥片在计算中处于可用状态，节点数算法将保证一组中掌握密钥片的大部分节点同时下线的概率极低。同一组中节点根据确定的分片长度随机和独立产生每一个私钥片，节点根据共识形成最终分片密钥片的值。 - 私钥的计算
使用私钥需要通过分布式加密计算。当一个交易签名认证被广播，节点可以基于它存储的密钥片进行计算和比较。当认证成功，节点签名和广播密钥片的认证结果。在这个过程中，每一处分片结果是不可逆的。密钥或任何分片不能从内容广播中推测出。当前，哈希算法和椭圆曲线算法可以支持私钥分片和分布式计算。对于不支持分片计算的链，可以采用同态加密实现密钥计算。
 - 交易确认（阈值签名认证）
当节点完成私钥片的认证，节点从广播中收集私钥片签名结果，当交易的签名数达到一个阈值时，交易被认为是有效的。在UTC的分布式签名过程中，如果一个节点（具有某个私钥片）从网络中退出，签名将失败，交易不能完成。UTC侧链使用阈值签名机制，在一组m个节点中，如果签名节点数大于某个阈值t,签名可以认为完成。根据分布式密钥产生网络的节点情况，为保证UTC链的有效操作，在极端的情况下UTC选择候选节点加入和更新分片密钥参数。
（3）通用通道主要合约设计
- Lock-in合约设计
用户在UTC上发起一个lock-in请求的过程类似在当前钱包里转账token。具体的实现步骤如下：

设计步骤：
（1） 开始一个Lock-in请求
用户A通过使用钱包里的LOCK-IN API（UTC的合约接口供钱包调用）发起一个10 BTC LOCK-IN请求（接口参数包括代表用户身份的公钥和币类型）到UTC（发到 UTC上的一个智能合约地址,对合约进行调用）。
（2） 私钥生成
LOCK-IN请求操作触发一个UTC上的LOCK-IN智能合约，组织一个私钥生成过程。所谓的私钥生成是以分布式的方式生成私钥。在这个过程中，智能合约将完成密钥的分片以及密钥片的分布式存储。
（3） 资产锁定
生成的私钥将产生一个相应的比特币区块链上的地址，用户A将BTC转到那个地址。用户A的转账操作（事件）将通过UTC接口发起一个广播，UTC节点检查这个转账是否完成（检查比特币链上的交易是否完成）。
当UTC链上节点收到交易的广播后，将通过第三方接口检查是否这个交易已经被比特币区块链确认（获取交易完成信息）。 如果结果显示操作已经成功，10BTC已经转到LOCK-in产生的地址，可以认为比特币已经成功被锁定。
（4） 映射token
确认了比特币的资产锁定后，智能合约将更新UTC上用户A的账户状态（用户A的账户由lock-in发送请求中的公钥产生）。LOCK-in记录将被打包和记录在UTC 区块链上。这时，用户A 10 BTC LOCK-in请求完成。 - Lock-out合约设计
用户LOCK out请求也是调用钱包内相应的API(lock-out合约地址)。步骤如下：
（1）发起一个lock-out请求
用户A操作钱包向UTC侧链发起一个10-BTC转账交易到一个比特币地址, 作为一个Lock-out请求（用户想将自己映射的token换回BTC，让UTC将比特币发送到自己的比特币地址上）。
（2）检查、锁定和产生交易
交易触发UTC上LOCK-out智能合约。合约将首先检查用户A在UTC上的资产状态，锁定用户A UTC账户中映射的10BTC 状态，使用用户A的签名产生一个用户到比特币地址的交易请求（认为用户A具有这种10BTC的所有权）。
（3）阈值签名
UTC链上节点收到交易请求，根据他们存储的key shards开始计算和比较,如果结果为正，节点将签名并广播这个结果。同时，每一个节点收集签名,当这个交易的签名数达到阈值t (t<=m),这个交易被签名认可，将被节点发送到比特币主网， 10 BTC交易转账将完成。
（4）确认交易
UTC上的节点通过对应的比特币接口检查是否这个交易在比特币区块链上被确认。交易被确认后，10BTC发送到用户A的地址。
（5） 释放token映射并销毁
智能合约将同步用户A在UTC账户上的状态，释放锁定的10BTC 映射并销毁这个映射。同时，这个LOCK-out记录被打包进UTC区块。这时，用户lock-out请求完成。 - 多token合约设计

多token合约多链交互原理图
多token合约存储UTC侧链上多种映射token。在此基础上，构建链下通用通道。与单链多token合约的设计思路相似，多链智能合约也具备容纳多种token的能力。此外，跨链多token合约可以与lock-in和lock-out构成松散的嵌套调用组合。如上图，用户A希望用10BTC换取用户B的200ETH，用户A通过lock-in 合约将映射币10BTC’存入多token合约中用户A的多token账户;同理，用户B的多token账户中也存入200ETH’。基于多token合约，可以构建链下的多token通用通道，称之为wormhole。用户A和用户B在链下使用HTLC构建tokenswap互换。互换完成后，BTC’和ETH’可以继续在链下使用，也可以通过嵌套调用返回LOCK-out账户。最后，当用户A需要在公链上结算时，用户A可以通过lock-out请求从侧链上解锁她互换的200ETH（通过钱包的以太坊接口），实现跨链资产的互换和交易。通过设计跨链多token智能合约在不同条件下和lock-in和lock-out的交互规则，在不同的值和参与者之间，在时间和空间上，使UTC上的跨链多token智能合约具有支持多token交互操作的灵活性。此外，根据多token账户合约的应用需求，可以进一步预设条件和业务逻辑构建网状的智能合约调用关系，在不同的应用中构建价值交互，提供复杂应用的可行性。UTC上的多token跨链合约不仅能够更新账户状态和值，而且在满足触发条件的基础上在执行期间能够调用另一个智能合约或被另一个智能合约调用。以多token智能合约A调用智能合约B为例：（1）构建一个智能合约对嵌套调用
在智能合约A的代码中，将目标智能合约的地址作为参数索引，对调用智能合约B设定一个预设的条件判断和一个预设的条件规则，判断和条件的基础来自于智能合约A被触发和数据计算的结果。预设条件包括两部分：规则和时间。规则是在智能合约中提前写好的计算功能。时间条件可以是智能合约预设的条件，当运行一个智能合约时触发，或者一个周期性检查智能合约状态的条件。（2） 嵌套调用过程
当智能合约A被触发，根据预设的调用条件，判断是否有必要执行智能合约B。当调用条件满足，预设的计算函数被执行，计算结果将作为智能合约B的输入。通过节点下载智能合约B到本地计算环境（已经执行了智能合约A），输入已经前述步骤中计算的数据作为智能合约B的输入，开始执行智能合约B。通过上述的步骤，多token智能合约A实现对智能合约B的调用。因此，多token合约可以与其他合约配合应用，为链下通用通道的跨链token互换构造功能基础。
四、研发计划及相关工作
4.1项目实现步骤
根据项目的设计方案，初步将整个研发计划分为以下八个步骤。其中前五个步骤，作为单链通用通道的研发步骤，后三个步骤作为跨链通用通道的延伸研发步骤。
- 单链多token合约设计对现有token合约进行修改，提供多token功能支持。
- token swap功能设计
对现有token swap功能提供多token支持。 - 合约功能接口设计
根据多token合约设计相应功能接口。 - 链下信息流程设计
根据链下多token业务进行逻辑信息流程设计。 - 功能实现及测试
修改代码实现合约设计主要功能和链下多token支付功能，并进行相应性能测试。 - 多token侧链设计
对多token侧链方案进行细化，对挂钩的不同公链进行针对性方案设计。 - 跨链多token智能合约设计
设计跨链多token合约、lock-in和lock-out合约。 - 跨链功能设计及相应代码实现
进一步实施方案，进行代码实现和功能测试。4.2 项目的准备
在项目方案中，虽然单链的通用通道基于目前的photon进行适配性修改设计，但通用通道将与原有photon不再兼容，因此，通用通道将会以Wormhole命名，所有代码均作为新项目更新和维护。第二，延伸开发中一些技术难点目前可参考的技术实现较少，重庆雷电在单链的开发过程中将同时进行相关技术的梳理，因此需要进行相关储备研究工作，以便后期开发时项目进度的正常进行。第三，项目研发过程中，原photon项目将仍然需要维护和技术支持，如确定新项目启动，原项目的技术支持的时间将自动作为新项目增加时间，以保证项目的开发质量。
4.3 项目的实施
项目将按照合约设计→流程设计→消息设计→代码设计→功能实现→功能测试的步骤实施，项目组成员按照开发任务进行分工，分别进行功能代码实现、接口实现、数据库实现、通信实现、功能测试、性能测试等工作，根据任务的难度进行独立完成和协作完成。实施过程上，如有更好的解决方案，需对局部方案进行调整，在不影响整体进度的前提下，选择性能更好的方案进行研发，保证项目的整体创新性和功能稳定性。
