Initial Hyperchains Discussion: Public/Private, Scalable PoS Child-Chains (sidechains)

Hyperchains
, ,
1

Disclaimer

This proposal is work-in-progress and based on previous internal discussions.
The intention is to find and agree on an approach which is both possible to
realize and practicable. So feel free to join the discussion with feedback and
ideas.

Value Proposition

Privacy and scalability through child-chains. By supporting
child-chains with more lightweight consensus mechanisms which
still leverage the root-chain for PoW we can improve privacy
and scalability for the entire network.

Definition of Terms

  • Child-Chain: A chain which is somehow linked to a root-chain, thus allowing
    one to build a network of chains.
  • Privacy: Describes the possibility to keep information within a child-chain
    inaccessible to users outside of that chain.
  • Scalability: Describes how much traffic/work the network can handle.

Status Quo

There is no child-chain support in Aeternity.

Approach

The idea is to leverage the Proof-of-Work consensus of the mainnet as an incentive and security to be able to use a leader-group consensus in a child-chain. A similar approach has been described some time ago by @yani as Hyperchains although in a more general context.

A child-chain would use a less expensive consensus which make it
more applicable for high-volume use-cases which would be economically impossible
to realize using mainnet.

In order for someone to apply for the leader election one registers in a pool of potential leaders. The protocol for leader pool most likely includes negotiating information for what each potential leader sees as the mainnet top hash. Then using the mainnet’s next header as a source of entropy, a new leader or leaders are selected deterministically. Since network propagation is bound at least with the speed of light, different nodes could see mainnet’s top hash being different at the same time even without a fork. For the next leader to be elected at least a certain majority of potential leader nodes must acknowledge they agree upon the next block in mainnet.

Note: State Channels as a feature/capability are orthogonal to child-chains.

Advantages

  • leaders only receive transaction fees, thus are incentivized to accept all transactions
  • mainnet miners still receive block reward, thus are incentivized to mine blocks
  • a child-chain can implement forms of governance different from mainnet

Disadvantages

  • miners in mainnet could stall progress in the child-chain by not including leader’s transactions

Additional References

https://eosauthority.com/producers_schedules

https://elrond.com/assets/files/elrond-whitepaper.pdf

Required Work

TBD

Estimate

TBD

Known Limitations

TBD

Outlook

1 Like
2

cc @hanssv.chain @ssh @uwiger @dimitar.chain @YaniUnchained @michalzee

As mentioned this should open up the more detailed discussion. Please post references to other work in that area, ideas on how to structure this and get going. We’ll have a (daily) call to synchronize further, but still use this post as a base for discussion.

3

I’ll start out by listing the questions which I’ve got in mind and need to sort out:

  1. How can I become a leader candidate? What distinguishes a leader candidate from a non-leader candidate?
  2. Once I am a leader candidate, I shall be part of leader election or is there some other step in between.
  3. So a node needs to be part of the child-chain and act as a client to the root-chain. That means we need to consume progress on the root-chain as well as push transactions onto the root-chain for leader election?
  4. Shall the leader candidate pool be limited in size? If so for how long and under which circumstances are candidates replaced?
1 Like
4

So, my first foray was to get an overview over the literature wrt usage of (bitcoin’s) block hashes as sources of randomness. This topic has been relevant for a long time because sources of randomness for on-chain gambling are hard to come-by.
In general, the selfish-mining problem lowers the actual security of using bitcoin blockhashes. Also, attaching more extractable value to block production—e.g. via piggybacking our leader selection onto theirs—reduces the security of the parent chain.

1 Like
5

Now, even if we assume the availability of a reliable source of randomness we still need sybil protection. The randomness can give us confidence that the selection process cannot be tempered with but it does not prevent a malicious actor from entering as many tickets as they can into the drawing. As is, this again would devolve into proof-of-work and thus would most likely gain us nothing other than unnecessary complexity.
This issue also challenges the notion that using this parent chain as a source of randomness will give us significantly higher security margins. So this needs to be addressed.

6

Not if you allow every delegatee only one vote (commitment) via letting them broadcast a Mainnet transaction. They need to register first via locking in AE, too.

1 Like
7

So it’s just proof of stake then, ok.

With that in mind, we could probably take any proof of stake construction and replace their public coin with the the randomness extracted from the given parent chain.
The next exercise is then to argue wether or not it is worth to use bitcoin/chainX as a source of randomness when so many other sources exist.

8

The point is to use æ Mainnet and not Bitcoin. At least not for the first version.

9

Some points from my discussion with @dimitar.chain :

  • delegatee election could be a 3-step process
    1. delegatee locks funds in mainnet to become candidate
    2. based on reputation and staking of funds a subset of the candidate becomes the temporary leader election group
    3. given the top hash of the mainnet as entropy a leader is elected from that group
    • how would a reputation system work? does the leader liveliness play a role?
      • by incident I think we would need such a reputation system for the current p2p protocol in the node since this would help to overcome issues with temporary nodes and nodes with bad connectivity
  • the assumption is that attack security of the child-chain depends entirely on the security of the parent-chain
    • if a miner in the parent-chain can somehow infer from a new key block hash which leader would be elected in a given child-chain, the miner could dismiss the block by intention to prevent such election
    • or if a miner can game the randomness of the hash function it could influence the leader election the other way around
  • does a child-chain have its own token supply?
    • the alternative would be one deposits funds from the mainnet into the child-chain, and vice versa

@dimitar.chain feel free to correct me

1 Like
10

Forgot one point: Is there a concept of stake maturation? @ssh

In terms of if a delegatee D1 locks a certain amount of funds F1 at point P1. And another delegatee D2 locks a high amount of funds F2 (e.g. 10x F1) at point P2 (5 weeks later). Then the funds F1 have matured to a point where they are still more representable as F2. Thus, even if D2 would draw multiple tickets it would have to put in a high multiple of the funds to do that.

11

Reputation systems are hard. I’m not confident that introducing an on-chain reputation system is something that will work out.

Both of these things are possible under selfish-mining and given the fact that all the information is available to miners.

Any child-chain will be entirely at the mercy of the main-chain miners, given that they can trivially censor transactions and thus exclude candidates without repercussions.

(Now if we assume that tx privacy exists, then things might look a bit better)

There are a couple of things in that regard in governance. What do you hope to gain from this?

This sounds a lot like plasma and if we want to pursue this then we should look at the learnings of all the various plasma versions. Especially around how hard it is to make exit of these child chains fair.

There still way too many unknowns to be able to start writing a spec.

12

I agree with you in terms of the difficulty. But one needs to be able to judge liveliness somehow or be able to present the relevant data in an automatic manner so other’s can make decisions based on that.

Hmm, true. I think a child-chain where leaders are entirely at the mercy of a main-chain miner wouldn’t have much benefit or am I missing something here?

I would view the time such funds are locked to be a notion of commitment to the child-chain and use it as a factor to differentiate between new delegatee’s and stable established ones. It would be a form of reputation.

More to read up for me. Generally this is also a bizdev question since the market will work differently, thus use-cases will be implemented differently.

13

I’m just afraid that the complexity of tracking this on-chain would far outweigh the benefit and these system can always be gamed. I suppose that if we just track availability, that could possibly work out but then someone might just spin-up a bunch of child-chains with only themselves and offset any other negative scores, just as a crude example.

I agree but it’s more important that we are upfront about the assumptions we are making when designing this system. We can still design a usable system but have to be aware of these assumptions.

But that would then also mean that a malicious actor with less coins has better chances. This goes both ways, I’m afraid. And selling private keys is a thing too. (There are some things to make this harder, but that’s what I meant when I said that there are still way too many unknowns)

Polkadot runs a system, where a mainchain secures all (para|side)-chains, so that will also have to be studied—and then justified as to why not just use polkadot/substrate as opposed to roll our own, imo.

14

Piggybacking PoW

I will try to describe the idea on how to do it. please stay on this idea and try to break it or point out where it could be weak and needs to be improved.

Follwing process to create a childchain:

  1. creation of a childchain smart contract on mainnet by someone
  2. “funding” it via sending (and locking) AE or the creation of a new token
  3. after n blocks (function of value locked in AE) a new genesis block gets created for the PoS childchain with the same allocation like the smart contract.
  4. leader gets selected by the blockhash of mainnet out of the top 100 stakeholders.
  5. leader publishes microblocks
  6. stakeholders can delegate their voting power to other accounts on the childchain
  7. top 100 delegates (before every stakeholder was his own delegate) commit to microblockchain block via broadcasting transaction on mainnet
  8. when next block gets mined on mainnet, then next leader is chosen by blockhash

key difference to every other side/child chain mechanism I have found so far is that every delegate (voting node) commits first to a microblockchainhash via broadcasting it on mainnet. when the next mined block gets broadcasted every delegate knows who becomes the leader. stake grinding is not possible this way. throwing away a valid PoW solution is very expensive.

censorship of the mainnet miners is indeed a problem. important here is that no miner has more then a few blocks in a row, with any blockchain. we assume that miners will not censor for now. but we can also come up with a scheme where miners can’t censor, because it looks like a regular transaction (hash encoded in address). only other delegates could find this out.

15

The contract in the mainchain can have various rules, especially about stake (e.g. it can produce child coins with leverage; it can burn stake; accept just a fee at defined level for a stake in child chain; limit stake holders to 100 etc.).

On every key-block the contract can produce the leader, which defines location of current computation node of the child chain. The only job of child-chain would be to exchange the latest state (or act like a regular blockchain and listen to all transaction). Root hash can be backed on main chain. Child chain can even use mainnet for broadcast, but the transactions would not be validated of course.

Scope of requirements for the child-chain would say if we need any custom changes in the main chain to support them.

I see two problems that are not solved by above post:

  1. How to safely operate the contract with leader group for child chains (sibyls, censorship and selfish mining further escalated on a fork and partitioned network)
  2. Technical: what to do with messages on the fly during all the networking edge conditions
16

In my design the contract on mainnet is only involved for creation of the childchain. in case its a pegged AE childchain then it is also involved for destruction of the childchain (and then unlocking the locked AE). otherwise it is fully independant from the contract, just the transaction inclusion and the mainblockchain header is important to know for all.

@michalzee

  1. to simplify things we can assume now that EVERY childchainnode is also a mainnet node, thus always knows what happens on mainnet and the networks are never split. not every mainnet node is a childchainnode though.
  2. someone else please answer. or maybe use the matrix protocol?

one of the goals we need to achieve is to change the existing codebase in a very minimal way and still enabling private scalable childchains. anyone who can point to the things which need to be changed/adapted? thanks

17

How would this list of stakeholders be changed over time after the creation of the chain?

This would already be an implementation decision. The assumption here would be that child-chain support is an integrated function for any node. Then I would go even further and specify that only 1 level of child-chains is possible and a single node can only be used for a single child-chain.

I don’t think the matrix protocol helps in that regard. Our requirements in case of networking issues are certainly more specific and hard than what the matrix protocol provides. Although I’d be happy if someone proves me wrong.

18

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?

19

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.

20

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