How we wrote a package to interact with gRPC via python for RChain

Here at Proof we are trying to find a new way to fight misinformation on the web. Our approach specifically aims at leveraging the wisdom of the crowd , by people registering and voting if articles are Mostly True or Mostly False. We have created a mechanism pushing the proper conditions for collective intelligence to be born and we plan to use it to reduce the spread of malicious and misleading content.


One key point needed for the Proof platform to work correctly is to have a trustless voting mechanism. We are trying to achieve it by using a decentralized ledger that proves the regularity of votes.

This is how we met the RChain blockchain platform (which I suggest you further investigate, because it’s awesome!). Interacting with nodes of the platform required using the gRPC system.

So what is gRPC?

Web applications nowadays heavily rely on backend accessible with RESTful API on top of the HTTP 1.1 protocol with payloads based on the JSON format. With gRPC instead there is a new attempt to write an API that exchanges protobuf messages solely on the HTTP 2 protocol; it was initially developed by Google (while protobuf still is).

Server / Client interactions via gRPC with protobuff messages

Generate your client!

A really nice thing you get with gRPC is that you can generate client code easily in many programming languages based on the definitions the server defines. You can check out our bash script in our repo to verify how easy it was to write the python client code from the RChain node specifications.

Generating the client is really easy

After that we tried to follow descriptions from the generated clients to write Python functions to wrap calls to the gRPC server actions.

When the gRPC server updates specifications you have to go through the generation and types/functions checking again


Once we had the code in place, we open-sourced the effort to allow other developers working in the RChain community who were also using Python. The easiest option was to make the code available as python package to install, and become one of our code base dependencies.

Here are the steps:

  1. To create a Python package you need to register a valid account on the Pypi website.

2. Then there’s a scaffold to follow; to make sure you have the basic files in place in your code repository it’s always a wise choice to ask for help to the awesome cookie-cutter project (which is also written in Python ;) ) — specifically we used the “Cookiecutter template for a Python package”.

3. Testing locally your with something similar to:

pip install --editable .

4. Either manually push the package release to Pypi creating a $HOME/.pypirc and uploading with twine, or configure some continuous testing platform to deploy the package on tags after passing all tests, e.g. we used travis CI.

Test it out!

To see the package in action you can watch the recorded demo I gave in the RChain hangout (see also slides):

And follow the below links to try it out:

Two sides of the coin

What I appreciate the most in gRPC is the strong typing derived from protobuf: you sacrifice some flexibility but avoid the validation effort we all have to take to avoid errors.

The biggest disadvantage of gRPC is — of course — the one that every new technology suffers: lack of support compared to battle-tested and older approach as REST .

Proof is happening: Come join the movement and make your voice heard! Will we succeed in getting to a universally agreed upon definition of real news?

If you think you’re interested in Proof you can join the alpha testing that is about to take place next month!