Exec Factor with decimals

[shargon]

Description

• Moved changes from Exec Factor with decimals #4202
• Moved from neo-project branch to user branch
• Rebased to master

Please @neo-project/core review this PR, as we agree in Centre Point it's important for the community.
Was decided in Centre Point to have two decimals in ExecutionFactor this PR tries to address it

Type of change

• Optimization (the change is only an optimization)
• Style (the change is only a code style for better maintenance or standard purpose)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

• Unit Testing
• Run Application
• Local Computer Tests
• No Testing

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[vncoelho]

I will test this week

[Jim8y]

give me a sec, i need to carefully check it. I think there are some inconsistency issues... but need to confirm

[erikzhang]

Why not we add a SetExecFeeFactorV2?

[erikzhang]

In this case, if there is a v2 value, we will ignore the v1 value.

[shargon]

Seems simple if we don't have an extra method, just change the factor

[vncoelho]

Master branch is working again properly, as well as most basic features in this PR.

I will review code now, but it looks good to me.

[shargon]

@roman-khimov What do you think about solve this issue increasing the GAS decimals from 8 to 12, it's an @erikzhang idea, and I think it's a good one

[roman-khimov]

It'd be a perfect idea for 2021, pre-3.0. But now there are two things:

• formally it's a grave violation of NEP-17, since decimals() "MUST always return the same value every time it is invoked" (https://github.com/neo-project/proposals/blob/master/nep-17.mediawiki#decimals)
• realistically everyone knows GAS has 8 decimals: wallets, explorers, exchanges, contracts, scripts, everyone knows it and assumes it'll never change, so if it is to change things will break for sure

The only way to go from 8 to 12 to me is to migrate to a different token, but it's not fun either.

[erikzhang]

What are your thoughts on making NEO 4 a new chain without a native token? Like NeoX, we could transfer tokens across chains, and vice versa. This would allow us to develop new features on NEO 4 without worrying about compatibility.

[roman-khimov]

To me N4 is a compatible evolution of N3. I doubt anyone wants yet another chain with associated interoperability overheads. In that sense a new native GAS token on the same chain is easier to handle. Also, this particular change is expected to be delivered in 3.9.

[erikzhang]

Anyway, I need a clean codebase for launching N4 isomorphic sidechains in the future. For example, we might want to make the new DEX an application chain (sidechain) to support high TPS without clogging the main chain. I think the master branch can forgo all N3 compatibility, while master-3 must retain all N3 compatibility.

[roman-khimov]

I don't see any contradiction between sidechains and N3 evolution. In fact, one of things we're doing right now for NeoFS is a separate metadata chain that is N3-based, but has a different set of native contracts. IMO full N3 compatibility makes the solution stronger in that it's compatible with all things that exist for N3 already. It also makes supporting the platform easier overall, maintenance cost for separate N3 and N4 branches can be higher when they share a substantial percentage of code. All of the N4 things can be introduced via a set of N3 hardforks.

[deanragnarok]

I think launching N4 as a new chain would be a very hard sell to the Neo community. There are optics to be considered in addition to the technical considerations. Many still attribute the loss of momentum in the ecosystem to the Legacy-to-N3 migration. Even if this is a different scenario, it would be difficult to shake the perception that it’s happening all over again.

On top of that, the bridging of assets between Neo N3 and Neo X hasn’t been widely embraced yet. I understand there’s currently limited motivation for users to bridge, but adding a third chain into that mix could put things firmly in the too-hard-basket for users.

Personally, I think we should be simplifying and consolidating our efforts behind fewer platforms. We’ve only just shut down the Legacy chain, and the idea of having to maintain both N3 and a new N4 chain along with X, it feels like we’d be spreading ourselves thin all over again, let alone have to explain how it all fits together to new users.

[vncoelho]

This is the first time we are considering this approach for N4. Initially, I viewed N4 as a major compatible release (from 3.x → 4.0).

From my perspective, an N4 chain that retains NEO and GAS as the core of its economic model is ideal. The blockchain industry has evolved significantly, and the introduction of sidechains and a native DEX is undoubtedly the right direction to follow.

Although maintaining compatibility with N3 code is technically possible, it comes at a high cost. A new, cleaner codebase would open broader opportunities for innovation and allow us to better align with current industry standards.

Assuming NEO and GAS remain at the heart of the ecosystem, I believe a modern and well-structured implementation will bring greater safety, efficiency, and long-term sustainability.
Moreover, we should focus on designing and delivering robust, high-level bridges and cross-chain operations — an area that was not fully achieved in the N2→N3 or N3→NeoX transitions.

[gsmachado]

Moreover, we should focus on designing and delivering robust, high-level bridges and cross-chain operations — an area that was not fully achieved in the N2→N3 or N3→NeoX transitions.

In some weeks, NeoN3 <> NeoX will have an Arbitrary Message Bridge solution. I have a strong belief that people will like it and will support many use cases. For example, it will allow Neo X contracts to call Oracles of NeoN3.

So, despite what you said @vncoelho, we are indeed covering N3 <> NeoX transitions.

People have to realize that bridging things is a technically challenging and complex topic, for various reasons. It takes a long time.

[gsmachado]

I know that this comment doesn't help much, but I just want people to think about it.

From my experience (and I can be wrong 😅), let me just project (out of the blue) the two options we have:

1. If we do a separate chain for N4 (rollup/L2 or sidechain), it will take 6 to 12 months of development until we have a first version on mainnet (with less risks).
2. If we develop N4 as a set of hardforks in N3, it will take 18 to 24 months for completion (with more risks).

No matter how many resources we throw at it.

There are no rights or wrongs in the direction we take. But let's think about it.

[lllwvlvwlll]

Per @roman-khimov's comment, I do not think its feasible to extend the decimals without a large BD push. Its much simpler for internal teams to make changes to support this, but much more complicated to discuss the topic with exchanges and other integrators that are outside the ecosystem and may not be using "Neo N3 informed" architectures to make this change simple.

If we need to run an external campaign (outside of the ecosystem projects) to update all of the integrators to enable a reduced fee factor, I do not think its worth prioritizing on N3 EVEN THOUGH there is a huge value proposition.

Before discussing the implementation approach, we should probably align on "what" the project is. A new L1 initiative could very easily kill this ecosystem if we aren't careful so we need to make sure everyone is aligned on the "what" and "why" of this initiative to make sure we execute as a cohesive team.

[deanragnarok]

I’m not going to pretend I can weigh in on the technical considerations here, but I want to remind us all of a few things.

If we build N4 as a new chain, that sends a signal to the ecosystem: stop building on N3. It becomes a hard sell to convince people to invest time and money into something that’s soon to be seen as an inferior product. This is exactly what happened in the transition from Legacy to N3. And the ecosystem's biggest issues is that we need dApps in the ecosystem right now.

Consider this:

• We had over 2.5 million wallets on Neo Legacy.
• On N3, we currently have 147,000 wallets.
• On Neo X, we have fewer than 16,000 wallets.

We have not succeeded in bringing our users with us into each new world. If we’re going to create another new chain for N4, we need to seriously ask ourselves: why would it be different this time? Maybe we have an answer for that. If we don't, I don’t want to repeat the mistakes of the past.

And those are just the facts before we even touch on the other challenges, increased complexity for wallets and dApps creating UX's that encompass the whole ecosystem, users needing to manage assets across multiple chains, documentation confusion (we already struggle with outdated or conflicting material across Legacy, N3, and X), and the added burden of figuring out how to message, explain, and position N4 as yet another chain in the Neo universe.

These are all real issues we will need to contend with if we go down this path.

It’s outside my expertise to debate which features are or aren’t compatible with N3, or whether a new architecture would be cleaner, or how either choice might affect the development timeline. I trust Core to make the right call there, and I'm not going to stand in the way of technical innovation or progress.

But I feel the need to point out, as someone who has watched, reported on, and spoken to the developers and regular users of our ecosystem for the past eight years - Every time we’ve introduced a new chain, it has fragmented us more than it has propelled us forward.

[erikzhang]

We don't necessarily need to launch a new N4 main chain, but we do need a clean N4 codebase without compatibility issues to launch new sidechains and application chains (such as DEXs). The NEO main chain can remain in the N3 codebase and port compatible N4 features over.

[adrian-fjellberg]

If we build N4 as a new chain, that sends a signal to the ecosystem: stop building on N3.

Even I feel that way with regards to Flamingo. I am following this issue to see what we should do now. How are DEX features going to be implemented? Do we need to move to a side chain? Will it be built in to N3? Will the users need to migrate somehow? Do I stop building for N3 now? 😅

I do not expect any answers to the questions above, I am just sharing what thoughts are coming to me as I read and follow this thread/issue.

[lllwvlvwlll]

Almost all of the contracts that could be impacted by this change are managed by COZ and Flamingo. I'm happy to sign us up for doing regression testing and contract updates if it moves this along.

@odd86 @adrian-fjellberg Are you also ok with this for Flamingo as well?

For wallets and aggregators, I also think it will be straight forward and we can do it quickly for Neon. @ixje @raulduartep

I do not think we should use this GH issue to discuss Neo4 and its approach since it is derailing the conversation about how the fee factor should be technically implemented.

This change was agreed on already as part of N3 so why are we wasting this entire ecosystem's time by opening the discussion up again? It is embarrassing.

[superboyiii]

Please @superboyiii ensure again if this is "state safe"

OK

[shargon]

@superboyiii You can use this PR for compile together neo-project/neo-node#916

[ixje]

@gsmachado

• If we do a separate chain for N4 (rollup/L2 or sidechain), it will take 6 to 12 months of development until we have a first version on mainnet (with less risks).

• If we develop N4 as a set of hardforks in N3, it will take 18 to 24 months for completion (with more risks).

I'm not sure what risks you're referring to here, technical? If we take Dean's comments (1, 2) w.r.t. public perception in mind then surely the risk is the inverse, as in; a set of hard forks is much less risk to losing those that are left building on NEO (or were considering it).

I'm starting to get the feeling that some consider this a hobby programming project and only want to take the easy route on the technical side to then let the users pick up all the migration pain.

[Wi1l-B0t]

Add testcase scripts later.

[superboyiii]

Tested, data is compatible.

The base branch was changed.

[shargon]

@neo-project/core
master-n3 rebased with master, let's review this one and merge it to master-n3. From now every n3 PR must go to master-n3, and maybe also to master (neo4)