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.我自己沒有在專案幾度延期的時候及時介入分析問題本質，只是簡單地認為只需要增加更多工時就能完成任務。
為了能更好地解決問題，我們決定：
一、開誠佈公地報告我們這一專案的進度和存在的問題，誠懇致歉，並讓我們的使用者、開發者社羣瞭解到底發生了什麼、為什麼會一再延期釋出。也許，外界會發現一貫以技術工程見長的 ArcBlock 團隊也同樣遭遇這麼多挑戰和問題。在創新的道路上，我們難免會走一些曲折的道路。
二、與此同時，全力以赴地投入工作：
•全公司已進入全天候工作狀態（過去我們一直實行彈性工作時間制度），但在解決本次問題前，我們也只好向大家“痛恨”的 996 致敬 :( ——畢竟解決問題要花很多時間；原本西雅圖團隊按慣例在聖誕節至元旦新年休假，但這次假期因此取消（除了法定節假日外全員繼續工作）；我自己也臨時取消了半年前就計劃安排好的全家聖誕休假，和團隊一起全身心投入工作；
•修改專案設計，從一個新的角度重新設計，把安全性和自動化運營作為最重要的基礎需求，但也儘可能重用之前的相關程式碼，避免徹底重頭開始；
•把這次專案延期的深層次原因作為一個重要的教訓來總結出相應原則，用於指導未來的專案管理。
為此，直接負責此專案的陳天在回顧反省專案教訓和失誤時，誠懇地表示：
“在 Token Swap 專案中，我們高估了團隊的能力和可用的人力資源，大大低估了專案實施的難度，導致專案一再延期。從開發的角度來看，Token Swap 的複雜度和一個刪減掉 order book 和 match maker 的交易所的複雜度不相上下，其涉及到非常細緻的內部安全性和外部安全性以及繁雜的風控流程。
“從一開始，我們朝著一個可以互換任意 Token 的非常靈活的架構出發，構建了三層結構的子網來一層層保護儲存私鑰的 Vault，使用者可以像使用交易所 App 一樣，把 Token 打入我們為其分配的受控賬戶，然後我們的 Sweeper 服務監聽以太坊網路上的轉賬，當發現收款方是受控賬戶的轉賬時由 Token Swap 服務進行後續的處理。這個方案耗費了我們很長時間開發，一直到內部做整合測試，結果還是不盡如人意：整個流程可能出現問題的環節太多，涉及到不少人工的干預；人工干預過程中不可避免需要訪問不同級別的私鑰，最終系統的內部風險敞口太大使得我們無法自信地將其釋出出去。
“在這個過程中，我負主要責任 —— 沒有安排好 Token Swap 和其他專案的優先順序，沒有找到更容易實施、風險更小的技術方案。目前，我們找到了更好地處理內部安全性的方案，專案重新迴歸最高優先順序，我們有信心透過一段時間的努力，將 Token Swap 最終上線。”
利用這次機會，我們也對 Token Swap 做一個技術性講解，詳細探討：
•究竟 ArcBlock Token Swap 是什麼？為什麼需要？
•我們的設計和過去的實現有什麼不同？
•為什麼我們的初版設計會導致專案的一再拖延？
•以及，為什麼我們的新設計會有信心解決之前的問題？
不日釋出，敬請期待。
