爲什麼Hyperledger Fabric 1.0中的chaincode不能被同時調用？

Question

註冊，安裝並實例化chaincode結構/ example/chaincode/go/chaincode_example02後，我運行以下步驟。

peer chaincode instantiate --orderer orderer0:7050 --tls true --path example02 --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/orderer/localMspConfig/cacerts/ordererOrg0.pem --chainID mychannel --name example02cc --version 1.0 --ctor '{"Args":["init","A","1000","B","2000"]}' 

peer chaincode query --chainID mychannel --name example02cc --ctor '{"Args":["query","A"]}' 

peer chaincode query --chainID mychannel --name example02cc --ctor '{"Args":["query","B"]}' 

到目前爲止，我確認A等於1000和B等於2000之後，其結果將是可變的，如果我調用下面的步驟用不同的定時。

peer chaincode invoke --orderer orderer0:7050 --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/orderer/localMspConfig/cacerts/ordererOrg0.pem --chainID mychannel --name example02cc --ctor '{"Args":["invoke","A","B","1"]}' 

具體來說，A將等於998，如果我以10秒的間隔運行上一步兩次，B等於2002。 A將等於990，而B將等於2010，如果我在每步之間停頓10秒後執行前一步十次。然而，沒有任何停頓，如果我執行前面的步驟兩次，A將等於999並且B將等於2001。如果我在每一步之間不停頓地執行前一步十次，A將等於999，B等於2001。

我用不同的參數測試過幾次。而且，我測試了其他的連鎖代碼。似乎鏈代碼只接受第一個調用請求，並丟棄後續的調用請求。所以，問題是：

1. 這是防止雙重支出的機制嗎？或者只是一個弱點？
2. 如何解決限制事務處理速度的問題。
3. 我認爲chaincode應該支持併發調用。 chaincode能否支持實際的併發調用？
4. 一個鏈碼可以在單個塊週期內調用多個請求嗎？

Answer 1

鏈代碼需要做認可，然後在下一次調用之前將其提交分類賬狀態。

當您撥打peer chaincode invoke ...時，背書後的面料反應很快完成。但是提交仍然需要一些時間。如果您在第一次調用後直接運行第二次調用，則第二次調用將被正確認可，但不會發生任何提交。

因此，對於您的問題：

1. 您可以嘗試通過Java的SDK或節點SDK調用chaincode。以javasdk爲例，進度首先將transactionProposalRequest發送給chaincode，這是結構中的認可過程。代言完成後，您的配額政策已正確通過。該交易是由sdk-client發送給fabirc，該API將返回一個CompletableFuture<BlockEvent.TransactionEvent>，這與js中的Promise類似。當事務完成時，會觸發CompletableFuture.thenApply（）。例如，您可以檢查src/test/java/org.hyperledger.fabric.sdkintergration/End2endIT.java。

2. 您可以在鏈碼中寫一個批次。這可以同時支持多個調用和查詢，它在一定程度上解決了您的問題。批處理設計如下，在你的cc中新建一個m map[string]string和toDelete []string，當調用把你的鍵/ val對放入m，並且當查詢首先從m獲得鍵/ val時，如果沒有找到，從存根查詢， ，從m中刪除，並將密鑰置於toDelete，完成所有要求後，立即提交m和toDelete中的所有數據。我在我的項目中嘗試了這種機制，它工作的很好。

3. blockchain是專爲高併發而設計的。它專爲保密性，可擴展性和安全性而設計。

4. 看到2

Answer 2

從視圖織物的點這實際上是正常行爲 - 雖然可能看起來有點違反直覺第一。

您看到的情況從documented transaction flow（+知道有批量超時的訂購者執行了一些批處理）邏輯地跟隨。讓我們假設在模擬（認可）過程中，變量A被讀取，然後標記爲鏈碼模擬重新設置。讀取什麼值以及您希望變量設置爲建議交易的一部分（+無論代言人是否接受交易+密碼）。然後我們通過提交訂單+分銷渠道向同行+渠道同行查詢（其中包括）原始「讀取價值假設」是否仍然成立。 （參見5：對參考同位體的驗證。）如果A的值自「模擬以來」發生了變化，則交易將無效。

時間對此的影響如下。如果有足夠的「迴旋餘地」兩所調用之間，會發生以下情況：

• CALL1 - 與原來的值
• CALL1提議得到認可，發給訂購者，被批量
• 一段時間後創建的提案，同行得到有序批准從訂貨TX，檢查它，發現它精細，A的值被修改（致力於萊傑）的要求
• CALL2 - 用新的值已建立的提案閱讀等

至關重要的是，如果您在之前創建並提交第二個建議，那麼會發生什麼情況，第一個建議的效果會落入分類帳。 （因此，沒有「等待足夠的」。）

• CALL2模擬仍把原來的值，代言是基於
• 這個計算被捆綁到事務的「讀值」屬性
• 通過它到達用於提交所述信道對等體時，A的值已經被通過CALL1改性
• 因此，該交易將是無效的，並且對分類帳沒有影響

這種效果不完全新的，我們被織物0.6用類似的東西咬了。幸運的是，有一些「乾淨」的方式，我建議閱讀區塊鏈上下文中的「標記化」。在example02的上下文中，你可以讓所有的「單位」都有一個GUID並追蹤所有權向量;或者你可以選擇全UTXO比特幣風格。選項b）可以將Tx請求本身寫入分類賬（Tx1：+20，Tx2：-40，Tx3：+65，...），並將基於「當前賬戶狀態」的指令以Ledger存儲的Tx日誌，雖然這可能會有點混亂。

並且請注意，只要Tx請求的「工作集」沒有太多重疊，就可以實現巨大（無痛苦）的併發。對於很多領域來說，這是可能的;例如對於一個加密貨幣來說，它並不是像熱土豆一樣被傳遞的貨幣單位，而是一大批貨幣單位有許多交易，但在整個貨幣單位之間均勻分佈。

在您的具體問題：

1. 看到遠高於
2. 見上
3. 取決於你所說的併發調用一下兩個建議，但在織物的心臟1.0體系結構是一個在所有批准的請求上設置完整排序，並且在驗證和分類帳更新期間執行此排序。大量的同行請求同時處理 - 當然; 「折返鏈代碼」 - 不 - 不 - 不。
4. Chaincodes不「調用請求」。如果你的意思是一個單一的chaincode是否可以在一個block中有多個事務：當然，例如使用「sell_cars」chaincode銷售100輛不同的汽車。