Blockstack 2.0 testnet – neon


Blockstack logo

I’ve participated in several testnet blockchains by setting up nodes or doing smart contract test development. We used to call this alpha or beta testing back in the day (I could date myself and refer to Z80 and 6502 assembly language testing – but I digress). But testnet is the new decentralized beta test, and it sounds cooler. And Blockstack has recently launched their 2.0 testnet.

Participating is the best way to learn about a blockchain technology. First of all, it really helps one to understand the solution. Also, this helps promote the blockchain being tested. Finally, it validates if the solution is what you thought it was aiming to be, and it REALLY lets you know if there is a community to provide support.

Blockstack checks all of these boxes.

Blockstack is naming the phases of their testnet after noble gases, so the first phase is called “neon”. That phase is almost complete, thus this summary of activities on Blockstack Testnet Neon.

Why Blockstack

I have been following Blockstack since 2017. I was interested (and remain so) in identity and access management, and Blockstack had the concept of a distributed de-centralized name space. Our company has a patent on non-repudiation, and the concept of an identity that was not beholden to a central entity was intriguing and attractive.

I generated a Blockstack ID on November 27, 2017 using the initial Blockstack Browser. Based on that and other activity I received a voucher that would allow participation to purchase tokens for $0.12. Unfortunately the voucher had the “subject to applicable law” caveat, and the great state of Texas where I abide was not progressive then (or now) in the ways of blockchains.

The Blockstack token sale became the first SEC qualified crypto token offering in U.S. History. While many other blockchain companies were doing off-shore offerings, working to classify their work as a token the SEC shouldn’t be worried about, or simply making an offering and not worrying about the SEC ramifications, Blockstack took the long road, and paved it for others.

Blockstack has just released the testnet for their 2.0 offering. Our company has released a version of our Authorization Service product that supports Blockstack identity (sign up for the demo of the Auth Service and a demo document uploader app at this link). For all these reasons, we will most certainly be experimenting on the Blockstack 2.0 testnet.

The support from the Blockstack team and other developers on the Blockstack discord has been close to immediate and 100%. This includes questions about our development efforts (thanks to friedgar), questions about testnet set up , Clarity smart contract development, governance of Blockstack and many other topics.

Setting up Blockstack 2.0 Testnet neon

The testnet was available for setup on Thursday, April 23, 2020. The setup instructions (found here and frequently updated and improved) were very straightforward, and I was able to get a testnet node up and running that day. I was using a Mac Mini that I have isolated for these types of beta projects.

The only issue that I encountered in this setup was caused by a lack of experience with Rust. Rust is the programing language used for the node software, so as one pulls down new versions the software needs to be re-compiled (showing my age with that description but I’m okay with that). The command to rebuild/recompile is “cargo” and there were environment variables that needed to be setup to use this command.

Blockstack Testnet Mining

As soon as mining was supported, I switched my test system over to a mining node. While a non-mining node will certainly support the Blockstack network that apps will run on, by also providing a miner will help ensure support for the underlying Proof of Transfer (PoX) protocol.

Setting up a system to mine was straightforward. The instructions are in the same link above for setting up a node, added at the bottom. Since Blockstack uses the bitcoin blockchain in their Proof of Transfer (PoX) protocol, a bit of Bitcoin is required. Blockstack provided a BTC faucet. This was the only issue that I had setting up the miner – getting BTC to run the test miner with. To the Blockstack developer’s credit, when the miner starts it looks to see if there is indeed any BTC present. If there is none, the miner still starts but it defaults back to just being a regular node on the testnet. The miner has to be restarted to check again if there is BTC in the account designated in the configuration. It would also be a nice feature to have a configuration option for the miner to check periodically for a BTC balance, and then switch or restart as a miner versus a regular node.

The SIP001 document described the Burn Election, which is a large part of the PoX protocol. For our company’s interests, it also has the potential to provide a more granular timestamp direct from the STX blockchain.

From this link on SIP001 covering “Novel Properties enabled by Proof of Burn“:

Global knowledge of time — Stacks blockchain peers each perceive the passage of time consistently by measuring the growth of the underlying burn chain. In particular, all correct Stacks peers that have same view of the burn chain can determine the same total order of Stacks blocks and leader epochs. Existing blockchains do not have this, and their peers do not necessarily agree on the times when blocks were produced.

from SIP001
Screenshot of STX Miner

There are two “Did not win sortition” lines in the screen shot above, but never fear! The miner has been randomly selected several times. Proof of Transfer (PoX), the guiding algorithm of Blockstacks 2.0, utilizes bitcoin and stacks. In the screenshot the “block_commit_op” messages for the burnchain blocks are for bitcoin addresses, and the “key_register_op” messages are for Stacks addresses.

As a developer (or at least someone who manages developers and pretends to still have developer chops) it is always gratifying to not only see a well-defined set of requirements, but a result that clearly represents those requirements. In the same SIP001 document there is a step-by-step process for the “Election Protocol” for Burn (Thanks to Jason from Blockstack for pointers to this part of the document).

  1. Register key. In the screenshot, there are a couple of lines in the log for “Miner node: submitting leader_key_register op”. At the top there is even a “Skipped tenure because no active VRF key. Trying to register one now.” I assume this means that the miner was too busy with other activities to get in on the next burn.
  2. Burn & Commit. There are several burnchain sections of this log snippet, the block_commit_op entries are, I assume, the commitment transactions described in this step.
  3. Sorition: Sadly, in this snippet my miner “Did not win sortition”. But in other parts of the log file it did. WINNING!

My miner started running on the 25th and it ran with limited issues until I restarted it to pull in new code on the 30th. A five day run-time for a beta testnet node and mining node this early in the life of Stacks 2.0 demonstrates quality software. Congrats to the dev team on this.

Even though this is just testnet, I was curious about the amount of STX mined over time. I found the cURL command to check this in the documentation, but it sadly showed zero. So either it is the wrong command or in this version of testnet only represents Proof of Burn and one of the next versions will include Proof of Transfer. Update: it does appear that mining balances are part of Phase 3: Krypton.

Clarity Smart Contract Hackathon

As part of the Stacks 2.0 testnet Blockstack introduced the Clarity Smart Contract language. The main differences between Clarity and other smart contract languages are:

  • Clarity is interpreted, and not compiled. My only concern with this is that compiled code is usually faster to execute versus interpreted code – this will need further testing.
  • Clarity is not Turing complete (unlike Solidity, the smart contract language for Ethereum).

Blockstack hosted a Hackathon to promote (and I assume debug) the usage of Clarity. This Hackathon ran May 14 – May 29th, 2020. This was the first of two Hackathons, with the second targeted specially at tooling. The first Hackathon had three levels (beginner, intermediate and advanced).

Getting setup for Clarity development for me involved just a few steps:

  • making sure my versions of node, npm and other tools were up to date.
  • understanding the file structure from the Clarity tutorials
  • understanding the Test Driven Development functionality – which is similar to what we do anyway.
  • learn Clarity – which gave me flashbacks to developing in Lisp in college.

As part of our company’s solution for workflow automation I targeted our Hackathon solution at simulating tasks of a workflow that are part of a smart contract. A snippet is below.

;; these are the basic task and subtask possible status states
;; ideally these should be mutually exclusive. will put a test for that in a private function
;; by default a task is not used until it is either moved to notstarted, inprocess, complete or cancelled 
(define-data-var notused bool true)
(define-data-var notstarted bool false)
(define-data-var inprocess bool false)
(define-data-var complete bool false)
(define-data-var cancelled bool false)
;; define read-only functions
(define-read-only (get-task-status)
  {notused: (var-get notused), notstarted: (var-get notstarted), inprocess: (var-get inprocess), complete: (var-get complete), cancelled: (var-get cancelled)}

The beginner version just defined the task statuses. The second tried to pull timestamps from the last block in the blockchain. And the third attempted to utilize an escrow smart contract developed by Friedger to distribute STX tokens at the completion of a task.

As mentioned earlier, for the purposes of tracking tasks that are time or Service Level Agreement (SLA) based, we are quite interested in the “Global Knowledge of Time” feature. The Clarity work to include time was inconclusive, as this version of testnet has only proof of burn and not proof of transfer, which would provide that level of time granularity. We’ll try again on the next version of testnet.

A link to GitHub containing all three contracts plus testing can be found here.

The Hackathon was very well supported by Blockstack and by all of the developers in the forum.

Next – Testnet Argon

In the next few days (I assume) Blockstack will move the testnet into the next phase, code named Argon (as opposed to Aragorn – who is a noble LOTR character, not a noble gas). As mentioned, it will feature a new Hackathon targeted at tooling, and potentially the ability to test full Proof of Transfer with STX mining. We may not participate in the tooling Hackathon unless there is an opportunity to further prove out the timestamping. But we will participate in the PoX testing.

You may also like...

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: