Uncouple the Domain Model from Neo Core

[devhawk]

Objective

Reduce the dependency tree for libraries and tools that need access to the Neo
core domain model but don't need all the dependencies to run a full node.

Problem

Tools like NEON and libraries like RpcClient depend on neo.dll. However, the neo.dll
package has a large dependency tree of libraries needed to run a full node such as
Akka and AspNetCore. These dependencies needlessly bloat the size of NEON and RpcClient.

Proposals

• Introduce a new assembly tentatively named "Neo.Nucleus". Source code for Neo.Nucleus
  would live in main Neo repository.
• Move Domain models that can be used outside of the context of a full node (i.e. Block,
  Transaction and Wallet) into Neo.Nucleus
• Move domain model dependent types into Neo.Nucleus. A non-exaustive list of these types
  would likely include:
  • UInt160/256
  • ECC Crypto
  • Managed RIPEMD160 implementation
  • Neo.IO.Json types
  • Neo.IO.ISerializable
• Update RpcClient and NEON to depend on Neo.Nucleus instead of Neo.dll

Neo Version

• Neo 3

[Qiao-Jin]

How about combining this issue with #1866 , to create somthing as follows?

Here Neo.Model only includes data structure (similiar to .proto files) of payloads as well as basic types like UInt160, etc, and corresponding logic stored in Neo.Nucleus

[devhawk]

Neo.Models proposal from #1866 is a namespace change. This issue is about moving a small subset of the type definitions in neo.dll into the neo.nucleus.dll (final name of this assembly to be determined)

[Tommo-L]

It's good for me, as neo.dll is too large to be a sdk. If we need it, we need to do it ASAP.

[devhawk]

It's good for me, as neo.dll is too large to be a sdk. If we need it, we need to do it ASAP.

Does this have to be done before preview 4 or is there still a window after preview 4 ships where we could do this work?

[devhawk]

It's good for me, as neo.dll is too large to be a sdk. If we need it, we need to do it ASAP.

Does this have to be done before preview 4 or is there still a window after preview 4 ships where we could do this work?

FYI, I'm not as worried about getting it done ASAP. This type of relayering shouldn't affect behavior. Assemblies that take a dependency on neo.dll would still work once neo-nucleus.dll is introduced. downstream projects like RpcClient and Neon could move to the nucleus dependency whenever it was available, even if it came after 3.0 (say in 3.1 or something).

I'm more worried about getting #1866 done ASAP because once we ship 3.0, our ability to break 3rd part code drops dramatically.

[gsmachado]

It seems this one is related to this request: neo-project/neo-modules#749

Isn't it? 😄 There's demand.

[devhawk]

cc @erikzhang @Liaojinghui

[Jim8y]

Well, i am always thumbs up on this and would be happy to see any progress and glad to contribute.