比較ERC與TRC的創建交易流程是如何做到防止重複交易
最近參與了有關區塊鏈相關的專案,系統內部的服務會去調 web3 的 API 做 ERC 或 TRC 的鏈路的 USDT 轉帳。實際下去開發後才發現在這兩個鏈路上創建交易的流程雖然有一些不一樣,但是卻都又能解決了重複交易的問題。因此趁著記憶猶新時寫了這篇:比較 ERC 與 TRC 的創建交易流程以及它們是怎麼防止同一筆交易被上鏈多次導致重複交易的。
最近參與了有關區塊鏈相關的專案,系統內部的服務會去調 web3 的 API 做 ERC 或 TRC 的鏈路的 USDT 轉帳。實際下去開發後才發現在這兩個鏈路上創建交易的流程雖然有一些不一樣,但是卻都又能解決了重複交易的問題。因此趁著記憶猶新時寫了這篇:比較 ERC 與 TRC 的創建交易流程以及它們是怎麼防止同一筆交易被上鏈多次導致重複交易的。
在當前採用微服務的架構下想要對特定服務 debug 除了在本機將服務啟起來然後仿照其他服務打 API 請求過來外,也可以採用將本機的 debugger 連接至遠端服務進行遠端 debug 下斷點。
在 dev 環境與其他人串接流程找問題時我自己滿常用這招的,畢竟如果要在本地 debug 不太可能將整套微服務都啟一遍。
首先要允許 dev 遠端環境的服務被 debugger 連接的話,我們需要調整一下服務的啟動指令加入以下參數。
公司的Node.js專案在經過好幾年的需求迭代後多少會出現些bad smells,為了解決這些bad smells於是又誕生了一些偏門的寫法,但卻也換來目前開發上很難確認眾多變數中哪些變數會是undefined
(對,我們的專案已經寫到連eslint的一些rule都認不得了)。因此最近在研究如何為專案的eslint增加客製化的rule,補上讓eslint去抓出偏門寫法中的undefined
變數。
在做了些研究後,發現eslint在為某個檔案做靜態檢查時,會先將整份檔案的程式碼讀一遍,並且建立抽象語法樹(Abstract Syntax Tree),然後透過遍歷這棵樹的操作去抓出沒有符合rule的地方。
其實不只是eslint,所有編譯器、直譯器在拿到一份程式碼時第一步也是先建立抽象語法樹,所以今天這篇要來簡單介紹什麼是抽象語法樹(Abstract Syntax Tree),或簡稱AST。
公司目前的服務有幾隻API會提供用戶上傳檔案(KYC及回傳明細)用。而現有檔案上傳機制是將檔案以BLOB的形式存在資料庫的ATTACHMENT
資料表內。
這種做法的好處是上傳檔案並且更改記錄狀態可以包成一包transaction,實現業務邏輯上資料的一致性(要嘛用戶的狀態為等待上傳並且屬於此用戶上傳的檔案還不存在、要嘛用戶的狀態為已上傳並且屬於此用戶上傳的檔案已歸檔)。
但是這樣做的壞處是DB那台機器對於操作下載檔案時會消耗一部分CPU與network io bandwidth,也就等於會拖慢DB處理關聯式資料CRUD的主業。隨著使用量的增加,團隊中最近開始考慮要將檔案上傳的功能拆出至DB以外的solution。
最近在工作上需要寫一隻圖片上傳的API,好讓使用者上傳證明用的圖片供後續人工審核用。身為一隻稱職的圖片上傳API,當收到使用者發過來的請求後第一步肯定要做參數檢查,驗證使用者上傳的檔案是不是真的是圖片檔,並將亂上傳的請求拒於門外。
但是今天使用者傳來的是檔案其實對API來說都是binary的形式,要怎麼檢驗它真的是圖片檔呢?如果用最直覺判斷副檔名的方式的話有可能會遇到使用者故意改副檔名,然後惡意上傳其它非影像的檔案,所以用副檔名擋肯定是不夠的。在survey了一下後,發現其實還有一招是可以從檔案內容中的magic number下手來判斷。
近期迴響