Separation of transaction creation and generation of TCerts

[dulcep]

Eliminate TCert generation in the middle of a transaction creation. i.e. avoid calling the TCA in the middle of a transaction in order to request the generation of a batch of TCerts

[diegomasini]

Providing a little more detail to this issue: The idea is to provide a way to request a batch of TCerts outside the current transaction execution flow. Similar to the GetTCertificateHandlerNext() function in client_impl.go This function is intended to request a batch of TCerts with a particular set of attributes to be included in them. Additionally the same function could be used to request TCerts in the background (in a separated thread) as a performance improvement. Other uses of it could appear later.

[diegomasini]

And additional use is the request of TCerts with specific attributes. There is a function to request one TCert from the REST API, GetTransactionCert() we need to add GetTransactionCerts() to request for a batch of TCerts and both requests need to specify the desired attributes.

[JonathanLevi]

@binhn Can you please assign this issue to me?

[binhn]

done. Thanks!

[JonathanLevi]

OK, I'm splitting this to a few items (physically and logically):

[JonathanLevi]

We have @dulcep's initial request for not requesting a TCert in the middle of a transaction creation. That's the easy step as one can simply provide the TCert as a parameter to the function call, in order to create the transaction. That's one issue - the ability to request a TCert externally.

This separation does make the system's 'timing' feel a lot more deterministic, as we don't have that 'cache-miss' type of performance (that is, create a TCert if one is not there). Separating this, will give the callee a lot more control.

[JonathanLevi]

The other functionality is to be able to ask for more than one TCert. While we do not need to add an extra REST API call (as the current one already supports a 'count' parameter, which specifies how many TCerts (that has not been used yet, obviously) should be returned back, however some of this logic is currently implemented at the

https://github.com/hyperledger/fabric/blob/master/core/rest/rest_api.go#L451

And following 1464, we can refactor this logic by adding an entry point at the crypto layer, re-using this logic.

[JonathanLevi]

The third item will be simply adding func (client *clientImpl) GetNextTCerts( nCerts int ) ( []tCerts, error) and work with a request for a set of TCerts, which can be called as GetNextTCerts(1) for retrieving/obtaining only one.

This is handled in #1693

[JonathanLevi]

Finally, associated with this issue, is the ability to provide the attributes (or more precisely, AVPs) as part of the TCert(s) request.

[smithbk]

Prefetch capability was added to the client node SDK, so I don't think this is needed any longer and can be closed.

The client node SDK keeps track of the rate at which TCerts are requested and the response time for retrieving TCerts from the TCA. It then dynamically calculates a low-water mark on the number of remaining TCerts at which point it requests the next batch of TCerts.

[JonathanLevi]

A few things happened since this issue got opened, it was split to various sub-issues and the bulk of the related work (in membersrvc) was actually done by @andresgaragiola and others in separate PRs. I know of one last sub-item that's pending (adding the attributes to the request), but it can be done separately.

@smithbk Trying to find out what's the wider plan regarding the last sub-item and the (deprecation of some of the) REST API, gRPC, etc. Regardless of the batch request (size), let me check around if this can be closed. I don't have a preference either way.