So how would I get my funds out of this thing again?
Would these allocations be updated by activity on the child chain?
What is supposed to happen if they don’t? Or if they disagree? On re-orgs?
After our latest discussions I tried to put everything together and describe it
in process terms. Here is the result for further discussion. Still missing lots
of details which were already touched upon here and there. I would like to
further refine the assumptions to limit the scope.
Assumptions
- the set of stakes is static after a child-chain is created
NOTE: In case the assumption change anything below needs to be adapted
accordingly.
Process
The creation and operation of every child-chain follows a simple set of steps.
1. Initialization
Starting out, someone creates the child-chain contract on-chain in the chosen
parent-chain (e.g. mainnet). In doing so some initial parameters of the
child-chain are set, e.g. network name, minimum and maximum stake, minimum and
maximum number of staking parties, creation deadline.
2. Staking
Participants register their stakes by locking AE tokens into the contract which is only
possible in the staking phase. Participants can also unregister their stakes and
therefore unlock their AE tokens.
3. Creation
Once any of the staking goals has been reached, the contract will create the
child-chain, basically freezing the stakes.
4. Operation
4.1. Delegation
By default any party which has staked is also eligibile to be a leader
candidate. If a party is interested in becoming a leader, its stake can be
delegated to itself. If a party is not interested in becoming a leader, its stake can be
delegated to another candidate. This increases the chance of that candidate to
join the pool of leader candidates which is eligible for election.
By default no delegations were made, thus no leader candidates are available.
This process is ongoing during the operation of the child-chain and is
implemented through the on-chain contract.
4.2. Leader Election
Whenever a leader candidate sees a new key-block on its parent-chain, it
posts a new transaction to the parent-chain, executing the on-chain contract
to identify the leader in the child-chain for the new generation. The contract
takes into account the current stakes and delegations, the previously configured election
pool size and based on that and the key-block hash as input, a new leader is
selected.
If no leader candidates are available, no leader will be chosen and the
child-chain can not progress.
5. Destruction
At any point parties which have staked might decide that the child-chain has
finished its purpose and shall be destructed, such that all locked AE tokens can
be unlocked.
In order to do so the child-chain must not progress for a previously configured
amount of parent-chain generations. This can be achieved if all parties remove
their delegations and no leader can be elected. Once the destruction limit has
been reached, stakes can be unregistered and the child-chain will stop
operating.
Likewise, if a minimum of leader candidates is available the child-chain might remain operable but without usage. Thus, over time all stakeholders are incentivized to remove their delegations.
Implementation Considerations
The goal is to leverage as much technology from the main AE node as possible,
therefore required effort can also improve the performance of the mainnet.
Child-chain support is provided as an additional component (plugin) which is
running alongside the main node within the same Erlang runtime system.
Therefore, the component has direct access to internal APIs and more importantly
to communications channels.
Each child-chain node is a valid and active parent-chain node. But not every
parent-chain node must be a valid and active child-chain node.
The child-chain component can use the existing sync/p2p infrastructure to
braodcast transactions and blocks. This requires some form of
privacy since potentially other nodes, which are not part of the child-chain
network, can see the transactions.
Alternatively the child-chain nodes use the main node’s peer discovery mechanism
to identify other child-chain nodes. Then sync/p2p connections with these nodes
are set up in parallel to the existing parent-chain network connections. Then
transactions and blocks could only be forwarded over the child-chain network
connections to other child-chain nodes, while the parent-chain sync/p2p
connections continue to be used for parent-chain operation. The sync/p2p child-chain network would be a sub-network of the parent-chain network when viewed conceptually.
Responding to my own post, but talking to @dimitar.chain we realized the following:
If we follow the implementation approach of using the AE node’s infrastructure as much as possible, we could create a first iteration of a child-chain component with a very limited on-chain contract for testing. The work on the component would ideally not be protocol-breaking. Then once done we could iterate a lot faster by “simply” working on the on-chain child-chain contract, testing out different staking, voting and candidate strategies without having to touch the core anymore. This would also open up any further work to anybody who can write Sophia, so others outside of the core team could also join the effort.
Does that sound reasonable or totally crazy?
1 Like
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