F.A.Q.
No, this SDK is an independent project that we use in our development
Yes, license allows using it in practically any scenario.
Currently, Hyperledger is in Alpha stage so many features are not implemented or stable and problems are expected. But this SDK communicates to Hyperledger using only protocol buffers (gRpc) so stable Hyperledger features become stable features in SDK.
Channels are very important concept in HL. Every channel represents independent blockchain data with all necessary attributes. In one HL installation there may be more than one channel, but they are completely independent. Peers can join one or many channels, but only peers that joined particular channel can execute operations on it.
Chaincode is the code that can read and update data in channel. It consists of series of functions that are executed by Peer, and any of those functions can manipulate blockchain stage. Chaincode must be installed on Peer before can be executed. One Peer can have more than one chaincode installed on it. Also in one channel there may be more than one chaincode.
No, chaincode can be written in any supported language like Go,Java,Car (more will be added). Chaincode is independent from SDK or even from Hyperledger itself. So from Go SDK you can invoke chaincode written on Java.
mspId stands for Member Service Provider ID. In very advanced scenarios users can create their own code that define users, work with their certificates, access control, affiliation, roles, attributes etc. This custom member service implementation can be attached to one or more installed chaincodes. So when users make request to HL they can specify which mspID must be used to check request and decide if this user can execute the request. HL has default mspId called "DEFAULT".
Before request is executed and blockchain state is changed the request is send to one or more Peers that verify the request, user, signature, etc... and simulate the request. Every Peer returns special response which unambiguously show that Peer is agree or not with this request. Then all endorsement responses are send to Orderer who can decide to execute actual blockchain update or to ignore the request completely. Decision is based on Policy rules attached to chaincode.
Policy defines how many Peers must endorse request to be considered as valid. Any Boolean logic can be used to create any scenario, but some of most common are: At least one Peer, majority of Peers, all Peers, majority of Peers + one specific Peer. Policy is attached to chaincode.
ECert stands for Enrollment certificate. It is x.509 cryptographic certificate with a private key that is used to sign request to HL. Certificate holds user identity, attributes and all other necessary data. This certificate is issued by Certificate Authority (CA). Requests made using this certificate link unambiguously the request with this particular user and this information is accessible from every valid participant in HL.
TCert stands for Transaction Certificate. They are same as ECerts but with one very important difference - TCerts are anonymous. Operations executed using TCert do not revile information about user identity that make the request. In general one TCert is used only for one operation. Using TCerts users can create many complex businesses scenarios. It is possible to make TCerts in such way that they are anonymous for most of the entities in HL, but some entities (like Auditor) can trace operation from TCert back to user that execute the request. For more details and examples refer to official HL documentation.
Enrollment is a process of creating ECert from Certificate Authority (CA). HL provide robust CA implementation called fabric-ca, but users can use custom CA.
Like in most common systems users must be registered before can be enrolled. This is a registration process in general. It is made to CA and additional info like affiliation, attributes etc... are provided. This information will be included in ECert returned from the Enrollment process and later can be used in chaincode.
gRPC is an open protocol developed by Google using protocol buffers. Main benefits are: gRpc is several factors faster than REST, supports very effective two-way async communication,compresses data to binary and automatically creates necessary code to work with it from protocol buffers. Protocol buffers are language agnostic so same protocol buffers can generate code for Go,Nodejs, C, Java etc... and communication between these languages will be compatible.