一、 輕節點和全節點
每乙個區塊包括區塊頭和區塊體，區塊體內包含著這個區塊中囊括的交易，而區塊頭只需要維護所有交易經過merkle tree計算而得的root hash值就可以了。
輕節點就像我們的手機，只需要維護區塊鏈中區塊頭的資訊。
而全節點需要維護所有區塊中的資訊，大多數全節點是礦機。
當輕節點想要確定這個交易是否在區塊中時，它首先收到交易對手發給它的資料區塊以及路徑節點。
輕節點首先需要驗證，資料區塊中是否存在發生的交易；
其次，輕節點將順著資料區塊，經過路徑節點步步計算得到區塊頭的hash值。注意這裡的hash值很難偽造，這保證了這個方法的可行性。
輕節點收到計算得到的區塊頭中的root hash值與自己維護的區塊頭資訊進行匹配，則完成了驗證。
通過上面的方法，雖然可以驗證交易存在是否合法，但是如果我們想主動驗證某個交易是否存在，該怎麼辦呢？
乙個方法就是窮舉資料塊，可以想象這個過程將消耗很大的計算量。
proof of non-membership提出，在資料區塊構成merkle tree的時候，資料區塊將根據每乙個區塊的hash值進行排列，這樣當我們想驗證某個交易是否存在時，我們對這個交易的資料求hash，然後按照大小進行尋找。當得到這個hash值相鄰的兩個區塊時，我們對其進行merkle proof向上求解，當得到root hash時，證明這個交易確實不存在。
位元幣系統中的全節點和輕節點
在本地硬碟上維護完整的區塊鏈資訊 在記憶體裡維護utxo集合，以便快速檢驗交易的正確性 監聽位元幣網路上的交易資訊，驗證每個交易的合法性 決定哪些交易會被打包到區塊裡 監聽別的礦工挖出來的區塊，驗證其合法性 挖礦 不用儲存整個區塊鏈，只要儲存每個區塊的塊頭 不用儲存全部交易，只儲存與自己相關的交易 ...
驗證控制項與JS驗證同時存在的問題
會員註冊時使用伺服器驗證控制項來驗證輸入的合法性,又在客戶端使用js訪問webservice來驗證會員資訊是否存在,這兩個驗證會發生矛盾,比如email,如果輸入的不合法,則驗證控制項生效,寫出乙個文字提示,而js也進行了驗證,也寫出了乙個提示,這時會有兩個提示同時存在,很影響頁面的邏輯,查閱大量文...
分片之間分割後的驗證節點
分片經常被視為一種可以隨著網路中節點數的增加而無限擴充套件的方案。雖然從理論上看，人們是有可能設計出這種方案的，但任何使用信標鏈概念的方案都不可能無限擴充套件。為了理解其原因，我們要意識到，信標鏈要做一些記賬的計算工作，例如給分片分配驗證節點，或快照分片鏈區塊，而這些都與系統中的分片數量成比例關係。...