Dear @chuxl,
I apologies for for the delay. It was my estimate and I will try to plan next time on a large time scale. Several members of of the core team were sick (corona and/or flu) and this leads to delay of ca. 2 weeks. However now the team is doing its best to deliver the hyperchains alpha for testing soon. Please note that in the software development an exact time planning is not always possible, especially in the case when a new research and (re)design are required for completing the implementation.
1 Like
Dear community,
The team is continuing the effort of preparing the new testnet environment.
All the recent code updates can be found in the feature branch: hc_alpha
@Baixin.chain the UI will live in hc_alpha repository
4 Likes
I looked at stakes Validator contracts and MainStaking contracts
I have a few questions I’d like you to answer
- After the Leader is elected, the validator receives a reward. How can the user receive the reward?
- This election does not seem to be completely random. The validator with the most votes may never be the Leader, and only the validator in the middle has a higher probability of winning the Leader
entrypoint elect_at_height(height : int) =
let sorted = List.sort(validator_cmp, Map.to_list(state.online_validators))
let shot = Bytes.to_int(state.entropy) * height mod state.total_stake
switch(find_validator(sorted, shot))
None => abort("NO CANDIDATE") // should not be possible
Some(new_leader) => new_leader
-
This seems to be DPOS or POS. What is the relationship between it and hyperlink? Where is the parent chain of BTC associated?
-
After the Leader is elected, what does the Leader need to do?
-
When will AE in the validator contract be destroyed?
I am a technical novice, may not understand thoroughly, hope to help me remove the doubt
3 Likes
首先希望您们的团队成员早日康复，也希望能早日看到超链的测试，虽然很多人可能对超链并不抱有太大的期望，这个期望是能不能让ae重新回到主流币的行列，但是至少让还没有对ae完全失去信心的人们看到团队依然在回归而努力！
1 Like
Shut up and speak English.
1 Like
The second one I understand. thank you
Hey, thanks for digging deeper! You’re not novice but rather modest. All of those are great questions, let me answer those:
It is a DPoS contract. We have 2 types of users: delegates and staking validators. If you cover the criteria - you can become a validator. This entitles you to be eligible for becoming a leader. Depending on your staking power - the higher it is, the more likely you would become a leader. Other users that do not cover the criteria for leaders, could support you in your effort. They delegate their staking power to you. This is all in the smart contract.
As you’ve said, once you become a leader, you receive rewards for your effort. Those are split between the validator and their delegates. The goal is one validator to be supported by as many delegates as possible. This would mean that rewarding everyone could become computationally heavy. We took a different approach.
Once Victor becomes a validator, there is a special smart contract created for his staking pool. Initially it receives Victor’s initial stake and mines new VictorTokens. Let’s have Victor staking 990 AE. Then in the staking pool contract he receives 990 VT (VictorTokens). Then comes Alice. She can not become a validator, so instead she supports Victor with 10 AE. Those are locked in the staking smart contract and there Alice is rewarded 10 VT. The total amount of AE in this contract represents the total stash in the pool, its staking power. The distribution of VTs represents percentage ownership of this stash. Think of it as a company: that the staking power is the market cap of this company and tokens represent shares. In our case the staking power is 1000 AE and Victor owns 99% of those, Alice owns 1% (990 VT and 10 VT respectively). A rate AE:VT is automatically persisted. In case someone wants to unstake - they sell their shares to the contract and receive corresponding AE amount. Fast forward in time: Victor is elected as a leader and receives 100 AE in fees and block rewards. We do not mint VTs for those. Then the total staking power of the contract is now 1100 AE. If neither Alice nor Victor had staked or unstaked - they still own their shares - 1% and 99% respectively. At this point the AE:VT rate is 1.1 - it had increased because of the rewards. If Alice wants to unstake - she has to sell all her VTs to the contract according to this rate. She will receive 11 AE and her VTs would be destroyed. Since the contract received 100 AE and she had 1% of the staking power, she receives exactly that.
What this approach allows us is rewarding millions of delegates on every generation: we only update the smart contract’s balance. If Alice wants to unstake - she has to explicitly state that and pay the fees for the computations required for the contract call.
It is pseudo-random, there is no way of achieving full randomness while being deterministic. Since the entropy is a random hash that inits the contract, its byte representation is a great seed for the randomness. This Bytes.to_int(state.entropy) * height essentially is a really big number that we take modulo of the total probability space. This should be good enough.
What is more - the contract is not final by any means:
- we must implement delays in staking and unstaking
- the entropy should change - it must come from the parent chain. This is one of the neat ways of using the parent chain as a source of entropy
- limiting the amount a validator can unstake
- requiring a minimum percentage of the validator in their own staking pool
- adding metadata to staking pools - staker name, URL, maybe an image
We know some of those and some are discovered as we go.
Exactly: it is DPoS. As you’ve probably guessed already, HC are really complex. Every hybrid PoW&PoS model is either PoW with PoS component or PoS with PoW component. HCs are DPoS with heavy PoW component. That’s why we first develop the DPoS part as this is the heart of the consensus. Without it we can not develop the PoW components. As you can see from the branch, most of the work in the consensus happens in one single module. This means adding more people to the effort would make it even harder to work. As described at the top post, we want to scale the effort but the DPoS consensus part is a blocker. Starting a HC Alpha testnet would allow us to build the parent chain connectors, UI and a test framework in parallel - we can finally add more people. We can also test different smart contracts and different approaches there altogether. Keeping the contract interface relatively static would mean that UI would work despite changing how the node operates.
From then on, it remains the same. The newly elected leader publishes a key block and micro blocks. What is different is that the key block is also signed by the leader. In the context of PoW we don’t do that. One of our primary goals is to keep all current tools that work for main net to be working on top of the hyper chain without any change. This means full backwards compatibility with regard to data structures. That’s why we are recycling unused data fields, ex. the signature goes in the PoW’s evidence. Internally this is now refactored to be called key_block_seal but we can not change APIs without breaking backwards compatibility. This is something to be further discussed down the road.
It is not destroyed, but it is rather withdrawn. Once someone decides to unstake, their staking pool tokens are destroyed and the AE is withdrawn to their account. Please consult the first point regarding more details.
So a lot of work had been done. We try being as open as possible but some of our progress is so deep in the node internals that it is a bit hard do describe, hence the short updates. We are working really hard on this. A lot more work is ahead of us and as you can see some of the details are not flattened out yet. Having HC Alpha will allow us adding more people to the effort and we would move faster but also it would provide us with a prototype to test different concepts.
Stay tuned.
7 Likes
Thank you for your answer. I understand.I learned a lot of knowledge
As for the destruction problem, if it is DPOS consensus, AE will not be destroyed even if the Leader does not generate key blocks for packaging after the Leader is successfully elected?
What is the minimum server configuration and initial AE required to become a validation node? There are sure?
6 Likes
Ah, I didn’t dive deep enough. So more details: all of the logic of the consensus is in the smart contract itself. This results in a really versatile design. We don’t think there could be one size fits all type of solution, on the contrary - different use cases would have different requirements. This means that there would be a lot of fundamentally different HyperChains, each having their own smart contract that serves their use case best.
To answer your question - we have a term for a leader that does not generate blocks - we call it a lazy leader. Proving that something had happened or that it exists is easy but proving that something didn’t happen is really hard. For this we could actually rely on the other stakes - if your use case requires punishing a lazy leader, then the stakes could vote on one being lazy. This should be implemented in the smart contract itself, as well as the punishing mechanism. We would provide some basic implementation that is to serve as a reference.
As stated above, each HC would be able to be adjusted according to their user’s needs. What is a validator’s treshhold is one metric that can be adjusted but there is so much more to change if needed. One good example would be the gas cap - every micro block has a limit of 6mln gas that could require to apply all the transactions in it. Let’s have an exchange example - we have an exchange that is a HC. Its network derives its security from the parent chain. It would be completely transparent and trustless network (opposed to the centralised and trustful exchanges at the moment). If the exchange owners expect a high tx throughput, they could set the gas limit to a significantly higher number, so it could handle tens of thousands of transactions a second. This would impact the server requirements 
The keep it as aeternity main net config would have similar expectations for the hardware required to run a node - mostly a decent SSD.
4 Likes
It’s getting delayed without a fixed period of time.
This week we were able to launch the new testnet with two nodes:
- producer: http://13.239.157.207:3013/v2/status
- and syncing node: http://3.105.185.75:3013/v2/status
The next step is the ongoing UI work. That will allow interaction with the staking contract.
On the other front, the team is working on leader validation.
2 Likes
HyperChains Alpha Testnet
We are approaching the launch of our HyperChains Alpha TestNet, and want to describe in some detail what to expect.
HyperChains Alpha
The HyperChains concept aims to secure smaller chains by anchoring them to a larger, demonstrably secure chain. The services derived from the parent chain are mainly:
- Entropy, via the parent chain block hashes
- Checkpointing, where the current state of the child chain can be ‘anchored’ to the parent chain.
On the child chain, some form of Proof-of-Stake consensus would typically be used.
The work so far on Aeternity has involved refactoring of the consensus logic subsystem to support a modular approach to consensus. This allows us to plug in a specialized consensus module at a given height.
A particular consensus plugin for HyperChains utilizes Sophia Smart Contracts: one for leader election, and one for administration of stake delegation and reward payouts. In the HyperChains Alpha version, the implementation simply relies on the entropy in previous blocks as a source of randomness. While this is not as hard to manipulate as entropy derived from a parent chain, it is still quite robust.
At a later stage, we will release one or more parent chain connectors.
The HyperChains Alpha implementation will be launched on a separate testnet. We encourage extensive testing of it, but please be advised that we will reset the contracts and contract states at each new test release.
TestNet User Interface
We are also developing a simple user interface for observing and interacting with the HyperChains Alpha network. We plan to deliver this in stages:
- Show the current and upcoming leaders, as elected by the contract
- Allow staking and show the current stake distribution
- Allow unstaking
Discussion
As we continue working towards full HyperChains, we also want to highlight the potential for using the contract-based consensus for e.g. a permissioned enterprise chain, or potentially for experimentation around different PoS solutions. Given Aeternity’s support for Governance, it will be possible to launch a chain with a very simple PoA contract, then mature into more sophisticated consensus models as the chain grows.
We also want to point out that this should not require expertise in the Erlang implementation of Aeternity: a theoretical understanding of the underlying consensus framework and knowledge of Sophia contract programming should suffice. As the relevant evolution occurs in the contracts, this should also help make the Governance process more inclusive.
9 Likes
Dear, at present, the community is very concerned about the cost of anchoring to the parent chain? How does stacking ensure profitability? @fabiankrol @uwiger
Thanks to the team for their hard work. As we all know, HC has been under development for a long time. Take the liberty to ask, according to the current development progress, when will HC be able to release the official version? Late 2022? Early 2023? Late 2023? We need a rough expectation, just like needing a lighthouse to guide the direction in the vast ocean. thank you all.
@uwiger @fabiankrol @lydia @YaniUnchained
1 Like
How do we test？ 
1 Like
Connectors will be designed to be modular, so that you can choose which chain to use as a parent chain.
There are chains that provide a high level of security e.g. through merge mining on Bitcoin, but still have low fees. If you trust Cardano, Solana or some other chain, those should be able to serve as parent chains. Of course, we also hope to make Aeternity a viable parent chain.
7 Likes
We expect the first version of the front end of Hyperchains Alpha to be available for tests at the end of this week. The current team had started to work on hyperchains some months ago. After extensive tests a final version and whitepaper are to be published this year. Since an enterprise specific consensus can be used now the cost of anchoring to parent bitcoin chain can be paid by the enterprise customer. After several iterations on the architecture and design of hyperchains a general model had been developed which can make the use of hyperchains attractive to new customers with specific projects requirements. We encourage the community and developers to test and share all ideas and suggestions for useful consensus and hyperchains. Thank you very much for supporting the core team and helping us to create the bright future of aeternity!
7 Likes
这个消息振奋人心，希望能如遇而至，白皮书的发布在今年，这个时间线还是挺长的，也希望尽快出来
1 Like
Well, that’s great news.
Of course, we also hope to make Aeternity a viable parent chain.
I don’t see this happening because let me quote @dimitar.chain comment here:
The way I see it, there wont be any more gpu mining after this because those rewards goes to validator for HC. Aeternity can keep the physical mining running if Aeternity mainnet split the reward 50/50 with HC/gpu miner. Don’t tell me you gonna increase Max Supply of token lol. AE holder like me would be pissed 
May I know what the path Aeternity going to take?