您是否需要非常高吞吐量的Corda網(wǎng)絡(luò)？ 網(wǎng)絡(luò)的吞吐量是否穩(wěn)定？ 您是否已經(jīng)從其他領(lǐng)域擠出了所有可能的表現(xiàn)？ 如果您對這些問題的回答是“是”，那么我可能會為您提供一些有用的信息。 我列出了這些問題，以減少您過早優(yōu)化Corda網(wǎng)絡(luò)/應(yīng)用程序的機(jī)會。 如果它是處理請求/事務(wù)中最慢的部分之一，則切換到使用多個公證人只會對性能產(chǎn)生顯著影響。 在考慮使用多個公證人之前，很可能需要改進(jìn)其他方面。

在我繼續(xù)之前。 我真的需要這么說。 在本文中，我并不是在談?wù)撌褂霉C集群，該公證集群由相互溝通以就是否使用了州達(dá)成共識的公證組成。 我說的是擁有多個公證人，每個公證人都有自己的身份，這些公證人僅與向其發(fā)送交易以進(jìn)行驗(yàn)證的節(jié)點(diǎn)進(jìn)行交互。 這種區(qū)別必須加以區(qū)分，并且應(yīng)該消除對我將在本文中準(zhǔn)確描述的任何混淆。

在撰寫本文時，Corda的當(dāng)前版本為：

• 開源3.3
• 企業(yè)3.2

我為什么要這樣做？

好吧 讓我們真正深入探討為什么要使用多個公證人。 圖表最能做到這一點(diǎn)，所以讓我們使用一個：

具有一個公證人的網(wǎng)絡(luò)的簡單視圖

這種情況看起來不太好。 但是，實(shí)際上可能并不那么糟糕。 如果網(wǎng)絡(luò)的吞吐量不是很高，則此體系結(jié)構(gòu)應(yīng)該能夠處理通過公證人的事務(wù)。

如引言中所述。 當(dāng)發(fā)送到公證人的交易率變得很高時，這成為一個問題。 一旦達(dá)到這一點(diǎn)，公證人將開始落后。 因?yàn)樗荒茏銐蚩斓仳?yàn)證事務(wù)中的狀態(tài)。 如果性能對網(wǎng)絡(luò)很重要，那么這是檢查的好地方。

從代碼角度來看，這是您可能已經(jīng)在編寫CorDapps的標(biāo)準(zhǔn)格式。 您可以根據(jù)特定條件挑選公證人，然后在其中發(fā)送交易。 您所處理的整個網(wǎng)絡(luò)中甚至可能只有一個公證人。 例如，在編寫類似于以下代碼的代碼之前，在我編寫的所有代碼示例中，它們僅依賴于網(wǎng)絡(luò)中的單個公證人，每次都盲目地使用那個公證人。

private fun notary(): Party = serviceHub.networkMapCache.notaryIdentities.first()

切換到多個公證人

從依賴一個公證人的網(wǎng)絡(luò)過渡到一個由許多公證人組成的設(shè)計(jì)，從根本上講，需要兩件事：

• 網(wǎng)絡(luò)中有多個公證人。
• 一種選擇向哪個公證人發(fā)送交易的算法。

此外，如果使用狀態(tài)，則將來的交易會參考為交易選擇的公證人。 如果最終導(dǎo)致消耗了來自不同公證人的輸入狀態(tài)的情況，則必須執(zhí)行公證人變更事務(wù)。 稍后我將討論這個主題。

下面是如何更改先前的設(shè)計(jì)以使用一些公證人的方法：

具有多個公證人的網(wǎng)絡(luò)的簡化視圖

關(guān)于此圖的最好之處在于，它說明了向網(wǎng)絡(luò)添加另一個公證人并在其中重新分配負(fù)載是多么簡單。 沒有什么可以阻止我們向網(wǎng)絡(luò)中添加越來越多的公證人。 但是，在某些情況下添加更多內(nèi)容不會導(dǎo)致性能提高。 這一直回到我之前提到的內(nèi)容。 添加更多的公證人只會在公證人本身達(dá)到飽和時增加吞吐量。

為發(fā)行交易選擇公證人

以下是選擇使用哪種公證人的可能算法：

private fun transaction(): TransactionBuilder =TransactionBuilder(notary()).apply {addOutputState(message, MessageContract.CONTRACT_ID)addCommand(Send(), message.participants.map(Party::owningKey))}private fun notary(): Party {val index = message.type.hashCode() % serviceHub.networkMapCache.notaryIdentities.sizereturn serviceHub.networkMapCache.notaryIdentities.single { it.name.organisation == "Notary-$index" } }

在此示例中，事務(wù)根據(jù)輸入狀態(tài)的屬性之一的hashCode和網(wǎng)絡(luò)中的公證人數(shù)來選擇要使用的公證人。

選擇公證人的方式可以根據(jù)需要簡單或復(fù)雜。 這將取決于要求，例如，僅一部分公證人的提議交易受信任，或者網(wǎng)絡(luò)變化中對公證人的彈性。

從同一公證人消費(fèi)狀態(tài)時選擇公證人

這是很好而且很簡單的…如果所有輸入狀態(tài)都引用同一個公證人。 下面是它的外觀（此示例僅使用一個輸入…，因?yàn)槲覒杏诰帉懥硪粋€版本）：

private fun transaction(response: MessageState): TransactionBuilder =TransactionBuilder(notary()).apply {addInputState(message)addOutputState(response, MessageContract.CONTRACT_ID)addCommand(Reply(), response.participants.map(Party::owningKey))}private fun notary(): Party = message.state.notary

如您所見，所有事務(wù)要做的就是檢索與輸入狀態(tài)相關(guān)的公證人，并將其用于自身。 可以提取此信息，因?yàn)閙essage是StateAndRef ，訪問其state屬性將返回TransactionState 。 遵循這種格式。 創(chuàng)建消耗狀態(tài)并產(chǎn)生大量輸出的新事務(wù)非常簡單。 此格式對于多個輸入狀態(tài)也有效。 當(dāng)且僅當(dāng)它們都引用同一個公證人。

因此……討論所有帶有不同公證人的輸入狀態(tài)。 我可能應(yīng)該進(jìn)一步討論。

消費(fèi)來自不同公證人的狀態(tài)時選擇公證人

在這里我們必須要小心，否則我們將看到類似以下的錯誤：

java.lang.IllegalArgumentException: Input state requires notary "O=Notary-1, L=London, C=GB" which does not match the transaction notary "O=Notary-0, L=London, C=GB".

該錯誤表明輸入狀態(tài)與包含它的事務(wù)沒有相同的公證人。

要解決此錯誤，我們需要使用公證更改交易。 根據(jù)文檔：

“用于更改州公證人的流程。 這是必需的，因?yàn)槭聞?wù)的所有輸入狀態(tài)必須指向同一公證人。”

我想把它放在那里，以防萬一您以為我是個更厲害的人！

執(zhí)行公證變更交易的代碼如下所示：

@Suspendable private fun notaryChange(message: StateAndRef<MessageState>,notary: Party ): StateAndRef<MessageState> =if (message.state.notary != notary) {subFlow(NotaryChangeFlow(message,notary))} else {message}

我相信您可以弄清楚自己的狀況，但是要使自己變得更加聰明……我將告訴您。 message表示輸入狀態(tài)， notary是新交易將使用的公證人。 如果公證人相同，則可以返回狀態(tài)，因?yàn)闊o需對其進(jìn)行任何操作。 如果確實(shí)不同，則調(diào)用NotaryChangeFlow ，它接受傳遞給原始函數(shù)的兩個參數(shù)。 這將返回一個新的StateAndRef ，然后從函數(shù)中返回它。

然后可以將從此函數(shù)返回的StateAndRef放入事務(wù)中。

如果您不確定傳遞到事務(wù)中的狀態(tài)是否來自同一公證人，那么建議您堅(jiān)持使用本節(jié)中的代碼。 選擇事務(wù)將使用的公證人（無論是特定的公證人還是從輸入狀態(tài)中獲取的公證人），然后對任何需要它的公證人進(jìn)行變更。 例如，我認(rèn)為類似于下面的代碼將提供一個通用且健壯的解決方案：

@Suspendable private fun transaction(): TransactionBuilder {val messages = getMessageStates()val notary = notary()return TransactionBuilder(notary).apply {messages.forEach {addInputState(notaryChange(it, notary))}addCommand(Delete(),(messages.flatMap { it.state.data.participants }.toSet() + ourIdentity).map(Party::owningKey))} }@Suspendable private fun notaryChange(message: StateAndRef<MessageState>,notary: Party ): StateAndRef<MessageState> =if (message.state.notary != notary) {subFlow(NotaryChangeFlow(message,notary))} else {message}// however you want to choose your specific Notary private fun notary(): Party =serviceHub.networkMapCache.notaryIdentities.single { it.name.organisation == "Notary-1" }

在這里，為交易選擇了一個特定的公證人，如果需要，每個輸入的公證人都將更改為所選公證人，并且簽名者包括消費(fèi)狀態(tài)的所有參與者。 這可能不適合您自己的用例。 很好。 但是，這在為不斷變化的公證人服務(wù)時（主要是為了提高性能）應(yīng)該是一個很好的起點(diǎn)。

稍稍更改此解決方案，我們可以改為根據(jù)輸入狀態(tài)參考的“公證人”來選擇“公證人”。 由于只有notary功能確實(shí)需要更改，因此我從示例中排除了其余代碼。

private fun notary(messages: List<StateAndRef<MessageState>>): Party =messages.map { it.state.notary }.groupingBy { it }.eachCount().maxBy { (_, size) -> size }?.key ?: throw IllegalStateException("No Notary found")

該功能選擇的公證人是根據(jù)輸入狀態(tài)共享的最常見的公證人來決定的。 這樣一來，所需的公證變更交易就更少了，因?yàn)榻^大多數(shù)輸入已經(jīng)引用了所選的公證。 如果您不知道輸入?yún)⒖嫉氖悄膫€公證人，這應(yīng)該提供最佳性能。

結(jié)論

在Corda網(wǎng)絡(luò)中實(shí)現(xiàn)高性能取決于消除系統(tǒng)中的瓶頸和其他常規(guī)性能調(diào)整。 公證人就是這樣的瓶頸之一。 在通過公證人的吞吐量非常高的情況下，網(wǎng)絡(luò)的性能將開始達(dá)到平穩(wěn)狀態(tài)。 公證人不能以傳入的速率足夠快地處理請求。移動使用共享請求負(fù)載的多個公證人將提高網(wǎng)絡(luò)的性能。 這在確定使用哪個公證人方面帶來了額外的復(fù)雜性，并且可能需要公證人變更事務(wù)。 但是，如果您的網(wǎng)絡(luò)確實(shí)需要實(shí)現(xiàn)高吞吐量。 這將是一個值得研究的領(lǐng)域。

我將在這里發(fā)表最后的評論。 隨著公證人內(nèi)部性能的提高，對這種架構(gòu)的需求將減少。 甚至有一個公證人能夠完全處理大量傳入請求的情況。 隨著Corda不斷提高整體性能，這是一個值得關(guān)注的領(lǐng)域。

這篇文章中使用的代碼可以在我的GitHub上找到 。

翻譯自: https://www.javacodegeeks.com/2018/11/increasing-network-multiple-notaries.html

總結(jié)

以上是生活随笔為你收集整理的多个公证员提高网络吞吐量的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。