There should not be separate versions of NEON for NEO 2 and 3

[devhawk]

having separate versions of NEON targeting NEO 2's VM and NEO 3's VM is going to be difficult for developers to manage. Instead of separate binaries, there should be a command-line switch specifying which VM version the developer is targeting.

As a suggestion, we could follow the model the C# compiler uses for specifying versions. The langversion command-line switch allows users to specify an exact version like "7.3" or versions that can change between releases such as "Latest".

[lock9]

I agree. Maybe we can read it from the manifest file (not sure if we already added that information there)

[igormcoelho]

We need to see if this is feasible @devhawk... perhaps changes for Neo 3 will require too many changes on compiler, even structural ones. This will depend on next steps on VM side.

[devhawk]

@lightszero and I discussed this issue over lunch. We agreed between the two of us that the best developer experience would be to have a single NEON tool that worked for NEO 2 and 3. This does make the NEON tool more complex than two separate tools, but provides a better experience for the developer using the tool.

My thinking is that by default NEON would target NEO 2 and developers could opt into NEO 3 via a command line switch (to be designed). This approach is used in other compilers :

• C# langversion option
• MSVC std option
• Clang std option

@igormcoelho Even if there are significant changes in the VM, we can still build a single tool to target both NEO 2 and 3. Even if NEO VM 2 and 3 diverge drastically, we could still have a single front end command line tool with a back end code generator for each version of NEO. I'm using a similar architecture in neo-express so that I will be able to add NEO 3 support w/o having separate versions of the tool.

[shargon]

But you are teaching different things to the developers, you are teaching, for the compiler you can use the same tool, for the node don't, for the explorer don't, for the wallet don't... strange, i think that all separated is not a bad idea.

If the user need to change the expected behavior according to the project, is confusing

[devhawk]

Developers are used to this - especially .NET developers. There aren't separate versions of the C# compiler for .NET Framework, .NET Core and Mono.

[devhawk]

master branch version of NEON has three dependencies on code in NEO.dll/NEOVM,dll:

• Neo.VM.OpCode
  • Since the list of opcodes is documented and standardized, it seems reasonable to have a copy of the OpCode enum in the compiler.
• Neo.Cryptography.RIPEMD160Managed
  • Since RIPEMD160 is a well known cryptographic hash algorithm that was created long before NEO project, it seems reasonable to have a copy of RIPEMD160Managed in the compiler. If there is a compelling reason for having a single binary implementation shared between NEO core dll and NEON compiler, we could refactor the RIPEMD160Managed implementation into a separate shared assembly
• Neo.SmartContract.InteropService.System_Runtime_Notify and System_Contract_Call
  • these fields are unique UInt32 sized hash values that are generated by calculated from the service name by ToInteropMethodHash. This method is only a single line, so it seems reasonable for the compiler to calculate this hash value independently.
  • This mechanism for generating a unique hash of a service name should be documented as part of the Interoperable Service Layer section of the NEO development guide.
  • The mechanism for generating the interop method hash is specified in the Smart Contract section of the NEO Development Guide.

[devhawk]

Draft PR that eliminates NEON dependency on NEO and NEO.VM: #104

[erikzhang]

Can we create tools for neo3 only?

[steven1227]

Can we create tools for neo3 only?

@erikzhang From the perspective of customer (Developers) of NEO blockchain, it is better to have a single neon compiler that can target neo 2 and neo3. There is still a large number of developers and projects that are developing NEO 2 SC/Dapps and for a long time before the official launch. And for the related tools such as neo-toolkit and neo-expressNode, their target is the developers for both 2.0 and neo3, and already did some great work on it. It is better to provide a single compiler for both versions. Although it has some pointless but complicated work to do, I discussed with @devhawk and @lightszero, there is solution and worth doing that.

[erikzhang]

I think those old tools are not very convenient, but they exist and can be used. We should not spend too much energy on the development of tools for neo2.

[lock9]

Hi everyone. I agree that we shouldn't invest too much energy in Neo 2, but I believe that this feature is a "migration" issue, that is why it is needed.

We can use both .NET Core 2.1 and 2.2 in the same machine, just by changing the configuration, therefore, I'm in favor of having a single distribution including Neo 2 and Neo 3. It will be easier for people to migrate their projects, and I also have to say that @devhawk is doing an amazing job with his tool. This will bring new developers to Neo 2 and we want these new developers in neo 3 too.

[devhawk]

I agree with @erikzhang that we "should not spend too much energy". But we shouldn't spend zero energy yto make sure we have a good dev experience.

It would be pretty easy to package the NEO2 version of NEON in a DLL and have the NEO3 version call the NEO2 Program.Main entrypoint if specifies neovm version 2. We would need to change the assembly name and namespace to avoid naming conflicts with neon 3 assembly and type names, but that's not very much effort.

I would NOT want to use this approach for supporting future versions of NEO after 3.0, but it will do for now.

[devhawk]

107 is a draft PR of the changes we could do to the NEON 2 code base in order to facilitate packaging NEON 2 and NEON 3 together. In particular, this code changes the assembly and type names of the NEO 2 version of NEON so 2 and 3 could work together.

Note, this PR will never exit draft status. In order to make it easy to see the changes, it's a delta from the master-2.x branch. If we choose to go this route, we'll need to add this code to a branch that can be merged into master branch.