去中心化应用程序（DApps）需要特殊的系统设计，以实现高安全性和可靠性。

在本文中，我将以以太坊为主要示例，介绍如何为去中心化应用程序正确设计、实现后端和智能合约的几个主要原则，尽管其中大部分将适用于Eos、Tron和其他去中心化数据平台。

文章重点：

• 如何在不考虑安全性的情况下将私钥存储在后端

• 如何正确设计智能合约以及“去中心化”的内容

• 分散式和半分散式应用程序架构示例

• 如何处理网络负载和故障等底层问题

让我们开始吧！

去中心化程序和区块链

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

区块链和其他类似技术带来的主要价值可以概括如下：它们使人们能够编写和运行程序，这些程序实际上在创建后就不能更改，在执行过程中也不能篡改。换句话说，这些程序始终按设计运行，并且任何一方都不能影响其行为。如果我们将它们视为定义如何来回转移硬币的程序，则此定义对当今存在的许多加密货币均有效。这也解释了为什么加密货币和多种令牌具有真正的价值：它们不能通过定义的“底层程序”凭空产生。

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

分散应用

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

如果有人要求我绘制DApps今天的工作方式，我可能会绘制此图

想象一下我们今天所说的去中心化应用程序，以_YouTube_或_Instagram_之类的任何现有集中式Web资源为例，并想象将您的“加密身份”绑定到Web /移动资源，而不是受密码保护的集中式帐户。

这就是电子钱包软件为您提供的。此身份的私钥（秘密，您可以代表此身份进行操作）存储在本地设备上，并且永远不会在线，因此没有人可以控制此身份。有了这个身份，你可以在两个执行不同的操作集中 和（由中央管理机构控制网络资源）分散（这是从传统的WWW不同的网络，目标，其中是消除中央机关）网络，将网站用作访问点和/或图形用户界面。这种“密码身份”的全部意义在于，您的操作是通过密码保护的，没有人能够更改您签名的内容或签名。

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

但是，由于这些网络目前无法扩展，因此我们结合了不同的方法来为我们的应用程序实现最大的分散级别。我们知道，“传统”后端没有任何发展。

例如：

• 我们使用后端来托管分散应用程序的前端。

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

• 我们使用后端存储和处理足以分散网络（尤其是区块链）的任何事物。实际上，整个应用程序及其业务逻辑存储在世界的某个地方，仅不包括区块链部分。更不用说，IPFS和类似的存储层不能保证文件的可访问性，因此我们也不能依靠它们而不自己托管文件。换句话说，始终需要专用的运行服务器。

到目前为止，如果不使用可靠的后端，就无法构建安全且部分分散的应用程序，本文的重点是解释如何正确地做到这一点。

（去中心化）和代币

碰巧的是，当今几乎所有分散式应用程序都是围绕所谓的令牌构建的，令牌是驱动特定分散式应用程序的定制（或只是简单克隆）的加密货币。令牌仅仅是一种可编程的货币或资产，仅此而已。

令牌智能合约决定了用户如何传输令牌，而应用程序智能合约可以扩展令牌智能合约中缺少的所有内容。两种智能合约都运行在去中心化网络之上通常，令牌是写在像以太坊这样的去中心化平台之上的“智能合约”。通过拥有一些令牌，您基本上可以在Web资源或移动应用程序上获得不同的服务，并将该令牌换成其他东西。这里的关键点是令牌本身是存在的，并且不受中央机构的控制。

有许多围绕令牌构建的应用程序示例：从诸如CryptoKitties（ERC721令牌）之类的众多可收藏游戏到诸如LOOM Network等面向服务的应用程序，甚至是诸如Brave之类的浏览器以及诸如DreamTeam（与ERC20兼容的令牌）之类的游戏平台。开发人员自己确定并决定他们将（或不会）对其应用程序进行多少控制。他们可以在智能合约的基础上构建整个应用程序的业务逻辑（就像CryptoKitties所做的那样），或者，他们根本不使用智能合约，将服务器上的所有内容集中在一起。但是，最好的方法是居中。

分散网络的后端

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

在当今的完全去中心化的应用程序中，客户端直接与智能合约进行交互，此桥被缩小为公共API或Infura之类的节点池的JSON RPC API功能，由于并非每个设备都可以运行并支持其单独的网络节点。但是，此API仅提供了一组基本且非常狭窄的功能，这些功能仅允许进行简单查询或有效地聚合数据。因此，最终会引入自定义后端，从而使应用程序成为半集中式。

与分散网络的整个交互可以缩小到一两个点，具体取决于应用程序的需求：

1. 侦听网络事件（例如令牌传输） /读取网络状态。

2. 发布交易（调用状态更改智能合约功能，如令牌转移）。

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

• 首先，在以太坊中，事件检索不是开箱即用的。由于多种原因：网络节点在提取大量事件时可能会失败，事件可能会由于网络派生而消失或发生更改等。我们必须构建一个抽象层，以同步网络中的事件并确保其可靠传递。

• 与交易发布相同，我们必须抽象以太坊的低端内容，例如随机数计数器和天然气估算值，以及交易重新发布，以提供可靠且稳定的界面。此外，事务发布意味着使用私钥，这需要高级后端安全性。

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

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

以太坊的后端监控。监控器演示的活动主要与我们的循环计费功能有关（尽管您可以看到每小时都有峰值）。

分散式应用架构

这部分高度依赖于特定的去中心化应用程序的需求，我们将尝试在构建这些应用程序的基础上梳理一些基本的交互模式（Ð平台=去中心化平台=以太坊/ EOS / Tron / Whatever）：

客户⬌平台：完全分散的应用程序。

客户端（浏览器或移动应用程序）在以太坊“钱包”软件（如Metamask，Trust）或硬件钱包（如Trezor或Ledger）的帮助下，直接与分散平台进行对话。以这种方式构建DApp的示例包括CryptoKitties，Loom的 Delegated Call，加密钱包本身（Metamask，Trust，Tron Wallet等），分散式加密交易所（如Etherdelta）等。

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

客户端与分散平台和服务器的交互几乎没有共同点。一个很好的例子是当今的任何（集中式）加密货币交易所，例如BitFinex或Poloniex：您在交易所交易的货币只记录在传统数据库中。您可以通过将资产发送到特定地址（“平台⬌客户端”）来“充值”数据库余额，然后在应用程序中执行某些操作后（后台⬌Ð平台）撤回资产，但是，您所做的一切都取决于“应用程序”本身（客户端⬌后端）并不意味着您与Ð平台直接交互。

另一个示例是Etherscan.io，它使用半集中式方法：您可以在其中执行所有有用的去中心化操作，但是没有它们的综合后端，应用程序本身就没有任何意义（Etherscan持续同步事务，解析数据并存储它，最终提供全面的API / UI）。

介于两者之间的内容：静止， 集中式或半集中式应用程序。

结合以上方法。例如，我们可以有一个应用程序，该应用程序提供各种服务以换取加密，从而使您可以使用加密身份登录并签名信息。

希望完全分散的应用程序（客户端Client平台）的交互模式不会引起任何问题。依靠Infura或Trongrid等令人赞叹的服务，您可以简单地构建根本不需要服务器的应用程序。像几乎所有的客户端库Ethers.js为复仇或特隆的Web为特隆可以连接到这些公共服务和与网络进行通信。但是，对于更复杂的查询和任务，您可能仍然需要分配自己的服务器。

其余涉及后端的交互模式使事情变得更加有趣和复杂。为了将所有这些图景化，让我们想象一下后端对网络中的某些事件做出反应的情况。例如，用户发布了一项配额交易，该交易允许我们向他们收取费用。要收取费用，我们必须针对发出的配额事件发布费用交易：

分散网络中服务器对用户操作的反应的示例流程从后端的角度来看，会发生以下情况：

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

• 收到事件后，我们将执行一些业务逻辑，然后决定发布一个事务作为响应。

• 在发布交易之前，我们要确保将有可能被开采（在以太坊中，成功的交易气体估计意味着没有相对于当前网络状态的错误）。但是，我们不能保证交易将被成功开采。

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

• 发布交易后，我们会连续轮询网络以了解其状态。

• 如果花费的时间太长而我们无法获得交易的状态，则必须重新发布它或触发“失败情况”。交易可能由于各种原因而丢失：网络拥塞，对等体掉落，网络负载增加等。在以太坊中，您还可以考虑以不同的（实际）汽油价格重新签署交易。

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

如您所见，发生了很多事情！但是，您的应用程序可能不需要其中的某些步骤，具体取决于您要实现的目标。但是，构建强大而稳定的后端需要解决上述所有问题。让我们分解一下。

分散的应用程序后端

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

• 侦听网络事件并从网络读取数据

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

收听网络事件

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

例如，在众所周知的ERC20令牌标准中，每个令牌转移都必须记录Transfer事件，从而使链下应用程序知道发生了令牌转移。通过“监听”这些事件，我们可以执行任何（重新）操作。例如，当令牌转移到您的地址时，某些移动加密钱包会向您发送推送/电子邮件通知。

实际上，没有可靠的解决方案可以开箱即用地监听网络事件。不同的库允许您跟踪/侦听事件，但是，在许多情况下，某些事情可能出错，从而导致事件丢失或未处理。为了避免丢失事件，我们必须构建一个自定义后端，该后端将维护事件同步过程。

根据您的需求，实现方式可能会有所不同。但是在这里给你一个图片是如何根据微服务架构构建可靠的以太坊事件交付的选项之一：

将以太坊事件可靠地传递给所有后端服务这些组件以以下方式工作：

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

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

结果，每个后端服务仅获取所需的那些事件。此外，消息总线可确保将所有事件发布到事件总线后再进行传递。

当然，您可以使用其他方式代替消息总线：HTTP回调，套接字等。在这种情况下，您需要弄清楚如何确保自己提供回调：管理指数/自定义回调重试，实现自定义监视。

发布交易

为了将事务发布到分散网络，我们必须执行几个步骤：

• 准备交易。与交易数据一起，此步骤意味着请求网络状态，以查明此交易是否有效并且是否将要开采（以太坊中的gas估计）和交易的序号（以太坊中的nonce）。一些库试图在后台进行此操作，但是，这些步骤很重要。

• 签署交易。此步骤暗示私钥的使用。最有可能的是，您将在此处嵌入自定义私钥组装解决方案。

• 发布和重新发布事务。这里的关键点之一是，您已发布的交易始终有机会从分散的网络中丢失或丢失。例如，在以太坊中，如果网络的天然气价格突然上涨，则已发布的交易可能会被丢弃。在这种情况下，您必须重新发布事务。此外，您可能希望重新发布具有其他参数的交易（至少在汽油价格较高的情况下），以便尽快进行交易。因此，如果替换交易之前未进行预签名（使用不同的参数），则重新发布该交易可能意味着对其重新签名。

以上有关以太坊交易发布的要点可视化通过使用上述方法，您可以最终构建类似于以下序列图中所示内容的内容。

在这个特定的序列图上，我将演示（大体上！）区块链循环计费的工作原理：

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

• 负责特定任务的后端服务侦听收费限额事件并发布收费交易。

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

区块链循环计费工作原理的一般序列图，展示了后端服务与以太坊网络之间的交互后端安全和智能合约。

事务发布始终涉及使用私钥。您可能想知道是否可以保护私钥安全。有许多的、复杂的策略和不同类型的软件这样可以非常安全地将私钥存储在后端。一些私钥存储解决方案使用地理分布的数据库，而另一些甚至建议使用特殊的硬件。但是，在任何情况下，半集中式应用程序最容易受到攻击的地方是私钥被组装并用于签署交易的地方（或者在使用特殊硬件的情况下，触发交易签署过程的地点）。因此，从理论上讲，没有100％可靠的解决方案可以使防弹保护免受损害存储的私钥。