Skip to content
Jasper den Ouden edited this page Jan 13, 2015 · 9 revisions

Hanging blocks(reddit thread) are a mechanism to get more cheap consensus storage and computation - more scalability -, sacrificing security via its achillies heel, data availability. It cannot determine whether the data is available, so it needs some mechanism to decide. How problematic that is depends on this decision method. For bitvote a clear way to decide could be delegative voting and clients automatically voting against a block of which they cannot find the data.

Note that the way hanging blocks work isnt really explained here, see that link. In short, a better name might have been 'auditable blocks', if the data of an invalid block is available, you can prove the block invalid. Pros/cons:

Pros:

  • On-hanging block activity doesnt cost gas.
  • Operations not available on ethereum can be implemented natively. (But they also need to be implemented in the Hanging-blocks-managing contract on Ethereum, so they can be audited, but that only needs to wrong if a block is invalid.)

Cons:

  • Data availability problem.
  • more complex; need separate implementation of communications for creating blocks.
  • Needs 'servicers' running software that create the blocks, and audit it.
  • Slower, need to wait on anti-nonavailability votes(/other) need to wait to see if blocks are not invalidated.

If the hanging blocks arent designed particularly to have contracts like Ethereum, DApps need to be specially made for them. So it could be advantageous to figure out how to make a hanging blocks system that works the exact same way as Ethereum.

One place it might be developed is a repo i have for some merkle tree stuff, however, more likely a Patricia tree -based approach is better.

Clone this wiki locally