Top-level blockchain-specific declarations

[adlerjohn]

To support all the functionality of the transaction format supported with Fuel v2 I suggest the following top-level declarations:

1. contract: defines a list of externally-callable functions that will be part of the contract's ABI, and a list of internally callable functions that are not part of the ABI. The ABI essentially replaces a main function with a giant switch statement to call different functions. Contracts will persist in the FuelVM's state.

contract {}

2. script: defines a single function that operates at the transaction level. Scripts exist only for the duration of a transaction.

script (input) -> output {}

3. predicate: defines a single function that must return a bool that operates at the input level. Predicates only exist for the duration of verifying the unlocking condition of an input.

predicate (input) -> bool {}

Smart contract developers will only use the first for writing their contract. Wallet and surrounding tooling can develop scripts and predicates using the latter two. But integration within a single language is important so that calls between them (say, a contract's function being called by a script) are type-safe, etc.

[sezna]

This makes sense, I can add this to the todo list.

[SilentCicero]

My only concern is, what is the larger cost benifit tradeoff moving away from a main function or block like Ethereum has now? John, we still have a main correct? It’s just your saying on a language level, contract isthis list of functions?

…

On Sun, Jan 31, 2021 at 4:09 PM Alex Hansen ***@***.***> wrote: This makes sense, I can add this to the todo list. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACK2CXVK7FOCMCDI5OJFUUDS4XBJNANCNFSM4WZMLNMQ> .

[adlerjohn]

Ethereum contracts don't have a main function.

[SilentCicero]

They don’t, they do have a runtime block, which you can consider a sort of main.

…

On Sun, Jan 31, 2021 at 4:53 PM John Adler ***@***.***> wrote: Ethereum contracts don't have a main function. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACK2CXSLQS7UE4V5ER6SQUDS4XGMJANCNFSM4WZMLNMQ> .

[sezna]

Should script be a top level block or should anything not within a predicate or contract be considered a script?

[adlerjohn]

You could say that technically anything that isn't a predicate or a contract can be part of the script, but that feels...messy? Because then your imports and pragmas and whatever are all part of the same scope as the predicate's body. Adding a predicate {} doesn't seem like much more work (correct me if I'm wrong) and adds clarity.

[sezna]

I was just thinking if you are writing a small script it may feel superfluous to wrap it in a script {} block. I've implemented script {}, contract {}, and predicate {} blocks in the parser already, so we can definitely stick with that for now. Maybe we can see what the community thinks upon release and tweak it if it's an issue.

[sezna]

update: there is now also a library {} for code intended to be used only as a library import

[sezna]

@digorithm