Search code examples
hyperledger-fabrichyperledger-chaincode

Can different hyperledger fabric chaincodes view all key/value pairs in world state?


I got two Smart contract definitions currently commited on the same channel. Both are written in Go and are somewhat basic, only doing basic CRUD operations. However, I've noticed that key/value pairs written with one chaincode, are unavailable to the other.

So, with go-audit I created the following record:

enter image description here

But then, I tried to perform a get operation on key ping with chaincode go-asset, is not found with the following error (returned by the chaincode)

bad request: failed to invoke go-asset: Error: No valid responses from any peers. Errors: **someurl***, status=500, message=the asset ping does not exist.

This is the transaction that reads:

func (c *GoAssetContract) ReadGoAsset(ctx contractapi.TransactionContextInterface, goAssetID string) (*GoAsset, error) {

    exists, err := c.GoAssetExists(ctx, hlpAssetID)
    if err != nil {
        return nil, fmt.Errorf("could not read from world state. %s", err)
    } else if !exists {
        return nil, fmt.Errorf("the asset %s does not exist", goAssetID)
    }

    bytes, _ := ctx.GetStub().GetState(goAssetID)

    goAsset := new(GoAsset)

    err = json.Unmarshal(bytes, goAsset)

    if err != nil {
        return nil, fmt.Errorf("could not unmarshal world state data to type GoAsset")
    }

    return GoAsset, nil
}

and the GoAsset struct

// GoAsset stores a value
type GoAsset struct {
    Value string `json:"value"`
}

shouldn't world state be available to all chaincodes approved/committed on a channel?


Solution

  • chaincodes deployed to the same channel are namespaced, so that their keys remain specific to the chaincode that is using them. So what you see with 2 chaincodes deployed to the same channel is working as designed, they cannot see each others keys.

    However a chaincode can consist of multiple distinct contracts and in that case the contracts have access to each others keys because they are still in the same chaincode deployment.