any update？
Dear community, after a long wait, I’m happy to share our updates.
You can access HC Alpha nodes via a new url: https://testnet-hc.aeternity.io/v2/status
HC-specific Base app wallet was deployed under: https://base-hc.dev.aepps.com/
before creating a new account, make sure you’re connected to propper network:
- url: https://testnet-hc.aeternity.io
- network id: ae_smart_contract_test
To top up your account, you can use a new faucet: https://dev-faucet-hc.aepps.com/ The limit is 30AE daily.
The new version of Demo UI allows staking: https://hc-alpha.aepps.com/staking
Feel free to play around and let us know if you have any issues.
Thank you for waiting!
2 Likes
Super! Super!
2 Likes
We’ve hit a consensus bug in the HyperChains’ testnet. This is exactly the reason we have this testnet in the first place 
it is really important catching those on testnets. For the time being, the network is paused: we need it in order to be able to debug the problem. We will keep you up to date.
6 Likes
Hi, I recently learned that the stacks blockchain is also doing research on hyperchains, and their purpose seems to be to layer the network through hyperchains to increase transaction speed.
Is this the same technical route as ae’s hyperchain? Can the two parties conduct technical exchanges to optimize technical functions?
Dear community,
We identified recent bug in the testnet, and we’re planning a new release with the fix.
We have started working on parent chain connectors, which will be our main focus in the upcoming weeks.
3 Likes
Hi, I have a new question. If the parent chain forks or the parent chain goes offline, what will be the impact on the child chain? After all, it’s all possible.
Looking forward to the developer’s answer, thank you
Or the parent chain delays producing blocks
1 Like
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
2 Likes
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. 
3 Likes
Can you elaborate on what the bug was and how it’s being fixed? 
1 Like
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.
2 Likes
希望可以及早的看到超链！！！期待
2 Likes
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.
2 Likes
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. 
1 Like
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. 
1 Like
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
3 Likes
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.
2 Likes
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
3 Likes
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.
1 Like