Neo: Auto generate entrypoint method redirection based on method names / ABI

[lock9]

Summary
Today we have the ABI listing the methods available in a contract, however, it is not possible to know how to call these methods, because it depends on the implementation of the "switch statement", so the operation parameter doesn't have to match any method name in the ABI - but it should.

Do you have any solution you want to propose?
We should auto generate the entrypoint map to the methods, just like neo-one does.
If we can ensure that the operation matches the method names, we can automatically deserialize the results based on the ABI and allow users to explore and use smart contracts deployed in the network.

Where in the software does this update applies to?

• Compiler

[shargon]

This is already done, and working well

https://github.com/neo-project/neo-devpack-dotnet/blob/master/tests/Neo.Compiler.MSIL.UnitTests/TestClasses/Contract_autoentrypoint.cs
https://github.com/neo-project/neo-devpack-dotnet/blob/master/tests/Neo.Compiler.MSIL.UnitTests/UnitTest_AutoEntrypoint.cs

[lock9]

@shargon but how does it work? Is the compiler blocking an implementation of Main(operation, args)? It should if it is auto-generated

[shargon]

The compiler generate it, only if not exists

[lock9]

@shargon I think we should block it completely, otherwise the ABI method names may not match the operation argument, and in my opinion, it should always match, after all, that is why the ABI is for

[shargon]

I don't think so, I think that should be created only if not exist, like now, maybe you need to add specific logic for verification, or maybe you don't want to create methods.

Now is more powerful. Acording to the abi, if a developer want to do by himself, what is wrong?

[lock9]

@shargon the problem is that the ABI won't represent what it should: the contract interface. What is the sense of having an interface if it is not respected? 🤔
Why can't we have this auto-generated and have one specific method to be used in the verification? Like some kind of 'default' methods that users should override?
I have to enforce that it does not make sense to have an interface for a smart contract if it is not respected, and, it usually is not, because in C# we write methods in upper camel case, while we use the operation parameter with lower camel case.
We implement 'Transfer' method but use 'transfer' as operation.

[shargon]

If we avoid the Main method and we index the Offset in the ABI for all methods, we can avoid the initial switch too and start in the right place at the beginning.

What do you think @erikzhang @lightszero?

[erikzhang]

This is an interesting proposal.

Usually we call a contract like this:

Call(hash, method, args)

Do you mean that we change to this:

Call(hash, offset, args)

This will indeed be faster. But I can think of some drawbacks, such as the inability to hide private methods.

[shargon]

exactly this

Call(hash, offset, args)

such as the inability to hide private methods.

If we allow only the offset if it is inside the ABI, we can hide them.

[erikzhang]

Then we need to compare. I think it is the same as comparing the method.