Yes, if we simply limit the commitement taken into account to just one - this kicks the stake grinding out of the window for good.
1 Like
I think I’ve identified an issue.
We have 5 delegates: Alice, Bob, Carol, Dave and Erik. Alice is the leader and she has to produce a (in the context of BitcoinNG) keyblock which hash then the new commitments will be based upon. Alice is malicious and produces not one but 3 different keyblocks with different hashes (1). Different delegates receive different keyblocks and start producing different commitments on the parent chain. This effectively splits the network.
Suggestion: issue arrises from the fact that the keyblock (hash) might not be deterministic so let’s make it deterministic. It might include a hash of the transaction in the parrent chain that includes the commitment. If there are a couple of transactions from the same delegate on the parent chain with the same commitment, then only the last one is being used. It could also include the blockhash being used a source of entropy. In the context of a BitcoinNG that would be the newly mined keyblock in the parent chain and in the case of traditional chain of blocks that would be the block that includes the transaction).
1 Like
So there is no gossip in this new chain? Otherwise the other delegates should quickly see that Alice is malicious and discard the whole generation?!
Also, why base your commitment on the last key-block, that is just begging for problems. You aren’t planning on having a commitment per delegate per generation I hope, that will not scale 
Then there is a network split on top of that and Bob does not see the network as Carol does.
It doesn’t scale well yes, but currently that is the idea.
1 Like
Interesting… What happens if the parent chain is so busy (or just produces a very short generation) that no commitment makes it into a generation?
I guess this also limits a bit which chains can be used as the parent chain, Etherum will be too expensive (and too fast?), Bitcoin will also be borderline I guess…
Reading the Ouroboros Praos paper, I am trying to identify potential issues that we should describe. Some improvements they made from the original algorithm were:
- Empty slots: some ‘election periods’ may pass without a new leader being elected. I assume the same thing could happen in our case, since for liveliness reasons, we want the delegate to actively claim the leadership position.
- Multiple leaders per slot
- Corruption, where an adversary can learn the identities of the slot leaders ahead of time and use that to corrupt the election.
My eyes glazed over when the paper got too deep into proofs, but I started thinking about what might be a simple election algoritm to start with.
So here’s one:
- An election starts with the production of a new key block on the parent chain
- Those who want to compete for leadership, commit a stake tx to some microblock in the generation. They of course can’t control which one.
- The next key block hash on the parent chain is used to elect a leader among the committers. The distribution is given by the stake amount of each committer, and the order in which the txs appear in the microblock sequence. Only the last commit tx for each delegate counts.
- All stake sizes are valid, but with a very small stake, your chance of winning is small.
This should be deterministic, and there is no way to predict the outcome unless you control the hash of the next key block. It would constrain the election rate to the key block rate of the parent chain.
A question would be what should happen if the winner doesn’t produce a key block. One might let the election produce an ordered set of candidates, where the no 2 waits until the first parent microblock in the new generation, and then produces a keyblock if one hasn’t yet arrived. There would be a possibility of a conflict, but the order of the candidates is fixed, and determines which block to use.
4 Likes
We get an empty generation, I guess. In the child chain the previous leader is still producing microblocks so we are safe. This is one of the perks the child chain using a BitcoinNG consesus: transaction flow is not interrupted. Then delegates decide it is time for a new election and they repost their commitments on the parent chain but this time in the newer parent chain generation.
Yes, in the case where the child chain uses BitcoinNG, this would be perfectly acceptable. If not, it may make sense to have runners-up.
2 Likes
My concern with runners up would be that we still need to prove in a non-disputable way that the first leader did not produce blocks in the child chain.
This by itself is an attack vector that we prefer to ignore saying that if delegates misbehave, they will get burnt as well.
1 Like
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
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