A more thought out version of this is BlockReduce.
https://bitcointalksearch.org/topic/blockreduce-scaling-blockchain-to-human-commerce-5060909
Overview paper:
https://arxiv.org/pdf/1811.00125.pdf
Topic: Blockrope - Internal Parrallel Intertwined Blockchains - scaleability related (Read 854 times)
December 09, 2019, 07:14:24 PM
December 09, 2019, 05:15:58 PM
For future historians, the concept of "blockrope" was fully developed and now exists. If you want to see it live: explorer.chainweb.com
Called Chainweb (Kadena discovered and developed the idea before finding this thread) the original blockrope concept was extended by leveraging graph theory to unbound the max-chain count a single network can have.
https://github.com/kadena-io/chainweb-node
https://www.kadena.io/whitepapers
Called Chainweb (Kadena discovered and developed the idea before finding this thread) the original blockrope concept was extended by leveraging graph theory to unbound the max-chain count a single network can have.
https://github.com/kadena-io/chainweb-node
https://www.kadena.io/whitepapers
May 31, 2015, 08:37:11 PM
Ah ha! Someone else also proposed this:
http://www.belmarca.com/2014/02/26/mt-gox-failure-and-opportunity/
ctrl-f for blockrope. ah screw it, here's the text
http://www.belmarca.com/2014/02/26/mt-gox-failure-and-opportunity/
ctrl-f for blockrope. ah screw it, here's the text
Quote
BLOCKROPE
The blockchain is perhaps the single most important technological contribution Bitcoin brought forth. Whenever I explain cryptocurrencies to a newcomer, I do my best so they leave knowing what a blockchain is. But the current state of the art isn’t without its potential problems. Transaction security aside, the Bitcoin blockchain is growing linearly and currently weighs just over 14 GB. This is not so concerning if you’re only interested in Bitcoin, but there exist multiple other cryptocurrencies that each have their own blockchain, which means you could end up storing very large amounts of transaction data on your computer. This problem is partly solved by thin clients like Electrum.
What I propose is not much of a scalability fix rather than a security enhancement that could be implemented by any blockchain dependent cryptocurrency. The concept of a Blockrope is very simple and demonstrated in the following image:
Image made with svg-edit http://code.google.com/p/svg-edit/
Blockchain to Blockrope
Much has been written about potential attacks against a blockchain-based network. Of these, the most probable seems to be the so-called 51% attack. By linking blockchains together to create a blockrope, one could decrease5 the odds of 51% attacks ever occurring on any currency.
The linking could be implemented in different ways, but would function much like the current hashPrevBlock. Say Blockchain B has been around for longer than Blockchain A. The latter could, once every n blocks, incorporate the hash of the most recent B block into its block header. “Roping” them this way could be called commensalist roping, since only one of the blockchains benefits. Mutualistic roping would see each blockchain referencing the other. In this case, every n A block incorporates a hash of the previous B block into its header, and every p B block incorporates the previous A block’s hash into its header. The rope would then be complete.
Benefits of such junctions between blockchains regarding 51% attacks are evident. An attacker would need not only re-generate blocks from the blockchain he is interested in, but also from the other, joined blockchain.
TRANSACTION SEGREGATION
Of course, the blockrope could be an ad-hoc addition to current protocols. What would be more interesting is to use it for experimentation. One might try what could be called time-zone transaction segregation mechanism into the protocols. What I envision is a network with a single blockrope made up of blockchains, one for each time-zone. That way, each “local” blockchain would mostly contain transactions that originate and stay in the same time-zone. This means that for example, at times of high activity in the East-coast, the West-coast blockchain wouldn’t grow as much in size6, and vice versa. A consequence of this could mean a leaner and more easily maintainable global cryptocurrency architecture.
A case could be made to establish something else, like an economic zone transaction segregation mechanism. This would work much the same way as the time-zone version described before, except that each major economic centre (NYC, Mexico, Tokyo, etc.) would be assigned a blockchain. Locals could have control over intra-chain transaction fees as well as chain-to-chain fees. The latter would apply to transactions originating in an economic zone and ending in another. This could, in my opinion, add depth to a cryptocurrency network.
The blockchain is perhaps the single most important technological contribution Bitcoin brought forth. Whenever I explain cryptocurrencies to a newcomer, I do my best so they leave knowing what a blockchain is. But the current state of the art isn’t without its potential problems. Transaction security aside, the Bitcoin blockchain is growing linearly and currently weighs just over 14 GB. This is not so concerning if you’re only interested in Bitcoin, but there exist multiple other cryptocurrencies that each have their own blockchain, which means you could end up storing very large amounts of transaction data on your computer. This problem is partly solved by thin clients like Electrum.
What I propose is not much of a scalability fix rather than a security enhancement that could be implemented by any blockchain dependent cryptocurrency. The concept of a Blockrope is very simple and demonstrated in the following image:
Image made with svg-edit http://code.google.com/p/svg-edit/
Blockchain to Blockrope
Much has been written about potential attacks against a blockchain-based network. Of these, the most probable seems to be the so-called 51% attack. By linking blockchains together to create a blockrope, one could decrease5 the odds of 51% attacks ever occurring on any currency.
The linking could be implemented in different ways, but would function much like the current hashPrevBlock. Say Blockchain B has been around for longer than Blockchain A. The latter could, once every n blocks, incorporate the hash of the most recent B block into its block header. “Roping” them this way could be called commensalist roping, since only one of the blockchains benefits. Mutualistic roping would see each blockchain referencing the other. In this case, every n A block incorporates a hash of the previous B block into its header, and every p B block incorporates the previous A block’s hash into its header. The rope would then be complete.
Benefits of such junctions between blockchains regarding 51% attacks are evident. An attacker would need not only re-generate blocks from the blockchain he is interested in, but also from the other, joined blockchain.
TRANSACTION SEGREGATION
Of course, the blockrope could be an ad-hoc addition to current protocols. What would be more interesting is to use it for experimentation. One might try what could be called time-zone transaction segregation mechanism into the protocols. What I envision is a network with a single blockrope made up of blockchains, one for each time-zone. That way, each “local” blockchain would mostly contain transactions that originate and stay in the same time-zone. This means that for example, at times of high activity in the East-coast, the West-coast blockchain wouldn’t grow as much in size6, and vice versa. A consequence of this could mean a leaner and more easily maintainable global cryptocurrency architecture.
A case could be made to establish something else, like an economic zone transaction segregation mechanism. This would work much the same way as the time-zone version described before, except that each major economic centre (NYC, Mexico, Tokyo, etc.) would be assigned a blockchain. Locals could have control over intra-chain transaction fees as well as chain-to-chain fees. The latter would apply to transactions originating in an economic zone and ending in another. This could, in my opinion, add depth to a cryptocurrency network.
May 14, 2015, 06:47:01 AM
So, I tried my due diligence to see if this had already been hashed out before, and there was an attempt maybe:
https://bitcointalksearch.org/topic/m.2304432
and maybe here:
https://bitcointalksearch.org/topic/m.3093912
So here are my assumptions. They may be naive and uninformed (I don't claim to be versed in this stuff), but I learn by doing, not by studying - so if you tell me why it couldn't work, then I understand bitcoin better.
The blocksize bottleneck has to do with too many transactions not making it into a block, they sit around in the mempool, things get backed up.
Relatively simple solution - increase blocksize.
Potential pitfalls, as I understand them, are increased resource requirements. The moot pitfall is storage space. The only relevant resource pitfall, methinks, is bandwidth.
After reading this, however, blockrope may be useless:
http://bitcoin.stackexchange.com/questions/36085/what-are-the-arguments-for-and-against-the-increase-of-the-block-size-limit
because the bandwidth issue has to do with concerns over supposed data caps - i.e., the concern is about how much data you have to push through the pipes, not how effectively you have to push the data through the pipes.
But here is the idea, and I think its simple. No idea re: implementation.
Introduce additional databases - additional ledgers. So, there's a bunch of transactions in the mempool, the miner is trying to solve a block for transaction collection #1, and trying to solve a block for collection #2, etc. And (as I think one of the posts above alluded to), this could be done in a merged mining fashion, wherein each nonce is tried against each block collection.
So say the miner is currently working on a block.. this is the primary block, and the miner has elected to only include transactions with a certain transaction fee. So this is his primary block. While working on that block, each nonce is checked on a seperate block, with a different set of parameters re: transaction fees.
A. Miner finds primary block, great. Standard bitcoin happens.
B. Miner finds solution to secondary block. What happens?
1. Secondary block added to separate blockchain. Something in the protocol would indicate that the transactions in this block refer to the data in blockchain A. The blockchain B block is propagated and added to everyones blockchain B.
2. How to make a transaction with multiple blockchains? These are just databases, right? Can't you have the wallet just scan multiple databases for the required information? "I need to see what outputs are owned by George. He has these on blockchain A, these on blockchain B, these on C... so to make this transaction, I'm going to to pull this one from A, this one from C, doop dee doo I'm a computer"
3. How to incentivize secondary blockchains? These would probably rely solely on transaction fees. In the future, you could imagine tiers of trust... "well, I'm selling you a taco, so I don't care if your on the secondary blockchain."
4. How to secure these additional blockchains? Every 10 blocks,? Every 20, some number of blocks - the primary chain includes information (the previous hash) of the additional chains. Secure is probably not the right word. Make trustless? So its like a checkpoint.
Potential pitfalls:
One issue I see is the increased rate at which the primary block would have to be modified - i.e., information of secondary, tertiary etc found blocks would propagate through the network, causing other blocks being worked on to become invalid, because those transactions were already sopped up from the mempool. Alternatively, would it be possible for bleedover to be ok? I.e., this confirmation was included in blockchain A at height X AND in blockchain B at height Y. Is it a double spend if the transaction is the same?
"Well I looked at ledger 1, and it says Alice's output #Y of 2 bitcoin is now bobs output #Z of 2 bitcoin, and I looked at ledger 2, and it says Alice's output #Y of 2 bitcoin is now bobs output #Z of 2 bitcoin."
But the important question: would this get at the scaleability problem?
The total amount of data would be the same... i.e., instead of going from 1 MB blocks to 20 MB blocks, we just have 20 blockTHREADS (?) with 1 MB blocksizes (for instance). But perhaps the effectiveness of the data transmission would increase, with the supposition being that smaller files would move through the network faster.
This might also create the phenomenon of blockchain locales.
oh boy. there goes the morning.
https://bitcointalksearch.org/topic/m.2304432
and maybe here:
https://bitcointalksearch.org/topic/m.3093912
So here are my assumptions. They may be naive and uninformed (I don't claim to be versed in this stuff), but I learn by doing, not by studying - so if you tell me why it couldn't work, then I understand bitcoin better.
The blocksize bottleneck has to do with too many transactions not making it into a block, they sit around in the mempool, things get backed up.
Relatively simple solution - increase blocksize.
Potential pitfalls, as I understand them, are increased resource requirements. The moot pitfall is storage space. The only relevant resource pitfall, methinks, is bandwidth.
After reading this, however, blockrope may be useless:
http://bitcoin.stackexchange.com/questions/36085/what-are-the-arguments-for-and-against-the-increase-of-the-block-size-limit
because the bandwidth issue has to do with concerns over supposed data caps - i.e., the concern is about how much data you have to push through the pipes, not how effectively you have to push the data through the pipes.
But here is the idea, and I think its simple. No idea re: implementation.
Introduce additional databases - additional ledgers. So, there's a bunch of transactions in the mempool, the miner is trying to solve a block for transaction collection #1, and trying to solve a block for collection #2, etc. And (as I think one of the posts above alluded to), this could be done in a merged mining fashion, wherein each nonce is tried against each block collection.
So say the miner is currently working on a block.. this is the primary block, and the miner has elected to only include transactions with a certain transaction fee. So this is his primary block. While working on that block, each nonce is checked on a seperate block, with a different set of parameters re: transaction fees.
A. Miner finds primary block, great. Standard bitcoin happens.
B. Miner finds solution to secondary block. What happens?
1. Secondary block added to separate blockchain. Something in the protocol would indicate that the transactions in this block refer to the data in blockchain A. The blockchain B block is propagated and added to everyones blockchain B.
2. How to make a transaction with multiple blockchains? These are just databases, right? Can't you have the wallet just scan multiple databases for the required information? "I need to see what outputs are owned by George. He has these on blockchain A, these on blockchain B, these on C... so to make this transaction, I'm going to to pull this one from A, this one from C, doop dee doo I'm a computer"
3. How to incentivize secondary blockchains? These would probably rely solely on transaction fees. In the future, you could imagine tiers of trust... "well, I'm selling you a taco, so I don't care if your on the secondary blockchain."
4. How to secure these additional blockchains? Every 10 blocks,? Every 20, some number of blocks - the primary chain includes information (the previous hash) of the additional chains. Secure is probably not the right word. Make trustless? So its like a checkpoint.
Potential pitfalls:
One issue I see is the increased rate at which the primary block would have to be modified - i.e., information of secondary, tertiary etc found blocks would propagate through the network, causing other blocks being worked on to become invalid, because those transactions were already sopped up from the mempool. Alternatively, would it be possible for bleedover to be ok? I.e., this confirmation was included in blockchain A at height X AND in blockchain B at height Y. Is it a double spend if the transaction is the same?
"Well I looked at ledger 1, and it says Alice's output #Y of 2 bitcoin is now bobs output #Z of 2 bitcoin, and I looked at ledger 2, and it says Alice's output #Y of 2 bitcoin is now bobs output #Z of 2 bitcoin."
But the important question: would this get at the scaleability problem?
The total amount of data would be the same... i.e., instead of going from 1 MB blocks to 20 MB blocks, we just have 20 blockTHREADS (?) with 1 MB blocksizes (for instance). But perhaps the effectiveness of the data transmission would increase, with the supposition being that smaller files would move through the network faster.
This might also create the phenomenon of blockchain locales.
oh boy. there goes the morning.
Jump to: