1. pow is verified from main chain and re-org is possible if main chain had one
2. There should some pre-defined genesis fingerprint, This is block zero with no transaction in it
3. From there on if next block of main chain contains hash of sidechain block with hash of prevblock, Then verify the validity of block. And accept only if its valid.
4. After that any attempt to attach another block to a that prevblock would fail. even though the created block is invalid.
5. If there exist a main chain block with multiple block of the same sidechain. Accept the one with greater or less than all the others. (hash of it)
If I understand you correctly, then this is a sidechain model where the sidechain nodes follow the main chain closely and only produce blocks when the main chain produces blocks, and re-orgs when the main chain re-orgs.
The big advantage is, obviously, that cross-chain transaction management (important for 2-way-pegs) is much easier. But a couple of questions come up:
1) How do you prevent conflicts between sidechain nodes? If you use some sort of mining (e.g. merged mining) then there can be 51% attacks, by definition, because conflicts are solved with the "longer chain/more PoW rule". If you don't use mining, then which chain is correct if a part of the network is on a different "tip" than the rest?
2) What is the incentive to add blocks to the sidechain and to add all transactions correctly?
Regarding Ardor and similar models where the main chain secures the child/sidechains, in Ardor you preserve part of the scalability advantage, but sidechain structure is tied to the main chain protocol, so you can't "experiment" with child chains. That child chains are currently not easily added without action of the main chain devs (Jelurida, in Ardor's case) is not mandatory, that can be changed. Another disadvantage of this model is that the main chain protocol must support it explicitly, so you can't create a Bitcoin child-chain currently.