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.)