You may be interested in another paper[1] by Sompolinsky and Zohar describing block-trees rather than block-chains as a better structural approach. 1: https://eprint.iacr.org/2013/881.pdf
Thank you so much for this. I work in this field and have been telling my coworkers that a tree or graph would make more sense. This is what i needed. Thank you Do you know if anyone is working to implement something like this?
Blockchains from a Distributed Computing Perspective [pdf]
21–30 of 73 posts
Re: Blockchains from a Distributed Computing Perspective [pdf]
#22> a ledger is just an indelible, append-only log of transactions that take place between various parties. Readers should decide either the above statement is true and ethereum is not a blockchain by that definition[0] or blockchain is just an abstract buzzword. Technology wise, git is as powerful as a blockchain at being an append-only log without the most important ingredient - proof-of work. 2. There is a whole sec…
Re: Blockchains from a Distributed Computing Perspective [pdf]
#23I appreciate the effort in writing this readable paper, but I do find the analogies in the first few sections to be quite strained. Here's an example: > Alice decides it is time to blockchain her supply chain. She rents some cloud storage to hold the ledger, and installs internet-enabled temperature sensors in each frozen yogurt container. She is concerned that sensors are not always reliable (and that Bob may have t…
All of the censors vote on if they have been tampered with. They will leave a record of their votes on the blockchain as Bob tampers with them in real time.
Re: Blockchains from a Distributed Computing Perspective [pdf]
#24I appreciate the effort in writing this readable paper, but I do find the analogies in the first few sections to be quite strained. Here's an example: > Alice decides it is time to blockchain her supply chain. She rents some cloud storage to hold the ledger, and installs internet-enabled temperature sensors in each frozen yogurt container. She is concerned that sensors are not always reliable (and that Bob may have t…
Re: Blockchains from a Distributed Computing Perspective [pdf]
#25You may be interested in another paper[1] by Sompolinsky and Zohar describing block-trees rather than block-chains as a better structural approach. 1: https://eprint.iacr.org/2013/881.pdf
Thank you so much for this. I work in this field and have been telling my coworkers that a tree or graph would make more sense. This is what i needed. Thank you Do you know if anyone is working to implement something like this?
Re: Blockchains from a Distributed Computing Perspective [pdf]
#26This seems an appropriate place to dump a thought I had while explaining the failures of all existing blockchains to a layman. 1) The problems with merkle trees & co. aren't the computational complexity, they are the space complexity. 1a) I can screw a current blockchain for all eternity by buying some token and then burning by keys. No one will ever know and they will have to keep track of those dead tokens until th…
And the notion of a secure financial system where if you don't move your money for a year your whole account is confiscated seems rather unappealing!
One thing I really want to be able to do with a blockchain system is to put my wallet in cold storage—like, in a safe. I don't want some arbitrary rule that I need to mark my calendar every year to retrieve all my keys from cold storage and do a meaningless transaction!
Re: Blockchains from a Distributed Computing Perspective [pdf]
#27You may be interested in another paper[1] by Sompolinsky and Zohar describing block-trees rather than block-chains as a better structural approach. 1: https://eprint.iacr.org/2013/881.pdf
The ledger would still be a chain of blocks.
For real tree like blockchains there are a few examples such as IOTA, raiblocks and byteball.
Re: Blockchains from a Distributed Computing Perspective [pdf]
#28This seems an appropriate place to dump a thought I had while explaining the failures of all existing blockchains to a layman. 1) The problems with merkle trees & co. aren't the computational complexity, they are the space complexity. 1a) I can screw a current blockchain for all eternity by buying some token and then burning by keys. No one will ever know and they will have to keep track of those dead tokens until th…
> 1-2Tb What blockchain are you talking about? The Bitcoin blockchain is between 150 and 160 GB
Re: Blockchains from a Distributed Computing Perspective [pdf]
#29> a ledger is just an indelible, append-only log of transactions that take place between various parties. Readers should decide either the above statement is true and ethereum is not a blockchain by that definition[0] or blockchain is just an abstract buzzword. Technology wise, git is as powerful as a blockchain at being an append-only log without the most important ingredient - proof-of work. 2. There is a whole sec…
So a transaction did take place "between various parties", nothing previous to block 1920000 was changed, and the transfer is there for all to see.
Re: Blockchains from a Distributed Computing Perspective [pdf]
#30Earlier quoted context omitted.
I don't think so, though maybe I am misunderstanding. In the pathological case, imagine that a node has made no transactions at all for a year. The owner will have to go to look up how much money they have in the ledger before they can complete a transaction and discover they have no money. The space complexity of maintaining accounts is extremely small compared to maintaining transactions. All transactions that were…
But that assumes that there is a trusted archival party that can verify account balances with authority. It may be technically possible to devise such a system, but as far as I understand, current decentralized blockchains require that you replay all previous transactions in order to learn the current state of the system.
Why do everybody needs to keep everything? The chain will be much smaller with just the id and the hash of the block. The payloads could be kept only by the interested parties and could be validated when needed with the chain.