Suggestion for enhancements to the smart contracts

[stevenj]

The smart contracts are great, but I think it would be good if we could add the following features to them:

1. Metadata: It should be possible for a smart contract to, on-demand, yield up information about itself, such as the author, its source repo, when it was published, its licence terms, its name, a description of what it does, etc. A smart contract browser could use all this information for a richer experience, and users could use it to get some idea what each smart contract is/does thats on their node. Bonus, if when the smart contract was built, its git hash was embedded in it, a user could independently validate that the source of the contract is as declared on their node, by rebuilding the contract (assuming reproducible builds).

For implementation, it just needs to be a webasm function that returns a json object with the appropriate data. Some fields should be mandatory, some optional and others custom to the contract.

2. Embedded Functions: Instead of ONLY managing the data, I should be able to call functionality embedded in the smart contract. I know this CAN be implemented in the UI, but I see the smart contracts as akin to lambda functions, and it would be good if the UI could be independent of the smart contracts for data (ie, multiple UI's could use the same contracts). But necessary internal processing can be enforced/standardised inside the smart contract itself.

Just like lambda, this could be a single function which is passed a JSON object that represents a rest call, such as: Method, Path, headers, Json parameter body (if any), and it returns a json object with a std web response code (200, 404, etc, and the response body which could be anything permissible in web (json, html, etc). This would also get the contracts parameters and state, so it could update the state, or read and respond with data (potentially processed) from the state.

This can be optional, and IF a webasm contract does not expose this function, any REST type calls to it return 404.

3. A Rest API (in addition to the websocket one). The rest api would be able to return the list of all known/installed contracts, the metadata for any of them, and a gateway to the embedded functions inside a smart contract. This way using the embedded functions would be identical to using a lambda function.

This would also make porting applications currently deployed on Lambda/serverless type systems much easier, because that interface could largely be preserved.

I have other ideas extending on from this base of ideas. But, I think adding these features would open up a world of possibilities within the smart contract and the system itself.

Example of the new contract functions I am proposing:

    /// Return metadata about the contract.
    /// 
    /// # Returns
    /// 
    /// Returns a JSON formatted string containing metadata about the smart 
    /// contract.
    /// 
    /// # Errors
    ///
    /// Will return `ContractError` if something is wrong with the contract.
    fn get_metadata(
        _parameters: Parameters<'static>,
        _state: State<'static>,
    ) -> Result<serde_json::Value, ContractError>;

    /// Execute Lambda Functions inside the contract.
    /// 
    /// # Passed
    /// 
    /// _event : The Rest API Event
    /// _context : Internal Rest API Context for the call
    /// _parameters : Immutable Contract parameters
    /// _state : Mutable Contract State
    /// 
    /// # Returns
    /// 
    /// Returns a JSON formatted result containing the response to send.
    /// 
    /// # Errors
    ///
    /// Will return `ContractError` if something is wrong with the contract.
    fn lambda_fn(
        _event: serde_json::Value,
        _context: serde_json::Value,
        _parameters: Parameters<'static>,
        _state: State<'static>,
    ) -> Result<(serde_json::Value, UpdateModification<'static>), ContractError>;

[ple1n]

I have a particular use case, an offline dictionary I wrote that uses rocksdb and the data size ranges from 20MBs to 100MBs. I haven't decided the way of community collaboration, voting, curation mechanism.

Now to decentralize this app. I would put the dictionaries onto Locutus network. And at least one dictionary is downloaded before any lookup. The data of one dictionary (~20MBs) would be spread over a few contracts. The contracts store indexed data. I would not duplicate the data, so Locutus would distribute the data and replace rocksdb here.

When the user opens the app, the client/browser has to download entire state of the contracts (20MBs for each) because of random access. The data and any following updates are certainly copied. Would it be more efficient to have Locutus 'cloud functions' which accept requests from clients and returns the processed local contract state, which in this case is looking up a word. The cloud function only serves the local user. It processes the existing, verified state of one or more contracts. It doesn't introduce external trust. It doesn't change how contracts states are propagated or verified.

@stevenj

[stevenj]

Yes, in theory, what you describe is exactly the kind of app that would benefit from the lambda_fn. You will still need to synch the entire data set using the existing locutus methods (between nodes), But there are lots of use cases for having a large data set in a contract, which a client app accesses via look ups (or processing) through an API. Rather than reading the whole thing into the browsers memory.

Also, I would like to be able to expose "API's" so that a community could re-implement the UI running on top of those API's. The API's being embedded within individual Locutus contracts. In your case, you could distribute the Contracts for the distributed DB, and a UI. But a user may think they can make a better UI, which still uses your backing data contracts (or even embeds your contracts into a different app all together). So that these Locutus contracts become part of a massive decentralized and self curating API layer.

Having the metadata means you could also link to the OpenAPI (or other) docs which describe how to use your contract/s, and give you the necessary credit for the work you did.

[ple1n]

Syncing the dataset (at least partly) is expected. Conceptually contracts verify their states and apply deltas, so it's currently not possible to verify the results of Contract APIs (API responses are not guaranteed to be verifiable, and verification requires context. Verification decentralizes) though querying APIs from other nodes without syncing could be a good idea in some cases. Under the original design apps retrieve states directly from the local daemon, in two ways, for web contracts through a filesystem like interface (the state is tar.gz and is extracted by locutus), and for others byte ranges. It's actually quite awkward that apps/frontend/clients access datasets/raw data directly. Separating API layer from the frontend is decoupling, I agree.

what we have now

• Contract API layer
• Contract State layer (verification and propagation)
  • Contract interdependence (of verification)
• Component (is this overlapping ?
• Job (also processes states, but requires trust

[stevenj]

I don't think you need to verify the contract API exposed through the lambda function I propose, in and of itself. There will always be a measure of trust there, as there is for the full contract. For example, nothing prevents me from writing a contract with a built in back door that subverts the built in synch/verification process.

That again is part of my reasoning for having the contract serve out metadata, so its possible to independently audit pre-built contracts. And the proposed reputation system plays into this as well, if someone posts malware they are only effecting their own data in the contract they expose.

I fear currently that contracts are a bit opaque, and I don't really know who made them or what they contain. If we could sign them, then I would be able to say to my node, i know this guy, here's his keys and I accept his contracts. Similar to how Linux distributions handle package updates, the packages are distributed through multiple mirrors but I know the package I am downloading comes from a "trusted" source because its signed by someone I recognize. And if I want, I can go to the source and audit it. It could even be possible to build a lot of this data into the metadata at compile time (Git hash, build time, options passed to the compiler, version of compiler and libraries, etc, could be embedded inside the contract metadata.) We should also have a way of blacklisting contracts, so that if there are bad contracts out there, we can tag them and they will be rejected from my node (and hopefully others). The blacklist itself could and probably should be in another contract the node uses, so I can subscribe to various trusted blacklists, just like I subscribe to add blocking dns lists hosted by various people.

I would also like it if contracts could call API functions in another contract, so they can use/consume that data for their own processing needs. For example, it f I had a contract that help authorized keys I could use that from another contract to validate the updates being made to my contract are properly signed by my known set of keys.

[ple1n]

Notice that our definition of verify diverged. Since the response of an API is the calculation result based on the contract state and request, the response alone would be less verifiable than getting the entire state. Therefore requesting APIs from other nodes requires trust.

There will always be a measure of trust there, as there is for the full contract.

That's not in the scope of this discussion. By definition, contracts verify their states, and relatively API responses are less verifiable alone.

[ple1n]

i know this guy

This would be the web of trust (as a reputation system and PKI) to be built on locutus. There are many ways.

if contracts could call API functions in another contract,

Yes. That has to be considered when designing the Contract API layer.

[stevenj]

I see where we diverged :)
I agree its less verifiable, but its more convenient. However, the full dataset behind the contract is always readable so you can verify if the contract behaves as its documented to, independently. And nothing would force you to use these functions, but they would allow one to encode universal/convenient access methods or also make it easier to port pre-existing non distributed apps relying on Rest API's.

Initially, I would imagine this Rest API would be used by the primary contract developers, so they would/should trust themselves. If you use a third parties contracts, part of the development process would be satisfying yourself as to their trustworthiness. It helps that the hash make the contract immutable, so if you develop against a particular contract, it can't be swapped out underneath you.

[ple1n]

A git platform can be hosted on locutus completely. Metadata can't be mandatory since no one can enforce that. To reduce cost, metadata can be a link to another contract (that is immutable or not) if necessary. Anyway it's good to have self-describing things just like multiformats.

[sanity]

Glad you brought this up, it's an important question but I'm not sure the solution requires changes to the low-level contract API itself.

I think what would solve this problem is a contract registry similar to Rust's https://crates.io/ or Java's Maven Central.

This would be a database that links to the contract's source code, the wasm produced by that source code, and the hash of that wasm. The registry could also provide serialization schemas for the contract's state and other useful information. It would support looking up contracts by their hash.

It could be available both on the web at https://freenet.org/contracts, and through Locutus.

Verifying that the compiled contract produces the webassembly is the more difficult part of this solution. Therefore, it would be better to have a semi-centralized solution initially. This could be decentralized later through something similar to issue #245.

Our lbt developer tool could provide explicit support for this registry (accessed either over the web or over Locutus).