Helix Blockchain

[TierNolan]

This is a system which consists of 4 (or more) parallel chains.  Coins can exist on one of the 4 chains.  Each transaction output would indicate the destination chain and it can only be spent in that chain.

In effect, blocks for all 4 chains can add to the UTXO set any chains, but only one of the 4 chains can spend each UTXO entry.

Each header points to a header from the previous chain.  This creates a helix.

Code:

====A====A====A====A====
    '.   '.   '.   '.
=====B====B====B====B===
     '.   '.   '.   '.
======C====C====C====C==
      '.   '.   '.   '.
=======D====D====D====D=

Block N in chain B points to block N in chain A.  Similarly for C and D.  Block N + 1 in chain A points to block N in chain D.   This creates a helix of block headers.

The combined header chain loops between the 4 sub-chains.

...  A <- B <- C <- D <- A <- B <- C <- D ...

This means that nodes can prepare blocks in advance.  If a sub-chain A block is the newest block found, then all the miners would be working on a chain B block.  This block can only spend sub-chain B UTXOs.  The miner can have a type C block ready and waiting to be mined.  None of the inputs into the sub-chain C block can possible be spent by whichever sub-chain B block is found, since they all have to be sub-chain C inputs.

Once a miner hits their sub-chain B block, they can broadcast the header.  All other nodes can immediately switch to mining their "pre-built" C block.  They still need to follow up with the actual block within a short period.

This means that the block rate can be safely increased, since the propagation time for new blocks is reduced greatly (only an 80 byte header).  If blocks ran at 10 mins per chain (so 2.5 mins combined), then the time to confirmation stays the same.

This reduces variance until a transaction is verified.

It means that distributed p2p systems for building up blocks would have time to build (and verify) new blocks and have them waiting in advance.  This means that p2p miners might be possible.  This is a p2p system that creates the blocks themselves, as opposed to p2pool which is a p2p mining pools, but each node produces their own blocks.

[1715595496]

1715595496

[1715595496]

1715595496

[1715595496]

1715595496

[1715595496]

1715595496

[altcoinex]

Sounds like a fun experiment for an altcoin... ;]

[TierNolan]

Sounds like a fun experiment for an altcoin... ;]

It works as a soft fork too.  Just define every fourth block as being in the same chain.  Transactions are only allowed to be in block N if the last 2 LSBs of the UTXO's digest match the block height.

This would split all current outputs 4 ways over the sub-chains.

[Jakesy]

Sounds like a fun experiment for an altcoin... ;]

It works as a soft fork too.  Just define every fourth block as being in the same chain.  Transactions are only allowed to be in block N if the last 2 LSBs of the UTXO's digest match the block height.

This would split all current outputs 4 ways over the sub-chains.

Why 4?  What is the principle behind this number?  Why not 3?

[TierNolan]

Why 4?  What is the principle behind this number?  Why not 3?

3 works too.  4 gives more time to get prepared for the next block.  You could get 2 blocks quickly, but less likely 3 fast.

[virtualx]

This is a system which consists of 4 (or more) parallel chains.  Coins can exist on one of the 4 chains.  Each transaction output would indicate the destination chain and it can only be spent in that chain.

In effect, blocks for all 4 chains can add to the UTXO set any chains, but only one of the 4 chains can spend each UTXO entry.

Each header points to a header from the previous chain.  This creates a helix.

Code:

====A====A====A====A====
    '.   '.   '.   '.
=====B====B====B====B===
     '.   '.   '.   '.
======C====C====C====C==
      '.   '.   '.   '.
=======D====D====D====D=

Block N in chain B points to block N in chain A.  Similarly for C and D.  Block N + 1 in chain A points to block N in chain D.   This creates a helix of block headers.

The combined header chain loops between the 4 sub-chains.

...  A <- B <- C <- D <- A <- B <- C <- D ...
..

Interesting idea. I think this could work. ? Can a coin move between the chains? This is the idea that I get from your image. What is the difference between one big chain and a couple of chains linked together?

[TierNolan]

Interesting idea. I think this could work. ? Can a coin move between the chains? This is the idea that I get from your image. What is the difference between one big chain and a couple of chains linked together?

You can spend a coin to any chain you wish.  Once the coin is on a particular chain, then it can only be spent in blocks for that sub-chain.

The advantage is that only around 25% of the coins can be spent at any one time.  This means that new blocks can be built in advance.  This would mean that a p2p mining system could be viable.

In this system, there is some p2p process to decide on the next block that everyone will mine, but that needs time for it to be verified.  It would be like p2pool, but everyone mines the same block.

[virtualx]

Interesting idea. I think this could work. ? Can a coin move between the chains? This is the idea that I get from your image. What is the difference between one big chain and a couple of chains linked together?

You can spend a coin to any chain you wish.  Once the coin is on a particular chain, then it can only be spent in blocks for that sub-chain.

The advantage is that only around 25% of the coins can be spent at any one time.  This means that new blocks can be built in advance.  This would mean that a p2p mining system could be viable.

In this system, there is some p2p process to decide on the next block that everyone will mine, but that needs time for it to be verified.  It would be like p2pool, but everyone mines the same block.

How can double spent be prevented in this system, if a user transmits a coin both to chain A and chain B at the same time? Which transaction would be accepted?
Would this speed up searching for a certain block in the set of chains?

[altcoinex]

This is a system which consists of 4 (or more) parallel chains.  Coins can exist on one of the 4 chains.  Each transaction output would indicate the destination chain and it can only be spent in that chain.

In effect, blocks for all 4 chains can add to the UTXO set any chains, but only one of the 4 chains can spend each UTXO entry.

Each header points to a header from the previous chain.  This creates a helix.

Code:

====A====A====A====A====
    '.   '.   '.   '.
=====B====B====B====B===
     '.   '.   '.   '.
======C====C====C====C==
      '.   '.   '.   '.
=======D====D====D====D=

Block N in chain B points to block N in chain A.  Similarly for C and D.  Block N + 1 in chain A points to block N in chain D.   This creates a helix of block headers.

The combined header chain loops between the 4 sub-chains.

...  A <- B <- C <- D <- A <- B <- C <- D ...

This means that nodes can prepare blocks in advance.  If a sub-chain A block is the newest block found, then all the miners would be working on a chain B block.  This block can only spend sub-chain B UTXOs.  The miner can have a type C block ready and waiting to be mined.  None of the inputs into the sub-chain C block can possible be spent by whichever sub-chain B block is found, since they all have to be sub-chain C inputs.

Once a miner hits their sub-chain B block, they can broadcast the header.  All other nodes can immediately switch to mining their "pre-built" C block.  They still need to follow up with the actual block within a short period.

This means that the block rate can be safely increased, since the propagation time for new blocks is reduced greatly (only an 80 byte header).  If blocks ran at 10 mins per chain (so 2.5 mins combined), then the time to confirmation stays the same.

This reduces variance until a transaction is verified.

It means that distributed p2p systems for building up blocks would have time to build (and verify) new blocks and have them waiting in advance.  This means that p2p miners might be possible.  This is a p2p system that creates the blocks themselves, as opposed to p2pool which is a p2p mining pools, but each node produces their own blocks.

This seems kind of similar to tree chains. The seeming difference would be four chains cross referencing, as opposed to four branches referencing the parent. I wonder how much of the tree chain model applies...

How can double spent be prevented in this system, if a user transmits a coin both to chain A and chain B at the same time? Which transaction would be accepted?
Would this speed up searching for a certain block in the set of chains?

Double spend risks were my first concern as well, more broadly, the same set of implications sidechains/treechains have had holding them back.

[TierNolan]

How can double spent be prevented in this system, if a user transmits a coin both to chain A and chain B at the same time? Which transaction would be accepted?
Would this speed up searching for a certain block in the set of chains?

The 4 sub-chains are completely synced.  Full nodes would watch all 4 at the same time.  The purpose isn't to spread out the load so each node only has to watch one of the 4 sub-chains.

This means that there is no additional double spend risk.

The advantage is that you can create blocks and have them waiting to be deployed immediately when a new block is found.

The p2p miner I am thinking of is that where there would be a merge mined chain with small blocks.  Each sub-block might be 100kB at most.  These blocks eventually form a full block.  Any illegal transactions get found and a fraud proof added to the parallel chain.  For that to work, there needs to be a time delay between when the new block is "locked" and when it has to be ready to be mined against.  The helix achieves that.

You can have a new sub-chain A block locked once the C block before it is found.  While the D block after that is being searched for, the pending A block can be analysed and fraud proofs issued if required.

[Carlton Banks]

How can double spent be prevented in this system, if a user transmits a coin both to chain A and chain B at the same time? Which transaction would be accepted?
Would this speed up searching for a certain block in the set of chains?

The 4 sub-chains are completely synced.  Full nodes would watch all 4 at the same time.  The purpose isn't to spread out the load so each node only has to watch one of the 4 sub-chains.

This means that there is no additional double spend risk.

The advantage is that you can create blocks and have them waiting to be deployed immediately when a new block is found.

The p2p miner I am thinking of is that where there would be a merge mined chain with small blocks.  Each sub-block might be 100kB at most.  These blocks eventually form a full block.  Any illegal transactions get found and a fraud proof added to the parallel chain.  For that to work, there needs to be a time delay between when the new block is "locked" and when it has to be ready to be mined against.  The helix achieves that.

You can have a new sub-chain A block locked once the C block before it is found.  While the D block after that is being searched for, the pending A block can be analysed and fraud proofs issued if required.

Sounds very intriguing. Are there no negative consequences to this? All the obvious objections seem to be invalid.

[TierNolan]

Sounds very intriguing. Are there no negative consequences to this? All the obvious objections seem to be invalid.

The first cost is higher confirmation time.  The average time to the next block is 5 mins.  The average time to the next block of a particular type is 25 mins.  It might be possible to increase the block confirmation time though.

Miners could even publish their blocks ahead of time, again with something like merged mining. 

Another cost is that wallets must maintain a range of coin types.  You can only spend multiple coins if they are for the same subchain.  A user might have 1BTC, but only be able to spend 0.25 BTC on any one thing.  Users could try to converge their coins on a particular sub-chain, so they can normally spend all their money at once.  Alternatively, they might try for a mix of types, so that they can reduce confirmation time.  If the current block is chain A, then broadcasting a chain C transaction will probably be confirmed quickly.

It can be implemented as a soft fork.  All blocks before block <some height> could be defined as sub-chain A and all the blocks after that could be arranged in the helix.  This means that all old transactions are still spendable (but only in every 4th block).

[Carlton Banks]

So if a helical chain can help circumvent block propagation latency issues, then how far could the (aggregated) block rate be increased?

It seems as if some goldilocks zone may exist, where a tradeoff between number of helices and the target block rate could be negotiated, such that the user (or wallet software) could balance their helices-specific outputs so as to make it a non-issue, i.e. it won't be necessary in most cases to wait for confirmations of every input in a transaction where some outputs are confirmed on a different chain, say, up to 30 seconds later than others. Although perhaps that possibility would require hard fork coding, IDK

[TierNolan]

So if a helical chain can help circumvent block propagation latency issues, then how far could the (aggregated) block rate be increased?

I think each sub-chain would still be restricted to 10 mins (if that is your acceptable target block rate) giving a total rate of 10 mins divided by number of sub-chains.

It seems as if some goldilocks zone may exist, where a tradeoff between number of helices and the target block rate could be negotiated, such that the user (or wallet software) could balance their helices-specific outputs so as to make it a non-issue, i.e. it won't matter in most cases where waiting on all confirmations for a transaction where some outputs are confirmed on a different chain, say, up to 30 seconds later than others.

The more sub-chains the more consistent the block rate.  This helps with building up blocks in advance, since it gives a minimum time between a proposed block being locked and when it would actually be used.

Since all inputs into a transaction have to be for the same chain, only coins of the same type can be spent together.  This means that if there were 100 sub-chains, wallet fragmentation would be a big deal.

Although perhaps that possibility would require hard fork coding, IDK

The block rate requires a hard fork to change, I think.  Even modifying the meaning of the timestamp doesn't help if you want legacy nodes to accept the fork.