如圖1所示，本說明書提供的實施例示意了一種基於區塊鏈的資訊監管方法，所述區塊鏈包括至少一個資訊監管方節點以及若干資訊提供方節點，該監管方法包括：
步驟102，所述資訊監管方獲取所述資訊提供方發佈的加密資訊記錄；其中，所述加密資訊記錄基於與所述資訊監管方的公鑰相關的密鑰進行加密；
步驟104，使用與所述資訊監管方的私鑰相關的密鑰，對所述加密資訊記錄進行解密獲取原始資訊記錄；
步驟106，基於預配置的監管規則對所述原始資訊記錄執行風險監管處理。
本說明書提供的實施例所述的“資訊監管方”為資訊監管中履行監管職責的機構所在的伺服器或終端，本說明書提供的實施例所述的“資訊提供方”具體可以為資訊監管中的被監管方終端，也可為與被監管方發生資料連接的其他伺服器或終端，其提供的“資訊”即為被監管的對象資訊資料，如貸款資料、交易資料等。在本說明書所述的實施例中，任意的資訊監管方與資訊提供方可透過遵循相應節點協議、運行節點協議程式的安裝來加入該區塊鏈，作為該區塊鏈的節點。因此相比於監管機構線下一一查看被監管機構的業務現狀，本說明書的實施例提供的線上加入該區塊鏈成為其節點以參與監管或被監管的方法有著更加優越的便捷性和經濟性，可隨時加入或撤出。
本說明書提供的實施例可以運行在任何具有計算和儲存能力的設備上，如手機、平板電腦、PC(Personal Computer，個人電腦)、筆記型電腦、伺服器等設備；還可以由運行在兩個或兩個以上設備的邏輯節點來實現本說明書實施例中的各項功能。
本說明書提供的實施例所述的“區塊鏈”，具體可指一個各節點透過共識機制達成的、具有分散式資料儲存結構的P2P網路系統，該區塊鏈內的資料分佈在時間上相連的一個個“區塊(block)”之內，後一區塊包含前一區塊的資料摘要，且根據具體的共識機制(如POW、POS、DPOS或PBFT等)的不同，達成全部或部分節點的資料全備份。本領域的技術人員熟知，由於區塊鏈系統在相應共識機制下運行，已收錄至區塊鏈資料庫內的資料很難被任意的節點篡改，例如採用Pow共識的區塊鏈，至少需要全網51%算力的攻擊才有可能篡改已有資料，因此區塊鏈系統有著其他中心化資料庫系統所無法比擬的保證資料安全、防攻擊篡改的特性。由此可知，在本說明書所提供的實施例中，由資訊提供方提供的、被該區塊鏈收錄的“資訊”不會被攻擊或篡改，從而保證了監管的真實與公正性。
為了進一步保證監管的隱私性，本說明書提供的實施例中，資訊提供方提供的資訊以與所述資訊監管方的公鑰相關的密鑰進行加密；該加密資訊僅能被所述資訊監管方的私鑰相關的密鑰進行解密以獲取原始資訊記錄，防止共處於同一區塊鏈的其他節點獲知該資訊的明文(即原始資訊記錄)。相應的資訊監管方可解密的加密方式有很多，如ECDSA、RSA，在本說明書提供的實施例中可根據需求而具體設定加密方式。
本說明書實施例所提供的基於區塊鏈的資訊監管方法，資訊監管方基於預配置的監管規則對所述原始資訊記錄執行風險監管處理，具體的風險監管處理方案有很多，例如將監管規則數位化為相應的監管指標，將監管指標的閾值與從區塊鏈網路上獲取的原始資訊記錄中監管因數的取值做比對，進而根據是否違規、違規程度直接有效輸出監管結果；或者是從區塊鏈網路上獲取的原始資訊記錄中識別違規因數，一旦識別出違規因數，即執行預設的風險監管處理，如預警、報警、執行封鎖等。所述基於預配置的監管規則對所述原始資訊記錄執行風險監管處理的方案，根據具體的監管要求具體設定，在本說明書中不作限定，從而最終完成了從監管資訊的收集到對被監管行為的處理的一體化的數位監管方法，提高了監管行為的便捷性、經濟性、真實性與高效性。
下面以金融監管機構監管同一借款人在同一網貸機構及不同網貸機構的借款情況為例，闡述本說明書所提供的具體實施方式。
在本實施例中，金融監管機構為資訊監管方，各個網貸機構為不同的資訊提供方，自然借款人用戶為被監管的對象。為降低交易或資料的確認時間、提高交易傳輸量、滿足對安全和性能的需求，金融機構通常選用聯盟鏈架構來建構該區塊鏈。信用較高的機構，如大型銀行、巨頭企業、一些監管機構可作為該聯盟鏈的預選的節點，參與區塊的記帳。聯盟鏈的共識過程也由該預選的節點控制，當網路上有超過設定比例(如2/3)的節點確認一個區塊，該區塊記錄的交易或資料將得到全網確認。聯盟鏈可以根據應用場景來決定對公眾的開放程度，對可開放的機構給予接入該聯盟鏈的權限，例如在本實施例中，作為資訊監管方的金融監管機構可為預選的節點參與記帳，各個資訊提供方如網貸機構可為具有接入聯盟鏈權限的一般節點；當然，金融監管機構也可為具有接入聯盟鏈權限的一般節點，在本說明書中不作限定。
聯盟鏈通常多採用權益證明或PBFT、RAFT等共識演算法。圖2示意了簡化的PBFT演算法的達到共識的一致性過程，其中C為客戶端，N0
~N3
表示服務節點，特別的，N0
為主節點，N3
為故障節點。PBFT系統通常假設故障節點數為m個，而整個服務節點數為3m+1個。簡單而言，整個通信過程如下：
1)客戶端向主節點發送請求調用服務操作；
2)當主節點接收請求後，啟動三階段的協議以向各從節點廣播請求；
[2.1]序號分配階段(又稱pre-prepare階段)，主節點給請求賦值一個序列號n，廣播序號分配訊息和客戶端的請求訊息m，並將構造PRE-PREPARE訊息給各從節點；
[2.2]交互階段(又稱prepare階段)，從節點接收PRE-PREPARE訊息，向其他伺服器節點廣播PRE-PREPARE訊息；
[2.3]序號確認階段(又稱commit階段)，各節點對視圖內的請求和次序進行驗證後，廣播COMMIT訊息，執行收到的客戶端的請求並給客戶端以相應。
3)客戶端等待來自不同節點的回應，若有m+1個回應相同，則該回應即為共識的結果。
同所有的狀態機副本複製技術一樣，PBFT對每個副本節點提出了兩個限定條件：
1)所有節點必須是確定性的。也就是說，在給定狀態和參數相同的情況下，操作執行的結果必須相同；
2)所有節點必須從相同的狀態開始執行。
在這兩個限定條件下，即使失效的副本節點存在，PBFT演算法對所有非失效副本節點的請求執行總順序達成一致，從而保證安全性。
根據圖2所示的共識通信過程一批記錄產生一個區塊，最終形成鏈。PBFT演算法作為本說明書所提供的一種較佳的實施方式，是由於採用該種演算法共識的效率高，可滿足高頻交易量的需求，例如在本實施例中頻繁的借貸交易；且共識的時延很低，基本達到即時處理的要求，能快速即時地對監管資訊輸出監管結果；可信節點作為預選的記帳節點，兼顧了安全性與穩定性；另外，採用PBFT演算法不會消耗過多的電腦算力資源，也不一定需要代幣流通，因此具有良好的可使用性。
更佳地，在本說明書所提供的實施例中，各個網貸機構作為資訊提供方，其提供的與個人借貸相關的資訊通常涉及身份等隱私資訊，如表1所示，為保證涉及自身機構或借貸人隱私的資訊明文只被相應的具有監管權限的金融監管機構獲知，而不被處在同一區塊鏈的其他節點獲知或非法使用，各個網貸機構應加密處理其提供的監管資訊。具體的加密方式有很多種，例如網貸機構可提前與金融監管機構約定對稱密鑰來進行加密和解密；網貸機構也可使用與金融監管機構的公鑰相關的密鑰來進行非對稱加密，則金融監管機構可使用與其私鑰相關的密鑰來進行解密得到網貸機構所提供的借貸資訊的明文(如表1所示)，從而防止其他節點獲悉該監管資訊。
表1 網貸機構A平台上發生的個人C向個人B借貸的資訊表
例如，如圖3所示，作為資訊提供方的網貸機構首先使用對應的金融監管機構的公鑰對其提供的借貸資訊的明文(如表1所示)進行加密得到借貸資訊的密文，接著為保證所述密文不被篡改和偽造，網貸機構對該密文進行數位簽章，並將該對密文的數位簽章和密文一起上傳至網貸機構節點所在的區塊鏈資料庫快取中；該區塊鏈的記帳工，如聯盟鏈中的預選的具有記帳權限的節點，需對可收錄至區塊鏈的資料記錄進行驗證，該驗證過程必然包含對上述數位簽章的驗簽，驗簽過程是為了防止資料被篡改或者該資訊是其他參與者偽造，驗簽通過後記帳工將該對密文的數位簽章和密文收錄至上述區塊鏈的區塊中。
在該對密文的數位簽章和密文被如聯盟鏈中的預選節點收錄至所述區塊鏈中後，作為該區塊鏈的節點，該金融監管機構可從區塊鏈中獲取上述對密文的數位簽章和密文，相應地，該金融監管機構可透過使用與上述公鑰對應的私鑰對密文進行解密，從而得到具體的借貸資訊的明文。在本實施例中，作為資訊監管方的金融監管機構可以是具有記帳權限的預選節點，也可為普通的節點，在本說明書中不作具體限定，只要其對上述對密文的數位簽章和密文具有訪問查看權限。
本說明書實施例對關於數位簽章及驗簽演算法、金融監管機構自身的公鑰-私鑰對的演算法不作具體限定，可選用橢圓曲線演算法、RSA演算法等完成，相關的hash演算法可選用MD5、SHA256等完成。
關於上述對借貸資訊進行加密以得到密文的過程，可以採用雙方約定對稱密鑰的方式實現。例如，如圖4所示，作為資訊提供方的網貸機構對借貸資訊的明文進行加密可採用ECDH交換密鑰的方式。本領域的技術人員應知，在使用同一橢圓曲線演算法(即選用同一直線或基點)獲取機構的身份相關的公鑰-私鑰對的區塊鏈系統中，機構A的私鑰AS與機構B的公鑰BP的乘積等於機構A的公鑰AP與機構B的私鑰BS的乘積。
即：AS，
在本說明書所述的實施例中：金融監管機構的公鑰JP。
因此，網貸機構可使用對應的金融監管機構的公鑰JP與自身的私鑰DS乘積所得的密鑰對借貸資訊的明文進行加密得到借貸資訊的密文，類似的，接著為保證所述密文不被篡改和偽造，網貸機構對該密文進行數位簽章，並將該對密文的數位簽章、密文和與上述對借貸資訊加密所使用的自身的私鑰DS相對應的公鑰DP、金融監管機構的公鑰JP一起上傳至網貸機構節點所在的區塊鏈資料庫快取中；該區塊鏈的記帳工，如聯盟鏈中的預選的具有記帳權限的節點，首先對該數位簽章進行驗簽，驗簽過程是為了防止資料被篡改或者該資訊是其他參與者偽造，驗簽通過後記帳工將該對密文的數位簽章、密文、和上述對借貸資訊加密所使用的自身的私鑰DS相對應的公鑰DP、金融監管機構的公鑰JP一起收錄至上述區塊鏈的區塊中。
在該對密文的數位簽章、密文和上述對借貸資訊加密所使用的自身的私鑰相對應的公鑰被如聯盟鏈中的預選節點收錄至所述區塊鏈中後，該金融監管機構可從區塊鏈中獲取上述對密文的數位簽章和密文，相應地，該金融監管機構可透過使用與上述從網路上獲取的公鑰JP對應的私鑰JS與從網路上獲取的DP相乘而得的密鑰對密文進行解密，從而得到具體的借貸資訊的明文。其他任意節點，由於不能獲知該金融監管機構的私鑰JS而無法將上述密文解密。
值得注意的是，由於同一機構在一個區塊鏈中可具有多組公鑰-私鑰對，上述對信貸資訊加密所用的網貸機構的公鑰DP、私鑰DS不一定與上述數位簽章過程及驗簽所使用的私鑰、公鑰相同，但這並不影響本技術方案的實施，反而由於增加了系統的複雜性而降低了被攻擊的可能性。
雖然該區塊鏈的記帳節點在收錄資料時已經驗證過密文的數位簽章，為了進一步地保證監管資訊來源的正確性，防止資料被篡改或者惡意節點偽造資料，上述對本說明書所提供的實施例的描述中，金融監管機構在從上述區塊鏈中獲取到借貸資訊的密文、網貸機構對該借貸資訊的數位簽章等資料後，首先可再次對獲取到的數位簽章進行驗證，驗證通過後再解密上述密文，從而進一步防止其他機構或個人偽造借貸資訊，加強該金融監管行為的真實可靠權威性。
在本說明書所提供的實施例中，作為資訊監管方的金融監管機構可建立監管風險引擎來模組化處理各個網貸機構提供的借貸資訊。如圖5所示，該監管風險引擎具體可包括：資料輸入模組M1、監管指標產生模組M2、風險決策模組M3、風險處置模組M4等。值得注意的是，上述風險監管引擎僅僅是風險監管處理的程式的具象化名稱，且該風險監管引擎的各個模組之間並無特定的分界，僅僅為了闡釋上述風險引擎的功能的方便，人為將其劃分為多個模組。
資料輸入模組M1用以處理該金融監管機構從上述區塊鏈獲取到的資料，包括借貸資訊的密文、網貸機構對該借貸資訊的數位簽章等資料，根據相關的解密演算法將上述借貸資訊的密文解密、或對上述數位簽章驗簽通過後再將上述借貸資訊的密文解密，按風險決策模組M3所需的資料格式將該借貸資訊的明文所包含的資料資訊解析。由於現有的分散式共享網路系統或區塊鏈系統承載的資料結構通常為文本格式，不具有良好的可操作性，因此資料輸入模組M1可將上述解密的借貸資訊的明文進行資料表格化解析，將風險決策模組M3中需用到的重要資料資訊建立成表格形式，例如還原為上文表1所述的資料表格，輸入至風險決策模組M3。
監管指標產生模組M2用於根據監管法規或準則產生監管行為對應的監管指標。如本實施例中，為監管“同一借款人在同一網貸機構的借款餘額上限”行為，根據“單一的個體、單一的自然人在一個平台上的借款上限是20萬”這一金融法條，訓練建立對應的指標。該訓練過程如下，
1)如圖6所示，透過命名實體識別、語法分析、依存分析等自動分析技術，依存分析句子的主謂賓結構特徵，獲取到動作元組(單一、自然人or個體、借款、上線、20萬)，進一步透過預定義的映射結構關係將該監管法規遵循法條轉換為一段電腦程式可執行的SQL語句。
2)產生一個指標Z1′，並和第1步產生的SQL語句映射關聯，將其一起存入監管指標池候選；
3)人工審核上述SQL語句，在修訂並確認上述SQL語句的正確性後，將其正式存入監管指標池，命名為Z1指標；Z1指標包括上述可執行的SQL語句，及其閾值——20W。
類似地，根據“單一的個體、單一的自然人在多個平台上的借款上限是100萬”這一金融法條，可訓練出Z2指標；Z2指標包括一段可執行的SQL語句，及其閾值——100W。
在本說明書所述的實施例中，為便於管理多個監管指標，可在監管指標池內設立的監管指標多叉樹儲存結構，將多個監管指標，如Z1、Z2，分別儲存在該多叉樹的節點上。進一步地，為便於對相似種類的行為進行統一監管，可以在監管指標池內設立多個不同種類的多叉樹，對應儲存相應類別的監管指標，例如監管指標池中設立有“自然人à借款報警”類指標的儲存多叉樹，其上可儲存如上述Z1、Z2及其他與自然人用戶在網貸平台上借款行為相關的指標；應“同一法人或其他組織在同一網路借貸資訊中介機構平台的借款餘額上限不超過人民幣100萬元”等其他相關監管辦法條款，監管指標池中還可設立有“企業à借款報警”類監管指標多叉樹，其上儲存有與企業用戶在網貸平台上借款的法定限額相關的監管指標。
而且，為了便於多層次監管，更好地達到提前警示預防違法的監管效果，可對一些指標設置相應的預警指標(預警指標對應的閾值可設定為全指標閾值的95%或其他值)，例如為“單一的個體、單一的自然人在一個平台上的借款不超過19w”預警監管語句，按照上述1)--3)的過程產生預警指標Z1Y，Z1Y包括由上述預警監管語句訓練出的可執行的SQL語句及其對應的閾值19W，將其存入上述監管指標池。類似地，可以在監管指標池內建立一個“自然人à借款預警”類指標的儲存多叉樹，並將Z1Y儲存在該多叉樹的節點上。該“自然人à借款預警”類指標多叉樹上還可儲存與同一自然人在多個網貸平台上借款行為的預警監管相關的Z2Y指標，在此不再贅述。
至此，監管指標產生模組M2透過以上資料訓練、審核、指標建立或指標多叉樹建立過程，將監管指標與可執行的SQL語句映射關聯，為監管自然人用戶在網貸機構上借款情況建立了可執行的監管範本，具體的風險監管及處置過程在風險決策模組M3中進行。值得注意的是，在本說明書中僅僅為了闡釋上述風險引擎的各個功能的方便，將其劃分為多個模組，各模組之間並無特定的界限，例如上述監管指標池可以歸屬於監管產生模組M2，也可歸屬於風險決策模組M3。
如圖7所示，上述的監管指標池(圖中所示的監管指標資料集市)被儲存於風險決策模組M3內，該監管指標池內可包含若干個監管指標。在風險決策模組M3接收到對“單一的個體、單一的自然人在一個平台上的借款是否需預警”的監管指令後，首先在其監管指標池中搜索是否有對應的監管指標Z1Y存在，如存在，風險決策模組M3進入風險因素識別階段。該風險決策模組M3讀取從資料輸入模組M1輸入的資料資訊，針對該監管指令從上述資料資訊中識別監管因數，在本例中監管對象為單個借款自然人，由於可唯一性確定自然人是否為單個的因素為自然人的身份證號碼(或其他唯一性用戶ID)，因此本例中的監管因數為自然人的身份證號碼，接著風險決策模組M3在監管指標Z1Y對應的SQL語句輸入該用戶的身份證號碼，運行該SQL語句對該身份證號碼進行查詢，即可得到該單一自然人在該單平台的實際借款數(餘額)，對比該監管因數的取值--實際借款數與指標Z1Y的閾值19W，該風險引擎的風險處置模組M4輸出相應的監管處理方案：當單一自然人實際借款數低於19W時，風險處置模組M4可不將其視為風險事件，不作回應；當單一自然人實際借款數高於19W時，根據預設的風險監管處理邏輯，風險處置模組M4可向相應的網貸平台節點發出預警提示訊息，如“已大額借款，即將達到監管限制上限”，從而阻止該網貸機構單平台對該用戶超過可放款餘額的新放款，減少某業務可能發生的損失。上述具體的風險處置方案可與監管指標關聯，以方便風險處置模組M4的處置方案輸出。
如上述金融監管機構發現某自然人在單平台的借款已經超出預警的閾值，可預案關聯而進一步對其進行報警指標監管：首先在其監管指標池中搜索是否有對應的監管指標Z1存在，如存在，風險決策模組M3進入風險因素識別階段。類似地，該風險決策模組M3讀取從資料輸入模組M1輸入的資料資訊，針對該監管指令從上述資料資訊中識別監管因數——該自然人的身份證號碼，接著風險決策模組M3在指標Z1對應的SQL語句中輸入該身份證號碼，並運行查詢，即可得到該單一自然人在該單平台的實際借款數，對比該監管因數的取值--實際借款數與指標Z1的閾值20W，該風險引擎的風險處置模組M4輸出相應的監管處理方案：當單一自然人實際借款數低於20W時，風險處置模組M4可不作輸出；當單一自然人實際借款數高於20W時，風險處置模組M4可向相應的網貸平台節點發出強力報警訊息，或再向本監管機構或上級監管部門呈報。同樣，上述具體的風險處置方案可與具體的監管指標管理，以方便風險處置模組M4的處置方案輸出。
當然，根據監管的具體需求，可以省去對預警指標的監管而直接對報警指標進行監管，在本說明書中不作限定。
當監管指標池中的多個監管指標以多叉樹的形式被儲存時，由於多叉樹資料結構便於提高遍歷查找的效率，因此在面對“篩查所有的監管指標，監測是否有違規行為”或類似的普遍性監管指令時，更能提高監管的效率。在普遍性監察是否有預警或違規行為發生時，金融監管機構可遍歷其監管指標池中儲存的監管指標多叉樹，對每個已經設立好的監管指標進行對應的風險決策，該風險決策的具體過程與上述對監管指標Z1、或預警監管指標Z1Y的過程類似，在此不作贅述。
值得注意的是，上述的風險處置模組M4針對具體的監管指標(如Z1Y或Z1)輸出的監管處理方案，也可關聯在該監管指標所在的、監管指標多叉樹的節點上，例如在監管指標Z1Y的節點上關聯兩種處理方案：當監管因數的取值小於監管指標Z1Y的閾值時，不作出回應；當監管因數的取值大於或等於監管指標Z1Y的閾值時，向相應的網貸平台節點發出預警提示訊息。這樣在對“自然人à借款報警”類指標的儲存多叉樹的遍歷監管程式運行到所述監管指標Z1Y時，將具體自然人的身份證號碼輸入指標Z1Y的可執行SQL語句並在所監管的每個平台所提供的資料中查詢，得到該自然人在每個平台上的實際貸款取值，根據該取值於Z1Y閾值的對比關係，從Z1Y節點上輸出執行相應的處理方案。上述將監管處理方案關聯於監管多叉樹的相應節點上的技術方案，方便風險處理程式或風險處理引擎更快地作出風險處理，從而提升監管的效率。
金融監管機構透過建立上述風險引擎或執行上述風險監管處理程式，完成了從監管資訊中提取監管查詢因數，並將所述監管查詢因數的取值與所述監管指標的閾值作對比，且根據所述比較結果執行風險監管處理方案的過程，尤其是透過同時監管多平台上發生提供的監管資訊，不僅僅識別單個平台的風險，穿透式集中監管多個網貸平台，極大降低了對多平台線下監管的時間和經濟成本，可有效防止跨機構跨地區違規行為。
在本說明書所提供的實施例中，上述基於預配置的監管規則對所述原始資訊記錄執行風險監管處理的實施，既可以由資訊監管方如金融監管機構的中心化伺服器來程式化運行實現，也可調用發佈在該監管區塊鏈上的風險監管智能合約，執行該智能合約中聲明的與監管規則對應的執行程式，對所述原始資訊記錄執行風險監管處理。該智能合約的發佈方，既可以是該金融監管機構，又可以是該金融監管機構的上級監管機構——上級監管機構為了監管方便，可發佈多個下級監管機構通用的智能合約程式，供各個下級監管機構使用。本領域的技術人員應知，相比於中心化的伺服器運行方式，智能合約在任何時候應相應用戶的請求而調用，大大提升監管的效率；且智能合約執行有著較低的人為干預、去中心化權威的優勢，更加增加了監管行為的公平性。
與上述流程實現對應，本說明書的實施例還提供了一種分散式資訊監管裝置。該裝置可以透過軟體實現，也可以透過硬體或者軟硬體結合的方式實現。以軟體實現為例，作為邏輯意義上的裝置，是透過所在設備的CPU(Central Process Unit，中央處理器)將對應的電腦程式指令讀取到記憶體中運行形成的。從硬體層面而言，除了圖9所示的CPU、內部記憶體以及記憶體之外，網路風險業務的實現裝置所在的設備通常還包括用於進行無線信號收發的晶片等其他硬體，和/或用於實現網路通信功能的板卡等其他硬體。
圖8所示為本說明書所提供一種基於區塊鏈的資訊監管裝置，所述區塊鏈包括至少一個資訊監管方節點以及若干資訊提供方節點，所述資訊監管裝置包括
資訊獲取單元802，用於所述資訊監管方獲取所述資訊提供方發佈的加密資訊記錄；其中，所述加密資訊記錄基於與所述資訊監管方的公鑰相關的密鑰進行加密；
資訊解密單元804，用於使用與所述資訊監管方的私鑰相關的密鑰，對所述加密資訊記錄進行解密獲取原始資訊記錄；
風險監管處理單元806，用於基於預配置的監管規則對所述原始資訊記錄執行風險監管處理。
上述裝置中各個模組的功能和作用的實現過程具體詳見上述方法中對應步驟的實現過程，在此不再贅述。
對於裝置實施例而言，由於其基本對應於方法實施例，所以相關之處參見方法實施例的部分說明即可。以上所描述的裝置實施例僅僅是示意性的，其中所述作為分離部件說明的模組可以是或者也可以不是物理上分開的，作為模組顯示的部件可以是或者也可以不是物理模組，即可以位於一個地方，或者也可以分佈到多個網路模組上。可以根據實際的需要選擇其中的部分或者全部模組來實現本說明書方案的目的。本領域普通技術人員在不付出創造性勞動的情況下，即可以理解並實施。
上述實施例闡明的系統、裝置、模組或模組，具體可以由電腦晶片或實體實現，或者由具有某種功能的產品來實現。一種典型的實現設備為電腦，電腦的具體形式可以是個人電腦、膝上型電腦、行動電話、相機電話、智慧型電話、個人數位助理、媒體播放機、導航設備、電子郵件收發設備、遊戲控制台、平板電腦、可穿戴設備或者這些設備中的任意幾種設備的組合。
與上述方法實施例相對應，本說明書的實施例提供了一種電腦設備，該電腦設備包括記憶體和處理器。其中，記憶體上儲存有能夠由處理器運行的電腦程式；處理器在運行儲存的電腦程式時，執行本說明書實施例中基於區塊鏈的資訊監管的實現方法的各個步驟。對上述資訊監管的實現方法的各個步驟的詳細描述請參見之前的內容，不再重複。
與上述方法實施例相對應，本說明書的實施例提供了一種電腦可讀儲存媒體，該儲存媒體上儲存有電腦程式，這些電腦程式在被處理器運行時，執行本說明書實施例中基於區塊鏈的資訊監管的實現方法的各個步驟。對上述資訊監管的實現方法的各個步驟的詳細描述請參見之前的內容，不再重複。
以上所述僅為本說明書的較佳實施例而已，並不用以限制本說明書，凡在本說明書的精神和原則之內，所做的任何修改、等同替換、改進等，均應包含在本說明書保護的範圍之內。
在一個典型的配置中，計算設備包括一個或多個處理器(CPU)、輸入/輸出介面、網路介面和記憶體。
記憶體可能包括電腦可讀媒體中的非永久性記憶體，隨機存取記憶體(RAM)和/或非易失性記憶體等形式，如唯讀記憶體(ROM)或快閃記憶體(flash RAM)。記憶體是電腦可讀媒體的示例。
電腦可讀媒體包括永久性和非永久性、可移動和非可移動媒體可以由任何方法或技術來實現資訊儲存。資訊可以是電腦可讀指令、資料結構、程式的模組或其他資料。
電腦的儲存媒體的例子包括，但不限於相變記憶體(PRAM)、靜態隨機存取記憶體(SRAM)、動態隨機存取記憶體(DRAM)、其他類型的隨機存取記憶體(RAM)、唯讀記憶體(ROM)、電可擦除可編程唯讀記憶體(EEPROM)、快閃記憶體或其他記憶體技術、唯讀光碟唯讀記憶體(CD-ROM)、數位多功能光碟(DVD)或其他光學儲存、磁盒式磁帶，磁帶磁片儲存或其他磁性存放裝置或任何其他非傳輸媒體，可用於儲存可以被計算設備訪問的資訊。按照本文中的界定，電腦可讀媒體不包括暫存電腦可讀媒體(transitory media)，如調製的資料信號和載波。
還需要說明的是，術語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、商品或者設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、商品或者設備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，並不排除在包括所述要素的過程、方法、商品或者設備中還存在另外的相同要素。
本領域技術人員應明白，本說明書的實施例可提供為方法、系統或電腦程式產品。因此，本說明書的實施例可採用完全硬體實施例、完全軟體實施例或結合軟體和硬體方面的實施例的形式。而且，本說明書的實施例可採用在一個或多個其中包含有電腦可用程式碼的電腦可用儲存媒體(包括但不限於磁碟記憶體、CD-ROM、光學記憶體等)上實施的電腦程式產品的形式。As shown in FIG. 1, the embodiment provided in this specification illustrates a method for information supervision based on a blockchain. The blockchain includes at least one information supervisor node and several information provider nodes. The supervision method includes: Step 102 , The information supervisor obtains the encrypted information record issued by the information provider; wherein, the encrypted information record is encrypted based on a key related to the public key of the information supervisor; step 104, using the information The key related to the private key of the supervisory party decrypts the encrypted information record to obtain the original information record; Step 106, performs risk supervision processing on the original information record based on the pre-configured supervision rules. The "information supervisor" described in the embodiments provided in this specification is the server or terminal where the institution performing the supervisory duties in information supervision is located. The "information provider" described in the embodiments provided in this specification may specifically be the information supervision The terminal of the supervised party may also be another server or terminal that has data connection with the supervised party, and the "information" provided by it is the supervised object information data, such as loan data, transaction data, etc. In the embodiments described in this specification, any information regulator and information provider can join the blockchain as a node of the blockchain by following the installation of the corresponding node protocol and running the node protocol program. Therefore, compared with the current status of the regulatory agency's online review of the business status of the regulated agency, the method provided by the embodiment of this specification to join the blockchain online to become its node to participate in the supervision or supervision method has more superior convenience and economy Sex, you can join or withdraw at any time. The embodiments provided in this specification can run on any device with computing and storage capabilities, such as mobile phones, tablet computers, PCs (Personal Computers), notebook computers, servers, etc.; it can also be run on two Or logical nodes of more than two devices to implement various functions in the embodiments of this specification. The “blockchain” described in the embodiments provided in this specification can specifically refer to a P2P network system with distributed data storage structure achieved by each node through a consensus mechanism, and the data in the blockchain is distributed in time Within the connected "blocks", the latter block contains the data summary of the previous block, and according to the specific consensus mechanism (such as POW, POS, DPOS or PBFT, etc.), all or The data of some nodes are fully backed up. Those skilled in the art are familiar with the fact that since the blockchain system operates under the corresponding consensus mechanism, the data that has been included in the blockchain database is difficult to be tampered with by any node. For example, the blockchain using Pow consensus requires at least a full Only an attack of 51% of the network's computing power is likely to tamper with the existing data. Therefore, the blockchain system has the characteristics of ensuring data security and preventing attack and tampering that are unmatched by other centralized database systems. It can be seen that in the embodiments provided in this specification, the "information" provided by the information provider and included in the blockchain will not be attacked or tampered, thereby ensuring the authenticity and fairness of supervision. In order to further ensure the privacy of regulation, in the embodiment provided in this specification, the information provided by the information provider is encrypted with a key related to the public key of the information regulator; the encrypted information can only be used by the information regulator The private key related to the private key is decrypted to obtain the original information record, preventing other nodes co-located in the same blockchain from learning the plaintext of the information (ie the original information record). There are many encryption methods that can be decrypted by the corresponding information regulator, such as ECDSA and RSA. In the embodiments provided in this specification, the encryption method can be specifically set according to requirements. According to the blockchain-based information supervision method provided by the embodiments of the present specification, the information supervisor implements risk supervision processing on the original information record based on pre-configured supervision rules. There are many specific risk supervision processing schemes, such as digitizing the supervision rules Transform into corresponding regulatory indicators, compare the thresholds of the regulatory indicators with the values of the regulatory factors in the original information records obtained from the blockchain network, and then directly and effectively output the regulatory results according to whether or not the violations are violated; or from Identify the violation factor in the original information records obtained on the blockchain network. Once the violation factor is identified, the default risk supervision process is performed, such as early warning, alarm, and blockade. The plan for performing risk supervision processing on the original information records based on the pre-configured supervision rules is specifically set according to specific supervision requirements, and is not limited in this specification, thereby finally completing from the collection of supervision information to the supervised behavior The integrated digital supervision method of processing improves the convenience, economy, authenticity and efficiency of supervision behavior. The following uses the financial regulator to supervise the borrowing of the same borrower in the same online loan institution and different online loan institutions as an example to explain the specific implementation methods provided in this manual. In this embodiment, the financial supervisory authority is an information supervisor, each online loan institution is a different information provider, and the natural borrower user is the subject of supervision. In order to reduce the confirmation time of transactions or data, increase transaction transmission volume, and meet the requirements for security and performance, financial institutions usually choose the alliance chain architecture to construct the blockchain. Institutions with higher credit, such as large banks, giant enterprises, and some regulatory agencies, can be used as pre-selected nodes of the alliance chain to participate in the block accounting. The consensus process of the alliance chain is also controlled by the pre-selected nodes. When there are more than a set proportion of nodes (such as 2/3) on the network to confirm a block, the transactions or data recorded in the block will be confirmed by the entire network. The alliance chain can determine the degree of openness to the public according to the application scenario, and give open institutions permission to access the alliance chain. For example, in this embodiment, the financial regulator as an information regulator can participate in accounting for pre-selected nodes Each information provider such as an online loan institution may be a general node with access to the alliance chain; of course, the financial regulatory agency may also be a general node with access to the alliance chain, which is not limited in this specification. The alliance chain usually adopts proof-of-stake or consensus algorithms such as PBFT and RAFT. Figure 2 illustrates the consensus process of the simplified PBFT algorithm, where C is the client, N 0 ~ N 3 represent the service node, in particular, N 0 is the main node, and N 3 is the faulty node. The PBFT system usually assumes that the number of faulty nodes is m, and the total number of service nodes is 3m+1. In simple terms, the entire communication process is as follows: 1) The client sends a request to the master node to call the service operation; 2) After the master node receives the request, it starts a three-phase protocol to broadcast the request to each slave node; [2.1] Sequence number allocation phase (Also called pre-prepare phase), the master node assigns a serial number n to the request, broadcasts the serial number assignment message and the client's request message m, and constructs the PRE-PREPARE message to each slave node; [2.2] interactive phase (also called prepare stage), receive PRE-PREPARE message from the node, broadcast PRE-PREPARE message to other server nodes; [2.3] sequence number confirmation stage (also called commit stage), after each node verifies the request and order in the view, broadcast COMMIT message, execute the received client request and respond to the client. 3) The client waits for responses from different nodes. If m+1 responses are the same, the response is the result of consensus. As with all state machine replica replication technologies, PBFT puts forward two qualifications for each replica node: 1) All nodes must be deterministic. That is to say, in the case where the given state and parameters are the same, the result of the operation execution must be the same; 2) All nodes must start execution from the same state. Under these two limited conditions, even if the failed replica node exists, the PBFT algorithm agrees on the total order of execution for all non-failed replica nodes, thereby ensuring security. According to the consensus communication process shown in Figure 2, a batch of records generates a block, and finally forms a chain. The PBFT algorithm as a preferred embodiment provided in this specification is due to the high efficiency of consensus using this algorithm, which can meet the needs of high-frequency transaction volume, such as frequent loan transactions in this embodiment; and consensus The delay is very low, basically meeting the requirements of real-time processing, and can quickly and immediately output the supervision results to the supervision information; trusted nodes as pre-selected accounting nodes, taking into account the security and stability; in addition, the use of PBFT algorithm will not consume Excessive computer computing resources do not necessarily require token circulation, so it has good usability. More preferably, in the embodiments provided in this specification, each online loan institution acts as an information provider, and the information provided by it related to personal lending usually involves privacy information such as identity, as shown in Table 1, to ensure that it involves its own institution Or the plaintext of the borrower’s privacy information is only known to the corresponding financial regulatory agency with regulatory authority, but not to other nodes in the same blockchain or illegal use. Each online loan agency should encrypt the regulatory information it provides. There are many specific encryption methods. For example, online lending institutions may agree with financial supervisory institutions to encrypt and decrypt symmetric keys in advance; online loan institutions may also use keys related to financial supervisory institutions' public keys for asymmetric encryption Then, the financial regulator can use the key related to its private key to decrypt to obtain the plain text of the loan information provided by the online loan institution (as shown in Table 1), thereby preventing other nodes from learning the regulatory information. Table 1 Information table of personal C borrowing from individual B on the platform of online lending institution A For example, as shown in Figure 3, the online lending institution as an information provider first uses the corresponding public key of the financial regulatory institution to lend to it The plaintext of the information (as shown in Table 1) is encrypted to obtain the ciphertext of the loan information, and then to ensure that the ciphertext is not tampered with and forged, the online loan institution digitally signs the ciphertext and encrypts the pair of ciphertext The digital signature and the cipher text are uploaded together to the cache of the blockchain database where the online loan institution node is located; the bookkeeper of the blockchain, such as the pre-selected node in the alliance chain with accounting authority, needs to be included To verify the data records to the blockchain, the verification process must include the verification of the above digital signatures. The verification process is to prevent the data from being tampered with or the information is forged by other participants. The digital signature and ciphertext of the ciphertext are included in the blocks of the above-mentioned blockchain. After the digital signature of the ciphertext and the ciphertext are included in the blockchain as a pre-selected node in the alliance chain, as a node of the blockchain, the financial regulator can obtain the above from the blockchain For the digital signature and ciphertext of the ciphertext, accordingly, the financial regulator can decrypt the ciphertext by using the private key corresponding to the above public key, thereby obtaining the plaintext of the specific loan information. In this embodiment, the financial regulator as the information regulator may be a pre-selected node with accounting authority or an ordinary node, which is not specifically limited in this specification, as long as it has the digital signature and The cipher text has access to view permissions. The embodiments of this specification do not make specific limitations on the digital signature and verification algorithm, and the public-private key pair algorithm of the financial regulatory agency, and can use the elliptic curve algorithm and RSA algorithm to complete the relevant hash calculation. The method can be completed with MD5, SHA256, etc. Regarding the above process of encrypting the loan information to obtain the ciphertext, it can be implemented by the two parties agreeing on a symmetric key. For example, as shown in FIG. 4, an online loan institution as an information provider may encrypt the plain text of loan information by using ECDH to exchange keys. Those skilled in the art should know that in a blockchain system that uses the same elliptic curve algorithm (that is, the same straight line or base point) to obtain the public-private key pair related to the identity of the organization, the private key AS of the organization A and the organization The product of B's public key BP is equal to the product of organization A's public key AP and organization B's private key BS. That is: AS , In the embodiment described in this specification: the public key JP of the financial regulatory agency . Therefore, the online lending institution can use the key obtained by multiplying the public key JP of the corresponding financial regulatory institution and its own private key DS to encrypt the plain text of the loan information to obtain the cipher text of the loan information, similarly, and then to ensure the secret The text is not tampered with and forged. The online lending institution digitally signs the ciphertext, and the digital signature of the ciphertext, the ciphertext and the corresponding private key DS used for encrypting the loan information mentioned above The public key DP and the public key JP of the financial regulatory agency are uploaded together to the cache of the blockchain database where the online loan institution node is located; the bookkeeper of the blockchain, such as a pre-selected node in the alliance chain with accounting authority, First verify the digital signature. The verification process is to prevent the data from being tampered or the information is forged by other participants. After the verification, the accountant will sign the digital signature, ciphertext, and the above The public key DP corresponding to the private key DS used for the encryption of the loan information and the public key JP of the financial regulatory agency are included in the blocks of the above-mentioned blockchain. After the digital signature of the ciphertext, the ciphertext, and the public key corresponding to the private key used to encrypt the loan information described above are included in the blockchain by the pre-selected node in the alliance chain, the financial The supervisory authority can obtain the above digital signature and ciphertext for the ciphertext from the blockchain. Accordingly, the financial supervisory authority can use the private key JS corresponding to the public key JP obtained from the Internet and The key obtained by multiplying the obtained DP decrypts the ciphertext to obtain the plaintext of the specific loan information. Any other node cannot decrypt the ciphertext because it cannot know the private key JS of the financial supervisory authority. It is worth noting that since the same institution can have multiple sets of public-private key pairs in a blockchain, the public key DP and private key DS of the online loan institution used to encrypt credit information above may not necessarily be signed with the above-mentioned digital The private key and public key used in the process and signature verification are the same, but this does not affect the implementation of the technical solution, but reduces the possibility of being attacked by increasing the complexity of the system. Although the accounting node of the blockchain has verified the digital signature of the ciphertext when collecting the data, in order to further ensure the correctness of the supervision information source and prevent the data from being tampered with or malicious nodes to forge the data, the above examples provided in this specification In the description, after the financial regulator obtains the ciphertext of the loan information from the above blockchain, and the online loan agency digitally signs the loan information, it can first verify the obtained digital signature again. After the verification is passed, the above ciphertext is decrypted, thereby further preventing other institutions or individuals from forging loan information, and strengthening the authenticity and authority of the financial supervision. In the embodiments provided in this specification, the financial regulator as an information regulator can establish a regulatory risk engine to modularize the processing of loan information provided by various online loan institutions. As shown in FIG. 5, the regulatory risk engine may specifically include: a data input module M1, a regulatory indicator generation module M2, a risk decision module M3, a risk disposal module M4, and so on. It is worth noting that the above-mentioned risk supervision engine is only the actualized name of the risk supervision processing program, and there is no specific boundary between each module of the risk supervision engine. It is only for the convenience of explaining the function of the above-mentioned risk engine. Divide it into multiple modules. The data input module M1 is used to process the data obtained by the financial regulatory agency from the above-mentioned blockchain, including the ciphertext of the loan information, the digital signature of the online loan institution on the loan information, etc. According to the relevant decryption algorithm, Decrypt the ciphertext of the above loan information, or decrypt the ciphertext of the above loan signature after passing the digital signature verification, and the data information contained in the plain text of the loan information according to the data format required by the risk decision module M3 Parse. Since the data structure carried by the existing distributed shared network system or blockchain system is usually in text format and does not have good operability, the data input module M1 can tabulate the plain text of the decrypted loan information above Analyze and build the important data information needed in the risk decision module M3 into a table form, for example, restore it to the data table described in Table 1 above, and input it to the risk decision module M3. The supervision indicator generation module M2 is used to generate supervision indicators corresponding to supervision actions according to supervision regulations or guidelines. As in this embodiment, in order to supervise the behavior of "the upper limit of the borrowing balance of the same borrower in the same online loan institution", according to the financial law "the single individual and single natural person's borrowing limit on a platform is 200,000", Training establishes corresponding indicators. The training process is as follows: 1) As shown in FIG. 6, through automatic analysis techniques such as named entity recognition, grammatical analysis, and dependency analysis, the subject-predicate-object structure features of the sentence are dependency-analyzed to obtain action tuples (single, natural person or individual, Borrowing, going online, 200,000), and further transforming the regulatory compliance rules into a SQL statement executable by a computer program through a predefined mapping structure relationship. 2) Generate an indicator Z1′ and map it with the SQL statement generated in step 1, and store it together in the candidate of the regulatory indicator pool; 3) Manually review the above SQL statement, after revising and confirming the correctness of the above SQL statement, It is officially deposited in the regulatory indicator pool and named Z1 indicator; Z1 indicator includes the above executable SQL statement and its threshold value-20W. Similarly, the Z2 indicator can be trained based on the financial rule of “single individual, single natural person’s borrowing limit on multiple platforms is 1 million”; the Z2 indicator includes an executable SQL statement and its threshold— —100W. In the embodiment described in this specification, in order to facilitate the management of multiple regulatory indicators, a multi-fork tree storage structure of regulatory indicators set up in the regulatory indicator pool may be used to store multiple regulatory indicators, such as Z1 and Z2, in the multiple On the nodes of the fork tree. Further, in order to facilitate the uniform supervision of similar types of behavior, multiple different types of multi-fork trees can be set up in the supervision indicator pool, corresponding to the storage of corresponding types of supervision indicators, for example, a “natural person à loan alarm” is set up in the supervision indicator pool "Indicated multi-fork tree of indicators, on which Z1, Z2 and other indicators related to the borrowing behavior of natural person users on the online loan platform can be stored; should be "the same legal person or other organization on the same online loan information intermediary platform The upper limit of the borrowing balance of the loan does not exceed RMB 1 million" and other relevant regulatory measures. A multi-fork tree of "enterprise à borrowing alarm" regulatory indicators can also be set up in the regulatory indicator pool, which stores online loan platforms with corporate users Regulatory indicators related to the statutory limits on loans. Moreover, in order to facilitate multi-level supervision and better achieve the effect of early warning and prevention of illegal supervision, corresponding early warning indicators can be set for some indicators (the threshold corresponding to the early warning indicator can be set to 95% or other values of the full indicator threshold), for example For the "single individual, single natural person's borrowing on a platform does not exceed 19w" early warning supervision statement, according to the process of 1)--3) above, the early warning indicator Z1Y is generated, Z1Y includes the executable training trained by the above warning supervision statement The SQL statement and its corresponding threshold value of 19W are stored in the above-mentioned regulatory index pool. Similarly, a storage multi-fork tree of the “natural person à loan warning” indicator can be established in the regulatory indicator pool, and Z1Y is stored on the node of the multi-fork tree. The “Natural Person à Borrowing Warning” indicator multi-fork tree can also store Z2Y indicators related to the warning supervision of the same natural person’s borrowing behavior on multiple online loan platforms, which will not be repeated here. So far, the regulatory indicator generation module M2 has mapped the regulatory indicators to the executable SQL statements through the above data training, auditing, indicator creation, or indicator multi-fork tree creation process. The executable supervision model, the specific risk supervision and disposal process are carried out in the risk decision module M3. It is worth noting that in this manual, just to explain the convenience of each function of the above-mentioned risk engine, it is divided into multiple modules, and there is no specific boundary between each module. For example, the above-mentioned regulatory indicator pool can be attributed to the regulatory The generation module M2 can also be attributed to the risk decision module M3. As shown in FIG. 7, the above-mentioned regulatory indicator pool (the regulatory indicator data mart shown in the figure) is stored in the risk decision module M3, and the regulatory indicator pool may contain several regulatory indicators. After the risk decision module M3 receives the supervision instruction on "whether a single individual or a single natural person borrows on a platform needs early warning", it first searches its supervision indicator pool for the existence of the corresponding supervision indicator Z1Y, such as Exist, the risk decision module M3 enters the risk factor identification stage. The risk decision module M3 reads the data information input from the data input module M1, and identifies the supervision factor from the above data information for the supervision instruction. In this example, the supervision object is a single natural person who borrows, because the uniqueness determines whether the natural person is The single factor is the natural person’s ID number (or other unique user ID), so the supervision factor in this example is the natural person’s ID number, and then the risk decision module M3 enters the user in the SQL statement corresponding to the regulatory index Z1Y ID card number, run the SQL statement to query the ID card number, you can get the actual number of loans (balance) of the single natural person on the single platform, and compare the value of the supervision factor-the actual number of loans and the indicator Z1Y The threshold of 19W, the risk disposal module M4 of the risk engine outputs the corresponding regulatory treatment plan: when the actual borrowing amount of a single natural person is less than 19W, the risk disposal module M4 may not treat it as a risk event and do not respond; when a single natural person When the actual loan amount is higher than 19W, according to the default risk supervision processing logic, the risk treatment module M4 can send an early warning message to the corresponding online loan platform node, such as "a large amount of borrowing is about to reach the upper limit of the regulatory limit." Prevent the online lending institution's single platform from making new loans to the user in excess of the loanable balance, and reduce the possible losses of a business. The specific risk treatment plan mentioned above can be associated with regulatory indicators to facilitate the output of the treatment plan of the risk treatment module M4. If the above financial regulatory agency finds that a natural person’s borrowing on a single platform has exceeded the warning threshold, it can be linked to a plan to further monitor its alarm indicators: first, search for the corresponding regulatory indicator Z1 in its regulatory indicator pool, if it exists The risk decision module M3 enters the stage of risk factor identification. Similarly, the risk decision module M3 reads the data information input from the data input module M1, and identifies the supervision factor—the natural person’s ID number—from the data information for the supervision instruction, and then the risk decision module M3 Enter the ID number in the SQL statement corresponding to the indicator Z1, and run the query to get the actual number of loans borrowed by the single natural person on the single platform, and compare the value of the supervision factor--the actual loan number and the threshold of the indicator Z1 are 20W , The risk disposal module M4 of the risk engine outputs the corresponding regulatory treatment plan: when the actual borrowing amount of a single natural person is less than 20W, the risk disposal module M4 may not be output; when the actual borrowing amount of a single natural person is higher than 20W, the risk disposal Module M4 can send a strong alarm message to the corresponding online loan platform node, or report it to the supervisory authority or the higher supervisory authority. Similarly, the above specific risk treatment plan can be managed with specific regulatory indicators to facilitate the output of the risk treatment module M4's treatment plan. Of course, according to the specific requirements of supervision, the supervision of warning indicators can be omitted and the warning indicators can be directly regulated, which is not limited in this manual. When multiple regulatory indicators in the regulatory indicator pool are stored in the form of a multi-fork tree, since the multi-fork tree data structure is convenient for improving the efficiency of traversal search, in the face of "screening all regulatory indicators, monitoring for violations "Or similar general supervision directives, can improve the efficiency of supervision. When there are early warnings or violations in the universal supervision, financial regulators can traverse the multi-fork tree of regulatory indicators stored in their regulatory indicator pool, and make corresponding risk decisions for each established regulatory indicator. The specific process is similar to the above process for the regulatory index Z1 or the early warning regulatory index Z1Y, and will not be repeated here. It is worth noting that the above-mentioned risk treatment module M4's regulatory processing solution output for specific regulatory indicators (such as Z1Y or Z1) can also be associated with the node where the regulatory indicator is located and the multi-tree of the regulatory indicator, for example Two processing schemes are associated with the node of the regulatory index Z1Y: when the value of the regulatory factor is less than the threshold of the regulatory index Z1Y, no response is made; when the value of the regulatory factor is greater than or equal to the threshold of the regulatory index Z1Y, the corresponding network The loan platform node issues an early warning message. In this way, when the traversal supervision program for the storage multi-tree of the "natural person à borrowing alarm" indicator runs to the supervision indicator Z1Y, the ID number of the specific natural person is entered into the executable SQL statement of the indicator Z1Y and the The information provided by each platform is queried to obtain the actual loan value of the natural person on each platform. Based on the comparison between the value and the Z1Y threshold, the corresponding processing plan is output from the Z1Y node. The above technical solution that relates the regulatory processing program to the corresponding node of the regulatory multi-fork tree facilitates the risk processing program or risk processing engine to make risk processing faster, thereby improving the efficiency of supervision. By establishing the above-mentioned risk engine or executing the above-mentioned risk supervision processing program, the financial regulatory agency has completed the extraction of the regulatory query factor from the regulatory information, and compared the value of the regulatory query factor with the threshold of the regulatory index, and according to the The process of implementing the risk supervision and treatment plan based on the comparison results, especially by simultaneously monitoring the supervision information provided on multiple platforms, not only identifying the risks of a single platform, but penetrating and centrally monitoring multiple online loan platforms, which greatly reduces the risk of multiple platforms. The time and economic cost of offline supervision can effectively prevent cross-institution and cross-region violations. In the embodiments provided in this specification, the implementation of the above-mentioned pre-configured supervision rules to implement risk supervision processing on the original information records can be implemented by programmatic operation of information supervision parties such as centralized servers of financial supervision institutions It can also call the risk supervision smart contract published on the supervision blockchain, execute the execution program corresponding to the supervision rules declared in the smart contract, and perform risk supervision processing on the original information record. The issuer of the smart contract can be either the financial supervisory authority or the superior supervisory authority of the financial supervisory authority-for the convenience of supervision, the superior supervisory authority can publish a common smart contract program for multiple subordinate supervisory authorities for each Used by lower-level regulatory agencies. Those skilled in the art should know that compared with the centralized server operation mode, smart contracts are called at any time according to user requests, which greatly improves the efficiency of supervision; and smart contract execution has low human intervention and The advantages of centralized authority further increase the fairness of regulatory actions. Corresponding to the above process implementation, the embodiments of the present specification also provide a decentralized information supervision device. The device can be realized by software, or by hardware or a combination of hardware and software. Taking software implementation as an example, as a logical device, it is formed by reading the corresponding computer program instructions into the memory through the CPU (Central Process Unit) of the device. From the hardware level, in addition to the CPU, internal memory, and memory shown in FIG. 9, the device where the network risk business implementation device is located usually includes other hardware such as chips for wireless signal transmission and reception. And/or other hardware such as boards for network communication. FIG. 8 shows an information supervision device based on a blockchain provided by this specification. The blockchain includes at least one information supervision node and several information provider nodes. The information supervision device includes an information acquisition unit 802 for Obtain the encrypted information record issued by the information provider from the information supervisor; wherein the encrypted information record is encrypted based on a key related to the public key of the information supervisor; the information decryption unit 804 is used for A key related to the private key of the information regulator, decrypts the encrypted information record to obtain the original information record; a risk supervision processing unit 806 is used to perform risk supervision on the original information record based on pre-configured supervision rules deal with. For the implementation process of the functions and functions of each module in the above device, please refer to the implementation process of the corresponding steps in the above method for details, which will not be repeated here. As for the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to the description of the method embodiments. The device embodiments described above are only schematic, wherein the modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules. It can be located in one place, or it can be distributed on multiple network modules. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution in this specification. Those of ordinary skill in the art can understand and implement without paying creative labor. The system, device, module or module explained in the above embodiments may be implemented by a computer chip or entity, or by a product with a certain function. A typical implementation device is a computer, and the specific form of the computer may be a personal computer, a laptop computer, a mobile phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email sending and receiving device, and a game control Desk, tablet, wearable device, or any combination of these devices. Corresponding to the above method embodiments, the embodiments of the present specification provide a computer device, which includes a memory and a processor. Among them, a computer program that can be executed by the processor is stored on the memory; when the processor runs the stored computer program, each step of the implementation method of information supervision based on blockchain in the embodiments of the present specification is executed. For a detailed description of each step of the above information supervision implementation method, please refer to the previous content and will not be repeated. Corresponding to the above method embodiments, the embodiments of the present specification provide a computer-readable storage medium on which computer programs are stored. When the computer programs are executed by a processor, the computer-based storage programs execute block-based storage in the embodiments of the present specification. Each step of the implementation method of chain information supervision. For a detailed description of each step of the above information supervision implementation method, please refer to the previous content and will not be repeated. The above are only the preferred embodiments of this specification and are not intended to limit this specification. Any modification, equivalent replacement, improvement, etc. made within the spirit and principles of this specification should be included in this specification Within the scope of protection. In a typical configuration, the computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory. Memory may include non-permanent memory, random access memory (RAM) and/or non-volatile memory in computer-readable media, such as read-only memory (ROM) or flash memory ( flash RAM). Memory is an example of computer-readable media. Computer-readable media, including permanent and non-permanent, removable and non-removable media, can be stored by any method or technology. The information can be computer readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM) , Read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, read-only disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic tape cassettes, magnetic tape storage or other magnetic storage devices or any other non-transmission media can be used to store information that can be accessed by computing devices. According to the definition in this article, computer-readable media does not include temporary computer-readable media (transitory media), such as modulated data signals and carrier waves. It should also be noted that the terms "include", "include" or any other variant thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device that includes a series of elements includes not only those elements, but also includes Other elements not explicitly listed, or include elements inherent to this process, method, commodity, or equipment. Without more restrictions, the element defined by the sentence "include one..." does not exclude that there are other identical elements in the process, method, commodity, or equipment that includes the element. Those skilled in the art should understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, the embodiments of the present specification may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the embodiments of the present specification may employ computer programs implemented on one or more computer usable storage media (including but not limited to disk memory, CD-ROM, optical memory, etc.) containing computer usable program code The form of the product.
