Block.ops - An Analysis Tool - Account Creation, Account Claiming, Follows, Unfollows, Reblogs, Power Ups, Power Downs and More!

A very busy week with three sets of blockchain transactions tackled covering ten different block operations! I also coded a number of new analysis functions and produced my third formal analysis using the block.ops system. I'm pretty pleased that, despite a fair number of complications, the project is now starting to produce those heavy analyses that were one of the main reasons behind its inception.

This represents the completion of the first stage of block operations that I plan to include in block.ops. Whilst there remains a long list of operations still to cover (for example witness operations and rewards, savings wallet transactions, internal market transactions) the first set of block operations cover the vast majority of everyday tasks. I will now turn towards loading / testing / optimising and adding some of the other functionality that the system needs.

Block operations added

• Account Creation block operartions (account_create, account_create_with_delegation, claim_account and create_claimed_account);
• Custom_json block operations (follows, unfollows and reblogs);
• Vesting block operations (transfer_to_vesting - power up, withdraw_vesting - power down, and fill_vesting_withdraw - power down payments).

Development of analyses

• New analysis for account creation operations;
• New analysis for follows, unfollows and reblogs;
• New analysis for power up and power down amounts;
• Updates to the Utopian analysis.

A couple of bug fixes

• Vote operation bug correction;
• Transfer operation bug removal.

---

For the last year I have carried out a monthly analysis of the Steem blockchain activity by application (i.e. by the different websites and applications through which you can post to the Steem blockchain - often termed dApps).

My aim is now to build a tool that can automate such complex analyses of Steem data, providing both historic time series and rapidly updatable real-time results. In addition to the dApp analysis there are many other projects for which such a system could be useful.

This tool is Block.ops.

You can read all about block.ops (including the project aims, technology stack, roadmap and how to contribute) in the introductory post here:
https://steemit.com/utopian-io/@miniature-tiger/block-ops-an-analysis-tool-1537300276791

---

Repository

https://github.com/miniature-tiger/block.ops

---

New Features

Account Creation block operartions and new Analysis

Post HF20 there are now four different Steem blockchain operations associated with account creation:

• account_create - the original and basic operation;
• account_create_with_delegation - the above operation inclulding some delegated Steem Power;
• claim_account - claiming accounts with resource credits (new for HF20); and
• create_claimed_account - turn a claimed account into an actual account (new for HF20).

These operations are now all handled by the block.ops system and stored in a new collection 'createAccounts' in the MongoDB database.

I added some analyses that perform the tasks of summarising account creation operations by hour and by creator with count, fees and delegation information. As an example here is a chart showing that you needed to get up early after HF20 to complete with accounts using the new claim_accounts functionality!

The code changes are here:
https://github.com/miniature-tiger/block.ops/pull/8/commits/c5dea90357d8530fb80f29d18c5bfe7622be924b

Custom_json block operations (Follows, Unfollows, Reblogs) and new Analysis

The custom_json block operations of the Steem blockchain are interesting. For everyday use they record account follow and unfollow transactions and reblogs. With the introduction of steemmonsters there are also now a large proportion covering the card transactions and battles. Finally there are a few transactions using the custom_json to store data.

These last two uses show the potential for the Steem blockchain to reach wider that its current basic functionality. I expect to see more devs following the steemmonster lead in the coming year.

For block.ops I decided to only capture follows, unfollows and reblog transactions. I expect that there will be summaries of steemmonsters progress and battles produced by the team themselves. It's something I can always come back and change later.

Follows, unfollows and reblogs are now handled within the block operations loop and stored within a separate "follows" collection in the MongoDB database. Whilst it may seem strange to include reblogs with follows in the database, the Steem blockchain actually records reblogs as a 'follow' of a particular post, so the data structure and processing required is similar.

I created an new analysis which summarises the highest number of follows and reblogs over a specific time/block range. For example:

• A summary of the highest number of follows received over the day.
• A summary of the most reblogged posts over the day.

Some raw output showing the the top reblogged posts for 2 October:

There are some interesting investigations that I have planned by expanding this starting analysis.

The code changes are here:
https://github.com/miniature-tiger/block.ops/pull/8/commits/cc3bf62cf72230c1c2f6e428bcde0d2cc7a6f5d9

Vesting block operations

Vesting operations are:

• transfer_to_vesting - Power up;
• withdraw_vesting - Power down; and
• fill_vesting_withdraw - A virtual operation representing the power down payment.

When you start to look at analyses with these operations you realise that there are some subtleties worth considering. A Power Up is not the opposite of a Power Down; under the former the whole amount is converted immediately, whilst for the latter the amount conversion takes place over 13 weeks. There may be far more Power Ups than Power Downs, since the former is a repeat task for those looking to stack, whilst the latter may only be triggered once and then left to run. Worth bearing in mind if you ever look at summaries of Power Ups v Power Downs.

These operations are now handled by the block.ops system and stored in a new collection 'vesting' in the MongoDB database.

Finally I added some more analyses which summarise:

• Power ups, power downs, and power down payments by date.
• Highest power ups and power downs by account over selected time period.

As an example:

Misterdelegation with the big stick, before you ask.

The code changes are here:
https://github.com/miniature-tiger/block.ops/pull/8/commits/7106fc05e5fedf216f2926590ba7ea2b0f7ce05e
and here:
https://github.com/miniature-tiger/block.ops/pull/8/commits/b8457c3b13c33fe8e118545158d7b1bad637a76c

Utopian Analysis

I added a raft of new functionality to the Utopian Vote Analysis, in particular the vote duration analysis, and presented this as the third analysis from the block ops system!

You can see the final analysis here:
https://steemit.com/utopian-io/@miniature-tiger/utopian-io-vote-analysis-october-2018

The code changes are here:
https://github.com/miniature-tiger/block.ops/pull/8/commits/57698fd1be337cfd25e95085184ed88bfb0c0c68

A couple of bug fixes

• Vote operation bug correction. Code here:
  https://github.com/miniature-tiger/block.ops/pull/8/commits/d917bbebc9558b3bf24d5e8658a3311ac52739df

• Transfer operation bug removal. Code here:
  https://github.com/miniature-tiger/block.ops/pull/8/commits/6ba63379c83fed9dc29eb5cad0e4cd77780c92db

As a final random thought, would it be useful to include bug fixes (those on other people's projects) in the contribution 'bugs' rather than 'development'. Bug fixing is useful, but unlikley to receive a high score and less likely to receive an upvote under the new voting bot. Some kind of separation could be in order.

Progress!

---

GitHub Account

My account on github is here:
https://github.com/miniature-tiger