pda ech urn common join rate instant ont 重要

一 checkConfig Before 1.1 private static final TestConfig testConfig = TestConfig.getConfig(); 這裏加載一個配置文件(test路徑/src/test/java/org/hyperledger/fabric/sdk/testutils.properties，文件不存在就加載代碼中寫死的默認配置)， 配置文件需要設置peer，orderer，ca，eventhub的地址，組織mspid，組織域名。解析配置文件，將信息加載到sampleOrgs中，如果與CA通信 啟用了tls，需要在sampleOrg中(字段caProperties)保存與CA通信的tls證書位置(src/test/fixture/sdkintegration/e2e-2Orgs/$(FAB_CONFIG_GEN_VERS)/crypto-config/peerOrganizations/$(DNAME)/ca/ca.$(DNAME)-cert.pem)，用於之後為組織創建CA客戶端， 當前樣例中與CA通信默認沒有啟用TLS。 ****註意sampleOrgs是一個重要的變量，保存了所有的配置信息，並且之後加入組織的成員信息也保存到sampleOrgs中，sampleOrgs集合中一 個典型組織結構如下： 1.2 為每個組織設置CA客戶端 從testConfig中獲取到sampleOrgs到testSampleOrgs中，遍歷每個組織並設置每個組織創建CA客戶端，用戶之後訪問CA服務器。 二 setup Test setup為測試主要流程實現，包括創建user，admin，peerAdmin，為每個用戶獲取CA證書，創建channel，安裝鏈碼，實例化鏈碼，設置事件，進行交易 幾個部分。 2.1 為每個組織創建用戶，也保存在sampleOrgs中 組織的用戶信息與常規配置不同，在程序運行區間會有動態添加用戶的需求，並且程序在運行時，需要保存用戶的信息。樣例中為了簡單，將用戶實例對象序列化到文件中，所以這裏第一步先去文件中恢復用戶信息到sampleOrg中。 反序列化本地緩存的用戶對象(/tmp/HFCSampletest)到sampleStore中 sampleStore = new SampleStore(sampleStoreFile); enrollUsersSetup(sampleStore); //This enrolls users with fabric ca and setups sample store to get users later. 1） 先獲取組織的CA客戶端實例； 2） 設置CA實例的加密套件，用於加解密和驗證； 3） 創建用戶，並通過ca.enroll(user, secret) 向CA服務端申請證書。 keypair = cryptoSuite.keyGen(); // generate ECDSA keys: signing and encryption keys，非對稱加密生成私鑰 //url：ca地址； body：通過kvpair和user生成； 加上user和secret去申請證書，最後從response中解析出證書 String responseBody = httpPost(url + HFCA_ENROLL, body, new UsernamePasswordCredentials(user, secret)); 這裏需要實例化三種用戶。 首先是admin，即登陸ca的管理員用戶，默認賬號密碼"admin", "adminpw"。這個用戶在ca服務器啟動時就有，先嘗試從用戶存儲文件中獲取，沒有的話直接從CA中獲取keypair和證書即可。所有的用戶抽象為sampleUser的結構，如下圖，keypaire和證書保存在enrollment中。另外所有的用戶都保存到sampleOrg中。

然後是普通用戶，普通用戶可以有多個，先嘗試從序列化後的用戶存儲文件中獲取，沒有的話需要先從CA註冊，再創建keypair，申請證書。最後保存到sampleOrg字段usermap中

sampleOrg sampleorg： 組織集合，包括orderer的地址(與orderer通信時使用的tls證書是啟動CA後去申請的)，peer地址，user，admin，peerAdmin Orderers集合： tls證書和orderer地址 HFCCient client： cryptoSuite加密解密組件， channel(需要通過tx配置，組織envelope，用peerAdmin簽名後，用orderer對象原子廣播生成channel)， userContext(對最後要發送的envelpe做簽名，如在創建channel時就是用peerAdmin對象的密鑰去做簽名，那就設置為peerAdmin, 如果是發送一筆普通交易，則可以用普通user做簽名) channel fooChannel： runFabricTest 1 創建HFClient，一個client配一個channel實例 設置client的加密組件，用於加密，解密，驗證。 2 創建channel 獲取org1的實例sampleOrg 創建channel實例，傳入client和sampleOrg Channel fooChannel = constructChannel(FOO_CHANNEL_NAME, client, sampleOrg); 1) 設置userContext client.setUserContext(sampleOrg.getPeerAdmin()); 2) 將sampleOrg下所有的orderer地址，實例化orderer對象，做成orderers集合

orderers.add(client.newOrderer(orderName, sampleOrg.getOrdererLocation(orderName), ordererProperties)); 3) 選擇集合中的第一個orderer去創建channel 先讀取[channel name].tx配置文件到ChannelConfiguration channelConfiguration對象中 然後創建channel，依據channel創建策略去創建channel，這裏只需要peerAdmin的簽名，如果策略需要更多，則需要指定更多 public Channel newChannel(String name, Orderer orderer, ChannelConfiguration channelConfiguration, byte[]... channelConfigurationSignatures) Channel newChannel = client.newChannel(name, anOrderer, channelConfiguration, client.getChannelConfigurationSignature(channelConfiguration, sampleOrg.getPeerAdmin())); newChannnel實現流程，[channelName].tx實際就是一個envelope結構體，先發序列化出來

反序列化payload

反序列化payload的header中的channelheader

校驗下header的值，common.java中定義了type的值：public enum HeaderType，這裏我們tx中應該為CONFIG_UPDATE(2)，表示一筆更新channel配置的交易

接著反序列化payload的data域，configUpdateEnv

獲取其中的configUpdate字段內容，發送 　　　　從中會重新構建一個envelope，做簽名後，再用orderer對象發送(發送給orderer對象中保存的地址，使用其tls證書) private void sendUpdateChannel(byte[] configupdate, byte[][] signers, Orderer orderer) 這裏就要創建channel了 1） 先構建一個交易上下文 TransactionContext transactionContext = getTransactionContext(); 從中調用new TransactionContext(this, userContext, client.getCryptoSuite());返回交易上下文對象

　　　　 cryptoPrimititives: client.getCrytoSuite() 加密解密驗證套件, userContext(即2-1中定義，主要是使用其公私鑰來給envelope做簽名)，channel當前的channel對象，identity身份認證信息

2）構建上下文對象後，要構建envelope，會使用上下文對象來作簽名。重要：上下文對象中包含client的usercontext，這裏要區別開創建channel傳進來的signer，signer是直接把序列化的證書byte存到了envelope中的payload中的data域(data域為一個configupdateenv結構，包含了signatures字段)。而上下文對象中的client的usercontext則是用來對envelope各個部分做簽名(包括payload整體做簽名(放到envelope的開始)，payload的header，payload的data) 猜測：signer可以自己設置任意用戶，任意多個簽名byte，即指定channel設置的一個策略？？？？？？？

　　　　 2-1）創建configupdateenv，同上面的configUpdateEnvelope結構，這裏重新構建信封結構，添加簽名。 這裏簽名只有peerAdmin的簽名。configupdateEnv將作為envelope payload結構中data域

2-2）然後設置envelope payload結構的header域，header域包括channel header(包含type，是普通交易還是channel配置等等和交易txid)，signatureheader(簽名頭） final ByteString sigHeaderByteString = getSignatureHeaderAsByteString(transactionContext); //signatureheader由交易上下文生成 final ChannelHeader payloadChannelHeader = ProtoUtils.createChannelHeader(HeaderType.CONFIG_UPDATE, transactionContext.getTxID(), name, transactionContext.getEpoch(), transactionContext.getFabricTimestamp(), null, null); //channel header final Header payloadHeader = Header.newBuilder().setChannelHeader(payloadChannelHeader.toByteString()) .setSignatureHeader(sigHeaderByteString).build(); //設置envelope payload的header 2-3）設置envelope payload的data域 final ByteString payloadByteString = Payload.newBuilder() .setHeader(payloadHeader) .setData(configUpdateEnvBuilder.build().toByteString()) .build().toByteString(); 2-4）設置整個envelope ByteString payloadSignature = transactionContext.signByteStrings(payloadByteString); Envelope payloadEnv = Envelope.newBuilder() .setSignature(payloadSignature) .setPayload(payloadByteString).build(); 2-5）根據orderer中設置的orderer地址和tls，使用原子廣播發送信封 BroadcastResponse trxResult = orderer.sendTransaction(payloadEnv); 至此channel創建完畢，將創建的channel加入到去安居channels變量中 後續參見End2endIT.java 844 // Set peer to not be all roles but eventing. 1） newChannel.joinPeer(peer, createPeerOptions().setPeerRoles(PeerRole.NO_EVENT_SOURCE)); 添加所有的peer到channel中，peer對象的屬性在sampleOrg中存儲 2） for (Orderer orderer : orderers) { //add remaining orderers if any. newChannel.addOrderer(orderer); } 添加所有的orderer到channel中 3） 設置eventhub，其實是設置與eventhub服務端的連接，後面去交易的時候才去設置監聽的事件 3 回到End2endIT.java 206行，在創建channel後安裝實例化鏈碼 sampleStore.saveChannel(fooChannel); 在sampleStore中本地序列化存儲創建的channel對象 然後runChannel runChannel(client, fooChannel, true, sampleOrg, 0); 3-1） 註冊了chaincode事件 3-1） 第一步，先安裝鏈碼，所有的peer都要安裝，安裝鏈碼只需要封裝proposal發送給peers就可以了 Collection<Peer> peers = channel.getPeers(); numInstallProposal = numInstallProposal + peers.size(); responses = client.sendInstallProposal(installProposalRequest, peers); 3-2） 實例化鏈碼 responses = channel.sendInstantiationProposal(instantiateProposalRequest, channel.getPeers()); //封裝proposal並發送給peer 3-3） 發送交易，實例化鏈碼也當作一筆交易處理，需要進行orderer排序，commiter驗證提交 channel.sendTransaction(successful, createTransactionOptions() //Basically the default options but shows it‘s usage. .userContext(client.getUserContext()) //could be a different user context. this is the default. .shuffleOrders(false) // don‘t shuffle any orderers the default is true. .orderers(channel.getOrderers()) // specify the orderers we want to try this transaction. Fails once all Orderers are tried. 　　　　　 .nOfEvents(nOfEvents) // The events to signal the completion of the interest in the transaction ) successful是所有交易提案的結果集合 在sendTransaction中，封裝一個envelope，不同於channel創建中的envelope，這個envelope中payload封裝為交易提案response，response為 多個背書節點的響應，這裏拿出來一個，ed是所有背書的集合(讀寫集簽名)，proposalResponsePayload為提案結果payload，共同作為payload 　　　 for (ProposalResponse sdkProposalResponse : proposalResponses) { ed.add(sdkProposalResponse.getProposalResponse().getEndorsement()); if (proposal == null) { proposal = sdkProposalResponse.getProposal(); proposalTransactionID = sdkProposalResponse.getTransactionID(); proposalResponsePayload = sdkProposalResponse.getProposalResponse().getPayload(); } } Payload transactionPayload = transactionBuilder .chaincodeProposal(proposal) .endorsements(ed) .proposalResponsePayload(proposalResponsePayload).build(); Envelope transactionEnvelope = createTransactionEnvelope(transactionPayload, userContext) resp = orderer.sendTransaction(transactionEnvelope); 3118行，發送信封，這裏會逐個orderer依次發送，哪個返回success，就break。 　　4 執行chaincode 　　client.setUserContext(sampleOrg.getUser(TESTUSER_1_NAME)); //重要：執行交易使用普通用戶對envelope做簽名即可 　　/////////////// 　　/// Send transaction proposal to all peers TransactionProposalRequest transactionProposalRequest = client.newTransactionProposalRequest(); transactionProposalRequest.setChaincodeID(chaincodeID); transactionProposalRequest.setChaincodeLanguage(CHAIN_CODE_LANG); //transactionProposalRequest.setFcn("invoke"); transactionProposalRequest.setFcn("move"); transactionProposalRequest.setProposalWaitTime(testConfig.getProposalWaitTime()); transactionProposalRequest.setArgs("a", "b", "100") 掠過交易提案過程，這裏獲取到所有提案結果successful後，設置並發送envelope給orderer 634 out("Sending chaincode transaction(move a,b,100) to orderer."); eturn channel.sendTransaction(successful).get(testConfig.getTransactionWaitTime(), TimeUnit.SECONDS); 執行到sendTransaction channel.java 3079 return sendTransaction(proposalResponses, createTransactionOptions().orderers(orderers).userContext(userContext)); 然後同實例化鏈碼一樣，3179行，封裝envelope並發送給orderer public CompletableFuture<TransactionEvent> sendTransaction(Collection<ProposalResponse> proposalResponses,TransactionOptions transactionOptions)

hyperledger fabric超級賬本java sdk樣例e2e代碼流程分析