search

eoscanada / EEPs

EOS Enhancements Proposals - (to be moved to another location)
12 stars 10 forks source link

EEP-6 - EOS Mainnet Extension Chains discussion. #32

Open abourget opened 5 years ago

abourget commented 5 years ago

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

cc32d9 commented 5 years ago

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 commented 5 years ago

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

abourget commented 5 years ago

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

cc32d9 commented 5 years ago

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 commented 5 years ago

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:

Some new ideas came in:

SonicAgamemnon commented 5 years ago

  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: