Verification Logic on Safe Network

Currently the Safe Network allows changes to mutable data based on who is making the change (via the signature check) and how it is being changed (via the permissions layer such as read, append, delete operations).

Do you think we should consider extending these ‘change conditions’ to also allow smart contracts?

I am certainly no expert on this subject, but here’s the way I see it (would be keen to hear from others)

Pros of having smart contracts

  • Allows for more flexible conditions for triggering changes, eg a change may be valid if
    • some other event has already happened (such as the network growing to a certain size) or
    • a non-signature-based authority is provided (such as the solution to a certain computation) or
    • some other piece of data on the network has changed in a specific way
  • Does not remove the existing simple signature/permissions option, just extends it

Cons

  • Greater flexibility increases the chance for bugs in ownership, leading to possibly undesired changes to the data.
  • Potential increases to the workload for verification. Signatures take a well known time to verify. Smart contracts may take a lot of time to verify.
  • Overall complexity increases compared to a simple signature-only change verification system.

Secondly, on a related but more specific note, should we consider incorporating the Ethereum Virtual Machine (EVM) as the basis for smart contracts?

Pros of using EVM for smart contracts

  • Well established low and high level languages (Solidity, LLL, Vyper)
  • Broad audience with existing code, contracts, documentation and testing

Cons

  • The EVM design may not suit the design of Safe Network (eg payment mechanisms, data types, inputs and outputs of contracts etc)
  • Maybe no desire to associate this project with ethereum
  • Possibly less control over smart contract design, or additional work to maintain an incompatible fork
Include smart contracts for change verification?
  • Yes
  • No
  • Undecided

0 voters

Use EVM for smart contracts?
  • Yes
  • No
  • Undecided

0 voters

What else should we consider when it comes to the possibility of Smart Contracts on Safe Network?

10 Likes

Great to see you resurrecting this topic.

I voted undecided for now because of my possible misunderstanding. Maybe you could clear that up for me.

Couldn’t smart contracts already be built with what exists? I just assumed some more specific code could be written utilizing

That way the base layer system remains simpler. If you think that is possible then do you see it beneficial one way or the other? These more time consuming operations (such as signature accumulation) would only be applicable to a running smart contact, correct?
Part of what lead me to thinking this was this post from David.

Maybe I misunderstood this though.

Another question.

What would need to be added?

If smart contracts were built into the network and network events such as these could be known to a smart contract could this become an attack surface? Otherwise are these things known fully? I suppose I assumed network metrics to monitor its growth and health would likely be something of value so maybe this info is available no matter what and not a worry? Maybe it’s a good thing even.
I guess I’m wondering what kind of ideas you have in mind for a smart contract execute upon such events.

If a user knew they were engaging with a smart contract somehow and if regular network functions (such as append, mutate, etc) aren’t inhibited then I wonder if there is much downside at all.

I would say a big no to integrating another projects blockchain. Interoperability would be great but I don’t think it would be worth the effort.

2 Likes

I see smart contracts as changing ‘who’ changes the data rather than ‘how’ the data is changed. It’s a more generalized way of specifying ‘who’. The permissions layer stays the same, but instead of saying the permissions belong to key ABC123, we may say the permissions belong to something which is not necessarily predefined (eg any section key with prefix length 5). Same permissions, but the ‘who’ is different.

I would imagine in mutable data (to use an old term, I think map and sequence are the new terms) we change the struct field from
owner: PublicKey
to
owner: SmartContract
The network logic changes from
verify(owner: PublicKey, sig: Signature)
to
verify(contract: SmartContract, inputs []Input)

If we can encapsulate all network logic into a signature, then I guess we don’t need a change. David seems to be suggesting we can do this by setting the content of mutable data to the contract logic, and use a signature to ‘seal’ the operation. My doubt is if the contract logic isn’t verified at the network level then maybe the data is open to being changed under invalid conditions.

I guess AT2 and CRDT significantly changes the way the network operates compared to blockchains. All the calculating is done by clients, the network just notarizes it for payment and signature validation.

As an example of when smart contracts offer extended functionality… we might set the wikipedia article for Fibonacci Sequence to only be allowed to be updated by people who know the fibonacci sequence. We can do this by getting any editor to provide the next value in the fibonacci sequence as the proof their page edit is valid. The owner of the page is a smart contract containing the logic for the fibonacci sequence. The first update can be done by anyone who can provide the first value in the sequence, ie 1. Second update by anyone who can provide the next value, ie 1. Third update by whoever can provide 2, fourth update by 3, fifth update by 5, sixth update by 8 etc. This type of ‘group’ ownership is not possible using only signature-based owners; it requires some sort of smart contract system. With signatures we must have some predefined person or group of people who are owners. But we can’t really go around asking everyone ‘do you know the values of the fibonacci sequence’ and then add their keys to the permissions on the wikipedia page for fibonacci sequence.

Is there a way to use the existing signature-based ownership and still get the fibonacci sequence editor working?

I agree. I am not interested in the blockchains. But I am interested in increasing the flexibility of proving ‘who’ is allowed to change data, which is exactly what EVM does. The EVM is a way to check if the proposed change is allowed, and if it passes through the EVM without failing then the change is valid and it happens. Restricting Safe Network to a digital signature is imo too restrictive.

I would much prefer to not introduce smart contracts if possible. I started this thread hoping to end up finding we don’t need them.

If we want to have rewards that are not owned by the network (see this post) we probably need more than signature-based ownership, since the reward must be owned by something other than a key+signature.

5 Likes

One (surmountable) concern would be ability to review the contract before it’s deployed. How would public/private code review be managed?

First and foremost, I think that smart contracts should be engineered in the most optimal way for the SafeNetwork. However, I also think that interoperability with and leveraging best practices from solidity/EVM should be a priority. Providing interoperability and leveraging best practices would ease adoption by making it easier for people to code, use, deploy, review and trust smart contracts on SAFE.

Smart contracts on the Safe Network seems non-negotiable. To not include smart contract functionality would severely limit the range of dApps on SAFE. Moreover, excluding smart contract capabilities would be like delivering a product that’s already dated/behind the times in a key way. Even if smart contracts are not ready to go from day one on SAFE, the path to integrating/servicing them should be clear and underway.

7 Likes

So to sum it up, this is the hurdle. Maybe it would be nice to allow Elders to give read type access of certain network ops (that wouldn’t compromise anonymity or security) and act as network oracles, providing a Network Agreed Logic (NAL) api or the like for “smart contracting” on the Safe Network?
If something like this would be possible then there would be less change necessary and the required info/permissions/etc are still all provided by the network officially.

Does that make sense? Just kinda spit balling here.

2 Likes

The interoperability bit would likely be a boat load of work, I would guess a security risk or at least a perceived one, and I wonder how beneficial it really would be. Hedera Hashgraph allows for Solidity written dApps that were hosted on ethereum and I’m not sure how much this has helped them. I follow the price of HBAR but I don’t follow the project itself and I simply never come across any news about it since after launch, before that there was a lot of promotion about it and they always mentioned that aspect.

I do think we can do smart contracts on the Safe Network. If not right away then I would say most definitely when decentralized compute is engineered. But I still think possible before.

3 Likes

Hedera has a number of issues from their positioning (I.e. “enterprise blockchain” that clearly doesn’t understand how enterprises operate or make decisions) to the general limitations of private-permissioned networks/chains.

Agreed. I think smart contracts are a must have, but (perhaps) not a must have right now.

3 Likes

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.

8 Likes

What if you ran a Safe Network within a Safe Network? You have the Safe Network as we now know it as the base layer and main Safe Network. Then you have the previous PARSEC state based? network but without the privacy focus and with the permissions changed to smart contract as you show in your original post. This smart contract Safe Network layer would be slower and wouldn’t be for general use (as it was shown as inadequate for general use and then PARSEC replaced for CRDT’s etc) but only for smart contract use and could then leverage the base layer Safe Network, passing actions or results to our basic base layer web experience.

If not a Safe Network within a Safe Network (Safeception) then maybe a parallel smart contract centric Safe Network utilizing quicp2p or webRTC or the like. It just has to be able to connect securely and in a compatible and recognizable manner with the base Safe Network.

Just thinking turtles all the way down and throwing spaghetti. Hopefully can spark or inspire a good idea in another.

2 Likes

At very high level, if we had smart contracts on Safe, then perhaps it’d be simpler to have the data owned by the smart contract and mutations to it are controlled by the contract, i.e. to mutate data you send a command/TX to the contract, and it’s the contract which then applies all the logic for a mutation to the data it owns…?..

Also, just to throw it here, and without knowing much about it, Cardano seems to be going with Haskel (or Haskel based/inspired lang it seems, Marlowe) and Plutus as languages, so I guess some information can be extracted from there as to why they are not going for Solidity.

7 Likes

Formal verification like Ocaml I would guess.

3 Likes

It might also be interesting to checkout what Algorand is doing - Introduction - Algorand Developer Portal

5 Likes

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.
13 Likes

For me, next gen has always been about handling larger data than simple, small, transactions. Safe Network seems to be the only project attempting to do this.

At the same time, I get a little frustrated that safe network is considered as a distributed file storage system. The design seems capable of so much more, when mixed with imagination.

There is a reason why safe network has been a long time coming. It is breaking new ground on many levels. I hope others realise this in time.

12 Likes

I just wanted to say thank you for this. “Verification logic” is a new term for me, and much clearer.

7 Likes

Might be worth keeping an eye on Aztec Protocol for private transactions, but still seems to be very early in development:

The Aztec Protocol allows logical checks to be performed on encrypted values without exactly revealing them, to the blockchain. The inputs and outputs of a transaction are encrypted and hidden, yet the blockchain can still verify the logical correctness of these encrypted statements.

The aztec.network site may also be of interest.

2 Likes

Quick skim but interesting to see they went for a zk-snark based approach, so that still has the setup phase issues (the grand show of destroying keys). I wonder why not bulletproofs instead, they are smaller and don’t require the setup shenanigans? If anyone find out then please post it here.

5 Likes

Tornado cash on Ethereum is also snark based

1 Like

There’s a great response on stackoverflow outlining the tradeoffs between zksnarks zkstarks and bulletproofs

Seems to boil down to tradeoffs between speed vs size vs convenience / trust. Why did Aztec specifically choose the tradeoffs offered by zksnarks? I’m not sure.

I’d guess it’s to do with the zkRollup feature (docs): “These transactions are then batched by relayers using a further ‘rollup’ zkSNARK — this single rollup proof is then sent to Ethereum, scaling the network” So the slowness of zksnarks becomes less important.

There’s a response in this topic that claims the benefits of zksnarks outweigh the compromises introduced by the trusted setup: “As Vitalik said, most of GP’s message is wrong. The trusted setup was participative, as in anyone could participate and as long as one person was honest the protocol was secure. I know people who participated, I think it’s FUD to say that the trusted setup is not great if you’re getting value from it (short-size proofs).”

A bit out of my league tbh.

6 Likes

Yes, although bulletproofs allows batching also. Maybe they are all close enough in practice and it does come down to speed/size. I read Vitalik’s points and agree to a level, but removing any trusted setup seems to me to be something that should be done, if possible. I am not deep enough into that to comment really, but the feel of a trusted setup is wrong to me.

6 Likes