ArcBlock 区块基石用户及开发者社区密切关注的 Token Swap（通证互换）服务研发遭遇困难、发布一再延期，ArcBlock 创始人兼 CEO 冒志鸿特撰本文致歉并对具体情况予以说明。

ArcBlock Token Swap 服务发布一再延期，这是我们在开发过程中首次遭遇这样长时间的延期并且影响发布的事件。在此，我们决定把整个事情的发展情况、原因和解决方案和大家公开透明地分享并讨论。

事件发展时间表：

• 2019 年 5 月：双向 Token Swap 计划开始概念设计和高层需求分析；
• 2019 年 7 月：正式开始 Token Swap 项目，考虑此项目关键性，由 ArcBlock 研发副总裁陈天亲自进行系统设计和主要项目开发实现，计划将在 8 周左右完成，预计 8 月底代码完成，在 9 月中旬“上海之巅 创见未来”活动上发布 Beta 版本；
• 2019 年 9 月：评估认为 Token Swap 落后于进度，无法在 9 月 16 日活动中发布，计划延期到 10 月初在以太坊 Devcon 5 期间发布测试版本；
• 2019 年 10 月：在以太坊开发者大会 Devcon 5 期间就测试版本征求专家意见和讨论，获得了很多反馈，尤其指出设计中存在理论上的安全性问题。这些问题引起我们的高度重视，决定延期整改后再发布，初步计划推迟到 10 月底或 11 月初；
• 2019 年 11 月：初步确定 12 月 8 日发布（后推迟到圣诞前发布）改进版本的 Token Swap，在此之前发布 1.0 版 Forge SDK 和 2.0 版钱包产品；
• 2019 年 12 月初：经评估发现原先的 Token Swap 在设计上安全性仍然达不到理论需求的安全水平，如果继续按原计划实施将存有严重的安全隐患并且需要相当大的人工运营负荷（ArcBlock 团队也不可能实现），因此无法发布。除非重新设计整改，原有设计的 Token Swap 不能达到 ArcBlock 所要求的产品质量标准；
• 2019 年 12 月 11 日：ArcBlock 决定重新设计 Token Swap，充分利用原有项目中积累的代码和经验教训，快速迭代采用一个更新的设计方案，预期争取在 12 月底代码完成，2020 年 1 月上线运行。

经过认真细致的复盘分析，我们检讨在以下地方出了问题：

1. 低估了项目的工程实现的复杂程度，以及双向 Swap 设计带来安全性方面新的要求；
2. 设计过于复杂，其复杂性导致产生了大量的工作量，以及在发现问题之后修改调整存在不小困难；
3. 没能从设计和实现一开始就充分考虑自动化和高级别的安全设计，而是期待通过人工运维和传统的网络安全手段来处理安全问题，进而导致为解决这些安全问题需要花费相当大的工程和运维代价，并且难以有充分的信心来发布足够安全的产品；
4. 我自己没有在项目几度延期的时候及时介入分析问题本质，只是简单地认为只需要增加更多工时就能完成任务。

为了能更好地解决问题，我们决定：

1. 开诚布公地报告我们这一项目的进度和存在的问题，诚恳致歉，并让我们的用户、开发者社区了解到底发生了什么、为什么会一再延期发布。也许，外界会发现一贯以技术工程见长的 ArcBlock 团队也同样遭遇这么多挑战和问题。在创新的道路上，我们难免会走一些曲折的道路。
2. 与此同时，全力以赴地投入工作： 1）全公司已进入全天候工作方式（过去我们一直实行弹性的工作时间制度），但在解决本次问题前，我们也只好向大家“痛恨”的 996 致敬 :( ——毕竟解决问题要花很多时间；原本西雅图团队按惯例在圣诞节至元旦新年休假，但这次假期因此取消（除了法定节假日外全员继续工作）；我自己也临时取消了半年前就计划安排好的全家圣诞休假，和团队一起全身心投入工作； 2）修改项目设计，从一个新的角度重新设计，把安全性和自动化运营作为最重要的基础需求，但也尽可能重用之前的相关代码，避免彻底重头开始； 3）把这次项目延期的深层次原因作为一个重要的教训来总结出相应原则，用于指导未来的项目管理。

为此，直接负责此项目的陈天在回顾反省项目教训和失误时，诚恳地表示：

“在 Token Swap 项目中，我们高估了团队的能力和可用的人力资源，大大低估了项目实施的难度，导致项目一再延期。从开发的角度来看，Token Swap 的复杂度和一个删减掉 order book 和 match maker 的交易所的复杂度不相上下，其涉及到非常细致的内部安全性和外部安全性以及繁杂的风控流程。

“从一开始，我们朝着一个可以互换任意 Token 的非常灵活的架构出发，构建了三层结构的子网来一层层保护储存私钥的 Vault，用户可以像使用交易所 App 一样，把 Token 打入我们为其分配的受控账户，然后我们的 Sweeper 服务监听以太坊网络上的转账，当发现收款方是受控账户的转账时由 Token Swap 服务进行后续的处理。这个方案耗费了我们很长时间开发，一直到内部做集成测试，结果还是不尽如人意：整个流程可能出现问题的环节太多，涉及到不少人工的干预；人工干预过程中不可避免需要访问不同级别的私钥，最终系统的内部风险敞口太大使得我们无法自信地将其发布出去。

“在这个过程中，我负主要责任 —— 没有安排好 Token Swap 和其他项目的优先级，没有找到更容易实施、风险更小的技术方案。目前，我们找到了更好地处理内部安全性的方案，项目重新回归最高优先级，我们有信心通过一段时间的努力，将 Token Swap 最终上线。”

利用这次机会，我们也对 Token Swap 做一个技术性讲解，详细探讨究竟 ArcBlock Token Swap 是什么？为什么需要？我们的设计和过去的实现有什么不同？为什么我们的初版设计会导致项目的一再拖延？以及，为什么我们的新设计会有信心解决之前的问题？

不日发布，敬请期待。