b. 對儲存礦工儲存的實際需求量進行檢查,需要滿足:
2. 對以上儲存礦工列表進行遍歷檢查N個週期內未出現PoST證明失敗。
3. 對儲存礦工表按照S持有量進行排序,取值TOP(x),X為需要補增的Validator數量。
4. 更新後的Validator表統一按照演算法進行排序,SortValidator(HASH(ValidatorID+BlockHeight))。
Validator退出機制:
1. 對Validator表進行遍歷檢查最近一次Validator為退出交易狀態Validator Logout。
2. 狀態為Login但不滿足該條件儲存容量條件。
3. 對以上Validator列表遍歷檢查N個週期內出現了M次扇區證明失敗。
4. 對以上Validator列表遍歷檢查N個週期內出現了參與共識失敗或其他惡意行為。
Lambda Consensus
· 共識輸入條件:
· Height,區塊高度
· Max Block Interval,出塊超時時間
· Max Block Size,塊最大值
· Election Seed,VRF隨機種子
· Validator Table,Validator列表
· VT Update Circle,Validator表更新週期
· Difficulty,時間引數,用於動態調整出塊週期
· Block Reward,塊獎勵函式
· Reward Curve, 激勵曲線
共識流程如下圖:
Lambda Consensus演算法是基於當前 Validator Table。
Lambda Consensus演算法基本步驟如下:
1) 根據當前塊資訊新區塊號、當前塊的ConsensusNodeHash、當前塊HASH、當前塊VRFSeed組成VRFParameter。
2) 根據VRFParameter使用VRF函式生成新一輪的VRFSeed。
3) 根據新一輪的VRFSeed與ValidatorTable生成 ConsensusNodeList = GetConsensusNodeList(ValidatorTable,Index(VRFSeed),TotalConsensusNode)。
4) 從ConsensusNodeList中對預選區塊進行驗證,並獲取權重最高的區塊進行投票,權重與Validator的Sector個數與節點Hash相關。
5) 對投票後的區塊進行BFT共識,並廣播區塊。
資料完整性
PDP
(a) 使用者為待外包的每塊資料生成一個 tag,這個 tag 是經由使用者簽名的;
(b) TPA 隨機地對使用者外包資料中的一塊或多塊發起 challenge,這個 challenge 中包含由 TPA 生成的隨機數;
(c) 儲存礦工根據被挑戰的資料塊內容、tag 資訊、challenge 資訊以及自己生成的一個隨機數計算得到一個 proof;
(d) TPA 以 challenge、proof 及使用者公鑰為引數,透過對映函式 的雙線性性質檢驗儲存礦工是否持有資料。
PDP形式化定義如下圖:
LAMB-PoST
PDP方案面臨的問題如下:
· Challenge隨機挑戰資訊的生成依賴於TPA,這個隨機挑戰值是否安全。發起Challenge時為了更高的檢測率,需要一次性完成多塊資料的檢測,對每一塊都需要生成隨機挑戰引數,大大增加了發起挑戰的通訊複雜度。
· 互動式的挑戰要求必須為強同步網路,並且<challenge,prove>互動次數過多造成系統的網路負載增加。
· 儲存礦工儲存了大量的碎片訂單,如果每次挑戰針對一個訂單,挑戰數量會嚴重影響系統的負載。
· 如果一份資料以多副本方式儲存,或匹配到多個礦工時,如何解決女巫攻擊和多副本的虛假儲存。
· 在生成證明時可以證明當前時刻儲存了檔案,如何確保在兩個檢測週期之間是否儲存了檔案。
· LAMB-PDP方案在PDP演算法之上需要解決以上的問題,基本流程如下圖所示。
· 礦工將多個檔案片段封裝到一個扇區中,同時將tag資訊、公共引數、片段/檔案索引記錄到區塊鏈中。
· 礦工從最新的區塊中獲取挑戰隨機種子R,礦工計算本次需要挑戰的扇區S,礦工應確保每個
· Sector在M個週期內提交儲存證明,以獲取相應收益。
· 礦工根據GenChallenge(R , S , Index) -> challenge生成挑戰。
· 礦工根據GenProof(data, challenge, tag) -> proof 生成證明。
· 礦工使用GenNextChallenge() 生成挑戰 ,重複進行t次證明並生成ProofSet。
· 礦工將ProofSet提交到網路中,等待被Validator驗證與打包。
· 礦工需要對扇區持續提供PoST儲存證明,T個週期未收到PoST則認為扇區丟失。
· 將扇區標記為丟失狀態,並更新相應懲罰記錄、扇區內包含的訂單資料進行重新匹配或修復
· 修復工作也可由使用者完成。
激勵機制與費用模型
激勵機制
共識激勵
共識節點是透過VRF在Validator表中隨機產生的,每次新的區塊產生後都會為下一區塊共識節點選舉生成種子並寫入新區塊中。每個出塊週期中共識節點個數為固定值,如出現某個共識節點未參與共識過程則不參與分配出塊獎勵,多次出現該行為則被退出Validator列表。共識節點的出塊獎勵為:
Lambda出塊獎勵總數為40億,初始階段每個塊獎勵160 LAMB,以後每4年區塊獎勵減少1/2,最終減少到每年0.5%後不再改變。出塊獎勵還受限於Lambda生態的發展程度,全網的儲存供應量和需求量共同決定,挖礦曲線及係數表如下:
舉例1:全網供應容量5PB、全網需求容量1PB、Validator參選條件為5PB/2/512 = 4.88TB、共識節點每次選取10個,假設抽取到的樣本為【20T、10T、6T、30T、32T、36T、8T、6T、10T、6T】。礦工A實際儲存量為20TB資料,出塊獎勵為:[160/2*0.5+160/2*0.5]*(20T/164T)*0.7=6.82LAMB,在共識節點抽取樣本不變得情況下,每天約收益約1150 LAMB
舉例2:全網供應容量120PB、全網需求容量60 PB、Validator參選條件為120PB/2/1024 =117TB、共識節點每次選取10個,假設抽取到的樣本為【200T、300T、120T、140T、380T、210T、130T、170T、260T、320T】。礦工A實際儲存量為200TB資料,出塊獎勵為:[160/2*1+160/2*1]*(200/2230)*0.7=10.045LAMB,在共識節點抽取樣本不變得情況下,每天收益約847 LAMB
礦工激勵
礦工包含儲存礦工與檢索礦工,為了Lambda網路能夠吸引地理位置分散的資源、更多儲存節點以及檢索節點的加入,在礦工晉升為Validator前能夠獲得更多的回報並不斷的升級儲存與檢索資源,非Validator礦工也可以獲得系統的出塊獎勵,出塊獎勵為N個節點平均分配(Block Reward * 30%),N作為系統引數待確定,N約為活躍礦工數的5%比例。
礦工列表維護條件:
1) 儲存礦工質押了扇區,檢索礦工質押了LAMB;
2) 礦工在M個塊週期內,接收了訂單或提交了PoST證明,檢索礦工為使用者提供了檢索服務;
3) 根據礦工ID與Block HASH 進行列表排序,並取前N個礦工予以獎勵。
MinerListSortBy(HASH(node id + block hash))
舉例3:全網供應容量5PB、非Validator礦工平均儲存容量2TB,共1250個非Validator礦工。非Validator儲存礦工儲存容量為2TB,8640*256/1250=1769.472次機會被選中。每天收益約:[160/2*1+160/2*1]*0.3=24/256=0.09375,每天收益約1769.472*0.09375=165 LAMB
費用模型
手續費用構成
轉賬交易手續費
Lambda網路中每筆轉賬交易均有手續費,手續費用的多少由網路當前執行的負荷量決定,手續費是否足額決定了交易的打包優先次序。轉賬交易手續費由 價格和數量兩個因子共同確認。手續費用由轉賬發起人支付,轉賬交易的手續費用受益人為共識網路中的Validator角色。
儲存訂單手續費
儲存訂單手續費是指,礦工賣單與使用者買單撮合後的成交訂單的手續費用,手續費用為訂單金額的固定比例,該固定比例為系統引數,主網啟動時決定。儲存訂單手續費由儲存礦工的儲存收益部分中結算時進行支付。儲存手續費用受益方分為兩部分,一部分為共識網路中的Validator,大部分為交易市場的運營者。運營者為第三方角色,可公開註冊並運營。
檢索訂單手續費
檢索訂單手續費是指,礦工與資源下載使用者撮合後的成交訂單的手續費用,手續費用為訂單金額的固定比例,該固定比例為系統引數,主網啟動時決定。儲存訂單手續費由儲存礦工的檢索收益部分中結算時進行支付。儲存手續費用受益方檢索交易市場的運營者。運營者為第三方角色,可公開申請並運營。
質押費用構成
儲存空間質押
儲存空間質押金額總體無限趨向於全網Coin發行量的40%,這一過程可能需要約數年時間,隨著礦工質押空間逐漸增加,單位空間質押量將逐步下降,單位空間質押金額與礦工自身質押累計量相關,關聯曲線與計算公式如下:
未成交的儲存質押可以撤銷質押,已成交儲存質押需要在申請撤銷後,由系統重新匹配訂單併成功轉移資料後可撤銷,且最短質押時長不低於四周。
Validator質押
Validator質押前提條件為該節點作為礦工,已經滿足當前Validator的最低儲存要求,此時儲存礦工需要執行獨立的共識節點程式,並質押一定數量的LAMB,質押數量為一個固定的金額, Validator可撤回質押,質押的LAMB可在四周內退回。質押金額也可能被扣減燃燒,如出現雙籤、離線、未投票等行為。
檢索礦工質押
檢索礦工少量質押,防止惡意攻擊,為固定數量LAMB,質押金額可以在檢索礦工撤銷檢索掛單後,檢索訂單服務完成後實時撤回全額檢索質押。
使用者消費保證金
使用者需要按照實時訂單金額足額提供保證金,如儲存10GB、一年、需要足額資金。儲存礦工在提交儲存證明後網路會從使用者提交的消費金額中按比例支付。使用者需至少儲存一週後方可取消訂單,同時將未消費部分返還使用者。
儲存設施
整體架構
Lambda儲存網路首先是一個DHT網路,所有儲存礦工透過節點自動發現加入到網路中,路由資訊儲存在整個DHT網路中,並能夠實現點對點的資料傳輸。DHT網路是Lambda儲存的網路基礎,在此至少我們去構建豐富的儲存型別。但這裡所有的技術細節透過訪問短的Agent進行封裝,對於使用者來說與使用傳統資料儲存設施有相同的體驗。在DHT網路中交換的只是資料片段,儲存礦工並不清楚資料的內容與意義。
基於DHT分散式網路之上,Lambda逐步開發不同儲存型別,如物件儲存、檔案儲存、KV儲存、部分關係型儲存型別,這也需要Agent的同步開發以降低不同儲存型別使用的開發難度。區塊鏈上的資料都是可公開訪問的資料,這極大限制了資料的使用場景,為了擴充套件使用場景,Lambda提供了基於多授權機構屬性基加密的訪問控制方案,並提供了資料加密的能力,以及透過代理加密對屬性撤銷的能力,安全訪問控制透過鏈上進行授權。
業務流程
Lambda網路交易市場連線了礦工與使用者,礦工透過資源準備、質押、價格釋出完成進入市場的動作,使用者根據儲存需求準備資金,使用者可選擇合適的交易市場後由Agent自動完成儲存、檢索掛單並透過選擇的交易市場完成訂單匹配,之後進行許可權驗證與資料交換。具體流程如下圖:
視覺化與擴充套件
錢包
Lambda錢包主要包含首頁檢視、礦工檢視、消費者檢視、Validator檢視。在錢包內可完成餘額、轉賬、借款、出借等交易功能,在礦工檢視中可完成裝置註冊、空間質押、銷售掛單、訂單跟蹤、取消質押、礦機下架、轉讓封存空間、加入礦池等功能;在消費者檢視中可跟蹤訂單與支付資訊,獲取訪問授權等操作;在Validator檢視中可跟蹤Validator資格驗證、Validator申請、撤銷、出塊跟蹤等功能。該錢包為引導性示例,在釋出時具備上述功能。同時Lambda會開發API可由第三方開發、釋出。
瀏覽器
後續工作
· 儲存介面的詳細定義與Agent開發;
· 提供第三方運營儲存於檢索市場的能力,合約能力的開放;
· 訪問控制與授權部分的完善;
· 儲存證明根據儲存型別的調整與最佳化;
· Validator儲存驗證的效能最佳化;
· 資料檢索市場與實時資料流的支援;