Distributed Computing / Smart Contracts Brainstorming

Apps
1

Continuing on from a couple of recent threads, I was musing about distributed computing and smart contracts and how they could work on Safe Network.

At first, I felt like there was a hurdle of these apps not being able to run within the network, rather than by users outside of the network. Now I’m not so sure.

When an app can be ran by a user outside of the network, we have certain advantages. Key management becomes easier, as the user has their own private keys for writing data. The user can also run the app anywhere, whether on their mobile, their laptop, in the cloud, etc. Any device which is capable of executing the code, which has connectivity, is capable.

The down side is that the network can’t guarantee that the apps are run. Users may or may not run them. However, they can be given incentives to run them, such as rewards on completion. Given the users may be anonymous (but may still have reputation built up), fear of running a controversial app should also be minimised.

So, given an ‘object’ in programming terms is data + code, we could define such an object in message format. It could contain a link to the code and links to data sources (both XOR-URLs to immutable data). E.g. something like this:

object safe://abc:

{
  "app": "safe://def",
  "input": [
    "safe://ghi"
  ],
  "output": "safe://xyz"
}

The object at safe://abc would define an application at safe://def that would take input from safe://ghi then output to safe://xyz when it fulfils a criteria defined in the app. The entire ‘object’ message would be immutable, as would each XOR-URL defined within.

Obviously, this is just a crude outline at this stage, but these could be picked up and executed by anyone with permission to read and/or write to the dependencies. The apps could also point to other objects, allowing a nest of objects to be executed, each with their own dependencies. Perhaps these dependencies could be provided by the parent too. Running them in a sandbox (WASM, perhaps?)

If this sort of approach could be wrapped by a mechanism/process to ‘offer’ these objects to users to execute, then validate and reward based on them, we start to form a distributed compute. The apps could be doing simple smart contract related tasks or CPU intensive compute.

Just early thoughts about this, but I wanted to dump my thoughts here. Maybe others have thought about this more?

8 Likes
2

This topic has some early thoughts from the usual suspects, including yourself. I haven’t thought about it since because it seems to me everything will be simplified if we can have the network do the consensus. Like the recent “plugin” discussions, we need an API and then all hell can break loose.

7 Likes
3

The tricky part is the validation and Sybil resistance. Did you have any particular approach in mind for the validation? Something like TrueBit maybe? Maybe the contracts are all some form of zkp that offers verifiability?

1 Like
4

Great to see. I have not thought much deeper about this, but an interesting point I am keen on is this.

We can secure data, to give it NetworkAuthority (means the network has also signed the data). We can also secure apps in the same way, this means we don’t qualify or audit apps but what we can ensure that an app that is good is not then corrupted/changed. So like data we can say, this is not changed, it is what you expect and we can cryptographically guarantee that. So we can do the same with apps. So this means if an app is good it will always be good. It may go out of date, but it won’t go corrupt.

I think this is an important aspect we need to get across. Upgrading and downgrading apps should be as simple a choosing the version of some data.

This seems trivial, but potentially solves another of societies issues, not data going out of date, but apps to read the data vanishing. As we keep data we keep apps.

Now those apps a wasm/wasi means we don’t need to worry about computing language either. We have a single “language” to preserve.

It make sense and done correctly (which I hope we are) will make the Safe network a powerful foundation for saving humanities information. At least I hope so.

13 Likes
5

Good memory! ha! Will have a read.

2 Likes
6

I hadn’t thought that far ahead yet, really. I just quite liked the idea that the app and data can be bundled together and trusted to be immutable. Combined with something like a WASM sandbox, that gives clients a level of confidence in the consistency of the task and some safety.

The joy of running from a client perspective is the flexibility available. You could open it in a browser or maybe as a background task via a CLI. You could run it once or many times. It could run on many different devices too, some of which may not always be online.

Perhaps it could leverage the reputation system built into safe network in some way. Could a vault node co-sign the output to act as a sort of guarantor? If the user also had a vault with good age, they could then leverage this. Granted, a client app couldn’t punish an abuse of this, but maybe it is an angle to consider.

Definitely an area which needs thought.

3 Likes
8

Maybe eWASM has a role in this or something similar?

3 Likes
9

WASM seems to be core to the future on a lot of these projects. Polkadot apparently uses WASM too. Maybe it will spur more interpolation between distributed projects.

1 Like
10

As I understand WASM is for making extra fast web service. Is it possible on blockchain? For me it is just marketing to boost up the price.

11

It’s rather more than that. When you compile something in wasm format, it will run on any platform in a virtual machine, at near native speed. It is also constrained by a sandbox found in web browsers.

So, you can compile rust or c++ etc to wasm and run it in a browser. It’s a bit like the java virtual machine, but without corporate baggage and restricted to a browser sandbox by default.

However, it doesn’t only need to live in a browser. You can run stand alone wasm apps, with WASI looking more like a java JVM in terms of full functionality.

1 Like