Protecting integrity of client-side data

Question

Scenario:

- I currently have a setup where an organization is running a node, and end-users communicate with this node via a REST API.

- I have used a node wrapper where I'm exposing a REST API with url's to do things like publishing to a stream, querying a stream,etc, by connecting to that node.

- The problem here is that a end-client needs to fully trust whoever is hosting this API layer, since they aren't: a) Running their own node, b) directly communicating with the node itself; When the client makes a POST call, the API layer might change something before publishing it to the stream, and similarly display ficticious data while doing a GET to query the stream.

So right now, if the client doesn't trust the API layer, the only way it can trust its data integrity is by hosting its own node which connects to the main blockchain, after which it can query it.

Am I understanding this situation correctly, and if yes, is there any workaround to this?
Like an SDK (on the roadmap?) which would directly communicate with the node instead of doing REST calls to invoke JSON-RPC API?

Answer 1

I'm afraid the solution is not as simple as you suggest. Even if the end users communicated directly with one particular node, how do they know they can trust that node? While it's harder for a malicious system administrator to modify MultiChain's code than to create a misleading API, it's certainly still possible.

If you want users to have trustless access to the network, they need to connect to the network directly themselves, as peers in the peer-to-peer architecture. One way to do this is to run MultiChain themselves. If that is not an option, they should run as light "SPV" nodes which don't process and store the whole blockchain, but still connect to multiple peers and send and receive transactions directly.

We don't yet have off-the-shelf code available for running SPV MultiChain nodes, but you can start by adapting an open source bitcoin SPV wallet. If the chain is set with anyone-can-connect=true, you don't need to modify the handshaking – just the logic for sending and receiving transactions to include MultiChain's metadata within the bitcoin transaction format.

Comments

Thanks, that was pretty helpful.

Is there a Multichain specific SPV node/'thin client' on your roadmap? (If yes, any timelines on that?!)

---

I'm afraid we don't currently have an ETA for that.