Initial Witness and Full Node Innovations –

in #budget6 years ago (edited)

Since long before we announced our Steem witness, @dutch and I have been making operational enhancements to steemd, the Steem daemon.

It is our goal to run a reliable witness, and then go above and beyond by improving how witnesses (and other Steem nodes) are run.


We believe in sharing our implementations once they are stable enough to run on so that all Steem nodes can benefit.

Here's what we've released so far:

We would like to gauge the community's interest on what tutorials they want to see next. Check out what else we've done in the "Innovations" section below and let us know what you'd like us to elaborate on and write more about.



Our greatest achievement so far in operational enhancements to Steem has been reducing the amount of memory needed to run a node (witnesses and full nodes alike). Any Steem node can make use of zram to compress the in-memory database of steemd.

The first success story aside from our own witness came from @someguy123 and his RPC node with 256GB of RAM. You can read about this at the top of this article.

Since then, the community began adopting zram as a best practice for Steem nodes. We are pleased to see that @themarkymark has begun rolling out zram on his witness nodes and full nodes.


Our Steem nodes' storage infrastructure is based on ZFS, which offers a lot:

  • Reduced disk usage: We compress the Steem blockchain to a ratio of about 1.58× (37% space savings) by storing it on an LZ4-compressed ZFS dataset.

    One day, the blockchain is going to be 100GiB large, and under our current setup, we expect to be storing all that in only 63GiB. (The compression ratio hasn't been changing much.)

    If 100 active Steem nodes use the same compression at that point in time, they'd collectively save about 3700GiB in storage. This is especially meaningful for people running off SSDs because SSD storage is typically expensive.

  • Quick screw-up recovery: Also thanks to ZFS, we are able to roll back to snapshots of our Steem nodes in case we corrupt our copy of the blockchain or even accidentally delete everything on the node.

    We've actually had this kind of disaster scenario twice already. Our backup witness took over, we rolled back the primary witness in a few seconds, then the primary witness caught up. The alternative would have been waiting hours to download the blocks and more hours to replay the blockchain, which would have certainly led us to missing blocks.

    As a bonus, thanks to how the blockchain is stored, snapshots hardly take up any additional space at all.

  • Easy backups: ZFS snapshots also let us back up our Steem nodes with ease. We can stream the datasets (zfs send/zfs receive) to whatever backup location we want (currently a nearby NAS over NFS). Snapshots are also incremental, which means only changes need to be sent over to backup storage.

  • Accelerated performance: The best practice advice is to store the blockchain on an SSD, but we are able to achieve acceptable performance on an HDD because of the ZFS Adjustable Replacement Cache (ARC), which speeds up access to the most frequently and most recently used data on disk.

  • Data corruption prevention: Yet another benefit of ZFS is how it checksums all data that it stores. Even if one (or both!) of our hard drives silently flip some bits and corrupts anything, ZFS will very likely be able to recover instantly upon reading the mismatched bits.

    At just 152 hours into service, the server we're hosting on already had a data corruption scenario where some disk sectors were unreadable. The ZFS mirror (equivalent to RAID 1) did exactly what it was supposed to and corrected the unreadable bits. We replaced the disk, and the data seamlessly "resilvered" onto the new hard drive.


Virtualization lets us take advantage of the technologies outlined above. Our witness nodes run on virtual machines, which in turn are run on dedicated hardware that we control. This lets us connect the software stack to the hardware how we want it.

Aside from facilitating the memory and storage innovations, virtualization also has benefits of its own:

  • Isolation: The witness nodes run in their own environments so that they can't interfere with the operational infrastructure below.
  • Security: If the nodes are compromised by some unforeseen vulnerability, we can stop it in its tracks, go back in time, and rectify the vulnerability before it's exploited again.
  • Overhead: Virtual machines don't have the hardware overhead of dedicated servers, so starting up is much faster.
  • Portability: In combination with ZFS snapshots, we've opened the possibility of migrating the witness to another physical server if we ever need to upgrade.

STEEM Price Feed

Many top witnesses use the same STEEM price feed software, which means if they're configured similarly, they can all go down at the same time. This could soon lead to outdated price feeds from major influencers.

We don't have a catch-all solution for price feed downtime (yet?), but we do have an alternative option: @deltik's Python STEEM Price Feed Updater (python-steemfeed).

This is not a "better" price feed updater. It's just a different one, and the objective is to introduce a bit of heterogeneity and diversity in price feed updates.

Here's what makes python-steemfeed v0.1.0 different:

  • Simple: The script does just one thing: Update your witness's price feed from CoinMarketCap data.
  • Uses official STEEM library: The script uses steem-python, the official Python STEEM library, to interface with the wallet and witness.
  • Batteries included: For 64-bit Debian and Ubuntu users, Python 3.6 (required by steem-python) and all Python dependencies are bundled in the repository. There are also installation instructions for required Python shared libraries (if necessary) and other distros.

Future Innovations


  • Even less disk usage: Our early tests have revealed that the blockchain could have a 1.83× compression ratio (45% space savings) with only a small loss in throughput. We are planning on setting this up with Linux kernel 4.14 or newer and the Zstandard compression algorithm.

    If the blockchain were 100GiB large, the current LZ4 compression algorithm would squash that into about 63GiB, but Zstandard could potentially reduce this to 55GiB.

  • Shared storage: Budget permitting, we'd like to set up distributed/clustered storage on which we'd run our Steem nodes so that physical servers can be taken down while the virtual machines stay up.

Steem Daemon

  • Active/active cluster: There could be a way for two or more witnesses to run with the same signing key but not cause a fork. The end result would be that your fastest witness stakes a block and your other witnesses that try to stake a block are gracefully ignored. If implemented, missed blocks could become a thing of the past.

    One possibility could be a proxy to the RPC nodes that intercepts the late blocks and rejects them so that the minority witnesses can abort their fork and continue on the accepted chain before they're called upon again to stake a block.

  • Eliminating blockchain replays: If steemd's in-memory database is preserved, it can be used to resume a new run of the daemon without replaying the blockchain (--replay-blockchain). The problem is that since the database is meant to be in memory, it gets erased on server crash or reboot.

    We intend to explore ways to persist the data on disk asynchronously so that steemd can resume without a blockchain replay, even after an unexpected crash.

Server Specifications

If you want to know what specs we've got, here they are:

Dedicated Server

CPU: Intel® Xeon® Processor D-1521 @ 2.40GHz
Memory: 64GB DDR4-2666 ECC
Disk: 2×480GB SSD and 2×2TB HDD
Bandwidth: 250Mbps
Operating System: Ubuntu 16.04 LTS

Steem Witness Virtual Machine

CPU: 4 logical cores of Intel Xeon D-1521
Memory: 16GiB plus 16GiB zram
Disk: 400GiB ZFS volume
Bandwidth: Unmetered
Operating System: Ubuntu 16.04 LTS


@jerrybanfield has identified as a low-ranked witness that qualifies for a generous donation.

We are publishing this initial update to show what has already been implemented and what is in the works. @jerrybanfield's donation would help us develop better ways to operate Steem and Graphene nodes that we would then bestow back on the community.

The witness is at the forefront of all the improvements outlined in this article. To support this witness, visit and add to the box at the bottom of the page, click vote, and authorize using your Active Key.

We want to continue innovating and sharing our discoveries. Please let me or @dutch know what other topics you'd like us to explore.


@deltik thank you very much for sharing with us what you are doing as a witness here, how you make your price feed, and helping me see the post for the 100 Steem! I just sent it from @budgets now!

Python STEEM Price Feed Updater

Are you going to look into alternative price feed sources than just coinmarketcap? If it goes down, so to will your scheduled price feeds.

Alternative price feed sources are on the table; however, it gets more complicated without CoinMarketCap:

  • Maintainability: APIs change, and each of them have their own quirks to work out.
  • Weighted averages: To get closer to the actual market value, one should look at the average price across the STEEM exchanges, weighted by trading volume. CoinMarketCap does this very well already, and it would be a challenge to clone CoinMarketCap to keep the average prices feature.
  • Service unavailable: The various markets and alternative price feeds may decide to deny service to the client, which could either prevent a price feed update or skew the weighted average.
  • More bandwidth: Asking other sources multiplies the number of API requests necessary to obtain prices.

I will add here that we also keep an eye on the price feed manually. Just recently the bandwidth of our node ran out and stalled the price feed for a short while. The update interval has since been increased to every 15 minutes.

I really like your posts and I enjoy very much with all your posts.👍

I love this!!!

What an interesting post, I hope that all your project is successful, you do it for the good of all, keep it up, regards.

thank you my friend @deltik for your good
and uesfully post

Congratulations @deltik, this post is the eighth most rewarded post (based on pending payouts) in the last 12 hours written by a Newbie account holder (accounts that hold between 0.01 and 0.1 Mega Vests). The total number of posts by newbie account holders during this period was 4931 and the total pending payments to posts in this category was $5431.48. To see the full list of highest paid posts across all accounts categories, click here.

If you do not wish to receive these messages in future, please reply stop to this comment.

Congratulations @deltik! You have completed some achievement on Steemit and have been rewarded with new badge(s) :

Award for the number of upvotes received

Click on any badge to view your own Board of Honor on SteemitBoard.
For more information about SteemitBoard, click here

If you no longer want to receive notifications, reply to this comment with the word STOP

By upvoting this notification, you can help all Steemit users. Learn how here!

Congratulations @deltik! You have received a personal award!

1 Year on Steemit
Click on the badge to view your Board of Honor.

Do not miss the last post from @steemitboard:
SteemitBoard World Cup Contest - Quarter Finals - Day 2

Participate in the SteemitBoard World Cup Contest!
Collect World Cup badges and win free SBD
Support the Gold Sponsors of the contest: @good-karma and @lukestokes

Do you like SteemitBoard's project? Then Vote for its witness and get one more award!

Congratulations @deltik! You received a personal award!

Happy Birthday! - You are on the Steem blockchain for 2 years!

You can view your badges on your Steem Board and compare to others on the Steem Ranking

Vote for @Steemitboard as a witness to get one more award and increased upvotes!

Coin Marketplace

STEEM 0.25
TRX 0.14
JST 0.035
BTC 51122.17
ETH 2943.29
USDT 1.00
SBD 4.24