Date   
Re: Modify the chaincode container for performance #fabric-kubernetes

Jean-Gaël Dominé
 
Edited

Hi,

In Kubernetes, the chaincode container management is currently difficult. You won't be able to easily access it because of the way the container is created.
You can access it using two options:

1) If you have access to the Docker daemon of your K8S cluster, then you can execute `docker ps -a` on it and you will see the chaincode containers. Then you can do a `docker exec` to connect to it.

2) You cannot have access to the daemon, in this case you can use Docker in Docker to add a Docker daemon inside the Peers pods so that it is the one to create the chaincode container on the fly.

In any case, IMHO you won't able to add files since the container is already up and running. Besides both solution are not satisfying as K8S does not have any control over the chaincode container as it is created outside of its scope.
Work is currently done around this issue because the way the chaincode is instantiated prevents the deployment on K8S from taking advantage of the orchestration features (pod monitoring, ...)
See https://jira.hyperledger.org/browse/FAB-13582

As for the image used for building the container, I'm no expert but I think the image might be created on the fly using some other images such as hyperledger/fabric-ccenv and hyperledger/fabric-baseos.
But this is definitely an assumption from my side

Hope it will help

JG

Documentation Workgroup: Agenda for Friday, 22 Mar

Anthony O'Dowd
 

Hi All,

We will hold the documentation workgroup on Friday, 22 Mar. We run the meeting twice during the day to make it easier for both Eastern and Western hemispheres.  See meeting times at the bottom of this note.  Please note that for the Western hemisphere, if you're joining from a European timezone, the call will be an hour earlier to accommodate our colleagues in the US who have moved to Daylight Savings. It 's another week before we resume normal time zones!

We'll start this week's call with an update on V2.0 development status with Pam and Joe. We've managed to finish the Developing application context topic, and thanks to numerous reviews, we can share this final to-be merged topic. Thanks again to folks for their great input!

Pam will share updates to the Policy topic -- which was well received last week. Likewise, Nik will share his updates on Tokens which were illuminating in that meeting -- and led to an expansive discussion on the application of tokens. Thanks to Chris and Jim for leading this dialogue.

Nik has also kindly offered to provide updates on the chaincode lifecycle topic he's been working.  And Joe, refreshed after his short vacation, will share the extensive material he's been developing and coordinating on the new orderer topic.  It promises to be a great set of sessions indeed.

If you'd like to contribute to these or another topic, please join the call -- there are now lots of people who are keen to help you contribute to the documentation!

The full agenda is available for you to read here : https://drive.google.com/open?id=1WikK60PPpW378biMwgDwh3m9zvHuurix
Feel free to post comments to the mailing list, so that we can include at the meeting. Or you can just come along, listen and discuss - you're always welcome!

Very best regards, Anthony.

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

Zoom should work in the browser.  I will open the call 5 minutes early so that folks can test it out. I'll also monitor the RocketChat at https://chat.hyperledger.org/channel/fabric-release so that if anyone has issues, ping me there!

More Zoom connection options at the bottom of this note.

The meeting times are as follows:

Meeting 77A: Friday 22 Mar
                   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 77B: Friday 22 Mar
              1000 Central Daylight Time
                   1100 Eastern Daylight Time
                   0800 Pacific Daylight Time
                   1200 Brasil Standard Time
                   1500 Greenwich Mean Time
                   1600 Central European Time
                   1700 Moscow Standard Time
 
More Zoom details
----------------

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/6223336701
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

Error getting endorser endorser client for channel #fabric #fabric-kubernetes #fabric-questions

Yousaf Zain <yousaf.zain000@...>
 

Hi everyone. I am deploying HL fabric network on kubernetes & facing the error below on joining peers with the channel.
For org1peer0 and org2peer0, joining is successful. But for org1peer1 and org2peer1 joining gives the error below.
  Error: error getting endorser client for channel: endorser client failed to connect to blockchain-org1peer1:30112: failed to create new connection: context deadline exceeded


Any suggestions or fixes about the issue above?

Modify the chaincode container for performance #fabric-kubernetes

Raj Bandhakavi
 

I have Hyperledger Fabric running on Kubernetes cluster. I know that whenever, a Chaincode is invoked a chaincode container is spun up.  Is there a way to access this chaincode container or the image that is building the chaincode container?

There would be a significant improvement in performance if we can add files to the chaincode container and let the Chaincode read these files to add data to the blockchain. 

Re: Chaincode Instantiate Payload #fabric #fabric-questions

Guillaume Cisco
 

Thank you very much Baohua, looks like exactly what I was looking for.

Do you know if this structure exists as a proto?

Re: Chaincode Instantiate Payload #fabric #fabric-questions

Baohua Yang
 

Hi guillaume

After dig out the code, it shows the data is for

type ChaincodeData struct {
// Name of the chaincode
Name string `protobuf:"bytes,1,opt,name=name"`

// Version of the chaincode
Version string `protobuf:"bytes,2,opt,name=version"`

// Escc for the chaincode instance
Escc string `protobuf:"bytes,3,opt,name=escc"`

// Vscc for the chaincode instance
Vscc string `protobuf:"bytes,4,opt,name=vscc"`

// Policy endorsement policy for the chaincode instance
Policy []byte `protobuf:"bytes,5,opt,name=policy,proto3"`

// Data data specific to the package
Data []byte `protobuf:"bytes,6,opt,name=data,proto3"`

// Id of the chaincode that's the unique fingerprint for the CC This is not
// currently used anywhere but serves as a good eyecatcher
Id []byte `protobuf:"bytes,7,opt,name=id,proto3"`

// InstantiationPolicy for the chaincode
InstantiationPolicy []byte `protobuf:"bytes,8,opt,name=instantiation_policy,proto3"`
}


FYI. Thanks!


On Thu, Mar 21, 2019 at 5:08 PM Guillaume Cisco <guillaumecisco@...> wrote:

Thanks Baohua for the precision.

But using the same way for decoding it does not work :/

We've created a bruteforce fonction for testing all the protos classes on this payload. And no one return something usable.

Python Code with fabric-sdk-py is:

import hfc.protos
import pkgutil
import importlib
from inspect import getmembers, isclass


payload = b'\n\nexample_cc\x12\x031.0\x1a\x04escc"\x04vscc*(\x12\x0c\x12\n\x08\x01\x12\x02\x08\x00\x12\x02\x08\x01\x1a\x0b\x12\t\n\x07Org1MSP\x1a\x0b\x12\t\n\x07Org2MSP2D\n ]\x92u\xa2a\x0e\xe5S\r\x0c\xbd\x14iN8N$Se\xa5\xe3It\xf3\x92\xa9\x19~\xc0D$\x18\x12 \x9eD\xb72\xc2\xed\xef\xe1\xf3\xa5\xe1\x96\xcf\xeb~\xb2\xf9\xda\xda{\x0f\x87\x97\x12i"\xd3\xd4\x08SL#: \xd9@\xbb\x12\xa1\xf3K\xb6&xr\x9a\xd8\x19\x1d\xdb@\x1f\x06\xa6C\xc1^&SS\x19&\x93\xcf\xec\xa1B,\x12\x0c\x12\n\x08\x01\x12\x02\x08\x00\x12\x02\x08\x01\x1a\r\x12\x0b\n\x07Org1MSP\x10\x01\x1a\r\x12\x0b\n\x07Org2MSP\x10\x01'


package = hfc.protos
packages = pkgutil.walk_packages(path=package.__path__,
prefix=package.__name__ + '.',
onerror=lambda x: None)
modules = [importlib.import_module(modname) for importer, modname, ispkg in packages
if 'pb2' in modname and 'grpc' not in modname]

proto_classes = {str(module.__name__): getmembers(module, isclass) for module in modules}

comp = {}

for k, v in proto_classes.items():
comp[k] = {}
for (n, cl) in v:
try:
p = cl()
p.ParseFromString(payload)
except:
pass
else:
comp[k][n] = p

for k, v in comp.items():
print('-' * 100)
print(k)
print('-' * 100)

for n, p in v.items():
print('-' * 50)
print(n)
print('-' * 50)
print(p)
print('\n\n')

You can run this function, you will see no protos interesting for decoding this payload.

We are in a dead end here, and we do not find in fabric the code where this payload is created.

 



--
Best wishes!

Baohua Yang

Re: Chaincode Instantiate Payload #fabric #fabric-questions

Guillaume Cisco
 

Thanks Baohua for the precision.

But using the same way for decoding it does not work :/

We've created a bruteforce fonction for testing all the protos classes on this payload. And no one return something usable.

Python Code with fabric-sdk-py is:

import hfc.protos
import pkgutil
import importlib
from inspect import getmembers, isclass


payload = b'\n\nexample_cc\x12\x031.0\x1a\x04escc"\x04vscc*(\x12\x0c\x12\n\x08\x01\x12\x02\x08\x00\x12\x02\x08\x01\x1a\x0b\x12\t\n\x07Org1MSP\x1a\x0b\x12\t\n\x07Org2MSP2D\n ]\x92u\xa2a\x0e\xe5S\r\x0c\xbd\x14iN8N$Se\xa5\xe3It\xf3\x92\xa9\x19~\xc0D$\x18\x12 \x9eD\xb72\xc2\xed\xef\xe1\xf3\xa5\xe1\x96\xcf\xeb~\xb2\xf9\xda\xda{\x0f\x87\x97\x12i"\xd3\xd4\x08SL#: \xd9@\xbb\x12\xa1\xf3K\xb6&xr\x9a\xd8\x19\x1d\xdb@\x1f\x06\xa6C\xc1^&SS\x19&\x93\xcf\xec\xa1B,\x12\x0c\x12\n\x08\x01\x12\x02\x08\x00\x12\x02\x08\x01\x1a\r\x12\x0b\n\x07Org1MSP\x10\x01\x1a\r\x12\x0b\n\x07Org2MSP\x10\x01'


package = hfc.protos
packages = pkgutil.walk_packages(path=package.__path__,
prefix=package.__name__ + '.',
onerror=lambda x: None)
modules = [importlib.import_module(modname) for importer, modname, ispkg in packages
if 'pb2' in modname and 'grpc' not in modname]

proto_classes = {str(module.__name__): getmembers(module, isclass) for module in modules}

comp = {}

for k, v in proto_classes.items():
comp[k] = {}
for (n, cl) in v:
try:
p = cl()
p.ParseFromString(payload)
except:
pass
else:
comp[k][n] = p

for k, v in comp.items():
print('-' * 100)
print(k)
print('-' * 100)

for n, p in v.items():
print('-' * 50)
print(n)
print('-' * 50)
print(p)
print('\n\n')

You can run this function, you will see no protos interesting for decoding this payload.

We are in a dead end here, and we do not find in fabric the code where this payload is created.

 

Re: Chaincode Instantiate Payload #fabric #fabric-questions

Baohua Yang
 

When doing instantiate, the response is with a similar structure, as it's the response from the lifecycle system chaincode.

I think you can decode it using the same way.

On Wed, Mar 20, 2019 at 11:45 PM Guillaume Cisco <guillaumecisco@...> wrote:

[Edited Message Follows]

Hi $$parthiban$$,


Thank your for answering. The payload I'm talking about already come from the blockdecoder.js.

When you make an instantiate request, you get a ProposalResponse.

Its proto is:

// A ProposalResponse is returned from an endorser to the proposal submitter.
// The idea is that this message contains the endorser's response to the
// request of a client to perform an action over a chaincode (or more
// generically on the ledger); the response might be success/error (conveyed in
// the Response field) together with a description of the action and a
// signature over it by that endorser. If a sufficient number of distinct
// endorsers agree on the same action and produce signature to that effect, a
// transaction can be generated and sent for ordering.
message ProposalResponse {

// Version indicates message protocol version
int32 version = 1;

// Timestamp is the time that the message
// was created as defined by the sender
google.protobuf.Timestamp timestamp = 2;

// A response message indicating whether the
// endorsement of the action was successful
Response response = 4;

// The payload of response. It is the bytes of ProposalResponsePayload
bytes payload = 5;

// The endorsement of the proposal, basically
// the endorser's signature over the payload
Endorsement endorsement = 6;
}

We can decode its payload thanks to the decodeProposalResponsePayload available in the blockdecoder.js

As I use fabric-sdk-py, we use decode_proposal_response_payload from block_decoder.py.

Both do the same thing.

decodeProposalResponsePayload is defined as:

function decodeProposalResponsePayload(proposal_response_payload_bytes) {
const proposal_response_payload = {};
const proto_proposal_response_payload = _responseProto.ProposalResponsePayload.decode(proposal_response_payload_bytes);
proposal_response_payload.proposal_hash = proto_proposal_response_payload.getProposalHash().toBuffer().toString('hex');
proposal_response_payload.extension = decodeChaincodeAction(proto_proposal_response_payload.getExtension());

return proposal_response_payload;
}



If you look carefully we have a Response inside the proto. Its proto is defined as:

// A response with a representation similar to an HTTP response that can
// be used within another message.
message Response {

// A status code that should follow the HTTP status codes.
int32 status = 1;

// A message associated with the response code.
string message = 2;

// A payload that can be used to include metadata with this response.
bytes payload = 3;
}

As you can see there is a payload, and it is this one I try to decode.

Currently it is equal to (python bytes string): b'\n\nexample_cc\x12\x031.0\x1a\x04escc"\x04vscc*(\x12\x0c\x12\n\x08\x01\x12\x02\x08\x00\x12\x02\x08\x01\x1a\x0b\x12\t\n\x07Org1MSP\x1a\x0b\x12\t\n\x07Org2MSP2D\n ]\x92u\xa2a\x0e\xe5S\r\x0c\xbd\x14iN8N$Se\xa5\xe3It\xf3\x92\xa9\x19~\xc0D$\x18\x12 \x9eD\xb72\xc2\xed\xef\xe1\xf3\xa5\xe1\x96\xcf\xeb~\xb2\xf9\xda\xda{\x0f\x87\x97\x12i"\xd3\xd4\x08SL#: \xd9@\xbb\x12\xa1\xf3K\xb6&xr\x9a\xd8\x19\x1d\xdb@\x1f\x06\xa6C\xc1^&SS\x19&\x93\xcf\xec\xa1B,\x12\x0c\x12\n\x08\x01\x12\x02\x08\x00\x12\x02\x08\x01\x1a\r\x12\x0b\n\x07Org1MSP\x10\x01\x1a\r\x12\x0b\n\x07Org2MSP\x10\x01'

 

We could use decode_response from BlockDecoder.js defined as:

function decodeResponse(proto_response) {
if (!proto_response) return null;
const response = {};
response.status = proto_response.getStatus();
response.message = proto_response.getMessage();
response.payload = proto_response.getPayload().toBuffer().toString();

return response;
}

 

As you can see it does nothing on the payload which is normal as this function can be used for chaincode invoke. And with a chaincode invoke, the smart contract can return whatever it wants.

But in the case of the instantiate, the smart contract does not play in the game. So fabric peer binary is returning a payload for this Response and I do not know how to decode it.

 



--
Best wishes!

Baohua Yang

Re: support for atomic commit of transactions across channels #fabric

Praveen
 

Thanks Brian for your comments.
 
Yes, the building blocks we have suggested can be a stepping stone to support atomic transactions across Fabric networks, as well as with other heterogeneous networks (e.g., Ethereum). One additional challenge to overcome to support atomic transactions across networks (Fabric or other) would be to address identity interoperability, i.e., how do we know that a client identity in one network corresponds to another identity in the second network? We have some thoughts around this, including leveraging Hyperledger Indy, but we have not included that in this proposal. That can be a natural next step.
 
With regards to Hyperledger Quilt, ILP and HTLA, we have included slides 19-24 in our deck in the Jira issue to call out the differences. HTLA provides a way to connect two clients who want to exchange cryptocurrencies with each other, through one or more intermediaries. The endorsement model in Fabric creates additional challenges to implement HTLA. Since the secret needs to be revealed to endorsers before commit (if you were to follow HTLA and the platform does not provide hash-lock and timeout capabilities), this creates a security risk. We will need some of the capabilities / building blocks we have suggested to even support HTLAs in Fabric. More details with an example is in the slide deck.
 
That said, after building the capabilities we have proposed, we can extend ILP to work with Fabric and also extend it to work beyond just cryptocurrency exchange.
 
Thanks and regards,
Praveen.
 

----- Original message -----
From: "Brian Behlendorf" <bbehlendorf@...>
Sent by: fabric@...
To: fabric@...
Cc:
Subject: Re: [Hyperledger Fabric] support for atomic commit of transactions across channels #fabric
Date: Thu, Mar 21, 2019 11:56 AM
 
Thanks for bringing this here for feedback.
 
One thing I noticed reading more closely is that this isn't just about transactions across channels in the same Fabric network, but even across different Fabric networks.  That's very cool!
 
Another part of Hyperledger, Hyperledger Quilt, has been working along the same lines, as an implementation of the Interledger Protocol written in Java.  It was originally written by Ripple and NTT Data and is now supported by Coil, and ILP is somewhat designed for a payments use case, so it right now just supports XRP and BTC; but we're working hard now to reboot the project and bring new contributors and thinking in.  If ILP can be made more general purpose than just payments of cryptocurrencies and apply to transactions of all sorts, perhaps it could also be looked at as the bridge between two Fabric networks?  I know that's a bigger lift but then we'd get interop with other ledger networks potentially more easily.  If not, it'd be great to understand what ILP doesn't yet provide to make this possible.
 
Brian
 
On 3/20/19 11:21 AM, Praveen wrote:
Hello everyone,
    We have a proposal and design for supporting atomic transactions across channels in Fabric. We have created an issue (https://jira.hyperledger.org/browse/FAB-13437) along with the details of the design. We would love to present this in a community call and get feedback from everyone. The design involves minimal changes to Fabric code and mostly to the ledger component, and we have in-house expertise to develop and contribute this to Fabric in 3 months. It also works seamlessly with upcoming features such as token transactions.
 
Thanks and regards,
Praveen.

 

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

Re: support for atomic commit of transactions across channels #fabric

Brian Behlendorf
 

Thanks for bringing this here for feedback.

One thing I noticed reading more closely is that this isn't just about transactions across channels in the same Fabric network, but even across different Fabric networks.  That's very cool!

Another part of Hyperledger, Hyperledger Quilt, has been working along the same lines, as an implementation of the Interledger Protocol written in Java.  It was originally written by Ripple and NTT Data and is now supported by Coil, and ILP is somewhat designed for a payments use case, so it right now just supports XRP and BTC; but we're working hard now to reboot the project and bring new contributors and thinking in.  If ILP can be made more general purpose than just payments of cryptocurrencies and apply to transactions of all sorts, perhaps it could also be looked at as the bridge between two Fabric networks?  I know that's a bigger lift but then we'd get interop with other ledger networks potentially more easily.  If not, it'd be great to understand what ILP doesn't yet provide to make this possible.

Brian

On 3/20/19 11:21 AM, Praveen wrote:
Hello everyone,
    We have a proposal and design for supporting atomic transactions across channels in Fabric. We have created an issue (https://jira.hyperledger.org/browse/FAB-13437) along with the details of the design. We would love to present this in a community call and get feedback from everyone. The design involves minimal changes to Fabric code and mostly to the ledger component, and we have in-house expertise to develop and contribute this to Fabric in 3 months. It also works seamlessly with upcoming features such as token transactions.
 
Thanks and regards,
Praveen.


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

Dynamic and automatic creation of PDCs

Isabell Kiral-Kornek
 

Hello, 
 
This is my first question here and I am hoping I'm following the right protocol. 
 
We are in the process of designing a fabric network and were wondering whether it is possible to create private data collections dynamically. 
 
My understanding at the moment is that any such configuration change has to go through the normal endorsement process, which means that dedicated people in the network would need to agree to this change. Is that correct? Or is this only true for changing the chaincode?
Is there a way to allow for this configuration change while all other updates still need to follow the normal procedure?
 
Many thanks in advance, 
Isabell
 

 
Isabell Kiral-Kornek, Ph.D.  60 City Road
Research Staff Member
 Southbank, Victoria 3006
Blockchain R&D, IBM Research Australia  Australia
Phone: (+61) 0422 335 797  
e-mail:
isabeki@...   

 

Re: Researching and Developing a Native Token for Fabric #fabric-questions #fabric

Michael Wang
 

Yes, there is a plan for this fabric native token. And it is in progress. Some works has been done. More effort will be needed. It is is at the initial stage right now.
If you can help, that will be great.


On Thu, Mar 21, 2019 at 5:42 AM <bryanedds@...> wrote:
Hello all.

I have been task with R&D for a Native Token in Fabric by my working group. We plan to modify Fabric and implement whatever modifications are needed to enable an Ethereum Coin-like solution. The first phase our of task involves developing an understanding of the Fabric source code architecture such that we can plot out what portions of the code base need to be modified and / or extended.

Toward this end, I am hoping to receive guidance on the following questions -

1) Does there exist centralized documentation on Fabric source code architecture? We see that there are bits and pieces of such documentation across various README.md files in the Fabric source tree, but we're hoping we could find something more like an overall explanation of how Fabric and its various modules are structured and coordinate. Anything that could help us understand the architecture of the Fabric source code would help us tremendously.

2) Are there existing public efforts to build a native coin solution like we are? We have done some research but found only efforts toward developing non-native coins. We would like to leverage other existing solutions if available to save us time and resources.

3) Do you have any general advice toward this end for our team?

Thank you very much for your time and consideration!



--
This is my life,but world of us~~

Using fabric-ca-client instead of cryptogen to launch a new fabric network #fabric-ca #fabric

Nye Liu <nye@...>
 

Here is the overall idea:

1) selfsign CA root keypair, bootstrap TLSCA and CA keys for a ca-server with openssl
2) create two ca-servers (TLSCA + CA)
3) enroll orderer tls and orderer MSP in a orderer org with fabric-ca-client
4) create orderer genesis block using orderer org
5) create orderer using tls, MSP, and gen block

For each peer creation request:

1) enroll peer tls and peer MSP in a peer org with fabric-ca-client
2) create peer BUT:

What is the best way to allow a peer to create a channel?

a) create a single (or more than one?) dedicated peer with an MSP in the orderer org that can create channels
b) create all peers in a peer org but add that peer org to orderer genesis block (requires relaunching orderer??) so they can all create channels
c) something else?

Note that the docs in the PR for FABC-814 describe creating all peer orgs and (anchor) peers before creating the orderer. For most BaaS launches, this might not be workable.

List of additional outstanding questions:

None of the bugs listed are outright blockers, they all have workarounds.

    Spin up separate TLSCA/CA server instances
        cacount vs cafiles (client specifies `--caname <caname>`) If using cacount, what is caname?
            How to configure each instance with just environment variables? Or have to create ca-config.yaml for each from template?
        Can they share postgres/sqlite instances?
        Generally, programs shouldn't write out their configuration. If they do, it should be the actual configuration
            https://jira.hyperledger.org/browse/FABC-763
    Bootstrapping pub keys requires using curl since fabric-ca-client cannot be told to disable cert checking
        https://jira.hyperledger.org/browse/FABC-460
    Enrollment supplied keys
        TLS certificates - ca enroll puts keys in MSP
            name of private key can only be derived by doing dirent() on keystore/
            CN is wrong
                https://jira.hyperledger.org/browse/FABC-437
        Public CA server key distribution
            The orderer public CA in the PoC is completely different than the CA server's public CA (used for peer and user enrollment).
                Is this expected?
                If we are generating orderer certs by enrolling on the CA, the orderer needs the ca-server's (orderer specific) pub CA cert
                Does anyone else need the orderer specific pub CA cert
        MSP enrollment - what is best practices for orderer/peer enrollment commands?
            Examples use cryptogen - is there a best practices guide for using fabric-ca-client instead?
            https://jira.hyperledger.org/browse/FABC-139
            https://jira.hyperledger.org/browse/FABC-814
    Orderer system genesis block generation
        Examples use a maximalist configtx.yaml file. What is the minimum contents for a simple, single orderer genesis block?
        Are peer public admin keys required to generate a genesis block?
        Can they be added later?
    Restart component every time a cert changes? A CRL is added?
    Other unresolved bugs
        https://jira.hyperledger.org/browse/FABC-60
        https://jira.hyperledger.org/browse/FABC-160
        https://jira.hyperledger.org/browse/FABC-490
        https://jira.hyperledger.org/browse/FABC-503
        https://jira.hyperledger.org/browse/FABC-545
        https://jira.hyperledger.org/browse/FABC-548 (regression)


Re: Researching and Developing a Native Token for Fabric #fabric-questions #fabric

Christopher Ferris
 

Please check out the fabric-chaincode-evm repo. We would love your feedback. 

Chris

On Mar 20, 2019, at 5:42 PM, bryanedds@... wrote:

Hello all.

I have been task with R&D for a Native Token in Fabric by my working group. We plan to modify Fabric and implement whatever modifications are needed to enable an Ethereum Coin-like solution. The first phase our of task involves developing an understanding of the Fabric source code architecture such that we can plot out what portions of the code base need to be modified and / or extended.

Toward this end, I am hoping to receive guidance on the following questions -

1) Does there exist centralized documentation on Fabric source code architecture? We see that there are bits and pieces of such documentation across various README.md files in the Fabric source tree, but we're hoping we could find something more like an overall explanation of how Fabric and its various modules are structured and coordinate. Anything that could help us understand the architecture of the Fabric source code would help us tremendously.

2) Are there existing public efforts to build a native coin solution like we are? We have done some research but found only efforts toward developing non-native coins. We would like to leverage other existing solutions if available to save us time and resources.

3) Do you have any general advice toward this end for our team?

Thank you very much for your time and consideration!

Researching and Developing a Native Token for Fabric #fabric-questions #fabric

bryanedds@...
 

Hello all.

I have been task with R&D for a Native Token in Fabric by my working group. We plan to modify Fabric and implement whatever modifications are needed to enable an Ethereum Coin-like solution. The first phase our of task involves developing an understanding of the Fabric source code architecture such that we can plot out what portions of the code base need to be modified and / or extended.

Toward this end, I am hoping to receive guidance on the following questions -

1) Does there exist centralized documentation on Fabric source code architecture? We see that there are bits and pieces of such documentation across various README.md files in the Fabric source tree, but we're hoping we could find something more like an overall explanation of how Fabric and its various modules are structured and coordinate. Anything that could help us understand the architecture of the Fabric source code would help us tremendously.

2) Are there existing public efforts to build a native coin solution like we are? We have done some research but found only efforts toward developing non-native coins. We would like to leverage other existing solutions if available to save us time and resources.

3) Do you have any general advice toward this end for our team?

Thank you very much for your time and consideration!

support for atomic commit of transactions across channels #fabric

Praveen
 

Hello everyone,
    We have a proposal and design for supporting atomic transactions across channels in Fabric. We have created an issue (https://jira.hyperledger.org/browse/FAB-13437) along with the details of the design. We would love to present this in a community call and get feedback from everyone. The design involves minimal changes to Fabric code and mostly to the ledger component, and we have in-house expertise to develop and contribute this to Fabric in 3 months. It also works seamlessly with upcoming features such as token transactions.
 
Thanks and regards,
Praveen.

Re: Chaincode Instantiate Payload #fabric #fabric-questions

Guillaume Cisco
 
Edited

Hi $$parthiban$$,


Thank your for answering. The payload I'm talking about already come from the blockdecoder.js.

When you make an instantiate request, you get a ProposalResponse.

Its proto is:

// A ProposalResponse is returned from an endorser to the proposal submitter.
// The idea is that this message contains the endorser's response to the
// request of a client to perform an action over a chaincode (or more
// generically on the ledger); the response might be success/error (conveyed in
// the Response field) together with a description of the action and a
// signature over it by that endorser. If a sufficient number of distinct
// endorsers agree on the same action and produce signature to that effect, a
// transaction can be generated and sent for ordering.
message ProposalResponse {

// Version indicates message protocol version
int32 version = 1;

// Timestamp is the time that the message
// was created as defined by the sender
google.protobuf.Timestamp timestamp = 2;

// A response message indicating whether the
// endorsement of the action was successful
Response response = 4;

// The payload of response. It is the bytes of ProposalResponsePayload
bytes payload = 5;

// The endorsement of the proposal, basically
// the endorser's signature over the payload
Endorsement endorsement = 6;
}

We can decode its payload thanks to the decodeProposalResponsePayload available in the blockdecoder.js

As I use fabric-sdk-py, we use decode_proposal_response_payload from block_decoder.py.

Both do the same thing.

decodeProposalResponsePayload is defined as:

function decodeProposalResponsePayload(proposal_response_payload_bytes) {
const proposal_response_payload = {};
const proto_proposal_response_payload = _responseProto.ProposalResponsePayload.decode(proposal_response_payload_bytes);
proposal_response_payload.proposal_hash = proto_proposal_response_payload.getProposalHash().toBuffer().toString('hex');
proposal_response_payload.extension = decodeChaincodeAction(proto_proposal_response_payload.getExtension());

return proposal_response_payload;
}



If you look carefully we have a Response inside the proto. Its proto is defined as:

// A response with a representation similar to an HTTP response that can
// be used within another message.
message Response {

// A status code that should follow the HTTP status codes.
int32 status = 1;

// A message associated with the response code.
string message = 2;

// A payload that can be used to include metadata with this response.
bytes payload = 3;
}

As you can see there is a payload, and it is this one I try to decode.

Currently it is equal to (python bytes string): b'\n\nexample_cc\x12\x031.0\x1a\x04escc"\x04vscc*(\x12\x0c\x12\n\x08\x01\x12\x02\x08\x00\x12\x02\x08\x01\x1a\x0b\x12\t\n\x07Org1MSP\x1a\x0b\x12\t\n\x07Org2MSP2D\n ]\x92u\xa2a\x0e\xe5S\r\x0c\xbd\x14iN8N$Se\xa5\xe3It\xf3\x92\xa9\x19~\xc0D$\x18\x12 \x9eD\xb72\xc2\xed\xef\xe1\xf3\xa5\xe1\x96\xcf\xeb~\xb2\xf9\xda\xda{\x0f\x87\x97\x12i"\xd3\xd4\x08SL#: \xd9@\xbb\x12\xa1\xf3K\xb6&xr\x9a\xd8\x19\x1d\xdb@\x1f\x06\xa6C\xc1^&SS\x19&\x93\xcf\xec\xa1B,\x12\x0c\x12\n\x08\x01\x12\x02\x08\x00\x12\x02\x08\x01\x1a\r\x12\x0b\n\x07Org1MSP\x10\x01\x1a\r\x12\x0b\n\x07Org2MSP\x10\x01'

 

We could use decode_response from BlockDecoder.js defined as:

function decodeResponse(proto_response) {
if (!proto_response) return null;
const response = {};
response.status = proto_response.getStatus();
response.message = proto_response.getMessage();
response.payload = proto_response.getPayload().toBuffer().toString();

return response;
}

 

As you can see it does nothing on the payload which is normal as this function can be used for chaincode invoke. And with a chaincode invoke, the smart contract can return whatever it wants.

But in the case of the instantiate, the smart contract does not play in the game. So fabric peer binary is returning a payload for this Response and I do not know how to decode it.

 

Re: Chaincode Instantiate Payload #fabric #fabric-questions

Parthiban Selvaraj
 

Hi,

Kindly use the block decoder JavaScript program (blockdecoder.js) to decode the payload response.
Block decoder comes with fabric package itself. Check the GitHub repo

Thanks and Regards
Parthiban Selvaraj


On Wed, 20 Mar, 2019, 4:29 PM Guillaume Cisco, <guillaumecisco@...> wrote:

Hi guys, we've correctly instantiated our chaincode and we get a return payload which looks like:

b'\n\nexample_cc\x12\x031.0\x1a\x04escc"\x04vscc*(\x12\x0c\x12\n\x08\x01\x12\x02\x08\x00\x12\x02\x08\x01\x1a\x0b\x12\t\n\x07Org1MSP\x1a\x0b\x12\t\n\x07Org2MSP2D\n ]\x92u\xa2a\x0e\xe5S\r\x0c\xbd\x14iN8N$Se\xa5\xe3It\xf3\x92\xa9\x19~\xc0D$\x18\x12 \x9eD\xb72\xc2\xed\xef\xe1\xf3\xa5\xe1\x96\xcf\xeb~\xb2\xf9\xda\xda{\x0f\x87\x97\x12i"\xd3\xd4\x08SL#: \xd9@\xbb\x12\xa1\xf3K\xb6&xr\x9a\xd8\x19\x1d\xdb@\x1f\x06\xa6C\xc1^&SS\x19&\x93\xcf\xec\xa1B,\x12\x0c\x12\n\x08\x01\x12\x02\x08\x00\x12\x02\x08\x01\x1a\r\x12\x0b\n\x07Org1MSP\x10\x01\x1a\r\x12\x0b\n\x07Org2MSP\x10\x01'

Do you know how to decode it?

It looks like the payload of a pb.Response

We've tried with some of the available protos without success :/

We tried looking at the code in fabric for understanding how it was created, without success :/

 

Could you help us, understanding how it is created under the hood and how to decode it?

 

Thank you,

Chaincode Instantiate Payload #fabric #fabric-questions

Guillaume Cisco
 

Hi guys, we've correctly instantiated our chaincode and we get a return payload which looks like:

b'\n\nexample_cc\x12\x031.0\x1a\x04escc"\x04vscc*(\x12\x0c\x12\n\x08\x01\x12\x02\x08\x00\x12\x02\x08\x01\x1a\x0b\x12\t\n\x07Org1MSP\x1a\x0b\x12\t\n\x07Org2MSP2D\n ]\x92u\xa2a\x0e\xe5S\r\x0c\xbd\x14iN8N$Se\xa5\xe3It\xf3\x92\xa9\x19~\xc0D$\x18\x12 \x9eD\xb72\xc2\xed\xef\xe1\xf3\xa5\xe1\x96\xcf\xeb~\xb2\xf9\xda\xda{\x0f\x87\x97\x12i"\xd3\xd4\x08SL#: \xd9@\xbb\x12\xa1\xf3K\xb6&xr\x9a\xd8\x19\x1d\xdb@\x1f\x06\xa6C\xc1^&SS\x19&\x93\xcf\xec\xa1B,\x12\x0c\x12\n\x08\x01\x12\x02\x08\x00\x12\x02\x08\x01\x1a\r\x12\x0b\n\x07Org1MSP\x10\x01\x1a\r\x12\x0b\n\x07Org2MSP\x10\x01'

Do you know how to decode it?

It looks like the payload of a pb.Response

We've tried with some of the available protos without success :/

We tried looking at the code in fabric for understanding how it was created, without success :/

 

Could you help us, understanding how it is created under the hood and how to decode it?

 

Thank you,

Error initializing the network channel from node sdk in hyperledger fabric

shahzad.adeel@...
 

Hi all,

KIndly resolve the issue described below:

Background: I have modified the first-network files (to a network with 2 Orgs and 1 peer in each of them) and installed my own chaincode on it. Additionally I have made a connection.yaml file to interact with the network.

 

Problem: But when I try to get the network channel & establish the gateway from nodeSDK, I encounter this error:

 

 

error: [Network]: _initializeInternalChannel: Unable to initialize channel. Attempted to contact 2 Peers. Last error was Error: 2 UNKNOWN: Stream removed

Failed to evaluate transaction: Error: Unable to initialize channel. Attempted to contact 2 Peers. Last error was Error: 2 UNKNOWN: Stream removed

 

Further details can be seen below,

https://stackoverflow.com/questions/55219497/error-initializing-the-network-channel-from-node-sdk-in-hyperledger-fabric

 

Thanks,

Adeel Shahzad