[[387427]]

本文轉載自微信公眾號「區塊鏈研究實驗室」，作者鏈三豐。轉載本文請聯系區塊鏈研究實驗室公眾號。   

區塊鏈不僅是一個流行詞。它也不限于加密貨幣和比特幣。憑借其創造透明度和公平性的能力，這項技術正在革新各個領域。應用范圍從跟蹤系統到保護數據，再到執行在線投票系統。它可以幫助實施反洗錢跟蹤系統，或者簡單地跟蹤您在商店購買的產品的來源。

就像信息科學中經常發生的那樣，許多區塊鏈平臺管理著所有的復雜性，使我們可以像保存一個簡單的數據庫一樣簡單地保存數據。

在本文中，我想實現一個區塊鏈數據庫，以了解此類解決方案的關鍵要素。而且，為了使其更具挑戰性，我將在不使用任何數據庫或服務器的情況下做到這一點。

該解決方案可以輕松地使您擁有可以驗證并安全存儲的不可變數據。

這篇文章的結構如下：

• 什么是區塊鏈數據庫及其使用方式
• 如何僅使用DNS服務來實現區塊鏈

什么是區塊鏈數據庫以及如何使用

像往常一樣，我們可以從Wikipedia定義開始：

“A blockchain，[ ...]，是一個越來越多的記錄，稱為塊，正在使用鏈接加密。每個塊都包含前一個塊的加密哈希，即時間戳[..]。通過設計，區塊鏈可以抵抗其數據的修改。這是因為一旦記錄，任何給定塊中的數據都不能追溯更改，而無需更改所有后續塊。

“對于用作分布式總賬，一個blockchain通常由管理對等網絡的網絡共同地粘附到協議用于節點間通信和驗證新塊”。

換句話說，區塊鏈的主要特征是：

• 通過將一條記錄連接到上一條記錄來存儲數據
• 做到這一點，因此您不能在不使所有數據順序不一致的情況下更改一條記錄
• 將數據存儲在分布式數據庫中

那么，如何創建呢?

我想的是，一個節點的鏈或多或少是一個鏈表，其中每個塊都有一個不可變的哈希。完成此操作后，您只需要一個安全的分布式數據庫即可存儲數據。什么是古老的分布式數據庫?好吧，每個人都有一個分布式數據庫，沒人知道!我說的是DNS。是的，它是分布式的，它存儲數據。每個人都有一個DNS服務。我意識到這不是預期的用途，但讓我們一起玩吧。

該協議的工作流程是受信任的機構將數據寫入DNS。每個記錄都有一個唯一的鍵，該鍵是內容的哈希值。這意味著，通過更改數據，您將更改ID，并且指向該ID的所有子代都將不一致。此外，DNS協議是分布式的，因此許多服務器之間共享數據的許多副本，這意味著您的一個DNS將脫機，而另一個將繼續為數據提供服務。還請考慮DNS被廣泛緩存，這使您的通信性能高(使用不可變數據緩存永遠不會成為問題)。

該系統使用所有公司都已經擁有的DNS作為存儲，因此無需任何額外費用。DNS本身是一個分布式數據庫。

現在我們已經定義了存儲數據的位置，我們只需要了解如何存儲數據即可。下一步是定義一個通信協議，使所有各方都可以扮演自己的角色。下圖顯示了流程。

DNS區塊鏈工作流程。

在上圖中，我們有：

• 在DNS上發布的推力實體。它是寫作的關鍵-其他人可以寫記錄，但是它們是無法理解的。
• 一個消費者，即推力生產者和讀取數據
• 數據，其 可以是任何JSON數據。您可以選擇將其公開或不公開。

如何實施

現在我們知道該怎么做，并且已經有了啟動該工具的工具，我們只需要使用源代碼即可。

為了使用DNS實現區塊鏈，我們必須面對一些重要問題：

• DNS限制-DNS并非旨在存儲大數據。我們想使用TXT記錄，但是它們只有254個字符。如果我們要存儲一個大的JSON對象，這是一個很大的限制。
• 安全性-即使我們想保持數據公開，DNS使用的UDP協議也存在問題。它沒有經過加密，并且沒有像HTTPS協議中那樣可以推動授權的證書機制。
• 數據是按設計公開的—這可能是一個問題。

所有這些方面都有一個解決方案，并且您將看到，它很容易實現。實際上，通過使用加密技術和獨創性，我們將為上述所有問題找到一個明智的解決方案。

讓我們看看它是如何工作的。

創建沙盒環境

第一步是創建一個我們想玩的沙盒環境。我們需要啟動該工作的是帶有API系統的本地DNS服務器。我們通過創建一個托管該文件的docker-compose文件來實現這一目標。我使用了一個Visual Studio項目，在其中創建了一個我們將用于驗證數據的Web應用程序，一個將成為我們核心的庫以及一個測試項目。結果如下：

DNS區塊鏈項目

通過運行docker-compose up，所有啟動并準備好進行測試。對于DNS部分，我使用了非常輕巧且具有HTTP API可用的DNS。它使用以下配置運行：

version: '3.4' 
services: 
  blockchaindns.web: 
    image: ${DOCKER_REGISTRY-}blockchaindnsweb 
    build: 
      context: . 
      dockerfile: BlockChainDNS.Web/Dockerfile 
  dns: 
    image: tgpfeiffer/shaman-dns   
    command: shaman --server --token xxx --api-listen 0.0.0.0:1632 --dns-listen 0.0.0.0:53 -l trace --insecure   
    ports: 
      - 1632:1632 
      - 53:53/udp 

這里xxx是您要用于身份驗證的令牌，并且DNS已配置為接受來自所有主機的請求(0.0.0.0:port)。

使用運行它之后docker-compose up，您可以使用控制臺對其進行測試：

#create a record in Shaman DNS 
curl --location --request POST 'localhost:1632/records' \ 
--header 'Content-Type: application/json' \ 
--data-raw '{ 
  "domain": "test.myfakedomain.it.", 
  "records": [ 
    { 
      "ttl": 60, 
      "class": "IN", 
      "type": "A", 
      "address": "127.0.0.1" 
    } 
  ] 
}' 
#test the record 
nslookup test.myfakedomain.it 127.0.0.1 
#output 
# Server:  UnKnown 
# Address:  127.0.0.1 
# Response from server: 
# Nome:    test.myfakedomain.it 
# Address:  127.0.0.1 

現在我們有了一個可以正常工作的本地DNS，我們可以創建一個可以通過API管理DNS記錄的客戶端。

DNS客戶端

第二步是包裝要在應用程序中使用的DNS客戶端功能。我想在這里做的是將來有能力更改DNS服務，因此我創建了一個接口和一個類實現。以下代碼片段顯示了該界面：

public interface IDNSClient 
{ 
  Task<DNSEntry> GetRecord(string host, string zone); 
  Task<bool> AddRecord(DNSEntry entry); 
  Action Init { get; set; } 
} 

如您所見，客戶端實現執行HTTP調用來存儲記錄。您可以在本文末尾的GitHub項目中找到完整的類實現。我們僅為薩滿實施了本地提供商，但很容易對其進行擴展以支持大多數現代托管提供商上的任何商業DNS。

區塊鏈服務

現在我們已經有了執行部分，是時候實現業務邏輯了。所有工作都在客戶端完成，客戶端將計算要存儲的數據并調用DNS客戶端方法以保留記錄。服務層由兩部分組成：

• BlockChainNode：節點的表示形式
• BlockChainService：實現邏輯的服務

讓我們詳細了解這些類如何工作。

區塊鏈節點

這是帶有JObject屬性的簡單類，用戶可以在其中存儲任何數據。它計算密鑰哈希數據。數據包含歷史記錄，該歷史記錄是到父項的鏈接。僅更改數據的字節將更改密鑰，這將導致以下節點不一致。以下代碼顯示了該類最重要的部分。

public class BlockChainNode 
    { 
 
        public BlockChainNode() 
        { 
 
            this.History.CollectionChanged += History_CollectionChanged; 
        } 
 
        private void History_CollectionChanged(object sender, System.Collections.Specialized.NotifyCollectionChangedEventArgs e) 
        { 
            this.Data["_history"] = JArray.FromObject(this.History); 
        } 
 
 
        private JObject _data = new JObject(); 
        public JObject Data 
        { 
            get { return _data; } 
            set { _data = value; History_CollectionChanged(null, null); } 
        } 
 
 
 
        public string Hash { get 
            { 
                return GetHash(this.ToBase64()); 
            } 
        }  
 
 
 
        public ObservableCollection<string> History { get; set; } = new ObservableCollection<string>();//First to last 
 
        public string ToBase64() 
        { 
            var content = UnicodeEncoding.Unicode.GetBytes(Data.ToString(Formatting.None)); 
 
            return Convert.ToBase64String(content); 
        } 
 
 
        public static string GetHash(string text) 
        { 
            using (var md5 = MD5.Create()) 
            { 
                return Base32.ToBase32String(md5.ComputeHash(UTF8Encoding.UTF8.GetBytes(text))).ToLower();                 
            } 
        } 
    } 

該代碼最相關的部分是：

• 數據對象：用戶可以在其中存儲數據的JSON對象
• 歷史記錄：與數據同步的可觀察列表(“歷史記錄”中的任何更改都會更改_history節點，反之亦然。)
• 哈希：根據數據的文本表示形式的MD5計算得出的哈希。結果以Base32算法編碼-類似于Base 64，但僅使用四個字節且僅包含小寫字符。這是因為DNS不區分大小寫，并且使用廣泛使用的Base64編碼產生了不一致的數據。

現在我們有了模型，我們必須繼續下一步：由服務實現的業務邏輯。

區塊鏈服務

區塊鏈服務實現用于保存，讀取和驗證記錄的方法。困難的部分是要解決DNS服務器記錄長度的255個字符的限制。解決方案是在Base64中對內容進行編碼，然后使用命名約定將其拆分成塊保存在不同的記錄中。密鑰用作URL的一部分。因此，對于該項目mykey.domain.dom，我們將有0.mykey.domain.dom，1.mykey.domain.dom等下一段代碼顯示了節能方法。

private int WriteDNSFragmentedText(string baseUrl, string value, int size) 
{ 
    var tokens = Tokenize(value, size).ToList(); 
    int i = 0; 
    foreach (var token in tokens) 
    { 
        WriteDNSRecord($"{i}.{baseUrl}", "TXT", token); 
        i++; 
    } 
    return i ; 
} 
 
private void WriteDNSRecord(string domain, string type, string value) 
{ 
    this.client.AddRecord(new DNSEntry() 
    { 
        Domain = domain, 
        Type = type, 
        Value = value 
    }); 
} 

從上一個調用的片段中可以看到WriteDNSFragmentedText，輸入文本被拆分，數據被保存在許多DNS條目中。

讀取數據是相反的。我嘗試獲取子記錄0,1,2，依此類推，直到有數據為止。一旦我收集了所有Base64塊，過程就是將它們連接，解碼并獲取純JSON。

private string ReadDNSFragmentedText(string domain) 
{ 
    List<string> fragments = new List<string>(); 
 
    for (int i = 0; i < 1000; i++)  
    { 
        var fragmentUrl = $"{i}.{domain}"; 
 
        var result = ReadDNSTxtResult(fragmentUrl); 
        if (result == null) break;// otherwise parent domain value will be added 
        fragments.Add(result); 
    } 
 
    return string.Join("", fragments); 
} 
 
private string ReadDNSTxtResult(string fragmentUrl) 
{ 
    if (!fragmentUrl.EndsWith(".")) 
    { 
        fragmentUrl = fragmentUrl + "."; 
    } 
    var result = lookup.QueryAsync(fragmentUrl, QueryType.TXT).Result; 
    if (result != null && !result.HasError && result.Answers?.Count > 0 ) 
    { 
        var resultDomain = result.Answers.FirstOrDefault().DomainName.Value; 
        if (resultDomain == fragmentUrl) 
        { 
          return result.Answers.TxtRecords().FirstOrDefault()?.EscapedText.FirstOrDefault(); 
        } 
    } 
    return null; 
} 

客戶端可以輕松地驗證所獲取的數據是否生成密鑰并且是否有效，因為客戶端可以獲取數據，哈希并比較結果。此外，客戶端可以遞歸驗證以檢查所有父節點是否都是真實的。這就是驗證過程所要做的。它由下一部分代碼表示：

public List<string> Validate(JObject data, string key, int db, string domain, byte[] privateKey, string expectedKey = null) 
{ 
    var errors = new List<string>(); 
    //ValidateBase: Coherence betweeen data and values. 
    var computed = this.Get(key, db, domain, privateKey); 
 
    if (key != computed.Hash) 
    { 
        errors.Add("Key mismatch"); 
    } 
 
    ValidateHierarchy(key,db,domain,privateKey, ref errors); 
    return errors; 
} 
 
private List<string> ValidateHierarchy(string  key,   int db, string domain, byte[] privateKey, ref List<string> errors) 
{ 
    var computed = this.Get(key, db, domain, privateKey); 
    if (computed == null) return new List<string>(); 
 
    if (computed.History.Count > 0) 
    { 
        var hierarchy = ValidateHierarchy(computed.History.Last(), db, domain, privateKey, ref errors); 
        if (hierarchy.Count != computed.History.Count-1) 
        { 
            errors.Add($"{computed.Hash}: history count not match with lookup"); 
        } 
        else 
        { 
            for (int i = 0; i< hierarchy.Count; i++) 
            { 
                if (hierarchy[i] != computed.History[i]) 
                { 
                    errors.Add($"{computed.Hash}: history do not match at {computed.History[i]}"); 
                } 
            } 
        } 
 
    } 
 
    return computed.History.ToList(); 
} 

如您在上一個片段中看到的那樣，將驗證記錄，然后下載所有層次結構并檢查數據一致性。

現在我們了解了如何從DNS寫入和讀取數據，下一步是如何確保它們的安全。

密碼學和密鑰

我們的系統可以向DNS讀取和寫入數據，現在該注意安全了。我們假設寫給我們的DNS的人是受信任的，但是我們不能確保惡意的DNS服務器不會給我們偽造數據或有人不會讀取它(請記住，DNS數據是公共的)。

我在這里所做的就是對協議進行了以下改進：使用非對稱算法對存儲的數據進行加密存儲。這樣可以確保只有數據生產者才能生成消費者可以理解的數據。任何人都可以創建偽造的DNS服務器，但是他們將無法對待您偽造數據。而且，數據現在已加密，沒有人可以讀取。

非對稱算法是完美的，因為它只允許一定數量的讀者理解消息，但是只有消息源才能產生消息。為此，客戶端生成一對密鑰。公鑰用于加密數據，因此生產者可以安全地保護它。與使用者共享用于解密的私鑰。可以手動共享它，例如通過電子郵件將其發送到加密的存檔中，或者發布在HTTPS網站上，證書可以在該網站上向用戶展示權限。

順便說一下，這個概念很簡單：現在數據已加密，沒有人可以代表我們寫入數據。但是還有另一個問題。對稱算法只處理少量數據(1024-4096字節)，但我們必須處理巨大的JSON有效負載。我們有兩種方法：

• 將完整的消息分成小字節塊，并一一加密/解密它們。
• 創建一個對稱密鑰，使用生成的密鑰對數據加密，然后使用非對稱對對生成的密鑰進行加密。這樣，每個記錄都具有用于加密數據的不同對稱密鑰。該密鑰是公開共享的，但只有擁有私有密鑰的人才能使用。

考慮到對所有字節塊進行編碼的計算量，我使用了第二種解決方案。這將我們帶到下一個有效負載：

{ 
   "data":"json object encrypted with the symm key", 
   "key":"symm key encripted with the aymm alghorithm" 
} 

在上面的代碼段中，我們可以看到存儲在JSON有效負載中的加密數據和解密密鑰。讀取器將使用私鑰解密對稱密鑰，然后將其用于解密數據。

代碼中的更改是最小的：所需的只是包裝\展開數據的附加步驟。

在下一個代碼段中，我顯示了完成數據生成的步驟：

#generate a one time password 
var password = SHA512.Create().ComputeHash(Guid.NewGuid().ToByteArray()); 
#encrypt the password 
var decriptkey = this.cryptoService.EncodeKey(password, publicKey); 
#encrypt data with the password 
 var dataEnrypted = this.cryptoService.EncryptData(dataToEncode, password); 
#json object is stored with decriptkey and dataEnrypted 

在下一個代碼段中，我們具有閱讀過程：

var decriptKeyEncoded = .. from json 
var dataEncrypted = ... from json    
var decriptKey = this.cryptoService.DecodeKey(decriptKeyEncoded, privateKey);  
 
var decodedData = this.cryptoService.DecodeData(dataEncrypted, decriptKey); 
#decodedData is the plain data. 

既然我們已經完成了有關區塊鏈實現的說明，那么我們就擁有了將數據存儲在DNS區塊鏈中的所有詳細信息。

結論

即使將DNS服務器用作數據庫看起來似乎很聰明，但事實并非如此。DNS并非旨在以這種方式存儲數據。

如果我們必須處理安全的不可變數據，則解決方案是使用標準的區塊鏈平臺，我的意思是需要使用一個真正的區塊鏈系統。

無論如何，嘗試實現無服務器的區塊鏈非常有趣，我希望它教會了我們區塊鏈平臺背后的原理。