Live data from Hacker News

Blockchains from a Distributed Computing Perspective [pdf]

cs.brown.edu

11–20 of 73 posts

Re: Blockchains from a Distributed Computing Perspective [pdf]

#11

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?

Re: Blockchains from a Distributed Computing Perspective [pdf]

#12

This 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…

>>No one will ever know and they will have to keep track of those dead tokens until the heat death of the universe Why does it matter? If the address never moves the tokens... it's not really a lot of computation required.

The point is that it requires space. We have to keep a record of the pointer.

Re: Blockchains from a Distributed Computing Perspective [pdf]

#13
post #7

This 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…

Demurrage[1] money acts in a similar manner to encourage usage of a currency. Freicoin[2] implemented a demurrage fee mechanism of 5% per year, which would have the effect of eventually clearing out burned "dead" tokens, although the transaction history would still need to be stored until the end of time if you ran a full node that long. [1] https://en.wikipedia.org/wiki/Demurrage_(currency) [2] http://freico.in/abou…

If you have a complete account of the location of every fractional token at time t and a time t + d then we should be able to get rid of all logs for transactions with time < t + d. Is there something that prevents freicoin from doing this?

Re: Blockchains from a Distributed Computing Perspective [pdf]

#14

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

What would trees give you for the usual ledger use case? Or would it be some other use?

Re: Blockchains from a Distributed Computing Perspective [pdf]

#15

Earlier quoted context omitted.

>>No one will ever know and they will have to keep track of those dead tokens until the heat death of the universe Why does it matter? If the address never moves the tokens... it's not really a lot of computation required.

The point is that it requires space. We have to keep a record of the pointer.

But also any transactions pertaining to a "dead" account has to be verified whenever a new node boots the chain from scratch, in all future. The aggregated cost in power will, in time, surpass the initial cost of buying those coins.

Re: Blockchains from a Distributed Computing Perspective [pdf]

#16

Earlier quoted context omitted.

The point is that it requires space. We have to keep a record of the pointer.

But also any transactions pertaining to a "dead" account has to be verified whenever a new node boots the chain from scratch, in all future. The aggregated cost in power will, in time, surpass the initial cost of buying those coins.

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 associated with that account have been wiped from the public ledger. An archival ledger may keep a record of retired transactions, but the archival is not required to settle all accounts.

Re: Blockchains from a Distributed Computing Perspective [pdf]

#17
> 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 section on private blockchains

Can you write one program using a private blockchain(for eg use ibm's hyperledger) that can't be written using git? Private blockchains, premined coins, colored tokens, assets etc all of them.

3. Regarding smart contracts, can you show me one use of turing completeness in a blockchain? If yes, ethereum is not turing complete practically cause gas.

4. How does one determine the gas price of an opcode in a network? How does ethereum do it? (i think only people understanding need of proof-of-work will understand this)

5. W.r.t the layers of OSI model, the need for smart contract is trivial. Show me one smart contract you can do 'in' a blockchain and I will tell you how to do it 'on' bitcoin.

[0]https://ethereum.stackexchange.com/questions/9535/how-does-a...

Re: Blockchains from a Distributed Computing Perspective [pdf]

#18

Earlier quoted context omitted.

But also any transactions pertaining to a "dead" account has to be verified whenever a new node boots the chain from scratch, in all future. The aggregated cost in power will, in time, surpass the initial cost of buying those coins.

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.

Re: Blockchains from a Distributed Computing Perspective [pdf]

#19

This 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]

#20
post #3

I 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…

The assumption is that there are only "a small number of faulty or corrupted sensors."
Post reply on HN