
Blockchains from a Distributed Computing Perspective [pdf] - rejectedalot
http://cs.brown.edu/courses/csci2952-a/papers/perspective.pdf
======
jasonzemos
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](https://eprint.iacr.org/2013/881.pdf)

~~~
matuszeg
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?

~~~
refset
[https://archain.org](https://archain.org) and their "Blockweave" construction
sounds similar. Here is a recent talk from Code Mesh on what they're building:
[https://m.youtube.com/watch?v=YO3zyQvL3Yg](https://m.youtube.com/watch?v=YO3zyQvL3Yg)

------
kccqzy
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 tampered with some), so she wires
> the sensors to conduct a Byzantine fault-tolerant consensus protocol, which
> uses several rounds of voting to ensure that temperature readings cannot be
> distorted by a small number of of faulty or corrupted sensors.

Now, since all frozen yogurt containers pass from Carol to Bob to Alice,
doesn't Bob at some point in time have access to _all_ the frozen yogurt
containers and their temperature sensors? Then Bob can easily corrupt _all_ of
them, rendering this scheme useless. He can, for example, replace all of the
sensors by malicious sensors that report wrong temperatures when they are in
Bob's truck.

Is there something I'm missing?

~~~
Donzo
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.

~~~
vertex-four
So Bob tampers with them all to record “everything’s fine” all the time. What
now?

~~~
Donzo
Finally! He can melt all the ice-cream and destroy his customer.

No, Bob's misconduct would potentially be provable in court based on the
trustless data ledgers in the blockchain.

Really, this example just shows one way how developers could use blockchain
technology to develop applications that utilize trustless data.

Imagine this same technology applied to the transfer of human organs, rather
than easily replaceable ice cream.

Challenge yourself to think of other scenarios in business where trustless
data might make a difference.

Maybe you'll have a valuable idea in this wide open space.

~~~
winslett
I’ve heard many scenarios like “transfer of human organs” as a scenario for
blockchain, but I’m skeptical that blockchain solves problems in the tangible
world all that easily. It is my perception that blockchain is great for
trustless information assets, but not great for trustless tangible assets.

Blockchain can’t stop a human from stealing an organ and replacing it with a
different organ. Even tracking shipping containers, which was high profile a
few years ago, only requires a human to make a mistake in loading a boat to
throw off the database.

In tangible-world-to-information-storage scenarios, the hard part is not the
information, but the guarantee that information matches the real world. In my
view, the claim that blockchain solves for a trustless tangible world is
naive.

~~~
Donzo
It's hard to imagine a solution to these problems because we are so far away
from highly functional examples of this tech in action in the "real" world.

That said, engineers live to solve problems in better, smarter ways.

I personally believe it is naive to bet against innovation in this sphere, but
we both shall see if we are so fortunate.

------
kang
> 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...](https://ethereum.stackexchange.com/questions/9535/how-does-a-hard-
fork-rollback-transactions)

~~~
yarrel
From [0] - "The transactions were not rolled back. The ETH amounts were just
transferred automatically at 1,920,000 ."

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.

~~~
mannykannot
No amount of wordplay and denial will alter the fact that the DAO fork was a
de-facto rollback.

~~~
DennisP
There's a fundamental difference: a rollback reverses _everybody 's_
transactions, the DAO fork left unrelated transactions alone.

Bitcoin had an actual five-hour rollback in its early days, when someone
figured out an exploit and awarded themselves over a billion coins.

~~~
codehalo
That’s incorrect. There was never a rollback in Bitcoin. You may be referring
to the leveldb bug that caused a fork, or Gavin and Satoshi’s discovery of the
billion coins bug, which was fixed by a software update, but none of these
involved a rollback.

~~~
DennisP
I was thinking of the billion coins bug. I did some searching and it appears
you're mostly correct; the errant transaction was removed, along with
subsequent transactions that descended from it, but unrelated transactions
were left in place.

[https://bitcointalk.org/index.php?topic=823.msg9557](https://bitcointalk.org/index.php?topic=823.msg9557)

------
0xdada
Since it's a draft I'll point out two typos. In 4.1 "if fills" should be "it
fills". In 4.3 "1000 to 10" should be "1000 to 100".

~~~
askee
Also, it's "deus absconditus" not "abscondidus" in 1.

------
hyperion2010
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 the heat death of
the universe. 2) To solve space complexity you need a time tax. I propose 1
year, because it is convenient. 3) Any tokens (or fractions of a token) [0]
that have not moved for more than a year (rolling) are returned to the common
pot. (sort of a non-usage tax)

This means that you can limit the space complexity of the whole chain as a
function of the number of transactions per 'tax interval.' This, or maybe a
similar approach could make the space complexity problem tractable for normal
users. (The blithe acceptance of a 1-2Tb (or is it 3 now?) space requirement
for the full blockchain by members of the community is so wildly out of touch
with reality it is laughable)

0\. There are a number of other 'units' that could be considered for tax-
interval retirement, such as the wallet. The nice thing about taxing fractions
of tokens is that the network can set the rate of the tax for investing over
the long term based on the cost of a single transaction fee. The day before a
fraction of a token would be dumped back into the pool the owner would just
have to send the token to another wallet they control and pay the relevant
transaction fee.

~~~
mbrock
It seems that in any real world blockchain, the space growth from actual
transactions will be much larger than the space wasted on inactive wallets.

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!

~~~
BraveNewCurency
> my calendar every year to retrieve all my keys from cold storage and do a
> meaningless transaction

No, you don't need to retrieve your keys each year. Before storage, create N
transactions moving all your coins to the next derived address. Sign all your
transactions at once. Then put it in the safe.

Store the transactions unencrypted on your computer. Send one each year. An
attacker can't do anything with them except send them early (and force you to
open your safe "sometime within the next year".)

~~~
mbrock
That's a good point, I didn't think about that. It does add some extra
complexity though—like, if I do want to make a real transaction, I have to re-
make the subsequent "keep-alive" transactions.

