Date   

CORE_PEER_CHAINCODEADDRESS when peer is not running in a docker container

Siddharth Jain
 

What should be the CORE_PEER_CHAINCODEADDRESS when the peer is not running in a docker container? E.g., peer is running on the host and listening for chaincode at 0.0.0.0:7052. If we set CORE_PEER_CHAINCODEADDRESS to 127.0.0.1:7051 then for the chaincode container 127.0.0.1 maps to the docker container itself not the host.


Re: Error: could not assemble transaction: ProposalResponsePayloads do not match

Siddharth Jain
 

could anyone point us to the code where the response payload is generated? is there any doc explaining what the response payload is? its a byte array but what does it contain?


From: Siddharth Jain <siddjain@...>
Sent: Monday, January 27, 2020 5:17 PM
To: fabric@... <fabric@...>
Subject: Error: could not assemble transaction: ProposalResponsePayloads do not match
 
we get this error when trying to invoke the chaincode on a network of 3 peers. However, we have verified if we invoke the chaincode individually on the peer nodes, all of them respond with Chaincode invoke successful. result: status:200. does anyone have any idea what could be wrong here?


Re: Storing/Retrieving key values in a collaborative way - endorsement policy

David Enyeart
 

Your question gets to the heart of many use cases. And with v2.0 release coming, this is a great time to have the discussion. You have two options to choose from depending on your specific requirements:

1) Key-level endorsement policy (v1.3 and higher)
- Key creates bound by chaincode endorsement policy and chaincode logic (e.g. you could set chaincode endorsement policy to any org, if you'd like any org to create keys).
- Key creator sets endorsement policy for future key updates - future key updates must be endorsed by specified org, or set or orgs
- Applicable to both public channel data and private data collections. Private data collection may be org-specific or a subset of channel members.
Documentation:
https://hyperledger-fabric.readthedocs.io/en/release-2.0/endorsement-policies.html#setting-key-level-endorsement-policies

2) Implicit org-specific private data collection (new in v2.0)
- Org-specific private key namespace (implicitly available for each org in the channel, no need to define) - only the specific org stores the data, other orgs receive hash only.
- All key creates and updates must be endorsed by the specific org
- The org can share their private key on a need-to-know basis by allowing other orgs to query chaincode on their peer (key-level ACL could itself be managed in the org's private key space)
- The org can also share their private data with another org by creating the same key/value in the other org's private key space, the 'receiving' org must endorse.
- A corresponding public channel key could also be written in the create transaction (or later), if the org would like to share their data with all channel members.
- On-chain hashes are used to verify that the shared private data matches the original private data.
Documentation:
https://hyperledger-fabric.readthedocs.io/en/release-2.0/private-data-arch.html#referencing-implicit-collections-from-chaincode
https://hyperledger-fabric.readthedocs.io/en/release-2.0/private-data/private-data.html#sharing-private-data

What is still not possible? Public channel keys segmented into org-specific namespaces that require the specific org to endorse creates/updates. That is, consider a more general collection concept, where on each collection you could specify not just endorsement policy (as in v2.0), but also whether the data is public or private. You can essentially get there using the techniques mentioned above, but if first class support is important to a large number of uses cases, direct support could be added in a future release. Let us know what you think!


Dave Enyeart

"Anoop Vijayan" ---01/28/2020 03:39:03 AM---Hello Fabric guys, I have a scenario where there are X orgs in a Hyperledger Fabric network.

From: "Anoop Vijayan" <anoop@...>
To: "fabric@..." <fabric@...>
Date: 01/28/2020 03:39 AM
Subject: [EXTERNAL] [Hyperledger Fabric] Storing/Retrieving key values in a collaborative way - endorsement policy
Sent by: fabric@...





Hello Fabric guys,
I have a scenario where there are X orgs in a Hyperledger Fabric network.
I would like to have each org can create/set/reset their respective values for key(s).
However, other orgs should be able to only read them but not modify them.
Also, as there is only possible to set one policy per Chaincode, I have to use `OutOf()` but this would end up to an ability to modify org1’s changes without involving org1.

E.g.

Lets say there are 10 orgs in a Hyperledger Fabric network.
Usual approach which we all know that works:

1. N (say N=2) Orgs should be able to set a unique key+value pair (can be implemented with Endorsement policy of type `OutOf(E[, E...])`)
   - Org1 creates the key+value pair and gets signed from any of OrgX (2..N)
2. Implicit: Any 2 Orgs is able to modify any key+value pair
3. Any one of those orgs is able to get the value from the key (IIRC)

My Requirements:

1. An org (containing multiple peers) should be able to set a unique key+value pair
2. Only that org can modify the key+value pair which it had set
3. Any one of orgs in Hyperledger Fabic network is able to read value from key

I have tried going through older mail archives (not all though) and didn’t find anything relevant.
The closest one which had relevance is, solved by private data collection which I am not sure if that solution applies here.

Hyperledger Fabric version can be: 1.4.x or 2.x

Please let me know your suggestions. Any answers like “Hyperledger is not suited for your purpose…” is also welcome :)

Thanks,
- Anoop






Storing/Retrieving key values in a collaborative way - endorsement policy

Anoop Vijayan <anoop@...>
 

Hello Fabric guys,
I have a scenario where there are X orgs in a Hyperledger Fabric network.
I would like to have each org can create/set/reset their respective values for key(s).
However, other orgs should be able to only read them but not modify them.
Also, as there is only possible to set one policy per Chaincode, I have to use `OutOf()` but this would end up to an ability to modify org1’s changes without involving org1.

E.g.

Lets say there are 10 orgs in a Hyperledger Fabric network.
Usual approach which we all know that works:

1. N (say N=2) Orgs should be able to set a unique key+value pair (can be implemented with Endorsement policy of type `OutOf(E[, E...])`)
- Org1 creates the key+value pair and gets signed from any of OrgX (2..N)
2. Implicit: Any 2 Orgs is able to modify any key+value pair
3. Any one of those orgs is able to get the value from the key (IIRC)

My Requirements:

1. An org (containing multiple peers) should be able to set a unique key+value pair
2. Only that org can modify the key+value pair which it had set
3. Any one of orgs in Hyperledger Fabic network is able to read value from key

I have tried going through older mail archives (not all though) and didn’t find anything relevant.
The closest one which had relevance is, solved by private data collection which I am not sure if that solution applies here.

Hyperledger Fabric version can be: 1.4.x or 2.x

Please let me know your suggestions. Any answers like “Hyperledger is not suited for your purpose…” is also welcome :)

Thanks,
- Anoop


Error: could not assemble transaction: ProposalResponsePayloads do not match

Siddharth Jain
 

we get this error when trying to invoke the chaincode on a network of 3 peers. However, we have verified if we invoke the chaincode individually on the peer nodes, all of them respond with Chaincode invoke successful. result: status:200. does anyone have any idea what could be wrong here?


signature set did not satisfy policy #fabric #fabric-questions

George
 

I've created a network configuration with 2 orgs, each one with 1 peer and CA.
I've successfully installed and instantiated my chaincode on both peers
But after invoking a transaction this error occurs on both peers:
~~~
peer0.org1.example.com|2020-01-27 21:32:00.531 UTC [committer.txvalidator] validateTx -> ERRO 047 VSCCValidateTx for transaction txId = d18ad9c8c5e6aada47b7c8677676b4d748bf2ae16256c093ae8f9dfb0bf17779 returned error: VSCC error: endorsement policy failure, err: signature set did not satisfy policy
peer0.org2.example.com|2020-01-27 21:32:00.531 UTC [committer.txvalidator] validateTx -> ERRO 069 VSCCValidateTx for transaction txId = d18ad9c8c5e6aada47b7c8677676b4d748bf2ae16256c093ae8f9dfb0bf17779 returned error: VSCC error: endorsement policy failure, err: signature set did not satisfy policy
~~~
that's how I installed the chaincode on both peers:
~~~
peer chaincode install -n mycc -v 1.0 -l node -p /opt/gopath/src/github.com/mychaincodes/
~~~
that's how I instantiated my contract
~~~
peer chaincode instantiate -o orderer.example.com:7050 --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/cacerts/ca.example.com-cert.pem -C $CHANNEL_NAME -n mycc -l node -v 1.0 -c '{"Args":[]}' -P "AND ('Org1MSP.member','Org2MSP.member')"
~~~
and that's how I invoked transaction
~~~
peer chaincode invoke -o orderer.example.com:7050 --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/ca/ca.example.com-cert.pem -C mychannel -n mycc --peerAddresses peer0.org1.example.com:7051 --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/ca/ca.org1.example.com-cert.pem -c '{"Args":["createMyAsset","001","Model X"]}'
~~~
 
Thanks in advance


revive^CC: static analysis of Go smart contracts

Ry Jones
 

Has anyone taken a look at revive^CC? it is:
Static analysis tool for Hyperledger Fabric smart contracts written in Go.
Ry
--
Ry Jones
Community Architect, Hyperledger


Re: CORE_PEER_ADDRESS vs CORE_PEER_LISTENADDRESS

Nye Liu <nye@...>
 

Listen is for the bind() call. Peer address is the externally visible address published during discovery. Please research bind() if that is unclear.


On Mon, Jan 27, 2020, 11:57 AM Siddharth Jain <siddjain@...> wrote:
One more question.

I am assuming the CORE_PEER_CHAINCODEADDRESS and CORE_PEER_CHAINCODELISTENADDRESS are analogous to CORE_PEER_ADDRESS and CORE_PEER_LISTENADDRESS respectively i.e.,

whereas the CORE_PEER_LISTENADDRESS is the address the peer will listen on for communication from other peers and orderers the CORE_PEER_CHAINCODELISTENADDRESS is the address the peer will listen on for communication from chaincode container. And the logic for other two env variables is same.

So now the question is can one set CORE_PEER_LISTENADDRESS = CORE_PEER_CHAINCODELISTENADDRESS and CORE_PEER_ADDRESS = CORE_PEER_CHAINCODEADDRESS or will that create a problem. If yes, why?


From: Yacov Manevich <YACOVM@...>
Sent: Monday, January 27, 2020 11:33 AM
To: Siddharth Jain <siddjain@...>
Cc: fabric@... <fabric@...>
Subject: Re: [Hyperledger Fabric] CORE_PEER_ADDRESS vs CORE_PEER_LISTENADDRESS
 
What if your friend is abroad and you're calling his office phone, and he configured his office phone to redirect the call to his cellphone?

The listen address is the address the peer binds its socket. It can be 0.0.0.0 for instance.

The peer address is an address that the peer publishes to other peers in its organization via gossip.

Imagine that you have a VM and inside the VM you have a docker container that runs the peer.
The address of the docker container is 172.20.0.2 so you'd want to bind to this address.

However, other peers cannot reach your docker container via this address, and they need to use the VM's IP which can be like 10.0.0.2

So you'd want to configure your peer address to be the VM's external address and have a port forwarding rule.



From:        "Siddharth Jain" <siddjain@...>
To:        "fabric@..." <fabric@...>
Date:        01/27/2020 09:27 PM
Subject:        [EXTERNAL] [Hyperledger Fabric] CORE_PEER_ADDRESS vs CORE_PEER_LISTENADDRESS
Sent by:        fabric@...




from the docs w.r.t. CORE_PEER_ADDRESS it is said that this represents the endpoint to other peers in the same organization.

and CORE_PEER_LISTENADDRESS is The Address at local network interface this Peer will listen on.

So why would anyone want to set these two differently? If my friend's actual phone number is 123-456-7890 (the CORE_PEER_LISTENADDRESS) and the number I have in my phone book is 234-567-8901 (the CORE_PEER_ADDRESS) then there is bound to be a problem when I try to call my friend. So why does Fabric open up this possibility?




Re: CORE_PEER_ADDRESS vs CORE_PEER_LISTENADDRESS

Siddharth Jain
 

One more question.

I am assuming the CORE_PEER_CHAINCODEADDRESS and CORE_PEER_CHAINCODELISTENADDRESS are analogous to CORE_PEER_ADDRESS and CORE_PEER_LISTENADDRESS respectively i.e.,

whereas the CORE_PEER_LISTENADDRESS is the address the peer will listen on for communication from other peers and orderers the CORE_PEER_CHAINCODELISTENADDRESS is the address the peer will listen on for communication from chaincode container. And the logic for other two env variables is same.

So now the question is can one set CORE_PEER_LISTENADDRESS = CORE_PEER_CHAINCODELISTENADDRESS and CORE_PEER_ADDRESS = CORE_PEER_CHAINCODEADDRESS or will that create a problem. If yes, why?


From: Yacov Manevich <YACOVM@...>
Sent: Monday, January 27, 2020 11:33 AM
To: Siddharth Jain <siddjain@...>
Cc: fabric@... <fabric@...>
Subject: Re: [Hyperledger Fabric] CORE_PEER_ADDRESS vs CORE_PEER_LISTENADDRESS
 
What if your friend is abroad and you're calling his office phone, and he configured his office phone to redirect the call to his cellphone?

The listen address is the address the peer binds its socket. It can be 0.0.0.0 for instance.

The peer address is an address that the peer publishes to other peers in its organization via gossip.

Imagine that you have a VM and inside the VM you have a docker container that runs the peer.
The address of the docker container is 172.20.0.2 so you'd want to bind to this address.

However, other peers cannot reach your docker container via this address, and they need to use the VM's IP which can be like 10.0.0.2

So you'd want to configure your peer address to be the VM's external address and have a port forwarding rule.



From:        "Siddharth Jain" <siddjain@...>
To:        "fabric@..." <fabric@...>
Date:        01/27/2020 09:27 PM
Subject:        [EXTERNAL] [Hyperledger Fabric] CORE_PEER_ADDRESS vs CORE_PEER_LISTENADDRESS
Sent by:        fabric@...




from the docs w.r.t. CORE_PEER_ADDRESS it is said that this represents the endpoint to other peers in the same organization.

and CORE_PEER_LISTENADDRESS is The Address at local network interface this Peer will listen on.

So why would anyone want to set these two differently? If my friend's actual phone number is 123-456-7890 (the CORE_PEER_LISTENADDRESS) and the number I have in my phone book is 234-567-8901 (the CORE_PEER_ADDRESS) then there is bound to be a problem when I try to call my friend. So why does Fabric open up this possibility?




Re: CORE_PEER_ADDRESS vs CORE_PEER_LISTENADDRESS

Yacov
 

What if your friend is abroad and you're calling his office phone, and he configured his office phone to redirect the call to his cellphone?

The listen address is the address the peer binds its socket. It can be 0.0.0.0 for instance.

The peer address is an address that the peer publishes to other peers in its organization via gossip.

Imagine that you have a VM and inside the VM you have a docker container that runs the peer.
The address of the docker container is 172.20.0.2 so you'd want to bind to this address.

However, other peers cannot reach your docker container via this address, and they need to use the VM's IP which can be like 10.0.0.2

So you'd want to configure your peer address to be the VM's external address and have a port forwarding rule.



From:        "Siddharth Jain" <siddjain@...>
To:        "fabric@..." <fabric@...>
Date:        01/27/2020 09:27 PM
Subject:        [EXTERNAL] [Hyperledger Fabric] CORE_PEER_ADDRESS vs CORE_PEER_LISTENADDRESS
Sent by:        fabric@...




from the docs w.r.t. CORE_PEER_ADDRESS it is said that this represents the endpoint to other peers in the same organization.

and CORE_PEER_LISTENADDRESS is The Address at local network interface this Peer will listen on.

So why would anyone want to set these two differently? If my friend's actual phone number is 123-456-7890 (the CORE_PEER_LISTENADDRESS) and the number I have in my phone book is 234-567-8901 (the CORE_PEER_ADDRESS) then there is bound to be a problem when I try to call my friend. So why does Fabric open up this possibility?




CORE_PEER_ADDRESS vs CORE_PEER_LISTENADDRESS

Siddharth Jain
 

from the docs w.r.t. CORE_PEER_ADDRESS it is said that this represents the endpoint to other peers in the same organization.

and CORE_PEER_LISTENADDRESS is The Address at local network interface this Peer will listen on.

So why would anyone want to set these two differently? If my friend's actual phone number is 123-456-7890 (the CORE_PEER_LISTENADDRESS) and the number I have in my phone book is 234-567-8901 (the CORE_PEER_ADDRESS) then there is bound to be a problem when I try to call my friend. So why does Fabric open up this possibility?


Re: #fabric #fabric-kubernetes #hyperledger-fabric #fabric #fabric-kubernetes #hyperledger-fabric

Nicholas Leonardi
 

You can start by having a look at this generic network.

Em segunda-feira, 27 de janeiro de 2020 10:34:01 BRT, <jquesada@...> escreveu:


Hi, can someone point me to more information on the resources we could need for a Hyperledger Fabric production deployment? The idea is to start with 3 organizations using on premise hardware. We are looking to use 9 peers total, and 5 orderer nodes. We have used docker containers on one machine so far for our development environment, but we are looking into using Helm with Kubernetes. We are expecting a low volume of transactions so far, maybe 5-10 tps to start, but we want to be ready to scale in the future. Any insight on the hardware we may need for a production environment will be really appreciated. Thank you.


#fabric #fabric-kubernetes #hyperledger-fabric #fabric #fabric-kubernetes #hyperledger-fabric

jquesada@...
 

Hi, can someone point me to more information on the resources we could need for a Hyperledger Fabric production deployment? The idea is to start with 3 organizations using on premise hardware. We are looking to use 9 peers total, and 5 orderer nodes. We have used docker containers on one machine so far for our development environment, but we are looking into using Helm with Kubernetes. We are expecting a low volume of transactions so far, maybe 5-10 tps to start, but we want to be ready to scale in the future. Any insight on the hardware we may need for a production environment will be really appreciated. Thank you.


Re: Is HLF a DLT or a blockchain?

Nye Liu <nye@...>
 


On Fri, Jan 24, 2020, 7:45 PM Trevor Lee Oakley <trevor@...> wrote:
 
I see conflicting references to this. The docs refer to a DLT and also a blockchain. In 4.5.1 of the docs it states it is a blockchain but in other parts it states it is a DLT. I have seen countless references to both. 
 
Is there any official statement from the Linux Foundation about this?
 
 
Trevor


Re: Is HLF a DLT or a blockchain?

greg m
 

‘Altar of Proof of Work’ seems to be the biggest sticking point for all the definitions and it echoes “bitcoin maximalism”. In my mind, Linux Foundation, have made so much investment into the blockchain phenomenon, that for the member companies there is no going back even if they end up not calling it DLT, but something else – a sign of changing DT environments.

 

My 2 cents and not meant to start a flame.

 

Thank you, greg

 

Sent from Mail for Windows 10

 

From: Brian Behlendorf
Sent: Saturday, January 25, 2020 4:22 AM
To: fabric@...
Subject: Re: [Hyperledger Fabric] Is HLF a DLT or a blockchain?

 

Let's not get too hung up on terminology in such a charged environment. Don't take this as an "official statement".

Yes, Fabric's underlying data structure involves a string of blocks, chained together, cryptographically signed and linked, and similar in spirit (if not exact approach) to Satoshi's use of the term in the Bitcoin white paper. Some would say you can't even whisper Satoshi's name let alone use the term "blockchain" without bowing down at the alter of Proof of Work, but I think most feel that ship has sailed.

Yes, it would also not in inaccurate to describe the resulting system you build with Fabric as a "distributed ledger", distributed amongst the peers on the system (more precisely, on the same channel), with referential integrity and transactional characteristics worthy of the accounting term "ledger".

Now it might be a good idea to make sure Fabric docs use the terms consistently, just for clarity's sake.  But one can use both terms around Fabric without conflict.

Brian

 

On 1/24/20 7:45 PM, Trevor Lee Oakley wrote:

 

I see conflicting references to this. The docs refer to a DLT and also a blockchain. In 4.5.1 of the docs it states it is a blockchain but in other parts it states it is a DLT. I have seen countless references to both. 

 

Is there any official statement from the Linux Foundation about this?

 

 

Trevor

 

-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf

 


Re: Is HLF a DLT or a blockchain?

Brian Behlendorf <bbehlendorf@...>
 

Let's not get too hung up on terminology in such a charged environment. Don't take this as an "official statement".

Yes, Fabric's underlying data structure involves a string of blocks, chained together, cryptographically signed and linked, and similar in spirit (if not exact approach) to Satoshi's use of the term in the Bitcoin white paper. Some would say you can't even whisper Satoshi's name let alone use the term "blockchain" without bowing down at the alter of Proof of Work, but I think most feel that ship has sailed.

Yes, it would also not in inaccurate to describe the resulting system you build with Fabric as a "distributed ledger", distributed amongst the peers on the system (more precisely, on the same channel), with referential integrity and transactional characteristics worthy of the accounting term "ledger".

Now it might be a good idea to make sure Fabric docs use the terms consistently, just for clarity's sake.  But one can use both terms around Fabric without conflict.

Brian


On 1/24/20 7:45 PM, Trevor Lee Oakley wrote:
 
I see conflicting references to this. The docs refer to a DLT and also a blockchain. In 4.5.1 of the docs it states it is a blockchain but in other parts it states it is a DLT. I have seen countless references to both. 
 
Is there any official statement from the Linux Foundation about this?
 
 
Trevor


-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf


Is HLF a DLT or a blockchain?

Trevor Lee Oakley <trevor@...>
 

 
I see conflicting references to this. The docs refer to a DLT and also a blockchain. In 4.5.1 of the docs it states it is a blockchain but in other parts it states it is a DLT. I have seen countless references to both. 
 
Is there any official statement from the Linux Foundation about this?
 
 
Trevor


Re: [i18n] Status report on translation of Fabric docs

Pam Andrejko
 

Yang,
Thanks for posting this update. The transition of Fabric from Gerrit to GitHub certainly facilitates this process making it easier to add the translations. There's alot of  good translation work that has already been done by the team so we are well positioned now to use that with the process you are proposing. 

I agree that creating the new Fabric-i18n repo with folders for each language is straightforward and should be easy to manage.

Thank you for putting together this proposal and we look forward to sharing more on one of the Contributors Calls.

~Pam




Re: what is the difference between system channel and application channel?

Yacov
 

the system channel is a channel that is available only on ordering service nodes, and it is simply used to synchronize application channel creation.

All transactions on the system channel are either configuration transactions, or transactions that create new channels.



From:        "Siddharth Jain" <siddjain@...>
To:        "fabric@..." <fabric@...>
Date:        01/24/2020 07:31 PM
Subject:        [EXTERNAL] [Hyperledger Fabric] what is the difference between system channel and application channel?
Sent by:        fabric@...




Hello

Is there any document explaining what is the difference between system channel and application channel in Fabric?

Sid




what is the difference between system channel and application channel?

Siddharth Jain
 

Hello

Is there any document explaining what is the difference between system channel and application channel in Fabric?

Sid

3921 - 3940 of 11526