My thought was that it would basically be the same kind of contention situation as if two miners produce keyblock candidates at roughly the same time on the parent chain. The difference would be that in this case, we can deterministically decide which keyblock wins, so nodes should prioritize that fork from the start.
But it would be an optimization favoring more frequent leader changes at the cost of slightly more frequent forks. The alternative would be an empty period, where the previous leader keeps producing microblocks.
Yes, the ‘parent chain’ will induce forks in the ‘child chain’ but I think it is a safe assumption to rely on the eventual consistency of the ‘parent chain’. Bottom line is: we can consider it a source of truth regarding:
- who committed what and when
- entropy
1 Like
@dimitar.chain
have you guys read the white paper of Harmony and Matic ?
They have similar approach. Matic is built on ethereum and harmony is a seperate chain itself
1 Like
Hi @Vikram,
No I wasn’t aware of those. I will take a look, thanks!
1 Like
So I’ve looked at both projects
Is a PoS with sharding. This by itself is cool but having the Effective PoS makes it better.
Is a means of creating sidechains on ETH: you lock your tokens in a contract and those are locked in the side chain. Side chain posts regular checkpoints on main chain.
What we propose building is quite different from both above. The idea is a hybrid consesus process that solves issues that PoS and PoW approaches have.
What is different from the Harmony’s apporach is it will have all the security of the parentt chain even if it is a really small hyperchain with a few dozen users. So you get the security of PoW in a PoS consesus.
What is different from the Matic is that the parent chain is completely unaware that there is a child chain. It only sees a few transactions flying in and does not know the meaning of those or to which child chain they are stakes, if they are stakes for a child chain at all. You don’t lock tokens, you don’t call contracts on parent chain. This makes it much much harder for miners to filter out your transactions. What is more - they only checkpoint on the ETH chain, otherwise they’re PoS. The idea behind hyperchains is to use the parent chain as a source of truth for the election process: so it is not a PoS but rather a hybrid.
2 Likes
Waaow this is super cool! @dimitar.chain, Like the mainchain not knowing what’s exactly happening on side chain is cool! . Does this means I can have staking nodes on my Hyperchains? or ill be relying on the Aeternity main nodes for consensus ?
I just wanted you guys to look on these new projects so while in development we dont miss out on something 
1 Like
Actually both You do get to have your staking nodes in your Hyperchain. Who is to be elected leader though depends on a source of entropy that comes from the parent chain - the Aeternity main chain. So you might have your staking nodes that ask mainnet nodes for blocks.
1 Like
Is this work already started?
Like we (@hypermine) don’t want to do the same work if you guys have already done lot of advancement.
So for next two/three months we will focus on our business case and tech feature requirement. And we can piggy back to you guys for the network development.
This will help both of us, Like in theory and white paper you will have a real world use-case on Hyperchain and we will be able to release our white paper /token quickly and see whats user’s think about this as a business.
Currently we have a centralised product which uses IBM tool and we are trying to sell it to customers. As we also have to show Ae ventures some paid customer ( 
) .
Personally I have been working with Staking networks so I know what all tooling will be required when you guys launch.
Like staking dashboards, wallets, community etc . I can help in that .
let me know your thoughts on this @dimitar.chain
1 Like
We are actively discussing implementation details and I expect that this is to be started really soon. Yes, I think it would be great working in a collaboration providing both the infrastructure and the toolset required.
1 Like
@hanssv.chain I found this helpful thought ill just keep it here
It talks about the current election process using VRF’s and then propose a different model
What is VRF Algorand's cryptographic sortition - YouTube
Some will say I’m not a fan of hyperchains, but:
“Once a generation is over, child chain nodes gather all commitments posted on the parent chain, they filter out the ones they consider invalid (ex. from non-eligable delegates, ones that commit to erroneous keyblock hash and etc.)“
How are the child chain nodes supposed to
- Have all information necessary to validate a leader candidate’s commitment at the right time
(We know figures about such issues quite well by now) - Let alone be aware of the fact this is the case ? (On
parent chainwe don’t and don’t need to)
Plus:
If nodes decide whom to follow plainly based on a parent chain commitment , the time window in which the electing node has to be perfectly synced with both child chain and parent chain is the timespan between the validator candidate providing a hash he commits on, and the moment he gets elected (Not even taking into account us maybe wanting the commit hash being based on a very recent microblock in the child chain, which makes everything ever more tighter)
The described time period can either be
-
Damn short
Then we probably don’t have all necessary information from either theparent chain,child chainor both, and need to wait until we can be sureif those blocks we get propagated in thechild chaincan be considered of someone we might want to accept as validator. Might this lead to a network split? -
Painfully slow
leader commitment transactions to theparentchainunderly the same mechanisms as any other transaction, at best(!). With all the implications that would have to thechild chain.
Depending on how often we want the leader to be re-elected, there might be “some” congestion on the parent chain…
Also: What implications do we want chain reorgs in the parent chain to have on the affected
- leader elections in child chains
- the blocks produced by those leaders ?
And in the end, let me break a child chain for you:
- Enter a
child chainwith an amount of nodes that makes up >1/3 the estimated amount of participants (from here on first try to guess the rest, people reading papers on consensus algorithms might have smelled it already)
- become a leader
- shortly before the election of a new leader, eclipse the participants (of which all to find out shouldn’t be hard in the
child chain) with different versions of a last microblock signed with the same key - Wait for chaos to evolve, because in the validation of the new leader, whoever it will be, there will be no consensus found among
child chainparticipants.
PoWs validation process prevents this from happening on the parent chain as you can’t produce that many blocks. A chain reorg in the child chain might happen after that, but it is easy to reproduce this repeatedly. Maybe that one expressed belief that it is not proof of stake we are doing here is indeed right, participants really have no stake they must prove to have in this system besides maybe an altruistic one by committing a hash and showing an unbinding wilfulness to play fair in the child chain Proper Proof of Stake on the other side can’t exist without a Proof of Fraud / slashing and other mechanisms disincentivizing bad behaviour.
I hope for the sake of hyperchains that I’m wrong with as much as possible of the above.
Haah this reminds me of the good old days in 2018/19, making core dev’s lives harder by “annoying” Happi, Tobias, @hanssv.chain and the rest by poking them with annoying-but-necessary, finger-in-the-wound-laying and-what-about-that remarks 
It will definitely be an interesting and challenging job to figure all those issues out (and the ones we havn’t thought of so far).
1 Like
Basically, it should be more similar to Lamport’s Happened-Before relation, in the sense that the point of election (assuming for now a Bitcoin-NG-style parent chain) is the latest key block, and the commitments are found in the preceding generation of microblocks. The election based on the entropy provided by the new key block and the now closed generation-set of commitments should be deterministic, and the winner produces a key block on the child chain with the ‘election key block hash’ included. Validation of that block is done by checking the commitments (hopefully already cached) and the key block hash on the parent chain.
This of course doesn’t force the new leader to follow the latest microblock on the child chain. OTOH, the Aeternity chain relies on incentives to make the new leader pick the latest microblock for its block candidate. In the case of the AE chain, this is actually a more costly proposition, since a new puzzle has to be solved for each new block candidate. In the case of a HC child chain, the new leader would simply pick the latest seen microblock and craft its key block from there. There is little benefit to picking an earlier microblock. There may of course be a race where the last microblock produced has not yet reached the new leder at election time, but this would be a typical micro-fork just as we see happening now and then on the AE main chain.
This is, if I understood you correctly, actually a scenario that’s described in the Cardano research, and they have a model where they observe that a competing fork will be less dense than the main fork. Quoting from the article “How safe is Cardano?”:
To solve the bootstrapping problem, a new chain selection rule called the ‘Plenitude Rule’ is proposed in Ouroboros Genesis. While the mathematical proofs that are described in the 64-paged paper are difficult to grasp for non-cryptographers (although this video by Aggelos Kiayias, one of the authors, might help), the authors show that adversarial blockchains in Ouroboros exhibit a less dense block distribution after the point where they diverge from other versions of the chain. Simply put; the attacker’s chain will contain less blocks in the time period shortly after the divergence point, despite it potentially containing more blocks altogether and being the longest chain.
I don’t think we need 64 pages whitepapers here. I think it’s sensible to assume that someone who has 30% or more of the voting power will not do things which are in conflict with the other 70%, otherwise they will fork off and he will end up with 100% of worthless coins.
1 Like
The commitments on the parent chain should also be anchored to the latest top on the child chain, such that the new leader will have no choice but to follow the top.
… Hmm… it basically works out that way, given that each leader must reference the “election hash” - a key block on the parent chain. The key block header (on the child chain), also references the previous key block, which in its turn references the corresponding election hash on the parent chain. The previous key block can also be derived from each commitment, since a valid commitment needs to refer to the then latest top on the child chain.
So it would seem as if we are actually protected from this. But please correct me if I missed something.
1 Like
someone who has 30% or more of the voting power will not do things which are in conflict with the other 70%
This attack scenario is not about voting power, but node counts. Unless we come up with a yet-to-be invented way of deciding which of the gossiped chains to believe in (classical mechanisms of the PoW parent chain of course can’t be applied here) we listen to the majority. Ans as described in the Lamport/Shostack/Pease BFT paper, the system collapses at >1/3 of fraudulent gossip nodes.
PoW still exists in the parent chain and gets utilized so that certain PoS attacks become impossible. Node count isn’t really very relevant here.
1 Like
PoW helps only in electing a leader. I f that leader spreads multiple versions of a microblock in the child chain which per se satisfy the criteria of validity (which is cheap to achieve for endless versions of a block, unlike in PoW), how are the nodes going to know which one to apply @YaniUnchained ? It is formally proven (bottom of page 4: https://people.eecs.berkeley.edu/~luca/cs174/byzantine.pdf ) that in a system of equally worth messages in a majority vote scenario a consensus cannot be found if 1/3 of the nodes are traitors.
You are in a room with 3 advisors and know max. one is lying. That means two are telling you the truth and you know what the truth is, because it’s being told by two people, the majority. (Traitors: <1/3 )
If you are in a room with two advisors, and one lies to you, you can’t tell who tells you the truth. (Traitors: 1/3)
So now one account is a leader, and floods the childchain with various cryptographically valid blocks at the end of a generation by using a lot of nodes. To which of them is the new leader supposed to commit ? Plus this can be targeted so well (as it’s easy to find out all child chain nodes) that to one single node there could be connected to 50%, 60% or more percent of fraudulent nodes, confusing it with all exact the same version of a variety of fraudulent but formally valid blocks. This node will then definitely believe these 10 nodes that tell it fraudulent block data. It’s a classic eclipse attack.
It’s a general problem with Bitcoin-NG-type solutions that the Leader can choose to disregard the microblocks of the previous leader, create no microblocks, or create a tree of weird microblock forks. The point of resolution is that a new leader will eventually be elected, and this leader can choose to ignore the confusion caused by the previous leader, simply pick one of the microblock forks created and run with it, etc.
The contribution of the HC solution should be that elections themselves are much harder to game, since the parent chain main fork is the reference for past and ongoing elections.