EEP-6 - EOS Mainnet Extension Chains discussion.

[abourget]

See https://eeps.io/EEPS/eep-6

[cc32d9]

Ok, you can copy user account names and permissions, but it's totally unclear how contracts would function on the sidechain.

Let's suppose you copied the permissions, bytecode and ABI of the original contract. But before it can function, some initialization actions need to be performed usually. The oracle would not be able to execute all that because it does not distinguish between administrative and user actions.

Then, what do we do with thousands of token contracts and symbols? If we just copy the contract code, somebody needs to create a token with a maximum supply. Then, how do we control that this would not double the total supply of the original token?

[cc32d9]

also some contracts need to perform some initialization actions, and then they change the authorization. here they would not have such a chance.

[abourget]

Interesting points, perhaps we should continue the conversation on Telegram over here: https://t.me/eos_extensions

[cc32d9]

So, what we have so far after a day of discussion:

1. Synchronizing account names and permissions is totally doable. I can make an oracle for that, based on Chronicle. I would suggest synchronizing only those accounts that want it.

2. Economics of such extension networks are totally unclear. Reminding again that pushing the businesses into voting proxies is a straightforward corruption.

3. The ultimate purpose of extension network is also not so much clear. Will they be dedicated to particular dApps?

4. There should be an automated way for client software to find relevant API endpoints. I hope what I started with apidirectory would help in that.

5. This construct needs an IBC solution. The solution presented by BOS needs at least $5k in RAM per pair of gateways and a dedicated server. Probably my lightweight proposal for cross-chain token transfers would be more suitable.

6. We better talk to the real businesses that want a blockchain before building anything. My strong feeling that we're inventing tools for a problem that doesn't exist.

Links:

https://github.com/EOSChronicleProject/eos-chronicle

https://github.com/cc32d9/eos.apidirectory

https://github.com/cc32d9/cc32d9_ideas_for_EOS/blob/master/Crosschain_Pegged_Token.md

[abourget]

What you have gathered so far today is in your summary above, agreed. Wouldn't want people to think it's an objective summary of the conversations though.

What is clear is this:

• The crux of the value is having replicated accounts, so users can flow from one chain to another transparently, and data migration becomes possible from chain to chain.
• Token economics need to be refined.
• More concrete examples of what this could bring about would be helpful.

Some new ideas came in:

• The possibility for a set of BPs to owner access to a Top-level Account (like .ext1) on mainnet, allowing creation of any .ext1 accounts on an Extension network, and doing reverse sync'ing.. allowing low-fee onboarding of new users, with the possibility (by reserving the namespace) of backsyncing to mainnet, and to other chains that do one-way sync.

[SonicAgamemnon]

1. We consider this an important enhancement. For many reasons, demand for extension/side chains will grow as load increases on mainnet, mainnet block production quality drops or geo-centralization increases, etc. We strongly support enhancement for EOS mainnet side chains with differentiated block production, governance, geo distribution, and a myriad of other factors that determine where application developers decide to deploy (besides mainnet). Extension side chains could be priced in tiers according to SLA factors such as 7x24 support, BP reputation via monitoring/metrics, assured geo-decentralized production (no more than 10% produced in any single jurisdication), enforced governance to assure high block production standards, etc. We like the idea of retaining the mainnet EOS token and its liquidity in the marketplace while deploying to a customized/SLA side chain and synchronizing accounts.

2. This would be our ideal EOS.IO platform to deploy into: EOS mainnet side-chain (uses EOS token, accounts, etc.) but with a high-quality set of block producers that provide the following guaranteed SLA, with:

• Widely distributed block production with no jurisdiction representing more than 10% of production
• Block producers cannot be coin exchanges or mining pools
• 7x24 monitoring and production support
• Minimum missed block assurance
• Optional BP 15/21 multi-signature contract administration
• Bare metal or metal/cloud hybrid preference
• Enforced BP governance ensuring SLA is maintained