I saw a lot of references to grpc and client interactions with http2 to the endorser. I have also seen some references to rest api. My confusion is that with so many versions now from 0.6 to 2.2 I am getting confused on the actual protocol standard from the client to the endorser.
If I have 2.0, is everything using grpc which implements the api from the client to the endorser via http2 and the sdk?
There are four primary APIs used for interactions between the Fabric SDK Client and the Fabric peers and orderers. These services are all gRPC based.
The peer exposes a Propose rpc, a Discover rpc and a Deliver rpc. The Propose rpc is responsible for producing endorsements which are bundled by the client into a transaction. The Discover rpc is used to help a client understand which peers a proposal could and or should be endorsed by. The Deliver rpc is used by the client to consume blocks as they are committed and detect transaction commitment.
The orderer exposes a Broadcast and Deliver rpc. The Broadcast rpc accepts transactions to be included into the blockchain, and the Deliver rpc provides blocks (usually to peers, but sometimes to clients as well).
There are some other components in the system which provide other APIs -- the operations endpoints meant for health checks and metrics, for instance use REST. But, these components are typically not consumed by a client application.
Related
In Hperledger caliper for benchmarking of fabric network, I have provided the connection profile with detail of CA. The transaction is successfully submitted to the network which is in the remote machine. I have checked the logs on peers, orderers, and CA. Only CA didn't have a log of requests to the CA server.
In my assumption, while submitting the transaction using fabric gateway the invoker identity must be verified by the CA. But this is not happing as a result of my configuration.
In which case CA server does not need to be enabled while submitting the transactions?
Edit: The question is edited to make the question specific to the involvement of CA while submitting the secure transaction on TLS enabled system.
Thank you!
It seems necessary to study the PKI and certificate(X.509) structure. Fabric-CA acts as an organization's CA and manages the identifiers of the each organization's member(orderer, peer, client...).
The authentication/authorization process for an identifier can be performed based on a certificate issued to a CA, but it does not need to be associated with a CA during the process.
In other words, during the P2P verification process, the CA is independent.
Taking the legacy system as an example, Facebook has issued a certificate from digicert, and the browser can verify the identifier through that certificate. (For Root CA verification, it is provided whitelisted at your browser or OS level level.)
It's like asking why you don't use digicert (Fabric-CA) when you say you do a transaction throughput benchmark for Facebook (peer/orderer).
Fabric-CA does not have a ledger and is not support for reading or storing transactions in the blockchain. it is just CA in Fabric Network, independent of the transaction processing benchmark.
If authentication/authorization for a resource has to be performed in the form of a live stream to a CA, it will have dependencies and cause big problems
(e.g. if digicert's system is paralyzed, Facebook will be paralyzed too)
in process, Fabric-CA issues an identifier on the network at the bootstrap stage before performing the benchmark, rather than verifying in the transaction processing process (if it has been created in advance through cryptogen, issuance. It can be seen as being.)
In the client applications (using Node/Go) we provide connection profile to identify the endpoints of endorsers.
There we specify endpoint of peer in terms of grpc://localhost:port but actually gRPC runs on HTTP2 right?
Then does the Fabric SDK convert the endpoint to a HTTP url or is it handled by fabric peer code?
I mean how is grpc endpoint converted to an HTTP one?
Or does the peer expose a grpc endpoint itself? If yes, how?
For communicating between the front-end and the Hyperledger Fabric Layer, we have two ways, one to use the gRPC calls OR use one of the SDKs provided by the Hyperledger Community. There are no REST API calls after v1.0, as opposed to v0.6, which had REST API calls, where you could use the IP Addresses to fire transactions to the Orderer, then Consensus.
Making it limited to gRPC and SDKs improves the design and connection security issues, which is vital for the Blockchain to work. gRPC is the HTTPS 2.0 protocol for communication which is faster and has improved security features over HTTPS 1.1. SDKs use gRPC calls to communicate to the network. So, putting it plainly, if you need to communicate with the Network, you need to use gRPC calls only
As suggested by #david_k in comments above, the URL in connection profile is used for extracting the host and port number after identifying whether it is grpc or grpcs (over SSL) call.
To verify:
Deploy the fabcar sample and install the node modules.
Go to the Endpoint.js file in the fabric-common node module inside the lib directory. Edit the line corresponding to line 44 here.
Go to the first-network directory (the network used by fabcar sample) to edit the connection profile. Replace the grpcs in the peer and orderer URL corresponding to the edit you made to the Endpoint.js file in node modules.
Return back to the javascript directory and fetch the wallet identities.
Modify the invoke.js to read the new connection profile.
Execute it to see that the transaction is submitted successfully.
Therefore, we can identify that only the host and port are fetched from the URL to be used for making a grpc/grpcs call to the fabric network.
Are there any existing methods for decentralized peer-to-peer identity verification without using any central entity for public-key signing. An example scenario is as follows.
We have a peer-to-peer system where each node has to verify the identity of another node. And the nodes won't use a central entity (like a Cert Authority for public-key signing). A simple solution would be to have all the nodes' public-keys baked in to every node during the creation/installation phase. But whenever new nodes are created or deleted, this has to be updated (which is an expensive step by the nature of the node's hardware/software design). Is there a better solution than this?
I was reading this pretty cool article this morning:
https://medium.com/#CazChurchUk/developing-multi-user-application-using-the-hyperledger-composer-rest-server-b3b88e857ccc
I am interested in the Rest Server features but I have a couple of questions on it:
How does the Rest Server knows which wallet to use for a specific logged-in client?
How to create channels and join peers from/using the Rest Server?
Thanks hackers!
Once a REST client (where the wallet is) has authenticated to the REST Server, that client can add Blockchain identities (one or more) to its own REST client wallet. The wallet is private to that client, and is not accessible to other clients. When a client makes a request to the REST server, a Blockchain identity in the clients wallet is used to digitally sign all transactions made by that client (and the REST server knows who that is on the business network as that identity is mapped to a participant).
Please note that this feature requires that clients trust the REST server. This trust is required because this feature requires that the REST server stores the clients Blockchain identities as part of the card. Therefore, it is strongly recommended that clients only use REST servers that are managed by a trusted party, such as an administrator within their organization.
All information regarding authenticated users and their wallets (containing each users business network cards when multiple user mode is enabled) is persisted in a LoopBack data source by using a LoopBack connector. You would normally set up a persistent store such as MongoDB and the REST server would use a Loopback adapter to access the MOngoDB store. REST clients that have authenticated via a strategy will normally get an access token (once they authenticate) and which is stored locally (such as in the browser for OAUTH2)
Channels and Peers (which come from Hyperledger Fabric) are configured in connection profiles (connection.json file) which are part of the business network cards built for a participant of the business network. The REST server itself doesn't 'join peers or channels' it knows about it because it is started with a business network card (and the definition of the channel and peers are known to the REST server that discovers the business network to which it relates). Obviously you can stand up many REST server instances to serve the different 'living' business networks deployed (on whatever channels (ledgers) or peers defined in the profile) in an organisation.
We use Azure Service Bus and Azure Web App which fills queue. They are in the same resource group. We use WindowsAzure.ServiceBus v2.6.5.
We get this error very rarely:
The X.509 certificate CN=servicebus.windows.net is not in the trusted people store. The X.509 certificate CN=servicebus.windows.net chain building failed. The certificate that was used has a trust chain that cannot be verified. Replace the certificate or change the certificateValidationMode. A certificate chain could not be built to a trusted root authority.
Question: Is this internal error on Azure ? If it's not, what can we do to not get this error ?
I managed to find our more information about this issue. First of all,
what needs to be established is that this is a pure client issue, this
is why there are no tracking IDs. The client refuses to complete the
TLS handshake with Service Bus.
This is a known issue this is a known issue with the way how Microsoft
manages certificates and how they are used on non-HTTP(S) transports.
The errors occur when the endpoint that hosts the intermediate
certificates for Microsoft is unavailable or slow or cannot be reached
by the client for any reason. We are investigating a workaround for
injecting the required extra certificate into the TLS handshake for
the SBMP and AMQP transports similar to how this is done by HTTP.SYS,
so that this extra request is not needed.
The immediate workaround available is to enable
ServiceBusEnvironment.SystemConnectivity.Mode = ConnectivityMode.Https
This will force all traffic to use a WebSockets tunnel that is
protected by a prior TLS/HTTPS handshake, and that handshake carries
the required intermediate certificate. The WebSockets handshake does
impose a little extra latency as the connection is established, but
will otherwise be comparable with the regular communication mode. The
messaging protocol used through that tunnel will still be AMQP or
NetMessaging, so you should not be worried to get HTTP characteristics
when choosing this option.
This is the response from Microsoft. I'll apply this and if I don't face any problem at some period time, I will accept this as an answer. Who faces this problem, they can try this also.
Edit:
ConnectivityMode.Https is just in avaliable service bus 3. I have to use servicebus 2 because of issue on Signalr. Therefore I couldn't apply this solution.
I believe there must be a missing certificate.
From this stack overflow post https://stackoverflow.com/a/24224550/4735373 here is a link that may help: https://corp.sts.microsoft.com/Onboard/ADFSOnboard.htm#Corp-STS-Certificates