How to choose a distributed system (blockchain) protocol?

When building applications that package distributed system functionality, Fortune 500 companies and founders often ask us the question: "What kind of protocol should we build?" "This problem is becoming more common because all The agreements that were funded in 2017-2018 are all trying to move from white papers to test networks and then to the main network. These new agreements are full of incubators, venture capital firms, co-working spaces, conferences, etc., looking for start-ups to build on their platforms. It can be overwhelming. So choosing the right protocol is as important as deciding how to lay the foundation for a tall building.
This first article is very high level and is designed to give you some useful guidelines. Future articles will cover the technical details of more key protocols. This is a complicated topic, so you can always send us a message suggesting editing.

1. Select a platform (Hyperledger / Quorum / Ethereum / Bitcoin / corba - r3). I will begin your exploration of the agreement by examining these. To the best of our knowledge, they are currently accelerating adoption and community development. If you are a start-up, you are already considered to be slightly more risky for your business customers. Therefore, you may wish to build an agreement that is already useful in production. Future articles will provide a more in-depth comparison. Keep in mind that these are not perfect, especially in terms of scalability and security.

2. Philosophically decide whether you believe in open networks or closed networks: This topic can be the subject of 10 articles alone. So far, we have seen that closed networks are more popular than open ones in enterprise use cases, but we hope to see winners in both areas. Now, the blockchain/distributed system community works in the split between open and closed, but as the space matures, and as the protocol begins to define transactions and business logic at the atomic level (rather than at the "network" level) The privacy and confidentiality of this may become a historic footnote. This means that a private transaction on the network can set its own permissions, and a smart contract can interoperate with other smart contracts based on its internal scope without being restricted to a general ledger of a "network." Opening and closing at the network level becomes a meaningless clause.

3. There are a number of emerging, well-funded agreements, and other operational layer innovators are worthy of attention. We saw early germinations of Hashgraph (for game-like TPS use cases), EOS (also including games), VEChain (supply chain), and Skale (scalability). We very much hope that companies will have new agreements, but we have not seen them in the customer dialogue. We also saw a wave of interesting sidechains and “second layer” innovation. Our favorite is the lightning network. We wouldn't be surprised if Square launches a product that uses Lightning Networks in the next 18 months.

4. As an architect of “union-related parties”. We are in the early stages of a new wave of distributed systems platforms, and it is too early to decide who is the winner. For example, if Ethereum is able to deliver plasma and other projects at the promised time and move to PoS, this will be a good long-term bet. It is important to remember that different protocols are more or less relevant, depending on the specific use case.

5. Be aware of open-ended questions that don't have a good answer yet. As mentioned earlier, we are in the early stages of enterprise adoption and have many problems/not being adequately addressed. This includes scalability, security, data transfer, legacy system integration, data residency compliance, and more.

6. Know where the developer is. To the best of our knowledge, 70-80% of blockchain/distributed system developers are proficient in superclassification and solid/Ethereum, with some overlap between the two. If you are choosing a non-Leadership agreement, you may have to work very hard to find developers or give them a cold start training. This may be a good decision. No matter what distributed developers know today, they must learn something new tomorrow. Therefore, you may not need to choose one based on someone's current chain code skills or reliability. Just hire a good developer who likes to learn.

7. Be cautious when choosing a large company blockchain platform. We are happy to see that almost every major technology company (Amazon, IBM, Microsoft, SAP) has launched a BaaS ("blockchain as a service") deployment platform for blockchain and believes it will help Accelerate the adoption of enterprises. but. Due diligence is extremely important! Most of the companies listed above have a history of working with start-ups and successful companies based on them. But not all. Ask other founders/CTOs which companies are better collaborating and which are having problems. Don't let some free developer points around you making the wrong choice. They may be building a future competitor! Another option is based on an independent BaaS (blockchain as a Service) company like www.blockdaemon.com.

8. Understand the dynamics of open source and protocol governance. Different protocols have very different open source frameworks and governance, and these frameworks and governance can have a huge impact on how they operate, whether hard forks occur (which can lead to a lot of complexity). Including understanding that someone says "it's open source" means that the code they actually run at runtime is zero. Before compiling, it's easy to get open source and insert some malware into it. Open source is very good, very important, and helps to spot bugs, but don't mistake it for security. Know who compiled the code and make sure it's best for all kinds of signature runs. The parties are required to accept this service and become the signing agent for the approved open source code base that meets its specifications. Obtaining a signature-approved runtime will ensure that the nodes of the parties are actually open source.