當(dāng)前位置：首頁(yè) > 编程资源 > 编程问答 >内容正文

编程问答

公证服务信息_使用多个公证员提高网络吞吐量

發(fā)布時(shí)間：2023/12/3 编程问答 28 豆豆

生活随笔收集整理的這篇文章主要介紹了公证服务信息_使用多个公证员提高网络吞吐量小編覺(jué)得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

公證服務(wù)信息

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

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

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

開(kāi)源3.3
企業(yè)3.2

我為什么要這樣做？

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

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

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

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

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

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

切換到多個(gè)公證人

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

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

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

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

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

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

為發(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ù)來(lái)選擇要使用的公證人。

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

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

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

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

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

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

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

在這里我們必須要小心，否則我們將看到類(lèi)似以下錯(cuò)誤：

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".

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

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

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

我想把它放在那里，以防萬(wàn)一你以為我是個(gè)騙子！

執(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(wú)需對(duì)其進(jìn)行任何操作。如果它們確實(shí)不同，則調(diào)用NotaryChangeFlow ，它接受傳遞給原始函數(shù)的兩個(gè)參數(shù)。這將返回一個(gè)新的StateAndRef ，然后從函數(shù)中返回它。

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

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

@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" }

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

稍稍更改此解決方案，我們可以改為根據(jù)輸入狀態(tài)參考的“公證人”來(lá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)共享的最常見(jiàn)的公證人來(lái)決定的。這樣一來(lái)，所需的公證變更交易就更少了，因?yàn)榇蠖鄶?shù)輸入已經(jīng)引用了所選公證。如果您不知道輸入引用的是哪個(gè)公證人，這應(yīng)該提供最佳性能。

結(jié)論

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

我將在這里發(fā)表最后的評(píng)論。隨著公證人內(nèi)部性能的提高，對(duì)這種體系結(jié)構(gòu)的需求將減少。甚至可能達(dá)到這樣一個(gè)程度，即一個(gè)公證人能夠完全處理大量傳入請(qǐng)求。隨著Corda不斷提高其整體性能，這是一個(gè)值得關(guān)注的領(lǐng)域。

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

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