-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add StateRoot
field to block header
#385
Comments
This is a very good idea, and necessary to guarantee trust on storage data. |
+1 |
Can someone give a practical example on how a light client would use this to solve the trust issue. I would be interested in implementing it |
This comment has been minimized.
This comment has been minimized.
Actually, you can find a usage scenario in https://arxiv.org/pdf/1806.03914.pdf. |
This comment has been minimized.
This comment has been minimized.
That would be awesome and would also help ensure consistent contract storage between versions / nodes. Atm we have to randomly resync, not knowing which node's view of contract storage is correct - for e.g. in neo-project/neo-node#191 |
This would be nice, but is probably too expensive to do. |
This comment has been minimized.
This comment has been minimized.
Ok, I did some heavy studies on Merkle Patricia/Trie used on Ethereum, and it's simple and efficient. That will solve 100% storage audit on Neo too... so, soon enough I'll start some experiments using data on https://github.com/neoresearch/neo-storage-audit. |
Guys, thanks to @rodoufu we are very advanced in building this MerklePatricia tree to handle storage hashes, which is very efficient and deterministic regarding insertion/deletion orders. In a first moment, we could add it in local database (together with an rpc call), so storage validation will start to work. In a second moment we put it in block header to strengthen the solution. |
We created a draft proposal on how Merkle Patricia trees could be useful to create safer storage and to provide a door out of UTXO model: neo-project/proposals#74 |
Waiting for the pull request review at #528 |
Nice feature!! Next year we finish that xD Happy 2019 to everyone :) |
Happy new year to everyone. Hope 2019 comes as sucesfull as 2018, full of development, great ideas and insights. Thanks to everyone that motivated and supported us. |
By putting the state on current block, we need to process the whole process during block proposal, hurting TPS, and I believe the path being followed now on Neo3 is to allow application be processed after. However, it could still be included in next block header, when previous state was already processed. I'll put an opinion on why this is not currently desirable either. |
Should we close this? |
If you fix the issue will be with another transaction, so you will use this state as a valid one, could you explain deeply when could be a problem? |
Erik gave a good example some time ago... about little endian format implemented as big on native contract. I'll give another one. suppose we wrongly implement some opcode, and allows doing unintentional stack access on program, or accessing forbidden context information, cheating on execution. This could leak funds from a contract,for example, similar to DAO hack. If we fix the issue, and re-run the chain on new version, previously states would now change, and hack wont happen. We have ways to protect user assets even without this.. for example, see Sólid States Nep. Another thing we should care is to not unfault tx,as this is not beneficial in any case... once faulted, faulted forever |
I think that if we are in this situation, or you find the error in this block and stop the chain at this moment, or never will be fixed, because this storage will be used in the next transactions, if you fix the opcode, al alter the behavior, you will get different future results. Any change on the vm should be done without backwards compatibility, controlled by the header. I prefer to save the states in the block header |
lets see if we can make cross chain perfect without this... I think we can. |
This idea was originally proposed by @muratyasin :
Link: #302 (comment)
The text was updated successfully, but these errors were encountered: