chatGPT智慧聊天機器人系統開發介面對接模式專案方案（成熟技術）

　　MySQL，關係型資料庫，支援schema和富查詢，效能較KV資料庫低，目前關係型資料庫與區塊鏈的狀態資料並不能很好的結合，導致很少有區塊鏈採用關係型資料庫作為狀態資料庫。原因主要有兩點：1.區塊鏈需要對智慧合約所讀寫的狀態資料做嚴格的控制和校驗，而SQL語句相對區塊鏈來說過於靈活，難以控制；2.需要提前建立庫表和索引，需要針對不同的智慧合約建立不同的資料庫表結構，不夠靈活。目前長安鏈支援MySQL儲存引擎，在系統資料如Block DB上支援區塊元資訊、交易資訊的關係型語義，狀態資料庫支援kv的方式和智慧合約編寫SQL語句方式讀寫狀態資料(world state)。

　　根據對同一批交易排程產生的執行順序是否隨機，並行排程演算法可分為：I8O系統2857開發8624遊戲

　　隨機性排程演算法：即針對同一批交易排程產生的交易執行順序是隨機的，即使同一節點針對同一批交易連續執行兩次排程演算法產生的結果也可能不同。此類演算法往往排程速度較快，其難點在於驗證節點如何保證執行順序與提案節點一致並得到相同的執行結果。因此，交易的執行順序必須打包至區塊中並由其他節點據此驗證。

　　確定性排程演算法：即針對同一批交易排程產生的交易執行順序是確定的。此類演算法的優點是交易執行順序產生穩定且可復現，因此理論上講交易執行順序的資訊可不包含在區塊內，各驗證節點執行並行排程演算法即可進行校驗。

　　同步服務模組handler

　　同步模組的訊息handler負責處理從net模組監聽到的NetMsg_SYNC_BLOCK_MSG型別的訊息

　　func(sync*BlockChainSyncServer)blockSyncMsgHandler(from string,msg[]byte,msgType netPb.NetMsg_MsgType)error{

　　//檢查服務是否啟動

　　check sync.start

　　//檢查訊息型別

　　check msgType!=netPb.NetMsg_SYNC_BLOCK_MSG

　　//解析msg

　　unmarshal msg->syncMsg

　　switch syncMsg.Type{

　　case syncPb.SyncMsg_NODE_STATUS_REQ:

　　//返回本地高度

　　return sync.handleNodeStatusReq(from)

　　case syncPb.SyncMsg_NODE_STATUS_RESP:

　　//在定時器任務佇列中新增NodeStatusMsg任務，啟動處理流程

　　return sync.handleNodeStatusResp(&syncMsg,from)

　　case syncPb.SyncMsg_BLOCK_SYNC_REQ:

　　//返回區塊資料（封裝在SyncMsg中，包含相應的業務資料）

　　return sync.handleBlockReq(&syncMsg,from)

　　case syncPb.SyncMsg_BLOCK_SYNC_RESP:

　　//在定時器任務佇列中新增SyncedBlockMsg任務，啟動處理流程

　　return sync.scheduler.addTask(&SyncedBlockMsg{msg:syncMsg.Payload,from:from})

　　}