目录
Catalogue
Web 3.0 应用（即DApps）的架构与 Web 2.0 完全不同。 The structure of the Web 3.0 application (i.e. Dapps) is completely different from Web 2.0. 以一个简单的博客网站Medium为例，用户可以在这里发布他们自己的内容并与其他用户的内容互动。 Take a simple blog site, Medium, for example, where users can post their own content and interact with the content of other users. 作为一个 Web 2.0 应用，可能听起来会很简单，但仍有以下这么多特性构成了Medium的架构，才使得一切成为可能： As a Web 2.0 application, it may sound simple, but there are still so many features that make up the Medium architecture that make everything possible: 首先，必须有一个地方用于存储重要的数据，比如用户信息、帖子、标签、评论、点赞等等，这需要一个不断更新的数据库。 First, there must be a place to store important data, such as user information, post, labels, comments, praises, etc., which requires a continuously updated database. 其次，后端代码（使用Node.js、Java或Python等语言编写的）必须定义Medium的业务逻辑。比如当一个新用户注册时、发布一条新博客时 或 在其他人的博客上评论时，分别会发生什么。 Second, backend codes (in Node.js, Java or Python) must define the business logic of Medium. For example, what happens when a new user is registered, when a new blog is published, or when comments are made on another person’s blog. 第三，前端代码（通常用JavaScript、HTML和CSS编写）必须定义Medium的UI逻辑。例如，网页长什么样，用户跟页面上的每个元素交互时会发生什么。 Third, the front end code (usually written by JavaScript, HTML and CSS) must define the UI logic of Medium. For example, what the web page looks like, what happens when the user interacts with each element on the page. 把这些串联在一起，当你在Medium上写博客文章时，你跟它的前端交互，前端跟后端通信，后端跟数据库打交道。所有的这些代码都托管在中心化的服务器上并通过一个网络浏览器发送给用户（译者注：前端代码会通过网络发送到前端并在浏览器渲染，后端以接口形式对前端提供服务）。这是对现在大多数的 Web 2.0 应用如何运作的一个比较好的顶层抽象总结。? Combining these links, when you write blog articles on Medium, you interact with the front end, the front end communicates with the back end, and the back end deals with the database. All these codes are hosted on a centralized server and sent to users through a web browser (translation: the front code is sent through the network to the front end and rewrites it on the browser, and the back end provides the front end with an interface). This is a better top-level abstract summary of how most of the web 2.0 applications now work. 但所有这些都在变化之中。? But all of this is changing? 区块链技术解锁了一个激动人心的Web 3.0应用新方向。在本文中，我们将聚焦于以太坊区块链给我们带来了什么。 Block chain technology unlocks an exciting new direction for Web 3.0 applications. In this paper, we focus on what the Etherm block chain brings us. 是什么让 Web 3.0 如此不同？ What makes Web 3.0 so different? 不像Medium这样的Web 2.0应用，Web 3.0消除了中间人，没有中心化的数据库存储应用状态，也没有中心化的Web服务器承载后端逻辑。 Unlike Web 2.0 applications such as Medium, Web 3.0 eliminates intermediaries, has no centralized database storage application status and has no centralized Web server carrying backend logic. 取而代之的是，你可以利用区块链，在一个由互联网上匿名节点维护的去中心化的状态机上构建应用。 Instead, you can use the block chain to build applications on a decentralised state machine maintained by anonymous nodes on the Internet. 这里的“状态机”，指的是维护某个状态的机器，包括某个给定的程序状态和该机器上未来允许的状态。区块链就是由某个“创世”状态实例化，并有着非常严格的状态转移规则（即共识机制）的状态机。 Here, the “state machine” refers to a machine that maintains a state, including a given state of procedure and a future permitted state on the machine. The block chain is an example of a “inventive” state, with a state-of-the-state transfer rule (i.e., a consensus mechanism) that is very strict. 更好的是，没有一个单一实体可以控制这个去中心化状态机，因为他是由网络中的每个人共同维护的。 Better still, there is no single entity that can control this decentralised state machine, as it is maintained by everyone in the network. 那后端服务器呢？不像Medium的后端控制方式，在Web 3.0中，你可以编写定义了你的应用逻辑的智能合约，并将它们部署在去中心的状态机中。这意味着，每个想要构建区块链应用的人都在这个共享的状态机上部署他们的代码。 What about backend servers? Unlike Medium's backend control, in Web 3.0, you can create smart contracts that define your application logic and deploy them in a state-to-centre machine. That means that every person who wants to build a block chain application deploys their code on this shared state machine. 还有前端呢？几乎保持不变，除了一些我们后面将会介绍的特例之外。 What about the front end? It's almost the same, except for some of the exceptions that we'll introduce later. 现在架构大概长这个样子： Now the structure is probably like this: 现在，我们一起更深入地探究是什么让这一切成为可能。 Now, together, we look deeper into what makes all this possible. 1) 区块链 1) Block chain 以太坊区块链被誉为“世界计算机”。这是因为他是由点对点节点网络维护的全球可访问、确定性的状态机。该状态机的状态改变受网络中的节点间遵循的共识规则所约束。所以，换句话说，跟字面意思一样，它确实是被设计为世界上任何人都可以访问和写入的状态机。这就使得该机器不由任何一个单一实体独有，而是由网络中的每个人共同拥有。 In other words, as literally, it is a state machine that is designed to be accessible and accessible to anyone in the world. This makes the machine not unique to any single entity, but shared by everyone in the network. 我们还要知道一件事：数据只能写入以太坊区块链——你永远无法更新现有数据。 We also need to know one thing: data can only be written in the Etherkom block chain — you will never be able to update the available data. 2) 智能合约 2) Smart Contract 智能合约是以太坊区块链上运行的一个程序，它定义了区块链上发生的状态改变背后的逻辑。智能合约使用高级语言编写，比如Solidity或Vyper。 The smart contract is a program that runs on the Taiwan block chain, which defines the logic behind the change of status that occurs on the block chain. 因为智能合约的代码在以太坊区块链上存储，所以每个人都可以检查网络上所有智能合约的应用逻辑。 Since the code for smart contracts is stored on the Etherkom block chain, everyone can check the logic of all smart contracts applied on the network. 3) 以太坊虚拟机（Ethereum Virtual Machine, EVM） 3) Etherium Digital Machine, EVM 再往下，就是以太坊虚拟机，用于执行智能合约中定义的逻辑，并处理在这个全球可访问的状态机上发生的状态改变。 The next step is to use the Taiwan virtual machine to implement the logic defined in a smart contract and to deal with changes in the state on this globally accessible state machine. EVM不理解像Solidity和Vyper这些用来编写智能合约的高级语言。取而代之的是，你必须把高级语言编译为EVM可以执行的字节码。 EVM doesn't understand advanced languages like Solidity and Vyper, which are used to create smart contracts. Instead, you have to translate advanced languages into the bytes that EVM can execute. 4) 前端 4) Frontend 最后，是前端。如前所述，前端定义了UI逻辑，但是它也跟智能合约中定义的应用逻辑进行通信。前端和智能合约之间的通信比上图中显示的要复杂一些，接下来我们仔细看看这部分。 Finally, the front end. As mentioned earlier, the front end defines the UI logic, but it also communicates with the application logic defined in the smart contract. The communication between the front end and the smart contract is more complex than the one shown in the figure above. 我们希望前端可以与智能合约通信，这样才能调用函数，但是请回想一下，以太坊是一个去中心化的网络。以太坊网络中的每个节点都保存了以太坊状态机上所有状态的副本，包括与每个智能合约相关的代码和数据。当我们想要与区块链上的数据和代码进行交互时，我们需要与其中一个节点交互。这是因为任何节点都可以广播会在EVM中执行的交易请求，然后，矿工会执行该交易，并将状态改变传播到网络中的其他节点。 We want the front end to communicate with the smart contract so that we can call the function, but think back that Ether is a decentralised network. Each node in the ether network keeps a copy of all the states on the ether network, including the codes and data related to each smart contract. When we want to interact with the data and codes on the block chain, we need to interact with one of them. This is because any node can broadcast a request for a transaction that will be executed in the EVM, and then the mining union executes the transaction and transmits it to the other nodes of the network. 有两个方法广播一个新交易： There are two ways to broadcast a new deal: 如果你使用第三方服务，则不必头痛于自己运行一个全节点。毕竟，在你自己的服务器上构建一个新的以太坊节点可能需要几天的时间。（有很多数据需要同步——这甚至会占有比典型笔记本电脑能正常处理的更多带宽和存储空间） If you use a third-party service, you don't have to have a headache running a full node. After all, building a new ether node on your own server may take a few days. (There's a lot of data that needs synchronization -- this would even hold more bandwidth and storage space than typical laptop computers can handle normally.) 此外，随着Dapp的规模逐渐扩大，存储完整以太坊区块链的成本也会增加，并且你需要增加更多节点来扩展你的基础设施。这就是为什么，随着基础设施愈加复杂，你需要全职的DevOps，他们会帮你维护基础设施，以确保可靠的正常运行时间和快速响应时间。 In addition, as the size of Dapp gradually expands, the cost of storing completeness will increase, and you will need to add more nodes to expand your infrastructure. That is why, as infrastructure becomes more complex, you need a full-time , they will help you maintain the infrastructure to ensure a reliable running time and quick response time. 可以说，避免这些头痛是许多DApp选择使用Infura或Alchemy之类的服务来管理他们的节点基础设施的原因。当然，这是一个权衡，因为这会产生一个中心化的卡点，但是我们暂时先不讨论这个难以摆脱的难题。;) It can be said that avoiding these headaches is why many Dapps have chosen to use services such as Infoura or Alchemy to manage their nodal infrastructure. Of course, this is a trade-off, because it creates a central card point, but for the time being we will not discuss this difficult problem;) 继续往前，我们来谈谈Providers（提供商）。当你需要与区块链交互时，你连接的节点（无论是你自己建立的还是使用第三方服务提供的现成节点）通常被称为“providers”。 Moving on, let's talk about Providers. When you need to interact with the block chain, the nodes you connect (whether you build them yourself or off-the-shelf nodes using third-party services) are commonly referred to as “providers”. 每个以太坊客户端（即provider）实现了一个JSON-RPC规范。这确保了当前端应用想要与区块链交互时，可以有一套统一的方法。如果你需要JSON-RPC的入门介绍，简单来说，它是一个无状态的、轻量级的远程过程调用（Remote Procedure Call, RPC）协议，定义了一些数据结构及其处理规则，它跟传输协议无关，所以这个概念可以在进程内通信、socket通信、HTTP通信或各种消息传输环境中使用。它使用了JSON（RFC 4627）作为数据格式。 Each 一旦你通过一个provider连接上了区块链，你就可以读取存储在链上的状态。但是如果你想要写入状态，在提交交易到区块链之前，你还需要做一件事——使用你的私钥对交易进行签名。 Once you connect to the block chain through a provider, you can read the state stored on the chain. But if you want to write to the state, you need to do one thing before submitting the transaction to the block chain -- signing the transaction with your private key. 例如，想象一下我们有一个DApp，用户可以在上面阅读博客或发布博客到区块链上。前端可能会有一个按钮，允许任何人查询特定用户写的博客。（回想一下，从区块链读取数据不需要用户对交易签名。）但是，当用户想要发布一个新帖子到链上时，DApp会要求用户使用他们的私钥对交易进行“签名”——只有这样，Dapp才会把交易转发到区块链上。否则，节点不会接受这个交易。 Imagine, for example, that we have a DApp on which users can read their blogs or post them on the block chain. There may be a button at the front end that allows anyone to consult a particular user’s blog. (Recall, reading the data from the block chain does not require a user’s signature on the transaction.) But, when users want to post a new post on the chain, DApp will ask the user to “sign” the transaction with their private key – and then Dapp will forward the transaction to the block chain. Otherwise, the node will not accept the transaction. 说到签名，就是?Metamask 大展身手的时候了。 Speaking of signatures, is that it? . Metamask是一个工具，可让应用程序轻松处理密钥管理和交易签名。它非常简单：Metamask将用户的私钥存储在浏览器中，每当前端需要用户对交易签名时，它会调起Metamask。 Metamask is a tool that allows the application to easily handle key management and transaction signatures. It is simple: Metamask stores the user's private key in the browser, and when each current end requires a user's transaction signature, it raises Metamask. Metamask也提供了与区块链的连接（作为一个provider），因为它已经与Infura提供的节点有连接（因为对交易签名时需要Infura（译者注：实际上签名的操作并不依赖Infura，只是Matamask在签名之前可能需要从Infura读取预估Gas等信息，另外，如果是通过Metamask来发送交易，Metamask自然也需要连接到Infura提供的节点））。这样，Metamask既是provider又是signer（签名者）。 Metamask also provided links to the block chain (as a provider) because it was already connected to the node provided by Infoura (because Infoura was required to sign the transaction: In fact, the operation of the signature was not dependent on Infoura, it was only that Matamask might need to read information such as Gas from Infoura prior to signing, and that if the transaction was sent through Metamassk, Metamassk would naturally also need to be connected to the node provided by Infoura) so that Metamassk was both provider and signer (signer). 当然，如果你构建一个应用，这个应用的所有智能合约和数据完全承载在以太坊区块链上，也是行得通的。但是，任何在以太坊上构建过应用的人都知道，把所有内容存储在区块链上真的很昂贵，（即便）也很敏捷。 Of course, it works if you build an application, and all the smart contracts and data for this application are completely embedded in the Etherm block chain. But anyone who has built an application in Ethern knows that it's really expensive to store all the content on the block chain, even if it's very agile. 请记住，使用以太坊，用户每次往区块链增加新数据时都要付费。这是因为在去中心化状态机上添加状态会增加维护该状态机的节点的成本。使用你的Dapp，每次用户的交易需要增加一个新状态时，都要求用户额外付费，这不是最佳的用户体验。一个减轻这种情况的方法是使用一个去中心化的链下存储解决方案，例如 IPFS 或 Swarm。 Remember, the user pays for adding new data to the block chain using the portal. This is because adding status to the decentralised state machine increases the cost of maintaining the node of the state. Using your Dapp, when each user's transaction requires a new state, the user is required to pay extra fees. This is not the best user experience. One way to mitigate this is to use a decentralized chain storage solution, such as IPFS是一个用于存储和访问数据的分布式文件系统。因此，IPFS系统不是将数据存储在一个中心化的数据库，而是将数据分布并存储在一个点对点的网站中，这使得你可以在需要时轻松地获取数据。 IPFS is a distributed file system for storing and accessing data. Therefore, IPFS does not store data in a centralized database, but rather distributes and stores data on a site with a point-to-point site, which allows you to easily access data when needed. IPFS还有一个称为“Filecoin”的激励层。激励层激励世界各地的节点存储和检索这些数据。你可以使用Infura（为你提供IPFS节点）或Pinata（为你提供易于使用的服务，你可以把你的文件“pin（固定）”到IPFS，获取IPFS哈希并将其存储在区块链上）之类的提供商。 IPFS also has an incentive layer called "Filecoin ". The incentive layer motivates nodes around the world to store and retrieve these data. You can use Infura (to provide you with an IPFS node) or Pinata (to provide you with easy-to-use services, you can get your file "pin (fixed)" to IPFS, get IPFSH and store it on the chain of blocks). Swarm的相似之处在于它是一个去中心化的存储网络，但有一个显著的区别。Filecoin是一个独立的系统，而Swarm的激励系统是在以太坊区块链中内置并通过智能合约强制执行的，用来存储和检索数据。 The similarity of Swarm is that it is a decentralised storage network, but there is a significant difference. Filecoin is an independent system, while Swamm’s incentive system is built in the chain of the Taiwan blocks and enforced through smart contracts to store and retrieve data. 所以到现在为止，加上IPFS或Swarm，我们的应用架构如下所示： So to date, plus IPFS or Swarm, our application architecture is as follows: 敏锐的读者可能也在下面的图中注意到了，前端代码并没有存储在区块链上。我们可以像在Web 2.0中那样在AWS上托管此代码，但那样就给你的DApp制造了一个中心化的卡点。如果AWS宕机了怎么办？如果它审查你的应用怎么办？ A keen reader may have noticed in the graph below that the front-end code is not stored on the block chain. We can host the code on the AWS like in Web 2.0, but then make a central card point for your Dapp. What if the AWS crashes? What if it reviews your application? 这就是为什么，如果你想要构建一个真正去中心化的应用，你应该选择把你的前端托管在一个去中心化的存储方案，比如IPFS或Swarm。 That's why, if you want to build a truly decentralised application, you should choose to host your front end in a decentralised storage program, like IPFS or Swamm. 所以现在应用架构看起来更像是这样： So the application now looks more like this: 到目前为止，我们讨论了如何通过签名并向区块链发送交易，从而向区块链写入数据。但是怎么从区块链智能合约读取数据呢？有两种主要的方法： So far, we have discussed how to write data to the block chain by signing and sending transactions to the block chain. But how to read the data from the block chain smart contracts? There are two main ways: 1) 智能合约事件 1) Smart Contract Event 你可以使用Web.js库来查询并监听智能合约事件。你可以监听特定的事件并指定一个每次触发事件时的回调。例如，如果你有一个智能合约，该合约发送一个从A到B的连续的支付流（在每个区块），那么你可以在每产生一笔向B的新支付时发布一个事件。你的前端代码可以监听该智能合约触发的事件，并基于此执行特定的行为。 You can use Web.js library to query and listen to smart contract events. You can listen to a given event and specify a callback for each trigger event. For example, if you have a smart contract that sends a continuous payment stream from A to B (in each block), you can post an event every time you generate a new payment to B. Your front-end code can listen to an event triggered by the smart contract and execute a specific act based on it. 2) The Graph 上面的方法是有效的，但它有一些局限性。例如，如果你在部署一个智能合约之后才意识到你需要发布一个原先没包含的事件，该怎么办？不幸的是，你不得不重新部署一个新的包含该事件和数据的智能合约。此外，使用回调来处理各种UI逻辑很快会变得相当复杂。 The above approach works, but it has a number of limitations. For example, what happens if you realize that you need to release an event that was not originally included before you deploy a smart contract? Unfortunately, you have to redeploy a new smart contract that contains the event and data. Moreover, the logic of using echoes to handle various UI logics will soon become quite complicated. 这就要“The Graph”出场了。 This is "The Graph. The Graph是一个链下的索引解决方案，它使得在以太坊区块链上查询数据变得更加容易。The Graph允许你定义要索引哪些智能合约，要监听哪些事件和方法调用，以及如何将传入的事件转换为前端逻辑（或任何使用该API的对象）可以消费的实体。它使用许多前端工程师都喜欢的GraphQL作为查询语言，因为它比传统的REST APIs更具表达性。 The Graph is a chain-based index solution that makes it easier to search data on the Ether section chain. The Graph allows you to define which smart contracts you want to index, which events and methods you want to listen to, and how to convert incoming events into forward logic (or any object that uses the API) that can be consumed. It uses GraphQL, which many front-end engineers like, as a query language, because it is more expressive than the traditional REST APIs. 通过索引区块链数据，The Graph让我们可以在应用逻辑中低延迟地查询链上数据。 By indexing block chain data, The Graph allows us to search the chain with low delay in applying logic. 现在，应用架构如下所示： The application structure is now as follows: 我们差不多快结束了，但是还剩一个主要的话题：扩容。 We're almost done, but there's one major topic left: magnification. 你可能已经有所耳闻，以太坊不具备扩展性——至少目前还没有。 You may have heard that the Ethio is not expansionary — at least not yet. 以太坊的平均gas价格 The average gas price in the district. 平均交易手续费 Average transaction fees 平均区块大小 Average block size 很明显，这会有一个问题。在有着高gas费和全量区块的以太坊上构建一个DApp导致了非常糟糕的用户体验。值得庆幸的是，有一些解决方案正在开发中。 Clearly, there's a problem. Building a Dapp on an Etheria with high gas fees and full blocks has led to a very bad user experience. Fortunately, some solutions are being developed. 一个流行的扩容解决方案是 Polygon，一个L2（layer 2，二层链）扩容方案。Polygon没有在主链上执行交易，而是使用“侧链”来处理并执行交易。侧链是与主链链接的二级区块链。每过一段时间，侧链将其最近区块的聚合提交给主链。 A popular maturation solution is , a L2(layer2, 2-storey) magnification program. Polygon does not execute transactions on the main chain, but uses "side chains" to handle and execute transactions. 另外一些L2解决方案的例子有?Optimistic Rollups 和 zkRollups。这里的思路是类似的，在链下使用一个“rollup”智能合约把交易分批打包，然后定期地把这些交易提交到主链上。 Other examples of L2 solutions are: . The idea here is similar, using a "roundup" smart contract to sub-pack these deals on a regular basis. 值得我们吸收的思想是：L2解决方案在链下执行交易（即比较缓慢的部分），链上仅保存交易数据。这使得我们可以拓展区块链，因为我们不必在链上执行每笔交易。这也使得交易更快，更便宜——并且在必要时交易仍然可以与以太坊主链进行通信。 The idea that we should absorb is that the L2 solution is to carry out the transaction (i.e., the slower part) under the chain, with only data on the transaction. This allows us to expand the block chain, because we do not have to carry out every transaction on the chain. It also makes the deal faster and cheaper – and, if necessary, the transaction can still communicate with the Ether main chain. 如果这一切让你感到头昏脑胀，那你不是孤身一人。把所有这些工具拼凑在一起非常复杂，会带来非常痛苦的开发体验。但是请放心——我们开始看到新的开发者框架，这些框架确实地改善了开发者的体验。 You're not alone if it makes you lose your mind. Combining all these tools together is very complicated, with very painful developmental experiences. But rest assured -- we're beginning to see a new developers' framework that actually improves the developers' experience. 例如，Hardhat?就是一个开发者框架，使以太坊开发者更容易构建、部署和测试他们的智能合约。Hardhat 提供了“Hardhat网络”，开发者可以利用它把智能合约部署在一个本地网络上——而无需处理真实的网络环境。更好的是，它还提供了一个非常不错的 插件生态，使开发者更加轻松。Hardhat也提供了类似 javascript 的 console.log() 方法，用于调试。 For example, is a framework for developers that makes it easier to construct, deploy and test their smart contracts. 当然，这只是一个开始。希望在将来我们能继续看到更好的开发者工具。 Of course, it's just the beginning. I hope we can continue to see better developers' tools in the future. 大多数人花了几个月的时间来弄清工具链的是如何工作的，所以如果你是一名新的DApp开发者，希望本文为你节省了一些时间。 Most people spend months trying to figure out how the tool chain works, so if you're a new Dapp developer, hopefully this paper will save you some time. Web 3.0 的核心是去中心化，这也是与 Web 2.0 最本质的差别。而去中心化，则要求由分布式网络来维护系统状态，并且分布式网络需要由不同利益方维护的节点构成。 The core of Web 3.0 is decentralisation, which is the most fundamental difference from Web 2.0. Decentralization requires a distributed network to maintain the system state and a distributed network to be composed of nodes maintained by different stakeholders. 另外，一个可以执行自定义逻辑的通用虚拟机也是非常重要的，这使得各式各样的应用在 Web 3.0 生态中百花齐放成为可能。我们把可以在这个虚拟机上执行的代码叫智能合约。 Also, a universal virtual machine that can implement custom logic is very important, making it possible for a variety of applications to be applied in the web 3.0 ecology. We call the code that can be implemented on this virtual machine a smart contract. 在应用层面，前端在调用智能合约时，需要与网络中的其中一个节点进行通信，最符合去中心化的做法是应用自己部署一个区块链节点，成为去中心化网络中的一员，但这无疑加重了开发人员的工作量。另一个更轻量的方式是选择一个第三方供应商提供的节点，如Infura等。但后者有中心化的风险，所以需要根据实际情况做权衡。无论是以上哪种情况，被连接的节点，都称为Provider，每一个Provider都需要实现一套标准接口（Ethereum JSON-RPC Specification），用于读写区块链数据。 At the application level, the front end is required to communicate with one of the nodes in the network, most in line with decentralisation, by deploying itself a block chain node and becoming a member of the decentralised network, but this certainly increases the workload of the developers. Another lightly way is to select a node from a third-party supplier, such as Infoura. The latter, however, has a central risk, so it needs to be weighed according to the circumstances. In either case, the node connected is called Provider, and every node connected is required to achieve a standard interface ( 对于应用的用户管理，稍不同于 Web 2.0 的中心化存储用户信息和密钥，区块链上的每个用户使用一个地址唯一标示，每个地址对应一个私钥。想使用某个地址作为交易的发送方时，都需要使用对应的私钥进行签名。所以只要拥有某个地址的私钥，就可以在不同的应用上，使用该地址发送交易。但假如我们有10个应用，是不是需要在使用每个应用时，都输入我们的私钥呢？暂且不讨论安全性，用户使用的便捷性已经成为了一个问题，毕竟，可能每个应用都是使用同一个私钥，重复输入只会消耗用户的耐心。那有没有一个统一的方法来管理私钥呢？这就是类似Metamask这样的钱包做的事情，用户只需要在钱包输入一次私钥（实际操作可能是导入助记符），每个应用在需要使用私钥签名时，都会调起钱包。另外，钱包本身也有一些简单的功能，比如显示用户余额、转账等。 For the user management of the application, it is slightly different from the centralized storage of user information and keys in Web 2.0. Each user in the block chain uses a single address and each address corresponds to a private key. To use an address as the sender of the transaction, a corresponding private key is required to sign it. So as long as you have an address's private key, you can send a transaction with it in different applications. But if we have 10 applications, we need to enter our private key when using each application. For the time being, without discussing security, the user's ease of use has become a problem. After all, each application may use the same private key and re-entry will only consume the user's patience. 在数据存储方面，由于区块链上存储数据需要全网共同维护，非常昂贵，所以可以选择把部分数据存储在IPFS/SWARM等链下去中心化存储中，这些存储使用激励等方式来保证数据的安全性。 In terms of data storage, since data stored on block chains need to be maintained on a web-wide basis and are very expensive, it is possible to choose to store part of the data in a centralized chain such as IPFS/SWARM, which provides incentives for data security, among other things. 在数据查询方面，可以直接调用Provider的读接口直接读取区块、交易、合约数据和事件等，但这相比传统的中心化数据库有非常大的弊端，就是缺少索引，无法快速地读取到想要的数据。所以The Graph这样的链下索引服务也就应运而生，应用可以使用它更方便快捷地索引到想要的数据。 In terms of data queries, the Provider reading interfaces can be accessed directly from blocks, transactions, contract data and events, but this is a very significant disadvantage compared to the traditional centralized database, which lacks an index and does not quickly access the desired data. So the index service under the chain such as The Graph should be created, and it can be used to index the desired data more quickly. 区块链经常被诟病的就是性能问题。已经有一些 Layer 2 方案陆续被提出并部分已付诸实践，通过交易在二层链执行，主链仅记录压缩的交易数据，可以在避开主链昂贵手续费和较大延迟的同时，又能享受主链带来的安全性保障。另外，以太坊计划在2022年将共识算法从POW升级到POS，这也会是性能优化的一个非常重要的里程碑。 There are a number of Layer 2 programs that have been proposed and partially put into practice, through which transactions are carried out in a two-tier chain, where only compressed transaction data are recorded, and where security guarantees from the main chain can be enjoyed while avoiding high transaction costs and significant delays. Moreover, the plan of the Etherpan to upgrade consensus algorithms from Pow to POS by 2022 would be a very important milestone in performance optimization. 最后，对于开发人员来说，可以使用Hardhat、Truffle、Remix等工具，来提高DApp应用开发的效率。 Finally, for developers, tools such as Hardhat, Truffle and Remix could be used to improve the efficiency of Dapp application development. 如果有任何疑问或发现文中的任何错误，欢迎评论交流！:) If there is any doubt or any error in the text, the exchange of comments is welcome! 记录下原文中几个有意思的短语： To record several interesting phrases in the original text: rabbit hole: 用于表示一个离奇的、令人迷惑的或者荒诞的情况或环境，通常难以从中解脱。 take-home: take sth. home 可以表示吸收/记住会议上的想法、观点或概念。文中使用“-”连接两个单词使其成为形容词，可理解为“值得吸收的”。 take-home: take sth. home.
注册有任何问题请添加 微信：MVIP619 拉你进入群
打开微信扫一扫
添加客服
进入交流群
发表评论