On Thursday August 1st, Guardian Circle participated in NEO Global Development’s new NEO LIVE series, an Ask Me Anything (AMA) styled community event that takes place on the official NEO Telegram. Guardian Circle co-founder and CTO, Chris Hayes, participated in the event, answering questions and outlining the project’s tech stack.

The full transcript of the event can be found below:

Songping Que: Hi, everyone, welcome to the second NEO Live on Telegram!!! This is Songping Que from NGD Marketing team and I will be your host tonight. Before the session starts, I would like to repeat the background of the NEO Live initiative in case that you are new to the group.

NEO Live is a marketing initiative from NEO Global Development, to bring latest blockchain knowledge and NEO news to the community. It’s one hour live chatting every Thursday night 8pm (UTC+8) in NEO official telegram group (https://t.me/NEO_EN). NGD core teams/NEO Eco Project leaders/NEO dev community leaders/pioneering blockchain leaders will be invited to share latest technological development, industry insights with the community members.

Our guest today is Chris Hayes, co-founder & CTO from Guardian Circle. Chris is a technologist, advisor, podcaster and serial entrepreneur. Chris’ credits include leading engineering teams at aerospace firms, Fortune 500 companies and consumer web platforms. Chris previously founder ShoutEngine, a hugely popular podcast publishing platform as well as building some of the largest podcasts in the automotive vertical.

Chris Hayes: Hello everyone. Good morning, afternoon evening etc. wherever you’re from. Hi Songping, thanks again to the NEO team for the invitation to address the community.

Songping: The Guardian Circle team has recently learned a lot in setting up their own NEO node on AWS to make their in-app $GUARD wallet run — including being able to differentiate tokens specifically. To pass along the knowledge, Chris will have a quick sharing, focusing on building a high availability NEO dApp. Please kindly hold your questions a little until the sharing ends.

So Chris, feel free to start your sharing 😄

Chris: Will do!

Today I’d like to start out with some discussion regarding our platform, the tech we chose to build Guardian Circle with, and how we interact with the blockchain.

While we utilize the NEO blockchain, Guardian Circle is very much a hybrid of conventional backend-end API frameworks, mobile frameworks and blockchain tools. Our back-end is mostly built using python (+ django) with a bit of Node.js as well. Those languages were picked specifically for the vast array of toolsets available and more importantly fantastic community support for integration with the NEO blockchain.

As the blockchain isn’t a suitable place for ALL data when it comes to building an application, we also utilize PostgreSQL and MongoDB for storage of system and user data. This of course has all been built inside Amazon Web Services.

A key part of our planning for scalability is the usage of AWS lambda for hosting our API. Lambda in conjunction with Amazon’s autoscaling RDS ensures that we can support many thousands of concurrent emergency alerts and millions of users on any given day.

One of the nice side-benefits of using Lambda is that we do not have API/Web servers to maintain. Servers are effectively launched instantly as users make requests to our API and and shut down as soon as they respond to the end-user. This is all done in counts of milliseconds (usually 100-400 ms) rather than seconds.

Given the “servers” are online for less than a second that also means we have an exceptionally small attack vector for anyone wishing to target the host OS/Server to attempt to to take control of our back-end. In short, VERY VERY difficult if not nearly impossible to accomplish.

Another side benefit is that we only pay for the computing resources we use, keeping overhead relatively low in comparison to a “conventional” API server configuration.

So with all of those considerations in place for scalability, and the want for Guardian Circle users to experience a positive user-experience interacting with our app and the blockchain, I made the call that we’d need to have our own blockchain nodes to ensure security and performance.

Additionally, if we’re successful in our mission of delivering a peer-to-peer safety network utilizing the NEO blockchain, we also would not want to be putting undue burden on other group’s NEO nodes. (looking at you COZ, O3 and NGD)

One of the things that makes NEO great is its implementation of an RPC API (remote procedure call application programming interface). Basically what this means is that developers can interact with the NEO nodes via a standard programming API without having to write to the blockchain directly.

This saves a massive amount of time/effort for doing basic tasks like querying for account balances, retrieving transactions, and other typical blockchain activity.

There are more-or-less two players in town right now for running a NEO node – and that’s using the official NEO-CLI (command line interface) or City of Zion’s neo-python. I’ve got a lot of experience with both and we ultimately utilized the “official” NEO CLI, running as a daemon on our Linux back-end to power our nodes.

The COZ node is great too, however, it is a bit behind the “official” release in terms of features which is a major concern for us.

So setting up the NEO-CLI as a proper daemon on a Linux server can be a bit daunting if you aren’t fairly experienced managing Linux boxes. After we release Guardian Circle 3.0 to the public, I plan on publishing my knowledge on the matter to help other people with their rollouts.

Our node setup is pretty similar to what exchanges implement and we’re every bit as concerned with reliability as they are.

We currently keep a total of 3 NEO nodes online at all times. The thing that differentiates how we’ve done this from other people is that we built a monitoring and load balancing layer over these servers, and we do not allow the NEO-CLI to directly negotiate SSL communications.

Each of our nodes also includes an installation of the Nginx web server. Nginx handles all SSL communications directly and passes all RPC API calls back to the NEO-CLI.

While we love the devs over at NEO, Nginx is a VERY trusted and high performing web server and it handles SSL communications exceptionally efficiently, and affords us a lot of options in terms of configurability and scaling. By placing that in front of the NEO-CLI we gain a lot of flexibility.

However before any API requests ever reach those nodes they reach a set of Node.js tools I’ve built to ensure end-users reach a healthy NEO node. These tools monitor each of the blockchain nodes for responsiveness, latency and block height. If any given server in our cluster is unresponsive, slow, or out of sync, our routing software pulls it from the group to ensure that user transactions always execute properly on the blockchain.

Looping back to an earlier statement I’d made regarding our choice of Python and Node.js, the libraries/toolsets for interacting with these RPC APIs is key to our success.

Frankly, the people over at City of Zion are quite possibly the biggest driving force in development as they are making nearly all of the programming tools outside of the C# tools released by NEO corporate.

Neo-Python, Neo-Python-Core, Neo-Python-RPC, Neon-JS, Neon-nep5 are absolutely amazing tools that we utilize for interacting with the NEO blockchain. They are simply some of the best tools I’ve seen for ANY blockchain and really do set NEO apart from many of its competitors.

We have friends developing on EOS and there simply isn’t an analog in that universe.

So regarding all the FUD you hear of people running to other blockchains, be aware that the quality of tools in the NEO universe is FAR beyond those on most other blockchains and as soon as devs figure this out it can end that consideration.

Songping: Chris, this is great! Thanks a lot for sharing the tech stack of Guardian Circle. Appreciate Guardian Circle’s engagement to the community and deep investigation into the tools available in the NEO ecosystem.💪

So everyone, it’s Q&A session now! To make it easy for the team to trace the question, please kindly number your questions, starting from 1. eg. A raise question starting with Q1, then B raises questions starting with Q2. Please keep the questions about NEO and Guardian Circle, we will remain the right to select the questions. Also the team won’t make comments on the token price.

Chris: You’re very welcome. Honestly, I could go longer but we’ve only got so much time allotted this morning 🙂

Happy to answer any questions people may have regarding what I’ve written above, dev/engineering in general or about Guardian Circle and the GUARD token.

Q1) How long have you been working with blockchain technology?

Chris: I’ve been actively developing blockchain tech for approximately two years however I’ve been keeping up on the technical implementations and doing deep dives into various blockchains for about 5 years.

Q2) Have you noticed a pattern of neo-cli nodes maxing out CPU/experiencing excessive memory usage over a regular time interval (requiring a restart), or are they mostly stable in your environment with just the occasional restart required?

Chris: I have in fact seen that in the past. *fingers crossed* our boxes have been stable for a while now. The pattern I usually notice is having inadequate amounts of RAM on a machine or having them on heavily utilized shared environments being an issue.

I’m running our nodes on a Ubuntu and have them set up as true Daemons running as a restricted user, FYI.

Q3) Were there any features you felt you were missing within the NEO ecosystem?

Chris: I would say the biggest thing missing is more native support in the RPC-CLI for working with NEP-5 assets and flexibility working with signed transactions. Some tools are there, but there are a few features that are unduly difficult to accomplish right now, specifically in regard to NEP-5 assets. However I’m sure this will evolve over time, all blockchains currently have glaring holes in certain aspects of their implementations currently.

Q4) Why did you choose NEO blockchain and not others like Ethereum or EOS?

Chris: The first thing that brought me to NEO (then it was Antshares) was the idea of the NEO VM and its flexibility. As time has gone on the dev tools and quality of consumer facing wallets have made NEO clearly stand out vs. others (predominantely EOS).

Another reason is frankly political stability and direction is strong in NEO. It’s no secret EOS is a constant roller-coaster and I tend to lean towards organizations with clear direction in terms of governance and tech.

Mark Jeffery (co-founder and CEO): One other big consideration: new accounts on EOS cost $1-$2 to create (in staked EOS). If we had selected EOS, and Guardian Circle were to suddenly get 10M users, that would cost us $10M-$20M (since we create a new NEO / $GUARD account for every Guardian Circle user to support the in-app $GUARD wallet). In NEO, new accounts are free to create. Big difference. 🙂

Q5) Can you tease a little bit about your upcoming release? What goodies are on the horizon in your app?

Chris: In GC 3.0 we have completely rewritten the app from the ground up using Google’s Flutter framework, it’s much faster, better designed and is honed in terms of focus as a result of lessons learned from prior releases. One of the key features is our new in-app wallet that brings verified identity to the NEO blockchain.

Q6) What issues did your first contract have?

Chris: We based our first contract on an open source “token sale” contract that had a feature built in that did not properly check an input and it could have facilitated the ability for an individual to acquire tokens and permanently burn them. It would be a costly exploit to execute but an exploit indeed, you’d just be burning your own $$$ to make it happen 🙂

Q7) Will NEO 3.0 simplify your efforts? And will it (let’s state it frankly) make it “cheaper” (I mean efforts and time)?

Honestly Oli, I don’t have a great answer on that yet. While I was at DevCon and have done some reading on V3 I’m not yet well enough-versed to know every way it will effect us. I’ve been occupied with getting GC 3.0 released to the public and plan on catching up on this as soon as we’ve got v3.0 out the door.

Q8) NEO 3 will be available in 2020 – Do you need to make changes on your backed code in order to support it?

Chris: I refer to the last answer I left for Oli regarding V3. From what I do know we’ll likely require some changes but I’m not well enough educated on the matter nor are the final specs of NEO 3.0 nailed down to the point where I feel I can answer this yet.

Note: Some edits have been made for formatting and readability. The full conversation can be found at https://t.me/NEO_EN.

Tags: ,