最近我與一位高級軟件工程師和一個區(qū)塊鏈架構(gòu)師就Insolar進行了一次對話，區(qū)塊鏈架構(gòu)師是世界上最大的軟件供應(yīng)商之一。這位工程師對前幾代的分散化和區(qū)塊鏈平臺提出了一些好觀點。我們的對話讓我解釋了Insolar區(qū)塊鏈平臺的一些基本架構(gòu)方面，并闡明了如何在一個系統(tǒng)中實現(xiàn)可伸縮性、透明性和許可性。讓我們來看看工程師經(jīng)常問我的關(guān)于Insolar體系結(jié)構(gòu)的一些主要主題。

處理和持久性

Insolar網(wǎng)絡(luò)的基本大規(guī)模單元是Globula，可能包含多達1，000個屬于不同參與者的節(jié)點。目前，我們開發(fā)主網(wǎng)和EnterpriseNet，其中的節(jié)點將基于云，由Insolar或其合作伙伴提供。將來，節(jié)點可以放置在室內(nèi)或云中 - 例如， Insolar主網(wǎng)/EnterpriseNet或AWS等。

共識

Globula生活在周期中 - 就是脈沖。脈沖同步網(wǎng)絡(luò)，是必須處理對象以執(zhí)行或驗證的設(shè)定時間。他們的持續(xù)時間可以調(diào)整，在寫作時大約10秒。在每個脈沖，基于BFT的共識算法確保網(wǎng)絡(luò)狀態(tài)是一致的：新節(jié)點插入網(wǎng)絡(luò)上的共享視圖，同時刪除故障/可疑節(jié)點等。這確保所有節(jié)點的行為一致， 達成共識的規(guī)則。在每次達成共識之后，Globula中的所有“好”節(jié)點都被分配為不同對象（鏈）執(zhí)行不同的角色。由于完成了共識，所有節(jié)點在網(wǎng)絡(luò)配置上具有相似的視圖，因此這種分配是精確且無爭議的。

節(jié)點角色

Insolar有Virtual Executors處理事務(wù)，Virtual Validators，Light Material Executors和Light Material Validators持久處理和驗證存儲操作的結(jié)果。共識協(xié)議確保沒有Executor可以驗證自己的輸出，并且沒有節(jié)點可以在下一個脈沖期間可靠地預(yù)測其角色。

OmniScaling

每個特定事務(wù)只能有一個Executor，但許多Validator。如果事務(wù)花費的時間超過一個脈沖，則Executor節(jié)點將獲得繼續(xù)執(zhí)行的權(quán)限（來自下一個脈沖上的可執(zhí)行執(zhí)行程序）。Validator的數(shù)量可以根據(jù)交易風(fēng)險的感知價值進行調(diào)整。同樣，這是OmniScaling的核心：在添加更多節(jié)點時允許容量的潛在線性增加。Insolar計劃通過匯集Executors來進一步擴展此功能。

冷熱儲存

持久層由Light和Heavy Material節(jié)點組成。Light節(jié)點負責(zé)構(gòu)建塊并將它們連接成鏈，以及形成物理存儲單元（在Insolar中稱為Jet Drops）。Light Material節(jié)點在預(yù)定義（可配置）的脈沖數(shù)量上有效地充當(dāng)緩存，而Heavy Material節(jié)點提供冷的長期存儲。這允許避免為經(jīng)常訪問的對象進入冷存儲器。只有Material節(jié)點才能訪問存儲的數(shù)據(jù) - 虛擬節(jié)點無法直接訪問它。

接入速率

有人會說，為了處理一個物體，這必須最終從冷藏庫中提起，這是昂貴的。但是在Insolar區(qū)塊鏈平臺上，它只在極少數(shù)情況下完成，并且只能從Heavy到Light Material節(jié)點完成。在此之后，該物體被緩存。仍然需要在節(jié)點之間傳遞數(shù)據(jù)，但是：僅針對直接參與所述數(shù)據(jù)對象的處理的節(jié)點（即，在單個Globula的情況下，并非所有網(wǎng)絡(luò)節(jié)點）。相反，在像以太坊這樣的普通式區(qū)塊鏈平臺中，完整的網(wǎng)絡(luò)處理和交換數(shù)據(jù); 在Insolar上，這只發(fā)生在幾個（可配置的數(shù)量）節(jié)點上。

公共/私人和許可/無權(quán)

域作為治理工具

域是一種特殊的智能合約，定義了一個框架（策略和設(shè)置），在其中執(zhí)行其他智能合約。該框架可能包含大量內(nèi)容：業(yè)務(wù)領(lǐng)域（例如貿(mào)易融資）; 訪問規(guī)則（許可或許可）; 可以執(zhí)行智能合約并存儲其結(jié)果的位置（例如地理位置）; 驗證的共識規(guī)則（例如驗證節(jié)點和/或算法的數(shù)量與風(fēng)險值的對比）; 等等。

Insolar網(wǎng)絡(luò)

我們相信，企業(yè)的任何實際設(shè)置都將獲得許可，因為企業(yè)需要保護有價值的數(shù)據(jù)。但是，Insolar正在開發(fā)主網(wǎng)，需要加入程序，但一旦參與者加入，所有參與者都可以使用所有數(shù)據(jù)。為了確保網(wǎng)絡(luò)的穩(wěn)定性和用戶的安全性，主網(wǎng)的初始設(shè)置將利用Insolar和Insolar合作伙伴的節(jié)點。在后期階段，任何節(jié)點都可以通過放樣過程公開加入。之后，我們將啟動EnterpriseNet，其中將針對不同的業(yè)務(wù)案例和適當(dāng)?shù)臄?shù)據(jù)訪問策略實施域。

互通性

Insolar開發(fā)路線圖的后期是不同的Insolar網(wǎng)絡(luò)（云）之間的集成，以及與其他區(qū)塊鏈和分布式分類賬（DLT）的連接。一切都是Insolar區(qū)塊鏈平臺內(nèi)的契約，這意味著內(nèi)部和外部都有技術(shù)上類似的通信 - 通過遠程調(diào)用和API調(diào)用。平臺代碼在Github上可用，我們計劃提供OEM包，因此大家都可以在完全私有（或相反，公共）設(shè)置中擴展功能。

關(guān)于Insolar區(qū)塊鏈平臺的花絮

· Insolar沒有“挖掘”職能

· 節(jié)點必須在任何設(shè)置（公共或私有）中被授權(quán)，有幾種機制和協(xié)議可確保它們符合網(wǎng)絡(luò)的利益。

· Insolar采用基于節(jié)點角色分離（executor/validators）的可擴展性機制以及熱和冷持久性的分片。

· 由于上述角色模型，通信和數(shù)據(jù)傳輸?shù)臄?shù)量得到了高度優(yōu)化，并且比像以太網(wǎng)這樣的普通式區(qū)塊鏈平臺低了幾個數(shù)量級。

· 使用Insolar并不意味著所有數(shù)據(jù)和所有處理遷移到Insolar區(qū)塊鏈平臺 - 該平臺可以是涉及現(xiàn)有系統(tǒng)的異構(gòu)設(shè)置的一部分。

· Insolar可以促進許可或許可的不同情況，以及公共或私人或其組合。

以上內(nèi)容涵蓋了Insolar區(qū)塊鏈平臺的基本架構(gòu)和重要特征。 此外，我決定將其分為兩個部分，以進一步深入了解Insolar的架構(gòu)。 在下一篇文章中，我們深入探討平臺的處理和持久性，以及私有/公共和許可/許可方面。 此外，我將澄清與早期DLT相比的架構(gòu)的一些方面。根據(jù)從平臺獲得的數(shù)據(jù)開發(fā)快速報告數(shù)據(jù)庫。