Yes this is exactly it.
I’ll rephrase it for where we are currently to make it really clear what I’m getting at with by expanding verification logic beyond signatures (although it sounds like you definitely do get it)
perhaps it’d be simpler to have the data owned by the smart contract public key and mutations to it are controlled by the contract signature verification, i.e. to mutate data you send a command/TX to valid signature for the contract signature verification, and it’s the contract signature verification which then applies allows all the logic for a mutation to the data it owns
We can easily see that signature verification is literally and directly a subset of the more general ‘verification logic’ (or smart contract) system.
It’s amazing to me how all these next-gen blockchain projects focus so heavily on money and transactions. The transaction operation is a subset of the more general ‘mutate’ operation that Safe Network will have. Really feels like stepping back in time when I see such a narrow focus in the literature.
Algorand uses TEAL language which is stack-based non-Turing-complete (no loops but does have forward branching). They have pyTEAL for a higher level system. Thanks for the suggestion @Sotros25. From first impressions it looks like a beefed up bitcoin tx system, but not as complex as ethereum. Would be good to look further into what they have added or excluded. Algorand is interesting because they have a two-tier architecture for their smart contracts, one for common everyday transactions, another for more complex unusual stuff. Both with the same language.
Eth2 is going with eWASM, basically wasm with the non-deterministic parts removed. Sounds promising but I have not looked very deeply into it.
Cardano is using Marlowe and Plutus which has Haskell as their higher level language. Their docs are unusable, broken getting started page, broken tutorial, I can’t say anything about these languages at all because of the broken docs. I found it really hard to get any useful info on this. Haskell-based is as far as I could get. Thanks @Nigel for the suggestion.
At this point it seems to me there are a few components to consider:
- the essential building blocks for managing data, flow control, arithmetic, some crypto primitives like signature verification and hashing, bitwise operations etc.
- the Safe Network specific operations, like looking up section membership, determining section prefix length, querying node age… this is probably where most of the novel thinking is required. I’m not sure how resource intensive these operations would be, or what types of operations we’ll want. But it might be good to start thinking about it. If you have ideas I would be keen to hear them.