Any forks on the parent chain propagate to the child chain. Anytime the parent chain is stuck, so is the election cycle on the child chain. This is a direct result of the parent chain being the source of truth regarding serialization of commitments and source of entropy. There are some assumptions to be made regarding the parent chain (like - it is stable, not prone to attacks and so on) that the child chain uses to derive its own security. If the parent chain fails - the child chain can not elect the next leader and the current leader remains such until the parent chain issue is resolved. Since we are using BitcoinNG, microblocks would still be produced so the child chain will not be stuck but rather centralized for the time being. This could be solved by providing some voting on the child chain but currently this is not a priority. A great question, though 
Thanks for the reply, I got the answer I was looking for.
At present, I am learning about the knowledge of blockchain. I think the development of smart contracts is a very interesting thing, and I hope to make some contributions to the development of the AE ecosystem in the future. 
Can you elaborate on what the bug was and how it’s being fixed? 
It was a smart contract bug.
There is a recouring metafor for staking: everyone involved gets a lottary ticket, the more tickets you have - the higher chance you get to get elected as a leader. The bug was a corruption of the ticket’s space. Meanwhile we fixed a few more bugs and developed testing framework to test edge cases. We are now closing known issues in the contract itself - like the validator can withdraw his stake and continue being a validator (having only delegated staking power). Once those are fixed, we will fire back the HC test network.
希望可以及早的看到超链！！！期待
Hi, I have a new confusion, I hope someone can help me answer it, thank you:
For the POS chain, since it is easy to forge the ledger, assuming that the perpetrator controls a block, and then starts from this block, forging a chain longer than the main chain (even if the pledged coins will be confiscated), then the newly added node , it is impossible to determine which is the real chain.
So for hyperchains, does this problem still exist? Suppose I completely control a certain block of the child chain, and then submit different information to the parent chain twice, which makes the child chain fork, and then keep synchronizing with the parent chain on the fake chain.
In this way, even if it is discovered, it does not seem to be able to change anything. After all, it does not need to consume computing power, and the cost of maintaining synchronization with the parent chain is relatively low.
Writing the history of the child chain to the parent chain is an excellent idea in my opinion, but I’m not sure if the above problem exists, and if so, there will be a different history of the child chain on the parent chain.
Hi, I did some more thinking on this issue and found a related paper online
Babylon: Reusing Bitcoin Mining to Enhance Proof-of-Stake Security
In this paper, a method to resolve the conflict of sub-chain blocks is expounded: the relevant data of the conflicting sub-chain blocks are submitted to the parent chain as evidence, the parent chain verifies its validity, and only the verified block is written to the parent chain.
But the premise of this is that the parent chain can interact with the child chain. If not, I am not sure whether directly storing the block data as evidence in the parent chain can achieve the same purpose, and are these data too large.
I have conducted preliminary research on this issue because of my interest. Due to the limitations of professional knowledge, the above views may not be accurate. And I look forward to the developers sharing their solutions, thank you. 
Of course, the scheme design that does not require the parent chain to check the data validity of the child chain is more versatile, but it also seems to have more challenges.
In addition, in my opinion, a POS chain without an external source of trust has security risks, but in some views, it is considered to be weak subjectivity, so there may be no right or wrong, only the most suitable usage scenarios. 
Hey, all of those are quite nice remarks! Yes, since block production is cheap, PoS are subject to long range attacks. With regards of HCs, this risk is mittigated: all commitments are published on the parent chain and in essence the parent chain is being used as a soft real time ledger for commitments: for each staker - which fork they supported. Please note that commitments are small (they are just the hash of the child chain keyblock) but also public for anyone to see in real time. A staker is not allowed to support 2 different forks and how to treat a staker if they publish a competing fork is yet TBD.
What is really important is that if someone has more than 51% of the staking power - they could start posting commitments in parallel in real time. What is the difference with traditional PoS is that such 51% attacks can not be based on old state - the parent chain ledger is being used to anchor the child chain, snapshot it so no attack based on old state could succeed. Still, if someone has 51% of the staking power now, they could start posting competing commitments while building a parallel fork over time. Assumption is that if they do so they could do a 51% attack but since they own 51% of the stake - they would be hurt the most.
Again - since commitments are public we can punish stakers that do more than one commitment. This would likely be implemented in the consensus smart contract itself so I would expect more than one solution to this problem
Hi, thanks for your reply, it made my understanding better.
I still have question about possible para-fake chains: Assuming this real happens (with new chains in development, I think it’s possible), what are the rules for judging the main chain and the evil chain, it seems that the longest chain rule doesn’t apply in this case.
Another great question Let’s dive into fork weights.
What is the longer chain in other chains, in AE is called difficulty - it represents not the amount of blocks but rather it is a measure for the amount of electricity spent on solving the PoW puzzle on a fork. It is the total amount of computations (which can be reduced to electricity cost) on all keyblocks on a fork. The more PoW computations a fork has, the heavier it is - it is the product of more miner’s work. The heavier fork wins.
In HC context we don’t have PoW, we don’t have miners and electricity spent makes no sense. We do have validators and they have corresponding staking powers. In the trivial case in which every staking validator posts a commitment on every election cycle it is easy: each commitment on the parent chain represents a vote, it is a statement like “I support this fork with my staking power”. Then at the end of the day we know how much staking power supported each fork - it is the toal sum of all the staking power of all validators that supported that fork. It is yet to be discussed if we punish validators supporting two different forks and how this would work in an environment more optimized with regards of a total number of commitments.
I really like your questions as they show your deep understaning of HCs
Hi, thank you for your answer and affirmation, I am very happy to communicate with the developers, I have learned a lot.
In my opinion, based on the security assumption of the parent chain, HC can solve some problems of POS, such as reliable timestamp and real-time monitoring, immutable history, etc. but there are still some problems to be discussed further, such as the above mentioned the choice of parallel fork chains, but I think that compared with pure POS, HC is more operable, and with the development of technology, these problems can eventually be well solved.
Looking forward to the launch of the Hyperchain Alpha version, which will allow more people to test HC in a more realistic environment and come up with more innovative solutions.
great,great…
An update from our team: we are about to restart the HC Alpha test network.
During the past few weeks we did a lot of work in the area. Most notable changes are:
Improved testing
We fixed a couple of bugs in the consensus smart contract. Those were resulting in the network getting stuck. We tightend up some tests to to help us detect regressions.
Parent chain connectors
A lot of work was done with regards of parent chain connections - the AE one is ready, the BTC one is under development. The node has the functionality to call a couple of different parent chain nodes and to build consensus from their responses. This is how the child chain node will interact with the parent chain: posting and fetching commitments, getting specific hashes and so on. Those are not yet propagated to the consensus smart contract.
Smart contract improvements
We revisited the smart contract with regards of usability and UI:
- an improved interface is being added for accessing validator’s state - now there is a single endpoint that fetches all the data required, no need to do a lot of sequential dry-runs
- the minumum staking and new validator stake limits are now fully configurable at genesis block. Those used to be hardcoded in the contract body. This allows users to spawn their own HCs configured according to their needs
- added additional functionality available only for the validator: now they can set their own name, description and avatar url. This will allow them to build branding of their pool. None of those are mandatorary for a pool to operate
- enforced a minimum amount a validator must persist in their own pool. The old behaviour was really dangerous as users had a minimum stake to become a validator but then they could simply withdraw all stake while still being a validator. This could potentially result in a validator getting staking support by their pool while not having any stake of their own
Revisited configs
The HC settings were a bit messy and this resulted in a corresponding refactoring and clean up. Now seed calls are moved to a json file of their own and they do not polute the config. The naming of seed files is being revisited as well. Furthermore - network ids that do not have a hc_ prefix are allowed to become HCs as well.
Staking interface improvements
The staking UI that showcases staking and unstaking had been reworked to better represent the data.
HC Alpha testnet
Based on the above, the HC Alpha testnet now has different expectations for becoming a validator (1mln AE opposed to 1000 as it used to be). Now some of the 3 validators have additional info - names, descriptions and avatars. It is by purpose that not all of them have it as we don’t want to enforce this on validators.
There is a lot of work ahead but we are moving in the right direction.
so… does this mean node can call BTC, LTC etc. parent chain?
Yes, but there are no commitments yet produced, none are collected, the entropy is not propagated to the contract and so on but this is a step in the right direction. But indeed this is the goal.
Dear community,
Demo UI is online again. Feel free to test on https://hc-alpha.aepps.com
We’ll be rolling out more updates on the presentation layer soon 
Dear community,
to improve the transparency of our work we created a GitHub project page. Now you can keep track of our progress: Hyperchains · GitHub
We’ll proceed with forum updates on a bi-weekly schedule.
It’s already great.
Relatively speaking, I don’t know anything. I came in to learn from my teacher.