Feature: Allow legacy versions of each compiler about neocompiler-eco

[igormcoelho]

That's true @ThomasLobker ... if specific images are created and properly named, they could be invoked and kept on disk (as docker creates incremental images, only the build output will remain). We are currently working in a full separation of consensus nodes in our network, which will be the basis of neo-tests project. After that, releasing this new testing part will be quick and easy.

[igormcoelho]

@ThomasLobker sorry for the delay, the idea is still on the table.. just time is short :)
I just thought this project will fit fine in another project we have, called neo-tests. The idea I have now is:

• you chose the language and pass the exact commit number or tag;
• the compiler is build on-the-fly with the desired configuration (may take a few minutes);
• the compiling process is made;
• everything is dropped.

The difference from our neocompiler.io project is that we must provide only a few pre-built options, in order to the viable to maintain them all on disk (because the purpose is to compile quickly). But if you just want to test a legacy version, it's ok to wait a few minutes. Do you agree?

[ThomasLobker]

@igormcoelho completely agreed. I think once you've built a compiler we can keep it on disk for future usage, so only the first time that it's selected it will take a couple of minutes. Disk space is cheap, so that should be no problem, but I can always help out with that.

Once we have this, we can use it to audit projects and verify the script hash, even if the projects don't want to open source their contract.

[vncoelho]

Closed through 77db351.

Thanks, @ThomasLobker for this insight.
The current implementation still needs more features, anyway, it was almost fully accomplished. 🗡️

[igormcoelho]

Hi Thomas, I liked a lot your idea. This can mean some extra overhead for our servers, but, who cares anyway :D it's for a good cause hahahah
We should first achieve some versioning convention for all compiling tools, because as you may have noticed, tools in Neo ecosystem don't usually have tags or unique names...
So, my first approach for naming could be X_Y_Z_A_B:

• language name (csharp)
• main maintainer name (neo)
• compiler release date (29052018) ddmmyyyy
• compiler tag, commit or partial commit (b18eb645)
• system os (ubuntu1710)
• dependencies (mono14......) This part should be quite free, the more explanation the better :)

So, we could theoretically provide a docker image like: neo-compiler:csharp_neo_29052018_b18eb645_ubuntu1710_mono14
And PROBABLY we could reproduce that in a near future :)

In fact, I believe compiler should come with a compiler.json specification, and smart contracts should return an informative string (we can propose a NEP for it!), so everybody will know how this contract was compiled.

compiler.json could be:

{
    "language" : "csharp",
    "maintainer" : "neo",
    "release_date" : "29-05-2018",
    "tag" : "b18eb645",
    "system" : "ubuntu1710",
    "dependencies": [
      {
         "mono" : "14"
      }
    ]
}

Perhaps I'm overcomplicating things, but in my opinion, if you want anything to be reproducible in this crazy environment, this could be a direction. Opinions???

[ThomasLobker]

@igormcoelho thank you so much for this insight. The JSON definition that holds all environmental parameters would be absolutely briliant. We would still need some relevant data on the smart contract level as well, something that points to where to find the source code (and where to find the compiler.json as well).

It can be part of the dApp NEP proposal in my opinion:
neo-project/proposals#46