As a light client, will I be able to ask any node to read data from my smart contract ?  

  RSS

lamouette
(@lamouette)
New Member
Joined:2 months  ago
Posts: 2
11/07/2018 12:40 pm  
 
Hey I'm a web developper and have some serious use case to build.
 
I encountered some problems by developping on the ethereum network (not only some scaling/latency related issues). I'd like to know if those flaws will also exist with RChain as it is planned to run (I hope not ^^ ).
 
This is my use case:
 
I want to build a dapp that will run on light clients, like smartphones or desktop browsers. The point of this dapp is to not rely on any centralized service (like infura.io, or just some private nodes), it must be able to interact with any node of the network/namespace to read or write in the blockchain, it must take full advantage of the decentralized characteristic of the network.
 
On the blockchain side, it is connected to a smart contract with get and set methods, for getting and setting a number for example. The get method is a read-only method, in ethereum, there is the constant prefix indicating it's a readonly method. The user can edit this value, and must be able to read it also, if any other user changes on the dapp changes it, it must be updated on every user's screen.
 
Write on the blockchain
To set the value, I guess it's quite easy, simple create a transaction that calls the set method of the smart contract, and send the transaction to any node of the network/namespace, it will then be processed and saved by all nodes.
 
Read from the blockchain
Now to read the value. The light client must read the value accessible through the get method of the smart contract. Can he call any node to have that value ? Of course I'm assuming there will be a SDK of some sort. But the first question is if it is possible ?
 
Moreover, in order to have a max probability of getting the right data from the blockchain, I want my dapp to request multiple nodes randomly (like 5 or 10), and compare the result afterwards to be sure that each nodes sends the right data, and that there is no fork going on.
 
 
 
In ethereum, the basic API doesn't propose that, we must go through a service like infura.io that runs the RPC api, or set up some personal nodes that run the RPC api, (we would do a eth_call). This makes dapps very less decentralized because they rely on one tiny portion of the network to read data in the blockchain (since it's running on a light client, it cannot download the all blocks). What happens when infura.io goes down ? Or starts to send malicious data ? What happen if my dapp rely only on my server, and some hacker easily sees it and ddos attacks my server (it's simpler to hack on one server than the entire network/namespace fleet).
 
The main point is that it is impossible, as a light client, to rely on the current ethereum network to read data from the blockchain/smart contracts. This is why there can be no true dapp at this moment.
 
Do you get my point ? Will a random RChain node be requestable to read data from the blockchain ? Will the state of a contract be accessible from the outside world (of course if it has explicitly be set as public) ?
 
Thanks for your responses !

ReplyQuote
MichaelBirch
(@michaelbirch)
Member Moderator
Joined:7 months  ago
Posts: 39
13/07/2018 2:47 pm  

The short answer to your question is no, you will not be able to query any node for blockchain state. There will probably exist similar centralized mirrors of the state and/or a handful of well-known nodes that serve the majority of state requests.

The essential issue is that only nodes that exist as part of some high-end hardware setup could handle the kind of traffic one might expect from exposing a public API to query its internal state. It is an easy DOS attack to send many requests for some random pieces of the state to a node and we cannot expect everyone who wants to run a node to set up protections against that.

Moreover, your question about querying multiple nodes and someone aggregating the results is really a question about handling consistency in a distributed database. The CAP theorem is a famous result with respect to this and blockchains tend towards availability and partition tolerance over consistency, so you can certainly expect that you will get different answers from different nodes even in the case that you could query arbitrarily and handling that would be something you as the dapp developer would need to handle because what it means to deal with inconsistent data sources properly is use-case specific.

That handles the read side of things. As for the write side, we cannot force all nodes to accept transactions from the outside world, though I think that most will because every validator will want there to be as many transactions on the network as possible. And handling "deploys" as we call them is much lighter compared to state queries, so the DOS risk is lower.

Thanks for the good question!


ReplyQuote
lamouette
(@lamouette)
New Member
Joined:2 months  ago
Posts: 2
15/07/2018 2:27 pm  

Ok thanks very much for your answer

I understand it, I'll have to rely on dedicated/readonly nodes to have a real-time access to the blockchain state. I guess some services like infura.io will pop as the RChain network grows.

Of course, I'll trust the response I guess as much as I trust the service I rely on or the security of the nodes I set up.

The conclusion I may have is that building real-time dapps (fully decentralized, not relying on one node/service) on light client is still, and will probably be for the next years a tough thing to do. Since the blockchain isn't there on the machine, there are some serious issues to consider, and compromises to make.


ReplyQuote
  
Working

Please Login or Register