寫在前面:本文作者為EOS創始人Daniel Larimer。他在文章中分析了傳統互聯網中的數據庫等基礎架構和設計的缺陷并指出區塊鏈是最好的解決方案:諸如EOSIO之類的區塊鏈開放式框架使得開發者無需為了構建安全的應用程序而重新創建“數據庫”,因為所有用戶使用私鑰對自己的行為簽名,可追溯和查證。未來B1的一個目標是添加工具和接口,促使在區塊鏈上部署業務的過程和傳統互聯網上部署業務相似(甚至更簡單)。
傳統的網頁應用程序基礎結構在設計時將安全性作為事后考慮事項,在過去的25年中,許多公司一直在試圖修補一個根本不安全的架構。這種架構在設計時就預設服務器是可以被信任和保護的,但是多年的經驗告訴我們,沒有服務器是安全的,更不用說內部的攻擊了。換句話說,服務器基本上是中心化的。
我們過去認為“問題”在于用戶和服務器之間的連接,因此我們引入了SSL和HTTPS。但后來我們發現,黑客會破壞數據庫并竊取密碼。所以我們開始存儲密碼的哈希值,但后來我們發現黑客會在盜取哈希值后強行破解密碼。然后,我們引入了密碼切換機制,以便在暴力破解時更改密碼,諸如此類的措施還有很多。
為了保護服務器和數據庫,企業需要花費數十億美元,盡管付出了所有努力,但仍然沒有簡單的方法來審查系統并確保企業按預期運行。
動態 | 跨ETH/EOS/TRON/IOST四大公鏈,DApp活躍度排行榜:據 DAppTotal 06月10日數據顯示,過去一周,綜合對比ETH、EOS、TRON、IOST四大公鏈的DApp生態情況發現:總用戶量(個): EOS(152,963) > ETH(98,813) > TRON(79,467) > IOST(15,929);總交易次數(筆):EOS(29,280,520) > TRON(4,895,991) > IOST(2,449,554) > ETH(537,537);總交易額(美元):EOS(118,441,801) > TRON(74,270,061) > ETH(36,520,987) > IOST(2,990,696);跨四條公鏈按用戶量TOP3 DApps為:Endless Game(EOS)、Hash Baby(EOS)、ERC20-USDT(ETH);按交易次數TOP3 DApps分別為:Hash Baby(EOS)、TRONbet(TRON)、Dice(EOS);按交易額TOP3 DApps分別為:EOSREX(EOS)、TRONbet(TRON)、EOSJacks(EOS)。[2019/6/10]
Block.one正在構建區塊鏈軟件,以保持數據庫和用戶賬戶的安全,防止未經授權的訪問和未予解釋的修改。有了區塊鏈,用戶可以使用高度安全的私鑰,這些密鑰存儲在安全的硬件中,用于對每個用戶交互進行簽名,而不是簡單地進行服務器連接的身份驗證。區塊鏈創建了一個不可更改的記錄,建立了接收用戶輸入的絕對和確定性的順序,而智能合約提供了確定性的業務邏輯,確保了所有系統之間的一致性。
行情 | EOS 出現劇烈波動:據Binance數據顯示,下跌: EOS 現報價2.39美元,1小時變化超過$0.05,波動較大,請做好風險控制[2018/12/5]
未來的Block.one正在消除密碼和昂貴的審計,為企業節省數十億美元,防止身份盜竊,并提供更高的可靠性和可審計能力。
多年來,我一直認為每個多用戶網站都可以從區塊鏈后端中獲益。和很多人的認知不同,區塊鏈不必是緩慢、低效的數據庫,也不必在抗審查、開放的基礎上運行。區塊鏈可以在安全性、審計能力、透明度和業務流程的完整性方面提供重要的改進,即使區塊鏈完全由公司自己操作,其中的所有內容都不會公開。本文旨在揭示區塊鏈在企業環境中的真正價值,并為區塊鏈行業的發展指明方向。
在區塊鏈行業中,許多人認為區塊鏈只有在將互不信任的參與方連接起來時才會創造優勢。他們認為,傳統的數據庫技術已經可以完成確保業務所需的所有工作。換句話說,他們認為傳統的數據庫復制和“數據完整性”保證就足夠了。在這個過程中,他們要么忽視要么無視區塊鏈所提供的完全不同的安全性和完整性保證:
1. 對全局事件序列的承諾
2. 業務邏輯的確定性執行
3. 業務邏輯和數據完整性的緊密耦合
4. 消除密碼
在傳統的業務應用程序架構中,業務邏輯與數據庫是分離的。通常有一個應用服務器,如Node.js或J2EE,提供了修改數據庫的密碼。Node.js服務器的作用是通過密碼或多因素認證機制對用戶進行身份驗證。一旦應用服務器對用戶進行了身份驗證,它就會發出一個會話令牌,用于對未來的用戶交互進行身份驗證,直到超時或會話的某些元素(如IP)發生更改。
行情 | EOS 出現劇烈波動:據Binance數據顯示,下跌: EOS 現報價2.44美元,1小時變化超過$0.05,波動較大,請做好風險控制[2018/12/5]
顯然,這種傳統設計通過應用服務器管理的單次登錄/密碼執行所有數據庫操作。通過最終用途,應用服務器負責部署身份認證機制。顯然,通常有多個用戶可以訪問用戶名和密碼。數據庫管理員可以向許多不同的應用服務器或個人分配和撤銷憑據。
高級系統確保在橫向擴展的系統中,每個應用服務器都有自己的用戶名和密碼,在某些情況下甚至可以使用公鑰基礎設施(PKI)和硬件安全模塊(HSM)。但是,即使在這里,數據庫也只認證應用服務器的連接。為了提供審計日志,它必須記錄安全連接的整個數據流。但是,即使這個日志也只能記錄應用程序服務器請求的“讀寫操作”,而應用程序服務器已經丟失了最初用戶意圖的所有信息。
審查這樣一個系統的審計師無法知道應用服務器(例如Node.js)是否遵循正確的業務邏輯,是否正確地驗證了最終用戶的身份。Node.js進程可以將用戶操作記錄到數據庫中,方便審計師復制同樣的計算,但這樣的記錄并非不可篡改,而且沒有獨立認證驗證,無法了解終端用戶真的授權了某一行為。
可以嘗試記錄每個用戶的連接,但是由于用戶經常通過連接傳輸他們的密碼,這些記錄最終會成為一個泄露用戶信息的蜜罐。更復雜的系統可以對這些記錄進行加密,這樣只有審計人員才能讀取它們。
神秘節點沖進EOS投票前三:EOS主網上線已進入投票階段。目前韓國節點EOSYS得票第一。EOS 佳能,EOS Gravity, EOS Beijing, EOS Store, HuobiPool, HelloEOS, EOS Asia等中國節點目前進入前30。晚上9點多,一個新注冊的神秘節點EOSflytoMARS(EOS飛往火星)得票突然沖進前三。[2018/6/12]
假設審計日志沒有被篡改,審計人員將不得不通過應用程序邏輯運行相同的操作序列,以驗證最終數據庫狀態是否匹配。這意味著應用服務器必須以確定性的方式實現。
雖然編寫確定性代碼似乎很簡單,但實際上所有常見的計算機語言都是非確定性的,因為它們允許開發人員獲取存儲在數據庫以外的數據。可以是一些簡單的東西,如時間戳、內存地址、環境變量、IP地址,也可以是一些更微妙的東西,如硬件上的浮點行為或哈希表的插入順序。在許多情況下,訪問長時間運行的應用程序服務器的內存變量就足以引入不確定性。啟動/停止應用程序服務器的動作必須被記錄和復制,否則在重放期間每個本地內存訪問可能是不確定的。
事實是,編寫確定性代碼對于受過常見誤區培訓、積極尋找非確定性的最佳開發人員來說是一個挑戰。典型的企業應用程序開發人員會發現以確定性的方式編寫代碼是困難的或不切實際的。
如果我們進一步假設應用程序代碼是確定性的,應用程序如實記錄用戶事件,那么我們仍然面臨跟蹤部署的代碼版本的挑戰。應用程序是動態的,并且經常更新,因此應用程序代碼本身也必須是數據庫狀態的一部分,并且其更新的管理和記錄與用戶操作的安全性和可審計性相同。然后,審計人員需要擁有應用服務器代碼的所有版本的副本,并根據需要通過每次版本升級來重放用戶輸入(以及重啟代碼)。
EOS換手率達32.13%:據數據統計,EOS的24h成交額達37.42億美元,排名第三,換手率達32.13%,資金流出2.95億元。同一時間BTC換手率為5.67%,ETH換手率為5.08%。[2018/5/12]
即使單個應用程序服務器在安裝和部署方面都能夠以確定的方式進行操作,它仍然會遇到一個主要的可擴展性問題。只有一個應用服務器實例可以在數據庫進行操作。并行訪問可以通過復雜的鎖實現,但是即使鎖上的競爭條件也必須被記錄和復制,或者兩個具有不同本地變量的應用程序邏輯實例也可能產生不確定的輸出。
此時人們可能會完全放棄確定性,但是確定性在缺席之后,會逐步在最終數據集累積大量的偏差。審計人員將被迫使用模糊邏輯和近似匹配,每個人都必須相信“模糊邏輯”已經夠好了。
當然,要否定編寫和部署確定性代碼所付出的所有努力,唯一要做的就是讓數據庫管理員直接修改數據庫而不進行跟蹤。在某些情況下,對用戶輸入日志和狀態的仔細更新可能會創建兩個不同的數據庫狀態,每個狀態都通過了確定性測試,但仍然具有不同的和不可調和的輸出。例如,假設一個教授向系統提交了一個學生的成績為F,然后這個學生可以通過黑客或賄賂的方式進入數據庫來更改他的成績和教授提交的記錄。
任何重視完整性的多用戶系統的最終目標都是確保不能偽造用戶輸入。用戶名/密碼或其他主觀的多因素認證(如SMS或谷歌驗證)的使用依賴于服務器來判斷密碼是否匹配,或者是否輸入了正確的SMS代碼/電子郵件鏈接/驗證碼。很明顯,這對系統的完整性來說是一個巨大的問題,我將提供一個真實的例子來說明這些系統有多糟糕。
2016年,我在一家加密貨幣交易所開設了一個賬戶,后來這家遭到黑客攻擊,黑客竊取了價值數萬美元的比特幣。我當時一共收到了4封郵件,第一封是 “密碼重置”郵件,然后是另一封表明我的密碼已成功重置的郵件。然后我收到一封要求確認我的比特幣提取(帶有代碼/鏈接)的郵件。然后我收到了一個通知,說我的提幣手續已經辦完了。
乍一看,我的郵箱似乎被黑了,但這是不可能的,因為我采用了多因素認證。我的郵箱安全頁面顯示,沒有未經授權的訪問。我也能看出來,因為谷歌會記錄并顯示所有訪問我郵箱的IP和設備。
事實上,攻擊者在郵件到達我的郵箱之前就截獲了郵件。應用服務器無法知道郵件被截獲,因此就算攻擊者只有應用服務器生成的一次性代碼,其還是能獲得密碼重置和提幣的授權。
同樣的漏洞也可用于SMS或依賴于用戶控制的私鑰以外的其他技術。真正安全的用戶賬戶是為所有用戶采用基于硬件的私鑰作為他們的登錄憑證,在硬件密鑰丟失的情況下,采用一個穩健的和費時的過程來促進安全復位。
此時,多用戶業務應用程序可以使用用戶的私鑰對每個用戶請求簽名,將這個簽名的請求記錄到數據庫中,并使用確定性代碼處理它。即使這樣也不能提供人們所期望的完整性,因為用戶請求仍然可能被刪除,同時還會產生副作用。想象一下,當一名警官提交了你的罰單,然后所有的州都產出了這個請求,你就可以入侵警察數據庫并刪除他簽署的請求。
此時,精明的工程師會宣稱,我提出的每個問題都可以通過更改應用程序邏輯來解決。他是對的,一個成熟的應用程序開發人員可以使用傳統的數據庫、傳統的應用程序服務器和常見的密碼原語來構建一個相對安全且可審計的系統。根據同樣的邏輯,一個精明的工程師可以聲稱數據庫是完全不必要的,所有的東西都應該直接構建在文件系統上。也有工程師可能會指出,我們可以從頭開始編寫代碼,不再依賴于Node.js和J2EE等應用服務器框架,這樣就能提高性能。這就好像所有的東西都是由低水平的技術制造出來的,我們也可以設計出性能最佳的晶體管。
我之所以指出這個極端,是因為它強調了了高級框架在加速和保護新應用程序開發方面的真正效用。很少有人編寫自己的密碼庫或算法,而編寫這些庫或算法的人要么是專家,要么在自己的系統遭到黑客攻擊時成為了反面教材。從頭開始開發/重新開發所有東西的成本可能會使每個應用程序都比在經過驗證的框架上構建更昂貴。
區塊鏈和EOSIO這樣的開發框架之所以存在,是為了讓應用程序開發人員不必為了構建安全的應用程序而重新創建“數據庫”。安全性和確定性很難實現,這就是為什么技術構建在抽象細節的層中。EOSIO在同一過程中將確定性執行環境(WebAssembly)與快速數據庫相結合。所有的用戶操作都由他們自己的私鑰簽名,并記錄在一個復制和分布式的數據庫中,該數據庫具有對區塊頭進行公開承諾的能力。
EOSIO這樣的框架變得與傳統的不安全系統一樣強大且易于開發,只是時間問題。在許多方面,EOSIO的架構已經比傳統系統具有更高的性能,這是因為它將應用程序邏輯放在與內存數據庫相同的進程空間中。這就創建了確定性存儲過程。
在未來的幾年里,Block.one的目標是添加工具和接口,使在區塊鏈上部署企業應用程序就像在傳統企業應用架構上部署同類應用一樣容易(或更容易)。
很明顯,采用區塊鏈技術應該成為政府機構、上市公司和有責任防止欺詐或進行財務報告的企業的優先事項。在我看來,未來幾年不采用區塊鏈技術就像銀行不采用SSL,一旦該技術得到廣泛使用,不使用區塊鏈技術就會被認為是疏忽。
是時候開始行動了。如果應用程序的構建方式沒有根本性的改變,你的企業和用戶就不會安全。每耽擱一天,你的生意就會面臨欺詐或黑客攻擊的風險。
Tags:EOS區塊鏈tronRONeos幣最新資訊區塊鏈存證怎么操作tronlinkapp中文tronlink錢包密碼忘記了怎么找回
經過長達五年的研發工作,中國版央行數字貨幣DCEP(Digital Currency Electronic Payment,數字貨幣與電子支付)隨時可能正式落地.
1900/1/1 0:00:00當與區塊鏈數據集一起使用時,機器學習模型往往會過擬合。什么是過度擬合以及如何解決?乍一看,使用機器學習來分析區塊鏈數據集的想法聽起來非常吸引人,但這是充滿挑戰的道路.
1900/1/1 0:00:00牛市在絕望中來臨、質疑中展開、猶豫中猛漲、狂熱中結束。現在是什么階段?——小荷才露尖尖角。最近碰到一些網友來詢問比特幣,開口就是,比特幣是不是來牛市了,是的話就貸款梭哈.
1900/1/1 0:00:00Joseph Young:比特幣從虛弱之手轉移到完美之手:12月27日,加密分析師Joseph Young發推稱,2017年,機構看著散戶FOMO,全都感到疑惑;2020年.
1900/1/1 0:00:00在過去的12個月中,一項關鍵的鏈上指標可能表明散戶正在持續積累比特幣。 多年來,盡管比特幣價格較為波動,但擁有一個或多個比特幣的賬戶地址數量一直保持穩定增長.
1900/1/1 0:00:00看著最后一車票據在紅色火焰中燒成灰燼,趙越松了口氣。一個時代也將隨著煙火飄散。他在浙江邵逸夫醫院財務科做了30年票據管理員。一份票據對應一個病人,這30年,票據數量隨著病人一起增多.
1900/1/1 0:00:00