search

hyperledger-archives / fabric

THIS IS A READ-ONLY historic repository. Current development is at https://gerrit.hyperledger.org/r/#/admin/projects/fabric . pull requests not accepted
https://gerrit.hyperledger.org/
Apache License 2.0
1.17k stars 1.01k forks source link

Ledger API needs to support GetTransaction by hash #491

Open srderson opened 8 years ago

srderson commented 8 years ago

The ledger API should provide the ability to retrieve transactions by hash so that greater security can be provided when accessing a previous transaction.

API example GetTransactionsByHash(hash) transaction

devrandom commented 8 years ago

It would be ideal if the parameter was id, and the transaction -> id transformation was defined by the chaincode. This would allow compatibility with existing transaction hashing schemes, such as the one in Bitcoin. I believe this would also enable schemes such as segregated-witness.

Cc @tamasblummer

srderson commented 8 years ago

That's an interesting idea. If the transformation code is chaincode specific, we may need to consider prepending the transaction ID with the chaincode ID to prevent collisions in networks with multiple independent chaincodes. Do you see any issues with this?

devrandom commented 8 years ago

That sounds reasonable.

One other possibility is to maintain the mapping chain txID -> OBC txID inside the chaincode. Is the plan for the chaincode to be stateless or stateful?

srderson commented 8 years ago

Yes, chaincodes have a state. There is a global state which is a key/value DB where the keys are strings and the values are arrays of bytes. Each chaincode has its own namespace in the DB so that they can set keys without having to be concerned about collisions and other chaincodes cannot modify their state. The hash of the global state is stored in each block.

Storing the mapping in the chaincode's state (which is available today) would be the easiest solution to implement if it works for your use case.

kletkeman commented 8 years ago

@srderson When you use the term chaincodes here, do you mean a global chaincode name space? As in all versions of chaincode at path X/version? Or perhaps path X so that each version deployed gets a separate name space? Or do you mean a specific chaincode instance? As in the name returned from deploy, which implies a path and a version?

Example: I instantiate a contract on a VIN and manage the automobile through its life cycle. I store certain bits of state in my namespace and would like to index an interactions by VIN. Can I do that easily under the current mechanism? I.e. can I easily do a VIN-based lookup at a generic end point to grab the instance of chaincode that is managing that asset? Or can I at least grab an instance of the right chaincode somehow to talk to all VINs' state?

If it is done by chaincode instance (returned name from deploy) then must I have an external mapping somewhere from VIN to chaincode path + name so that I can talk to that instance at any node globally?

I think that I am missing something here. Thx.

srderson commented 8 years ago

@kletkeman chaincode instances and versioning is not part of the MVP, so I didn't consider it in my previous comment, although a discussion of how state is handled in those cases will be needed. We could open a new issue, but first I want to lock down the use cases for those features.

Today, a deployed contract can access its state, and only its state. For example, if I deploy contract VIN1, I could implement a VIN loopkup. If I deploy contract VIN2, the only way to access the state of VIN1 is to call functions on VIN1 from VIN2. For example, VIN1 could expose a getCarByVIN(...) function that VIN2 could call.

kletkeman commented 8 years ago

@srderson In a large blockchain, would this not be a bit slow? It would have to search the entire chain to find the VIN's initial and subsequent transactions, would it not? I can see, though, that it might be quite performant with a separate API chaincode that defined a group of cars and that maintained a database of all cars based on crawling the blockchain itself (like a monitor, but available at each end point.)

On the other hand. perhaps just naming each deployed instance with the VIN would solve most of the access problem. Does that make sense?

Regarding instance not being part of MVP, I presume that you mean separate deploy and instantiate. We can still use the same chaincode path to create many instances of a car, for example. We just have to somehow manage the namespace of car chaincodes.