Hi, I’m a long time Ethereum Solidity developer and just started working in Tezos.
I have to argue, that we NEED return values from contract calls, it’s simply not possible to do a lot of things Ethereum is capable of doing as long as we don’t support it.
Ex:
New EU regulation demands KYC+KYT+AML for any market that is run from inside the EU, so we need a contract that contains a whitelist for every wallet. Any TX pertaining to a swap or auction should therefore have to make a check FIRST, then perform the transfer.
Ofc, you can design the contract as just failures on calls, this is a workaround, but thinking of Tezos as a DB it would be EXTREMELY useful not to have to replicate state in multiple contracts in some scenarios, because this is the only workaround that works right now, you have 4-5 contracts that work together, you set a variable on the contract that “owns” the true data, then that contract goes and sets maps in every other contract and they have internal “views” so to speak of that data.
Can you please elaborate on that. I am not that familiar with development on blockchains so i might be missing something but there are quite a few successful software framework/architectures around that work similar to this.
For example: Elm, various actor model libraries or reactive libraries dont use return values for external calls.
Checks are hard in that the contract being called needs to contain the logic for the check, or if you use a callback, it’s just super unintuive which makes programming more convoluted resulting in code that’s harder to reason about and audit.
I’ve used quite a bit of reactive programming, I don’t think I understand what you mean, the way things work right now in tezos would be the equivalent of having to write a mobile app using RX that wouldn’t be able to make network calls.
Sure,there is a workaround in tezos which is to build a lambda, store it, make it so that you call a contract that then calls a callback which executes a lambda based on the result, but it’s very very complex, unsafe and error prone
Sorry for the late response, missed your answer. Its not that easy to see the equivalence with RX since it comes from the opposite direction and every observable knows what observable can call them while every smart contract knows the smart contracts it can call. Smart contracts map more naturally to the actor model.
For example this new internet computer thingie uses a smart contract language with actor idioms: Actors and async data :: Internet Computer but their needs might differ.
Maybe something like MailboxProcessor<'Msg> (FSharp.Core) could be implemented in a higher level language like Ligo, Smartpy, Morley, Archetype to give us idioms and primitives for comfortable and safe concurrent smart contract design and not michelson. Michelson needs the elements to make this possible for higher level languages.
But you always want to do as little async programming as possible and with the additional knowledge that the Tezos VM gives us it might be possible to find a better idiom than the actor model.
