The Ethereum Book is a useful resource for this topic (much as I dislike ethereum I can’t deny they’ve done a lot of research and thinking on the topic, and even though we will probably never use it directly it seems unwise to ignore it).
I’ve renamed this topic from Smart Contract to Verification Logic, even the ethereum book says
In the 1990s, cryptographer Nick Szabo coined the term and defined it as “a set of promises, specified in digital form, including protocols within which the parties perform on the other promises.” … In the context of Ethereum, the term is actually a bit of a misnomer, given that Ethereum smart contracts are neither smart nor legal contracts, but the term has stuck.
The EVM Chapter is a good one to read, especially the EVM Instruction Set (Bytecode Operations) section. This is the ethereum equivalent of bitcoin transaction opcodes and it’s easy to see the increased flexibility offered by ethereum.
In addition to the typical bytecode operations, the EVM also has access to account information (e.g., address and balance) and block information (e.g., block number and current gas price).
This is one area where Safe Network would not and could not replicate the EVM. The contract operates in some sort of environment, so it has access to ‘global variables’ on the blockchain. The ethereum blockchain acts like a huge data variable that contracts can use. For example, a contract can execute the operation GASLIMIT which is specific to the ethereum blockchain (ie not part of the contract itself and depends on the current time/block).
This introduces some difficulties (that eth2 will also face). A single blockchain means all nodes see the same state so the verification logic all executes with the same data. But what happens when we split that up (sharding / disjoint sections)? Do nodes performing verification need to query the state from other sections? This seems like it removes a big part of the benefit of disjoint sections (ie we still need to deal with the whole network rather than just our section).
Safe might need some different opcodes, for example a way to query the current section membership, or historical membership details. Maybe a way to load a data chunk onto the stack.
I see where you’re coming from but I feel there’s a move to thinking of elders with less permissions rather than more. I appreciate a readonly permission is fairly benign but I’m not sure if this is moving in the right direction.