Loading src/dlt/gateway/README.md +46 −3 Original line number Diff line number Diff line Loading @@ -78,14 +78,57 @@ a sample gRPC client which connects the service and perform all the CRUD operati ## General notes Current Fabric deployment uses Fabric test network with some additional helping scripts on top of it. This deployment is highly insecure and *shouldn't be used in production* in any case. To start the network just run the `raft.sh` from `blockchain/scripts` directory. Use `stop.sh` when you need to stop the network. ## Server start preparations To run the server it's necessary to copy certificate file `fabric-samples/test-network/organizations/peerOrganizations/org1.example.com/ca/ca.org1.example.com-cert.pem` to the config folder (replacing the existing one). Also it's necessary to copy `scripts/connection-org1.json` to the config folder (replacing the existing one). Also, it's necessary to copy `scripts/connection-org1.json` file (again, replacing the old one). After copying, it must be edited. First, all `localhost` entrances should be replaced with `teraflow.nlehd.de`. Second, `channel` section at the end of the file should be removed. This should be done after every restart of the Fabric network. ## Fabric configuration Even though a test network is easy to deploy and use it's better to perform a custom configuration for a production deployment. In practice every participating organization will likely prefer to have its own Peer/Orderer/CA instances to prevent possible dependency on any other participants. This leads not only to a better privacy/availability/security in general but also to the more complicated deployment process as a side effect. Here we provide a very brief description of the most important points. ### Organizations Organization represents a network participant, which can be an individual, a large corporation or any other entity. Each organization has its own CAs, orderers and peers. The recommendation here is to create an organization entity for every independent participant and then decide how many CAs/peers/orderers does every organization need and which channels should it has access to based on the exact project's goals. ### Channels Each channel represents an independent ledger with its own genesis block. Each transaction is executed on a specific channel, and it's possible to define which organization has access to a given channel. As a result channels are a pretty powerful privacy mechanism which allows to limit access to the private data between organization. ### Certificate authorities, peers and orderers Certificate authorities (CA) are used to generate crypto materials for each organization. Two types of CA exist: one is used to generate the certificates of the admin, the MSP and certificates of non-admin users. Another type of CA is used to generate TLS certificates. As a result it's preferable to have at least two CAs for every organization. Peers are entities which host ledgers and smart contracts. They communicate with applications and orderers, receiving chaincode invocations (proposals), invoking chaincode, updating ledger when necessary and returning result of execution. Peers can handle one or many ledgers, depending on the configuration. It's very use case specific how many peers are necessary to the exact deployment. Orderers are used to execute a consensus in a distributing network making sure that every channel participant has the same blocks with the same data. The default consensus algorithm is Raft which provides only a crash fault tolerance. ### Conclusion As you can see, configuration procedure for Fabric is pretty tricky and includes quite a lot of entities. In real world it will very likely involve participants from multiple organizations each of them performing its own part of configuration. As a further reading it's recommended to start with the [official deployment guide](https://hyperledger-fabric.readthedocs.io/en/release-2.2/deployment_guide_overview.html). It contains a high level overview of a deployment process as well as links to the detailed descriptions to CA/Peer/Orderer configuration descriptions. No newline at end of file Loading
src/dlt/gateway/README.md +46 −3 Original line number Diff line number Diff line Loading @@ -78,14 +78,57 @@ a sample gRPC client which connects the service and perform all the CRUD operati ## General notes Current Fabric deployment uses Fabric test network with some additional helping scripts on top of it. This deployment is highly insecure and *shouldn't be used in production* in any case. To start the network just run the `raft.sh` from `blockchain/scripts` directory. Use `stop.sh` when you need to stop the network. ## Server start preparations To run the server it's necessary to copy certificate file `fabric-samples/test-network/organizations/peerOrganizations/org1.example.com/ca/ca.org1.example.com-cert.pem` to the config folder (replacing the existing one). Also it's necessary to copy `scripts/connection-org1.json` to the config folder (replacing the existing one). Also, it's necessary to copy `scripts/connection-org1.json` file (again, replacing the old one). After copying, it must be edited. First, all `localhost` entrances should be replaced with `teraflow.nlehd.de`. Second, `channel` section at the end of the file should be removed. This should be done after every restart of the Fabric network. ## Fabric configuration Even though a test network is easy to deploy and use it's better to perform a custom configuration for a production deployment. In practice every participating organization will likely prefer to have its own Peer/Orderer/CA instances to prevent possible dependency on any other participants. This leads not only to a better privacy/availability/security in general but also to the more complicated deployment process as a side effect. Here we provide a very brief description of the most important points. ### Organizations Organization represents a network participant, which can be an individual, a large corporation or any other entity. Each organization has its own CAs, orderers and peers. The recommendation here is to create an organization entity for every independent participant and then decide how many CAs/peers/orderers does every organization need and which channels should it has access to based on the exact project's goals. ### Channels Each channel represents an independent ledger with its own genesis block. Each transaction is executed on a specific channel, and it's possible to define which organization has access to a given channel. As a result channels are a pretty powerful privacy mechanism which allows to limit access to the private data between organization. ### Certificate authorities, peers and orderers Certificate authorities (CA) are used to generate crypto materials for each organization. Two types of CA exist: one is used to generate the certificates of the admin, the MSP and certificates of non-admin users. Another type of CA is used to generate TLS certificates. As a result it's preferable to have at least two CAs for every organization. Peers are entities which host ledgers and smart contracts. They communicate with applications and orderers, receiving chaincode invocations (proposals), invoking chaincode, updating ledger when necessary and returning result of execution. Peers can handle one or many ledgers, depending on the configuration. It's very use case specific how many peers are necessary to the exact deployment. Orderers are used to execute a consensus in a distributing network making sure that every channel participant has the same blocks with the same data. The default consensus algorithm is Raft which provides only a crash fault tolerance. ### Conclusion As you can see, configuration procedure for Fabric is pretty tricky and includes quite a lot of entities. In real world it will very likely involve participants from multiple organizations each of them performing its own part of configuration. As a further reading it's recommended to start with the [official deployment guide](https://hyperledger-fabric.readthedocs.io/en/release-2.2/deployment_guide_overview.html). It contains a high level overview of a deployment process as well as links to the detailed descriptions to CA/Peer/Orderer configuration descriptions. No newline at end of file