7

As explained in an Ethereum blog post, one consequence of consensus-by-bet is that:

a block can remain unconfirmed even when blocks after that block are completely finalized.

The given example makes sense given the regardless caveat:

if their transaction was confirmed and finalized in block 20101, and they know that regardless of the contents of block 20100 that transaction will have a certain result, then the result that they care about is finalized even though parts of the history before the result are not.

But what if someone's transaction in block 20101 does depend on block 20100?
Then how can 20101 be finalized if 20100 isn't?


For additional clarity, an example: account E gets 1 ETH from account D in block 20101. But what if some of the unconfirmed blocks at height 20100, have D's balance as 2 ETH and some have D's balance as 0 ETH. Is this possible? Or how does finalizing 20101 eliminate the 20100 candidate blocks that do not have sufficient balance for D?

If a reason is that validators will not bet to finalize 20101 unless they are sure that in previous blocks D has more than 0 ETH, what if they make a mistake, all bet blindly, follow each other and do finalize 20101? Everyone must now construct a history so that in 20100 account D has a balance of more than 0 ETH?

What are the gaps in the understanding above and how can a block be finalized if previous blocks are unconfirmed?

Post is related to a rapidly changing event.

2

Good question. Caspar makes explicit the idea of rewriting history.

First, blocks from a long period of time in history (like 3 months) are locked, finalized, not allowed to change and validators can't change their vote.

Second, within that time, validators under go iterative rounds of betting to converge to a chosen block. This betting happens once every block. So even if one block has the majority of votes at one time, the validators can switch to another. But, from one of the blog posts:

if validators change their bets too dramatically, for example by voting with a high probability on one block after voting with a very high probability on another, then they are severely punished

To answer another question:

But what if some of the unconfirmed blocks at height 20100, have D's balance as 2 ETH and some have D's balance as 0 ETH. Is this possible?

This situation is the equivalent of a fork in GHOST. In GHOST the network eventually converges to the heaviest chain (one with the most PoW behind it). In Caspar a rational validators would be incentivised to vote weakly at first and then revote over time to converge on the block with the most validators. Even though revoting has a penalty, the penalty is smaller than voting on the wrong block.

If a reason is that validators will not bet to finalize 20101 unless they are sure that in previous blocks D has more than 0 ETH, what if they make a mistake, all bet blindly, follow each other and do finalize 20101? It's up to miners to keep track of how much account balances, it wouldn't make sense to finalize 20101 without simultaneously of previously voting for a block which gives E enough ether for the transaction.

This post by Vlad may help: https://blog.ethereum.org/2015/08/01/introducing-casper-friendly-ghost/

Edit: I also found this document by Vitalik: http://vitalik.ca/files/finality.html

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.