Ellaism and Frontier alternative upgrade paths!
-
Hello Everyone,
Ellaism has some exciting changes in its near future! I urge everyone to read https://github.com/ellaism/meta/discussions/67 Educate yourself on the potential future of Ellaism. It’s a couple minute read, and worth it.
Although it’s exciting and i would love to see changes happen quickly and Ellaism spring to life, I am curious of the last option Sorpaas describes. He states...
- “Wrapper block with strict consensus rules: This is similar to the recommended method as described above, but with state root validation as well. This is more sophisticated. However, the disadvantage is that it may take a long time to be implemented, as it relies on a feature not yet ready in Substrate.”
What will it take to get that feature prepared for Substrate? It sounds like the best option in the long run? What do you think?
-
@differdrift Are you talking about practicalities? Fair concern. We don't want this to take another 6 months. It needs to be done before this bull market ends or we'll never get a good share of the network effect.
I believe we should go for the fastest more secure option. And that Ethereum researches, tests things and develop new things. We don't have the resources for that. We can hardly just implement the available solutions. Not saying our developers are inferior. Just that they have operating costs we cannot afford at this stage.
If substrate is not a ready solution, we should just scratch that.
-
@batman I just hope the faster option doesn’t bite us later. I wonder if it can be changed down the road when practicalities are available for the more “sophisticated” solution.
-
@differdrift you mean we start with what we have for now (ETH2.0) and then shift when possible?
-
@batman Nope. I am talking about the “wrapper block with relaxed consensus rules” on substrate with frontier toolkit.
-
@differdrift sorpaas states the "wrapper block with strict consensus rules" route will take an indeterminate amount of time, a couple times in the proposal.
...and thus massively increase the development time.
However, the disadvantage is that it may take a long time to be implemented, as it relies on a feature not yet ready in Substrate.
To me, it seems to be an obvious indicator that if we went that route, we would have to consider a long road to implementation (if ever?). Is it necessary? I do not have enough knowledge to answer that. I presume you could err on the side of caution and say strict consensus is better than relaxed consensus.
Additional questions could be:
- What is a reasonable time estimate to build in the additional complexity?
- What is the cost-benefit to this? Maybe it is not really necessary for Ellaism, but could be more important for a large chain, such as Ethereum.
The Core Paper site has a lot of great information, largely technical, but worth reading.
-
I think we need to have the facts straight first. Questions such as following needs to be answered first: how easy is to just follow Ethereum? Easy at all? How about the Substrate route? Which one takes less effort?
Perhaps a report, by the developers is in order, specifying which options are possible and the approximate time each one will take. It's also a good roll-call to see who we have onboard as developers and how much time they are willing to spend here. So far it seems we only have 2 developers. Even if they work full time on this project, it'll take possibly a year or so to develop something new, as it requires research, development, implementation and testing before deployment. We might choose to relax some steps here to speed it up but how do I know? We need to hear from the people who want to do the work. But even figuring this out takes a lot of time on the side of developers.
My guy feeling is that copying a proven solution is easier. Reduce the emission and just follow Ethereum if it's doable. There is nothing wrong with Eth other than the presale.
