ViteX生意业务所要实现订单笼络僻静台经济模子的两个焦点成果，假如放在一个合约内里实现，未便于问题的聚焦，会造成问题的开拓人员及外部接口利用人员的狐疑，很自然的想到把他们拆分。别的，笼络引擎从观念上是基本成果，从设计之初并差池外直接袒露接口，和经济模子解耦后，便于后续的笼络引擎进级。详细拆分的两个合约是dexFund和dexTrade，dexTrade实现订薄弱存储及订单笼络的成果，dexFund完成资产、挖矿及分红等ViteX经济模子相关成果。
要晋升笼络机能就必需要能快速的匹配待笼络订单，常用的做法是将头部订单可能全部订单都放入内存来实现高效的会见。可是对付链上合约来说，因为受限于链底层提供的接口本领会见存储，不能做到订薄弱常驻内存。这时候可以思量方法是充实操作底层存储的特点，担保订薄弱有序存储，这样笼络进程只需要依次简朴迭代会见就可以了。由此我们获得了《ViteX内置合约设计与实现简介》所先容的订单id的设计方案，通过把价值作为订单id的一部门，而订单id是底层key有序levelDB的存储key，这样订薄弱在底层存储就是价值有序，通过简朴的key顺序遍历即可完成笼络进程。这样的实现足够简朴也很是高效。
因为订薄弱的存储是在dexTrade合约，撤单直接和订薄弱交互，所以最初的撤单进口也是放在dexTrade。可是下单成果因为会涉及到资金冻结所以是以dexFund合约为进口的，这就导致了下单和撤单有差异的进口。在合约实际执行的进程中会呈现订单下单后因为链上共鸣延迟没有写入dexTrade订薄弱就举办撤单的环境，此时撤单操纵会因为不能从订薄弱查到订单而导致执行失败。为此，我们在dexFund合约新增了撤单进口，对同一个订单来说因为是同一个用户发出的生意业务，通过用户链的生意业务顺序性担保撤单操纵必定会在下单后上链执行，有效的撤单必定可以正确执行。比拟两个撤单进口可以或许发明，dexTrade合约的撤单进口因为制止dexFund合约的转发所以越发直接和轻量级，而dexFund合约因为颠末尾dexFund合约会需要特另外开销，可是该进口提供了署理撤单的先验操纵，所以假如是署理撤单就必需走dexFund合约来撤单， 详细来说dexTrade撤单进口适合及时性要求不高的普通用户，而dexFund撤单进口适合对及时性要求较高的自动化挪用。
5.淘汰存储占用的一些步伐这是第三篇给各人先容关于ViteX的技能文章，本篇文章主要从ViteX整体设计、机能优化及系统靠得住性三个方面先容了vDex内置合约的设计配景、思路及方案。但愿各人能更深入的领略ViteX运行机制。
6.vDex如何提高靠得住性
ViteX作为去中心化生意业务所，通过内置合约vDex实现笼络引擎及ViteX经济模子的相关成果，在实现高机能的同时分身实现的简捷，简朴的系统更结实。在之前的一篇文章《ViteX内置合约设计与实现简介》中我们已经就内置合约的要害设计细节举办了先容，本篇文章从几个较量有代表性的问题入手先容一下相关的设计配景、思路及方案。
1.vDex为什么要分两个合约来实现
2.为什么会有两种订单id
4.订单笼络机能问题
作为内置合约，vDex每行代码的实现都是协议，要担保协议的执行正确性，除了通过测试发明问题外，从设计之初就思量如何提高模块的靠得住性。vDex在最初设计的时候，一条重要的原则就是要分身简捷和高机能，过于巨大的设计会成倍提高代码量，同时堕落概率也会相应增加。以简捷为原则，我们的相关数据布局都只管精简字段，不相关的信息不做存储，可能放到链下存储，链上只处理惩罚凡是不会改变的焦点数据布局，极力制止信息冗余，通过链下配套处事来实现传统生意业务所的多维度的富厚查询和展示。代码实现层面，节制单个函数的代码行数，当令举办拆分和经心定名，节制巨大度的同时也极大淘汰了反复代码的呈现，布局更公道之后，每个实现细节也就更清晰，便于领略而不容易堕落。最后，通过《ViteX内置合约设计与实现简介》提到的对账机制，我们也可以或许从别的一个角度验证代码执行的正确性，同时担保用户资产的安详。
3.撤单为什么有两个进口
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
