編者的話：本提案為Qtum聯(lián)合創(chuàng)始人以及核心開(kāi)發(fā)工程師Jordan Earls發(fā)布在Github的Qtum x86虛擬機(jī)最新進(jìn)展中(點(diǎn)擊閱讀原文或復(fù)制鏈接至瀏覽
編者的話：本提案為Qtum聯(lián)合創(chuàng)始人以及核心開(kāi)發(fā)工程師Jordan Earls發(fā)布在Github的Qtum x86虛擬機(jī)最新進(jìn)展中(點(diǎn)擊閱讀原文或復(fù)制鏈接至瀏覽器打開(kāi)：https://x86.qtum.org/)，他提出了一種關(guān)于存儲(chǔ)的全新技術(shù)提案——Qtum-x86虛擬機(jī)中所有存儲(chǔ)區(qū)都可實(shí)現(xiàn)租賃機(jī)制，高效的節(jié)省了虛擬機(jī)內(nèi)存。
就目前而言，在EVM基礎(chǔ)設(shè)施不受影響下，全新租賃機(jī)制是一種“被動(dòng)”的方式去實(shí)現(xiàn)，不需要特殊的合約邏輯來(lái)處理相關(guān)的租賃過(guò)程，也不需要支付所消耗存儲(chǔ)區(qū)的租金。該技術(shù)設(shè)計(jì)將有效地限制節(jié)點(diǎn)需要存儲(chǔ)的數(shù)據(jù)總量，同時(shí)還能限制輕量級(jí)SPV節(jié)點(diǎn)對(duì)智能合約進(jìn)行有效治理與交互所需的總空間。
為什么會(huì)提出EVM租賃機(jī)制?
區(qū)塊鏈基礎(chǔ)設(shè)施技術(shù)背后的邏輯都面臨著一個(gè)問(wèn)題：“區(qū)塊鏈虛擬機(jī)數(shù)據(jù)越來(lái)越多怎么辦?”，因此存儲(chǔ)空間的消耗長(zhǎng)期以來(lái)一直是區(qū)塊鏈領(lǐng)域內(nèi)一個(gè)受人關(guān)注的話題。任何區(qū)塊鏈，尤其是具有智能合約功能和附加狀態(tài)的區(qū)塊鏈，據(jù)估計(jì)存儲(chǔ)空間的需求會(huì)在短短10年內(nèi)超出大多數(shù)計(jì)算機(jī)和服務(wù)器的存儲(chǔ)能力。
這種磁盤空間需求的膨脹將導(dǎo)致全節(jié)點(diǎn)會(huì)集中到那些能負(fù)擔(dān)得起價(jià)格高昂的具有非常大存儲(chǔ)的價(jià)格的人手中。簡(jiǎn)而言之，未來(lái)就會(huì)出現(xiàn)由于存儲(chǔ)設(shè)備的門檻導(dǎo)致資源的集中，也就與去中心化背道而馳。
舉例而言，數(shù)年來(lái)隨著區(qū)塊鏈?zhǔn)袌?chǎng)的蓬勃發(fā)展，以太坊交易數(shù)量越來(lái)越多，單個(gè)區(qū)塊體積的最大值限制使得區(qū)塊空余空間顯得越來(lái)越小。如圖，相比比特幣而言以太坊的區(qū)塊大小更加呈現(xiàn)增量上升的模式，甚至在2017年后以太坊的區(qū)塊大小由不足0.1TB上升至接近0.4TB。
因此，越來(lái)越多的開(kāi)發(fā)者和相關(guān)技術(shù)都在進(jìn)行底層基礎(chǔ)設(shè)施的探索，想要商業(yè)應(yīng)用于區(qū)塊鏈技術(shù)真正實(shí)現(xiàn)技術(shù)的融合，就需要不斷去提出新的思想和新的技術(shù)探索，因此本文提出共享存儲(chǔ)的設(shè)想，幫助區(qū)塊鏈的基礎(chǔ)設(shè)施早一步更好的搭建商業(yè)設(shè)施的橋梁。
QIP-17：Qtum-x86內(nèi)的存儲(chǔ)區(qū)租賃
對(duì)此在Qtum x86設(shè)計(jì)上所做的變更可以劃分為以下3個(gè)部分：
DeltaDB 重新傳播和租賃行為
“休眠”狀態(tài)的智能合約行為
“喚醒”休眠狀態(tài)的方法
首先，用于不同狀態(tài)的術(shù)語(yǔ)解釋
· 活躍：該狀態(tài)要求支付一定的租金，從而在區(qū)塊鏈上保持其活躍性并易于訪問(wèn)
· 休眠：未能在適當(dāng)?shù)臅r(shí)間內(nèi)支付租金時(shí)所處的狀態(tài)，并且在沒(méi)有通過(guò)交易進(jìn)行重新傳播的情況下不能通過(guò)智能合約直接訪問(wèn)
· 喚醒：這是將休眠狀態(tài)恢復(fù)到活躍狀態(tài)的動(dòng)作，以便可以再次通過(guò)智能合約直接訪問(wèn)它
DeltaDB 重新傳播和租賃行為
合約的每一個(gè)狀態(tài)，包括它自己的字節(jié)碼，都有一個(gè)通過(guò)區(qū)塊高度表示的租金計(jì)時(shí)器。一旦該計(jì)時(shí)器值為0，就會(huì)從活躍狀態(tài)切換到休眠狀態(tài)，并且節(jié)點(diǎn)可以安全地從其內(nèi)部數(shù)據(jù)庫(kù)中刪除與該狀態(tài)相關(guān)的大部分?jǐn)?shù)據(jù)。當(dāng)訪問(wèn)或修改狀態(tài)時(shí)，會(huì)隱性地進(jìn)行租金支付，這會(huì)被計(jì)入至該操作的gas開(kāi)銷中。當(dāng)通過(guò)訪問(wèn)數(shù)據(jù)進(jìn)行租金支付時(shí)，該狀態(tài)會(huì)將其計(jì)時(shí)器重置為RENT_TERM。無(wú)法通過(guò)預(yù)付款的方式將一個(gè)狀態(tài)的計(jì)時(shí)器設(shè)置為大于RENT_TERM的值。
使用DeltaDB當(dāng)前的共識(shí)模型時(shí)，讀取一個(gè)狀態(tài)(通常)不會(huì)向DeltaDB證明樹(shù)添加新的delta(狀態(tài)更改/通知)。使用本文提出的存儲(chǔ)區(qū)租金提案，每個(gè)狀態(tài)訪問(wèn)都會(huì)通過(guò)向DeltaDB證明樹(shù)提交一個(gè)delta從而引起狀態(tài)的“重新傳播”。雖然這對(duì)合約甚至大多數(shù)區(qū)塊鏈開(kāi)發(fā)人員而言都沒(méi)有影響，但還是會(huì)帶來(lái)許多副作用：
· SPV(輕錢包)節(jié)點(diǎn)可以證明狀態(tài)最近一次租金支付的時(shí)間
· 相反，它允許可以從SPV或全節(jié)點(diǎn)的內(nèi)部數(shù)據(jù)庫(kù)中刪除狀態(tài)和大多數(shù)證明開(kāi)銷的證明
· SPV節(jié)點(diǎn)可以更快地獲得狀態(tài)數(shù)據(jù)的抗審查證明，通過(guò)更頻繁地傳播合約中最常用的數(shù)據(jù)，需要掃描的區(qū)塊也更少
· 除了喚醒狀態(tài)所需的開(kāi)銷之外，這不會(huì)消耗額外的區(qū)塊空間，因?yàn)镈eltaDB證明樹(shù)會(huì)以單個(gè)32字節(jié)長(zhǎng)的哈希值的形式保存在區(qū)塊頭中，而不會(huì)帶來(lái)其他的開(kāi)銷
· 由于能夠證明不再需要比RENT_TERM更舊的數(shù)據(jù)， 這可以大大降低Qtum-x86區(qū)塊鏈理論上的最大磁盤空間消耗，尤其是在進(jìn)行修剪操作時(shí)。通過(guò)修剪，經(jīng)過(guò)500個(gè)區(qū)塊后，大多數(shù)喚醒狀態(tài)下的交易就不再需要存儲(chǔ)了
當(dāng)然，這將限制節(jié)點(diǎn)存儲(chǔ)的數(shù)據(jù)僅限于持續(xù)共識(shí)所需的數(shù)據(jù)。區(qū)塊鏈上的證明總是可用的，例如出版證明等用例。然而，這些證明通常只會(huì)被添加一次，并且之后也是偶爾才會(huì)被訪問(wèn)，因此對(duì)于共識(shí)而言是非必要的。
對(duì)于每個(gè)休眠狀態(tài)，節(jié)點(diǎn)需要記錄以下數(shù)據(jù)：
· 狀態(tài)最后一次傳播所處的區(qū)塊高度(即最后一次支付租金的時(shí)間)
· 索引數(shù)據(jù)的密鑰哈希
智能合約
大多數(shù)關(guān)于存儲(chǔ)租賃設(shè)計(jì)的提案都要求智能合約具有明確且易錯(cuò)的租金管理和意識(shí)。在這種設(shè)計(jì)中，一切都是隱性的，在特定合約設(shè)計(jì)之外不需要進(jìn)行租金檢測(cè)操作。通過(guò)這個(gè)提案，一定程度上會(huì)對(duì)不可避免的異常行為產(chǎn)生影響，包括合約試圖訪問(wèn)休眠狀態(tài)時(shí)拋出的異常。
· 與以太坊的異常模型會(huì)消耗所有的gas不同，該機(jī)制只會(huì)消耗合約產(chǎn)生異常時(shí)的那部分gas，以及一定的“異常稅”
· 所有修改后的狀態(tài)都會(huì)被恢復(fù)，這點(diǎn)與以太坊的異常模型類似，并且這些被恢復(fù)的狀態(tài)不會(huì)在DeltaDB中傳播
· 在發(fā)生異常之前訪問(wèn)的所有活躍狀態(tài)都會(huì)有租金支付，因此這些狀態(tài)會(huì)在DeltaDB中傳播
· 如果活躍狀態(tài)被修改了并且實(shí)際執(zhí)行過(guò)程中從未讀取過(guò)該狀態(tài)，則狀態(tài)不會(huì)有租金支付，因此也不會(huì)在DeltaDB中傳播。如果執(zhí)行沒(méi)有以異常結(jié)束，則將傳播修改后的新?tīng)顟B(tài)
· 如果執(zhí)行附加了喚醒狀態(tài)，則此狀態(tài)會(huì)被標(biāo)記為“已訪問(wèn)”，因此即使在執(zhí)行中出現(xiàn)異常，該狀態(tài)仍會(huì)在DeltaDB中傳播并恢復(fù)。請(qǐng)注意，恢復(fù)狀態(tài)下存在“喚醒稅”，必須在合約執(zhí)行開(kāi)始前支付。如果發(fā)送到賬戶的用于支付喚醒稅的gas數(shù)太少，則將不會(huì)進(jìn)行任何恢復(fù)操作，除了返回表明執(zhí)行失敗的收據(jù)之外，不會(huì)執(zhí)行其他的操作并且所有g(shù)as都會(huì)被消耗掉
· 如果執(zhí)行附加了喚醒狀態(tài)，但該狀態(tài)已經(jīng)處于被喚醒的狀態(tài)，那么這個(gè)已經(jīng)處于喚醒狀態(tài)的狀態(tài)將被忽略，并且也不會(huì)消耗任何gas。這使得那些為確保合約成功執(zhí)行而謹(jǐn)慎地加入即將到期的喚醒狀態(tài)的人不必支付成本。附加的休眠狀態(tài)將被喚醒并需支付喚醒稅
· 在上述這些被附加的狀態(tài)已經(jīng)處于喚醒狀態(tài)的情況下，該狀態(tài)會(huì)被認(rèn)為是已訪問(wèn)的，因此會(huì)在DeltaDB中傳播并且INDEX_TAX + PROP_TAX將按狀態(tài)鍵收費(fèi)
這種隱性租金支付和異常設(shè)計(jì)方案意味著大多數(shù)合約完全不需要擔(dān)心租賃機(jī)制的正常運(yùn)作。但是，對(duì)于那些需要對(duì)租賃機(jī)制有一些自我意識(shí)的合約，則需要添加一些額外的系統(tǒng)接口：
uint32_t remainingRent(uint8_t * key，size_t keylen); -- 針對(duì)區(qū)塊而言，將返回特定狀態(tài)鍵所需支付的剩余租金。如果狀態(tài)處于休眠狀態(tài)或尚未寫(xiě)入，則返回0
uint32_t remainingExternalRent(UniversalAddressABI * target，uint8_t * key，size_t keylen); -- 與remainingRent方法的行為相同，但作用于外部合約
uint32_t remainingExternalBytecodeRent(UniversalAddressABI * target); -- 與remainingExternalRent方法的行為相同，但該方法會(huì)檢查外部合約的字節(jié)碼而不是狀態(tài)鍵。請(qǐng)注意，不需要內(nèi)部版本，因?yàn)橥ㄟ^(guò)執(zhí)行合約的行為，剩余的租金將始終是RENT_TERM
uint32_t BlockData-> RENT_TERM -- 這是一個(gè)區(qū)塊常量(可能之后會(huì)由DGP修改)，其最大租期為
GAS模型
當(dāng)前Qtum-x86虛擬機(jī)中用于存儲(chǔ)的gas模型設(shè)計(jì)還沒(méi)有完全實(shí)現(xiàn)，不然要是實(shí)現(xiàn)了的話，本提議將完全地改變它。所以，現(xiàn)在最好是暫時(shí)放下手中的設(shè)計(jì)工作。
定義：
PROP_TAX -- 對(duì)任何添加到DeltaDB樹(shù)的傳播收取的稅費(fèi)
READ_TAX(size) -- 從節(jié)點(diǎn)數(shù)據(jù)庫(kù)讀取狀態(tài)所收取的稅費(fèi)。這個(gè)開(kāi)銷不是固定不變的，可能是由最小成本加上一定長(zhǎng)度后的每字節(jié)成本構(gòu)成。這會(huì)對(duì)存儲(chǔ)開(kāi)銷產(chǎn)生影響，例如將數(shù)據(jù)復(fù)制到VM內(nèi)存中
EXEC_TAX -- 為了執(zhí)行合約而初始化一個(gè)新的VM實(shí)例所收取的稅費(fèi)
SHORT_READ_TAX(size) -- 當(dāng)前執(zhí)行中讀取先前從數(shù)據(jù)庫(kù)讀取的狀態(tài)所收取的稅費(fèi)。其他方面與READ_TAX類似
INDEX_TAX(key_size) -- 對(duì)數(shù)據(jù)庫(kù)中數(shù)據(jù)建立索引收取的稅費(fèi)。這設(shè)計(jì)的相對(duì)便宜，并且包括了在需要時(shí)對(duì)密鑰進(jìn)行哈希的成本
WRITE_TAX(size) -- 將狀態(tài)寫(xiě)入數(shù)據(jù)庫(kù)而收取的稅費(fèi)
EXTERNAL_TAX -- 訪問(wèn)外部賬戶狀態(tài)的一小筆額外稅費(fèi)
LIBEXEC_COST -- 執(zhí)行任何可信庫(kù)合約的固定成本。請(qǐng)注意，為防止濫用，可信庫(kù)合約的大小存在嚴(yán)格限制
STORE_REFUND(size) -- 假設(shè)狀態(tài)減少為0，則因修改狀態(tài)而給予的退款
DIRTY_STORE_REFUND(old_size) -- 與STORE_REFUND類似，但如果狀態(tài)減少為0并且它是在當(dāng)前執(zhí)行中創(chuàng)建的(即，它從未寫(xiě)入數(shù)據(jù)庫(kù))，則返回一筆更大金額的退款
PROP_REFUND -- 如果狀態(tài)在執(zhí)行開(kāi)始時(shí)未建立，而在執(zhí)行期間建立，且在執(zhí)行完成之前減少到0，則給予退款，這意味著不需要進(jìn)行傳播。這只適用于以null狀態(tài)作為開(kāi)始狀態(tài)和結(jié)束狀態(tài)的修改。即，如果狀態(tài)切換過(guò)程為“abc” - > 0 - >“abc”，則仍將收取PROP_TAX的費(fèi)用，但如果狀態(tài)切換過(guò)程為0 - >“abc” - >“xyz” - > 0，則將會(huì)退款
CLEANING_REFUND(size) -- 這是額外的退款，用來(lái)激勵(lì)對(duì)存儲(chǔ)進(jìn)行清理。僅在狀態(tài)重置為0時(shí)有效，而在狀態(tài)調(diào)整時(shí)不會(huì)給予退款
WAKE_TAX(size) -- 將狀態(tài)恢復(fù)為“活躍”狀態(tài)的額外開(kāi)銷
SLEEPING_REFUND -- 打破休眠狀態(tài)的固定退款
實(shí)際操作
在閱讀時(shí)請(qǐng)注意：
初始化合約執(zhí)行：PROP_TAX + READ_TAX(size)+ EXEC_TAX
首次執(zhí)行外部合約：PROP_TAX + READ_TAX(size)+ EXEC_TAX + EXTERNAL_TAX
第二次執(zhí)行外部合約：SHORT_READ_TAX(size)+ EXEC_TAX + EXTERNAL_TAX
遞歸地執(zhí)行合約：SHORT_READ_TAX(size)+ EXEC_TAX
合約自我銷毀：PROP_TAX + STORE_REFUND(size)+ CLEANING_REFUND(size)
內(nèi)部首次大小檢查：PROP_TAX + INDEX_TAX(key_size) - 這可用于強(qiáng)制支付(便宜的)租金而不用將狀態(tài)實(shí)際讀入內(nèi)存;當(dāng)前這只是讀取一個(gè)0字節(jié)長(zhǎng)的狀態(tài)。(狀態(tài)讀取通常返回?cái)?shù)據(jù)的實(shí)際大小)
外部首次大小檢查：PROP_TAX + INDEX_TAX(key_size)+ EXTERNAL_TAX
內(nèi)部第二次大小檢查：INDEX_TAX(key_size) -- 這里的第二次表示發(fā)生在先前的大小檢查或狀態(tài)讀取之后
外部第二次大小檢查：INDEX_TAX(key_size)+ EXTERNAL_TAX
內(nèi)部首次讀?。篜ROP_TAX + READ_TAX(size)+ INDEX_TAX(key_size)
內(nèi)部第二次讀取：SHORT_READ_TAX(size)+ INDEX_TAX(key_size) -- 讀取在同一執(zhí)行過(guò)程中寫(xiě)入的狀態(tài)
首次寫(xiě)入新?tīng)顟B(tài)：PROP_TAX + WRITE_TAX(size)+ INDEX_TAX(key_size)
首次寫(xiě)入新?tīng)顟B(tài)，設(shè)置為0：INDEX_TAX(key_size) - 這是一個(gè)空操作，所以正常情況下不應(yīng)該執(zhí)行
第二次寫(xiě)入新?tīng)顟B(tài)：WRITE_TAX(size)+ STORE_REFUND(size)+ INDEX_TAX(key_size)
第二次寫(xiě)入新?tīng)顟B(tài)，設(shè)置為0：DIRTY_STORE_REFUND(old_size)+ INDEX_TAX(key_size)+ PROP_REFUND
首次寫(xiě)入現(xiàn)有狀態(tài)：PROP_TAX + WRITE_TAX(size)+ STORE_REFUND(old_size)+ INDEX_TAX(key_size)
首次寫(xiě)入現(xiàn)有狀態(tài)，設(shè)置為0：PROP_TAX + STORE_REFUND(old_size)+ INDEX_TAX(key_size)+ CLEANING_REFUND(size)
第二次寫(xiě)入現(xiàn)有狀態(tài)：WRITE_TAX(size)+ STORE_REFUND(old_size)+ INDEX_TAX(key_size)
第二次寫(xiě)入現(xiàn)有狀態(tài)，設(shè)置為0：PROP_TAX + STORE_REFUND(old_size)+ INDEX_TAX(key_size)+ CLEANING_REFUND(size) - 與首次寫(xiě)入相同
第二次寫(xiě)入先前在第一次寫(xiě)入時(shí)設(shè)置為0的現(xiàn)有狀態(tài)：WRITE_TAX(大小)+ INDEX_TAX(key_size) - 基本上與正常的第二次寫(xiě)入相同
首次寫(xiě)入休眠狀態(tài)：PROP_TAX + WRITE_TAX(size)+ INDEX_TAX(key_size) - 請(qǐng)注意，在這種情況下，減少數(shù)據(jù)無(wú)法給與退款，但WAKE_TAX預(yù)期會(huì)高于退款金額。另請(qǐng)注意，第二次寫(xiě)入與寫(xiě)入正常的現(xiàn)有(臟)狀態(tài)相同
首次寫(xiě)入休眠狀態(tài)，設(shè)置為0：PROP_TAX + INDEX_TAX(key_size)+ SLEEPING_REFUND - 理論上這應(yīng)該與平均鍵大小(小于32字節(jié))四舍五入后的值相抵消
注意：在第一次寫(xiě)入之后，休眠狀態(tài)在設(shè)置為0、調(diào)整大小等方面會(huì)被視為與其他狀態(tài)的行為相同
外部首次讀?。篜ROP_TAX + READ_TAX(size)+ INDEX_TAX(key_size)+ EXTERNAL_TAX
外部第二次讀?。篠HORT_READ_TAX(size)+ INDEX_TAX(key_size)+ EXTERNAL_TAX
獨(dú)立代碼執(zhí)行：EXEC_TAX - “獨(dú)立”執(zhí)行只是一段UTXO中的代碼，執(zhí)行一次而不對(duì)狀態(tài)進(jìn)行存儲(chǔ)，因此除了執(zhí)行之外沒(méi)有任何其他成本
休眠狀態(tài)的預(yù)執(zhí)行恢復(fù)：WAKE_TAX(size)+ INDEX_TAX(size)+ PROP_TAX - 請(qǐng)注意，這是在執(zhí)行原始合約之前發(fā)生的
注意：恢復(fù)休眠狀態(tài)后，所有g(shù)as成本與正常的活躍狀態(tài)的存儲(chǔ)相同
可信庫(kù)執(zhí)行：PROP_TAX + LIBEXEC_COST - 這顯然不會(huì)帶來(lái)每字節(jié)長(zhǎng)度的開(kāi)銷。除了實(shí)際執(zhí)行代碼所需的gas成本之外，該執(zhí)行的成本是固定的。這是為了使可信庫(kù)執(zhí)行更具可預(yù)測(cè)性
注意：代表合約的所有受信任庫(kù)讀/寫(xiě)與正常的合約執(zhí)行相同，不會(huì)帶來(lái)EXTERNAL_TAX
雖然這個(gè)操作列表看起來(lái)非常大，但實(shí)際上它是非常公式化的，并且在代碼的實(shí)現(xiàn)過(guò)程中不會(huì)太難。它是非常有規(guī)則的，應(yīng)該只需要處理很少的邊界情況。上面定義的每個(gè)常量或方法應(yīng)該是不言自明的，并且應(yīng)該考慮到節(jié)點(diǎn)和更大網(wǎng)絡(luò)所需的所有成本。
這種方法的一些風(fēng)險(xiǎn)在于退款必須是保守的，以避免出現(xiàn)下面這種投機(jī)取巧的情況：例如，先將數(shù)據(jù)寫(xiě)入狀態(tài)，然后將狀態(tài)修改為較小的大小，而不是在開(kāi)始簡(jiǎn)單地就寫(xiě)入較小的狀態(tài)。退款行為與以太坊不同，執(zhí)行操作后的任何剩余的gas都會(huì)被發(fā)送回收款人，其中數(shù)量不超過(guò)發(fā)送給合約的總gas數(shù)。如果允許發(fā)送回多于合約中發(fā)送的gas數(shù)，那么可以人為地利用高的gas價(jià)格輸出Qtum，從而以比初始支付時(shí)更高的gas價(jià)格進(jìn)行退款。
AAL賬戶抽象層修改
為了適當(dāng)?shù)匦藜艉霞s交易中的無(wú)關(guān)數(shù)據(jù)，所有的合約執(zhí)行和交易創(chuàng)建都將經(jīng)由AAL支出并進(jìn)行壓縮。這也會(huì)極大地簡(jiǎn)化將來(lái)其他的QIPs，例如基于UTXO模型的“一次性擁有”狀態(tài)的提案。目前，合約執(zhí)行僅在執(zhí)行中的資金實(shí)際用于智能合約時(shí)才由AAL支出。此外，合約創(chuàng)建交易僅在合約自毀時(shí)花費(fèi)。這允許SPV節(jié)點(diǎn)利用一些額外的功能來(lái)跟蹤合約行為，但這會(huì)以在 UTXO集中保留重復(fù)且不太相關(guān)的數(shù)據(jù)為代價(jià)。DeltaDB中的SPV目標(biāo)訪問(wèn)和跟蹤方法將有效地取代此功能。
新的節(jié)點(diǎn)分類
目前，Qtum生態(tài)系統(tǒng)中有三種主要類型的節(jié)點(diǎn)：
1. 存檔節(jié)點(diǎn) ：該類節(jié)點(diǎn)包含整個(gè)區(qū)塊鏈的數(shù)據(jù)。UTXO集被修剪至不包含重復(fù)數(shù)據(jù)，但所有已花費(fèi)的交易數(shù)據(jù)會(huì)保存在磁盤上，數(shù)據(jù)存取較慢。該類節(jié)點(diǎn)可用于任何用例，包括委托，常規(guī)錢包，歷史數(shù)據(jù)分析，開(kāi)發(fā)等。
2. 修剪的全節(jié)點(diǎn)： 該類節(jié)點(diǎn)類似于一個(gè)全節(jié)點(diǎn)，會(huì)下載并驗(yàn)證整個(gè)區(qū)塊鏈，但會(huì)刪除那些可證明不被使用的數(shù)據(jù)。特別地，這包括已花費(fèi)的交易數(shù)據(jù)以及舊的區(qū)塊數(shù)據(jù)。除歷史數(shù)據(jù)分析外，該節(jié)點(diǎn)能夠處理全節(jié)點(diǎn)的所有用例。
3. SPV節(jié)點(diǎn) ：這種類型的節(jié)點(diǎn)通過(guò)按需下載與當(dāng)前錢包“相關(guān)”的數(shù)據(jù)以及整個(gè)區(qū)塊鏈的區(qū)塊頭來(lái)進(jìn)行驗(yàn)證和證明。該類節(jié)點(diǎn)是非常輕量級(jí)的，通常用于移動(dòng)設(shè)備和“快速同步”的錢包。節(jié)點(diǎn)是去中心化的，但會(huì)受審查的影響，因?yàn)闊o(wú)法證明它所連接的全節(jié)點(diǎn)是否具有應(yīng)該存在的數(shù)據(jù)。通常認(rèn)為這種最終的安全性是穩(wěn)定的，但容易受到女巫攻擊。這種類型的節(jié)點(diǎn)通常僅可用于錢包和一些有限類型的智能合約的開(kāi)發(fā)。值得注意的是，它不能用于委托。
基于本提案提出的新功能和可證明的行為，提出了一種新的節(jié)點(diǎn)分類方案：快速開(kāi)發(fā)節(jié)點(diǎn)。該類節(jié)點(diǎn)使用了SPV節(jié)點(diǎn)的通用安全范例，并且初始時(shí)需要下載以下數(shù)據(jù)：
· 使用最佳區(qū)塊狀態(tài)樹(shù)根節(jié)點(diǎn)的完整EVM數(shù)據(jù)(這是無(wú)法避免的)
· 區(qū)塊鏈的所有區(qū)塊頭(與SPV相同)
· DeltaDB證明以及那些最近RENT_PERIOD區(qū)塊的數(shù)據(jù)(根據(jù)區(qū)塊頭的DeltaDBRoot進(jìn)行驗(yàn)證)。修改后的數(shù)據(jù)可以在處理時(shí)進(jìn)行修剪
· 相關(guān)的UTXOs和當(dāng)前受控錢包的證明(與SPV相同)
按需下載的數(shù)據(jù)包括：
1. 為新區(qū)塊委托UTXO
2. 用于證明UTXO存在性的UTXO證明(即區(qū)塊哈希和merkle路徑)，然后接受區(qū)塊將其作為委托花費(fèi)
3. 需要已花費(fèi)的用于委托UTXO的UTXOs的證明(與SPV節(jié)點(diǎn)相同)
4. 需要已花費(fèi)且為相關(guān)地址創(chuàng)建的UTXOs的證明(與SPV節(jié)點(diǎn)相同)
5. 需要與合約交互并跟蹤RENT_PERIOD內(nèi)的DeltaDB狀態(tài)變化的交易(不僅僅是UTXO)。交易數(shù)據(jù)在執(zhí)行后被修剪，只留下DeltaDB跟蹤數(shù)據(jù)
6. 正在進(jìn)行的區(qū)塊頭下載
對(duì)于委托和安全性這類關(guān)鍵目的而言，這種方案并不是安全的，因?yàn)樗暮诵陌踩匀匀皇怯蒘PV保證的。然而，對(duì)于智能合約開(kāi)發(fā)而言這已經(jīng)完全足夠了，同時(shí)也可作為SPV節(jié)點(diǎn)的一個(gè)功能更強(qiáng)大的版本。歷史合約執(zhí)行可以忽略，但進(jìn)行中的新合約執(zhí)行可以完全地被執(zhí)行和跟蹤。最初的同步過(guò)程只會(huì)比SPV慢一點(diǎn)，主要是因?yàn)樾枰螺d完整的EVM和修剪的DeltaDB數(shù)據(jù)。帶寬成本也只比SPV節(jié)點(diǎn)略高，主要用于完整地下載智能合約執(zhí)行所涉及到的所有交易。
原理
這種特定的租賃實(shí)現(xiàn)方式不同于現(xiàn)有的已提出的大多數(shù)方案。這其中一個(gè)最大的擔(dān)憂是，智能合約本身已經(jīng)相當(dāng)復(fù)雜了，租賃方案所帶來(lái)的額外的復(fù)雜性會(huì)大大增加智能合約代碼中的問(wèn)題和漏洞利用的可能性。該提案以一種不同的方式利用DeltaDB的特性從而使租賃系統(tǒng)對(duì)生態(tài)系統(tǒng)有益，而在大多數(shù)情況下不需要任何額外的智能合約邏輯。
此外，該提案的一個(gè)重點(diǎn)是將節(jié)點(diǎn)達(dá)成共識(shí)的所需和其他內(nèi)容分離開(kāi)來(lái)。將那些很少訪問(wèn)且永遠(yuǎn)不會(huì)更新的數(shù)據(jù)上鏈?zhǔn)峭耆梢越邮艿?，但這些數(shù)據(jù)對(duì)節(jié)點(diǎn)而言應(yīng)該是無(wú)關(guān)的。當(dāng)然，仍然可以證明數(shù)據(jù)在某個(gè)區(qū)塊高度時(shí)在區(qū)塊鏈上的存在性，但是，預(yù)計(jì)它不會(huì)被網(wǎng)絡(luò)上的大多數(shù)節(jié)點(diǎn)直接存儲(chǔ)和訪問(wèn)。
這種證明可以在不消耗任何會(huì)帶來(lái)gas開(kāi)銷的區(qū)塊鏈資源的情況下完成。此類歷史數(shù)據(jù)可以轉(zhuǎn)移到歸檔節(jié)點(diǎn)上。對(duì)于僅需要訪問(wèn)某個(gè)智能合約的休眠數(shù)據(jù)的應(yīng)用程序，可以使用部分歸檔節(jié)點(diǎn)。這基本上是一個(gè)標(biāo)準(zhǔn)的修剪節(jié)點(diǎn)，但它會(huì)存儲(chǔ)相關(guān)智能合約的完整歷史數(shù)據(jù)。
策略
這將在Qtum-x86的初始版本中實(shí)現(xiàn)。在發(fā)布后更改該存儲(chǔ)模型是非常困難的，因此，在已經(jīng)實(shí)現(xiàn)的情況下推出Qtum-x86是有很大好處的。
待實(shí)現(xiàn)
· 需要計(jì)算不同的RENT_TERM值的理論上的數(shù)據(jù)上限
· 需要計(jì)算對(duì)于一個(gè)合約執(zhí)行的完整區(qū)塊而言，DeltaDB merkle樹(shù)的大小，以及一個(gè)典型的區(qū)塊
· 這并不能完全消除對(duì)存儲(chǔ)所有數(shù)據(jù)的“歸檔節(jié)點(diǎn)”的需求。為了無(wú)信任地同步一個(gè)全節(jié)點(diǎn)，仍然必須且/或需要從區(qū)塊數(shù)據(jù)重建所有的“休眠”數(shù)據(jù)，以便證明區(qū)塊鏈的當(dāng)前狀態(tài)是有效的。
為了實(shí)現(xiàn)更好的區(qū)塊鏈技術(shù)與互信商業(yè)之間的橋梁，Qtum量子鏈不斷在努力，持續(xù)的技術(shù)更新迭代和提出新的可實(shí)現(xiàn)的技術(shù)思考。（Qtum）
