The Alpha Predator’s Heart and Art of RPyC: Python Coding for the Crypto-Curious
By: Blockforce Capital Research
In our last article [APM II], the Alpha Predator was slowly skulking away from the garden while we watched from behind a few bushes. Alas, the Alpha Predator’s thick fractal-like tail got caught on a thorn, releasing a drop of blood without the predator noticing. This single drop of blood is a rare chance to learn more about the inner workings of Blockforce Capital’s Alpha Predator. By rushing back to the lab and placing this sample under the microscope, we begin to see the fine structure DNA of Python code that gives life to the predator.
Our research team has a set a goal to help the broader community of coders and crypto enthusiasts by highlighting and explaining the technologies we use. This article is the first in our new series called “Tech Corner”; a series of posts catering to our readers with a knack for technical and coding details. We’ll get right down to the code and share details of our Alpha Predator Model (APM) for systematic digital asset trading. It’s our goal to be transparent and educational. If you would like to stay up to date, please consider joining our mailing list so you don’t miss our next installment of Tech Corner. Let’s begin!
Under the Microscope
The APM is written in Python and relies on the Pandas and NumPy packages for number crunching. It runs on dedicated web service computing resources and draws data from a PostgreSQL database running on the server’s high-availability RDS service. The database itself is fed by many redundant data collectors and binners to make sure that APM can devour the freshest market data.
The Alpha Predator maintains detailed logs of its activities and findings and sends out trade signals through various channels. They include Slack, text message, a queuing system for automatic trade execution, and even robocalls to portfolio managers.
One problem we faced was to get more detailed live information about how APM is making its decisions, including graphs of the market data and its analytics. As we’ve described in [APM I] and [APM II], APM follows a decision tree based on market properties and the current version makes decisions on the basis of optimized stochastic oscillators.
At first, a low-tech approach
Our first approach was to use an offline copy of APM to render static graphs using the same data source as the live APM. This plan got us about halfway, but there were two significant problems. First, we could never be 100% sure that the live APM was seeing the same data and analytics as the offline copy. To solve this problem, we had to double and triple check the APM configuration files, which change a lot as APM optimization progresses. The second problem was the manual aspect of this strategy. We always needed someone to run the offline APM to check the live APM, which isn’t practical.
The obvious alternative to that just described was another low-tech approach: have APM dump all its data to disk every time it updates and evaluates trading criteria. The logic would then have been to write an automated code that takes these data to render and update graphs displayed on a web page. While practical, this would’ve been a very much one-way avenue of communication.
Enter RPC -- Remote Procedure Call
Our engineering team came up with a much more powerful, bi-directional, way of interacting with a running APM. It’s called “Remote Procedure Call” (RPC) and dates back to the dark ages of computing before the internet. In its modern incarnation, RPC allows one program to attach itself to another running program. It can then inspect and even change the latter program’s data and execute functions, based on predefined permissions. RPC allows us to have a direct channel to APM’s heart: we can extract and graph all its live data, and we can influence its behavior by changing the variables that control its evolution.
This interaction is extremely powerful. We implement it by adding a little bit of code to APM (we’ll give details later) and then connecting to the running APM instance from a Python/Flask web process that serves APM data and interactivity via HTTPS. Here’s a screenshot of how this looks:
We’re using plotly.js to display the above data. Shown is the BTC price (in black) and the %D (red) and %DS (blue) of the active stochastic oscillator. Trades happen whenever these two cross. The selector and a submit button on the top left are an example of how RPC lets us interact with APM. We can activate or deactivate automatic trade execution using our proprietary trading engine that we’ll describe in a future post. Most importantly, the above graph is drawn on the basis of data pulled out of a live instance of APM!
It’s super easy!
So how does this work? It’s super easy! All that is needed is a modern Python interpreter (>= 3.6) and the RPyC package [pip install rpyc], and a little bit of code. We’ve put together example code snippets for you to try out and run yourself.
First, you add some RPyC instructions to your primary code you want to interact with later. Here’s an example:
A couple of things to note: RPCService is the class that is exposed by RPyC. We are passing in an object called “my_object” of class My_Object that has a property called “solution”. Using RPyC’s mechanism for exposing objects, we expose “my_object” using the method “exposed_get_my_object()”.
We also note that RPyC is launched using the Python threading mechanism. RPyC will listen on the local port number 12345. It’s sitting and running in the background while the main program continues to execute. In this case, all the latter does is print out the solution every two seconds.
Here’s the client code. It’s even shorter:
So the client program (also called “process”) connects to the RPyC server that’s listening on port 12345. It then grabs the exposed “my_object” object and prints its solution property. Next, it updates the solution to 43.
For trying this out, first, start the RPyC server (the first code snippet), then run the client (the second code snippet). You’ll get output from the server process that looks like this:
Here, the change from 42 to 43 occurs when the client is run, connects to the server, and modifies my_object.solution from 42 to 43.
This is precisely how we manage run-time changes to variables in our APM runs. Of course, there’s much more functionality offered by RPyC, including the remote invocation of functions run by the server and much more. Make sure to check out RPyC’s documentation: http://bit.ly/rryc
We hope this post inspired you to try out RPyC and put it to productive use for your purposes. It’s needless to say we’re great fans and will continue to use RPyC in many ways throughout APM and the rest of our software stack. We’ll continue analyzing the DNA of the Alpha Predator under the microscope and share what we find here in future Tech Corner pieces.
Blockforce Capital does not recommend that the information presented herein serve as the basis of any investment decision. The information is given in summary form and does not purport to be complete. The sole purpose of this material is to inform, and in no way is intended to be an offer or solicitation to purchase or sell any security, other investment or services, or to attract any funds or deposits.