Blockchains from a Distributed Computing Perspective [pdf]
cs.brown.eduYou may be interested in another paper[1] by Sompolinsky and Zohar describing block-trees rather than block-chains as a better structural approach.
The paper just describes a new method for selecting the main chain. Bitcoin uses the longest chain (with the most work) whereas this paper wants to use the block that is the child of the heaviest sub tree.
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.
What would trees give you for the usual ledger use case? Or would it be some other use?
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?
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
hashgraph?
Spectre is super interesting, same author, they started https://www.daglabs.com to implement this
https://medium.com/@avivzohar/the-spectre-protocol-7dbbebb70...
Ethereum has something along these lines in production; it's how they get higher throughput and 15-second block times.
Please tell me this is how the internet will work in space.
Ethereum actually uses a reduced version of this to accept portions of competing chains so as to be more efficient.
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?
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.
So Bob tampers with them all to record “everything’s fine” all the time. What now?
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.
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.
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.
If you have trust in a court, you don't need a trustless system, by definition.
Slippery slope: I can trust the court if I don't have to trust the data. I can't trust the court if I have to subjectively prove my arguments.
But you can't trust the data if the systems providing - creating - that data are tampered with, by definition!
You are very interested in defining things.
This is a case where imagination is needed.
Its easy to go through a couple containers and find/replace a few sensors. But it would be a lot of work for Bob to go through every single yogurt container and corrupt all the sensors.
Hmmm. But, how does a distributed blockchain help anyway?
The assumption is that there are only "a small number of faulty or corrupted sensors."
> 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...
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.
No amount of wordplay and denial will alter the fact that the DAO fork was a de-facto rollback.
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.
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.
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.
A rollback followed by a replay of desired transactions is still a rollback. This is how you can tell if an attempt to refute-by-redefinition is denial: first determine why it would be unfortunate if the predicate being refuted were true, and then ask if the redefinition actually fixes the problem.
Ethereum didn't have to replay transactions, because there was no rollback at all; it was an isolated change to the data in one contract. Ethereum doesn't work the way Bitcoin does.
Here we have another distinction without a relevant difference. A rollback is defined by its consequences, not the details of its process.
If you want to redefine "rollback" as "any fork that changes a blockchain's data" then ok, but that seems like a misleading definition to me. Normally a rollback means "all transactions are rolled back," which has entirely different consequences. In Ethereum's case, the data afterwards is different even from a rollback/reapply, since the theft is still in the transaction history.
In any case it seems fairly useless to debate what the meaning of "rollback" should be.
The meaning of rollback transcends and precedes blockchains, and it use here is in that sense.
If you're using the original definition from SQL, the DAO event still doesn't qualify. A SQL transaction rollback removes the transaction from the log, while the DAO theft transaction is still on chain. What Ethereum did was an additional update transaction.
The original post is clearly referring to the general engineering usage of rollback, as seen, for example, in source code control systems. As I pointed out before, 'rollback' is defined by its effects, not the mechanism by which it is performed, to which I might add that it is even less defined by mechanisms that are specific to a particular implementation.
If the existence of a record of the rolled-back transaction made a difference to whether an action is a rollback or not, then, by your argument, it would seem that the existence, or not, of a backup (or any other record) preserving the prior state of the system, would make the difference as to whether an SQL rollback was or was not actually a rollback. This, of course, is absurd, but its what you get from mistaking an implementation for a definition.
> In any case it seems fairly useless to debate what the meaning of "rollback" should be.
That was the point of my first post in this thread (with special reference to self-serving definitions.)
> Technology wise, git is as powerful as a blockchain at being an append-only log without the most important ingredient - proof-of work.
PoW is not required to have a blockchain. What you need is any consensus algorithm. For example you could use Proof of Stake.
The impression I got last time I studies about proof of stake is that it is still an open problem. You need to find ways to stop people from gaming the system by computing multiple parallel histories (which would devolve the system into proof-of-work) and the only ways to do this that I am aware of are at least partially reliant on agreeing on a central authority.
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".
Also, it's "deus absconditus" not "abscondidus" in 1.
2.2 : "...small number of of faulty..."
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.
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!
> 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".)
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.
> 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
AFAIK, you can generate a paper wallet with any blockchain system. You're keys are rendered as a QR code and/or series of words (there is a name for this protocol that hopefully someone else can remember!), and you can then print and store it.
Hardware wallets are also a thing for some systems, such as Bitcoin.
Yeah, exactly. BIP39 is a common protocol for mnemonic keys also supporting subkeys. Hardware wallets like the Ledger Nano S have support for Bitcoin, Litecoin, and Ethereum, and they let you sign transactions without ever exposing your private keys to a general purpose computer. And yeah, you can always just keep your private key in any way you want—it's just an n-bit number.
> 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!
This is why conventional money has a low amount of inflation. It incentives you to invest your money instead of putting it under a mattress.
That is indeed a more conventionally appealing way to encourage circulation—a gradual inflation in prices rather than sudden account confiscation!
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.
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?
>>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.
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.
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.
I'm new to blockchains so I'm sorry if this is stupid, maybe somebody can explain to me.
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.
> Why do everybody needs to keep everything?
Because every node in the network must be able to verify all transactions all the way from the genesis block. In order to ensure that this is possible, everyone who keeps the history must keep the full history.
With the MimbleWimble design [1] [2], inputs may be cancelled against the outputs they spend, with no loss of security. Essentially, the entire blockchain history may be collapsed to a single mega transaction, with all coinbases as inputs and the UTXO set as outputs.
[1] http://mimblewimble.cash/20160719-OriginalWhitePaper.txt
Look at R3 Corda, transactions only shared and stored between parties involved, not the rest of the network.
> 1-2Tb
What blockchain are you talking about? The Bitcoin blockchain is between 150 and 160 GB
Maybe he meant the UTXO set? Even that is off by a factor of 2 though.
Ya sorry, a bit of an exaggeration there. I was recalling the size of the hard disks that some folks routinely kept around just for storing crypto blockchains. That said, the actual numbers are already out of the rang for storage on the vast majority of commercially available mobile devices which basically relegates cryptos to enthusiasts. If we could fit a year worth of transactions in to on the order of 10 gigs, or at least provide a constant size estimate per unit time as a function of the number of transactions then we might be able to get adoption.
Well a full node doesn't need to keep the full block chain around, just the UTXO set. But you're not going to be able to handle the bandwidth of a full block chain on a mobile device anyway (~1TB/mo).
The blockchain grows at a constant linear rate, 1MB every 10 min or 144MB per day. Isn't that what you mean by "constant size estimate per unit time"?
The number you describe is a constant "change in size." What I describe is a constant maximum worst case "size." Yours would be velocity, mine would be position, function, derivative, etc.