3

Context

Suppose I program a blockchain which doesn't require proof-of-work and deploy it on 3 servers A, B and C.

Now suppose server A and B receive requests to insert a new block with some data in the blockchain. Both A and B modify their local copies of blockchain. Before the modifications, the local copies of the blockchain are in sync. After the modification block a1 gets inserted in the copy of blockchain A, and block b1 gets inserted in the copy of blockchain B.

Question

How do I sync the blockchains in A and B, and what will the blockchain on C look like after a successful sync?

The previous block hashes on a1 and b1 will be same. However, after a sync, which one goes first? which block's previous hash get's modified? And most importantly, is there any established protocol to accomplish this synchronisation?

I hope my question was clear, can update the question with more details based on comments and answers. Thanks.

Didix
  • 107
  • 5
kapv89
  • 649
  • 1
  • 6
  • 12
  • I think the answer is "use Proof of Work (PoW) or Proof of Stake (PoS)". Or are you asking about how to merge immutable data? Basically with blockchain, a1 or b1 will be declared invalid (usually by PoW or PoS) and the other would be accepted as the "official" blockchain... There's no way to sync/merge them. – Maybe_Factor Feb 22 '18 at 06:54
  • 1
    Also... This would be a perfect question for https://area51.stackexchange.com/proposals/106592/blockchain-technology Please check it out and "commit" to using it if you are interested. – Maybe_Factor Feb 22 '18 at 07:00
  • Have a look at the [consensus problem](https://en.wikipedia.org/wiki/Consensus_(computer_science)) , proof of work is one of the protocols to tackle it. – S.D. Feb 22 '18 at 07:21
  • surely it must be possible to merge non conflicting transactions..... or maybe not!! – Ewan Feb 22 '18 at 10:33
  • You discovered the reason proof-of-work exists. – user253751 May 19 '22 at 09:44

1 Answers1

1

the solution depends on the specific blockchain-implementation. in general this situation is called a "fork".

the classical simple (and probably most implemented) solution is the following:

the first broadcasted block (eg a1) "wins". the second block (eg b1) is called "orphaned block". in the time between the broadcasting of a1 and b1 all other miner see only a1 and will mine on the base of a1 because a1 represents the longest blockchain. b1 can be broadcasted, but b1 will not be accepted as "THE real blockchain" as long as b1 will not has the longest blockchain. since the miner will mine based on a1 the blockchain with contains a1 will have the longest blockchain after the next block (which then based on a1) was found. b1 will be ignored ("orphaned") by all other nodes and miner. (this is the reason eg that you must wait for more than one confirmation if you want to be sure your transaction is in "THE real blockchain" and not in a block which will be orphaned.) there is no merging-protocol for orphaned-blocks: orphaned blocks are not a part of THE real blockchain so they will be ignored by others (eg by C). so the content of orphaned-blocks is de facto lost.

note: this approach is not really dependent on the algorithm how blocks are created. a block can be created by proof of work or by any other block-creation-algorithm where it is not predictable who creates the next block. the trivial solution above is still applicable.

anion
  • 249
  • 2
  • 8
  • Thanks for the answer. It was pretty informative. I have a question. The solution that you mentioned, ie, in which a1 "wins" and b1 becomes an "orphaned block", that solution is dependent on the implementation of the blockchain, right? Hypothetically, if I preserve the blockhain data-structure, and implement a syncing strategy by introducing a factor of "trust" between pairs, the resulting system will still have the security features that a blockchain provides, right? – kapv89 Feb 25 '18 at 18:08