SAFE needs fo support Smart Contracts

Features
1

Hi all. I believe the biggest thing that SAFE still NEEDS to have before launch is support for smart contracts! I can volunteer to help add this support, but we would obviously need to work in the proper way with the core team, however your procedures are set up (making a proposal, formalizing it, etc).

Data and Safecoins is NOT ENOUGH in 2021. It’s like Bitcoin having only one operation: transfer balances. So the use case is to store value and send value. That’s only scratching the surface. And exactly why Ethereum made a Turing-complete language of INSTRUCTIONS that are executed in all the nodes doing consensus, and an instruction to rollback() a transaction.

SAFE must support this in v1.0 unless it supports soft-forking it later.

Look, this will give SAFE superpowers, and attract a lot of developers. Not at the app layer — which requires TRUSTING a user (very much against the ethos of SAFE) — but at the layer of vaults doing consensus.

In other words, the key promise of Ethereum and other smart contract platforms like Tron etc. is that your CODE can be trusted to run. That is the entire premise that we built Intercoin on, and all the other DeFi projects do.

(Other DeFi projects are little games like cryptokitties or financial games like yield farming and automated market makers. Intercoin is about much more serious applications: Applications of Intercoin: Making Crypto Mainstream - Applications - Intercoin )

But anyway… if you want to attract actual development ecosystem of SMART CONTRACTS in the “distributed system” layer and not merely in the “trusted endpoint” layer, then support the EVM and its opcodes. Simply clone a reference implementation in Go or Javascript and interpret it.

All your vaults have to do is spin up a virtual machine to do some opcodes and implement rollback(). The “gas fees” can be paid in safecoin, and would be tiny since consensus between 30’vaults of a secon is inexpensive.

That’s what Tron, xDaiChain, Cardano, Polkadot, Solana and ALL OTHER distributed systems do. They support EVM. Same as all commodity hosts supported PHP. Because 95% of all smart contracts target the EVM for compilation. Whether they are written in solidity or another thing. It’s like Microsoft.NET bytecode.

You’ve spent 14 years building SAFEnet and in the meantime a rich ecosystem of code has emerged which runs in a new Trusted Computing Base. Support the EVM as a compulation target and let them port to SAFENet. It will make the network much much larger than if we cut this one corner and released it with no ability to run smart contracts in a trusted environment, and only run them by a trusted edge participant. Your mission is to eliminate needing to trust anyone for storing data. Just a little bit more lets you eliminate needing anyone for the APP LAYER also.

@Melvin @happybeing I forgot, who is involved also with Tim Berners-Lee’s Inrupt team? They and many others have been advocating that the apps and data be decoupled. But in 2021 the apps themselves should be decoupled into the “blockchain layer” (stored procedures) business logic and the “dapp layer” (user agent) UX. SAFE should have a way to support the former.

All that is needed for that is to support running arbitrary code in a safe VM on the nodes (even if the EVM support is added layer), and to support for ROLLBACK and COMMIT instructions. As long as these two are added, everyone can port their smart contracts - and not just their databases - to SAFE.

Imagine a network where smart contracts operate on data that is cheap and not outrageously expensive like blockchain based systems. They’d have a field day!

14 Likes
2

Greg your initiative is very welcome and something that already has a lot of interest and support.

Work on this could begin now but it doesn’t need to hold up release of the current feature set, nor should it IMO. The way upgrades operate will allow features to be added later and decentralised computation has always been envisaged as an upgrade.

Forking is not necessary for this to happen and once we have a sufficient base network I don’t think it will be hard to achieve sufficient node upgrades because, as you point out it will be very attractive and cause a new demographic to take notice and get involved.

12 Likes
3

I see your point on the app layer. Although if it is audited, open source, and then the developer proves destruction of their keys to control it to make it truly immutable. At least I believe that would be a pretty satisfactory and feasible solution.

Also as Mark says, it could always be injected as an upgrade to core at a later date. I hope you keep up on this initiative in some form. I will second @happybeing in that now is not the time to delay launch any further.

Do you have any technical approaches on your mind currently?

8 Likes
4

While I agree that smart contract capabilities are a must, launch should not be delayed to integrate them. Much like ADA, Safe can integrate smart contracts post launch.

11 Likes
5

Nigel - yep. I’ve been in the smart contract space long enough to suggest the canonical solutions right off the bat:

  1. You can’t replace “onchain” distributed computation with a trusted node setup, and still be able to trust the smart contract state, code and side effects will not be corrupted.

  2. The developer doesn’t prove they destroyed the keys. Instead they call a method like transferOwnership(0x0) to a null address, and the smart contract can have access control checks like if (transaction.sender == self.owner) but they can also be more complex checks. The point is that someone can set up the contract and “throw away the keys” by not literally doing anything with their private keys but rather setting self.owner to a new hash of a public key — or in this case 0.

6 Likes
6

Is the launch imminent? What is the date set for it?

SAFE doesn’t have to integrate smart contracts, it has to integrate enough capabilities to enable them later! Which I listed:

  1. Ability for vaults to run code from a file inside a sandboxed virtual machine process, via a pluggable interface, the actual EVM support can be added later.
  2. Native COMMIT and ROLLBACK for vault consensus process, that can be called from the virtual machine.

There is one optional thing, which can be added in future versions:
3) Ability to fetch structured data (or sub-data) from resources elsewhere on SAFENetwork via some sort of GraphQL API and clone them inside the virtual machine for use in computations.

The project has been preparing to launch for 14 years, and this is absolutely essential to get right so we never need to hard fork. We should have SAFE code in addition to SAFE data! Then it will attract all the right people.

4 Likes
7

The tokenomics analysis is that as a smart contract gets more valuable, it attracts more of the native currency (eth, xdai, safecoin, whatever). Smart contracts of the type ERC20 or ERC777 might have to additionally send safecoins to indicate the size of the value transfers. (Since we don’t really know how many safecoins really should equal one USDC or DAI token).

After each transaction, as more and more such value ends up in a section, that section will have to recruit MORE vaults to secure it (something along the lines of log N vaults to secure N amount of value).

Also, every time a transaction begins (some user signs it with their key and pays enough safecoin to make it happen) the section hosting the smart contract, and its vaults, may pull in OTHER sections into doing one instance of consensus because the transaction would be atomic across several sections (shards).

Whenever a smart contract hosted by one section calls methods of a smart contract hosted by another section, it would be pulled in. Typically smart contracts do not call outside their web of trust (whitelist) because the called function may do a while(1); and kill the transaction with out-of-gas. So you will have “affinity” between some contracts and the network can learn who to pull in for what method, and even optimize that over time. After the transaction ends, each section checks how much safecoin or ERC20 balances it ended up with, and adds or reduces its recruitment of vaults to log N of that number. It would be a market for vaults to join.

Smart contracts would start out with zero value, but as they attract more safecoin, the section hosting them would attract more vaults. Or alternatively, we can keep section size uniform but sections can recruit other sections to join into a consensus with them, or disband as coins move to another smart contract address.

2 Likes
8

The fact that we don’t have clarity on the date beyond “soon” is a leading reason not to hold up development any further at this point, IMO.

As previously noted:

Since you have a lot of experience with smart contracts, would you be able to define a route to integrating that capability on Safe? That would definitely help the team out I think.

9 Likes
9

@GregMagarshak ,

I love this idea! - but I am not competent to say whether it should cause any delays to the launch.

I am guessing but smart contracts would be required to get my wish of a SAFE DAO working? In my first use case I would just want a some voting mechanism:

  • one person, one token, one vote

OR

  • one vote per token owned

BTW, I am happy to help with an effort like this - I have some dev experience - but mostly C, Ruby, bash . .

10

I am perhaps being dim here, but I am confused though, and maybe my question will prompt more clear explanations, which is always good. Basically, this part:

I don’t get how ‘app’ is being defined here, is maybe the problem. If the data on the network is easily provable as what it says it is, which I think is going to be the case, then what problem is being solved by smart contracts? If the network stores data in an autonomous and trustless way, then it also stores ‘app layer’ data in the same way, right?

Or am I totally missing something? Again, it’s totally possible. Interesting trying to figure out though, and happy to see exciting ideas being thrown out.

1 Like
11

Safe proves the data is what you think it is, is created by who you believe it is etc.

Smart contracts prove that processing is what you wanted, that not just the data, but the result of some calculation is sound.

8 Likes
12

I don’t pretend to understand too many of the nuances of this but it looks like a Very Good Thing Indeed. I am totally sold on how desirable this feature is - both for the functionality of the network itself and for the dev community we could quickly bring on board, but I have not a scooby how long it would take for a PoC and then a working PR. Frankly even if it was 100% guaranteed to take less than a week, then I’d say lets do it in (say) the 3rd week after launch.

Post- launch, the team will be monitoring and iterating very quickly indeed. Is there sufficient resource to come up with a plan to implement SAFE Contracts soon after launch?

Please resist this incredibly attractive feature creep. For just a wee while to we get launched.

OR do we have sufficient community resource to examine this and give a VERY informed guesstimate of the scope of the changes and the testing required? I am loath to interrupt the team at this point. Can we even just start to bring this into the conversations on farming economics/dynamics? We really are going to have to find a different name for farmers or do we see the storage nodes and the computation nodes as two separate “communities” but inevitably overlapping to a greater or lesser extent?

Many thanks to Greg for bringing this up, I wish you had said earlier though :smile:

7 Likes
13

I agree with this. I’m not technical, but if the launch has to be delayed to support this, I’m all for it. Just the idea that SAFE has the ability to support smart contracts will attract more developers and talent than not having it.

4 Likes
14

Safe Contracts!! I love that. Should get a trademark :smile:

7 Likes
15

Aye but naw…

NO feature creep, no matter how deeply desirable the feature is.

David said months ago, the design was done, its the engineering and test now. There has to be a Design Freeze for another couple of weeks.

4 Likes
16

It isn’t needed day 1, imo. Let’s prove the tech works well with core use cases first, before bolting additional functionality on.

Safe network isn’t a blockchain, so there should be nothing to hard fork. If vaults grow additional capability, it should be alongside what they can already do.

Maidsafe have mentioned wanted to look into distributed processing and such after the data layer is complete. We must remember that all these current smart contract chains don’t have native storage, which limits their usefulness too, but few are saying they need that in 2021 to be viable.

We need a good foundation, then can iterate on it later. It will be great to have it, but the network will have many great use cases without it.

14 Likes
17

What’s the status of Eth 2.0? I thought I read there’d be a stage where data storage is added? I imagined the Safe Network being a viable option when that time came along and it’s on the road map to add computation to the Safe Network.

1 Like
18

I am aware that eth 2.0 is considering using eWASM as their VM. This could be important for any safe network implementation.

This article in ethereum site from last week discusses storage. Interestingly, safe network isn’t even mentioned:

I suspect safe network isn’t mentioned as folks don’t know about the current status and capabilities. One of the many reasons we should remain focused on release with the core feature set.

6 Likes
19

Smart contracts.

I would think having the ability for Safe to use its consensus to perform atomic decisions for an APP would allow all sorts of Applications that require it. The design of the Atomic operation would have to allow for numerous items/keys be signed all together (ability to wait for all keys to be signed, with abort allowed)

One example would be for two objects be swapped between owners in a way that it succeeds for fails in a provable way. IE I give you “x” items if you give me “Y” items. Items here are whatever they want to be. Then the atomic operation of Safe would be to do the ownership change in a all done or none done

Then the Application can utilise this feature to perform the contract in a provable way that cannot be faked.

6 Likes
20

Yes, while that is certainly useful, it is only a tiny subset of what smart contracts can do. We want trustless computation…

Take for example these smart contracts and tell me how you would accomplish them on SAFENet at the moment:

How would any of this be accomplished? It could be, if SAFE supported the EVM eventually.

That link Traktion posted seems like a really good explanation, and I agree we may as well aim to support eWASM. That’s why I think the choice of virtual machine implementation isn’t the point, the point is to have support for one, and allow it to read values from the rest of SAFENET and to call COMMIT or ROLLBACK.

3 Likes