Why choose Fabric for enterprise application development?

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 Control
The 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:

1.Problem analysis, architecture review, design review

2.Bug recurrence, problem identification, data source location, source code location

3.Bug fixed

However, the reality is like so:

1.Demand, data structure design, table structure design

2.Development, test

3.Going online, maintenance

When bugs occurred, I went through the following process:

1.Bug occurrence, frantic log search

2.Bug recurrence, database data search, code location

3.Bug fixed

Since I started developing Ethereum smart contracts, my development process has been as follows:

1.When there is demand, the following questions come to my mind: How many mappings do I need? How many layers of mapping? Structures?

2.Development, test

3.Going online, maintenance

When bugs occur, this is what I face:

1.Bug occurrence, no log file, at a loss

2.Cannot find data inventory, at a loss

3.Analysis shows the impact is not big; freeze contracts if impact is big; otherwise, no change is made

4.Bug fixes released, rush to modify code; redeploy, change contract address, migrate data

5.Bug fixed

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 fixedNow 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:
[{"constant":true,"inputs":[],"name":"name","outputs":[{"name":"","type":"string"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":false,"inputs":[{"name":"_spender","type":"address"},{"name":"_value","type":"uint256"}],"name":"approve","outputs":[{"name":"","type":"bool"}],"payable":false,"stateMutability":"nonpayable","type":"function"}...
Then the call you initiate may be like this:
0x23b872dd0000000000000000000000006e80d21aa536cefdb4a6d5f879af619ef97157760000000000000000000000009f5217d4a04a10649547f5ccd835e2d69efc2a0e00000000000000000000000000000000000000000000000006f05b59d3b20000
Looking at a call like this, I feel helpless.

Let's take a look at Fabric's contract call, which is as follows:
peer chaincode query -C $CHANNEL_NAME -n mycc -c '{"Args":["query","a"]}'

Of course, it may also be like this:
var request = {targets: peerNames,chaincodeId: chaincodeName,
fcn: fcn,args: args,chainId: channelName,txId: tx_id};
let results = await channel.sendTransactionProposal(request);

Json is used for transferring parameters, so this puts me at ease.

4. Summary
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.