Trusting that an App is tied to a trusted contract

It has been mentioned that contracts bring transparency to the financial transaction process as they are codified, autonomous and viewed on the blockchain. However, contracts will usually be behind an application facade such that a user will be interacting with an application which, in turn, will be interacting with a contract. So how will a user be able to identify that an app can be trusted because it is tied to contract x? Will there be some way of signing an app allow the user to trust the app because it, in turn, is tied to trusted contract x?

Comments

  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    You can just sign packages of the program as usual, either with public keys inside the contracts itself, or a namecoin-like contract can list public keys that come with contract software.

    Still, this can be made stronger if third parties get specifications of about what transactions contract-associated-software produces. Clients receiving output from those programs, given some context, can use those specifications to raise red flags if the specification isnt followed, and sometimes if the addresses dont match the usual.
  • rabbitrabbit Member Posts: 15 ✭✭
    There are a number of solutions to this kind of problem and it really depends on your use case. Ideally what we'll end up with are a number of smart contracts that together establish an identity layer and based on your need you'll interact with that layer to achieve the confidence you require. Think of it like a set of API's that you use to query metadata you can use to verify the integrity of the application.

    One example would be contracts that act together as a developer registry which contains a list of developers, their development keys, and application metadata for things like application name with version checksum. When you download an app it carries metadata that act as claims which you then cross check with the developer registry. With that information your device can know, even if you downloaded from a fraudulent site, that the application was developed by the claimed developer and was not tampered with during transit or otherwise.

    Thinking in web terms, if your application is simply frontend code you could take this a few steps further by verifying the identity of all service endpoints to see that they match services you trust. So you go to a server, it gives you a web client, your browser scans it for unknown service endpoints and gives you a chance to allow or deny it. If the frontend code contains the contract references, you could determine then and there if it's using the right connections.

    There are a number of other ways to solve this, but again, really depends on the case. At least, this has been my line of thinking, I could be way off.
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    edited March 2014
    The words 'Transaction Firewall' probably say more vividly what i meant. If programs provide transactions with a non-manual insertion, their name and 'claim of kind' has to be included. These would be 'pre transactions' they're not signed or on a block yet. The specification can be used to, defaultly block anything that doesnt match the specification. Manual insertion without use of profiles, or overriding the firewall could be considered insecure -know-what-you're-doing cases.

    Such specifications have a useful side-effect that it requires developers to specifically claim what it does -it reduces plausible deniability about the behavior of the program. If they make big vague claims, their specification could show they're full of hot air.

    Afaik establishing 'transaction itself trust' is always the same, other than the specifications differing, as in the end up you always have a transaction to use, there is no context dependence. Establishing 'transaction origin trust' however can differ.

    At least one portion of trusting SaaS or programs are the usual ones. For programs, you always want to try make sure the software indeed came from the developers, that the binary matches the source code, that the software doesnt have critical bugs. For SaaS the concern also is about the service disappearing or changing behavior without recourse, or the data being altered en-route too your computer. Both for SaaS and programs encryption/digital signatures can help, indeed the blockchain can help against MITM, and naming the public key. But it isnt particular to transaction-creating scripts.

    But are there ones that are particular to, or stand out/are good examples wrt creating transactions? Not sure.
  • StephanTualStephanTual London, EnglandMember, Moderator Posts: 1,282 mod
    "However, contracts will usually be behind an application facade such that a user will be interacting with an application which, in turn, will be interacting with a contract. "

    Exactly. This is why it would be a bit ironic to find a webserver owned by a centralized entity claiming to be a true 'distributed exchange'.

    Ultimately you're looking at having to trust the provider of the interface, just like today, you trust that the provider of the web browser you typed this on doesn't have a secret monitoring program baked in, and you trust amazon to actually send the products you just browsed and ordered. Did you ever look at the code behind Amazon? Me neither.

    A solution to this is a combination of a decentralized GUI system (which we're working on and aiming to have a prototype of for POC5), alongside a 'reputation' system + open state everything. External data concerns are alleviated by signing data feed contracts (Bloomberg signing currency exchange rates, and NASA signing weather information for example), or leveraging swarms of data sensors.

    In fact, the concept needs to be taken even further. For example, a truly decentralized storJ type program shouldn't leverage a closed list of 'cloud' services. Instead, it should probably be interacting with distributed storage layers such as Tahoe-LAFS, maidsafe, bitcloud or DHT+bittorrent.


Sign In or Register to comment.