Gateway overview edited #3042
Gateway overview edited #3042
Conversation
joshhus
force-pushed
the
gatewayoverview
branch
from
3ae9552
to
61d9c24
Compare
|
@joshhus you need to sign the commit, instructions on the DCO details link - https://github.com/hyperledger/fabric/pull/3042/checks?check_run_id=4191174881. More details at: Also, we typically amend commits and re-push, as opposed to adding additional commits. This way the final merge to the main branch is a single clean commit. You can also add commits and then squash, but I think the amend approach is easier. More details at: |
|
@denyeart I think we're fine, it's just an odd concept to the uninitiated person, from a language pov. That an org can be a "member" of a data collection. ...Perhaps we have a definition of what this means, or could add one somewhere. e.g. What makes Org A and B "members" of Data collection C, while Org D is not a member of Data collection C. Perhaps this definition already exists. |
|
@denyeart Is there a way to configure my signing automatically? Or just add the step / cmd to my process. |
Signed-off-by: Josh Horton <joshh@us.ibm.com>
Signed-off-by: Josh Horton <joshh@us.ibm.com>
Signed-off-by: Josh Horton <joshh@us.ibm.com>
joshhus
force-pushed
the
gatewayoverview
branch
from
a44dcb0
to
d8483f6
Compare
The instructions at https://hyperledger-fabric.readthedocs.io/en/latest/github/github.html recommend you simply sign the commit when you create the commit with the signoff flag:
|
You can see the private data collection doc topic here: https://hyperledger-fabric.readthedocs.io/en/latest/private-data/private-data.html , feel free to do a PR against that topic for any language you find confusing. |
|
|
||
| ### Targeting specific endorsement peers | ||
|
|
||
| In some cases, a client application must explicitly identify the specific organizations to evaluate or endorse a transaction proposal. Transient data, for example, often contains personal or sensitive information that must only be written to a shared private data collection. In these cases, the client application can explicitly specify the endorsing organizations; the gateway will select the available peer with the highest block count from each organization. However, if the inclusion of an organization violates a required endorsement policy, then the transaction is invalidated by all of the requested endorsing peers. This failed endorsement is recorded on the ledger but no transaction writes will exist in the state database. |
There was a problem hiding this comment.
"However, if the inclusion of an organization violates a required endorsement policy, then the transaction is invalidated by all of the requested endorsing peers."
"inclusion of an organization" is awkward here. It would be better to say something like "if the specified endorsing organizations violates the endorsement policy"...
Also, "then the transaction is invalidated by all of the requested endorsing peers" is not correct. The endorsing peers will successfully return a proposal response. Once the transaction gets included in a block, EVERY peer on the channel (not just the endorsing peers) will invalidate the transaction and not update its state database.
There was a problem hiding this comment.
So there's this concept of a "plan" when there are multiple endorsement policies that must pass. I think just referencing multiple policies is easier to digest than an additional concept. Here you say "the endorsement policy" as if there is only one policy, please confirm.
There was a problem hiding this comment.
And what is the proposal response in this case of failure for one or more of the endorsement policies. failed, e.g.
There was a problem hiding this comment.
"if the specified endorsing organizations violates the endorsement policy"... we're talking about the mere selection of a given org as violating a policy right. So it's the "selection" of an org, right, not something the selected org. would then do.
There was a problem hiding this comment.
So we currently have this:
In some cases, a client application must explicitly select the organizations to evaluate or endorse a transaction proposal. For example, transient data often contains personal or sensitive information which must be written only to a private data collection, thereby limiting the pool of endorsement organizations. In these cases, the client application can explicitly specify the endorsing organizations; the gateway will then select the (available) endorsing peer with the highest block count from each organization. However, if the selection of one or more endorsing organizations violates an endorsement policy, then the transaction is invalidated by all peers in the channel. This failed endorsement is recorded on the ledger but the transaction is not written to the state database on any channel peer.
There was a problem hiding this comment.
You're right, one transaction may have multiple endorsement policies due to chaincode-level, collection-level, and state-based endorsement policies. All of these have to be satisfied for the transaction to be validated. Sometimes we refer to this whole set as the endorsement policy of the transaction as a whole.
There was a problem hiding this comment.
And what is the proposal response in this case of failure for one or more of the endorsement policies. failed, e.g.
Remember, endorsement policy is not checked until validation/commit time later. The proposal and proposal response are ignorant of the endorsement policy. The gateway peer however does inspect the first proposal response and work with discovery service to identify the endorsement policy of the transaction and route the proposal to the required organization's peers.
|
BTW, the commits are still not squashed into a single commit. |
@denyeart idk how to squash or why it's required please advise. |
The rationale and instructions are provided at the link: |
|
Even though we like to squash to a single commit, for the sake of time I'll go ahead and merge as-is and submit a subsequent PR for the remaining comments so it will be easier to focus on them. |
|
Follow-on PR: |
New Fabric Gateway overview doc, written by @andrew-coleman, reviewed by @denyeart, and edited by @joshhus.
Type of change
Description
Fabric Gateway simplifies client app / SDK development by migrating transaction endorsement functionality to a Fabric Gateway peer.
Additional details
Some related doc file reviews and edits are still TBA.
Related issues
#2807
Release Note
Fabric Gateway simplifies client application development by migrating transaction endorsement functionality from the client to the Fabric Gateway peer. This new gateway functionality is currently optional. Simplified SDKs are provided for clients who choose to implement the new gateway. Read more at (link to documentation start -- gateway.md).