Pages:
Author

Topic: BlockReduce: Scaling Blockchain to human commerce - page 3. (Read 1305 times)

legendary
Activity: 1456
Merit: 1176
Always remember the cause!
I think there are a few contradictions and shortcomings in the model you have proposed in the github document:

Let's begin with your following argument
Quote from: mechanikalk link=https://github.com/mechanikalk/bips/blob/master/bip-%3F%3F%3F%3F.mediawiki
Now that the transactions are built up into larger groups of data, say hundreds or thousands of transactions, nodes can first check if they need to transmit data to their peers by checking a hash. This enables a significant increase in bandwidth efficiency. Transmitting a hash would only take tens of bytes, but would allow the nodes to determine if they need to transmit several kilobytes of transaction data.
{hence} Most importantly, the amount of bandwidth used to create 1,000 TPS blocks is significantly smaller than that of current blockchains
It is based on a false understanding of how bitcoin networking layer works. Actually, it is a while that there is no unnecessary transmission of raw transaction data in bitcoin. If a node is already aware of a transaction, it will never ask for it to be re-transmitted and no peer would 'push' it again. Nodes just check txids included in the blocks by querying the Merkle path and if they ever find an unknown txid they can submit an inv message and ask for the raw data.

So, In your so-called Prime chain, we have no communication efficiency compared to bitcoin as long as nodes present on this chain have to validate the transactions they are committing to.

But nodes do have to validate the transactions, don't they? Otherwise how they could ever be able to commit to their sub-trees (regions/zones)? I think there is a big misunderstanding for you about blockchains, we don't commit to the hash of anything (a block, a transaction, ...) unless we have examined and validated it and we couldn't validate anything without having access to its raw data.  

It leads us to another serious issue: state segmentation. Officially you describe the proposal being a combination of state sharding with other techniques:
Quote from: mechanikalk link=https://github.com/mechanikalk/bips/blob/master/bip-%3F%3F%3F%3F.mediawiki
BlockReduce combines the ideas of incremental work and sharding of state with merge-mining to form a tightly coupled PoW-managed hierarchy of blockchains which satisfies all of the proposed scaling requirements.
Well, it is not completely right, I afraid.

For prime chain being legitimate for committing to region blocks (and so on) they not only need ultimate access to all transaction data of the whole network but they need to keep the whole state preserved and uptodate. There could be no sharding of state.

There is more to discuss but for now I suppose we have enough material to work on.

P.S.
Please note that I'm a fan and I'm not denouncing your proposal as a whole. I'm now thinking of hierarchical sharding as a promising field of investigation, thanks to your work, well done.   Smiley


member
Activity: 99
Merit: 91
Are there or are there not legal and tax implications with respect to explicitly selecting a geographic location from which your transaction originates?


The regions and zones will are not prescribed by BlockReduce, but rather incentivized.  Therefore, there will be influences of economic groups, geographic groups, and network topologies that play into "where" a region or zone is "located".  However, none of the regions or zones will be perfectly monolithic.  They will be overlapping and intertwined with little respect for geographic jurisdictional boundaries.  Furthermore, because there will always be at least one zone node outside of a given jurisdiction, there will be no ability for anyone to claim geographic location of a transaction.
hero member
Activity: 718
Merit: 545
OP! Congratulations on getting to this stage  Smiley There is a lot of work here. Wonderful stuff.

A main chain that acts as an anchor for all the other chains running off it. Merged Mining Meta-Chain or something. (I have a niggly feeling that somewhere deep in the bowels of bitcointalk something like this was mentioned / discussed - no idea though )

Diving straight in - Merge mining means that the hash power is spread over all the chains that miner chooses to mine. All the chosen chains benefit. This is good.

The only chain that everyone mines in your system is the PRIME chain. The lower levels are mined by less of the miners the lower you go.  

So although the hash power is kept high on PRIME - what gives the lower level chains the POW security required ?  

Adding them in as a root hash in the prime block (or whatever merkle path binds it) depends on lower level regions agreeing via POW what goes up to the higher levels. So - would that not be the attack vector ?

Please correct my understanding if this is incorrect!
newbie
Activity: 21
Merit: 2
Are there or are there not legal and tax implications with respect to explicitly selecting a geographic location from which your transaction originates?
member
Activity: 99
Merit: 91
I have developed this idea into a BIP which is available for people to view here. https://github.com/mechanikalk/bips/blob/master/bip-%3F%3F%3F%3F.mediawiki

Would really appreciate any additional feedback or discussion.

The TL;DR is that it is many Bitcoin blockchains that are merge mined at different difficulties with different sets of state.  This prevents sharding of PoW without causing sharding of state.  Would enable a Bitcoin like blockchain to scale to 10,000s of TPS without any centralization.

Thanks!
member
Activity: 99
Merit: 91
Quote
1. Since there are many region and zone, do you think each region/zone would have active nodes, miners and users? IMO with current Bitcoin state, i'm sure many region/zone would have empty block (no transaction).

The idea of BlockReduce is that the protocol would be able to adjust the block size and the number of region and zones such that the system operates near capacity say 80% fill.  This will ensure that transaction fees are non-zero, but also that there is economic incentive to balance transaction demand evenly amongst the zones.  This also will help to create transaction revenue to incentivize miners to continue to secure the chain when inflation block rewards move towards zero.

Quote
2. In 4.4, it mentions that region and zone have lower mining difficulty. If so, what stopping attacker from 51% hash rate attack to prevent transaction from confirmed or double-spend transaction? I've read 4.11, but IMO it's not good enough since :
Attacker might pretend as honest 40%/miner with minority hash rate
Human intervention is required (move to different zone)

The zone is only a mechanism in which incremental work ensures valid transaction processing without necessarily requiring other nodes validate all transactions.  This does not mean that other nodes don't need to verify the transactions.  If they have enough hash power they will be economically incentivized to validate a greater number of transactions from further removed zones to ensure they never lose work.  Additionally, even light nodes could validate transactions of adjacent zones without necessarily having to keep canonical state.  Large miners will keep the entirety of state as well as verify all transactions just because they do not want to lose hash working on bad blocks.  Even if a bad block is added in a zone, it will eventually be found and thrown out as it propagates up into regions and zones.  Ideally, it will be found out quickly in a zone, but if it is not, eventually all hash power in the network will work on it, which means that to get included persistently in PRIME it would be a 51% attack of all network hash.

Quote
3. In 4.5, it mentions "If multiple inputs are used in a transaction, they must reside within the same scope, meaning inputs must be taken from the same zone". Is it possible to treat it only as region/PRIME transaction scope?

Originally, I thought that this could be done.  However, I don't think it is a good idea because if a UTXO had PRIME scope, a user could initiate conflicting transactions in many zones.  This would take some time to be discovered and would cause significant waste of hash power.  If the PRIME transaction was sufficiently expensive to make this type of SPAM attack unreasonably expensive, it could be done.

Quote
4. Since both nodes with PRIME and region scope require more resources. IMO, centralization or control will happen since there's less group or nodes that needs to be attacked/hijacked.

There could potentially be some amount of centralization, but the fact that nodes can have a continuum of different resource requirements is decentralizing.  Additionally, the fact that overlap of verification and processing is not prescriptive, but rather variable based on a nodes economic incentives, it will create a diverse overlapping set of miners.

Quote
5. With region and zone scope, this will make bitcoin less pseudonymous since this would make transaction tracking analysis far easier

There will be some decrease in anonymity, however this is likely small and can be managed by the user if they desire better privacy.  If a user is in a set of 1/4 of bitcoin transactions rather than all bitcoin transactions there is less anonymity.  That user could choose to operate throughout all zones which would cost slightly more, but would provide the same amount of anonymity as bitcoin.

Quote
Your idea is interesting, but i seriously doubt Bitcoin community will accept idea since :
1. Increase bitcoin development complexity a lot

This is actually an incredibly simple change to the bitcoin code base.  It only requires a change in the block header, transaction header, peer management, and the chain database.
member
Activity: 99
Merit: 91
ETFBitcoin, thank you for taking a first look!  I look forward to hearing your further thoughts.

1.  The sub-groups are essentially children blockchain.  They have the same characteristics and issues in terms of transaction propagation as BTC.  However, because the groups are smaller and economically incentivized to form into low latency groups, the bandwidth constrained TPS will likely be much higher in BlockReduce.

2.  I don't think that the attack vector is ultimately any different than Bitcoin because the transactions are all ultimately propagated, validated, and recorded using PoW.  They just do so incrementally.

3. This is a good point.  If you look in the paper one of the references is to a study published by BitFury looking at the constraints to scaling.  The first constraint is bandwidth, the next is RAM, and the last is persistant data storage.  However, BlockReduce actually enables meaningfully different types of nodes which allows nodes to decide on the level of resource they want to commit based on the economic use case.  For example,  a "zone node" would only need to keep state of their zone as well as a trimmed region state and trimmed PRIME state.  This would mean that although the aggregate blockchain is running at tens of thousands of TPS, the "zone node" would be using similar amount of resources as a Bitcoin node uses today.  If a large miner wants to participate, they will dedicate more computation resources (RAM, storage, et cetera) because they will have an economic incentive to validate more transactions in more zones.  This will allow them to quickly discover if a fork exists in a zone or region preventing them from wasting hash power.  Also, it will provide them a arbitrage opportunity by increasing their ROI by directing hash into a zone when a fork takes place.
member
Activity: 99
Merit: 91
BlockReduce presents a new blockchain topology that offers 3+ orders of magnitude improvement in transaction throughput while avoiding the introduction of hierarchical power structures and centralization. This is accomplished through a modification to the block reward incentive to not only reward work, but to also reward optimization of network constraints and efficient propagation of transactions. This is accomplished by creating a Proof-of-Work (PoW) managed hierarchy of tightly-coupled, merge-mined blockchains.

Please take a look at the paper:https://arxiv.org/pdf/1811.00125.pdf

Here is a video presentation of BlockReduce presented at the McCombs Bitcoin Conference.

Also, here is a BIP draft to review and contribute to on Github.

Any comments or questions are greatly appreciated!
Pages:
Jump to: