（夜晚，梵高）
前言：傳統web應用架構存在安全性問題，為了確保更高程度的安全，企業耗費巨資，不過依然無法從根本上解決問題。而本文作者Daniel Larimer（也就是眾所周知的EOS的BM）則認為要解決這個問題，需要採用區塊鏈的架構來確保資料庫和使用者賬戶的安全，可以防止未經授權的訪問和防篡改，同時可以為採用區塊鏈技術的企業節省費用。BM認為區塊鏈是更好的應用伺服器/資料庫架構，未來會成為很多企業的必備技術，這會是超級大的潛在市場嗎？大家如何看？本文由藍狐筆記的社群“DoTi”翻譯。
傳統的web應用基礎架構在設計時考慮了安全性，並且二十五年來，公司一直在試圖修補根本上存在不安全的體系架構。該架構設計的假設是伺服器可以被信任和保護，但多年的經驗告訴我們，沒有伺服器可以免受外部攻擊，更不用說內部的危險了。換言之，伺服器從根本上是中心化的。
我們曾經把“安全問題”歸結為使用者和伺服器之間的連線，因此，我們引入了SSL和HTTPS。但是，後來我們發現，駭客會破壞資料庫並竊取密碼。因此，我們開始儲存密碼的雜湊值，但接下來我們又發現，在竊取雜湊值後，駭客可以使用暴力破解密碼。隨後，我們引入密碼輪換，這樣在駭客進行暴力破解時，密碼會發生更改。如此這般的攻防，不斷上演。（藍狐筆記：SSL是為網路通訊提供安全的協議，SSL協議位於TCP/IP協議和應用層協議之間，對網路連線進行加密。而HTTPS則是在HTTP的基礎上加入SSL。）
企業花費數十億美元，試圖保護其伺服器和資料庫，儘管付出這些努力，但依然沒有簡單方法來審計系統，且能確保企業按他們的意願執行。
Block.one正在構建區塊鏈軟體以確保資料庫和使用者賬戶的安全，防止未經授權的訪問和未經說明的修改。使用區塊鏈時，使用者採用高度安全的私鑰，這些私鑰儲存在安全硬體，且私鑰用於簽名每個使用者互動，而不是簡單驗證與伺服器的連線。（藍狐筆記：Block.one是開發EOSIO軟體的公司）
區塊鏈建立不可篡改的日誌，它構建絕對和確定性的順序，接收使用者輸入，而智慧合約提供確定性的商業邏輯，以確保所有系統的一致性。
未來的Block.one正在建立消除密碼和昂貴審計的方法，可為公司節省數十億美元，防止身份被竊取，併為所有人提供更高的可靠性和審計能力。我多年來堅定地認為，每個多使用者網站都可以因為採用區塊鏈後端而受益。與流行觀點相反，區塊鏈並不一定是緩慢的低效的資料庫，也不必一定在抗審查和開放訪問的基礎上執行。
即使區塊鏈完全由公司本身運營，且區塊鏈的所有內容都不公開，區塊鏈也能為公司在安全、審計能力、透明度以及業務流程完整性上提供巨大改進。本文旨在闡明區塊鏈在企業環境中的真正價值，併為區塊鏈行業指明前進方向。
常見的誤解
在區塊鏈行業中，很多人的看法是，只有當區塊鏈將彼此不信任的各方連線起來時，區塊鏈才能帶來好處。他們認為，傳統資料庫技術已經可以完成確保業務完整性所需的一切。換句話說，他們認為有了傳統的資料庫複製和“資料完整性”保證就已經足夠。在此過程中，他們要麼忽略要麼不瞭解區塊鏈提供的根本不同的安全性和完整性保證：
對全球時間順序的承諾
業務邏輯的確定性執行
業務邏輯&資料完整性的緊耦合
消除密碼
在傳統的業務應用架構中，業務邏輯跟資料庫是分離的。通常有應用伺服器，例如Node.js或J2EE，其提供了修改資料庫的密碼。Node.js伺服器的作用是透過密碼或多因素身份驗證機制來實現對使用者的驗證。一旦應用伺服器進行使用者身份驗證，它將發起會話令牌，該會話令牌用於驗證未來的使用者互動，直至會話超時或會話（如IP）的某些元素髮生改變為止。
很顯然，這種傳統的設計透過由應用伺服器管理的單個登入名/密碼來執行所有資料庫操作。應用伺服器負責用最終的終端使用來執行其自身的身份驗證方案。同樣，也很顯然，通常有多方可以訪問使用者名稱和密碼。資料庫管理員可以對多個不同的應用伺服器和/或個人分配和撤銷憑證。
先進的系統確保，在水平擴充套件的系統中每個應用伺服器都有其自己的使用者名稱/密碼，且在某些情況下，它甚至可以使用公鑰基礎設施（PKI）和硬體安全模組（HSM）。
然而，即使在這裡，資料庫也僅對與應用伺服器的連線進行驗證。為了提供稽覈日誌，它必須記錄安全連線的整個資料流。然而，即使這個日誌僅記錄應用伺服器請求的“讀取和寫入”，該應用伺服器已經丟失關於原始使用者意圖的所有資訊。
審查這種系統的稽覈員無法知道應用伺服器（如Node.js）是否遵循了正確的業務邏輯且正確驗證了終端使用者。Node.js程序可以將使用者操作“記錄”到資料庫中，便於稽覈員可以嘗試重現相同的計算，但這種記錄本身並非不可篡改，且並不附帶獨立可驗證的身份驗證，無法驗證終端使用者是否實際上授權了其記錄的操作。
可以嘗試記錄每個使用者的連線，但由於使用者經常透過這樣的連線傳輸密碼，因此，這些記錄最終會建立可能會導致洩露使用者身份憑證的蜜罐。（藍狐筆記：蜜罐意為駭客喜歡攻擊的豐盛之地）更負責的系統可能會對這些日誌進行加密，以便只有稽覈員才能讀取。
假設稽覈日誌沒有被篡改，稽覈員必須透過應用邏輯跑出相同的操作序列，以驗證結果資料庫狀態是否匹配。這意味著應用伺服器必須以確定性的方式來實現。
確定性計算是不容易的
儘管寫確定性程式碼看起來“容易”，實際上，所有通用計算機語言都是非確定性的，因為它們允許開發者訪問存在資料庫中的外部資料。這可能是一些簡單的資料，如時間戳、記憶體地址、環境變數、IP地址、或其他更微妙的資料，例如硬體上的浮點行為或雜湊表的插入順序。
在很多情況下，只是簡單地訪問長時間執行的應用伺服器的記憶體中的變數就足以引入不確定性。啟動/停止應用伺服器的實際操作必須被記錄和重現，否則在重放過程中每個本地記憶體訪問都可能是非確定性的。
事實真相是，對於在通用陷阱中受過訓練並積極尋找非確定性的最佳開發者來說，編寫確定性的程式碼是具有挑戰性的。典型的商業應用開發者會發現以確定性方式編寫程式碼很難或不切實際。
如果我們走得更遠，並且假設應用程式碼是確定性的，那麼，應用忠實記錄使用者事件，我們依然還要面臨跟蹤在任何特定時間部署的程式碼版本的挑戰。應用是動態的且頻繁更新的，因此，應用程式碼自身也必須是資料庫狀態的一部分，且其更新必須跟使用者操作一樣以同等的安全性和可審計進行管理和記錄。之後，稽覈員需要所有應用伺服器程式碼的版本的複製，並需要根據每個版本的升級重放使用者輸入（並在過去每次重啟時重啟程式碼）。
即使單個應用伺服器在其實現和部署方面都能夠以確定性的方式執行，它仍然會面臨重大的可擴充套件性問題。應用伺服器僅有一個例項能執行在資料庫上。透過複雜鎖來實現並行訪問，但即便是鎖上的競爭條件也必須被記錄和重現，否則具有不同本地變數的應用邏輯的兩個例項可能會產生非確定性的輸出。
在這一點上，人們可能會試圖完全拋棄確定性，但是，如果缺乏確定性，那麼些許的差異就會隨時間推移而加劇，並最終導致資料集產生巨大差異。稽覈員將被迫使用模糊邏輯和近似匹配，並且每個人將不得不相信這個“模糊邏輯”足夠好。當然，否定編寫和部署確定性程式碼的所有努力的唯一方法是，資料庫管理員直接修改程式碼且神不知鬼不覺。
在某些情況下，使用者輸入日誌和狀態的仔細更新可能會建立出兩個不同的資料庫狀態，每個都透過確定性測試，然而仍具有不同且不可調和的輸出。
例如，假設教授將一位學生的分數F提交到系統，然後該學生透過駭客入侵或賄賂方式進入資料庫，並更改其成績以及教授提交的日誌。
更換密碼
任何關心完整性的多使用者系統的最終目標是確保使用者輸入不會被偽造。使用者名稱/密碼的使用，甚至其他多因素身份驗證（如SMS或谷歌雙重驗證）的使用都依賴於伺服器得出這種結論：密碼匹配或輸入了正確的SMS碼/郵件連結/雙重驗證碼。很顯然，這對於系統的完整性來說是巨大的問題，我會提供一個真實案例，來說明這些系統的嚴重程度。
2016年，我在一個加密交易所的賬戶被駭客入侵，它允許駭客竊取數萬美元價值的比特幣。從我的視角，這種駭客行為先是顯示有一封“密碼重置”的電子郵件傳送到我的電子郵箱，然後另外一封郵件顯示密碼已被成功重置。隨後，收到一封郵件，要求確認提取比特幣（附有程式碼/連結）。最後，收到通知說提現已經完成。
乍一看，似乎是電子郵件被駭客入侵，但考慮到我在電子郵件中採用了多重因素登入，不太不可能被入侵。快速瀏覽我的電子郵件安全頁面顯示，並沒有未經授權的訪問。我知道是因為谷歌記錄並顯示了所有訪問我電子郵件的IP/裝置。
而這其中發生的事情是，攻擊者在郵件抵達我的郵箱之前截獲了交易所傳送的郵件。應用伺服器無法知道郵件已被攔截，因此只是基於攻擊者擁有應用伺服器生成的一次性程式碼，實現密碼重置和提現的授權。
針對SMS或其他任何依賴於非使用者控制私鑰的技術，都可能被相同方法利用。歸根結底，保障使用者賬戶安全的唯一方法是讓所有使用者都採用基於硬體的私鑰作為其登入憑證，並且結合穩健且耗時的過程，以在硬體金鑰丟失時便於安全的重置。
在這一點上，多使用者業務應用現在可以使用使用者私鑰簽名每個使用者請求，將該簽名的請求記錄在資料庫中，並使用確定性程式碼進行處理。即使這樣，也沒有提供人們期望的完整性，因為整個使用者請求依然可以被刪除也有副作用。想象一下，破解警察資料庫並刪除由警察在提交使用者票證時簽署的請求。
說到此處，精明的工程師會聲稱，每個我提出的問題都可以透過改變程式邏輯來解決。他說得沒錯，經驗豐富的應用開發者可以使用“傳統資料庫”、“傳統應用伺服器”以及“通用加密原語”，並構建相對安全和可審計的系統。基於同樣的邏輯，精明的工程師可以聲稱資料庫是完全不必要的，相反，所有內容都應該直接構建在檔案系統上。
而其他工程師可能會指出，可以透過從頭開始編寫所有程式碼來提升效能，而不是依賴於諸如Node.js和J2EE這樣的應用伺服器框架。幾乎所有東西都是由較低層級的技術構建的，我們不妨為實現最佳效能設計電晶體。（藍狐筆記：此處意為這些解決方案的成本極高）
我提出這一極端建議，是因為它突出了更高層級框架在加速和確保新應用開發安全方面的真正作用。很少有人編寫自己的密碼學庫或演算法，而真正編寫的人要麼是專家，要麼是當系統被駭客入侵時充當警戒尾巴。從頭開始開發/重構一切會導致每個應用比基於成熟框架構建的應用成本更高。
區塊鏈應用程式/資料庫伺服器的好處
諸如EOSIO這樣的區塊鏈和開發框架之所以存在，是為了將應用開發者從不得不重新發明“資料庫”以構建安全應用中解放出來。安全性和確定性很難，這就是為什麼將技術構建在抽象細節的層上的原因。
EOSIO在同一程序中將確定性執行環境（WebAssembly）和快速資料庫結合起來。所有使用者操作均由其私鑰簽名，並記錄在複製的分散式的資料庫中，且具有向區塊頭做出公開承諾的能力。
像EOSIO這樣的框架達成傳統系統這般強大和易於開發，只是時間的問題。透過將應用邏輯（Web Assembly）放在與記憶體資料庫相同的處理空間中，EOSIO的體系結構在很多方面已經比傳統系統效能更高。
在未來幾年中，Block.one旨在新增工具和介面，以使得在區塊鏈上部署業務應用跟在傳統業務應用架構上部署應用一樣容易（或更容易）。
顯而易見，區塊鏈技術的採用將會是有責任防止欺詐和進行財務報告的政府機構、上市公司和企業的優先事項。我的看法是，未來不採用區塊鏈技術就像是現在的銀行不採用SSL技術一樣，一旦區塊鏈技術廣泛可用，不採用區塊鏈技術就可能被認為是過失。
今天到了該採取行動的時候了。如果沒有對當今應用構建方式的根本改變，業務和使用者是不安全的。每耽擱一天，業務面臨可能有被欺詐和被駭客入侵的風險。
