Opinion: The future of the blockchain client will be in full bloom

The current author works at Parity Technologies and is working on building blockchain clients. Blockchains are attractive in many ways, especially from a software engineering perspective. Working on a blockchain client means interacting with all levels of the software stack, high or low.

At the lowest level, you need to do assembly optimization, writing compilers and virtual machines (VMs). You work through the network and the database. Finally, at the highest level, you'll deal with issues like open source organizations and how to organize code in a large, complex application.

This article will focus on a higher level, how do we manage the complexity of the application?

The authors want to add a little bit of introductory knowledge about blockchain clients and how they interact in the ecosystem over time. The blockchain (usually) begins with the protocol and is specified by a protocol specification.

Bitcoin starts with a white paper, followed by a C++ implementation. This C++ implementation has become the norm for protocols, and the true multi-client ecosystem has never been promoted.

However, in a blockchain such as Ethereum, there are multiple clients from the very beginning. There is a community consensus about what the agreement should be, not the yellow book and other norms defined by any implementation. But this does not take into account which type of client can or should be considered.

• With 25% layoffs, Messi can't save the world's "first" blockchain phone!
• Do not understand technology? Talking about project investment opportunities from the operational level
• Research Report | Trading Platform's Liquidity and Market Pricing Standards

This article will focus on Ethereum, so the author will mainly focus on this perspective. In the early days of blockchain life, there was a client that could do anything. All blockchains were run on top of this client, which is understandable.

At that time, the blockchain and state were small enough that synchronization was not a problem and almost no resources were used. Everyone runs a full node, so there is no need for light clients, and there isn't a large service industry in this chain that has different needs from the client.

However, as the chain grows and its ecosystem grows, it makes no sense to have a software that can do everything. In our early research on Ethereum, we learned that nodes should not be responsible for managing private keys. If the user has a networked software that also manages the user's private key, it will be a disaster (many related disasters have already occurred).

As we continue to grow, the author believes that we will see the emergence of a large number of professional clients. The Ethereum client is mainly responsible for the following tasks:

• As a light client (does not store complete state information), allowing users to interact with the network;
• As a full node, store complete state information and all history records;
• As a file node, you can create custom indexes and data sets to check past status;
• Handling data requests from nodes via JSON-RPC
• Provide data for mining software;
• Broadcast blocks and transactions;

The problem here is that in a mature ecosystem, almost no user wants to do all of the above.

How will this affect the complexity of the software?

Building a blockchain client that does all of these tasks is a huge task that takes years of technical work. Parity's Ethereum code base is expected to contain a total of approximately 500kloc lines of Rust code. (Note: kloc ie kilo lines of code, thousand lines of code)

But the number of lines of code is not the best sign of complexity. As an open source project, we saw that you are trying to join the project, whether it is inside or outside Parity. Based on experience, it takes about 3 months to make the code base productive, and then you certainly still don't fully grasp it. What I want to say is that there are only a total of 10 people in the world who know all aspects of the Ethereum client. The situation with Bitcoin can be said to be worse because it has only one implementation. We have built a Bitcoin client, and the number of strange corner cases and bugs in the C++ implementation is surprising. Since there are no multiple (active) implementations, these vulnerabilities have never been discovered and have become part of Bitcoin now.

What can we do about this?

The author believes that in the future, blockchain will become commonplace and the ecosystem will become more mature, without a client can do all of this. It is likely that the miner will run one type of client, such as an archiving service such as a block explorer that will run another client, while the end user will run a light client (perhaps in a mobile app) . For those who want to profit by providing data to light clients or storing historical block data, more roles will be introduced on the blockchain network.

There are two main arguments about why this happens. First, this is the only way to handle complex and large-scale core development, which is necessary if we want to have a well-functioning and mature ecosystem.

The second is economic issues. Whether it is Ethereum or Bitcoin, core developers are currently unable to make money. This is a typical "tragedy of the commons" where everyone uses the software, but no one feels responsible for it, or specifically wants to spend money on it.

The author believes that we can't get rid of this tragedy of the commons unless we implement the client's specialization and begin to introduce economic models into the use of software. Because all are open source software, you can always remove any hard-coded economic model, but the authors think this is not a problem.

From what the authors observe today in many ecosystems, core development efforts are often supported by team-providing advisory services or funding from generous donors. But this is not sustainable. For most core development teams, engaging in consulting work is distracting, and this is not what they want to do. This is where professional blockchain clients can make a difference.

Blockchain client type & how to profit from the client

• Miner client

Currently, miners don't think they should pay for using a blockchain client because the client is open source and good for everyone. But what if there is a blockchain client that specializes in serving miners? This client may have a small flag that allows you to set a contribution rate, and the default value can be set to pay $1 for each block.

If Parity receives $1/block revenue from the Ethereum main network through the Parity client, the company will receive more revenue than any commercial project and grant it receives. More importantly, it will give Parity a sustainable and predictable source of revenue, as long as the Parity client is used by miners and is valuable. But the problem is that for miners, a client will probably be far superior to other clients trying to provide the best service for everyone, so the benefits of the multi-client ecosystem will be lost. Save.

If you are concerned about mining use cases, you can make basic changes to how the nodes operate. You can manage merkle-trie in a completely different way. You don't need to access the data through trie to synchronize or serve the light client, just generate a merker-root. You can make completely different assumptions about resource usage, such as requiring miners to have 32GB of memory, while light client users don't need to.

You won't need to manage RPC at all, and you can eliminate the whole complexity for this. The miners will need to go to work and report the excavated blocks, which are two endpoints. You can increase your competitiveness by including mining pool software in your client, the tools you need to deploy a tiered server, and more. These are not related to the average user and are not part of the "applicable to everyone" blockchain client category.

To solve the problem of all miners using the same mining software, you can measure rewards based on the distribution of mining software, encourage more participants, or no one has any rewards. You can also play other smart economic games here, but they all require very complex protocol layer changes, which can cause other side effects. The author is still unclear how to solve this problem unless he wants economic competition in the market to be unfavorable to it.

• Light client

Light clients need a way to interact with the network to request data. It needs to validate Merkle proofs and PoW hashes, after which it needs a set of RPC methods to pass to the application that uses the light client. This information, whether the app is a Dapp or a wallet app.

Conceptually, this is much simpler than anything else. In practice, there are a lot of overlaps between the light client and the full node in RPC, which we will discuss later.

The problem with light clients is that they currently rely on altruistic behavior. No one has any reason to serve the light client. It doesn't enhance the network (which is why you want to broadcast blocks and transactions), so you have no reason to do this. Ideally, users of the light client will use a light client server to open a payment channel and send a micropayment for each request they send.

In addition, you can let the light client open a channel to the software manufacturer and send one thousandth of the micropayment to the software manufacturer (or any other appropriate rate, or the user may choose). Suppose a light client has a large and healthy ecosystem of millions of mobile light client users, which can generate considerable revenue.

• Full node

In terms of the complexity of writing and maintaining, the whole node has always been the most complex software, because the whole node needs to do the most work. But there are still things that they don't need to do: they don't need to be light clients, and they don't need to deal with mining and block generation.

They need to be able to send, receive, and verify data on the network. They also need to be able to serve light clients. They can get paid for serving a light client. Similar to a light client, a software manufacturer can also extract a portion of the profits (usually optional).

We can imagine a lot of complexity by eliminating the RPC interface. There is basically no other way to interact with a node other than through a light client. This can have a negative impact on performance (especially for DApps that are not optimized for light clients). Advanced users may want to be able to interact directly with the full node for optimal performance. However, it's easier to add a "local" interface (such as an IPC or similar interface) between the light client and the full node, so if you are an advanced user, you can run both interfaces at the same time, and the light client is still Fully responsible for the complexity of the RPC interface.

There are also some notions for simplifying the interface and proposing a better structure around generating GraphQL, and generating GraphQL can be either "client" (between user and node) or "server" ( Between nodes).

• File node

An archive node is an interesting example because it has no use on blockchain networks and is often merged with full nodes. The archive node handles a lot of extra complexity because it is accompanied by higher resource usage.

Bitcoin does not have a node similar to a file node, but the block browser still needs to create its own file node. In the past, the author suggested removing the archive node from the main client and letting the users who use it build their own version. Currently, this is clearly not welcomed by those who rely on archival node software.

A file node is a full node that can quickly retrieve historical data, build additional indexes, and store intermediate states. For those who build the full node described above, there is an opportunity to add a "hook" so that "all processed transactions can be sent to the Elasticsearch search backend". Archiving services are becoming more and more complex, and there are now some services that do not use the built-in archiving mode at all. They use full-node RPC to extract data and stuff it into Kafka or something like it for processing.

We can imagine a software that interacts with the network to get data. It then gives the external indexer and data source the flexibility to get the data and process it.

In either case, it is difficult to charge because there is no chain transaction or chain payment during the period. The author believes that a good archival software will be a great example of a closed source proprietary software because it is essentially an analytical tool.

This type of software has many consumers. Block explorers is the Infura of the blockchain world, which provides data to end users without the need to go through networks or analysts or researchers who study blockchain trading patterns or behaviors. They all have different needs, but it's best to meet these needs by building software that connects to existing databases and tools, so that no one else needs to do anything other than them.

• Historical archivist

This role doesn't exist yet, but the author thinks this is why many people confuse file nodes with other nodes. In Ethereum, a full node stores all historical data, but it does not need to do this.

In fact, the entire node does not need to store more than the last 100 blocks of data to achieve the purpose of finalizing the block. Removing other data can save 100 GB of storage capacity for all nodes. There is currently no way to remove this data while ensuring the availability of historical data. When there has been some related discussion, the data will be placed in IPFS (interstellar file system), and the data of several people interested in it will be fixed on IPFS.

Of course, this is the same situation as a light client who needs altruistic actors. Ideally, we can come up with an incentive to store this historical data so that at least some economic guarantees can use it. One can imagine using an interoperable network to store this data on one of a number of blockchains that are specifically tailored to store large amounts of data for long periods of time.

Then we can solve this problem and eliminate the need to store all historical data records for all nodes. The question is who will pay for it because ensuring data availability is not the responsibility of a single entity. It will have to pay through inflation, which requires a difficult and potentially controversial consensus change.

The road to the future

The author personally believes that the future of the blockchain is the proof of rights (PoS). This is not to say that the proof of work (PoW) will disappear. PoW is an amazing invention, and Bitcoin will always use it. The new blockchain will use the PoS mechanism and may use PoW for special anti-witch attacks, such as VDF (verifiable delay function) or VRF (verifiable random function) (authors tend to classify it as PoW) PoW is used in a subset of).

We have seen some PoS attempts in the blockchain world, but they are usually very simple. In more complex PoS designs, we have seen a trend to divide the protocol into many new roles.

There is a validator in the PoS mechanism to replace the miner, but sometimes there is a nominator or a delegator. In blockchains such as Bitcoin, we see many new characters appearing on the second level, such as the lightning tower's watch tower. The author believes that the above layout is equally applicable to the PoS world.

The verifier has completely different interests and needs than the full node. The functionality of the full node is also very different from the light client.

When building software for the first time, it's much easier to build everything into a whole, and a few people who understand the entire design can do everything in one place and make sure everything is consistent from day one. Effective. If you try to build this de-architecture in a decentralized way from the first day, I am almost certain that you will pick up your own feet.

We have been in Ethereum for 5 years, and we are now beginning to clearly see these users and their needs. No one can predict on the first day that almost the entire Ethereum user base will interact with the network through a centralized service. In another five or ten years, the authors believe that we will witness the rise of these specialized clients for all next-generation blockchains.

The question is whether we will see if these clients will target Bitcoin and Ethereum as they do today. The author is skeptical because it involves a lot of work, but the profitability of it will probably encourage more people to get involved.

Reference link:

Https://medium.com/@folsen/the-future-is-a-myriad-of-blockchain-clients-d05e1d7ac181

Author | Fredrik

Source | Medium

Compile | Jhonny

We will continue to update Blocking; if you have any questions or suggestions, please contact us!