來點有趣的嘗試:設計比特幣期貨交易系統
今天來點有趣的嘗試:設計比特幣期貨交易系統。🤫
合約交易,一般來說指的是期貨合約,是期貨交易所統一製定的、規定在未來某一特定時間和地點交割一定數量標的物的標準化合約。
筆者在學習過程中,常常會思考期貨合約存在的意義,目前我比較接受的說法是「無論是何種期貨,其產生的根源都是市場對風險管理工具的需求」,直白說就是可以轉嫁風險,同時承擔風險的一方可以獲得高額回報或者大額虧損。
這裏我們以數字貨幣的期貨合約為例,來實現一個基於 BTC/USDT 價格指數的期貨合約。
期貨合約需要交易雙方以約定的「份數」進行買賣,例如黃金期貨,外盤通常以「盎司」為單位進行買賣,只能買賣整數倍的合約。
在期貨交易中,通常不需要支付全額費用,而只需要支付一定比例的保證金。根據保證金比例不同,期貨交易的杠桿也不同。例如,10% 的保證金率就是 10 倍杠桿,5% 的保證金率就是 20 倍杠桿。杠桿可以放大收益,也能擴大虧損。
很重要的一點,如果不計算交易所提取的手續費,期貨合約的買賣雙方就是一個零和博弈,即所有交易方的盈利和虧損相加為 0 。
先來看期貨合約系統的組成模塊:
![](https://assets.matters.news/embed/4032b317-6d0e-46f0-9df0-c807a03f1720.webp)
和任何其他系統一樣,當用戶的訂單請求到來時,首先需要對【用戶系統】進行身份認證,驗證完成後,確認用戶所選擇的期貨合約是否在有效期限內,接下來就需要【賬戶系統】驗證用戶用戶是否有足夠的余額來作為保證金進行交易。
如果以上驗證均通過,該訂單請求就由【訂單系統】創建成功,並進入定序系統排隊等待撮合,到達【撮合引擎】後,如果完成成交,訂單由【清算系統】進行清算。
和我們一般見過的現貨交易不同的是,用戶訂單成交後,同時創建一個【倉位】(你可以理解為雙方簽訂了合約),所以期貨合約系統需要一個【倉位管理模塊】來管理平臺上所有的用戶的倉位。
市場價格在實時變動,傳統的期貨交易所實行「當日無負債結算」的製度,用以防範風險和保障期貨市場正常流轉,收盤後要求虧損的用戶補足保證金。數字貨幣交易所一般都是 24 小時交易,無法每日結算,因此需要一個動態的【爆倉引擎】。
爆倉引擎一般也是交易所的核心所在。爆倉引擎會根據當前市場價格實時計算所有用戶的倉位權益是否降至 0 ,如果用戶的倉位保證金不足,爆倉引擎就會啟動爆倉流程:
- 監測用戶是否設置了「自動轉入保證金」,並且賬戶是否有足夠余額;
- 如果能自動轉入保證金,則自動轉入,權益提高,不需要爆倉;
- 如果不能自動轉入,則爆倉引擎首先接管倉位,用戶對此倉位的權益歸零;
- 爆倉引擎計算用戶權益為 0 的價格,並按照該價格平倉。平倉是否成功取決於市場波動性和流動性。
如果市場缺乏足夠的流動性,導致爆倉引擎所持有的倉位無法及時平倉,交易所本身就會承受損失。在某個期貨合約周期內,交易所可以選擇所有盈利用戶共同分擔損失,也可以優先選擇高風險盈利用戶強製減倉來提高流動性。
如果選擇強製減倉,系統還需要一個【 ADL 自動減倉系統 】,自動減倉系統根據用戶風險和盈利高低對盈利倉位排序,排在靠前的倉位更有可能被強製減倉。
合約到期後,由【清算系統】對所有倉位進行交割,按照盈虧更新賬戶,然後平掉所有倉位,合約交割完成。
到這裏,合約交易的業務邏輯就說完了,看起來並不復雜,但是講深入了我也不知道了 😭。
到了代碼實現階段,需要考慮的東西就多了:高並發、賬戶安全、風控、性能等。這些都是挑戰開發人員的地方。
說點其他的,實際上在互聯網產品中,業務系統也是有高下之分的,一般的 CMS 系統 或者 信息流系統 往往並不難實現,但是一旦涉及到資金安全、高頻交易的場景就會使系統變得極其復雜。阿裏巴巴可以孵化出阿裏雲,亞馬遜孵化出 AWS ,這都是有原因的。
喜欢我的作品吗?别忘了给予支持与赞赏,让我知道在创作的路上有你陪伴,一起延续这份热忱!