Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feat/full blocks #33

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Feat/full blocks #33

wants to merge 3 commits into from

Conversation

BelfordZ
Copy link
Contributor

@BelfordZ BelfordZ commented Sep 25, 2019

prolly a bit outlandish of an idea, but I figured I'd write it down anyways.

@phyro
Copy link
Contributor

phyro commented Sep 25, 2019

@BelfordZ finally someone talking about the bloat, thank you! I agree the empty blocks are suboptimal (their emptiness could be temporary though).
Some things that come to mind around the idea:

  • How would you set/adjust the block difficulty in this case?
  • This would likely change the incentives of actors in the network quite a bit
  • The mental model of a chain being a global clock doesn't work anymore because the tick becomes too random - I like this model because it is simple and predictable

Another approach could be increasing the blocks times to 1 or 2 minutes (this is something I've mentioned on discord but nobody seemed to be interested in this at the time). I never really understood what the point of 15sec blocks was since you still need to wait the exact same time to have enough energy spent to 'secure' a block. Whether you wait for 120 confirmations with 15sec blocks or 30 confirmations with 1min blocks is equivalent in terms of how secure your transaction is. The 15sec block "speed" is an illusion. The real blockchain speed is the hash rate.

Other possible approaches to think about:

  • merging sequential empty blocks when epoch ends (need to make sure the security properties are preserved)
  • check if we can define a merge(b1, b2) function that merges two sequential blocks (it would be nice if it was a Monoid so it would output a block that is equivalent to a sequence of blocks b1->b2. This would mean that things the block holds would also likely need to be monoids. PoW is unfortunately not, so I'm not sure how you would join two proofs of work and combine their difficulty) which would allow us to reduce the blocks to a single one. Similarly how txs can be aggregated in the utxo model. Might not be possible, but it's fun to think about it

@zmitton
Copy link
Contributor

zmitton commented Sep 25, 2019

There is unfortunately a lot of theoretical science why block times have to stay above a certain amount or else miners will gain advantage by centralizing. This was the motivation behind GHOST protocol, but uncle rates become a problem if we do not target larger block times and smaller block-gas-limits.

Also, miners can add transactions for free so, they would easily fill a block with garbage in order to mine their block (there is no way to know they are paying themselves. There are some interesting ideas to change the way fees work (that burn part of the fee), so that it would not make sense for a miner to fill blocks with garbage. see EIP 1559 https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md and Vitaliks paper linked from here https://ethresear.ch/t/draft-position-paper-on-resource-pricing/2838 I havent read it yet.

With burned fees it seems you could put a lower limit on the transactions needed to produce a valid block, however it starts to accelerate a core criticism of a fee-only bitcoin market outlined in the red balloons paper. The issue is basically that mining nodes will not want to relay or accept blocks because they will be fighting over the fees from the same transactions.

@zmitton
Copy link
Contributor

zmitton commented Sep 25, 2019

red balloons: https://arxiv.org/pdf/1111.2626.pdf

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants