In my previous post, we started with a small NEO private net. Today, we will take a quick look into NEO-CLI and what it offers. Although it is named NEO-CLI, in practicality, this is a full blown NEO blockchain node instead of just a CLI tool to communicate with it. NEO offers two node types – GUI and CLI. I think the suffix comes from that and I wanted to explicitly mention it since it is a tad confusing.
At first, we will try to connect to our newly created private net. To do that, we will start with installing a separate installation of NEO-CLI. Installing NEO-CLI is pretty straight forward. You will need .Net core installed in your machine. If you don’t follow the instruction here.
Installation
I’m currently using an Ubuntu 16.04 as a reference OS. After installing .Net core framework you will need to install the NEO-CLI package. And since Im on a debian it was quite easy to do so the following way:
We are testing and my local machine doesn’t have a frame of reference of the test private net we just created over Azure. To give this node a frame of reference we need to configure its SeedList to point to our own private net. What is a seed list? Simply put, it is nothing more than a list of URLs as described in the official NEO documentation. This is the first set of nodes NEO-CLI will try to connect to when it boots up.
To configure the aforementioned SeedList, we will modify the protocol.json file, under the neo-cli directory.
We need to update the SeedList section of the configuration the following way:
If you opt to use the public test net, rename the protocol.testnet.json to protocol.json and you should be good to go.
Booting up the node
Now, it is time to start the node, we are going to invoke:
dotnet neo-cli.dll --log --nopeers
The log option will log the smart contract information and nopeers makes the node only connect to the seed nodes from the configuration file. this is something we want since this is a private network.
Creating a new wallet
Let’s create a new wallet then.
neo> create wallet mywallet.db3
NEO-CLI will ask for password twice for the wallet, pick your desired password. And copy the address and pubkey to keep it a safe place. If you forget the public key you can use list key command to see it.
More on protocol.json
Before we end this one, we will have one last look at the protocol.json configuration file for our node.
The Magic field contains a uint value that denotes the source network of the message.
The StandbyValidators field are the validating nodes in the private node. It is the list of public keys of aforementioned validating nodes. We created 4 wallet here in this specific example and thus we have 4 entries here. 4 is the minimum number of nodes here to be listed for reaching a consensus.
SeedList is configured to localhost in this example configuration since NEO-CLI is booting up against the localhost node.
SystemFee section is the section that defines the system fee. As the configuration states, the registration fee for assets is 100000 GAS depicted by the RegisterTransaction field. EnrollmentTransaction field defines the registration fee for book-keepers. IssueTransaction is the fee for distributing assets. Finally the PublishTransaction is the fee for smart contracts.
That sums it up for this time. Next, we are going to have a look at how consensus works in NEO. And finally we will write a smart contract on NEO in C#. 🙂
If you are a blockchain enthusiast in these days, there is a good chance you have heard about NEO. NEO, arguably dubbed the “Ethereum Killer” promises to be a tailor made dApp platform for digitizing assets. This blog is not scoped to give everyone an introduction on NEO itself. So, I highly suggest reading the white paper from here.
What interests me mostly apart from NEOs approach with GAS and NEO to drive an economy for digitizing and managing assets is how it is built. Since it has its “ties” with Ethereum, my initial idea was it would probably be another Ethereum fork. And to my surprise, NEO is actually built from scratch. It has been on github since 2015 and totally built on C#. To be specific, net core. A quick look at the .csproj file tells me this is running on Asp.net core 2.0.2 now. Apart from whatever the promise it brings, this alone justifies my interest on how this is built.
Another thing that interests me here is how NEO approaches developers. Instead of having tailor made languages for smart contracts, NEO allows developer to write smart contracts with the the popular programming languages already. This list includes C#, Java, Golang and JavaScript. NeoVM, the small virtual machine that allows this to happen is .net core driven and hosted here.
The goal of today here is to deploy a NEO private net on Azure. Don’t get confused since for this time I won’t be using Azure Blockchain As A Service. Although the Azure Blockchain Workbench is indeed intriguing, that is a story for another day since Azure BAAS doesn’t support NEO out of the box yet. So we will go ahead with an Ubuntu Server 17.10.
We will use the test net ports here, not the main net. We are going to add port 20332-20336, 30332-30336 to the inbound rules.
When that is taken care of, we will move to the final validation stage and create the VM. Now from the information found newly created resource page we would go ahead and ssh into the newly created VM.
If you are on a OSX, Linux or basically any *nix you could use your native terminal to ssh to the new VM. If you are on windows, my choice is usually WSL.
To verify docker-ce is running, try the official hello world or ask systemctl.
$ sudo docker run hello-world
$ sudo systemctl status docker
After all said and done, we will pull the docker image cityofzion/neo-privatenet. This is a 4 Node NEO private net with 100M NEO and a lot of GAS. It also comes with a pre-loaded wallet. To pull and run the docker image, do the following:
Now, we are going to check out that preloaded wallet inside that docker container. To do that, execute the following:
$ sudo docker exec -it neo-privnet /bin/bash
* Consensus nodes are running in screen sessions, check 'screen -ls'
* neo-python is installed in /neo-python, with a neo-privnet.wallet file in place
* You can use the alias 'neopy' in the shell to start neo-python's prompt.py with privnet settings
* Please report issues to https://github.com/CityOfZion/neo-privatenet-docker
root@b6477e009639:/neo-python#
The banner will tell you that the screen sessions are running the consensus nodes and neo-python is already installed.
Execute a ls and you will see that neo-privnet.wallet is present there. We will run the pre-installed neopy and open the wallet.
neopy
neo> open wallet neo-privnet.wallet
The password for this is coz. To check the balance, execute:
wallet
We have around 100m NEO and 16K gas as promised!
There you go! You have your own NEO private net running over azure. To connect to the hosted private net from a remote client, we need to modify our neo client configuration. That is a story for another day.
For all the REST resources we deploy out every day, one of the most common scenario a developer ends up handling is designing a nice and effective search/filter/query endpoint for these aforementioned resources. Usually in these scenarios conventions play a big part and that starts from query filter parameters in the query string to using a full blown search engine like ElasticSearch, Lucene or Algolia. Vinay Sahni did a phenomenal job for putting out the gist for basic REST practices here. If you are new into REST and want to get yourself started talking REST, it’s worth a look.
Today, we will do a simple yet fun experiment. Our goal today is to create a simple nifty looking query language for a sample REST resource. We will try to mimic a couple of features Twitter Search Api provides and our sample data storage today will be Azure Cosmos Db: Document Db which previously was known as just Azure Document db. Recently it moved to the Azure Cosmos Db family and if you have missed it, here is the full details.
Therefore, the first thing we need is a set of sample data we can use as our REST resource. Since we are going to mimic the twitter public search api, we definitely need some sample data first. And of course github comes to the rescue. Download the sample data and put it to your own document db instance. If you don’t know how to create a document db instance, follow the quick start here. I’m referencing the link to the .net quick start, but there are node.js, Python, Java and Xamarin resources right by the side of it. For those of you who do not want to test your work against an Azure hosted document db and want to test Azure document db locally, you can always opt for the azure document db emulator.
Now, for the sake of this experiment I ported the github twitter sample data to an azure document db instance. It has 10 entries in that small data set and hosted here. If you want to browse the data, azure portal does allow it. But I suggest looking at this open source app here named Azure DocumentDB Studio. You can use the endpoint and the key written in the sample code in github to connect. The database is public just for you guys so you can test the sample code I have hosted in github and will list out in the end of this article. TL;DR people, this is your cue to go to the end of the article, but I highly suggest to stick around.
Features to be built:
Out of all the features twitters search api provides, I will port the to:UserAccount, from:UserAccount and “exact text” search capabilities. That means, We will be able to search tweets sent from one account to other and we will also be able to search tweets by mentioning a string we like to be present in the tweets. For an example if we want to find tweets
If you have an eye for detail, you will notice that this is not exactly like the twitter search api since doesn’t use an and operator. But for the sake of the simplicity in this example this should be enough.
Tools we are going to use:
Our api stack will be written in asp.net core. We will use ANTLR as our query language lexer-parser. If you need an ANTLR primer and another experiment I did with it, please have a look here where I tried to gobble up a simple scripting language. If you are not really accustomed to any of .net stacks, fret not. All of these are totally doable in any other tech stack you will possibly prefer to use. Since ANTLR has targets for multiple languages, api can be built in basically any language and even for our sample storage solution azure document db here, you have access to multiple client SDKs.
The data:
As I mentioned above, we have a little data set of 10 entries. I’m posting a sample entry here so the rest of the tutorial makes sense. One entry points to a single tweet made by a sample user.
It’s a small and simple grammar like the one we used in our scripting language tutorial. Since our REST resource query is essentially an expression, our entry rule will be expr. The railroad diagram for expr looks like:
Rule expr
This means we can have a single search term or multiple search term chained by a op rule. The op rule is nothing but the two relational operator we support: AND and OR.
Rule op
Along side of the op rule we also need to know what the term rule stands for. The term rule stands for the search term format we are allowed to use. In our sample query stated above, we have terms like from:terminator, to:robocop, “I’m back” or a hashtag like #HastaLaVista. That’s why we have 4 rules defining all of these cases and the term rule is a OR relationship between them.
rule term
I’m not going to post the railroad diagram for toText, fromText, hashText and exactText rules since they are pretty self-explanatory if you have a cursory look at the grammar.
So, what are we waiting for? Let’s start writing our little codebase that will parse this query string and translate it to an azure document db SQL that we can use to fetch the tweets. For that, we need a small repository that will connect to our desired database and collection in document db and will let us fetch some items. I only added methods that will allow us to read the tweets and connect to the database. I ignored the rest since you can always have a look at those in the quick start for azure document db.
Here’s our small rough database repository. Please remember to keep your endpoint and key strings somewhere secret and safe in production environment, since this is a tutorial, I went with what is easy and fast to go for a proof of concept.
namespace TweetQuery.Lib
{
using System;
using System.Collections.Generic;
using System.Threading.Tasks;
using Microsoft.Azure.Documents.Client;
using Microsoft.Azure.Documents.Linq;
public class CosmosDBRepository<T> where T : class
{
private readonly string Endpoint = "https://tweet.documents.azure.com:443/";
private readonly string Key = "fjp9Z3qKPxSOfE0KS1aaKvUY27B8IoL347sdtMBMjkCQqPmoaKjGXoyltrItNXNN6h4QjAYLSY5nyb2djWWUOQ==";
private readonly string DatabaseId = "tweetdb";
private readonly string CollectionId = "tweets";
private DocumentClient client;
public CosmosDBRepository()
{
client = new DocumentClient(new Uri(Endpoint), Key);
}
public async Task<IEnumerable<T>> GetItemsAsync(string sql)
{
if (string.IsNullOrEmpty(sql))
throw new ArgumentNullException(nameof(sql));
FeedOptions queryOptions = new FeedOptions { MaxItemCount = -1 };
var query = this.client.CreateDocumentQuery<T>(
UriFactory.CreateDocumentCollectionUri(DatabaseId, CollectionId),
sql, queryOptions)
.AsDocumentQuery();
List<T> results = new List<T>();
while (query.HasMoreResults)
{
results.AddRange(await query.ExecuteNextAsync<T>());
}
return results;
}
}
}
I opted for executing a SQL instead of a linq expression since constructing SQL is easier and simpler for a tutorial. Plus it decouples the query structure from compile time POCOs that we use as our models too.
I created a DocumentDbListener class based off the SearchBaseListener which was auto-generated from our ANTLR grammar. The sole purpose of this class is to generate a simple SQL against our search expression. To search inside nested arrays, I used a user defined function for azure document db. All of these are very crudely written, so forgive my indecency. Since this is just a tutorial, I tried to keep it as simple as possible.
function matchArrayElement(array, match) {
for (var index = 0; index < array.length; index++) {
var element = array[index];
if (typeof match === "object") {
for (var key in match) {
if (match.hasOwnProperty(key) && element.hasOwnProperty(key)) {
var matchVal = match[key];
var elemVal = element[key];
return matchVal == elemVal;
}
}
}
else {
return (element == match)
}
}
return false;
}
All this method does is it tries to find nested array elements based on the match we send back. You can achieve the same result thorough JOINs in Azure Document Db or Array method ARRAY_CONTAINS, but I preferred a user defined function since it serves my purpose easily.
Constructing SQL from the query expression:
To understand how the SQL is generated from the query expression, let’s begin with the to:UserAccount expression. Since we start with the rule expr, let’s override the SearchBaseListener method EnterExpr first.
namespace TweetSearch.CosmosDb.DocumentDb
{
using Antlr4.Runtime.Misc;
using TweetSearch.CosmosDb.Util;
public class DocumentDbListener : SearchBaseListener
{
private string projectionClause = "SELECT * FROM twt";
private string whereClause;
public string Output
{
get { return projectionClause + " " + whereClause; }
}
public override void EnterExpr([NotNull] SearchParser.ExprContext context)
{
this.whereClause = "WHERE";
}
}
}
The approach I took here is essentially the simplest. I handle the events fired the moment ANTLR enters a specific rule and I keep appending the SQL string to the whereClause. Since, entering the expr rule means that I will need a where SQL clause, I initialized it with “WHERE”. The thing to notice here is instead of concatenating I chose to initialize it because I expect this event to be fired exactly once since that is how the grammar is designed.
Following the same trail the next thing to handle will be the EnterTerm event. But, term is nothing but an OR relationship between 4 other rules. Handling them specifically gives me the edge since they produce simpler and smaller readable methods. For example, if we want to handle the to:UserAccount expression, a simple method like following should be sufficient for our use case.
This is where our user defined function also comes in play though. I’m trying to find any tweet that has an user mention to the parsed user account I fetched from the query.
By following the same rule I completed the rest of the four rules and my full listener class looks like:
namespace TweetSearch.CosmosDb.DocumentDb
{
using Antlr4.Runtime.Misc;
using TweetSearch.CosmosDb.Util;
public class DocumentDbListener : SearchBaseListener
{
private string projectionClause = "SELECT * FROM twt";
private string whereClause;
public string Output
{
get { return projectionClause + " " + whereClause; }
}
public override void EnterExpr([NotNull] SearchParser.ExprContext context)
{
this.whereClause = "WHERE";
}
public override void EnterFromText([NotNull] SearchParser.FromTextContext context)
{
var screenName = context.GetText().Substring(5).Enquote();
this.whereClause = string.Concat(whereClause, " ", "twt.user.screen_name = ", screenName);
}
public override void EnterOp([NotNull] SearchParser.OpContext context)
{
var text = context.GetText();
this.whereClause = string.Concat(this.whereClause, " ", text.ToUpper());
}
public override void EnterToText([NotNull] SearchParser.ToTextContext context)
{
var screenName = context.GetText().Substring(3).Enquote();
this.whereClause = string.Concat(whereClause, " ", $"udf.matchArrayElement(twt.entities.user_mentions, {{ \"screen_name\" : {screenName} }} )");
}
public override void EnterHashText([NotNull] SearchParser.HashTextContext context)
{
var hashtag = context.GetText().Enquote();
this.whereClause = string.Concat(whereClause, " ", $"udf.matchArrayElement(twt.entities.hashtags, {hashtag})");
}
public override void EnterExactText([NotNull] SearchParser.ExactTextContext context)
{
var text = context.GetText();
this.whereClause = string.Concat(whereClause, " ", $"CONTAINS(twt.text, {text})");
}
}
}
We got our listener ready! Now, all we need is a context class that will bootstrap the lexer and parser and tokens so the input expression is transpiled and the output SQL is generated. Just like our last work on ANTLR, the TweetQueryContext class will look like the following:
namespace TweetSearch.CosmosDb.DocumentDb
{
using Antlr4.Runtime;
using Antlr4.Runtime.Tree;
public class TweetQueryContext
{
private DocumentDbListener listener;
public TweetQueryContext()
{
this.listener = new DocumentDbListener();
}
public SearchParser.ExprContext GenerateAST(string input)
{
var inputStream = new AntlrInputStream(input);
var lexer = new SearchLexer(inputStream);
var tokens = new CommonTokenStream(lexer);
var parser = new SearchParser(tokens);
parser.ErrorHandler = new BailErrorStrategy();
return parser.expr();
}
public string GenerateQuery(string inputText)
{
var astree = this.GenerateAST(inputText);
ParseTreeWalker.Default.Walk(listener, astree);
return listener.Output;
}
}
}
Whew! That was easy, right?
Bootstrapping the api layer:
We have all we need except the api. Thanks to asp .net core, that is two clicks away. Open Visual Studio and open a .net core api project. Our TweetsController class looks like the following:
namespace TweetQuery.Controllers
{
using Microsoft.AspNetCore.Mvc;
using System.Threading.Tasks;
using TweetQuery.Lib;
using TweetQuery.Lib.Model;
using TweetSearch.CosmosDb.DocumentDb;
[Route("api/[controller]")]
public class TweetsController : Controller
{
private CosmosDBRepository<Tweet> repository;
private TweetQueryContext context;
public TweetsController(CosmosDBRepository<Tweet> repository)
{
this.repository = repository;
this.context = new TweetQueryContext();
}
[HttpGet("search")]
public async Task<IActionResult> Search([FromQuery] string q)
{
if (string.IsNullOrEmpty(q))
return BadRequest();
var querySql = this.context.GenerateQuery(q).Trim();
var result = await repository.GetItemsAsync(querySql);
return Ok(result);
}
}
}
I reused the db repository we created earlier and as you see that is dependency injected in the controller which you have to configure in the ConfigureServices method in your Startup class. I’m not adding that specific code here since it is already in the sample code and doesn’t belong to the scope of this tutorial. Same goes for the model class Tweet and the classes it uses inside.
Time to test!
The project is hosted here in github. Clone the code, and build and run it from your visual studio. As a sample query try the following:
http://localhost:5000/api/tweets/search?q=to:hatena_sugoi AND from:maeta_tw OR %23HopesUp OR "Surely June is a summer"
I url-encoded the hashtag here just to be nice on the REST client you might use. I highly suggest Postman if you don’t want anything heavy.
I only took the minimalists way of using ANTLR here, you can build your own expression tree based on the auto-generated listener and can do so much more if you want. A perfect example will be LinqToQuerystring written by Pete Smith. It generates the necessary LINQ expression for any IQueryable and thus allows you to write database agnostic Odata driven queries and it’s tons faster and lighter than the one Microsoft ships.
When that is taken care of, we will move to the final validation stage and create the VM. Now from the information found newly created resource page we would go ahead and ssh into the newly created VM.
I Love C# 