Hyperchains Alpha

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

Dimitar uses AE-mainnet as an example of what’s technically possible. In this example, BTC/ETH/… networks can be used for the “parent chain” as well.
It doesn’t mean we’re planning to anchor our HC net to AE-mainnet.

We’re not planning to release a new coin.

2 Likes

Take back your hypothetical situation! As a developer, please speak more carefully! Would you please explain if there are any new coins? Is our five-year trust and company like a dog@ Noyyy, please explain!

hyperchain is so cool;Thanks to the team developers for their appreciated and exciting work。The other team had said long ago that they wouldn’t issue new tokens.hyperchain is also a part of aeternity 。using hyperchain requires ae

2 Likes

I am afraid you completely miss the point here. You know how ERC20 had empowered people to develop new business usecases? Well HC are that on steroids. It allows everyone to spawn their own network with their own coins. We are not issuing new coins, users are. What is more - they can tweak the consensus as they see fit. You need more gas in micro blocks? Go for it. You need keyblocks being issued more often - great, it is just a setting. You want to have a use-case specific consensus? You write a Sophia smart contract for it. You get all the AE tools working out of the box.

Imagine hypothetical air carrier Companies A, B and C. They want to go crypto. They spawn a HC of their own, adjusted for their needs. They sell tickets, define rules for whoever can use their services and so on. They keep being independent companies that do not trust each other, on the contrary — all business is tamperproof and transparent.

You can do that as well at the moment. You can fork the repo and do whatever you need with it. If it is still a PoW - you need to convince enough miners to support your network. Hyperchains offers an alternative for this: there is a parent chain that is either PoW or another HC, there is also a child chain. Through a process unique for AE, the child chain derives its security from the parent chain. There are still miners but they are on the parent chain. Everyone else reuses their work and pays for it with fees on the parent chain. This scales extremely well and could fit all types of scenarios.

So we are not creating a new coin, we are providing new tools for business to build on top of AE. The goal is a decentralised and free future.

6 Likes

Dear @wangqiyong, I do not understand your confidence on what aeternity needs and not needs. Good architecture with reusable components and services is crucial for any strategic blockchain. Blockchains who attempt to move unsolvable problems from first layer to the second and third layers are from an architectural point not well designed and not useful in long term. From my long experience (more than 35 years ) in computer science I can only state that a solid architecture is the base requirement for any long term successful software project. Aeternity has a good architecture and is on the way to make it one of the best blockchain architectures. @dimitar.chain has delivered excellent research, design and source code and we all appreciate his work on hyperchains. Concerning your comments above I want to share the following: You can see the aeternity general architecture as if you have a car factory in which you can build any car (tesla, bmw, mercedes, etc.), but you insist to produce just Russian Lada because it is the only car you know and want to use. If you are not satisfied please make sure to use a civilized way and arguments to discuss.

8 Likes

I still don’t understand because I kept imagining about current AE main net (chain 1) and HC (chain 2) that anchored to AE/BTC/LTC. Both can can issue AE at same time.

Hopefully somebody can draw a diagram next time.

I also apologize for the way some user responds to developer.

1 Like

How do I get test coins and become a verifier? So far I have it up and running on Linux, But I can’t mine, it feels like I’m just synchronizing nodes

Hyperchains is a tech to scale on-chain transactions on blockchains. Everyone should be able to launch a hyperchain in the future.

Every hyperchain will probably have its own coin. If things go well, the current aeternity mainnnet will be forked after a governance decision into æternity PoW/classic and æternity PoS/hyperchains (secured by the Bitcoin blockchain). Then, æternity PoW and PoS can each have many hyperchains. If things go well, there will be also a native Bitcoin hyperchain which will have BTC as its native currency via a bridge, similarly to Rootstock. Analogously, this can happen to Ethereum and any other blockchain or hyperchain too.

3 Likes

Hello, according to what you said, HC is a separate chain, so is the AE chain still Pow? Having experienced a double-spend attack, everyone has lost confidence in AE ‘s security. It is very difficult to regain confidence. If nothing changes, I don’t think it has any advantages.
In addition, according to the early publicity, I always thought that the AE chain would be converted to Pos and linked to a more secure Pow chain (BTC), but after carefully reading your replies, I found that this is not the case.
I’m a software engineer, but not blockchain oriented, so I don’t know the specific technical details very well, but from my point of view, the point is as above.

1 Like

æternity hyperchains/PoS will be hooked into the Bitcoin blockchain (most secure), thus it will contain also an PoW-element. To initiate this fork decision needs to be done via governance vote after hyperchains development has been completed. There will be two aeternity blockchains afterwards: aeternity classic/PoW and æternity hyperchains/PoS. Hope this answers your question.

4 Likes

Dear, will the core team continue to maintain aeternity POW after the launch of hyperchain? Both are our children. I hope to love them well.

Yes. Thank you. My understanding is not wrong. hyperchains/PoS will be the main chain that issue AE coin. Classic PoW chain will issue AEC (AE classic)