论如何提高去中心化应用程序dapp的安全性和可靠性

去中心化应用程序或ÐApps需要特殊的系统设计才能实现高安全性和可靠性。在本文中，我将介绍如何为去中心化应用程序正确设计和实现后端和智能合同的几个主要原则，以以太坊为主要示例，尽管其中大部分原则也适用于EOS，Tron和其他去中心化数据平台。

• 如何在没有安全问题的情况下在后端存储私钥。

• 如何正确设计智能合约以及decentralize的内容。

• 去中心化和半集中式应用程序架构示例。

• 如何处理网络负载和故障等低级别的东西。

去中心化应用和区块链

尽管区块链今天面临着许多采用和监管方面的困难，但它仍然是一种技术，无论是区块链，哈希图Hashgraph，tempo还是任何其他分布式账本技术，无论算法如何。

区块链和其他类似技术带来的主要价值可以概括如下：它们允许人们编写和运行程序，这些程序实际上在创建后不能更改，也不能在执行期间被篡改。换句话说，这些程序总是按设计运行，任何一方都不能影响他们的行为。

如果我们将它们视为定义如何来回转移数字货币的程序，则此定义适用于当今存在的许多加密货币。这也解释了为什么加密货币和多种代币具有真正的价值：它们不能通过其定义的底层程序underlying program凭空产生。

与比特币相比，以太坊/EOS/Tron/…平台实现了更复杂的程序层，这反过来实现了执行环境，允许任何人在平台上编写自己的去中心化程序。这个用户定义的程序始终按设计运行，没有任何例外，平台保证了它们的安全性。

去中心化应用程序

这些安全且不可更改的程序在去中心化网络上运行，结合传统的前端和后端技术，我们今天称之为去中心化应用程序（ÐApps）。通过其中一些可以半集中化，真正去中心化的应用程序中的活动的主要部分应该发生在中央方的控制之下。

想象一下我们今天所谓的去中心化应用程序，以任何现有的集中式Web资源（如YouTube或Instagram）为例，并想象你的加密身份crypto identity与Web/移动资源绑定，而不是受密码保护的集中式帐户。

这就是Wallet Software为你提供的服务。来自此身份的私钥（一个秘密，你可以代表此身份行事）存储在你的本地设备上，永远不会上线，因此没有人能够控制此身份。使用此标识，你可以在集中式（由中央机构控制的Web资源）和去中心化（与传统的www不同的网络，其目标是消除中央权限）网络中执行不同的操作，使用网站作为接入点或作为图形用户界面。这种加密身份crypto identity的重点在于你的行为是加密安全的，没有人能够改变你签名的内容和你的签名。

如今，以太网，EOS或Tron等容错去中心化网络的计算和存储能力有限。如果它们是可扩展的，我们可以使用去中心化的网络来存储整个去中心化的应用程序，包括其图形用户界面，数据和业务逻辑。在这种情况下，我们将这些应用程序称为真正的去中心化/分布式。

但是，由于这些网络目前无法扩展，我们将不同的方法结合起来，以实现应用程序的最大去中心化水平。我们所知道的传统traditional后端不会随处可见。例如：

• 我们使用后端来托管去中心化应用程序的前端。

• 我们使用后端与任何其他现有技术和服务集成。真正的世界级应用程序无法生活在孤立的环境中。

• 我们使用后端来存储和处理任何足够大的去中心化网络（特别是区块链）。实际上，整个应用程序及其业务逻辑存储在世界的某个地方，仅限于区块链部分。更不用说，IPFS和类似的存储层不能保证文件的可访问性，因此我们不能在没有自己托管文件的情况下依赖它们。换句话说，总是需要专用的运行服务器。

如今，如果不使用可靠的后端，就无法构建安全且部分去中心化的应用程序，本文的重点是解释如何正确执行此操作。

去中心化或集中化和token

碰巧的是，今天几乎所有去中心化的应用程序都是围绕所谓的token构建的，定制构建（或者只是简单克隆）的加密货币驱动特定的去中心化应用程序。代币只是一种可编程的货币或资产，就是这样。

通常，Token是在像以太坊这样的去中心化平台上编写的智能合约smart contract（自定义程序）。通过拥有一些Token，你基本上可以在Web资源或移动应用程序上获得不同的服务，并将此Token换成其他内容。这里的关键点是Token独立存在而且不受中央机构的控制。

有许多应用程序围绕Token构建：从众多可收集的游戏如CryptoKitties（ERC721Token）到更多面向服务的应用程序（如LOOM Network），甚至像Brave这样的浏览器和DreamTeam等游戏平台（ERC20兼容Token）。

开发人员自己决定并决定他们将（或不会）对其应用程序的控制程度。他们可以在智能合约之上构建整个应用程序的业务逻辑（如CryptoKitties），或者，他们根本不能使用智能合约，将所有内容集中在他们的服务器上。但是，最好的方法是在中间的某个地方。

去中心化网络的后端

从技术角度来看，必须有一个连接Token和其他智能合约与网络/移动应用程序的桥梁。

在当今完全去中心化的应用程序中，客户端直接与智能合约交互，这个桥梁缩小为公共API的JSON RPC API功能或Infura等节点池，而后者又被迫存在，因为不是每个设备都可以运行并支持其各自的网络节点。但是，此API提供了一组基本且非常窄的函数，几乎不允许进行简单查询，也无法有效地聚合数据。因此，最终，自定义后端启动，使应用程序半集中化。

根据应用需求，与去中心化网络的整体交互可以缩小到一两点：

• 监听网络事件（如Token传输）/读取网络状态。

• 发布交易（调用状态更改智能合约函数，如Token传输）。

实现这两点非常棘手，特别是如果我们想要构建安全可靠的后端解决方案。以下是我们要分解的要点：

• 首先，在以太坊中，事件检索不是即插即用的。由于多种原因：网络节点在获取大量事件时可能会失败，因为网络分叉等事件可能会消失或发生变化。我们必须构建一个抽象层来同步来自网络的事件并保证其可靠的传输。

• 对于交易发布来说，我们必须抽象以太坊的低级别的东西，如nonce计数器和gas估计，以及交易重新发布，提供可靠和稳定的界面。此外，交易发布意味着使用私钥，这需要高级后端安全性。

• 安全。我们将认真对待它，并且面对不可能保证私钥不会在后端受到损害。幸运的是，有一种设计去中心化式应用程序的方法，甚至不需要高度安全的后端帐户。

在我们的实践中，所有这些使我们为以太坊创建了一个强大的后端解决方案，我们将其称为以太坊网关。它从以太坊的乐趣中抽象出其他微服务，并提供可靠的API来使用它。

去中心化的应用程序架构

本文的这一部分在很大程度上取决于特定去中心化应用程序的需求，但我们将尝试理清这些应用程序构建的基本交互模式（ÐPlatform= Decentralized Platform=Ethereum/EOS/Tron/Whatever）：

客户端/平台：完全去中心化的应用程序。

客户端（浏览器或移动应用程序）直接在去中心化的平台上与Metamask，Trust等钱包软件或Trezor或Ledger等硬件钱包进行交互。以这种方式构建的DApps的示例是CryptoKitties，Loom的Delegated Call，加密钱包本身（Metamask，Trust，Tron Wallet，其他），去中心化的加密交易所，如Etherdelta等。

平台/客户端/后端/平台：集中或半集中式应用程序。

客户端与去中心化式平台和服务器的交互几乎没有共同之处。这方面的好例子是今天的任何（集中式）加密交易所，比如BitFinex或Poloniex：你在交易所交易的货币只记录在传统数据库中。你可以通过将资产发送到特定地址（ÐPlatform/客户端）来充值你的数据库余额，然后在应用程序中执行某些操作后撤消资产（BackEnd/ÐPlatform），但是，你执行的所有操作都是ÐApp本身（客户端/后端）并不意味着你与ÐPlatform的直接交互。

另一个例子是Etherscan.io，它使用半集中式方法：你可以在那里做所有有用的去中心化操作，但如果没有全面的后端，应用程序本身就没有意义（Etherscan不断同步交易，解析数据并存储它，最终提供全面的API/UI）。

介于两者之间：still，集中或半集中的应用程序。

以上方法相结合。例如，我们可以拥有一个应用程序，它提供各种服务以换取加密，允许你使用加密身份登录和签名信息。

希望完全去中心化的应用程序（客户端P平台）的交互模式不会引起任何问题。依靠Infura或Trongrid等令人惊叹的服务，人们可以简单地构建一个根本不需要服务器的应用程序。几乎所有客户端库（如Ethereum的Ethers.js或Tron的Tron-Web）都可以连接到这些公共服务并与网络进行通信。但是，对于更复杂的查询和任务，你可能还需要分配自己的服务器。

其余涉及后端的交互模式使事情变得更加有趣和复杂。为了将所有这些放在一张图片中，让我们想象一下我们的后端对网络中的某些事件做出反应的情况。例如，用户发布允许交易的许可交易。为了收费，我们必须公布收费交易以响应发出的津贴事件：

从后端的角度来看，这是发生了什么：

• 1.我们通过不断轮询网络来收听特定的网络事件。

• 2.一旦我们得到一个事件，我们就会执行一些业务逻辑，然后决定发布一个事务作为响应。

• 3.在发布交易之前，我们希望确保它可能被挖掘（在以太坊中，成功的交易gas估算意味着当前网络状态没有错误）。但是，我们无法保证交易将成功挖掘。

• 4.使用私钥，我们签署并发布交易。在以太坊，我们还必须确定交易的gas价格和gas限额。

• 5.发布交易后，我们不断轮询网络的状态。

• 6.如果它花费的时间太长而无法获得交易的状态，我们必须重新发布它或触发一个失败场景fail scenario。交易可能由于各种原因而丢失：网络拥塞，节点丢失，网络负载增加等。在以太坊中，你还可以考虑使用不同（实际）的gas价格重新签署交易。

• 7.在我们最终开始挖掘交易之后，我们可以根据需要执行更多业务逻辑。例如，我们可以通知其他后端服务有关交易完成的事实。此外，在做出有关交易的最终决定之前，请考虑等待几个确认：网络是分布式的，因此结果可能在几秒钟内发生变化。

如你所见，有很多事情发生了！但是，你的应用程序可能不需要执行某些步骤，具体取决于你要实现的目标。但是，构建一个强大而稳定的后端需要为上述所有问题提供解决方案。

去中心化的应用程序后端

在这里，我想强调大多数问题产生的一些要点，即：

• 监听网络事件并从网络中读取数据。

• 发布交易以及如何安全地进行交易。

监听网络事件

在以太坊以及其他分散的网络中，智能合约事件（或事件日志，或仅仅是日志）的概念允许离线应用程序了解区块链中发生的事情。这些事件可以由智能合约开发人员在智能合约代码的任何位置创建。

例如，在众所周知的ERC20代币标准中，每个代币传输都必须记录Transfer事件，从而让脱链应用程序知道发生了代币传输。通过listening这些事件，我们可以执行任何动作。例如，当代币转移到你的地址时，某些移动加密钱包会向你发送推送/电子邮件通知。

实际上，没有可靠的解决方案来即插即用地监听网络事件。不同的库允许你跟踪/监听事件，但是，在许多情况下可能出现问题，导致丢失或未处理的事件。为了避免丢失事件，我们必须构建一个自定义后端，它将维护事件同步过程。

根据你的需求，实施可能会有所不同。但是，为了让你了解这里，你可以选择如何在微服务架构方面构建可靠的以太坊事件：

这些组件以下列方式工作：

• 1.事件同步后端服务不断轮询网络，尝试检索新事件。一旦有一些新事件可用，它就会将这些事件发送到消息总线。成功将事件提交到消息总线后，就区块链而言，我们可以保存最后一个事件的块，以便下次从该块请求新事件。请记住，一次检索太多事件可能导致始终失败的请求，因此你必须限制从网络请求的事件/块的数量。

• 2.消息总线（例如，Rabbit MQ）将事件路由到为每个后端服务单独设置的每个队列。在事件发布之前，事件同步后端服务指定路由密钥（例如，智能合约地址+事件主题），而消费者（其他后端服务）创建仅为特定事件订阅的队列。

因此，每个后端服务只获得它需要的事件。此外，消息总线一旦发布，就保证所有事件的传递。

当然，你可以使用其他东西而不是消息总线：HTTP回调，套接字等。在这种情况下，你需要弄清楚如何保证回调自己交付：保证幂等/自定义重试回调，实现自定义监控等等。

发布交易

为了将交易发布到去中心化网络，我们必须执行几个步骤：

• 1.准备交易。与交易数据一起，该步骤意味着请求网络状态以便找出该交易是否有效并且将被挖掘（以太坊中的气体估计）和交易的序号（以太坊中的随机数）。一些库试图在后端进行，但是，这些步骤很重要。

• 2.签署交易。此步骤意味着使用私钥。最有可能的是，在这里你需要嵌入自定义私钥组装解决方案。

• 3.发布和重新发布交易。这里的一个关键点是，你发布的交易总是有可能从去中心化的网络中丢失或丢失。例如，在以太坊中，如果网络的gas价格突然上涨，则可以删除已公布的交易。在这种情况下，你必须重新发布该交易。此外，你可能希望使用其他参数（至少具有较高的gas价格）重新发布交易，以便尽快开采。因此，如果替换交易之前没有预先签名（使用不同的参数），则重新发布交易可能意味着重新签名。

通过使用上述方法，你最终可以构建类似于下面的序列图中显示的内容。在这个特定的序列图中，我演示了区块链重复计费如何工作（链接文章中有更多内容）：

• 1.用户在智能合约中执行功能，最终允许后端执行成功的收费交易。

• 2.负责特定任务的后端服务监听收费许可事件并发布收费交易。

• 3.一旦开始收费交易，负责特定任务的该后端服务从以太坊网络接收事件并执行一些逻辑（包括设置下一个收费日期）。

后端安全和智能合约

交易发布始终涉及使用私钥。你可能想知道是否可以保护私钥安全。嗯，是的，不。有许多复杂的策略和不同类型的软件允许非常安全地在后端存储私钥。一些私钥存储解决方案使用geo-distributed数据库，而其他人甚至建议使用特殊硬件。但是，在任何情况下，半集中式应用程序的最脆弱点是组装私钥并用于签署交易（或者，在特殊硬件的情况下，触发交易签名过程的点）。因此，从理论上讲，没有100％可靠的解决方案可以使保护大家不会危及存储的私钥。

现在就这么想。在许多情况下，你甚至不需要经常在后端保护私钥。相反，你可以设计智能合约和整个应用程序，使私钥泄漏不会影响其通常的行为。通过这种方法，授权帐户如何与智能合约进行交互并不重要。他们只是触发triggering智能合约来完成其正常工作，而智能合约本身也会执行任何必要的验证。我称之为运营账户模式operational accounts patter。

这样，在紧急情况下：

• 攻击者可以窃取的唯一东西是存入交易发布的操作账户中的少量以太（以太坊）。

• 攻击者无法破坏智能合约逻辑，也无法损害参与此过程的任何人。

• 妥协的运营帐户可以快速替换为其他帐户，但是，这需要手动更换（生成新帐户，重新授权所有智能合约中的帐户）或开发一个额外的解决方案，这将通过超级单一交易完成所有super-secure（硬件或multi-sig）主帐户。

例如，在我们对以太坊解决方案的定期计费中，无论后端发生什么，定期计费智能合约的设计方式使我们有一整个月的时间来更换受损帐户（如果其中任何一个受到损害）。

但是，如果你希望尽可能安全地保护你的后端私钥存储，你可以尝试使用Vault以及用于存储和管理以太坊帐户的以太网的优秀插件。