Plasma offers solution how to quit the child chain when it progresses, but some parties feel cheated.
I have to read up on that. But I guess there is no solution where nobody feels cheated to some extend.
The problem with plasma is its very high complexity which the proposed system will also suffer from—and is also the reason why plasma has been mostly abandoned. (See also this article for a very high level overview)
Similar to how state channels need challenge periods, this will be required here as well, only that these will be even more complicated, given that you need all sorts of data availability proofs added. Otherwise a leader on the child-chain could withhold data, attack the chain and then wouldn’t be able to get slashed on the parent chain.
In general, putting this just into a smart contract to lower impact on mainnet development seems like a good approach if everything can be adequately represented/coordinated this way.
1 Like
the point of blockchains is that not a single entity can create n number of blocks in a row and this way control the blockchain for n*blocktime. This also means that miners/stackers CONTROL the blockchain during the time they are creating blocks. Ideally every block gets created by a separate entity.
thus, if you have AE coins on mainnet aeternity, then you trust the majority of the miners.
thus, if you have AE coins childnet aeternity, then you trust the majority of the stackers.
this is in the nature of things.
the more miners (mining pools) on mainnet and the more they have an equal hashrate, the better.
the more stackers (delegate’s voting nodes) and the more they have an equal voting power, the better.
its the responsibility of the AE coin miners to distribute more or less evenly across the mining pools.
it is the responsibility of the AE coin (or new child coin) voters to distribute their voting power more or less evenly across delegate’s voting nodes.
So how would I get my funds out of this thing again?
I suggest to have a “merge back” transaction which the staking nodes can use to signal that they want to unlock the tokens on mainnet. if after 100 blocks at least 3/4 (can be set by stakeholders at creation of child-contract since everyone needs to agree) have signalled that they want to merge back, then the childchain gets locked for for another 100 blocks for non-voting types of transactions. the childchain blockheaderhashes are already timestamped and signed on mainnet. @michalzee any idea how to create a proof of fraud for the past 100 blocks? maybe this is not necessary even. I think it only needs to be proven to the mainnet contract that for 200 blocks the childblockchain headers can be inspected that they are signed and timestamped on mainnet. the final state of childnet tokendistribution needs to be imported though and new accounts created of the ones which don’t exist on mainnet already.
Would these allocations be updated by activity on the child chain?
only when you merge back in case of AE-coin-type sidechain. not really needed for new types of tokens.
What is supposed to happen if they don’t? Or if they disagree? On re-orgs?
if they don’t than the leader stays the same until someone does and becomes leader. childchains are aware of the mainnet forks and should insert in both forks transactions. in case they are not aware, they can obviously only participate in the fork they know of. if an reorg suddently happens then there might have been a childchain leader or not. in every case, as soon as they know of the longest PoW mainnet chain, they should insert their delegate-transactions in there, otherwise don’t get a reward for this, and also re-run all transactions which are not part of this childchain fork.
they agree to disagree 
Right. A child-chain has to depend on the guarantees given by its parent-chain. Thus if a fork happens, it may only act on the forks it sees and once forks have been re-reconciled, needs to use the main fork again. I don’t see how this can be circumvented or even should.
Correct, the approach I described was too blue-eyed to begin with.
@ssh Did you compile a list of crypto primitives as requested here ? Or maybe @hanssv.chain knows where to find those?
Yeah, this might be the nicest way forward. The tricky bit is re-using and building upon the existing peer discovery and sync protocols. These were heavily tested, thus any change would also require good reviewing and testing. But, the result would also enhance the mainnet node’s stability.
I’m well aware of what ought to be the state of things and am just saying that the status quo of the mainnet is still not there.
(And I would say, the point is that you don’t have to trust the miners but you can always verify that they followed the protocol.)
I suspect that the fork and re-org handling will be very complex and error prone.
In general, I assume that we have two paths we can choose from wrt fraud:
- We choose to continue with fraud proofs
- we already have some experience with these
- they assume that fraud is a rare occurrence
- they assume that fraud can be detected easily and punished
- they can possibly be very expensive, posting all required state on-chain etc
- go with computational integrity (e.g. STARK, SNARK, …)
- we have not much expertise here
- requirement to prove every transition from state A → B would make frauds impossible
- constructing these proofs is more work upfront
- verifying proofs is cheaper than verifying the actual computation
Since our assumption is that all members of a child chain are known and static, this should be less of a problem, no?
1 Like
I think it all starts to resemble optimistic roll-ups.
From child-chain perspective there will be no forks as the nodes that run child chain are present in the context of single main-chain fork.
For the frauds, we can follow the optimistic roll-up approach. Reward for the fraud that can be submitted over longer period of time (2-weeks). It is not painful if we have liquidity providers, that monitor all forks and know the risk of swapping tokens (child-chain → main-chain) and they do it for fee.
Further we can punish malicious leader, by removing him from the contract. And again, contract lives in context of given main-chain fork and the fraud proof must be submitted from the same context.
The leader election would happen in the contract. API can be, get_leader(Data), where data can be any hash. If some nodes use different Data, then they will wait for another leader or eventual consistency will make them realize correct Data.
All happens in the mainchain contract (with arbitrary rules re consensus and delegates).
Main chain support is limited to not validating child-chain transactions (potentially some generalization of network structure).
Child chain support is capturing and understanding them in the context of relevant genesis contract.
2 Likes
Let me here summarize the call from the last week.
It turned out that above input from me, @botanicalcarebot.chain and @ssh is not relevant to the version of child chain management which @YaniUnchained meant.
To clarify:
- Potential-Leader parties submit transactions to parent chain
- Child chain’s nodes on every mined block in parent chain evaluate configured period of past transactions in parent chain (e.g. past generation, past block, past X-blocks)
- Out of this time frame they filter child chain Potential-Leader activity and use it as arguments to protocol-level function to pick Leader for child chain in random way
- The new Leader emits blocks/microblocks and these are treated as confirmed in child chain
All in all, parent chain acts as serialization engine.
Side thoughts from me:
Ad 1. It should be something hashed, so parent chain can’t easily censor child chain activity
Ad 2. Time frame of analysis of the parent chain is purposed to confirm that Potential-Leaders are active and ready to take over
Ad 3. This protocol-level function can be very well implemented as a contract in the child chain
Ad 3. The assumption is child chain will have random seed from the parent chain PoW
Interesting possibilities:
Actually, given that random leader election is open function each client can up front compute next leader (I mean: in parallel to child chain and don’t wait for Key Block or equivalent from new Leader). It means that Potential-Leaders can also add their Gateway address in parent chain submission. Users can then post transactions directly to the next leader.
Also, next leaders (so Potential-Leaders) can directly query leader node for latest block and don’t wait for gossip.
This is of course only for Leaders that can manage DDOS.
2 Likes
@michalzee of course your feedback is welcome and would be great if it was documented here. first we need to evaluate or break my approach and not get distracted by 100 other ways of doing it. if we can’t break it, then just build it since its quite simple, I think.
thanks!
- transactions contain commit to some microblockhash which they would follow on if they get elected as leader
- not sure why we need a time-frame here? the blockhash random number picks a leader, weighted by his weighted (delegated voting power)
- additionally they get confirmed by 1 (on the macroblockchain/keyblockchain)
Exactly, lets nailed it first to talk about the same thing. Not sure what I think about it yet.
No, can’t be, as in the child chain there is active leader emitting new microblocks with potentially higher frequency than in parent chain. So, the microblock hash would be stale when partent chain PoW comes around
This is my suggestion to consider only active parties. Use the partent chain as presence list to have ready to go leader. It would require, tho, constant activity of Potential-leader in parent chain, so I see this disadvantage.
The advantage is that we don’t pick up legit Potential-Leader, which happens to be offline.
If we don’t need that, we canuse only child chain list that got registered via parent chain at some point.
This one I don’t understand
I don’t think this is a problem since none of the leaders (constantly commiting to some new hash as a new candidate). they should not ddos the mainnet though, can be done via some transaction fee market, as they also get rewarded with some childchain tokens for this. there would be even a probability for microblockchain(forks) since there are many votes on ‘a’ microblockchaintop.
Happy to contribute in matters such as:
- Finding a suitable product market fit and defining a clear value proposition
- Further applying the SCAMPER model (Substitute, Combine, Adapt, Modify, Put to another use,Eliminate,Reverse/Rearrange) in existing solutions.
- Validating hypotheses and help formulating problems to solve
- Analysing competitors
- Assessing who will use our hyperchain, why and with what objective.
- Identifying pain points to tackle or “needs for vitamines”
- Researching why similar mainet leveraged solutions have not got any significant traction in the market, mainly thinking in Ardor/ NXT/ Ignis.
IMHO these are crucial even before development actually starts to avoid ending up with a solution looking for problems and users. We’d better define them beforehand and let users themselves come to solve their needs when a correct product market fit has been found.
Building the right product vs building the product right, of course the former includes the latter.
I have some suggestions on how to move forwards towards prototyping.
-
The parent-chain representation should be a contract. This might even be a viable solution for the long term, but for prototyping, it is definitely the easiest path. It also means that Sophia expertise is sufficient for that end. Erlang expertise is not required.
-
For the child chain, I think we can rely on the
ae_pluginapproach, if we complement it with a registration API for alternative logic at strategic points. Ideally, these points are very carefully selected in order to keep future maintenance as low as possible.
There are a few different ways to approach the ‘choice point’ selection. One way would be to describe how key and micro blocks differ on the child chain vs the main chain. It may be that they actually have to have slightly different structure, in which case the plugin also needs to be able to specify which block types are valid on the chain (and how to find the code that handles them). But still, analysing how the blocks differ, in type, and/or validation semantics, would be one way to attack the problem. This requires knowledge of the chain, but not necessarily the Erlang implementation.
Once the above analysis has some meat to it, the core team can help identify where in the aecore implementation the code needs to consult the plugin registry to find which code to call. I strongly suggest that we do it this way (overt branching) rather than the more hackish Erlang way of replacing specific modules. While this is a very cool feature of Erlang’s, it should be used for debugging and experimentation, not persistent overloading.
We should also absolutely not go overboard and invent some Ruby-on-Rails-style overloading hell, where you have to partially evaluate the code to understand what modules are actually being called.
4 Likes
With @Arthur and @dimitar.chain we had more detailed discussion regarding hyperchain concept, and we would like to summarise it here.
Child chain - PoS child blockchains, where:
- Child chain is parameterised blockchain, defined by its creator.
- There are delegates and regular accounts. Delegate is a candidate leader. As @dimitar.chain suggested in his post, in the init version, X topmost accounts with the highest balances can be counted as delegates. And delegates are the only ones, who can candidate for becoming a new block leader.
- In order for a delegate to participate in an election of the next leader, he will have to make a commitment transaction, to the parent chain. By doing so, the tokens of given candidate will be locked.
- All accounts in child chain should be able to delegate their power to delegates(but the concept of delegating is not yet discussed).
- All the delegates create the leader pool - after a round of commits, the delegate should be selected randomly, as the bigger stake the one has - the greater are his chances of becoming a next leader.
- Once the leader is selected, he starts creating microblocks. From the child chain txs pool, starts picking up valid txs and putting them in microblocks.
- Governance constants should be defined by the creator of the child chain.
- Once a miner in parent chain mined a new keyblock, the child chain should initiate a new child chain leader election.(Quite unclear here, should be more discussed).
- In order to be elected, a potential child chain leader will have to create a new keyblock, hash it and make a commitment to the parent chain, which will contain the next block hash in the transaction(Also is under discussion and unclear statement).
6 Likes