Lambda(LAMB)去中心化結構雲儲存

買賣虛擬貨幣
Lambda專案致力於為和去中心化應用提供一個資料儲存基礎設施,在此基礎設施平臺之上,提供去中心化的雲資料庫儲存和訪問能力,並且,Lambda基於水平可擴充套件性和分片技術,提供了高速的交易能力;透過中繼鏈技術和跨鏈交易驗證,提供了系統內的跨鏈交易和資料訪問及驗證能力,透過對BCP協議的支援,提供和其他鏈系統的跨鏈通訊能力。透過提供可無限擴充套件的塊儲存、檔案儲存、物件儲存、KV儲存和表格儲存,以及快速網路傳輸(rsync)在內的一系列基礎能力服務,Lambda使分散式應用可以輕鬆完成資料的生成、計算、傳輸、儲存、檢索。透過屬性加密和代理加密技術,我們對資料的隱私性提供了保護。不僅如此,Lambda 專案還具有資料結構靈活、程式設計介面強大、高效備份等特點。隨著Lambda專案的發展,會有越來越多的服務能力,如分散式快取、基於非易失性記憶體的分散式共享記憶體計算、分散式關係型資料庫、分散式MapReduce等專案,作為平行子鏈加入到網路中來,透過Lambda一起對外提供基礎設施服務。最後,會形成一個雲端的涵蓋數千萬節點的自組織自管理的資料管理系統,所有的去中心化應用均可以透過API來方便的使用這個雲端資料庫來儲存和查詢資料。特別的是,由於無需負擔昂貴的中心化IAAS龐大的組織成本,這個去中心化的雲資料庫一定具備極高的價效比優勢,以及天生具備的異地災備、跨洲際資料共享等能力。這已經初步形成一個去中心化的IAAS,具備儲存、計算、網路頻寬三種基本的IAAS能力,再加上區塊鏈網路提供的價值交換體系,Lambda將是一個具有無限想象空間的全球基礎設施網路。Lambda作為一個去中心化的區塊鏈資料基礎設施,並不會對標中心化資料庫的效能指標,並且,考慮到對等節點分散式網路的特性,Lambda雲資料庫在當前時間肯定存在使用場景的限制。Lambda的優勢在於開源、社羣治理、經濟模型和信任機制可驗證,對於今天的技術人員來說,Lambda可以作為一個雲端的KV資料庫(如redis)、文件型資料庫(mongodb)和時間序列資料庫(druid)來使用,可以先從備份和歸檔場景開始使用,來儲存不可變資料。從業務場景來說,Lambda更加適合於交易速度頻繁,資料流入流出數量較高但改變數較小的場景。Lambda可以用來儲存物聯網和AI資料,此外,也可以用來儲存KV資料、日誌資料、Mertrics和Event資料、物聯網和AI資料、feed流資料等,因此,類似於去中心化的彩票、低頻菠菜、影片網站、Feed流應用、部落格、論壇等去中心化業務均可以使用Lambda雲資料庫作為資料的後端儲存。Lambda Project設計架構

Lambda是一個高速、安全、可擴充套件的區塊鏈基礎設施專案,透過分片技術,可以處理每秒鐘數百萬筆的交易,透過安全的去中心化雲資料庫,為Dapp提供無限擴充套件的儲存能力。Lambda是由以下幾個部分組成,分別是:

一個同構多鏈的鏈系統Lambda Chain,提供高TPS的訪問能力、圖靈完備的智慧合約、跨鏈交易能力等
一個p2p的網路系統Lambda p2p,提供網路層的定址能力
一個多資料庫叢集系統Lambda DB,提供可無限擴充套件的安全加密資料儲存能力
一個Lambda DB的底層結構支撐系統,包括一個塊儲存系統和一個分散式檔案系統Lambda FS
一個由多節點共識組成的屬性基加密認證訪問系統Lambda ABE,資料庫的訪問控制閘道器
一個由多個驗證人節點組成的資料完整性驗證組織Lambda TPA Chain(WorkChain3)
一個自適應的探針系統Lambda Agent,提供記憶體資料儲存、效能監控、安全監控和Metrics資料上傳能力

Lambda專案核心的整體設計思想是鏈庫分離機制和功能子鏈設計。去中心化應用可以按照資料不同的信任和公開驗證等級,將資料分別存放在鏈上和資料庫系統中,Lambda專案提供了不同型別不同層級的資料協同管理。並且,由於整個Lambda DB是一個Permissionless的環境,Lambda還完成了基於多授權機構屬性基加密的訪問控制機制,以及完整的對儲存資料的持有性證明。

鏈庫分離設計的主要原因是為了系統未來的升級和更新考慮,由於區塊鏈系統的更新會導致系統的分叉,總而對整個經濟系統造成不可逆的影響,因此,我們把主要的資料處理能力放在資料庫系統之上,把對於資料庫系統的訪問控制體系透過功能子鏈來完成。功能子鏈設計一是為了未來的擴充套件性,更多是為了完成去中心化儲存系統的兩個核心功能:隱私保護和資料持有性證明。我們透過一種高效的多授權機構屬性基加密方案實現了對雲端儲存資料訪問控制功能和加密功能,並且透過PDP機制(Provable Data Possession, PDP)完成了資料的持有性證明。

Lambda鏈本身是一種同構多鏈的設計,從概念上來說,有三個層次和三個角色。三個層次又劃分為兩個真實鏈層和一個虛擬鏈層,分別是MainChain(真實層,WorkChain0)、WorkChain(虛擬層,WorkChain0到 WorkChainN)和ShardChain(真實層),除了WorkChain0以外,其他所有的WorkChain都是由多個ShardChain組成的概念上存在的鏈。其中,MainChain的共識機制是Nominated Proof-of-Stake NPos,ShardChain的共識機制是HoneyBadgerBFT。MainChain是所有鏈的主鏈和中繼鏈,擁有全部的節點,包括提名人節點、驗證人節點和釣魚人節點。任意一條WorkChain都是由MainChain指派的驗證人節點負責交易的打包和出塊,Sharding的機制則是透過對驗證人節點的分組之後進行BFT共識來完成。因此,Lambda支援跨鏈的交易和跨鏈的通訊。為了實現對資料庫系統的管理,Lambda團隊自己實現了前三條子鏈,分別是對資料請求(Request)進行授權、記錄和請求轉發的WorkChain1、對資料響應(Response)情況進行統計和對資料庫節點進行共識管理的WorkChain2,以及對資料完整性驗證的WorkChain3。未來,透過對更多子鏈的加入,Lambda可以實現更多的功能。

Lambda三個角色的設計分別是提名人、驗證人和釣魚人:

驗證人:驗證人有最高的許可權,在整個Lambda網路中進行交易的打包和出塊,驗證人需要抵押足夠多的TOKEN。另外,我們允許擁有資金的提名人推舉一個或者多個代表他們的驗證人,所以,驗證人的押金不完全是自己所擁有的,有部分是屬於提名人的。驗證人的硬體環境必須符合相應的要求,硬體要求主要是針對CPU核心數、記憶體、SSD硬碟,驗證人的網路環境必須符合高可用、高網路頻寬以及低延遲的要求。驗證人在以上符合要求的機器環境中執行我們的中繼鏈的全賬本客戶端,也就是MainChain的客戶端。在每個區塊上,節點都準備驗證和打包已經在子鏈上完成了共識的區塊的雜湊值。另外,驗證人節點被隨機分配到不同的WorkChain上面,進行子鏈交易的驗證打包和出塊。主鏈和子鏈都是每間隔5秒出一個塊,每過1024個塊,驗證人節點會進行輪換。在我們選擇的共識演算法下,會懲罰一個沒有履行職責的驗證人,如果是偶發性的錯誤,只是會扣留出塊獎勵,但重複的錯誤會導致扣減驗證人的押金(透過燃幣),嚴重的錯誤如雙籤或合謀攻擊等情況發生的時候,會扣除該名驗證人全部的押金,燃燒一部分,並將大部分獎勵給誠實驗證人和提供資訊的釣魚人。

在某種程度上,驗證人和比特幣的礦池作用類似,我們預期系統會有數百個驗證人節點。

提名人:提名人是一個擁有權益的群體,他們把安全性押金委託給驗證人,他們除了投入資金以外,沒有更多的職能。

在我們的設計中,每一個儲存節點/資料庫節點也都要進行安全性押金的委託,因此,每一個資料庫節點和儲存節點也都是提名人。

提名人和比特幣系統的礦工類似,他們起到了監督的作用。我們預期全網有數千名提名人

釣魚人:釣魚人和區塊打包的過程並不相關,他們的角色類似於現實世界中的“賞金獵人”,激勵他們的是一次性的大額獎勵。由於釣魚人的存在,我們才能減少惡意行為的發生。釣魚人只需要及時舉報並證明至少一個有抵押的參與方存在非法行為,他們就能獲得獎勵。比如說對有相同父塊的兩個區塊進行簽名或者在子鏈上打包出一個無效區塊。成為釣魚人的要求是最低的。

短程攻擊、長程攻擊和檢查點機制:對於一個POS的共識機制來說,一個必須要解決的問題就是惡意的驗證人的短程攻擊和長程攻擊。我們透過驗證人抵押資金的方式,來避免驗證人對兩個高度相同的區塊的同時簽名。對於長程攻擊來說,我們計劃採用類似於Polkadot和Casper專案的檢查點機制,來引入強制確定性(Finality)的概念。

權益合約:我們透過權益合約來管理整個驗證人集合,合約主要解決這些問題:

1 哪些賬戶是驗證人
2 哪些賬戶在短期內可以變成驗證人
3 哪些賬戶為了提名驗證人而進行了TOKEN質押
4 每個賬戶的屬性狀態,包括賬戶餘額、接收的質押比例、地址列表等

賬本結構:MainChain是Lambda中的總賬本,每個Workchain都會根據負載情況進行自動拆分與合併,通常情況下一個WorkChain會根據所處理的賬戶字首拆分為多個ShardChain,每個ShardChain均為一條完整的區塊鏈。為了使Lambda中主賬本與分片賬本相互驗證形成網狀的互驗證結構,每個MainChain的新區塊中包含了ShardChain所有新區塊的雜湊(除非部分ShardChain在超時時間內未出區塊),ShardChain的新區塊包含了上一個MainChain的區塊的Hash。

在Lambda中,引入了FishMan角色,即該節點可以對歷史區塊的有效性發起驗證,如果檢測到該區塊無效或區塊中的Transaction無效,則會發起更為嚴厲的驗證並對歷史區塊進行修復,所以Lambda為每一個區塊本身也設計為一個blockchain,正常狀態下該blockchain為一個區塊,當該區塊處於修復的情況下,會在該區塊的垂直方向產生新區塊對對應歷史區塊進行整體替換或修復失效區塊中的部分Transaction資訊。同時引用該失效區塊的其他區塊同樣需要進行修復直至所有狀態修改正確為止。所以Lambda區塊鏈賬本不會產生分叉,即使部分交易遭到破壞,Lambda可以透過垂直鏈進行修復,並同時儲存了所有歷史交易的有跡可尋。

其他未在本文描述的問題:關於WorkChain的註冊、跨鏈交易的訊息和佇列、p2p網路架構設計、垂直鏈賬本、自我修復能力等基礎設計,以及業務邏輯中的資料請求統計、資料響應統計、請求響應對賬、資料庫節點加入交易、資料庫節點離線共識處理、Lambda FS詳細設計等,限於篇幅,我們未將此類問題在本文中列出,在正在編寫的技術黃皮書中,我們會詳細描述此類問題。

在進行資料系統設計的時候,為了保證服務的可用性、效能、可擴充套件性,我們採用資料庫叢集的技術,向去中心化應用提供服務。叢集是Lambda資料庫的一個基本概念,在提供服務的時候,資料總是在一個資料庫叢集內部進行副本的複製,而不會跨越叢集。另外,叢集技術可以使負載在所有的裝置之上保持相對的均衡。

Lambda在設計資料庫系統的架構時,實現了在異構環境下均衡分佈資料的CCHDP演算法。目前,大部分的佈局演算法面向同構的儲存系統,而網際網路的裝置主要是異構裝置,在這些裝置中有效地存放PB規模的資料,是一個具有挑戰性的問題,不合理的資料佈局將會導致大量的儲存空間白白浪費,而且使用者需要花費大量的時間尋找所請求的資料,因而資料佈局演算法在大規模網路儲存系統中非常重要,並且均衡地使用裝置容量可以平衡I/O負載。

為了儘可能地發揮每個裝置的儲存能力,使得儲存系統的整體效能最大化, Lambda會根據裝置的容量以及頻寬公平地分配資料。而且,由於整個系統會不定時新增新的節點以及刪除不合格的裝置,或者某些節點的裝置發生失效等.為了讓儲存系統的效能最大化,需要重新公平地分佈資料。Lambda資料庫系統的某些應用可能是24 小時運轉的,遷移大量的資料必然會消耗大量的頻寬,降低Lambda資料庫系統對應用的服務質量,甚至影響整個系統的可用性。為了不影響系統的儲存服務, Lambda的演算法保證了再次分佈的資料量要儘可能地少。因而, Lambda資料庫系統的資料佈局演算法能夠動態自適應儲存規模的變化,在系統規模變化時遷移儘可能少的資料.同時,也保證了佈局演算法能夠利用很少的時間和空間資訊計算出某個資料的存放位置。

Lambda使用的CCHDP(clustering-based and consistent hashing-aware data placement)演算法可以在異構的裝置集合中按照裝置的權重公平地分佈資料,自適應儲存規模的變化,在儲存規模變化時遷移最少的資料量,而且能夠在較短的時間內計算資料的位置,僅需要引入少量的虛擬裝置,大大減少了儲存空間,CCHDP是一個聚類和一致性雜湊技術相結合的演算法。

Lambda 資料完整性驗證的基本原理(選讀)

在雲端計算技術發展初期,學術界就將資料的完整性證明和持有性證明視為研究的前沿領域,並不斷的進行相關的探索。在常規雲端計算環境中,由於大規模資料所導致的巨大通訊代價,使用者不可能將資料下載後再驗證其正確性.因此,雲使用者需在取回很少資料的情況下,透過某種知識證明協議或概率分析手段,以高置信概率判斷遠端資料是否完整。典型的工作包括:面向使用者單獨驗證的資料可檢索性證明(POR)方法、公開可驗證的資料持有證明(PDP)方法。NEC實驗室提出的PDI(provable data integrity)方法改進並提高了POR 方法的處理速度以及驗證物件規模,且能夠支援公開驗證。其他典型的驗證技術包括:Yun 等人提出的基於新的樹形結構MAC Tree 的方案;Schwarz 等人提出的基於代數簽名的方法;Wang 等人提出的基於BLS 同態簽名和RS 糾錯碼的方法等。

去中心化的雲端儲存和雲資料庫,相比較於中心化的雲,其最大區別在於Permissionless的儲存節點,並且,雲使用者不可作為驗證發起人,也沒有完全可信的TPA節點。在Lambda的設計中,我們採用的是支援公開驗證的PDP方法的兩個升級版本,BLS-PDP和MF-PDP,我們將透過多個驗證人節點的共識來共同一個可信TPA的工作,也就是完成資料的持有性和完整性驗證,並將驗證結果寫到鏈上,以備FisherMan查驗。在區塊鏈系統中,由於資料本身具備按照時間的自增加特性,沒有更新和刪除的邏輯,資料的修改模式為just append。另外,在雲端儲存環境下,針對動態資料更新問題,我們觀察到,雲端儲存有別於傳統儲存(如檔案系統)的資料更新模式,即,典型的資料更新操作不是對檔案內容的插入或修改,而是靜態檔案數量的變化(通常為增加),因此,我們可以將資料庫的表空間檔案視為具備靜態檔案的特點。

Lambda驗證方案中的BLS-PDP基於BLS同態簽名演算法,BLS簽名機制是由Boneh等人提出的一種短訊息簽名機制, 相比目前最常用的兩種簽名機制RSA 和 DSA 而言, 在同等安全條件下(模數的位數為 1024bit), BLS 簽名機制具有更短的簽名位數,大約為 160bit(RSA 簽名為 1024bit, DSA 簽名為320bit). 另外, BLS 簽名機制具有同態特性, 可以將多個簽名聚整合一個簽名. 這兩點好的特性使得基於 BLS 簽名的 PDP 機制可以獲得更少的儲存代價和更低通訊開銷來實現. 基於 BLS 簽名的 PDP機制是一種公開驗證機制, 使用者可以將繁瑣的資料審計任務交由我們的WorkChain3 來完成, 滿足了雲端儲存的輕量級設計要求, 具體實現如下圖所示. 另外, 相比其他機制而言, 該機制具有更小的儲存開銷和通訊開銷。

Lambda 的多授權機構屬性基加密資料訪問控制方案(選讀)

當前,區塊鏈上的資料都是可公開訪問的資料,這極大限制了資料的使用場景,為了擴充套件使用場景,Lambda提供了基於多授權機構屬性基加密的訪問控制方案,並提供了資料加密的能力,以及透過代理加密對屬性撤銷的能力。屬性基加密(attribute-based encryption,簡稱ABE)機制以屬性為公鑰,將密文和使用者私鑰與屬性關聯,能夠靈活地表示訪問控制策略,從而極大地降低了資料共享細粒度訪問控制帶來的網路頻寬和傳送結點的處理開銷.因此,ABE 在細粒度訪問控制領域具有廣闊的應用前景。

在屬性基加密(Attribute-Based Encryption,簡稱ABE)方案中,其金鑰構成與屬性集合相關,密文構成與訪問結構相關;如果屬性集合能夠滿足密文中的訪問結構,便可以獲取明文。ABE 不僅具有一對多的特點,而且可以實現不確定使用者數的解密,因此被廣泛地應用於雲端儲存資料的細粒度訪問控制。但常規ABE加密計算代價大,並且計算開銷隨著訪問結構中屬性個數的增加而線性增加,不適合直接應用於電力資源有限的移動終端,因此不適合在區塊鏈領域直接使用。

線上-離線(Online-Offline)和轉換金鑰技術可以透過預處理及外包解密的方式來降低使用者端加密和解密的計算開銷,但前者需要在離線加密階段確定訪問結構,實際上不同資料的訪問結構並不相同,不便於提前確定;後者透過把解密外包到不完全可信的第三方,不能保證解密的正確性.儘管Shao 等人提出的方案可以不用提前確定訪問結構,但是使用者的屬性集合只受到一個屬性授權機構的管理,不利於系統規模的擴充;而且其沒有驗證外包解密的正確性。

面對以上的挑戰, Lambda採用了一個線上- 離線的多授權機構屬性基加密(Online/Offline Multi-Authority Attribute BasedEncryption,簡稱OO-MA-ABE)方案,其主要思想是把使用者端線上計算代價轉移到離線階段或者雲伺服器上。

Lambda 生態系統

1/Lambda 經濟生態

不同於大多數的區塊鏈應用,Lambda是一個區塊鏈的資料儲存基礎設施,並帶有自己的若干條用於計費、交易、加密和訪問控制的鏈。Lambda專案的原生代幣LAMB產生要消耗節點的記憶體和儲存資源。在Lambda平臺之上,可以交易的資源主要是格式資料的訪問能力,快速訪問能力是硬碟儲存能力和記憶體大小的結合體,由於儲存之後的資料是以加密的形勢存放,應用訪問的時候需要解密,因此,也需要消耗CPU資源。我們在衡量儲存提供方貢獻的時候,以對資料塊的千次解密並返回作為單位計價單元。

Lambda生態中,參與各方的角色分別是Dapp開發者和專案方、鏈節點參與方、儲存節點參與方和其他參與方如投資人。其中鏈節點的角色在第一張已經進行過闡述,主要是提名人、驗證人和釣魚人。Lambda不同於其他主鏈的點在於,我們有自身的業務邏輯(Business Logic),我們要對使用者的請求、返回進行處理和記賬,並且管理儲存資源池內的共識和結算。

Lambda的資料儲存池邏輯由四種角色組成:儲存資源提供者,儲存資源購買者,社羣開發人員和資料購買者這四個群體組成了Lambda相互依存的生態系統。並且,從商業模式來說,這四類角色都有可能是個人使用者,也有可能是企業。

2/Lambda Cryptocurrency LAMB

主鏈共識演算法: POS
我們選擇Nominated Proof-of-Stake NPos作為共識演算法

簽名演算法:可變簽名型別
每個公鑰均具有一個說明符(specifier)(一個16位元組的陣列)和包含公鑰編碼(encoding)的位元組切片(byte slice)。 說明符用來指定在校驗簽名時使用哪個簽名演算法。,每個簽名將是一個位元組切片,其編碼可以透過檢視相應公鑰的說明符來確定。

備選簽名演算法有:ed25519、ECDSA secp256k1、Schnorr secp256k1

Lambda Cryptocurrency(LAMB)
Lambda Coin :Lambda Coin(簡稱“LAMB”)是Lambda專案的核心,也是Lambda專案顛覆傳統的商業閉源軟體開發模式的主要武器。傳統軟體公司的商業模式下,存在著大量的交易成本和組織成本,軟體公司為了價值的轉移和交付,不得不僱傭大量的人工來獲取使用者、提供服務、解決問題,在Lambda專案中,這些可以更加最佳化的方式完成。

· POS共識機制:Lambda鏈的共識機制採用POS工作量證明,驗證人完成雜湊計算可以得到Lambda獎勵。另外,資料庫儲存節點在指定時間完成對對指定大小的資料檔案存放,根據合約可以得到Lambda Coin獎勵;

· UTXO模型:作ambda鏈的賬本結構採用UTXO模型,同時支援Account模型,設計實現方式類似於Qtum。
· 跨鏈交易和BCP協議:作為UCE經濟體系聯盟的成員,我們的設計中遵循BCP協議,並且支援在UCE體系內的原子跨鏈交易和原子合約交易。
· EVM和智慧合約:我們將在鏈上實現對智慧合約的支援,並提供完備的合約形式化驗證能力。
· 總量:Lambda Coin的總量是100億枚
· 質押:驗證人和提名人需要質押LAMB,質押總量約等於LAMB總數的8~12%。
· 流通:第一年,40%的Token還在等待出塊獎勵,20%的Token鎖定在基金會賬戶,10%的團隊Token和20%的私募也在凍結期尚未解鎖,市面可流通的Token最大約為10%。
· 租用:租用雲端Lambda資料庫的使用者需要在交易所購買LAMB。
· 交易:在Marketplace交易資料的人,買方需要在交易所購買LAMB。
· 規則:Lambda Coin的的分配規則是,創始團隊10%,募資30%,基金會20%,其餘40%為出塊獎勵,20年挖完。20年後,代幣總數保持每年約0.5%的緩慢增長。

3/區塊產生規則

MainChain區塊和ShardChain區塊

最大的區塊大小為32*10∧6(32e6)位元組,也就是32M。交易(transaction)大小沒有限制,但它必須能夠被容納於區塊內部,驗證人制每個交易的大小。

每個區塊都有一個最小准許時間戳。它是透過取前面10個區塊的中間時間戳來確定的。如果之前的區塊不足10個,則需重複使用初始時間戳(genesis timestamp)。

區塊ID的產生規則是:H(父區塊ID + 64位隨機數+ 區塊Merkle樹根節點)。
對於有效的區塊,區塊ID必須低於某個特定目標。
MainChain和ShardChain的出塊預期都是5秒鐘。
MainChain中包含了所有ShardChain的區塊的雜湊,ShardChain包含了上一個MainChain區塊的區塊頭。

交易

一個交易(Transaction)主要由以下幾個物件組成:

LAMB輸入(LAMB Inputs)
LAMB輸出(LAMB Outputs)
檔案合約(File Contracts)
檔案合約修訂(File Contract Revisions)
儲存證明(Storage Proofs)
礦工酬勞(Miner Fees)
交易簽名(Transaction Signatures)

所有LAMB輸入(LAMB input)的總和必須等於所有礦工酬勞(miner fee)、LAMB輸出(LAMB output)和檔案合約支出(filecontract payout)的總和,沒有剩餘。在上述物件中存有解鎖hash值(unlock hash)。 解鎖雜湊值是“解鎖條件(unlock condition)”物件的Merkle樹根,解鎖條件包含一個時間鎖數值(time lock)、若干必需的簽名以及可在簽名期間使用的一組公鑰。解鎖條件(unlock condition)物件的Merkle樹根節點,是由時間鎖(timelock)、公鑰(每個公鑰對應1個葉子節點)以及簽名的數量所構成的Merkle樹的根。 需要提供足夠多的簽名,並且區塊鏈的高度至少等於時間鎖(timelock)的值,才能滿足解鎖條件(unlock condition)。

解鎖條件(unlock condition)包含一組公鑰,每個公鑰只能在提供簽名時使用一次。相同的公鑰可以被包含兩次,這意味著它可以使用兩次。所需簽名的數量指示必須使用多少公鑰來驗證輸入(input)。如果所需的簽名數量為“0”,則輸入(input)是“任何人都可以消費”。如果所需的簽名數量大於公鑰的數量,則輸入(input)是不可消費的。

合約

資料儲存合約是資料儲存提供商與其客戶之間的協議。客戶選擇Lambda提供的虛擬資料節點來儲存資料,並進行相應的資料庫檢索等操作。客戶和儲存提供商之間簽訂的是一個持續性協議,並根據一定的條件進行分期付款。不同於檔案類儲存的是,資料庫儲存的資料是慢慢增大的,因此,客戶向每個節點的資料庫服務商的每次付款金額是:

總約定金額* 變更週期 * 當前使用的儲存空間大小/ 總持續時間 * 總約定空間
付款週期取決於驗證人節點對資料儲存節點進行資料持有性證明的週期。
一個資料合約的核心是資料儲存檔案的Merkle DAG。

4/Lambda 經濟系統

Lambda的經濟系統的角色由以下幾類組成:

鏈節點
· 鏈節點上又分為驗證人、提名人和釣魚人。鏈節點主要提供了對服務訪問的路由、記賬、訪問控制和加密的能力。
1 鏈節點的主要受益來自於POS的Staking交易的挖礦收入,另外,釣魚人可以對驗證人的記賬資訊和儲存節點的儲存資訊進行驗證,並獲得受益

儲存節點

·儲存節點的主要收入來自使用者支付的費用
·儲存節點需要預先質押一部分資金,並獲得POS的分成受益
·儲存節點需要定期向驗證人傳送心跳資訊,其中的幸運者可以獲得一些獎勵,這個設計主要是為了激勵儲存節點的線上

使用者
·使用者是採購並使用儲存節點的人,通常來說,會是其他應用鏈和Dapp

投資人
·投資人投資於Lambda專案,並分享LAMB上漲帶來的收益

交易所
·數字貨幣交易所

5/平臺能力

5.1 對修復和提交bug的獎勵機制

軟體的使用者在使用過程中遇到問題,會選擇向社羣提交Bug,社羣的程式碼開發人員會按照程式碼bug的影響範圍和重要程度,依次修復Bug。修復之後的Bug會用Patch的形式做成安裝包,放到社羣供使用者下載。

在這個模型下,由於過程不連貫,並且程式碼bug的修復判斷依賴於人,導致很多基礎軟體都沒有能夠升級到最近版本,給系統整體可用性、效能和安全性帶來了極大影響。Lambda專案透過智慧合約的形式,使用者可以釋出懸賞,消耗一定的LAMB要求開發人員修復,修復之後的Bug patch會自動透過Lambda Agent Release Automation模組來安裝到使用者系統之內,無須手動操作。

最初提交Bug的使用者,會根據後續的其他使用者使用Patch的情況,得到LAMB獎勵。

5.2 對效能提升的獎勵機制

5.3 安全漏洞自動防護

Lambda Agent還收集各種安全資料。然後向安全社羣報告。我們使用AI檢查資料,並將安全資料進行彙總。如果是新的或罕見的安全問題,將會向公司生態安全專家報告。如果確認是安全問題,例如一個成功的CVE被公開承認宣佈,第一個報告者將被授予LAMB幣。


關於更多Lambda資訊:

更多區塊鏈資訊:http://www.qukuaiwang.com.cn/news/
風險提示:區塊鏈投資具有極大的風險,專案披露可能不完整或有欺騙。請在嘗試投資前確定自己承受以上風險的能力。區塊網只做專案介紹,專案真假和價值並未做任何稽覈!

免責聲明:

  1. 本文版權歸原作者所有,僅代表作者本人觀點,不代表鏈報觀點或立場。
  2. 如發現文章、圖片等侵權行爲,侵權責任將由作者本人承擔。
  3. 鏈報僅提供相關項目信息,不構成任何投資建議

推荐阅读

;