Date   

Re: #hyperledger-fabric #hyperledger-fabric

sstone1@...
 

Hi Subhra,

The balance transfer sample was removed in Fabric v2.0 as it was not a good sample, and it did not demonstrate good practices for application development. You can use the FabCar sample or the Commercial Paper sample instead.

Best regards,

Simon Stone


-----fabric@... wrote: -----
To: fabric@...
From: ssbose77@...
Sent by: fabric@...
Date: 02/10/2020 05:20PM
Subject: [EXTERNAL] [Hyperledger Fabric] #hyperledger-fabric

Hi Team,
I don't see the balance-transfer example in v2.Will it be updated anytime soon or not in v2 ?

Regards,
Subhra
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


#hyperledger-fabric #hyperledger-fabric

ssbose77@...
 

Hi Team,
I don't see the balance-transfer example in v2.Will it be updated anytime soon or not in v2 ?

Regards,
Subhra


Re: Hyperperledger 1.4 LTS, until when?

Aboubakar Koïta
 

All right, thank you for that information.

Regards,
Aboubakar


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Monday 10 February 2020 15:48, Brett T Logan <Brett.T.Logan@...> wrote:

We expect sometime mid-year to announce Fabric 2.x as LTS. Once this happens there will be a period of time where both 1.4.4 and 2.x are LTS to provide a transition period for users to migrate to 2.x.
 
Brett Logan
Software Engineer, IBM Blockchain
Phone: 1-984-242-6890
 

 
 
----- Original message -----
From: "Aboubakar Koïta via Lists.Hyperledger.Org" <aboubakar.koita=protonmail.com@...>
Sent by: fabric@...
To: "fabric@..." <fabric@...>
Cc: fabric@...
Subject: [EXTERNAL] [Hyperledger Fabric] Hyperperledger 1.4 LTS, until when?
Date: Mon, Feb 10, 2020 9:45 AM
 
Hi,
 
With the release of Hyperledger 2.0 I would like to know until when version 1.4 will be maintained.
 
Best regards,
Aboubakar
 


Re: Hyperperledger 1.4 LTS, until when?

Brett T Logan <brett.t.logan@...>
 

We expect sometime mid-year to announce Fabric 2.x as LTS. Once this happens there will be a period of time where both 1.4.4 and 2.x are LTS to provide a transition period for users to migrate to 2.x.
 
Brett Logan
Software Engineer, IBM Blockchain
Phone: 1-984-242-6890
 
 
 

----- Original message -----
From: "Aboubakar Koïta via Lists.Hyperledger.Org" <aboubakar.koita=protonmail.com@...>
Sent by: fabric@...
To: "fabric@..." <fabric@...>
Cc: fabric@...
Subject: [EXTERNAL] [Hyperledger Fabric] Hyperperledger 1.4 LTS, until when?
Date: Mon, Feb 10, 2020 9:45 AM
 
Hi,
 
With the release of Hyperledger 2.0 I would like to know until when version 1.4 will be maintained.
 
Best regards,
Aboubakar
 


Hyperperledger 1.4 LTS, until when?

Aboubakar Koïta
 

Hi,

With the release of Hyperledger 2.0 I would like to know until when version 1.4 will be maintained.

Best regards,
Aboubakar


Re: [External] Re: [Hyperledger Fabric] Transaction Validation Failure

Eryargi, Hakan
 

Regular one

 

From: Yacov Manevich <YACOVM@...>
Sent: Monday, 10 February 2020 13:19
To: Eryargi, Hakan <hakan.eryargi@...>
Cc: fabric@...
Subject: [External] Re: [Hyperledger Fabric] Transaction Validation Failure

 

This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links and attachments.


 

Is this a system chaincode or a regular one?





From:        "Eryargi, Hakan via Lists.Hyperledger.Org" <hakan.eryargi=accenture.com@...>
To:        "fabric@..." <fabric@...>
Cc:        fabric@...
Date:        02/10/2020 02:16 PM
Subject:        [EXTERNAL] [Hyperledger Fabric] Transaction Validation Failure
Sent by:        fabric@...





Hi,
 
Are all transaction validation failures handled the same way and propagated back to client (Node.js SDK)? In particular I’m asking about EXPIRED_CHAINCODE failure.
 
I’m investigating a weird issue where some transactions somehow disappear from the chain. Developers claim it is committed to chain and visible in the CouchDB but somehow later on disappear somehow. It’s not also visible in the key history.
 
While checking the peer logs I’ve came across below failure. My understanding is, chaincode is upgraded to a new version in the time window between transaction proposal is endorsed and sent to peers for commitment. So peers rejected the transaction because it’s endorsed by an old version of chaincode.
 
Weird thing is, there are no logs on the application side related to this validation failure.
 
So may it be the case, this error is not propagated to the client application? Or is it an improper setting on our side for listening for such events?
 
Thanks,
Hakan
 
 
[34m2020-02-0709:34:55.628UTC [gossip.privdata] StoreBlock -> INFO3f2[0m [public] Received block [386] from buffer
[31m2020-02-0709:34:55.628UTC [committer.txvalidator] VSCCValidateTx -> ERRO 3f3[0m chaincode info:17260/publicdidn't match info:17280/publicin lscc
github.com/hyperledger/fabric/core/committer/txvalidator.(*VsccValidatorImpl).VSCCValidateTx
    /opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/vscc_validator.go:200
github.com/hyperledger/fabric/core/committer/txvalidator.(*TxValidator).validateTx
    /opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/validator.go:345
github.com/hyperledger/fabric/core/committer/txvalidator.(*TxValidator).Validate.func1.1
    /opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/validator.go:158
runtime.goexit
    /opt/go/src/runtime/asm_amd64.s:1337
[31m2020-02-0709:34:55.628UTC [committer.txvalidator] validateTx -> ERRO 3f4[0m VSCCValidateTx for transaction txId = ecb40373f63e23e46b95a9181b82bd667d88ffd3ec2ce3298f6584f6320babedreturned error:chaincode info:17260/publicdidn't match info:17280/publicin lscc
[34m2020-02-0709:34:55.629UTC [committer.txvalidator] Validate -> INFO3f5[0m [public] Validated block [386] in 0ms
[33m2020-02-0709:34:55.629UTC [valimpl] preprocessProtoBlock -> WARN3f6[0m Channel [public]: Block [386] Transaction index [1] TxId [ecb40373f63e23e46b95a9181b82bd667d88ffd3ec2ce3298f6584f6320babed] marked as invalid by committer. Reason code [EXPIRED_CHAINCODE]
[34m2020-02-0709:34:55.719UTC [kvledger] CommitWithPvtData -> INFO3f7[0m [public] Committed block [386] with 2transaction(s) in 90ms (state_validation=6ms block_and_pvtdata_commit=63ms state_commit=7ms) commitHash=[04da119737eb4edc05196bf00299754f07df0b5f1601474c227140486f547b07]
[34m2020-02-0709:34:56.964UTC [gossip.privdata] StoreBlock -> INFO3f8[0m [public] Received block [387] from buffer
[31m2020-02-0709:34:56.964UTC [committer.txvalidator] VSCCValidateTx -> ERRO 3f9[0m chaincode info:17260/publicdidn't match info:17280/publicin lscc
github.com/hyperledger/fabric/core/committer/txvalidator.(*VsccValidatorImpl).VSCCValidateTx
    /opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/vscc_validator.go:200
github.com/hyperledger/fabric/core/committer/txvalidator.(*TxValidator).validateTx
    /opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/validator.go:345
github.com/hyperledger/fabric/core/committer/txvalidator.(*TxValidator).Validate.func1.1
    /opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/validator.go:158
runtime.goexit
    /opt/go/src/runtime/asm_amd64.s:1337
[31m2020-02-0709:34:56.964UTC [committer.txvalidator] validateTx -> ERRO 3fa[0m VSCCValidateTx for transaction txId = 2a686e6948e892c853e48972863bdd6c40c79189ec89099d80dfd69db9fe68eareturned error:chaincode info:17260/publicdidn't match info:17280/publicin lscc
[34m2020-02-0709:34:56.964UTC [committer.txvalidator] Validate -> INFO3fb[0m [public] Validated block [387] in 0ms
[33m2020-02-0709:34:56.964UTC [valimpl] preprocessProtoBlock -> WARN3fc[0m Channel [public]: Block [387] Transaction index [0] TxId [2a686e6948e892c853e48972863bdd6c40c79189ec89099d80dfd69db9fe68ea] marked as invalid by committer. Reason code [EXPIRED_CHAINCODE]
[34m2020-02-0709:34:57.043UTC [kvledger] CommitWithPvtData -> INFO3fd[0m [public] Committed block [387] with 1transaction(s) in 78ms (state_validation=0ms block_and_pvtdata_commit=46ms state_commit=16ms) commitHash=[e229a1c1b938ac6f9ee707f3ab7a6899f5dccb5cbc30443a18da54121fa56194]
[34m2020-02-0709:34:58.533UTC [gossip.privdata] StoreBlock -> INFO3fe[0m [public] Received block [388] from buffer
[31m2020-02-0709:34:58.534UTC [committer.txvalidator] VSCCValidateTx -> ERRO 3ff[0m chaincode info:17260/publicdidn't match info:17280/publicin lscc
github.com/hyperledger/fabric/core/committer/txvalidator.(*VsccValidatorImpl).VSCCValidateTx
    /opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/vscc_validator.go:200
github.com/hyperledger/fabric/core/committer/txvalidator.(*TxValidator).validateTx
    /opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/validator.go:345
github.com/hyperledger/fabric/core/committer/txvalidator.(*TxValidator).Validate.func1.1
    /opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/validator.go:158
runtime.goexit
    /opt/go/src/runtime/asm_amd64.s:1337
[31m2020-02-0709:34:58.534UTC [committer.txvalidator] validateTx -> ERRO 400[0m VSCCValidateTx for transaction txId = df6187ff4f6b822cd60f17a4cd5f04e27ac8ab1c86bbbf550409feff47912b43returned error:chaincode info:17260/publicdidn't match info:17280/publicin lscc
[34m2020-02-0709:34:58.534UTC [committer.txvalidator] Validate -> INFO401[0m [public] Validated block [388] in 0ms
[33m2020-02-0709:34:58.534UTC [valimpl] preprocessProtoBlock -> WARN402[0m Channel [public]: Block [388] Transaction index [1] TxId [df6187ff4f6b822cd60f17a4cd5f04e27ac8ab1c86bbbf550409feff47912b43] marked as invalid by committer. Reason code [EXPIRED_CHAINCODE]
 

 



This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at
https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________

www.accenture.com



Re: Transaction Validation Failure

Yacov
 

Is this a system chaincode or a regular one?





From:        "Eryargi, Hakan via Lists.Hyperledger.Org" <hakan.eryargi=accenture.com@...>
To:        "fabric@..." <fabric@...>
Cc:        fabric@...
Date:        02/10/2020 02:16 PM
Subject:        [EXTERNAL] [Hyperledger Fabric] Transaction Validation Failure
Sent by:        fabric@...




Hi,
 
Are all transaction validation failures handled the same way and propagated back to client (Node.js SDK)? In particular I’m asking about EXPIRED_CHAINCODE failure.
 
I’m investigating a weird issue where some transactions somehow disappear from the chain. Developers claim it is committed to chain and visible in the CouchDB but somehow later on disappear somehow. It’s not also visible in the key history.
 
While checking the peer logs I’ve came across below failure. My understanding is, chaincode is upgraded to a new version in the time window between transaction proposal is endorsed and sent to peers for commitment. So peers rejected the transaction because it’s endorsed by an old version of chaincode.
 
Weird thing is, there are no logs on the application side related to this validation failure.
 
So may it be the case, this error is not propagated to the client application? Or is it an improper setting on our side for listening for such events?
 
Thanks,
Hakan
 
 
[34m2020-02-0709:34:55.628UTC [gossip.privdata] StoreBlock -> INFO3f2[0m [public] Received block [386] from buffer
[31m2020-02-0709:34:55.628UTC [committer.txvalidator] VSCCValidateTx -> ERRO 3f3[0m chaincode info:17260/publicdidn't match info:17280/publicin lscc
github.com/hyperledger/fabric/core/committer/txvalidator.(*VsccValidatorImpl).VSCCValidateTx
    /opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/vscc_validator.go:200
github.com/hyperledger/fabric/core/committer/txvalidator.(*TxValidator).validateTx
    /opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/validator.go:345
github.com/hyperledger/fabric/core/committer/txvalidator.(*TxValidator).Validate.func1.1
    /opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/validator.go:158
runtime.goexit
    /opt/go/src/runtime/asm_amd64.s:1337
[31m2020-02-0709:34:55.628UTC [committer.txvalidator] validateTx -> ERRO 3f4[0m VSCCValidateTx for transaction txId = ecb40373f63e23e46b95a9181b82bd667d88ffd3ec2ce3298f6584f6320babedreturned error:chaincode info:17260/publicdidn't match info:17280/publicin lscc
[34m2020-02-0709:34:55.629UTC [committer.txvalidator] Validate -> INFO3f5[0m [public] Validated block [386] in 0ms
[33m2020-02-0709:34:55.629UTC [valimpl] preprocessProtoBlock -> WARN3f6[0m Channel [public]: Block [386] Transaction index [1] TxId [ecb40373f63e23e46b95a9181b82bd667d88ffd3ec2ce3298f6584f6320babed] marked as invalid by committer. Reason code [EXPIRED_CHAINCODE]
[34m2020-02-0709:34:55.719UTC [kvledger] CommitWithPvtData -> INFO3f7[0m [public] Committed block [386] with 2transaction(s) in 90ms (state_validation=6ms block_and_pvtdata_commit=63ms state_commit=7ms) commitHash=[04da119737eb4edc05196bf00299754f07df0b5f1601474c227140486f547b07]
[34m2020-02-0709:34:56.964UTC [gossip.privdata] StoreBlock -> INFO3f8[0m [public] Received block [387] from buffer
[31m2020-02-0709:34:56.964UTC [committer.txvalidator] VSCCValidateTx -> ERRO 3f9[0m chaincode info:17260/publicdidn't match info:17280/publicin lscc
github.com/hyperledger/fabric/core/committer/txvalidator.(*VsccValidatorImpl).VSCCValidateTx
    /opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/vscc_validator.go:200
github.com/hyperledger/fabric/core/committer/txvalidator.(*TxValidator).validateTx
    /opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/validator.go:345
github.com/hyperledger/fabric/core/committer/txvalidator.(*TxValidator).Validate.func1.1
    /opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/validator.go:158
runtime.goexit
    /opt/go/src/runtime/asm_amd64.s:1337
[31m2020-02-0709:34:56.964UTC [committer.txvalidator] validateTx -> ERRO 3fa[0m VSCCValidateTx for transaction txId = 2a686e6948e892c853e48972863bdd6c40c79189ec89099d80dfd69db9fe68eareturned error:chaincode info:17260/publicdidn't match info:17280/publicin lscc
[34m2020-02-0709:34:56.964UTC [committer.txvalidator] Validate -> INFO3fb[0m [public] Validated block [387] in 0ms
[33m2020-02-0709:34:56.964UTC [valimpl] preprocessProtoBlock -> WARN3fc[0m Channel [public]: Block [387] Transaction index [0] TxId [2a686e6948e892c853e48972863bdd6c40c79189ec89099d80dfd69db9fe68ea] marked as invalid by committer. Reason code [EXPIRED_CHAINCODE]
[34m2020-02-0709:34:57.043UTC [kvledger] CommitWithPvtData -> INFO3fd[0m [public] Committed block [387] with 1transaction(s) in 78ms (state_validation=0ms block_and_pvtdata_commit=46ms state_commit=16ms) commitHash=[e229a1c1b938ac6f9ee707f3ab7a6899f5dccb5cbc30443a18da54121fa56194]
[34m2020-02-0709:34:58.533UTC [gossip.privdata] StoreBlock -> INFO3fe[0m [public] Received block [388] from buffer
[31m2020-02-0709:34:58.534UTC [committer.txvalidator] VSCCValidateTx -> ERRO 3ff[0m chaincode info:17260/publicdidn't match info:17280/publicin lscc
github.com/hyperledger/fabric/core/committer/txvalidator.(*VsccValidatorImpl).VSCCValidateTx
    /opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/vscc_validator.go:200
github.com/hyperledger/fabric/core/committer/txvalidator.(*TxValidator).validateTx
    /opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/validator.go:345
github.com/hyperledger/fabric/core/committer/txvalidator.(*TxValidator).Validate.func1.1
    /opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/validator.go:158
runtime.goexit
    /opt/go/src/runtime/asm_amd64.s:1337
[31m2020-02-0709:34:58.534UTC [committer.txvalidator] validateTx -> ERRO 400[0m VSCCValidateTx for transaction txId = df6187ff4f6b822cd60f17a4cd5f04e27ac8ab1c86bbbf550409feff47912b43returned error:chaincode info:17260/publicdidn't match info:17280/publicin lscc
[34m2020-02-0709:34:58.534UTC [committer.txvalidator] Validate -> INFO401[0m [public] Validated block [388] in 0ms
[33m2020-02-0709:34:58.534UTC [valimpl] preprocessProtoBlock -> WARN402[0m Channel [public]: Block [388] Transaction index [1] TxId [df6187ff4f6b822cd60f17a4cd5f04e27ac8ab1c86bbbf550409feff47912b43] marked as invalid by committer. Reason code [EXPIRED_CHAINCODE]
 




This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at
https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________

www.accenture.com




Transaction Validation Failure

Eryargi, Hakan
 

Hi,

 

Are all transaction validation failures handled the same way and propagated back to client (Node.js SDK)? In particular I’m asking about EXPIRED_CHAINCODE failure.

 

I’m investigating a weird issue where some transactions somehow disappear from the chain. Developers claim it is committed to chain and visible in the CouchDB but somehow later on disappear somehow. It’s not also visible in the key history.

 

While checking the peer logs I’ve came across below failure. My understanding is, chaincode is upgraded to a new version in the time window between transaction proposal is endorsed and sent to peers for commitment. So peers rejected the transaction because it’s endorsed by an old version of chaincode.

 

Weird thing is, there are no logs on the application side related to this validation failure.

 

So may it be the case, this error is not propagated to the client application? Or is it an improper setting on our side for listening for such events?

 

Thanks,

Hakan

 

 

[34m2020-02-07 09:34:55.628 UTC [gossip.privdata] StoreBlock -> INFO 3f2[0m [public] Received block [386] from buffer

[31m2020-02-07 09:34:55.628 UTC [committer.txvalidator] VSCCValidateTx -> ERRO 3f3[0m chaincode info:17260/public didn't match info:17280/public in lscc

github.com/hyperledger/fabric/core/committer/txvalidator.(*VsccValidatorImpl).VSCCValidateTx

    /opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/vscc_validator.go:200

github.com/hyperledger/fabric/core/committer/txvalidator.(*TxValidator).validateTx

    /opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/validator.go:345

github.com/hyperledger/fabric/core/committer/txvalidator.(*TxValidator).Validate.func1.1

    /opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/validator.go:158

runtime.goexit

    /opt/go/src/runtime/asm_amd64.s:1337

[31m2020-02-07 09:34:55.628 UTC [committer.txvalidator] validateTx -> ERRO 3f4[0m VSCCValidateTx for transaction txId = ecb40373f63e23e46b95a9181b82bd667d88ffd3ec2ce3298f6584f6320babed returned error: chaincode info:17260/public didn't match info:17280/public in lscc

[34m2020-02-07 09:34:55.629 UTC [committer.txvalidator] Validate -> INFO 3f5[0m [public] Validated block [386] in 0ms

[33m2020-02-07 09:34:55.629 UTC [valimpl] preprocessProtoBlock -> WARN 3f6[0m Channel [public]: Block [386] Transaction index [1] TxId [ecb40373f63e23e46b95a9181b82bd667d88ffd3ec2ce3298f6584f6320babed] marked as invalid by committer. Reason code [EXPIRED_CHAINCODE]

[34m2020-02-07 09:34:55.719 UTC [kvledger] CommitWithPvtData -> INFO 3f7[0m [public] Committed block [386] with 2 transaction(s) in 90ms (state_validation=6ms block_and_pvtdata_commit=63ms state_commit=7ms) commitHash=[04da119737eb4edc05196bf00299754f07df0b5f1601474c227140486f547b07]

[34m2020-02-07 09:34:56.964 UTC [gossip.privdata] StoreBlock -> INFO 3f8[0m [public] Received block [387] from buffer

[31m2020-02-07 09:34:56.964 UTC [committer.txvalidator] VSCCValidateTx -> ERRO 3f9[0m chaincode info:17260/public didn't match info:17280/public in lscc

github.com/hyperledger/fabric/core/committer/txvalidator.(*VsccValidatorImpl).VSCCValidateTx

    /opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/vscc_validator.go:200

github.com/hyperledger/fabric/core/committer/txvalidator.(*TxValidator).validateTx

    /opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/validator.go:345

github.com/hyperledger/fabric/core/committer/txvalidator.(*TxValidator).Validate.func1.1

    /opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/validator.go:158

runtime.goexit

    /opt/go/src/runtime/asm_amd64.s:1337

[31m2020-02-07 09:34:56.964 UTC [committer.txvalidator] validateTx -> ERRO 3fa[0m VSCCValidateTx for transaction txId = 2a686e6948e892c853e48972863bdd6c40c79189ec89099d80dfd69db9fe68ea returned error: chaincode info:17260/public didn't match info:17280/public in lscc

[34m2020-02-07 09:34:56.964 UTC [committer.txvalidator] Validate -> INFO 3fb[0m [public] Validated block [387] in 0ms

[33m2020-02-07 09:34:56.964 UTC [valimpl] preprocessProtoBlock -> WARN 3fc[0m Channel [public]: Block [387] Transaction index [0] TxId [2a686e6948e892c853e48972863bdd6c40c79189ec89099d80dfd69db9fe68ea] marked as invalid by committer. Reason code [EXPIRED_CHAINCODE]

[34m2020-02-07 09:34:57.043 UTC [kvledger] CommitWithPvtData -> INFO 3fd[0m [public] Committed block [387] with 1 transaction(s) in 78ms (state_validation=0ms block_and_pvtdata_commit=46ms state_commit=16ms) commitHash=[e229a1c1b938ac6f9ee707f3ab7a6899f5dccb5cbc30443a18da54121fa56194]

[34m2020-02-07 09:34:58.533 UTC [gossip.privdata] StoreBlock -> INFO 3fe[0m [public] Received block [388] from buffer

[31m2020-02-07 09:34:58.534 UTC [committer.txvalidator] VSCCValidateTx -> ERRO 3ff[0m chaincode info:17260/public didn't match info:17280/public in lscc

github.com/hyperledger/fabric/core/committer/txvalidator.(*VsccValidatorImpl).VSCCValidateTx

    /opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/vscc_validator.go:200

github.com/hyperledger/fabric/core/committer/txvalidator.(*TxValidator).validateTx

    /opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/validator.go:345

github.com/hyperledger/fabric/core/committer/txvalidator.(*TxValidator).Validate.func1.1

    /opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/validator.go:158

runtime.goexit

    /opt/go/src/runtime/asm_amd64.s:1337

[31m2020-02-07 09:34:58.534 UTC [committer.txvalidator] validateTx -> ERRO 400[0m VSCCValidateTx for transaction txId = df6187ff4f6b822cd60f17a4cd5f04e27ac8ab1c86bbbf550409feff47912b43 returned error: chaincode info:17260/public didn't match info:17280/public in lscc

[34m2020-02-07 09:34:58.534 UTC [committer.txvalidator] Validate -> INFO 401[0m [public] Validated block [388] in 0ms

[33m2020-02-07 09:34:58.534 UTC [valimpl] preprocessProtoBlock -> WARN 402[0m Channel [public]: Block [388] Transaction index [1] TxId [df6187ff4f6b822cd60f17a4cd5f04e27ac8ab1c86bbbf550409feff47912b43] marked as invalid by committer. Reason code [EXPIRED_CHAINCODE]

 




This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________

www.accenture.com


Re: How many ordering services should a network have? #fabric #fabric-orderer

Joe Alewine <joe.alewine@...>
 

Rui,
 
While it's possible to use the console to build a configuration of any number of ordering nodes (no configuration is explicitly restricted), some numbers provide a better balance between cost and performance than others. The reason for this lies in satisfying the needs of high availability (HA) and in understanding the Raft concept of the "quorum", the minimum number of nodes that must be available (out of the total number) for the ordering service to process transactions.
 
In Raft, a majority of the total number of nodes is needed to form a quorum. In other words, if you have one node, you need that node available to have a quorum, because the majority of one is one. Similarly, if you have two nodes, you will need both available, since the majority of two is two (for this reason, a configuration of two nodes is discouraged; there is no advantage to a two node configuration). In a similar vein, the majority of three is two, the majority of four is three, the majority of five is three, and so on.
 
While satisfying the quorum will make sure the ordering service is functioning, production networks also have to think about deployment configurations that are highly available (in other words, configurations in which the loss of a certain number of nodes can be tolerated by the system). Typically, this means tolerating two nodes failing: one node going down during a normal maintenance cycle, and another going down for any other reason (such as a power outage or error).
 
This is why five nodes is a good number for a production network. Recall that the majority of five is three. This means that in a five node configuration, the loss of two nodes can be tolerated. If your configuration features four nodes, only one node can be down for any reason before another node going down means a quorum has been lost and the ordering service will stop processing transactions.
 
Hope this helps.
 
Regards,
 
Joe Alewine
IBM Blockchain, Raleigh
 
rocket chat: joe-alewine
slack: joe.alewine
 
 
 

----- Original message -----
From: "Rui Gonçalo" <rainmanmorais@...>
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] How many ordering services should a network have? #fabric #fabric-orderer
Date: Sat, Feb 8, 2020 11:03 AM
 
Hello guys,

I was just wondering what is the best practice when it comes to the ordering service in a production environment.
What is the proportion of ordering service nodes in relation to the size of the network? Or is a ordering service node with Raft, meaning various instances, enough for a production network?
Should each organization have its own ordering service node? or only a instance?

Help would be much apreciated guys, Thank You.
 


How many ordering services should a network have? #fabric #fabric-orderer

Rui M.
 

Hello guys,

I was just wondering what is the best practice when it comes to the ordering service in a production environment.
What is the proportion of ordering service nodes in relation to the size of the network? Or is a ordering service node with Raft, meaning various instances, enough for a production network?
Should each organization have its own ordering service node? or only a instance?

Help would be much apreciated guys, Thank You.


Re: docker-compose.yml syntax doubts

Yacov
 

In green.



From:        "Tomás Peixinho" <tom.peixinho@...>
To:        Yacov Manevich <YACOVM@...>
Cc:        "hyperledger-fabric@..." <hyperledger-fabric@...>
Date:        02/08/2020 01:50 AM
Subject:        [EXTERNAL] RE:  [Hyperledger Fabric] docker-compose.yml syntax doubts




Thanks for the quick response, Yacov! And when I said 2.5 years, I atually meant it. That's the time I have been working on my master's thesis. Anyway...

What do you mean when you say I shouldn't use the "Any member" policy? Why is it bad? If it's the default, why should I not? Not that I want to, I would like to define my own policy, I'm just trying to understand.
Because an endorsement policy is what defines who, among the organizations in the network, is able to change data in an arbitrary way.
Consider a case where you have a smart contract that transfers money from Alice to Bob.
You'd want both Alice and Bob to consent on the money transfer, otherwise any of the parties can rob each other.
You'd also probably want another party, say - some auditor, to consent on these transactions, otherwise Alice and Bob can collude to print infinite money.
This is also why you should never use system chaincodes as smart contracts, because their endorsement policy can't be changed and it's always "any member".


"and it is the address that the peer publishes to other peers"  What do you mean by this? Published address for what? And why do they all take the same port, in this case, the 7051? That's just the default peer port, it can be changed. The address is the address that peers publish to each other in the gossip protocol. the other address they publish is the external endpoint (CORE_PEER_GOSSIP_EXTERNALENDPOINT) which is used for inter-org communication.

"An endorsing peer is a peer that has the chaincode installed."Thank you for this, I never really got this and I don't see anywhere in the docs where this explanation is. However, if this is the case but all the peers are invisible to other organization's peers, how does this work? If you're a client then when you send a transaction to a peer, as long as you know the peer, it doesn't mean anything if the other peers don't know about the peer. All peers receive blocks from the ordering service node(s) so in theory unless you use private data or service discovery, you don't need peers to know about each other.  If they can't communicate with each other, does that mean that only the peers from the same org are endorsing my transactions? When I look at the logs from all the other containers, all of them have lines that read something like:

2020-02-07 23:34:49.793 UTC [gossip.privdata] StoreBlock -> INFO 04d [mychannel] Received block [4] from buffer
2020-02-07 23:34:49.798 UTC [committer.txvalidator] Validate -> INFO 04e [mychannel] Validated block [4] in 4ms
2020-02-07 23:34:49.816 UTC [kvledger] CommitWithPvtData -> INFO 04f [mychannel] Committed block [4] with 1 transaction(s) in 18ms (state_validation=0ms block_commit=10ms state_commit=2ms)

What is this referring to if they can't see what the other peers are doing They got a block from the ordering service and validated and committed it. (this was from a log from a peer in a different org than the one that issued the transaction)?

As for the sample/tutorial that I was using, it was the one that was recommended in a lot of places, a while back, when Hyperledger started to have support for java. I'm mainly a java developer, so I thought it'd be easier to work with a java blockchain. The guy who did it worked for IBM so I thought it was trustworthy. Trustworthy or not, the developer can always abandon its repository because he/she is busy or moving to another project, and as Fabric develops these samples are not updated along with Fabric because they are not in the official Hyperledger organization. Going back and changing everything to work with the byfn is not an option now.

Anyway, thanks for the patience, man.

Tomás





De: Yacov Manevich <YACOVM@...>
Enviado:
sexta-feira, 7 de fevereiro de 2020 23:01
Para:
Tomás Peixinho <tom.peixinho@...>
Cc:
hyperledger-fabric@... <hyperledger-fabric@...>
Assunto:
Re: [Hyperledger Fabric] docker-compose.yml syntax doubts

 
Answers inline in blue.





From:        
"Tomás Peixinho" <tom.peixinho@...>
To:        
"hyperledger-fabric@..." <hyperledger-fabric@...>
Date:        
02/08/2020 12:35 AM
Subject:        
[EXTERNAL] [Hyperledger Fabric] docker-compose.yml syntax doubts
Sent by:        
fabric@...




Good evening,


I am at my wits end with Hyperledger Fabric. Now that I got this out of the way, on to my question:


Apparently, to define the network topology for my blockchain, I have to modify three files, configtx.yaml, crypto-config.yaml and docker-compose.yml (I know that in the byfn examples, there are more files, like docker-compose-cli.yml, however I'm using the java sdk provided here,
https://github.com/IBM/blockchain-application-using-fabric-java-sdk,
Do yourself a favor and don't use any sample or tutorial that is not hosted under the official Hyperledger organization https://github.com/hyperledger/.and I only have the three files that I mentioned previously).

The syntax for the first two is pretty straight-forward, I add the orgs and the peers that I need and that's that. As for the docker-compose.yml, I'm really having trouble understanding what I have to change. For each peer there are two lines on the "ports" field. For peer0-org1, for example, there's this "7051:7051" and on the second line "7053:7053". From the docker compose web page, I read that the first port is the host port and the second is the container port... I don't know what any of these are and what they are used for
The A:B notation means that traffic towards the host on port A is redirected towards the container on port B.. Also, why are there two entries for the same peer? You only need the A:7051 one. The 7053 port was deprecated a few years ago. That's why you shouldn't use samples from a non-Hyperledger repository. People leave them and never update themWhen I get the network up and running, I can see that all the other containers are connecting to these two ports, but why? Actually, I think I know why, it's because it is defined for each peer in the docker-compose, but is there any reason for this? What is the core peer that every other peer has to reference, for example, CORE_PEER_ADDRESS=peer0.org1.example.com:7051? Why do all the peers need this line and have to have the defined port as the peer0-org1 port? Does this mean that all the peers in the network have to communicate with this peer? And if so, why is that? I'm really having trouble understanding this part.  The A_B_C="foo" environment variable definition, is a way to configure the core.yaml or orderer.yaml files without changing the files, but just defining environment variables instead. This CORE_PEER_ADDRESS defines peer.address in the core.yaml file and it is the address that the peer publishes to other peers

Also, and I don't even know if this has something to do with this file or not but, how can I see which peers are "endorsing peers" and which aren't?
An endorsing peer is a peer that has the chaincode installed.  And how can I define the endorsement policy? Read the documents https://hyperledger-fabric.readthedocs.io/en/release-1.4/endorsement-policies.htmlI know this has to be defined at instantiation time, but if nothing is passed, what is the default policy that is used? "Any member" (don't use it...)Are all the peers endorsing every transaction, or are no peers doing it?  "Any member" means - at least a single endorsement from any peer or client (don't use it) I know in byfn you have to change this with the cli but, again, I'm using the java sdk blockchain example and I'm not doing anything with the cli. I know I can give a file to my instantiation function, but by default it's not using anything and I wonder what's happening behind the scenes in this case.

Finally, when trying to see which peers were endorsing the transactions, I came across this warning in one of the container logs:
"2020-02-07 18:50:44.458 UTC [gossip.gossip] NewGossipService -> WARN 013 External endpoint is empty, peer will not be accessible outside of its organization".
Does this mean that the peers can't communicate with each other between organizations?
Exactly, but it also means the peer is "invisible" to peers in other organizations. What does that mean for the endorsing process? Does this have something to do with the ports that I defined in the docker-compose.yml? No. This has nothing to do with it. You can configure the SDK to use these peers as you see fit, but these peers won't be used by service discovery https://hyperledger-fabric.readthedocs.io/en/release-1.4/discovery-overview.html

I'm really struggling with this, so any help would be greatly appreciated. Also, I have been working on this for the past almost two and a half years of my life,
 Are you saying that you aged 2.5 years in one day or one week? so please don't tell me to read the tutorials on the IBM page and the readthedocs page, coz I've read that a million times already and I still don't understand most of what I'm doing

Sorry for the rant. Thank you in advance.


Tomás






Re: docker-compose.yml syntax doubts

Tomás Peixinho
 

Thanks for the quick response, Yacov! And when I said 2.5 years, I atually meant it. That's the time I have been working on my master's thesis. Anyway...

What do you mean when you say I shouldn't use the "Any member" policy? Why is it bad? If it's the default, why should I not? Not that I want to, I would like to define my own policy, I'm just trying to understand.

"and it is the address that the peer publishes to other peers"  What do you mean by this? Published address for what? And why do they all take the same port, in this case, the 7051?

"An endorsing peer is a peer that has the chaincode installed." Thank you for this, I never really got this and I don't see anywhere in the docs where this explanation is. However, if this is the case but all the peers are invisible to other organization's peers, how does this work? If they can't communicate with each other, does that mean that only the peers from the same org are endorsing my transactions? When I look at the logs from all the other containers, all of them have lines that read something like:

2020-02-07 23:34:49.793 UTC [gossip.privdata] StoreBlock -> INFO 04d [mychannel] Received block [4] from buffer
2020-02-07 23:34:49.798 UTC [committer.txvalidator] Validate -> INFO 04e [mychannel] Validated block [4] in 4ms
2020-02-07 23:34:49.816 UTC [kvledger] CommitWithPvtData -> INFO 04f [mychannel] Committed block [4] with 1 transaction(s) in 18ms (state_validation=0ms block_commit=10ms state_commit=2ms)

What is this referring to if they can't see what the other peers are doing (this was from a log from a peer in a different org than the one that issued the transaction)?

As for the sample/tutorial that I was using, it was the one that was recommended in a lot of places, a while back, when Hyperledger started to have support for java. I'm mainly a java developer, so I thought it'd be easier to work with a java blockchain. The guy who did it worked for IBM so I thought it was trustworthy. Going back and changing everything to work with the byfn is not an option now.

Anyway, thanks for the patience, man.

Tomás




De: Yacov Manevich <YACOVM@...>
Enviado: sexta-feira, 7 de fevereiro de 2020 23:01
Para: Tomás Peixinho <tom.peixinho@...>
Cc: hyperledger-fabric@... <hyperledger-fabric@...>
Assunto: Re: [Hyperledger Fabric] docker-compose.yml syntax doubts
 
Answers inline in blue.





From:        "Tomás Peixinho" <tom.peixinho@...>
To:        "hyperledger-fabric@..." <hyperledger-fabric@...>
Date:        02/08/2020 12:35 AM
Subject:        [EXTERNAL] [Hyperledger Fabric] docker-compose.yml syntax doubts
Sent by:        fabric@...




Good evening,

I am at my wits end with Hyperledger Fabric. Now that I got this out of the way, on to my question:

Apparently, to define the network topology for my blockchain, I have to modify three files, configtx.yaml, crypto-config.yaml and docker-compose.yml (I know that in the byfn examples, there are more files, like docker-compose-cli.yml, however I'm using the java sdk provided here, https://github.com/IBM/blockchain-application-using-fabric-java-sdk,
 Do yourself a favor and don't use any sample or tutorial that is not hosted under the official Hyperledger organization https://github.com/hyperledger/.and I only have the three files that I mentioned previously).

The syntax for the first two is pretty straight-forward, I add the orgs and the peers that I need and that's that. As for the docker-compose.yml, I'm really having trouble understanding what I have to change. For each peer there are two lines on the "ports" field. For peer0-org1, for example, there's this "7051:7051" and on the second line "7053:7053". From the docker compose web page, I read that the first port is the host port and the second is the container port... I don't know what any of these are and what they are used for The A:B notation means that traffic towards the host on port A is redirected towards the container on port B.. Also, why are there two entries for the same peer? You only need the A:7051 one. The 7053 port was deprecated a few years ago. That's why you shouldn't use samples from a non-Hyperledger repository. People leave them and never update themWhen I get the network up and running, I can see that all the other containers are connecting to these two ports, but why? Actually, I think I know why, it's because it is defined for each peer in the docker-compose, but is there any reason for this? What is the core peer that every other peer has to reference, for example, CORE_PEER_ADDRESS=peer0.org1.example.com:7051? Why do all the peers need this line and have to have the defined port as the peer0-org1 port? Does this mean that all the peers in the network have to communicate with this peer? And if so, why is that? I'm really having trouble understanding this part.  The A_B_C="foo" environment variable definition, is a way to configure the core.yaml or orderer.yaml files without changing the files, but just defining environment variables instead. This CORE_PEER_ADDRESS defines peer.address in the core.yaml file and it is the address that the peer publishes to other peers

Also, and I don't even know if this has something to do with this file or not but, how can I see which peers are "endorsing peers" and which aren't? An endorsing peer is a peer that has the chaincode installed.  And how can I define the endorsement policy? Read the documents https://hyperledger-fabric.readthedocs.io/en/release-1.4/endorsement-policies.html I know this has to be defined at instantiation time, but if nothing is passed, what is the default policy that is used? "Any member" (don't use it...)Are all the peers endorsing every transaction, or are no peers doing it?  "Any member" means - at least a single endorsement from any peer or client (don't use it) I know in byfn you have to change this with the cli but, again, I'm using the java sdk blockchain example and I'm not doing anything with the cli. I know I can give a file to my instantiation function, but by default it's not using anything and I wonder what's happening behind the scenes in this case.

Finally, when trying to see which peers were endorsing the transactions, I came across this warning in one of the container logs:
"2020-02-07 18:50:44.458 UTC [gossip.gossip] NewGossipService -> WARN 013 External endpoint is empty, peer will not be accessible outside of its organization".
Does this mean that the peers can't communicate with each other between organizations? Exactly, but it also means the peer is "invisible" to peers in other organizations. What does that mean for the endorsing process? Does this have something to do with the ports that I defined in the docker-compose.yml? No. This has nothing to do with it. You can configure the SDK to use these peers as you see fit, but these peers won't be used by service discovery https://hyperledger-fabric.readthedocs.io/en/release-1.4/discovery-overview.html

I'm really struggling with this, so any help would be greatly appreciated. Also, I have been working on this for the past almost two and a half years of my life,  Are you saying that you aged 2.5 years in one day or one week? so please don't tell me to read the tutorials on the IBM page and the readthedocs page, coz I've read that a million times already and I still don't understand most of what I'm doing

Sorry for the rant. Thank you in advance.

Tomás




Re: docker-compose.yml syntax doubts

Yacov
 

Answers inline in blue.





From:        "Tomás Peixinho" <tom.peixinho@...>
To:        "hyperledger-fabric@..." <hyperledger-fabric@...>
Date:        02/08/2020 12:35 AM
Subject:        [EXTERNAL] [Hyperledger Fabric] docker-compose.yml syntax doubts
Sent by:        fabric@...




Good evening,

I am at my wits end with Hyperledger Fabric. Now that I got this out of the way, on to my question:

Apparently, to define the network topology for my blockchain, I have to modify three files, configtx.yaml, crypto-config.yaml and docker-compose.yml (I know that in the byfn examples, there are more files, like docker-compose-cli.yml, however I'm using the java sdk provided here, https://github.com/IBM/blockchain-application-using-fabric-java-sdk,
 Do yourself a favor and don't use any sample or tutorial that is not hosted under the official Hyperledger organization https://github.com/hyperledger/.and I only have the three files that I mentioned previously).

The syntax for the first two is pretty straight-forward, I add the orgs and the peers that I need and that's that. As for the docker-compose.yml, I'm really having trouble understanding what I have to change. For each peer there are two lines on the "ports" field. For peer0-org1, for example, there's this "7051:7051" and on the second line "7053:7053". From the docker compose web page, I read that the first port is the host port and the second is the container port... I don't know what any of these are and what they are used for The A:B notation means that traffic towards the host on port A is redirected towards the container on port B.. Also, why are there two entries for the same peer? You only need the A:7051 one. The 7053 port was deprecated a few years ago. That's why you shouldn't use samples from a non-Hyperledger repository. People leave them and never update themWhen I get the network up and running, I can see that all the other containers are connecting to these two ports, but why? Actually, I think I know why, it's because it is defined for each peer in the docker-compose, but is there any reason for this? What is the core peer that every other peer has to reference, for example, CORE_PEER_ADDRESS=peer0.org1.example.com:7051? Why do all the peers need this line and have to have the defined port as the peer0-org1 port? Does this mean that all the peers in the network have to communicate with this peer? And if so, why is that? I'm really having trouble understanding this part.  The A_B_C="foo" environment variable definition, is a way to configure the core.yaml or orderer.yaml files without changing the files, but just defining environment variables instead. This CORE_PEER_ADDRESS defines peer.address in the core.yaml file and it is the address that the peer publishes to other peers

Also, and I don't even know if this has something to do with this file or not but, how can I see which peers are "endorsing peers" and which aren't? An endorsing peer is a peer that has the chaincode installed.  And how can I define the endorsement policy? Read the documents https://hyperledger-fabric.readthedocs.io/en/release-1.4/endorsement-policies.html I know this has to be defined at instantiation time, but if nothing is passed, what is the default policy that is used? "Any member" (don't use it...)Are all the peers endorsing every transaction, or are no peers doing it?  "Any member" means - at least a single endorsement from any peer or client (don't use it) I know in byfn you have to change this with the cli but, again, I'm using the java sdk blockchain example and I'm not doing anything with the cli. I know I can give a file to my instantiation function, but by default it's not using anything and I wonder what's happening behind the scenes in this case.

Finally, when trying to see which peers were endorsing the transactions, I came across this warning in one of the container logs:
"2020-02-07 18:50:44.458 UTC [gossip.gossip] NewGossipService -> WARN 013 External endpoint is empty, peer will not be accessible outside of its organization".
Does this mean that the peers can't communicate with each other between organizations? Exactly, but it also means the peer is "invisible" to peers in other organizations. What does that mean for the endorsing process? Does this have something to do with the ports that I defined in the docker-compose.yml? No. This has nothing to do with it. You can configure the SDK to use these peers as you see fit, but these peers won't be used by service discovery https://hyperledger-fabric.readthedocs.io/en/release-1.4/discovery-overview.html

I'm really struggling with this, so any help would be greatly appreciated. Also, I have been working on this for the past almost two and a half years of my life,  Are you saying that you aged 2.5 years in one day or one week? so please don't tell me to read the tutorials on the IBM page and the readthedocs page, coz I've read that a million times already and I still don't understand most of what I'm doing

Sorry for the rant. Thank you in advance.

Tomás




docker-compose.yml syntax doubts

Tomás Peixinho
 

Good evening,

I am at my wits end with Hyperledger Fabric. Now that I got this out of the way, on to my question:

Apparently, to define the network topology for my blockchain, I have to modify three files, configtx.yaml, crypto-config.yaml and docker-compose.yml (I know that in the byfn examples, there are more files, like docker-compose-cli.yml, however I'm using the java sdk provided here, https://github.com/IBM/blockchain-application-using-fabric-java-sdk, and I only have the three files that I mentioned previously). 

The syntax for the first two is pretty straight-forward, I add the orgs and the peers that I need and that's that. As for the docker-compose.yml, I'm really having trouble understanding what I have to change. For each peer there are two lines on the "ports" field. For peer0-org1, for example, there's this "7051:7051" and on the second line "7053:7053". From the docker compose web page, I read that the first port is the host port and the second is the container port... I don't know what any of these are and what they are used for. Also, why are there two entries for the same peer? When I get the network up and running, I can see that all the other containers are connecting to these two ports, but why? Actually, I think I know why, it's because it is defined for each peer in the docker-compose, but is there any reason for this? What is the core peer that every other peer has to reference, for example, CORE_PEER_ADDRESS=peer0.org1.example.com:7051? Why do all the peers need this line and have to have the defined port as the peer0-org1 port? Does this mean that all the peers in the network have to communicate with this peer? And if so, why is that? I'm really having trouble understanding this part.

Also, and I don't even know if this has something to do with this file or not but, how can I see which peers are "endorsing peers" and which aren't? And how can I define the endorsement policy? I know this has to be defined at instantiation time, but if nothing is passed, what is the default policy that is used? Are all the peers endorsing every transaction, or are no peers doing it? I know in byfn you have to change this with the cli but, again, I'm using the java sdk blockchain example and I'm not doing anything with the cli. I know I can give a file to my instantiation function, but by default it's not using anything and I wonder what's happening behind the scenes in this case.

Finally, when trying to see which peers were endorsing the transactions, I came across this warning in one of the container logs: 
"2020-02-07 18:50:44.458 UTC [gossip.gossip] NewGossipService -> WARN 013 External endpoint is empty, peer will not be accessible outside of its organization". 
Does this mean that the peers can't communicate with each other between organizations? What does that mean for the endorsing process? Does this have something to do with the ports that I defined in the docker-compose.yml?

I'm really struggling with this, so any help would be greatly appreciated. Also, I have been working on this for the past almost two and a half years of my life, so please don't tell me to read the tutorials on the IBM page and the readthedocs page, coz I've read that a million times already and I still don't understand most of what I'm doing

Sorry for the rant. Thank you in advance.

Tomás


Hyperledger Fabric Documentation Workgroup call - Western hemisphere - Fri, 02/07/2020 #cal-notice

fabric@lists.hyperledger.org Calendar <noreply@...>
 

Hyperledger Fabric Documentation Workgroup call - Western hemisphere

When:
Friday, 7 February 2020
4:00pm to 5:00pm
(GMT+00:00) Europe/London

Where:
https://zoom.us/j/6223336701

Organizer:
a_o-dowd@... +441962816761

Description:
Documentation workgroup call.
Agenda, minutes and recordings :https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group


Fabric-Ca User Revoke

Nicholas Leonardi
 

Hey guys,

I've been working on a user revoke script but have come across some points after some research and testing.
Here's a scenario that makes it very troublesome from the process that I understood.

There are two organizations, Org1 as the main organization with permissions to submit 
channel configurations with a root CA. 

There's Org2 that uses an Intermediate CA to issue users and manage their own "staff" and
who may access the network to transact with the chaincodes. 

However, Org2 does not have permission to submit channel configuration updates so when
it is needed to revoke Org2 users certificates, it would need to request Org1 to do so through 
a channel update and add it to a revocation list. 

Is there a policy that would allow Org2 to submit channel updates that only affects it's own
json configuration "channel.Org2MSP..." section of the config json but restrict it from changing any
other channel configurations?

I must be missing something with ACL's because this would be very impractical if there are a bunch
of organizations in a network with only one org managing channel updates.

Thanks in advance,
Nick


Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere - Fri, 02/07/2020 #cal-notice

fabric@lists.hyperledger.org Calendar <noreply@...>
 

Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere

When:
Friday, 7 February 2020
6:00am to 7:00am
(GMT+00:00) Europe/London

Where:
https://zoom.us/j/6223336701

Organizer:
a_o-dowd@... +441962816761

Description:
Documentation workgroup call.
Agenda, minutes and recordings: https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group


Documentation Workgroup: Agenda for Friday, 7 Feb

Anthony O'Dowd <a_o-dowd@...>
 

Hello!

Please note the change in time for the Western hemisphere call this week. For this week only, it is 1 hour later than usual! The Eastern hemisphere call is at its regular time.

Other than this one-off change, we will hold the documentation workgroup call this Friday, both Western and Eastern hemispheres.   Thanks to everyone who attended last week's call.

The summary minutes for last week's meeting: https://wiki.hyperledger.org/display/fabric/Meetings

You can read all about the call at https://wiki.hyperledger.org/display/fabric/2020+01+31+DWG+Agenda It included a V2 status update from Pam and Joe, a migration walk-through from Joe, as well as a style guide review. We also covered introductory topic consolidation with Nik.  

Thanks for a great session last week. You can catch up via the recording: https://wiki.hyperledger.org/display/fabric/Recordings

You'll see that there are lots of interesting items for this week: https://wiki.hyperledger.org/display/fabric/2020+02+07+DWG+Agenda
Please feel free to contribute using the wiki.

You can also help build next week's agenda: https://wiki.hyperledger.org/display/fabric/2020+02+07+DWG+Agenda

Thanks!

Pam, Anthony,  Joe, Nik

Meeting Details
-------------
Please use the following link to attend the meeting:  https://zoom.us/j/6223336701

The meeting times are as follows: https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group

Meeting 114A: Friday 07 Feb
                   1130 India Standard Time
                   1400 China Standard Time
                   1500 Japan Standard Time
                   1700 Australia Eastern Time
                   1400 Singapore Time
                   1000 Gulf Standard Time
                   0900 Moscow Standard Time
                   0600 Greenwich Mean Time
                   0700 Central European Time    

Meeting 114B: Friday 07 Feb
              1100 Central Daylight Time
                   1200 Eastern Daylight Time
                   0900 Pacific Daylight Time
                   1400 Brasil Time (BRT)
                   1700 Greenwich Mean Time
                   1800 Central European Time
                   1900 Moscow Standard Tim

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


Re: Why does the Ordering Consensus Work?

Nikhil Gupta
 

Want to jump in to clear up something Brett said. If the chaincode is non-deterministic, then the read write sets will not match and will not pass the endorsement policy, and proposals will be rejected at the last stage of the transaction flow. The endorsement itself prevents non-deterministic chaincode from leading to divergent results.

Nik



-----fabric@... wrote: -----
To: trevor@...
From: "Gari Singh"
Sent by: fabric@...
Date: 02/05/2020 11:29PM
Cc: <fabric@...>
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Why does the Ordering Consensus Work?

Transaction consensus and validity in Fabric is not the same thing as the consensus mechanism used to build a fault tolerant ordering service.

Have a look at https://hyperledger-fabric.readthedocs.io/en/release-2.0/txflow.html  which describes the entire Fabric transaction flow ... this would be considered consensus for Fabric transactions.  At a high-level, it is comprised of:

- execute chaincode and collect endorsements
- submit for ordering
- ordering service orders and batches into blocks
- ordering service pushes blocks to peers on a per channel basis
- peers validate and commit transactions
  - check that endorsement policy has been satisfied (which means that enough peers executed chaincode with the same results based on policy)
  - check for collisions using an MVCC-like model (aka double-spend)
  - if valid, update state


The ordering service itself uses a consensus algorithm itself to make sure that all ordering nodes produce batches/blocks with the same transactions in the same order.

-----------------------------------------
Gari Singh
Distinguished Engineer, CTO - IBM Blockchain
IBM Middleware
550 King St
Littleton, MA 01460
Cell: 978-846-7499
garis@...
-----------------------------------------

-----fabric@... wrote: -----
To: <fabric@...>
From: "Trevor Lee Oakley"
Sent by: fabric@...
Date: 02/06/2020 03:30AM
Subject: [EXTERNAL] [Hyperledger Fabric] Why does the Ordering Consensus Work?

  
From what I know, the orderer is just assembling blocks from application transactions composed of the endorser responses to proposals. Then sending the blocks to committing peers. How is that a consensus process?
  
Surely we have to somehow compare the outcomes of the smart contracts and check that they all agree? Is that done in validation somehow?
  
  
Trevor
  







Re: Is it efficient when "Upgrade Chaincode New Docker Container will be created"?

Brett T Logan <brett.t.logan@...>
 

In 2.0 Fabric we added logic to remove unreferenced chaincode containers, so once your old version is no longer used anywhere it would be cleaned up. We also introduced a  new chaincode builder and launcher model in 2.0, this empowers developers and admins to run chaincode however they see fit, including totally devoid of Docker, take a look at it here: https://hyperledger-fabric.readthedocs.io/en/master/cc_launcher.html
 
Brett Logan
Software Engineer, IBM Blockchain
Phone: 1-984-242-6890
 
 
 

----- Original message -----
From: "Kimheng SOK" <sok.kimheng@...>
Sent by: fabric@...
To: hyperledger-fabric@...
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] Is it efficient when "Upgrade Chaincode New Docker Container will be created"?
Date: Thu, Feb 6, 2020 9:37 AM
 
Dear all,
 
I would like to ask about hyperledger performance related to chaincode upgrade. 
 
Each time when we upgrade the new chaincode, a new docker container will be created.
Do you think this is an optimal way to go?
 
Will hyperledger continue to adopt this concept, or may be modified to other solutions?
If YES why and if NO what is the alternative solution in mind?
 
Bests,
 

3761 - 3780 of 11436