Hyperchains Alpha

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 :slight_smile:

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:

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:

  1. Show the current and upcoming leaders, as elected by the contract
  2. Allow staking and show the current stake distribution
  3. 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? :joy:

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 :rofl:

May I know what the path Aeternity going to take?

Dear community,
we created an initial version of the demo UI: https://hc-alpha.aepps.com

This week we’ll focus on adding more details about the chain and the node.
Another primary task is the ability to stake and unstake :raised_hands:

Later today, we will post a longer write-up about the new HC alpha node release.

2 Likes

The fee and reward structure of course needs to be adapted to any viable scenario.

The main requirement on whichever chain is selected as parent chain is that it can serve as a robust source of entropy. Given that the AE Mainnet is currently PoW, and the total mining power is pretty low, it’s a questionable choice as a parent chain, except for proof-of-concept testing, where its high performance and very low fees are quite attractive.

EDIT: The above comment was mainly about specific attack vectors for HC parent chains. We have added protections against double-spent attacks against the Mainnet, effectively preventing the type of attacks AE suffered in the past, but these do not necessarily help protect against some potential short-range attacks that might affect HC specifically.

There are different ways to strengthen the AE Mainnet. One would of course be to attract more mining power. Another would be to morph it into a robust PoS chain, or a hybrid PoS/PoW, perhaps. Another would be to anchor it to e.g. Bitcoin as a HC childchain. Using BTC as a parent chain would be safe, but expensive, so smaller chains might not want to do this. But anther chain anchored to BTC would be a robust, and probably much cheaper parent chain for other HC chains.

From a Core Team perspective, we are gradually making the consensus architecture more modular, so that different routes become technically possible. This is partly because consensus changes are ultimately a community decision, and will hinge on challenges, opportunities and incentive structures beyond the Core Team’s control, but also partly because all known blockchain consensus protocols are flawed, and the best thing we as developers can do is to allow adopters to pick their poison, so to speak, in the least risky way possible. This goes not just for the AE Mainnet, but also for any future enterprise chains or HC chains using the Aeternity code base.

4 Likes

Let’s have a parent chain AE and a child chain that we will call CAE (ChildAE). The AE main net would still be mining and the inflation curve would be the same as it is now. The child chain would have its own coin and would have its own inflation curve. It would be independent of the AE main net. The child chain would be printing its own CAEs and would be a PoS. It would not have any miners only stakers. It would be posting transactions on the AE main net and would be paying their fees in AE.

This means any service can spawn their own network with their own coins, inflation curve (if any) and would be paying for its security in AE on AE main net :slight_smile:

4 Likes

HC Alpha release

We are happy to announce that the HC Alpha testnet is released!

Introduction

We currently have 2 nodes:

curl -s http://3.105.185.75:3013/v3/status | jq .

and

curl -s http://13.239.157.207:3013/v3/status | jq .

One of them is producing blocks, the other is syncing. You can easily join the testnet and sync as well. For that, see below.

The HC Alpha is up and running. Blocks are being produced by the appropriate leaders. Those are elected in the smart contract. Rewards are being redistributed according to the smart contract. New staking validators can be created, anyone can stake or unstake (if you have coins, see below). Both keyblocks and microblocks are being signed by the appropriate leaders and this is being validated by syncing nodes.

At this point we have a prototype of a PoS blockchain that is being ruled by a smart contract. Anyone can spawn their own chain with their own unique conensus rules. You don’t need to know Erlang to do so, you only need to be able to write Sophia contracts.

This is the basis that we will build on top in order to achieve HyperChains. It took a lot of effort to get where we are now. What is more - a lot of work still lies ahead of us. Having HyperChains Alpha would allow us to redistribute the work to more people so we can be moving faster.

How to join

The node

There is a special release that you can download and run. If you want to - you can compile the source code. Please note that this is not the master branch. HyperChains still live in a branch of their own (hc_alpha) that is yet to be merged into master. The latest release will not work, you need to get the special release from the link above.

Config

The HC Alpha has its own special config. A default one looks like this:

chain:
    consensus:
        '0':
            config:
                calls:
                -   abi_version: 3
                    amount: 1000000000000000000000
                    call_data: cb_KxFuGm1JPyDWziI=
                    caller: ak_2MGLPW2CHTDXJhqFJezqSwYSNwbZokSKkG7wSbGtVmeyjGfHtm
                    contract_pubkey: ct_LRbi65kmLtE7YMkG6mvG5TxAXTsPJDZjAtsPuaXtRyPA7gnfJ
                    fee: 1000000000000000
                    gas: 1000000
                    gas_price: 1000000000
                    nonce: 1
                -   abi_version: 3
                    amount: 1000000000000000000000
                    call_data: cb_KxFuGm1JPyDWziI=
                    caller: ak_nQpnNuBPQwibGpSJmjAah6r3ktAB7pG9JHuaGWHgLKxaKqEvC
                    contract_pubkey: ct_LRbi65kmLtE7YMkG6mvG5TxAXTsPJDZjAtsPuaXtRyPA7gnfJ
                    fee: 1000000000000000
                    gas: 1000000
                    gas_price: 1000000000
                    nonce: 1
                -   abi_version: 3
                    amount: 0
                    call_data: cb_KxHmZidJP7W4jFY=
                    caller: ak_2MGLPW2CHTDXJhqFJezqSwYSNwbZokSKkG7wSbGtVmeyjGfHtm
                    contract_pubkey: ct_LRbi65kmLtE7YMkG6mvG5TxAXTsPJDZjAtsPuaXtRyPA7gnfJ
                    fee: 1000000000000000
                    gas: 1000000
                    gas_price: 1000000000
                    nonce: 2
                -   abi_version: 3
                    amount: 0
                    call_data: cb_KxHmZidJP7W4jFY=
                    caller: ak_nQpnNuBPQwibGpSJmjAah6r3ktAB7pG9JHuaGWHgLKxaKqEvC
                    contract_pubkey: ct_LRbi65kmLtE7YMkG6mvG5TxAXTsPJDZjAtsPuaXtRyPA7gnfJ
                    fee: 1000000000000000
                    gas: 1000000
                    gas_price: 1000000000
                    nonce: 2
                -   abi_version: 3
                    amount: 1000000000000000000000
                    call_data: cb_KxFuGm1JPyDWziI=
                    caller: ak_2KAcA2Pp1nrR8Wkt3FtCkReGzAi8vJ9Snxa4PcmrthVx8AhPe8
                    contract_pubkey: ct_LRbi65kmLtE7YMkG6mvG5TxAXTsPJDZjAtsPuaXtRyPA7gnfJ
                    fee: 1000000000000000
                    gas: 1000000
                    gas_price: 1000000000
                    nonce: 1
                consensus_contract: ct_LRbi65kmLtE7YMkG6mvG5TxAXTsPJDZjAtsPuaXtRyPA7gnfJ
                contract_owner: ak_11111111111111111111111111111115rHyByZ
                contracts:
                -   abi_version: 3
                    amount: 0
                    call_data: cb_KxFE1kQfG58AoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqXepHQw==
                    code: cb_+QKRRgOgKxRFIonHw2b00MtV1VFfVfnD2QGDOcetap/BIocR6zPAuQJjuQHS/g3YEMwENwA3AFUAICCCBwwE+wOBT25seSBhbGxvd2VkIHRocm91Z2ggTWFpblN0YWtpbmcBAz/+PR6JaAA3ADcDRwBnRwAHBwwCggwChAwChicMBgD+RNZEHwA3AUcANwAaDoQvABoGggAaDoYAAQM//lrbON4ENwFHADcAVQAgIIIHDAT7A4FPbmx5IGFsbG93ZWQgdGhyb3VnaCBNYWluU3Rha2luZwsAHzAABwwI+wNFU3Rha2UgbXVzdCBiZSA+IDALAAIDEVsUB7kPAgoMAgoMAQACAxHUzSn4DwJvgibPFCqGhgoBAz/+WxQHuQI3AQcHIDiGAAcMBBoKBIZTABUQABYkAAQXAAABAQD+gjZJAQA3AkcABwdVACAgggcMBPsDgU9ubHkgYWxsb3dlZCB0aHJvdWdoIE1haW5TdGFraW5nGgoGhCzaCAYAACIYCAIHDAj7A0VOb3QgZW5vdWdoIHNoYXJlcxoKDoZTABYEAhciEA5lCQAQFRoUCAIgOBQABwwOFRqGhgItmoSEABQMAz8GAwwPAm+CJs8BAhAVGoaGAi4ahIQADAM/BgMM/tTNKfgCNwJHAAc3ACzaBoQAABQYBgItGoSEAAEDP7iJLwcRDdgQzBlwcm9maXQRPR6JaCVnZXRfc3RhdGURRNZEHxFpbml0EVrbON4Vc3Rha2URWxQHuYkuU3Rha2luZ1ZhbGlkYXRvci5jYWxjdWxhdGVfc2hhcmVzEYI2SQEddW5zdGFrZRHUzSn4cS5TdGFraW5nVmFsaWRhdG9yLmFkZF9zaGFyZXOCLwCFNy4wLjAA8DZ7EA==
                    nonce: 1
                    owner_pubkey: ak_11111111111111111111111111111115rHyByZ
                    pubkey: ct_KJgjAXMtRF68AbT5A2aC9fTk8PA4WFv26cFSY27fXs6FtYQHK
                    vm_version: 8
                -   abi_version: 3
                    amount: 0
                    call_data: cb_KxFE1kQfK58CoCmQRGuzLDSzySG/5UcFOdoQ1iYy6a6fhJXVahjufrESFWRvbWF0f5V9Nw==
                    code: cb_+QyLRgOgTOfU7DyN1cZmgtfUa3jk7qW2EZAbRCeBIHFA5zy90bPAuQxduQnH/gfOsjICNwInNwLnADcCRwIHB4cCNwA3AecAMwQABwwINQYAADYGAgAoLgQAACguBgIAKCwCBh8QAgcMBigsAgYVBQICGgkAAgYDAAwCBET8IwACAgIAAQOvggABAD/+D8HMmgA3ACc3AkcABxoKAIQyCAAMAysRqp+U+z8EAxFodtbf/hN32AYCNwIn5wAn5wAn5wAzBAAHDAQ1BgAANgUAADQZAgACBgMAAQEC/hniRPMCNwFHADcCRwIHDAEAAgMRLCYHHgg8BAYrGIQAACsYhgAA/ia0rRACNwEn5wAn5wAMAwMMAQAEAxETd9gG/iwmBx4CNwFHAIcCNwA3AC8YhAAHDAgvGIYABwwG+wNVVmFsaWRhdG9yIG11c3QgZXhpc3RzAQOvggAAAT8BA6+CAAAAP/5DDIOYAjcANwB9AFUAIAAHDAT7A3lNdXN0IGJlIGNhbGxlZCBieSB0aGUgcHJvdG9jb2wBAz/+RNZEHwA3AkcCdzcAGg6ELwAaDoYvABwGigJeAowaBoIAGg6IAAEDP/5G5LLNAjcENwJ39+cAJ+cAJ+cAJyfnADMEBgcMDjUGAAY2BgIGDAECDAIAKBwCACgcAAACAAcMCDQVBAIEGgkCABoJBgIGAwA0KAACDAEAAgMRidwMPzQUAgQCAxEmtK0QNAAADAMDNBQCBAIDESa0rRA0AAD+VfilEAI3AjcCd/cnJ+cAJyfnADMEAgcMDDUGAAI2BgICMwgCBwwMBgMGNggCDAEAAgMRVfilEDUIAgwCAAwBAAIDEdv4HGw0AAABAQL+Wts43gQ3AUcANwALACIwb4iKxyMEief/wAcMBPsDdU11c3Qgc3Rha2UgdGhlIG1pbmltdW0gYW1vdW50DAEAAgMRLCYHHgg8CAwaCgaEKxoIBgBVAAsAKCwACAMA/BFa2zjeNwFHADcADwJvgibPGgoSiAsAFAoYEiguGgIICwAUChwaKawCCBwtGoSEABoKiBgBAz8aCgaGKxoIBgBVAAsAKCwACAMA/BFa2zjeNwFHADcADwJvgibPKC4YAggLABQKGhgprAIIGi0ahoYAAQM//mh14NEANwBHAFkAEAQDEYB1oMf+aHbW3wI3AjcCd/cn5wAn5wEzBAIHDAg2BAIMAQACAxFodtbfNQQCKBwCACgcAAACADkAAAEDA/5uGm1JBDcARwILACIwb4k2Ncmtxd6f/8AHDAT7A3VNdXN0IHN0YWtlIHRoZSBtaW5pbXVtIGFtb3VudF4ADAN/DAMADAM3AUcADAKCpAAPAgRVAAsADAIEAwD8EVrbON43AUcANwAPAm+CJs8MAgQLACcMBFUALQqGhgECBP6AdaDHADcBB0cAGgoAhDIIAAwDKxGWvHa1PwIDEfwIDR0PAgAaCgKIGgoEij8IBBYQABggAgwCAAIDEQfOsjIPAgYIPgYGCPsDMU5PIENBTkRJREFURUY4BgAA/oI2SQEANwJHAAcHDAEAAgMRLCYHHgg8BAgaCgKEKxoEAgAMAQJVAAwDACgsAAQDAPwRgjZJATcCRwAHBw8CBhoKDogLABUKFA4oLhYCBBUqGBYGKawCBBgtGoSEABoKiBQBAgYaCgKGKxoEAgAMAQJVAAwDACgsAAQDAPwRgjZJATcCRwAHBw8CBiguFAIEFSoWFAYprAIEFi0ahoYAAQIG/oncDD8CNwI3Anf3J+cAJyfnADMEAgcMDjUGAAI2BgICMwgCBwwOBgMGNQoEAjYKBgIMAgAMAgQoHAIAKBwAAAIABwwMDAIGNDgAAwwCBAwBAAQDEUbkss0MAgY0OAADDAIEDAEABAMR7uAJiDQ0AgMA/o3sy98CNwI3Anf3JyfnACfnADMEAgcMBjUGAAI2BgICMwgCBwwKBgMGDAECDAEAAgMRVfilEA8BAgYDAAECAP6WvHa1AjcD9/f39wwBBAwBAgQDEeOzccP+lyifYQA3ACc3AkcABxoKAIYyCAAMAysRskuyMD8EAxFodtbf/qQ8zFQANwBHAAECjP6lGrHCBDcBRwA3AAwBAAIDESwmBx4IPAQIGgoChCsaBAIACwAoLAAEAwD8EQ3YEMw3ADcADwJvgibPGgoOiAsAFAoUDiguFgIECwAUChgWKawCBBgtGoSEABoKiBQBAz8aCgKGKxoEAgALACgsAAQDAPwRDdgQzDcANwAPAm+CJs8oLhQCBAsAFAoWFCmsAgQWLRqGhgABAz/+qp+U+wI3Avf39ygeAgICDAMDKBwAAigsAgInDAQ0AAD+skuyMAI3Avf39ygeAgICDAMDKBwAAigsAgInDAQ0AAD+tIwWhAA3AUcABwwBAAIDERniRPMPAgAoLAIAAP7NPVq4ADcANwACAxFDDIOYDwJvgibPWQACAxGAdaDHDwKMAQM//tnn19UANwFHADcDRwBnRwAHBwwBAAIDESwmBx4IPAQIGgoChCsaBAIADAMAKCwABAMA/BE9HoloNwA3A0cAZ0cABwcAGgoChisaBAIADAMAKCwABAMA/BE9HoloNwA3A0cAZ0cABwcA/tv4HGwCNwM3Anf3J+cAJ+cAJ+cAMwQCBwwYNQYAAjYGAgIzBAQHDBIGAwY1BgQENgYGBAwCBAwCACgcAgAoHAAAAgAHDA4MAgY0KAACDAEAAgMR2/gcbDQIBAA0KAQGDAICDAEAAgMR2/gcbDQIAAAzBAQHDBb7A01JbmNvbXBsZXRlIHBhdHRlcm5zAQECAQEE/uOzccMCNwI3AkcANwJHAgc3AkcANwJHAgcXKB4AAAAoHgICACgeBAACKB4GAgIoLAIGKCwCAiAABwwEKCwCBigsAgIeAAAeKAAEAP7lveq2ADcANwAMA6+CAAAAP1UAAgMRLCYHHiAABwwG+wNRVmFsaWRhdG9yIG5vdCBvbmxpbmUaCgSEVQArCgYEGgoMhhoKDogoLAIGFQoUDlUALYoWDAZVAC4KhIQaCoYWGgqIFAEDP/7mZidJADcANwAMA6+CAAABP1UAAgMRLCYHHiAABwwG+wNVVmFsaWRhdG9yIG5vdCBvZmZsaW5lGgoEhlUAKwoGBBoKDIYaCg6IKCwCBhQKFA5VAC4KFgxVAC2KhIQGGgqGFhoKiBQBAz/+7uAJiAI3BDcCd/fnACfnACfnACcn5wAzBAYHDAw1BgAGNgYCBgwCAAwBAigcAgAoHAAAAgAHDAg0FQQCBBoJAgAaCQYCBgMANCgAAgwBAAIDEYncDD80FAIENAAANBQCBDQwAwD+/AgNHQI3AjcCd/cn5wAn5wAzBAIHDAgGAwQMAQIMAQACAxGJ3Aw/DAEABAMRjezL3wEDA7kCjS8hEQfOsjJtLk1haW5TdGFraW5nLmZpbmRfdmFsaWRhdG9yEQ/BzJpFb25saW5lX3ZhbGlkYXRvcnMRE3fYBjkuTGlzdC5yZXZlcnNlXxEZ4kTzaS5NYWluU3Rha2luZy5nZXRfdmFsaWRhdG9yESa0rRA1Lkxpc3QucmV2ZXJzZREsJgcedS5NYWluU3Rha2luZy52YWxpZGF0b3JfYnVja2V0EUMMg5iFLk1haW5TdGFraW5nLmFzc2VydF9wcm90b2NvbF9jYWxsEUTWRB8RaW5pdBFG5LLNJS5MaXN0LmFzYxFV+KUQRS5MaXN0Lm1lcmdlX3BhaXJzEVrbON4Vc3Rha2URaHXg0SllbGVjdF9uZXh0EWh21t9ZLkxpc3RJbnRlcm5hbC5mbGF0X21hcBFuGm1JNW5ld192YWxpZGF0b3IRgHWgxz1lbGVjdF9hdF9oZWlnaHQRgjZJAR11bnN0YWtlEYncDD9RLkxpc3QubW9ub3RvbmljX3N1YnMRjezL3z0uTGlzdC5tZXJnZV9hbGwRlrx2tRkuXjEyNzYRlyifYUlvZmZsaW5lX3ZhbGlkYXRvcnMRpDzMVBlsZWFkZXIRpRqxwhlyZXdhcmQRqp+U+xkuXjEyNzgRskuyMBkuXjEyNzcRtIwWhB1iYWxhbmNlEc09WrgVZWxlY3QR2efX1U1nZXRfdmFsaWRhdG9yX3N0YXRlEdv4HGwtLkxpc3QubWVyZ2UR47Nxw2kuTWFpblN0YWtpbmcudmFsaWRhdG9yX2NtcBHlveq2LXNldF9vZmZsaW5lEeZmJ0kpc2V0X29ubGluZRHu4AmIKS5MaXN0LmRlc2MR/AgNHSkuTGlzdC5zb3J0gi8AhTcuMC4wAKKRRys=
                    nonce: 2
                    owner_pubkey: ak_11111111111111111111111111111115rHyByZ
                    pubkey: ct_LRbi65kmLtE7YMkG6mvG5TxAXTsPJDZjAtsPuaXtRyPA7gnfJ
                    vm_version: 8
                expected_key_block_rate: 180000
                stakers: []
            name: smart_contract
    db_path: ./db-path
    hard_forks:
        '6': 0
    persist: true
fork_management:
    network_id: ae_smart_contract_test
http:
    external:
        port: 3013
    internal:
        port: 3113
include_default_peers: false
keys:
    dir: keys
    peer_password: secret
peers:
- aenode://pp_2abigQ2fewdAH2eMMDReP4q13uYdsjXhjM1Qvs4xUn29auo8Hs@13.239.157.207:3015
sync:
    port: 3015

Some of the settings above are mandatorary so please be careful changing them. For example the chain section above must not be changed. It creates the two consensus smart contracts in the genesis block. It also creates 2 staking validators using contract calls. This seeds the initial state of the blockchain. Without those, there will be noone to produce block 1. Changing those would likely result in a different genesis block, so please do not change anything in chain section.

Another magical setting is the network ID. It must be ae_smart_contract_test. All transactions must be signed this network ID as well. hard_forks section must not be changed as well, also the include_default_peers would not help you anyhow. You need a peer so please keep the one provided. Please do not provide a beneficiary - since your node will not be producing key blocks and you don’t need it. There is a known bug in hc_alpha that plays bad with beneficiary. This will be fixed ASAP.

Feel free adapting the network settings as you see fit: ports, endpoints and so on. You can both persist the chain on disk, define your own path where it would live and so on. This has nothing to do with conensus anyway.

Once set up, you can join the testnet: your node will sync.

What is missing

Ok, we have HC Alpha but what is still left to do? Let’s split the tasks in 2 sections - short term tasks and long term goals. Those are listed in no specific order.

We plan on continuing aggressive development and delivering some backwards incompatible changes when we need to. This means that every new release will bring something that would break existing consensus. That’s why we can not keep the old exsisting DB but rather we will delete it and start from genesis. We do still want to keep your contributions in place, so we will keep the consensus smart contracts’ states. Any stake you had made in one development cycle would be put in the genesis of the next one. Any other balances, contracts, names and so on will be lost.

Short term

Our goal was moving fast and breaking things. We had left a lot of TODOs. A huge part of the work on HC Alpha was scoping what shall be changed, what shall be refactored, what piece we are missing and so on. It had been an exploritory endevour. Now we must fill the missing pieces. Some of those are small tasks, some are more of an ongoing process (like writing test coverage).

  • rebase hc_alpha on top of latest master and merge - the HC Alpha branch had divered from our main branch some time ago, it must be rebased and merged. This will allow us to have one release that would be working both for main net and HCs. For this we would need to test heavily the HC code for backwards compatibility, and yes - make a full sync. We don’t want to break main net, right?

  • config must be simplified - as you had already seen above - there are a lot of magic settings in the config. With the exception of the network ID, changing the config should not result in a significantly different and incompatible chain. The config shall be cleaned up and reduced to a single protocol config. The smart contract creates and calls for the genesis block shall be moved in an external file and so on.

  • difficulty - currently the difficulty is not being changed. This will be done in the smart contract itself, using smart contract calls. Every staking validator would be allowed to support a fork and get a corresponding reward for it.

  • voting for missing leaders - similarly to the previous bullet point - if a leader is being elected but not producing keyblock - what shall we do? Shall we accept the next one in line instead? How would the network support or reject this? This is not a trivial question, we plan on pushing the responsibility to the ones that have skin in the game to decide - the staking validators. This means that they would be able to support a validator that is not elected as a leader if they want to. It would not be any validator, of course. The logic for this would be in the smart contract itself but the detection would happen in Erlang code. This is going to be a big and bloody task.

  • delegates participation - it is a DPOS, so we would like to invite you to join the testnet as delegates. We will provide whoever wants to with some HC-Alpha-testnet-coins (suggestions for a better name are welcome). The UI will allow you to stake and support a staking validator of your choise. You will be able to see how your stake grows with time, then unstake, stake again for a different staker and so on. The details of this would be provided shortly.

  • expand the network - currently we have two nodes and only one of them is producing blocks. We shall expand the setup to more nodes, esp. block producing ones. We would likely have a node dedicated to the UI as well. This is yet to be determined.

  • improve the contracts - we aim at providing great UX. For this we will provide some swag for the contracts. We will let the staking validator define some meta data that would describe their service - name, description, image and so on. We would also put some limits in place - ex. at the moment any staking validator can withdraw all of their stake and still be a staking validator (having only the delegated stake)

  • test, test, test :slight_smile:

Long term

We could start working on parent-chain connectors now. There are still some open questions with regards of who posts a commitment and when they do so, but this is not a blocker. On the contrary - having a working prototype could actually help nailing the details.

4 Likes

Sorry, I’m still not clear. If AE mainnet is still active and HC is anchored to AE mainnet; isn’t 2 different chain would exist at the same time?

1 Like

It’s quite possible to run tons of different chains using the Aeternity code base.
The network ID, node addresses etc. are all configurable.

3 Likes