But can they now? I'm not sure we have a problem that needs solving.
Topic: Entangled Chains for Scalability (Read 201 times)
With sharding each chain gets less hashing power (for PoW) or less stake (for PoS), and hence easier to attack..
Ya especially for sharded chains where each chain has smaller set of miner/validators..
But this is an effective way to harden data structure so miners can't play dirty tricks with chains easily.
But can they now? I'm not sure we have a problem that needs solving.
But this is an effective way to harden data structure so miners can't play dirty tricks with chains easily.
Also different from many other sidechain and sharding proposals, all the entangled chains share the same token.
A user can't validate all these chains at once to detect rogue emission. From his point of view it isn't the same token.
https://bitcointalksearch.org/topic/split-bitcoin-2381234
Just wondering whether similar proposals have been discussed..
The idea has some similarity with side-chain and sharding, but there are differences. The following figure shows the basic structure of the "Entangled Chains". Each block header has two hash pointers, one pointing to the previous block in the same chain, the other points to the tailing block in the longest branch of the "neighboring chain". The chains can grow in parallel so it has higher throughput than a single chain. The entangled chain concept also bears some similarity with IOTA, but the hash pointers in our proposal are more structured, i.e. the hash point of a block on chain i can only points to the blocks on the same chain, or a block on chain (i + 1 mod N), where N is the total number of chains. Also different from many other sidechain and sharding proposals, all the entangled chains share the same token.
https://i.imgur.com/ijdTJAq.png
The cross chain hash pointers help improve the security of the system (against double spending). As shown in the figure below, the fan-in tree of the bottom left corner block contains blocks in different chains (shown in red color). Hence if an attacker wants to create an double spending transaction, he/she needs to create the entire fan-in tree across multiple chains, and need to create those faster than the honest miners/validators.
https://i.imgur.com/73e8HGQ.png
To handle ever increasing throughput, the chain can split as shown in the figure below. We can introduce voting mechanisms so the community can vote whether to split (or even merge) the chains depending on the need. With this the throughput of network can scale linearly with the number of new users.
https://i.imgur.com/v71r5ak.png
The entangled chain structure also helps reduce the storage requirement. A miner/validator for a chain only needs to store the transaction data on its own chain, and the headers of other chains for cross chain transaction verification. In the example shown in the figure below, the miners/validators on chain #2 only stores the transaction data for chain #2. This could greatly reduce the amount of storage space needed as the users grow.
https://i.imgur.com/H9UBET8.png
Transactions within the same chain will be processed the same way as in Bitcoin. Cross-chain transactions need to have special treatment to ensure safety and liveness. We propose to carry out a cross-chain transaction in two steps:
Step 1: generate a special transaction tx_id = lockin(source_chain_id, source_addr, target_chain_id, target_addr, amount). The only valid next operation for lockin is to commit a cross chain transfer. After this type of lockin transaction got written into a block, honest validators/miners will automatically generate and propagate a corresponding commit_xchain_transfer transaction as follows.
Step 2: commit_xchain_transfer(tx_id), along with the lockin transaction, its merkle siblings also need to be sent to the validators of the target chain. The miners/validators use SPV to verify that the lockin transaction has been included in the source chain. The initiator of the lockin transaction can also initiate the commit_xchain_transfer if the auto generated commit_xchain_transfer failed for some reason. Eventually the cross chain transaction will be executed successfully.
Double spending is not possible since the lockin step has specified the target chain, the amount of token is already deducted from the sender’s balance, and can only be transferred to the target chain.
This approach seems to work with different consensus mechanisms, including PoW and PoS.
Thoughts?
The idea has some similarity with side-chain and sharding, but there are differences. The following figure shows the basic structure of the "Entangled Chains". Each block header has two hash pointers, one pointing to the previous block in the same chain, the other points to the tailing block in the longest branch of the "neighboring chain". The chains can grow in parallel so it has higher throughput than a single chain. The entangled chain concept also bears some similarity with IOTA, but the hash pointers in our proposal are more structured, i.e. the hash point of a block on chain i can only points to the blocks on the same chain, or a block on chain (i + 1 mod N), where N is the total number of chains. Also different from many other sidechain and sharding proposals, all the entangled chains share the same token.
https://i.imgur.com/ijdTJAq.png
The cross chain hash pointers help improve the security of the system (against double spending). As shown in the figure below, the fan-in tree of the bottom left corner block contains blocks in different chains (shown in red color). Hence if an attacker wants to create an double spending transaction, he/she needs to create the entire fan-in tree across multiple chains, and need to create those faster than the honest miners/validators.
https://i.imgur.com/73e8HGQ.png
To handle ever increasing throughput, the chain can split as shown in the figure below. We can introduce voting mechanisms so the community can vote whether to split (or even merge) the chains depending on the need. With this the throughput of network can scale linearly with the number of new users.
https://i.imgur.com/v71r5ak.png
The entangled chain structure also helps reduce the storage requirement. A miner/validator for a chain only needs to store the transaction data on its own chain, and the headers of other chains for cross chain transaction verification. In the example shown in the figure below, the miners/validators on chain #2 only stores the transaction data for chain #2. This could greatly reduce the amount of storage space needed as the users grow.
https://i.imgur.com/H9UBET8.png
Transactions within the same chain will be processed the same way as in Bitcoin. Cross-chain transactions need to have special treatment to ensure safety and liveness. We propose to carry out a cross-chain transaction in two steps:
Step 1: generate a special transaction tx_id = lockin(source_chain_id, source_addr, target_chain_id, target_addr, amount). The only valid next operation for lockin is to commit a cross chain transfer. After this type of lockin transaction got written into a block, honest validators/miners will automatically generate and propagate a corresponding commit_xchain_transfer transaction as follows.
Step 2: commit_xchain_transfer(tx_id), along with the lockin transaction, its merkle siblings also need to be sent to the validators of the target chain. The miners/validators use SPV to verify that the lockin transaction has been included in the source chain. The initiator of the lockin transaction can also initiate the commit_xchain_transfer if the auto generated commit_xchain_transfer failed for some reason. Eventually the cross chain transaction will be executed successfully.
Double spending is not possible since the lockin step has specified the target chain, the amount of token is already deducted from the sender’s balance, and can only be transferred to the target chain.
This approach seems to work with different consensus mechanisms, including PoW and PoS.
Thoughts?
Jump to: