2

Am relatively new to the realm of Dapps and blockchain in general, and if you ask someone well-informed about the characteristics of blockchains, the word "immutable" will invariably appear in the response. Doing a simple search on google regarding immutability, the explanations given make sense, from a blockchain point of view. But when you dive deeper into coding, ethereum smart contracts, to be specific, the idea becomes vague. I have come from reading a two part series of how to implement CRUD operations in solidity, and as you can tell, Update and Delete part of CRUD introduces mutability. Towards the end of part 2, the author says:

1) The mapped struct (where the details still exist) is for the exclusive use of our contract. Sure, the data is still somewhere in the blockchain, but if this contract won’t retrieve it for you (it won’t), it’s approximately the same as gone.

2) There’s nothing we can do to prevent a determined adversary from finding data that once was but no longer is part of the current chain state. Overwriting data doesn’t undo immutable history.

Am concerned because my 4th year project entails developing a blockchain app for Ethereum to enable our country store public records like academic records, title deeds, driving licenses and log books.

One of the promises I gave in my proposal is this idea of immutability-: once the records enter the blockchain, there is no editing them, thus help curb forgery that we see all the time. If an update can be performed as simple as the tutorial linked above demonstrates, what will prevent anyone from updating their academic achievements for example (with the help of the system developer of course or some other way)?

So my reasoning at the moment is to provide setters and getters for these records, but explicitly omit functions to update/delete them. That way as a developer I help achieve immutability, not so much as a feature in blockchain.

But I feel am getting this wrong. How do I demonstrate immutability in this project?

Improve this question
0

2 Answers 2

Reset to default
2

Zach is exactly right. The delete and update operations described in my tutorial append new transactions that adjust the current state. Doing so does not (cannot) alter immutable history in any way.

You can have a value X stored in the contract, and set it to 1, then 2, then 3. You will have three immutable transactions. Even if you "delete" the records by the method described, there will still be a history of insertion (with the values), any updates that happened, and then the delete transaction that made it logically disappear. No data is lost and this is why I caution readers that delete doesn't conceal information from curious observers as they might mistakenly expect.

The blockchain is an immutable, append-only transaction set. It can give the appearance of a logical overwrite, if desired. There are lots of cases where it is desirable.

Hope it helps.

Improve this answer
5
  • Yea this helps a big deal...Which is what I was kinda hopping to be happening in the background coz when sb sells a car or land, I need to show two version of the log books, one of the previous owner, and one of the new owner, but most of the other info still remains the same like car plate number. So one question left is, how do I obtain this transaction history? coz I assume if I search a log book by its serial number (assuming its the unique key,), am likely to get the latest update...
    – Sean
    Jun 6, 2018 at 16:53
  • The event emitters are instrumental. Software clients can listen for new events that chronicle updates to the contract state (assuming the contract emits events by the suggested style). Acceptable transactions are governed by contracts and nothing is acceptable unless explicitly implemented. So, a contract can easily implement a rule such as "transfers must be signed by current owners". If this occurs, then update the state and emit an event.
    – Rob Hitchens
    Jun 6, 2018 at 17:11
  • In case it's puzzling, the current state is usually the most important, so it can be handy to implement read-only functions that return values. In my opinion it should also be possible to construct the state history by listening to events. For that to work, each state change should be accompanied by a corresponding event emitter in the actual contract.
    – Rob Hitchens
    Jun 6, 2018 at 17:14
  • Yea I will use event emitters, and as you note in your latter comment, it should be possible to construct the state history. Does solidity support this inherently or should I implement it on my own and how?
    – Sean
    Jun 6, 2018 at 17:19
  • Blockchain records all transactions inherently, and you can make it easier/better/more convenient by constructing event logs, in contract, that make it theoretically possible to reconstruct the state history using no other sources.
    – Rob Hitchens
    Jun 7, 2018 at 10:30
1

Immutability, with respect to blockchains (including Ethereum), refers to transactions themselves. Immutability does not apply to the state of the blockchain.

Any data within smart contract storage can be manipulated, given the necessary CRUD functions. Of course, to edit the state at all, a transaction must be broadcast and confirmed.

Improve this answer
9
  • So, given the intentions of my project, at what point do we separate transaction from state? Since am not dealing with cryptocurrencies, its simply adding a student's performance in the blockchain. In some cases though, transactions seem more apparent, like changing ownership of land and cars, the log books and title deeds will need to show that transaction, but academic records don't capture that
    – Sean
    Jun 6, 2018 at 16:26
  • Any action which modifies the state of your contracts storage (and therefore, the blockchain in general) will occur as a transaction. It doesn't matter whether it is a token transfer, the addition of a student's grade within a storage struct, or changing ownership on a vehicle. Any modification to any piece of data within storage must occur as a transaction.
    – Zack McGinnis
    Jun 6, 2018 at 16:30
  • Okay...Now that makes more sense...one thing is still unclear though..how do I demonstrate that once a student grade has been stored, its final.
    – Sean
    Jun 6, 2018 at 16:34
  • 1
    Yes it is up to you to maintain immutability of your contract's storage state (if that's what you want). Immutability of previous transactions is handled by the blockchain protocol. Nothing will prevent the hypothetical situation you outlined, but then again, that isn't the value proposition of blockchain immutability.
    – Zack McGinnis
    Jun 6, 2018 at 16:51
  • 1
    Your last point sort of anwers it all coz being a public system, I believe there will be auditors and other code reviewers who will go through the code to catch such loop holes...Thank you Zack..
    – Sean
    Jun 6, 2018 at 16:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.