pixelspark
Sidechains
Currently, a node can choose whether to 'replay' SQL transactions on top of the database engine, and select only those tables that it is interested in. The query history however needs to be stored by all nodes for all tables (nodes could throw away blocks after a certain amount of time has passed, but that would make it impossible for new nodes to download the full blockchain from block 0).
It would be preferable if SQL transactions could be split into 'side chains', where each node would only 'follow' the side chains of its interest (and discard the rest).
- A sidechain is an independent block chain with their own numbering and sidechain genesis (which identifies a particular sidechain)
- Root chain blocks contain only the hashes of newly mined blocks (if they are accepted). For a miner to determine which sideblocks are acceptable, it only needs to check the last block in the sidechain (is index successive) and maintain state (what is the sidechain difficulty?).
- The root chain should contain an incentive for mining a side chain block ('credits'?).
Starting a sidechain would be akin to creating a new database. The root chain may also handle payments and dropping of sidechains (either upon request, or when a certain time has exceeded).
Nodes mining a sidechain block should perhaps be required to 'prove' they also still have all history blocks (perhaps by requiring a deterministically randomly chosen history block to be included in the signature hash?).
Things to figure out:
- How to incentivize miners to both mine the root chain as well as the side chains?
- Make root blocks only mineable if a miner has provably done N sidechain work (sum of sidechain difficulty * blocks mined since a certain root block)?
- Difficulty levels of the side/root chain?
- Should there be a single difficulty level for all sidechains, or individual difficulty levels?
- Difficulty level for a new sidechain? (genesis requirement)
- How to ensure that nodes actually keep the blocks in side chains available for download? Require at least the miners to do so?
So in order to claim a reward in the 'superchain' for work on a sidechain, the miner should simply submit the same block to the superchain again. As this defeats the purpose of having side chains at all, we should find a way to exclude the payload from the block, but still have enough information to validate the block.
This could be done by online including a hash of the payload in the signature (like Bitcoin's merkle root), and then include only that signature in the 'light' block.
Also we'd need to add the genesis hash, so the superchain can distinguish between chains. The superchain also needs to be aware of the difficulty mechanism used in the sidechain. A 'light' block (which would be a superblock transaction, let's call them a 'claim') thus looks like this:
- Block version (8 B)
- Genesis hash for the chain (32 B)
- Previous block hash (32 B)
- Block height (8 B)
- Timestamp (8 B)
- Payload hash (32 B)
- Miner public key hash (32 B)
- Nonce (8 B)
- Signature (based on the above) (32 B)
(Total size is 192 bytes, which means a 1MB superblock can contain ±5k 'claims' We could shave a few bytes off by taking only 4 bytes for nonce and version, which would make the block 184 bytes).