EOS sw/eden | BM最新博文：为什么区块链有更好的应用服务器和数据库架构

给EOS sw/eden | EOS瑞典投票，请认准我们的主网节点ID：eosswedenorg

今日BP排名：33

编译：参考默燃译文；优化byaLex_区块链行者[EOS sw/eden中文社区经理]

声明：文章内容仅为原作者观点，不代表本节点立场，且不构成任何投资建议

BM最新博文：为什么区块链有更好的应用服务器和数据库架构

传统的网页应用基础结构在设计时仅将安全性作为次优先事项，在过去的25年里，公司们一直在尝试修补一个从根本上就不牢靠的体系结构。这种结构的设计基于服务器安全可信的假设，但是多年的经验告诉我们，没有服务器是安全的，更不用说内部攻击了。换句话说，服务器的底层是中心化的。

我们过去认为“问题”在于用户和服务器之间的连接，因此我们引入了SSL和HTTPS（安全通讯协议）。但后来我们发现，黑客会入侵数据库并窃取密码。因此我们开始只在数据库存储密码的哈希值，但后来我们发现黑客会在盗取哈希值后再强行破解密码。再然后，我们引入了定期密码更换，如真有强行破解的情况，更换了密码可让强行破解白费，等等。

企业花费数十亿美元试图去保护它们的服务器和数据库，尽管竭尽全力，但仍然没有简单的方案来审计系统以确保企业完全正确运行。

Block.One正构建的区块链软件，可保证数据库和用户帐户的安全，防止未经授权的访问和目的不明的篡改。用户在区块链上可采用高度安全的私有密钥，这些密钥存储在安全的硬件中，每个用户在交互操作时签名，而这不是简单地连接服务器进行身份验证。区块链创建了一个不可篡改的日志，在接收用户输入时创建了完全确定性的顺序，而智能合约提供了确定性的业务逻辑，确保了所有系统之间的一致性。

未来，Block.One会开发出无需密码即可防止身份遭窃的技术，并不断提升其可靠性和可审计性，为企业节省数十亿美元的审计开支。

多年来，我一直认为用于大量用户的网站后端都可以采用区块链技术，并从中获得收益。和当下一些流行的观点相反，我认为，区块链并不是缓慢的、低效的数据库，也不必抵抗审查、在完全开放的基础上运行。即使不公开任何区块链上的内容，并完全由公司自己操作的情况下，区块链仍旧可以为企业在安全性、可审计性、透明度和业务流程的整体完整性方面带来巨大的改进。这篇文章旨在阐释区块链在企业中的真正价值，并为区块链行业引领方向。

常见的误解

在区块链行业中，许多人认为区块链只有在将互不信任的各方连接时才有用。他们认为，传统的数据库技术已经可以确保业务完整性所需的所有工作。换句话说，他们认为传统的数据库复制和“数据完整性”保证已经足够。在这个过程中，他们要么无知，要么故意忽视了区块链所提供的完全不同的安全性和完整性的构建基础：

1.对全局事件序列的保证
2.业务逻辑执行的确定性
3.业务逻辑和数据完整性间的紧密耦合
4.消除密码

在传统的企业应用架构中，业务逻辑与数据库是分离的。通常有一个应用服务器，如Node.js或J2EE，它提供了修改数据库的密码。js服务器的作用是通过密码或多重身份验证方案对用户进行身份验证。应用服务器对用户身份验证后，会发出一个会话认证，用于对用户未来交互时进行身份验证，直到超时或会话的某些元素（如IP）发生更改。

很明显，这种传统设计是通过应用服务器来管理单个登录/密码来执行所有数据库操作。应用服务器负责完成自己的身份验证。显然，通常有多个用户可以获取到用户名和密码。数据库管理员可以向许多不同的应用服务器和/或个人分配和撤销证书。

更先进的系统是确保在水平可扩展的系统中，每个应用服务器都有自己的用户名/密码，在某些情况下甚至可以使用公钥基础设施和硬件安全模块(HSMs)。但是，即使在这里，数据库也只验证到应用服务器的连接。为了提供审计日志，它必须记录安全连接的整个数据流。但是，即使是这个日志也只记录应用服务器请求的“读写”，而这时候其实已经丢失了向应用服务器发出指令的包含原始用户意图的所有信息了。

审计人员在查验这样一个系统时无法知道应用服务器(例如Node.js)是否遵照了的正确的业务逻辑执行，并正确地验证了终端用户的身份。node.js程序可以“log”用户操作行为到数据库中，因此审计人员可以试图复制同样的计算，但这样的日志不是防伪造的，也没有独立可验证身份验证，终端用户实际上授权所有的操作给日志。

可以尝试记录每个用户的连接，但是由于用户会经常连接并输入密码，这些日志最终会成为一个泄露用户凭证的“蜜罐”。复杂一些的系统会对这些日志加密，只有审计人员才能读取。

假设审计日志没有被篡改，审计人员需要运行具有相同逻辑的操作序列，来验证数据库状态结果是否匹配。这意味着应用服务器必须通过具有确定性的方式来实现。

确定性计算是困难的

虽然编写确定性代码看起来很“简单”，但实际上所有常见的计算机语言都是非确定性的，因为开发人员是可以访问数据库中存储的数据之外的数据，它可能是一些简单的东西，如时间戳、内存地址、环境变量、IP地址，也可以是一些更微妙的东西，如硬件上的浮点行为或哈希表的插入顺序。在很多情况下，简单访问一个长时间运行的应用程序服务器的内存变量，就完全可以引入不确定性。启动/停止应用程序服务器的动作必须被记录和复制，否则在重播期间每个本地内存访问可能都是不确定的。

事实上，即使对于那些经过训练去发现常规漏洞或有意识去寻找不确定问题的优秀开发者来说，编写确定性代码仍旧是很有挑战的。典型的企业应用程序开发者会发现以确定性的方式编程是困难的或不切实际的。

如果我们进一步假设应用程序代码是确定性的，应用程序真实地记录了用户事件，我们仍面临在随时可能进行的给定时间内，追踪代码部署版本的挑战。应用程序是动态的，并且经常更新，因此应用程序代码本身也必须是数据库状态的一部分，并且其更新的管理和记录与用户操作的安全性和可审计性相同。审计人员需要拥有应用服务器代码所有版本的副本，并根据需要通过每次版本升级来重播用户输入。

即使单个应用服务器在实现和部署方面都以确定的方式操作，它仍然会遇到可扩展性这个主要问题。只有一个应用服务器可以对数据库进行操作，并行访问可以通过复杂的锁定来实现，但是即使锁定的争用条件也必须被记录和复制，或者两个具有不同本地变量的应用逻辑也可能产生不确定的输出。

在这点上，人们可能会完全放弃确定性，但是没有确定性，随着时间推移，一个比特的差异可累加成巨大差异，并最终到数据库中。审计人员将不得不使用模糊逻辑和近似匹配，而且每个人都要相信“模糊逻辑”是足够好的。

当然，要想免去编写和部署确定性代码所做的努力，惟一需要做的就是让数据库管理员直接修改数据库而不跟踪。在某些情况下，对用户输入日志和状态的更新可能会创建两个不同的数据库状态，每个状态都通过了确定性测试，但仍然具有不同的和不匹配的输出。例如，假设一个教授向系统提交了一个学生成绩F，然后这个学生通过黑客/贿赂的方式进入数据库来更改他的成绩和教授提交的日志。

替代密码

任何大用户量的系统最终目标都是要确保不能伪造用户的输入。用户名/密码或其他主观的多重身份验证（如SMS或谷歌身份验证器）的使用依赖于服务器来判断密码是否匹配或输入了正确的SMS代码/电子邮件链接/身份验证器代码。很明显，这对系统的完整性来说是一个巨大的问题，但是为了以防万一，我将提供一个真实世界的案例来说明这些系统的问题。

2016年，我在一家加密货币交易所开设了一个账户，这个账户遭到黑客攻击，黑客窃取了价值数万美元的比特币。我观察的黑客操作路线是，先通过发送给我“密码重置”邮件，再发一封密码重置成功的电子邮件。然后我收到一封电子邮件，要求确认我的比特币提取(带有代码/链接)，再之后我收到了一个通知，说我的取款手续已经办完了。

乍一看，我的电子邮件帐户好像是被黑了，但这是不可能的，因为我使用了多重验证登录了我的电子邮件。然后我快速访问电子邮件的安全页面，显示并没有未经授权的访问。可以说，因为谷歌记录并显示所有访问我电子邮件的ip/设备。

所发生的事情是，攻击者在邮件到达我的电子邮件账户之前截获了邮件。应用服务器无法知道电子邮件被截获，因此只有在攻击者拥有应用服务器生成的一次性代码的情况下，才能授权密码重置和撤回。

同样的漏洞也可能存在于SMS或任何依赖于用户控制私钥之外的其他技术中。最终，真正能保护用户帐户的唯一方法是让用户采用基于硬件的私有密匙作为他们的登录凭证，经过一个稳定和时间消耗的过程，以便在硬件密匙丢失时进行安全重置。

此时，多用户业务应用程序可以使用用户的私钥对每个用户请求签名，将这个签名的请求记录到数据库中，通过确定性代码处理。即使是这样，也不能提供人们所期望的完整性，因为整个用户请求仍然可能被删除，同时还会产生任何可能的副作用。想象一下，当一名警官提交了你的罚单，所有地区都从这个请求中衍生出来，你就可以入侵警察数据库并删除他签署的请求。

此时，有经验的工程师可能会说，我提出的每个问题都可以通过更改应用程序逻辑来解决。这是对的，一个成熟的应用程序开发人员可以使用“传统数据库”、“传统应用服务器”和“通用密码原码”来构建一个相对安全且可审计的系统。根据同样的逻辑，一个资深的工程师也可以说，数据库是完全不必要的，所有的东西都应该直接构建在文件系统上。另一位工程师可能会指出，通过从头开始编写代码，而不是依赖于Node.js和J2EE等应用服务器框架，可以提高性能。这就好像说，我们都用低水平的技术开发，但仍不妨碍我们做出性能最好的晶体管。

我之所以指出这个极端，是因为它强调了高层级框架在加速和保护新的应用程序开发方面的真正效用。很少有人编写自己的密码库或算法，而编写这些库或算法的人要么是专家，要么在自己的系统遭到黑客攻击后才开始警惕。相比基于经过验证的框架上构建应用，从头开始开发或重新开发的成本要高得多。

区块链应用/数据库服务器的优势

区块链和EOSIO这样的开发框架之所以存在，是为了让应用程序开发者不必为了构建安全的应用程序而重新创建“数据库”。安全性和确定性很难实现，这就是为什么技术是构建在抽象了细节的层中。EOSIO在同一过程将确定性的执行环境WebAssembly与数据库相结合。所有的用户操作都由他们自己的私钥签名，并记录在一个可复制和分布式的数据库中，这个数据库具备确认区块头的能力。

像EOSIO框架实现与传统不安全系统一样强大且易于开发，只是时间问题。在许多方面，EOSIO的架构已经比传统系统具有更高的性能，这是因为它将应用逻辑（Web程序组）与内存数据库归于同一进程空间中。这就实现了快速建构确定性存储的过程。

在未来的几年中，Block.One的目标是通过增加工具和接口，让部署在区块链上的企业应用与部署在传统架构上一样简单容易。

采用区块链技术应该成为政府机构、上市公司和有责任防止欺诈和/或进行财务报告的企业优先考虑的事项。在我看来，未来几年不采用区块链技术就像银行不采用SSL，一旦该技术被广泛使用，不使用区块链技术就会被认为是一种疏忽。

是行动的时候了！如果应用的开发方式没有根本性改变，企业和用户就不会安全。每拖延一天，你的业务遭欺诈或黑客攻击的风险就高一些。

（全文完)

为家乡祈福·祝爷爷一路走好????

参考资料：

https://medium.com/@bytemaster/why-a-blockchain-is-a-better-application-server-database-architecture-9d7b78730fbb

https://mp.weixin.qq.com/s/WOf6xxER-qgEvyn8wqw93w

如果您想了解更多，我们在这里：

WEB: https://eossweden.org
币乎: https://bihu.com/people/98843
微博: https://weibo.com/eossweden
BUSY: https://busy.org/@xebb
TELEGRAM: https://t.me/eossweden
TWITTER: https://twitter.com/eossweden
MEDIUM:https://medium.com/@eosswedenorg
STEEMIT: https://steemit.com/@eos.sw-eden FACEBOOK: https://www.facebook.com/EOS-sweden-554084258304426

给EOS sw/eden | EOS瑞典投票，请认准我们的主网节点ID：eosswedenorg

扫一扫加入我们的官方微信社群
共建EOS sw/eden中文社区

—-

编译者/作者：EOSsweden

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。