Blockchain Wave Lab

Why choose Fabric for enterprise application development?

2018-11-12 15:27:19

Ethereum's smart contract development has gained traction recently. However, few enterprise-level blockchain applications choose Ethereum for development. Based on experience in actual project applications, I think Ethereum is not suitable for enterprise-level applications for three reasons: inadequate permission control; the high technical threshold and cost of checking and correcting Ethereum smart contract errors; and the uncertainty of calling Ethereum smart contracts. Fabric has a great advantage in these aspects which I will elaborate on below.

1. Multi-Dimensional Permission ControlThe development of business-oriented applications is often complex. In contrast, Ethereum is very convenient. You only need to start the client wallet and then you can start developing smart contracts as shown below.

Or you can use Remix:

However, when everything is ready, the customer tells me that their business data is confidential. Only data of authorized nodes can be shared, and data of unauthorized nodes should be isolated. Then we find that there is no data isolation or permission authentication on Ethereum.

The advantage of Fabric is obvious. Fabric offers multi-dimensional certificate permission control, data isolation between nodes supported by channels, and Docker-based deployment of smart contracts. Fabric can meet customer needs and is probably already one step ahead. We can see this from the following certificate directory structure:.

├── ordererOrganizations

│ └── example.com

│ ├── ca

│ ├── msp

│ ├── orderers

│ ├── tlsca

│ └── users

└── peerOrganizations

├── org1.example.com

│ ├── ca

│ ├── msp

│ ├── peers

│ ├── tlsca

│ └── users

└── org2.example.com

├── ca

├── msp

├── peers

├── tlsca

└── users

2. Low Troubleshooting Threshold

I wonder how Solidity developers feel when they hear about the bugs in Ethereum smart contracts. I, for one, feel like it gets my heart beating and my blood pumping.

When I was involved in business development previously, I followed the following process:

On the other hand, since I started developing Fabric smart contracts, my development process has been as follows:

1.Demand, data collection design

2.Development, test

3.Going online, maintenance

When bugs occurred, I went through the following process:

1.Bug occurrence, log search

2.Bug recurrence, database data search, source code location

3.Bug fixed

Now that's how it was in the good old days!

3. Calling Smart Contracts

What comes to your mind when you hear about API calls? The things that come to my mind are RESTful, HTTP, API, TCP, etc. However, since the use of Ethereum, the way of calling API has changed. First of all, you should have an API like this:

Having said all of the above, in fact, enterprise-level applications focus more on

permission control

,

data isolation

,

development costs

,

operation and maintenance costs,

etc. Ethereum, as the most authoritative smart contract public chain currently, obviously does not focus on this aspect. Fabric is designed for enterprise-level blockchain platforms, and is relatively more suitable for enterprise applications than Ethereum.