<p dir="auto">Since long before we <a href="https://steemit.com/witness-category/@dutch/announcing-the-gridcoin-science-witness-stem-on-steem" target="_blank" rel="noreferrer noopener" title="This link will take you away from hive.blog" class="external_link">announced our Steem witness @gridcoin.science<code>steemd, the Steem daemon.<span>, <a href="/@dutch">@dutch and I have been making operational enhancements to <p dir="auto">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. <h2>Tutorials <p dir="auto"><span>We believe in sharing our implementations once they are stable enough to run on <a href="/@gridcoin.science">@gridcoin.science so that all Steem nodes can benefit. <p dir="auto">Here's what we've released so far: <ul> <li><strong><a href="https://steemit.com/witness-category/@deltik/make-your-steem-server-last-longer-with-memory-compression" target="_blank" rel="noreferrer noopener" title="This link will take you away from hive.blog" class="external_link">Make Your Steem Server Last Longer With Memory Compression <li><strong><a href="https://github.com/Deltik/python-steemfeed" target="_blank" rel="noreferrer noopener" title="This link will take you away from hive.blog" class="external_link">Python STEEM Price Feed Updater <p dir="auto">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. <h2>Innovations <h3>Memory <p dir="auto">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 <a href="https://www.kernel.org/doc/Documentation/blockdev/zram.txt" target="_blank" rel="noreferrer noopener" title="This link will take you away from hive.blog" class="external_link">zram to compress the in-memory database of <code>steemd. <p dir="auto"><a href="https://steemit.com/witness-category/@deltik/make-your-steem-server-last-longer-with-memory-compression" target="_blank" rel="noreferrer noopener" title="This link will take you away from hive.blog" class="external_link">this article.<span>The first success story aside from our own witness came from <a href="/@someguy123">@someguy123 and his RPC node with 256GB of RAM. You can read about this at the top of <p dir="auto"><a href="https://steemit.com/witness-category/@themarkymark/why-you-should-vote-for-themarkymark-as-witness" target="_blank" rel="noreferrer noopener" title="This link will take you away from hive.blog" class="external_link">rolling out zram on his witness nodes and full nodes.<span>Since then, the community began adopting zram as a best practice for Steem nodes. We are pleased to see that <a href="/@themarkymark">@themarkymark has begun <h3>Storage <p dir="auto">Our Steem nodes' storage infrastructure is based on <a href="https://github.com/zfsonlinux/zfs/wiki" target="_blank" rel="noreferrer noopener" title="This link will take you away from hive.blog" class="external_link">ZFS, which offers a lot: <ul> <li><p dir="auto"><strong>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. <p dir="auto">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.) <p dir="auto">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. <li><p dir="auto"><strong>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. <p dir="auto">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. <p dir="auto">As a bonus, thanks to how the blockchain is stored, snapshots hardly take up any additional space at all. <li><p dir="auto"><strong>Easy backups: ZFS snapshots also let us back up our Steem nodes with ease. We can stream the datasets (<code>zfs send/<code>zfs receive) to whatever backup location we want (currently a nearby <a href="https://en.wikipedia.org/wiki/Network-attached_storage" target="_blank" rel="noreferrer noopener" title="This link will take you away from hive.blog" class="external_link">NAS over <a href="https://en.wikipedia.org/wiki/Network_File_System" target="_blank" rel="noreferrer noopener" title="This link will take you away from hive.blog" class="external_link">NFS). Snapshots are also incremental, which means only changes need to be sent over to backup storage. <li><p dir="auto"><strong>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. <li><p dir="auto"><strong>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 <a href="https://en.wikipedia.org/wiki/Data_corruption#SILENT" target="_blank" rel="noreferrer noopener" title="This link will take you away from hive.blog" class="external_link">silently flip some bits and corrupts anything, ZFS will very likely be able to recover instantly upon reading the mismatched bits. <p dir="auto">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 <a href="https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_1" target="_blank" rel="noreferrer noopener" title="This link will take you away from hive.blog" class="external_link">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. <h3>Virtualization <p dir="auto">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. <p dir="auto">Aside from facilitating the memory and storage innovations, virtualization also has benefits of its own: <ul> <li><strong>Isolation: The witness nodes run in their own environments so that they can't interfere with the operational infrastructure below. <li><strong>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. <li><strong>Overhead: Virtual machines don't have the hardware overhead of dedicated servers, so starting up is much faster. <li><strong>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. <h3>STEEM Price Feed <p dir="auto">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. <p dir="auto"><a href="https://github.com/Deltik/python-steemfeed" target="_blank" rel="noreferrer noopener" title="This link will take you away from hive.blog" class="external_link">Python STEEM Price Feed Updater (<a href="https://github.com/Deltik/python-steemfeed" target="_blank" rel="noreferrer noopener" title="This link will take you away from hive.blog" class="external_link"><code>python-steemfeed).<span>We don't have a catch-all solution for price feed downtime (yet?), but we do have an alternative option: <a href="/@deltik">@deltik's <p dir="auto">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. <p dir="auto">Here's what makes <a href="https://github.com/Deltik/python-steemfeed/releases/tag/v0.1.0" target="_blank" rel="noreferrer noopener" title="This link will take you away from hive.blog" class="external_link"><code>python-steemfeed v0.1.0 different: <ul> <li><strong>Simple: The script does just one thing: Update your witness's price feed from <a href="https://coinmarketcap.com/" target="_blank" rel="noreferrer noopener" title="This link will take you away from hive.blog" class="external_link">CoinMarketCap data. <li><strong>Uses official STEEM library: The script uses <a href="https://github.com/steemit/steem-python" target="_blank" rel="noreferrer noopener" title="This link will take you away from hive.blog" class="external_link"><code>steem-python, the official Python STEEM library, to interface with the wallet and witness. <li><strong>Batteries included: For 64-bit Debian and Ubuntu users, Python 3.6 (required by <code>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. <h2>Future Innovations <h3>Storage <ul> <li><p dir="auto"><strong>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 <a href="https://facebook.github.io/zstd/" target="_blank" rel="noreferrer noopener" title="This link will take you away from hive.blog" class="external_link">Zstandard compression algorithm. <p dir="auto">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. <li><p dir="auto"><strong>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. <h3>Steem Daemon <ul> <li><p dir="auto"><strong>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. <p dir="auto">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. <li><p dir="auto"><strong>Eliminating blockchain replays: If <code>steemd's in-memory database is preserved, it can be used to resume a new run of the daemon without replaying the blockchain (<code>--replay-blockchain). The problem is that since the database is meant to be in memory, it gets erased on server crash or reboot. <p dir="auto">We intend to explore ways to persist the data on disk asynchronously so that <code>steemd can resume without a blockchain replay, even after an unexpected crash. <h2>Server Specifications <p dir="auto">If you want to know what specs we've got, here they are: <h3>Dedicated Server <blockquote> <p dir="auto"><strong>CPU: Intel® Xeon® Processor D-1521 @ 2.40GHz<br /> <strong>Memory: 64GB DDR4-2666 ECC<br /> <strong>Disk: 2×480GB SSD and 2×2TB HDD<br /> <strong>Bandwidth: 250Mbps<br /> <strong>Operating System: Ubuntu 16.04 LTS <h3>Steem Witness Virtual Machine <blockquote> <p dir="auto"><strong>CPU: 4 logical cores of Intel Xeon D-1521<br /> <strong>Memory: 16GiB plus 16GiB zram<br /> <strong>Disk: 400GiB ZFS volume<br /> <strong>Bandwidth: Unmetered<br /> <strong>Operating System: Ubuntu 16.04 LTS <h2>Acknowledgements <p dir="auto"><a href="https://steemit.com/witness-category/@jerrybanfield/100-steem-for-witnesses-below-rank-80" target="_blank" rel="noreferrer noopener" title="This link will take you away from hive.blog" class="external_link">low-ranked witness that qualifies for a generous donation.<span><a href="/@jerrybanfield">@jerrybanfield has identified <a href="/@gridcoin.science">@gridcoin.science as a <p dir="auto"><span>We are publishing this initial update to show what has already been implemented and what is in the works. <a href="/@jerrybanfield">@jerrybanfield's donation would help us develop better ways to operate Steem and Graphene nodes that we would then bestow back on the community. <p dir="auto"><strong>gridcoin.science to the box at the bottom of the page, click vote, and authorize using your Active Key.<span>The witness <a href="/@gridcoin.science">@gridcoin.science is at the forefront of all the improvements outlined in this article. To support this witness, visit <a href="https://steemit.com/~witnesses" target="_blank" rel="noreferrer noopener" title="This link will take you away from hive.blog" class="external_link">https://steemit.com/~witnesses and add <p dir="auto"><center><a href="https://steemit.com/~witnesses" target="_blank" rel="noreferrer noopener" title="This link will take you away from hive.blog" class="external_link"><img src="https://images.hive.blog/768x0/https://steemitimages.com/DQmcdJwtxDGhAPeB2oGn2F8K4nQKaogVpQfd4oXoQDLn9uZ/image.png" srcset="https://images.hive.blog/768x0/https://steemitimages.com/DQmcdJwtxDGhAPeB2oGn2F8K4nQKaogVpQfd4oXoQDLn9uZ/image.png 1x, https://images.hive.blog/1536x0/https://steemitimages.com/DQmcdJwtxDGhAPeB2oGn2F8K4nQKaogVpQfd4oXoQDLn9uZ/image.png 2x" /> <p dir="auto"><span>We want to continue innovating and sharing our discoveries. Please let me or <a href="/@dutch">@dutch know what other topics you'd like us to explore.