作(zuò)者 | 丁藝明，榮澤科(kē)技區塊鏈高級咨詢顧問(wèn)、高級架構師(shī)

拜占庭問(wèn)題

探究區塊鏈其源頭，我們不得(de)不追溯到“拜占庭将軍問(wèn)題”。它是整個區塊鏈技術(shù)核心思想的真正根源，也直接決定了區塊鏈技術(shù)的種種與衆不同的颠覆性特質。

在2013年(nián)獲得(de)計(jì)算機(jī)科(kē)學領域最高獎項圖靈獎的31年(nián)前，萊斯利·蘭伯特（Leslie Lamport）加入斯坦福國(guó)際研究院（SRI）。在SRI那段歲月裡(lǐ)， 有一個項目，要在美國(guó)航空航天局建立容錯型航電計(jì)算機(jī)系統。考慮到系統的工(gōng)作(zuò)性質，故障是不允許發生(shēng)的。這段經曆孕育了兩篇旨在解決一種特殊故障的論文，由蘭伯特和SRI同事(shì)馬歇爾·皮斯（Marshall Pies）及羅伯特·肖斯塔克（Robert Shostak）合作(zuò)完成。使用計(jì)算機(jī)術(shù)語，普通故障可(kě)能會導緻信息丢失或進程停止，但(dàn)系統不會遭到破壞，因爲這種普通故障屬于一出錯就(jiù)會停下來(lái)的故障類型，剩下的備份的、正常的部分(fēn)照(zhào)樣可(kě)以運轉，發揮作(zuò)用。就(jiù)像戰場上的士兵(bīng)，他(tā)們一旦受傷或陣亡就(jiù)停止戰鬥，但(dàn)并不妨礙他(tā)人(rén)繼續作(zuò)戰。然而一旦發生(shēng)“拜占庭故障”，就(jiù)會非常麻煩，因爲它們不會停下來(lái)，還(hái)會繼續運轉，并且給出錯誤訊息。就(jiù)像戰争中有人(rén)成了叛徒，會繼續假傳軍情，惑亂人(rén)心。使用三台計(jì)算機(jī)進行萬一其中一台出錯的備份工(gōng)作(zuò)，并不能完全解決這個問(wèn)題。三台獨立的計(jì)算機(jī)按照(zhào)少數服從(cóng)多數的原則“投票”。要求其中一台機(jī)器提供了錯誤結果的情況下，其他(tā)兩台仍然會提供正确答案。但(dàn)是爲了證明這種解決“拜占庭故障”方法的有效性，必須拿出證據。而在編寫證據的過程中，研究人(rén)員(yuán)遇到了一個問(wèn)題：“錯誤”的計(jì)算機(jī)可(kě)能給其他(tā)兩台計(jì)算機(jī)發送互不相(xiàng)同的信息，而後者卻無法區别正确性。這就(jiù)需要使用第四台計(jì)算機(jī)來(lái)應對這類“拜占庭故障”。

蘭伯特認爲把問(wèn)題以講故事(shì)的形式表達出來(lái)更能引起人(rén)們的關注。蘭伯特還(hái)聽吉姆·格雷談論過另一個性質大(dà)體(tǐ)相(xiàng)同的問(wèn)題，這引起了蘭伯特有關司令将軍和叛徒将軍的聯想，于是他(tā)将這個問(wèn)題及其解決方案命名爲“拜占庭将軍問(wèn)題”。

拜占庭帝國(guó)想要進攻一個強大(dà)的敵人(rén)，爲此派出了10支軍隊去(qù)包圍這個敵人(rén)。這個敵人(rén)雖不比拜占庭帝國(guó)，但(dàn)也足以抵禦5支常規拜占庭軍隊的同時襲擊。基于一些原因，這10支軍隊不能集合在一起單點突破，必須在分(fēn)開的包圍狀态下同時攻擊。他(tā)們任一支軍隊單獨進攻都(dōu)毫無勝算，除非有至少6支軍隊同時襲擊才能攻下敵國(guó)。他(tā)們分(fēn)散在敵國(guó)的四周，依靠通信兵(bīng)相(xiàng)互通信來(lái)協商進攻意向及進攻時間。困擾這些将軍的問(wèn)題是，他(tā)們不确定其中是否有叛徒，叛徒可(kě)能擅自(zì)變更進攻意向或者進攻時間。在這種狀态下，拜占庭将軍們能否找到一種分(fēn)布式的協議(yì)來(lái)讓他(tā)們能夠遠(yuǎn)程協商，從(cóng)而赢取戰鬥？這就(jiù)是著名的拜占庭将軍問(wèn)題。

應該明确的是，拜占庭将軍問(wèn)題中并不去(qù)考慮通信兵(bīng)是否會被截獲或無法傳達信息等問(wèn)題，即消息傳遞的信道絕無問(wèn)題。蘭伯特已經證明了在消息可(kě)能丢失的不可(kě)靠信道上試圖通過消息傳遞的方式達到一緻性是不可(kě)能的。所以，在研究拜占庭将軍問(wèn)題的時候，我們已經假定了信道是沒有問(wèn)題的，并在這個前提下，去(qù)做一緻性和容錯性相(xiàng)關研究。

口頭消息算法，簡稱OM（m）

在原始的戰争年(nián)代，将軍與将軍、将軍與下屬間隻能采用原始的方式——“出行靠走，通訊靠吼”的口頭傳輸。這對應蘭伯特論文提出算法中的第一部分(fēn)的口頭消息算法，簡稱OM（m）算法。這種情形，真僞很難辨别，隻有當叛徒的總數不超過将軍總數的1/3，成爲一個特殊的“拜占庭容錯系統”時，才能在很大(dà)的消息驗證代價後，實現最終的一緻行動。這個結果非常令人(rén)驚訝，如(rú)果将軍們隻能發送口頭消息，除非超過2/3的将軍是忠誠的，否則該問(wèn)題無解。尤其是，如(rú)果隻有三個将軍，其中一個是叛變者，那麽此時無解。但(dàn)這樣的錯誤，這樣的有意、無意的“叛徒”卻可(kě)能經常出現。

首先，我們明确什麽是口頭協議(yì)。我們将滿足以下三個條件(jiàn)的方式稱爲口頭協議(yì)：

A1：每個被發送的消息都(dōu)能夠被正确的投遞

A2：信息接收者知道是誰發送的消息

A3：能夠知道缺少的消息

簡而言之，信道絕對可(kě)信，且消息來(lái)源可(kě)知。

定義一個變量vi（爲不失一般性，并不要求vi是布爾值），作(zuò)爲其他(tā)将軍收到的第i個将軍的命令值；i将軍會将把自(zì)己的判斷作(zuò)爲vi。可(kě)以想象，由于叛徒的存在，各個将軍收到的vi值不一定是相(xiàng)同的。之後，定義一個函數來(lái)處理(lǐ)向量(v1,v2,…,vn)，代表了多數人(rén)的意見(jiàn)，各将軍用這個函數的結果作(zuò)爲自(zì)己最終采用的命令。至此，我們可(kě)以利用這些定義來(lái)形式化這個問(wèn)題，用以匹配一緻性和正确性。

一緻性

條件(jiàn)1：每一個忠誠的将軍必須得(de)到相(xiàng)同的(v1,v2,…,vn)指令向量或者指令集合。

這意味着，忠誠的将軍并不一定使用i将軍送來(lái)的信息作(zuò)爲vi，i将軍也可(kě)能是叛徒。但(dàn)是僅靠這個條件(jiàn)，忠誠的将軍的信息送來(lái)的信息也可(kě)能被修改，這将影(yǐng)響到正确性。    

正确性

條件(jiàn)2：若i将軍是忠誠的，其他(tā)忠誠的将軍必須以他(tā)送出的值作(zuò)爲vi。

OM(0)算法

1. 司令将他(tā)的命令發送給每個副官。

2. 每個副官采用從(cóng)司令發來(lái)的命令；如(rú)果沒有收到命令，則默認爲撤退命令

OM(m)算法

1. 司令将他(tā)的命令發送給每個副官。

2. 對于每個i，vi是每個副官i從(cóng)司令收到的命令，如(rú)果沒有收到命令，則默認爲撤退命令。副官i在OM(m-1) 中作(zuò)爲發令者将之發送給另外n-2 個副官。

3. 對于每個i，和每個j ≠ i，vj 是副官i 從(cóng)第2步中的副官j （使用OM(m-1)算法）發送過來(lái)的命令，如(rú)果沒有收到第2步中副官j 的命令，則默認爲撤退命令。最後副官i 使用majority(v1,…,vn-1)得(de)到命令。

其中，majority(v1,…,vn-1)代表了大(dà)多數人(rén)的命令，若不存在則默認爲撤退命令。

口頭消息算法實例推演

考慮m=1，n=4的情形：

n=4，意味着一個司令發送命令給三個副官，m=1意味着他(tā)們中有一個叛徒。首先考慮司令忠誠而副官3是叛徒的情況。

圖1   m=1，n=4中司令忠誠而副官3是叛徒的情形

參考圖1，

L1收到：（A，A，R）=》輸出共識 majority(A，A，R) = A

L2收到：（A，A，R）=》輸出共識 majority(A，A，R) = A

L3收到：（A，A，A）=》輸出共識 majority(A，A，R) = A

那麽對于副官1（或副官2）來(lái)說(shuō)将會采用A。

倘若司令是叛徒，爲方便，我們假設叛徒司令在OM(1)會給三個副官發送的信息是(x,y,z)，其中x，y，z都(dōu)可(kě)以是A或R的任意一種。之後，三位忠誠的副官将會按照(zhào)OM(0)要求的那樣，交換他(tā)們收到的信息。

圖2  m=1，n=4中司令是叛徒的情形

L1收到：（x，y，z）=》輸出共識 majority（x，y，z） ；

L2收到：（x，y，z）=》輸出共識 majority（x，y，z）；

L3收到：（x，y，z）=》輸出共識 majority（x，y，z）。

對于副官1，他(tā)綜合司令、副官2和副官3後得(de)到的消息向量将會是(x,y,z)，可(kě)以發現對于其他(tā)兩個忠實的副官，他(tā)們得(de)到的消息向量也将是(x,y,z)。不管x，y，z如(rú)何變化，majority(x,y,z)對于三人(rén)來(lái)說(shuō)都(dōu)是一樣的，所以三個副官将會采用一緻的行動。

口頭消息算法證明

算法的證明思路(lù)其實并不複雜，簡單的來(lái)說(shuō)，對于一個遞歸算法，基于一個叛徒情景下的實例推演，可(kě)使用數學歸納法來(lái)證明。考慮篇幅，這裡(lǐ)未提供完整的證明，可(kě)參考相(xiàng)關資料。

HyperLedger1.0系統架構

Hyperledger是被業界非常看(kàn)到的聯盟鏈的實現，包括IBM、Intel、R3、各個大(dà)型商業銀行等都(dōu)參與其中，帶給我們關于區塊鏈技術(shù)與軟件(jiàn)工(gōng)業、金融、保險、物流等領域碰撞結合的想象空間；在這個聯盟中，有超過1/4的成員(yuán)都(dōu)來(lái)自(zì)中國(guó)，這更是我們對于它的一舉一動都(dōu)非常關注。很大(dà)程度上，Hyperledger和它背後的聯盟體(tǐ)系就(jiù)代表着區塊鏈在産業環境中的未來(lái)。

主要模塊：

• 客戶端SDK（Client SDK）: 協助應用安全管理(lǐ)、和協助處理(lǐ)區塊鏈上交易事(shì)務。

• 節點是網絡中的組成部分(fēn)，負責維護節點的賬本和職能合約。

• 任意多個節點可(kě)參與到網絡中。

• 節點類型可(kě)以是背書(shū)節點（endorser）、或交付節點（committer ）。背書(shū)節點必然是交付節點。

• 背書(shū)節點執行并對交易事(shì)務進行背書(shū)。

• 交付節點驗證背書(shū)結果并對交易事(shì)務進行驗證。

• 節點管理(lǐ)事(shì)件(jiàn)集線器（event hub）并發送事(shì)件(jiàn)給訂閱者。

• 節點組建成一P2P網絡。

• 節點是無運行狀态的，事(shì)務與事(shì)務間是獨立的。

• 排序服務（Ordering Service）：是處于一個非中心化的網絡中的一個中心化的節點。其排序服務是一可(kě)插拔的組件(jiàn)，例如(rú)Kafka、或BFT等。

• 成員(yuán)權限管理(lǐ)：通過基于 PKI 的成員(yuán)權限管理(lǐ)，平台可(kě)以對接入的節點和客戶端的能力進行限制。

圖3  HyperLedger1.0系統結構圖

事(shì)務交易流程

HyperLedger1.0的共識機(jī)制（Consensus）是通過事(shì)務背書(shū)策略（Transaction Endorsement Policy）、排序服務、和各提交節點Committer的校(xiào)驗這三個措施保證的。

背書(shū)（Endorsement）: 每個背書(shū)節點（stakeholder ）決定是否接受或拒絕一事(shì)務。

排序服務（Ordering）: 對執行後的事(shì)務進行排序形成一即将提交的區塊。

校(xiào)驗（Validation）: 所有提交節點（Committer ）都(dōu)需校(xiào)驗事(shì)務的背書(shū)是否滿足背書(shū)政策（Endorsement Policy），同時根據數據庫多版本并發控制MVCC，校(xiào)驗事(shì)務轉換是否有效。

以背書(shū)節點n=4、提交節點數p=5爲例子。背書(shū)策略設置爲：4個背書(shū)節點中，允許1個拜占庭故障節點情況下，要求有3個以上的有效簽名。

圖4  事(shì)務交易流程

也就(jiù)是，如(rú)果允許m個無效簽名的情況下，要求背書(shū)節點總數n>=3*m + 1，即需要有效簽名數n-m>=2*m+1。如(rú)圖4所示事(shì)務處理(lǐ)流程爲：

步驟1：提交事(shì)務

客戶端SDK提交一報文爲Propose的消息的交易事(shì)務Transaction到客戶端選擇的背書(shū)節點E0，要求執行一智能合約A。

圖5   步驟1提交事(shì)務

步驟2：第一個背書(shū)節點執行事(shì)務

被客戶端選中的背書(shū)節點E0模拟交易的執行。

圖6   步驟2第一個背書(shū)節點執行事(shì)務

步驟3：其他(tā)背書(shū)節點執行事(shì)務

客戶端根據背書(shū)策略，要求其他(tā)節點E1E2和E3進一步背書(shū)。

圖7   步驟3其他(tā)背書(shū)節點執行事(shì)務

步驟4：背書(shū)簽名

背書(shū)節點對智能合約的執行結果進行簽名，并發送背書(shū)簽名給客戶端。

圖8  步驟5提交排序服務

步驟5：提交排序請(qǐng)求

最後，客戶端根據背書(shū)政策（Endorsement Policy）檢查是否滿足條件(jiàn)，若滿足條件(jiàn)則發送給排序服務。

圖9  步驟6交付

步驟6：交付

排序服務集群交付事(shì)務執行結果的下個版本的賬本數據塊給各節點。

圖10  步驟7校(xiào)驗并更新

區塊鏈應用于政務網

傳統中心化的電子證照(zhào)技術(shù)自(zì)2008年(nián)發展至今，解決了傳統模式下的數據歸集和中心化的數據标準與安全問(wèn)題。但(dàn)經過近十年(nián)的“互聯網+政務服務”的應用發展，該技術(shù)也凸顯它的局限性。

• 跨部門(mén)的政務數據是否可(kě)信

• 信息難以全面歸集

• 信息難以快(kuài)速檢索

• 信息洩露安全隐患

• 系統穩定性難度大(dà)

• 金字塔模式效率低下

雖然已有的人(rén)口信息、法人(rén)信息實現了部分(fēn)集中管理(lǐ)，但(dàn)中心化系統存在信息洩露，存儲丢失等風(fēng)險，而且中心化系統的建設、維護成本非常高，無法交互驗證，無法實現各個部門(mén)真正意義上的信息共享、共建。所以，如(rú)何在現有的電子政務基礎上，打破部門(mén)的數據壁壘，實現各部門(mén)之間的高效協作(zuò)，實現真正意義的“一張網”，爲群衆提供便利的服務，是政務工(gōng)作(zuò)迫切需要解決的問(wèn)題。

另外，區塊鏈技術(shù)具有信息共享、信息透明、難以篡改的優勢。利用該優勢可(kě)打破原有信息傳遞的壁壘，實現電子證照(zhào)服務模式的創新，提升用戶體(tǐ)驗。

目前證照(zhào)辦理(lǐ)過程中，大(dà)部分(fēn)步驟需在線下處理(lǐ)，并且受到地域、時間的限制，需消耗較多的時間；同時紙質證明存在易僞造風(fēng)險，相(xiàng)關證明接收機(jī)構還(hái)需核驗證明的真僞性。

通過區塊鏈技術(shù)打造各類證明的線上認證服務模式，可(kě)以提供證明從(cóng)申請(qǐng)、開立、查詢、銷毀的全流程服務，打造電子證明生(shēng)态圈。該創新将帶來(lái)巨大(dà)的社會效益：

對于證明所有者，無須在證明開立方和證明使用方來(lái)回傳遞紙質證明，省卻了物理(lǐ)地點（如(rú)異地）對證明開立及使用的限制；

對于證明提供方的權威機(jī)構，可(kě)通過自(zì)動化審批替代目前的人(rén)工(gōng)審批，大(dà)大(dà)提高了工(gōng)作(zuò)效率和服務水平；

對于證明需求方，基于區塊鏈的電子證明難以僞造及篡改，大(dà)大(dà)降低了虛假證明的風(fēng)險。

圖11  “我的南(nán)京”App政務辦理(lǐ)

在南(nán)京政府多部門(mén)的支持下，率先上線全國(guó)第一批基于區塊鏈接技術(shù)的電子證照(zhào)共享平台。參見(jiàn)圖11，市民(mín)可(kě)通過“我的南(nán)京”App進行政務的辦理(lǐ)，“我的南(nán)京”App是該電子證照(zhào)共享平台的數據訪問(wèn)終端。電子證照(zhào)共享平台由政府職能部門(mén)共同組成的電子證照(zhào)區塊鏈網絡，建立起政府部門(mén)之間點對點的可(kě)信網絡。采用區塊鏈的去(qù)中心化同步記帳、交易身(shēn)份認證、數據不可(kě)篡改、以及數據加密等多種技術(shù)手段。參見(jiàn)圖12電子證照(zhào)政務網結構圖，網絡由信息中心、公安、民(mín)政、社保、稅務、衛生(shēng)等多個節點組成。共享賬本中存儲公民(mín)信息和數據歸集記錄。在智能合約中實現了數據目錄規則、和數據隐私管理(lǐ)規則。現有電子證照(zhào)網絡隻支持南(nán)京市的數據，考慮到擴展性支持，通過全國(guó)索引節點，不同城(chéng)市不同省份的數據索引到不同的電子證照(zhào)區塊鏈子網。

圖12  電子證照(zhào)政務網結構圖

基于區塊鏈技術(shù)的電子證照(zhào)共享平台與傳統的電子證照(zhào)庫相(xiàng)比，具有更好的真實現、安全性、穩定性及可(kě)行性，解決了傳統中心化架構的電子證照(zhào)庫采集和應用過程中權責不分(fēn)的問(wèn)題，徹底解決了數據被篡改的可(kě)能性，并通過激勵機(jī)制提升數據相(xiàng)關方共享數據的積極性，且具備數據不被篡改、去(qù)中心化、數據加密及信任傳遞的特征，創新實現電子證照(zhào)在全省、全市範圍内跨區域的信息歸集、快(kuài)速檢索和結果應用。透過任意職能部門(mén)提供照(zhào)證證明服務，提高政務工(gōng)作(zuò)效率，提高市民(mín)、企業的辦事(shì)效率。對進一步推進南(nán)京“互聯網＋政務服務”，深化簡政放(fàng)權、放(fàng)管結合，實現各部門(mén)、各層級間政務服務數據共享，促進政府高效施政，提供了強有力的支持。

區塊鏈弱并發問(wèn)題

在應用區塊鏈解決方案于政務網工(gōng)程建設過程中，發現不少區别于傳統關系型數據庫的區塊鏈特點。

HyperLedger其設計(jì)目标主要包括一緻性（共識）、保密性、可(kě)擴展性和安全性，但(dàn)是對高并發寫事(shì)務的支持并不其主要目标。HyperLedger采用樂觀鎖（多版本并發控制）機(jī)制來(lái)支持并發，當交付節點（Submitter Peers）提交事(shì)務之前，如(rú)果發現ReadSet和WriteSet已經不一緻了，将回滾事(shì)務。客戶端需要盡可(kě)能避免同一關鍵字的寫沖突，如(rú)果寫沖突，需要多次提交事(shì)務。

假設在同一時刻有10個事(shì)務同時提交，當時這10個事(shì)務讀(dú)取到的賬本的數據一緻。第一階段，各背書(shū)節點執行事(shì)務，計(jì)算每個事(shì)務的讀(dú)集合ReadSet0~9（K,V）和寫集合WriteSet0~9（K,V），并提交到排序服務；第二階段，排序服務對10個事(shì)務進行排序，并依次提交到所有的交付節點（Submitter Peers），交付節點會根據當前賬本中的值檢查對應于某一事(shì)務的讀(dú)集合和寫集合。如(rú)果對于同一個鍵Key，被前一個事(shì)務修改了，則該事(shì)務的讀(dú)集合與當前賬本的讀(dú)集合不一緻，則該事(shì)務不得(de)不回滾。

爲了避免并行執行的事(shì)務讀(dú)寫沖突，提升事(shì)務的并發執行效率。對于出現讀(dú)寫沖突的事(shì)務，采用拆分(fēn)事(shì)務成爲兩個階段的方法，在背書(shū)階段記錄事(shì)務的明細賬，在提交階段才進行彙總。例如(rú)對于會員(yuán)積分(fēn)變更的應用場景，在背書(shū)階段，記錄會員(yuán)積分(fēn)的變化明細，+ x1 + ... + xi 和 - y1 - ... - yi，在提交階段才進行彙總積分(fēn)的變更 D += + x1 + ... + xi - y1 - ... - yi 。

關系型數據建模的支持

區塊鏈的底層數據模型爲比較簡單的鍵值對Key/Value模型，對于現實中的結構化數據的建模一般采用關系數據模型，如(rú)果采用Key/Value模型，開發人(rén)員(yuán)需要耗費很多精力用于各種應用場景下數據模型的建設，和數據的索引、查詢、統計(jì)等常規處理(lǐ)；同時存儲在區塊鏈中的數據需要進行進一步的大(dà)數據分(fēn)析和數據挖掘工(gōng)作(zuò)，需要支撐區塊鏈中的數據的導入導出到關系型數據庫。另外現有區塊鏈還(hái)沒有支持數據的隐私保護、數據的提交維護和訪問(wèn)的權限管理(lǐ)。需要一完善的區塊鏈數據建模基礎框架來(lái)解決這些基于區塊鏈的應用開發問(wèn)題。

基于鍵值數據模型爲基礎進行關系型數據建模，其支持的特征包括：

基于鍵值數據模型，選擇一取值唯一的字段作(zuò)爲鍵，包括多個屬性字段的記錄作(zuò)爲值，記錄用獨立于語言的輕量級數據交換格式JSON進行編碼。

支持表結構、索引結構數據字典的維護；屬性字段支持數值類型、字符串類型、日(rì)期類型。這些類型的字段是有序的、可(kě)建索引的；支持屬性索引，索引類型包括唯一索引、非唯一索引。索引的維護與記錄的增删改同步，同時索引數據結構的維護對模型的使用者透明。對于複雜結構的字段例如(rú)結構數組，可(kě)用JSON編碼，隻是該JSON類型字段不支持索引。另外利用索引支持數據約束，例如(rú)屬性字段取值的唯一性約束。

支持豐富的數據查詢方式，例如(rú)根據鍵的某一取值查詢記錄；根據鍵的取值範圍查詢多條記錄；根據已建立唯一索引的屬性字段的某一取值查詢記錄；根據已建立非唯一索引的屬性的某一取值，或屬性字段的取值範圍查詢多條記錄；支持分(fēn)組統計(jì)，例如(rú)基于屬性字段的非唯一索引進行分(fēn)組統計(jì)，統計(jì)函數包括個數統計(jì)、取分(fēn)組的最大(dà)值、最小值、平均值；支持分(fēn)頁查詢和分(fēn)頁統計(jì)；支持區塊鏈數據的導入導出到關系型數據庫，用于支撐數據分(fēn)析。

後續豐富的政務網應用

本電子證照(zhào)共享平台還(hái)将實現更多政務事(shì)項在線辦理(lǐ)功能，如(rú)：“購(gòu)車資格證明在線辦理(lǐ)”、“戶口在線遷入”、“社保在線轉移”、“公積金在線提取”、“護照(zhào)在線辦理(lǐ)”、“出入境自(zì)助簽注”等。