I'm new to IBM Hyperledger Fabric.
While trying to go over documents, I see there are couple states
getState, putState, delState., etc
https://github.com/hyperledger/fabric/blob/master/core/chaincode/shim/chaincode.go
I'm wondering if ledger is 'immutable and chained', how can we 'delete' the state?
Given that it is a ledger which is chained by each transaction or transactions, wouldn't it be impossible to delete state or at least corrupt the chains of hash?
Thank you!
There is a state database that stores keys and their values. This is different from the sequence of blocks that make up the blockchain. A key and its associated value can be removed from the state database using the DelState function. However, this does not mean that there is an alteration of blocks on the blockchain. The removal of a key and value would be stored as a transaction on the blockchain just as the prior addition and any modifications were stored as transactions on the blockchain.
Concerning different hashes, it is possible that block hashes could diverge if there is non-deterministic chaincode. Creating chaincode that is non-deterministic should be avoided. Here is a documentation topic that discusses non-deterministic chaincode.
The history of a key can be retrieved after the key is deleted. There is a GetHistoryForKey() API that retrieves the history and part of its response is an IsDeleted flag that indicates if the key was deleted. It would be possible to create a key, delete the key, and then create the key again; the GetHistoryForKey() API would track such a case.
The state database stores the current state, so the key and its value are deleted from the state database. The GetHistoryForKey() API reviews the chain history and not the state database to find prior key values.
There is an example that illustrates use of the GetHistoryForKey() API. See the getHistoryForMarble function.
Related
After going through the Vault documentation of Corda, it is still not clear between how on-ledger & off-ledger data works in a Vault. A good explanation is appreciated.
On-ledger data is states that resulted from Corda transactions; the notary attests that the transaction inputs haven't been used before, and registers the transaction outputs as unconsumed states. The on-ledger data is cryptographically secured, any tampering with the node's tables will lead to a faulty ledger. All states are final and cannot be updated or modified. Every transaction has a set of required signers; so there's always an audit trail showing who approved the transaction and when.
Off-ledger data is data that is not tracked by your distributed ledger; meaning it's not finalized by the notary or cryptographically secured; but there's nothing stopping you from using the node's database schema to add your own tables, and you can even insert data into those tables from inside of your flows, but that data is not protected; it's like the data of any non-blockchain related app, anyone with database access can change the data and there's no audit trail showing that the data was tampered with, or by who.
Have a look at my article here, it shows an example of on-ledger and off-ledger data; the on-ledger data is the tokens (e.g. FungibleToken states) which result from using the Tokens SDK flows (issue and move tokens); while the custom table that I created for reporting purposes is the off-ledger data, even though I insert data into it from inside of my flows; that data is not the result of a transaction that is finalized by the notary and signed by a quorum of parties, so anyone can login to the database and modify it.
I found a paper which is talking about a way to store data off-chain using the blockchain. The data are sent to the blockchain with a transaction which subsequently routes it to an off-blockchain store, while retaining only a pointer to the data on the public ledger.
In particular the paper says:
Consider the following example: a user installs an application that uses our platform for preserving her privacy. As the user signs up for the first time, a new shared (user, service) identity is generated and sent, along with the associated permissions, to the blockchain in a Taccess transaction. Data collected on the phone (e.g., sensor data such as location) is encrypted using a shared encryption key and sent to the blockchain in a Tdata transaction, which subsequently routes it to an off-blockchain key-value store, while retaining only a pointer to the data on the public ledger (the pointer is the SHA-256 hash of the data).
What I cannot understand is how they do it! If all the nodes on the blockchain have to execute that very transaction, it means that they all have to save those information off-blockchain causing a duplication of contents. Did I get it wrong?
After a quick glance at the paper in question, it makes no mention of storage replication. The use case they are describing here is to use blockchain transactions as references to physical data that is stored somewhere. The data can be accessed by anyone who has the reference to it; i.e. access to that particular blockchain system, however the data is encrypted such that only parties with the encryption key can actually decipher it. This approach allows for quick validation of data integrity while maintaining privacy.
From the perspective of the blockchain node all they see is a transaction that will be added to their local ledger, they don't actually save the data themselves.
Let's say that I have several AWS Lambda functions that make up my API. One of the functions reads a specific value from a specific key on a single Redis node. The business logic goes as follows:
if the key exists:
serve the value of that key to the client
if the key does not exist:
get the most recent item from dynamoDB
insert that item as the value for that key, and set an expiration time
delete that item from dynamoDB, so that it only gets read into memory once
Serve the value of that key to the client
The idea is that every time a client makes a request, they get the value they need. If the key has expired, then lambda needs to first get the item from the database and put it back into Redis.
But what happens if 2 clients make an API call to lambda simultaneously? Will both lambda processes read that there is no key, and both will take an item from a database?
My goal is to implement a queue where a certain item lives in memory for only X amount of time, and as soon as that item expires, the next item should be pulled from the database, and when it is pulled, it should also be deleted so that it won't be pulled again.
I'm trying to see if there's a way to do this without having a separate EC2 process that's just keeping track of timing.
Is redis+lambda+dynamoDB a good setup for what I'm trying to accomplish, or are there better ways?
A Redis server will execute commands (or transactions, or scripts) atomically. But a sequence of operations involving separate services (e.g. Redis and DynamoDB) will not be atomic.
One approach is to make them atomic by adding some kind of lock around your business logic. This can be done with Redis, for example.
However, that's a costly and rather cumbersome solution, so if possible it's better to simply design your business logic to be resilient in the face of concurrent operations. To do that you have to look at the steps and imagine what can happen if multiple clients are running at the same time.
In your case, the flaw I can see is that two values can be read and deleted from DynamoDB, one writing over the other in Redis. That can be avoided by using Redis's SETNX (SET if Not eXists) command. Something like this:
GET the key from Redis
If the value exists:
Serve the value to the client
If the value does not exist:
Get the most recent item from DynamoDB
Insert that item into Redis with SETNX
If the key already exists, go back to step 1
Set an expiration time with EXPIRE
Delete that item from DynamoDB
Serve the value to the client
I am working on a use case. The requirement being I need to create an order. The order has some customer parameters. The order can be modified multiple times. Initially, I thought of implementing it in Ethereum. So, I thought of capturing the customer details from a UI and store it on the smart contract. However, the issue is once the contract is deployed I cannot change it since it is immutable. This drawback prevents me to use Ethereum. Deliberating on Corda, can I store the customer data as a single records and make modifications to it such that modifications are stored on the ledger which we can query. For instance, I want to store customer ID, Customer name, customer purchase order number, order type, and order status.
How would I do that in Corda data model?
Will that data be modifiable based on the rules coded on smart contract?
The data can be queried?
Yes.
In Corda, you store information using States. In your case, you might create a CustomerDataState class. You'd then create instances of this class on the ledger to represent your various customers.
This data can then be updated using transactions. But not all transactions are allowed. Which transactions are valid is based on the rules in the associated CustomerDataContract. The CustomerDataContract will be stateless, and simply exists to say how CustomerDataStates can evolve over time.
You can then easily query this data from your node's vault or transaction storage using an SQL-style syntax.
I am trying to understand about registry, like what is registry, why do we need to store Assets and Chaincodes in registry, where does registry gets stored.
Firt of all, the chaincode (or smart contracts) and the assets are two different things.
Chaincode: the code that you will execute/invoke. This code is the same in all the nodes, i.e. each node of the network has installed the same chaincode.
Assets: you digitize the assets using transactions that are governed by smart contracts.
On the other hand, how it works:
Ledger: the Ledger stores all the transactions. The ledger is comprised of a blockchain (‘chain’) to store the immutable, sequenced record in blocks. Each peer maintains a copy of the ledger.
State Database: maintains the current state. It represents the latest values for all keys ever included in the chain transaction log. Chaincode invocations execute transactions against the current state data.