Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix test-network to work with BFT consensus. #1047

Merged
merged 1 commit into from
Aug 22, 2023

Conversation

arkadiPiven
Copy link
Contributor

Added a new option for creating channel:
Running ./network.sh createChannel -bft will initiate a channel running BFT orderers.

@arkadiPiven
Copy link
Contributor Author

@yacovm

@arkadiPiven arkadiPiven force-pushed the test-network-bft branch 3 times, most recently from 7519e1d to d7529ea Compare June 28, 2023 20:56
@@ -3,15 +3,19 @@
# imports
. scripts/envVar.sh
. scripts/utils.sh
export PATH="${PWD}"/../../fabric/build/bin:"${ROOTDIR}"/../bin:"${PWD}"/../bin:"$PATH"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are you sure this is needed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You need this in case someone will want to use old binaries.
Me and Dave had the same approach when constructing nano-bash

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Most people that download the samples and try it out will not have a fabric directory. I'd suggest to remove this change.
We added it for the nano bash sample since a target user of that sample was a Fabric developer who compiles their own binaries.

@yacovm
Copy link
Contributor

yacovm commented Aug 3, 2023

@denyeart let's get this PR in, shall we?

test-network/bft-config/configtx.yaml Outdated Show resolved Hide resolved
test-network/bft-config/configtx.yaml Outdated Show resolved Hide resolved
test-network/bft-config/configtx.yaml Show resolved Hide resolved
test-network/configtx/configtx.yaml Outdated Show resolved Hide resolved
@@ -3,15 +3,19 @@
# imports
. scripts/envVar.sh
. scripts/utils.sh
export PATH="${PWD}"/../../fabric/build/bin:"${ROOTDIR}"/../bin:"${PWD}"/../bin:"$PATH"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Most people that download the samples and try it out will not have a fabric directory. I'd suggest to remove this change.
We added it for the nano bash sample since a target user of that sample was a Fabric developer who compiles their own binaries.

@@ -18,7 +18,7 @@
# this script is actually in and infer location from there. (putting first)

ROOTDIR=$(cd "$(dirname "$0")" && pwd)
export PATH=${ROOTDIR}/../bin:${PWD}/../bin:$PATH
export PATH="${PWD}"/../../fabric/build/bin:"${ROOTDIR}"/../bin:"${PWD}"/../bin:"$PATH"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Most people that download the samples and try it out will not have a fabric directory. I'd suggest to remove this change.
We added it for the nano bash sample since a target user of that sample was a Fabric developer who compiles their own binaries.

test-network/README.md Outdated Show resolved Hide resolved
@arkadiPiven arkadiPiven force-pushed the test-network-bft branch 2 times, most recently from 6c693ad to b8c697b Compare August 17, 2023 17:09
@@ -316,7 +319,8 @@ function deployCCAAS() {

# Tear down running network
function networkDown() {

local temp_compose=$COMPOSE_FILE_BASE
COMPOSE_FILE_BASE=compose-bft-test-net.yaml
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not following this change... won't this always force the use of compose-bft-test-net.yaml instead of the default compose-test-net.yaml?
Why is the temp_compose required here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are correct.
The compose-bft-test-net.yaml is a super set of the compose-test-net.yaml. This means that if a user launched a regular network or a bft network, during shutdown all containers will be stopped no matter what initial configuration the user chose.
This actually spares me to pass any flags to the ./network.sh down command, and to refer to different kinds of networks.

@@ -0,0 +1,310 @@
# Adding Orderer To An Existing Network
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be part of the official documentation, not in the samples.

Added a new option for creating channel:
Running ./network.sh createChannel -bft will initiate a channel running BFT orderers.
Using ./network.sh up -bft will initiate dockers for bft environment.
Added option for 4 orderers.

Add add_new_orderer_to_config.py which is referenced in the fabric official docs.

Signed-off-by: Arkadi Piven <arkadi.piven@ibm.com>
Signed-off-by: arkadipiven <arkadi7770@gmail.com>
Comment on lines +63 to +75
identities = config['channel_group']['groups']['Orderer']['policies']['BlockValidation']['policy']['value']['identities']
identities_before_update = copy.deepcopy(identities)
new_identity = copy.deepcopy(identities[0])
new_identity['principal']['id_bytes'] = identity
identities.append(new_identity)
_log_update('block validation identities', identities_before_update, identities)

rule = config['channel_group']['groups']['Orderer']['policies']['BlockValidation']['policy']['value'][
'rule']
rule_before_update = copy.deepcopy(rule)
rule['n_out_of']['n'] = _calculate_bft_quorum(new_orderers_count)
rule['n_out_of']['rules'].append({'signed_by': new_orderers_count - 1})
_log_update('block validation rules', rule_before_update, rule)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One general question and one specific question.

General question - I didn't see this file originally... is it used in this PR? Or will other instructions use it?

Specific question - I didn't see anything like these BlockValidation policies in the original configtx.yaml, like I did for the Orderer Endpoints (above) and consenter mapping (below). Can you educate me on this... why are they not in configtx.yaml? Is it in the channel config implicitly somehow originally? Is this new for BFT?

Copy link
Contributor

@yacovm yacovm Aug 22, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't see anything like these BlockValidation policies in the original configtx.yaml, like I did for the Orderer Endpoints (above) and consenter mapping (below). Can you educate me on this... why are they not in configtx.yaml? Is it in the channel config implicitly somehow originally? Is this new for BFT?

I'll answer this one, and will let Arkadi answer the first one.

First of all, remember that the "name" of the policy in configtx.yaml is a mere pointer to a meta policy of "any orderer".
The meta policies we have, or, the policies we have in general in Fabric, are not suitable to define BFT policies, as BFT policies depend on additional input found in the channel config (the consenters...) . To add support for that, it requires invasive changes to the channel config infrastructure.

However, a signature policy is a supported policy that can always be used and it is flexible enough to fit BFT block validation.

In the spirit of making Fabric more generic and pluggable, we don't want to define policy names for every type of consensus we can imagine. Some protocols require more signatures, some require less, some require a single threshold signature, etc.
While in Raft it's easy to define a policy string ("any orderer"), for BFT it's complex to do that in the configtx.yaml, and it can also be error prone.

For BFT, the Fabric tooling (configtxgen) overrides the block validation policy that is defined in the configtx.yaml, both in order to "protect the user from a misconfiguration", and also because it was my belief that a user should not need to understand the underlying BFT protocol to configure the policy.
So, when a channel is created using configtxgen, the genesis block contains the right policy. When a channel is updated, the orderer itself checks that the policy was correctly computed via an ad-hoc verification.

Copy link
Contributor Author

@arkadiPiven arkadiPiven Aug 22, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the general question:
This file is used in the following tutorial:
hyperledger/fabric#4390
Please look at the add_orderer.md committed file,
Under section "Add the fifth orderer to the config" subsection 4.

Copy link
Contributor

@denyeart denyeart left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The sample looks great now, let's go ahead and merge while we finish out the doc PR.

@denyeart denyeart merged commit eb16caf into hyperledger:main Aug 22, 2023
36 of 41 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants