fabric1.0與0.6相比改動較大激才，解決了不少痛點(diǎn)問題。第一：動態(tài)增加節(jié)點(diǎn)功能 第二：分鏈結(jié)構(gòu)鞍匾，容易實(shí)現(xiàn)spv 第三：策略管理（過濾器）機(jī)制，增加權(quán)限控制骑科。 第四：提高高可用性HA（此詞來自于殷舒～若使用不當(dāng)和我沒關(guān)系～～）增加kafka集群橡淑。第五：支持合約升級，有利于后期維護(hù)咆爽。第六：將ca功能拆分梁棠，ca證書分發(fā)的過程可以單獨(dú)處理。第七：模塊分割斗埂，結(jié)構(gòu)清晰符糊，各模塊分工明確。

fabric1.0整體流程是客戶端通過grpc連接peer的endorser server呛凶，endorser server仿真智能合約男娄，仿真結(jié)果簽名后返回客戶端，客戶端通過Broadcast將返回結(jié)果發(fā)送至orderer漾稀，orderer處理數(shù)據(jù)將結(jié)果交給kafka集群模闲，orderer切割kafka交易成塊，orderer將切割的block信息通過Deliver發(fā)送給commiter peer崭捍，committer peer之間通過gossip來實(shí)現(xiàn)一致性尸折，commit peer 存儲到db中。

fabric1.0管理不是以chaincode為處理單元殷蛇，而是以chainID分割实夹，也就是說以鏈為單位進(jìn)行處理。fabric1.0以channel為載體粒梦，peer節(jié)點(diǎn)與orderer通信前提是搭建channel亮航，而且每個channel只能承載一條鏈chainid，每個chainid 可以承載多個智能合約谍倦。（多個智能合約用一條鏈，ledger數(shù)據(jù)也是在一起泪勒？）這種思想有利于動態(tài)增加節(jié)點(diǎn)昼蛀，peer節(jié)點(diǎn)關(guān)心的chainid可以直接向orderer進(jìn)行訂閱（join channel）宴猾。

fabric0.6處理交易信息都是由peer節(jié)點(diǎn)進(jìn)行處理，而在1.0里交易由endorser server接收后叼旋，都是要交給system chaincode處理仇哆。目前一共由五個系統(tǒng)級chaincode，他們分別是：

cscc：負(fù)責(zé)joinchannel／config update等
escc：負(fù)責(zé)對傳入數(shù)據(jù)進(jìn)行簽名（msp管理）
lccc：負(fù)責(zé)deploy invoke
vscc：負(fù)責(zé)簽名驗(yàn)證／策略驗(yàn)證（這里如何進(jìn)行策略驗(yàn)證夫植？）
qscc：負(fù)責(zé)ledger查詢

這五個系統(tǒng)級應(yīng)用綁定在chainID：test_id 上讹剔，這五個又分成chainlessCC chainCC,例如cscc用于joinchannel沒有數(shù)據(jù)需要單獨(dú)存儲所以是ChainlessCC，escc執(zhí)行合約產(chǎn)生的數(shù)據(jù)需要保存所以是ChainCC详民，形象說endorser peer節(jié)點(diǎn)搭建合約仿真環(huán)境的時候延欠，需要考慮是否要給其流出存儲接口，合約產(chǎn)生的數(shù)據(jù)都提交到這個接口沈跨，合約結(jié)束后統(tǒng)計數(shù)據(jù)內(nèi)容由捎。

Peer節(jié)點(diǎn)Ledger：
類型：state存儲／block存儲／ledgerProvider／index
statedb：用于存儲世界狀態(tài)可選：leveldb couchdb
blockdb：存儲block信息，leveldb
indexdb：存儲塊號索引 txid饿凛，leveldb
ledgerProviderdb：屬于管理db狞玛，記錄整個peer一共由多少chainID ledger
／＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

Ledger工程描述（可跳過）：
init期間創(chuàng)建“openedLedgers”的map表，key：chainID涧窒，value：PeerLedger實(shí)例對象心肪。PeerLedger數(shù)據(jù)結(jié)構(gòu)由三個重要成員變量：statedb操作句柄／blockdb＋indexed操作句柄／ledgerProviderdb操作句柄。所以每個chainID在創(chuàng)建的時候都要創(chuàng)建chainID－PeerLedger操作句柄纠吴。在初始化期間創(chuàng)建ledgerProvider對象硬鞍，該對象是各Ledgerdb的總句柄，chainID—PeerLedger的分配就是由ledgerProvider管理呜象。
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊／
Orderer節(jié)點(diǎn)ledger：
類型：block存儲db
可選file ram兩種方式
／＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
Ledger工程描述（可跳過）：
Orderer是以chainID為單位進(jìn)行l(wèi)edger存儲膳凝，其方式與Peer 節(jié)點(diǎn)非常相似，map中key為chainID恭陡，value：能夠?qū)lock進(jìn)行操作的ReadWrite對象／以及便于查找的鏈表指針（ram方式是采用的鏈表方式存儲）為什么不采用數(shù)組而采用鏈表呢蹬音？這里是因?yàn)槠湟S護(hù)一個動態(tài)的臨時block組，當(dāng)block數(shù)量過多的時候要從低塊號刪除block休玩，數(shù)組刪除后不好填補(bǔ)空間著淆。
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊／

通信方式：
客戶端通過endorser grpc訪問endorser peer
客戶端通過Broadcast訪問orderer
orderer通過Deliver訪問commuter peer

ordererManager：多鏈管理員

所有由客戶端發(fā)起創(chuàng)建的chainID，ordererManager負(fù)責(zé)管理所有有關(guān)chainID的操作拴疤。GetChain（）永部，newChain（），以及生成該chain的策略方案呐矾，Chain相應(yīng)的數(shù)據(jù)庫操作等
PS：ProposeChain的函數(shù)配置創(chuàng)建前先提交了kafka苔埋，這里思考可能是因?yàn)槠渌疃际窍冉唤okafka后直接存儲，而配置文件的提交orderer必須在本地操作蜒犯，先要生成對象组橄，這里目的性還不清晰荞膘。
／＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
ordererManager工程描述（可跳過）：
ordererManager數(shù)據(jù)結(jié)構(gòu)｛
chains map key：chainID value：chainSupport
ledger：數(shù)據(jù)庫訪問句柄
consenter：solo／kafka 操作句柄
｝
ledger consenter 好理解，chainSupport主要是生成策略方案／配置管理／過濾器管理／kafka通信／簽名及認(rèn)證／數(shù)據(jù)庫操作（policyManager／sharedconfigManager／ledgerManager）
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊／
過濾器Filter：
過濾器在orderer模塊創(chuàng)建chainID時配置的Filter玉工，過濾器包括判斷batch大小是否在規(guī)定范圍內(nèi)／policy檢測／config檢測是否通過等羽资。過濾器都在什么地方使用？solo是在生成block前進(jìn)行檢測遵班，例如如果該tx是配置屠升，則在進(jìn)行config檢測時發(fā)現(xiàn)沒有該配置，也就是說這是一條創(chuàng)建ChainID的操作狭郑，則調(diào)用ordererManager來創(chuàng)建chainID

創(chuàng)建channel流程：
由于合約要依附chainID腹暖，chainID要依附channel，創(chuàng)建channel是首先要做的愿阐。
1）客戶端發(fā)起create channel操作微服，客戶端封裝自己的Item，例如：本地證書／策略項(xiàng)缨历。個人看的版本還沒有支持外接參數(shù)導(dǎo)入（以后可能會支持自定義配置）以蕴，消息封裝簽名。
2）將消息通過broadcast發(fā)送給orderer節(jié)點(diǎn)辛孵，本地創(chuàng)建Deliver client連接到orderer
3）orderer節(jié)點(diǎn)消息解析出chainID丛肮，ordererManager檢測是否存在該chainID發(fā)現(xiàn)不存在后，檢測提交的是否是chainID配置項(xiàng)魄缚，檢測配置項(xiàng)是否滿足規(guī)則宝与，交給kafka。
4）kafka消費(fèi)者將該tx信息使用過濾器進(jìn)行過濾冶匹，過濾器發(fā)現(xiàn)這是chainID配置項(xiàng)习劫，則交給ordererManager進(jìn)行創(chuàng)建配置操作，然后將信息存儲到orderer本地塊里
5）塊存儲過程中利用通道將block信息通過Deliver發(fā)送給客戶端

 所以chainID的第一個塊一定是配置塊嚼隘，但最終配置塊不一定是第一塊诽里，當(dāng)發(fā)起config更新時第一塊不再具有意義。

join channel流程：
客戶端建立channel后飞蛹，其他peer節(jié)點(diǎn)如果對該chainID關(guān)心谤狡，則可以訂閱該channel
假設(shè)peer0對某chainID關(guān)心
1）客戶端封裝報文結(jié)構(gòu)，包括：需要訪問的chaincodeName：cscc 訪問的方法：JoinChaincode chainID配置塊內(nèi)容：first block
2）客戶端創(chuàng)建endorser client 鏈接peer0 endorser服務(wù)
3）peer0檢測消息真實(shí)性以及判斷訪問的chaincodeID是否是系統(tǒng)chaincode
4）將報文數(shù)據(jù)傳遞給cscc卧檐，cscc在本地創(chuàng)建first block保存chainID配置塊墓懂，同時與orderer建立Deliver通信。
5）peer0返回status信息
6）客戶端檢測status

這里peer0的作用是希望做commit peer霉囚，結(jié)果其還是需要endorser的功能捕仔，這種情況下沒有做到節(jié)點(diǎn)分開。
（kafka集群是否與orderer節(jié)點(diǎn)分離，目前看還是在一起的）

deploy流程：
1）客戶端封裝報文結(jié)構(gòu)榜跌，包括：需要訪問的chaincodeName：lccc 訪問的方法：deploy 簽名：xxx
2）客戶端創(chuàng)建endorser client 鏈接peer0 endorser服務(wù)
3）peer0檢測消息真實(shí)性后發(fā)送lccc闸天，執(zhí)行部署操作，返回數(shù)據(jù)
4）peer0將lccc返回數(shù)據(jù)斜做，送入escc進(jìn)行簽名，將簽名結(jié)果返回客戶端
5）客戶端驗(yàn)證返回數(shù)據(jù)真實(shí)性后湾揽，簽名通過broadcast發(fā)送給orderer瓤逼。

策略機(jī)制分類：
orderer接受消息的策略機(jī)制
orderer建立chainID的策略機(jī)制
chaincode執(zhí)行的策略機(jī)制
chaincode部署的策略機(jī)制

這幾個策略機(jī)制個人理解實(shí)現(xiàn)還不完全，目前情況是只支持Sign一中策略库物，也就是通過簽名個數(shù)來執(zhí)行策略霸旗，而且一直在改動，個人分析的版本還不支持－p 來指定chaincode策略戚揭，fabric也在持續(xù)更新诱告，下面是未來得及整理的某一個版本的策略部分，選看：

chain的創(chuàng)建 join 以及后續(xù)的應(yīng)用部署／調(diào)用／查詢民晒，都是在這個chain上精居，chain所應(yīng)用的策略很重要。

明確：這些管理都是在orderer上做的

1.configManager如何管理配置潜必？
configManager時policyManager sharedManager的匯總靴姿，負(fù)責(zé)對policyManager sharedManager的消息錄入／分析／整理。有個policyProviderMap的key value key是各種策略類型（簽名策略／配置策略／order item策略）磁滚，value是一個PolicyProvider對象佛吓，例如簽名策略的value是具有g(shù)etPolicy與驗(yàn)證是否符合policy的能力的對象。
2.policyManager如何管理垂攘？
multiledger創(chuàng)建policyManager結(jié)構(gòu)體：

policyManagerImpl｛
providers 負(fù)責(zé)newPolicy
policies 負(fù)責(zé)記錄各種策略维雇，并提供驗(yàn)證策略的方法（Evaluate）
｝

創(chuàng)建configHandlerMap的map，key：configuration_policy value：policyManagerImpl

調(diào)用policyManagerImpl的beginHandlers方法 processConfig方法 commitHandlers方法

實(shí)際程序處理的時候是對configManager整體解析config晒他，內(nèi)部調(diào)用各自configtype的beginHandlers等interface方法吱型，這里為了清晰，單獨(dú)提取policyManager仪芒。

首先檢測配置編號是否正確唁影，檢測新的策略是否滿足舊的策略限制，滿足舊的策略就更新

舉例：chain:test_id

mini——config:

Item1:
        {
            type: configItem_orderer
            key: consensusType
            value:solo
        }

Item2:
        {
            type:configItem_orderer
            key: batchSizeKey
            Value: {maxMessagecount, AbsoluteMaxBytes, PreferredMaxBytes}
        }

Item3:
        {
            type:configItem_orderer
            key:BatchTimeoutKey
            value:{timeout}
        }

Item4:
        {
            type:configItem_orderer
            key:IngressPolicyNamesKey
            value:AcceptAllPolicyKey
        }

Item5:
        {
            type:configItem_orderer
            key:EgressPolicyNamesKey
            value:AccessAllPolicyKey    
        }

Item6:
        {
            type:configItem_Policy
            key:NewConfigurationItemPolicyKey    
            value:Policy{
                                    type:Policy_signature
                                    Policy:RejectAllPolicy{
                                                                                version:0
                                                                                Identities:nil
                                                                                Policy{
                                                                                                    SignturePolicy{
                                                                                                                                    Noutof(N=1,SignPolicy{nil})
                                                                                                                            }
                                                                                            }
                                                                        }
                                }
        }
Item6代表從nil個policy條件中滿足1個掂名，則驗(yàn)證通過据沈，由于sign policy＝nil，所以一定是拒絕的饺蔑，RejectAllPolicy

Item7:
     ｛
            type：configItem_Policy
            key: AcceptAllPolicyKey
            Policy:同上锌介，剛好相反N＝0
        ｝

System－config：

Item1:
       ｛
                type：config_orderer
                key:chainCreationPolicyNamesKey
                Value:DefaultChainCreationPolicyNames
         ｝

Item2:
        {
            type:config_orderer
            key:KafkaBrokerkey
            value:一個代理的IP地址Brokers
        }

上述創(chuàng)建了一個配置，該配置是block0，應(yīng)用到chainid＝test_id上

根據(jù)配置創(chuàng)建該chainID的policyManager sharedConfigManager

policyProviderMap[Policy_signature] = NewPolicyProvider
policyProviderMap[config_policy] = policyManager
policyProviderMap[config_orderer] = sharedConfigManager

調(diào)用interface Handler BeginConfig() RollbackConfig() CommitConfig() ProposeConfig()將配置項(xiàng)解析

解析是否存在oldconfig孔祸，如果存在檢查ModificationPolicy隆敢，調(diào)用其Evaluate判斷可否update策略，這個ModificationPolicy如果未定義崔慧，則采用key:NewConfigurationItemPolicyKey拂蝎，如果注意發(fā)現(xiàn)，該配置一旦解析完成存儲惶室，下次則不可以更改這個配置温自，因?yàn)槲覀兣渲玫氖荘olicy:RejectAllPolicy

其中NewPolicy函數(shù)返回的是一個函數(shù)，evaluation函數(shù)皇钞。

分析evaluation這個函數(shù)指針：
SignaturePolicy分成from／signed by悼泌，兩部分。from負(fù)責(zé)統(tǒng)計滿足多少policy可以算通過夹界，signed by是用來計算簽名的馆里，可以指定簽名人來驗(yàn)證數(shù)據(jù)。其結(jié)構(gòu)可以遞歸

from signby
signby
signby
from signby
singby
singly

目前應(yīng)該只支持簽名策略可柿。

策略管理在何處使用鸠踪？
更新config的時候
invoke／query的時候

sharedconfig：所有itemtype＝orderer配置內(nèi)容在這

問題：這種多少人簽名通過的Policy外界如何配置

創(chuàng)建一個新的chain，以上內(nèi)容策略是如何定義的复斥？慢哈？？永票？卵贱？？侣集？键俱？？世分？

peer節(jié)點(diǎn)
Item1：
｛
type：“ConfigurationItemMSP”
key: mapKey
value: 各種證書
｝
Item2:
{
type:ConfigurationItem_peer
key:AnchorPeerConfItemKey
value:ip:port
}
Item3:
{
type:configuration_orderer
Key:creationPolicyKey
value:{
AcceptAllPolicy
Hash(allItem)
}
}

廣播到orderer后编振，交給multimanager管理調(diào)用ProposeChain（），orderer檢測了Key:creationPolicyKey是否是系統(tǒng)中已經(jīng)配置的支持的創(chuàng)建chain方式臭埋，目前只是支持AcceptAllPolicy踪央，在orderer處理創(chuàng)建channel的時候都是找sqschain來處理的。那幾個manager例如：policyManager sharedConfigManager瓢阴，這里policyManager未執(zhí)行策略