Skip to content

Decentralized Sharedrop Protocol

Tomáš edited this page Oct 20, 2017 · 1 revision

This protocol extends on the idea by @cm-steem to transfer Gridcoin to new codebase and blockchain. It has been show by Martin Grothe that some private information can be recovered from the blockchain and since we can't just change a data in a blockchain (a Hash List) we need to somewhat transfer the account balances to new chain. This protocol aims to do this process securely, that is without a single entity governing the process. Instead, the users of Gridcoin will have a share on validating the whole transition.

From some block, two chains will run in parallel. The new chain will start with genesis as normal coins do. But the mint mechanism on the new chain will be absolutely new thing. No PoW not PoS, but blocks on the new cahin will be secured by blocks from the old. Blocks on the old chain are signed by the same key as coinstake kernel input. How the new blocks will be created:

User A founds a kernel on the old chain, he will:

  • create empty block Bold for the old chain and Bnew for the new
  • include transactions from mempool into BOld using standard mechanism
  • copy and transcode transactions from BOld into BNew using Sharedrop method
  • add and transcode more unspent transactions from old chain to BNew
  • put height of BOld in BNew
  • sign BNew by the kernel key
  • put height and hash of BNew in BOld
  • sign BOld with the kernel key
  • publish both blocks

Conflict resolution:

  1. blocks on new chain that don't satisfy rules are rejected
  2. if hash of this bad block ends up in block on old chain, it is ignored, but the block is still let in the old chain (as nodes that don't run this dual-chain would fork with higher weight)
  3. if block on new chain is signed by different key than corresponding block (by heigh) on the old chain, then it is rejected
  4. Rule 2 must be enforced even for existing blocks on new chain, as the old can experience reorganizing

Sharedrop is a process of translating unspent transactions from the old chain in the new blocks. Since the old chain continues to run, this new transactions must be translated too. Transactios on new chain have different hash than on old, some lookup table must be used. When transcoding a new transaction:

  • it's hashboinc is cleared
  • for each input:
    • if corresponding transaction is in the new chain, the input hash is replaced by corresponding new transaction hash
    • othervise the input is marked as generated
  • output scripts are unchanged
  • the old_trxid is blacklisted from future transcoding
  • the new-old, old-new mapping is recored into lookup table

For sharedropping old UTXOs:

  • Miner can select any transaction from the old chain that is
    • not blacklisted from prefious transcoding
    • has at least one, nonzero onspent output
  • the transaction is transcoded as described above
  • this process repeats until the block size limit is reached or the transaction pool was exhausted

When all the transactions from old chain will be transcoded, both chains will continue running for a while. By some event the new chain will switch from this sharedrop minting protocol to classic PoS protocol and transaction transcoding will be disabled. At this point the old chain will become independent and should be abandoned.

You can’t perform that action at this time.