There was a potential vulnerability in
steemd that could lead to a denial of service. Current
stable branch (
2ee5160) has an appropriate fix. All publicly accessible nodes should be updated.
This bug, however, did not create any risk to the Steem blockchain, accounts, keys, or balances.
Last but not least:
I want to thank you (know who) for reporting and handling it in a professional way.
Good job, as always :-)
Dear witness, please keep your nodes in shape
If you are a witness, it is highly recommended to support the network by running some nodes. Some of us run their services powered by one or many of such nodes, others have complex, distributed infrastructures for their R&D projects, while some are taking their first steps by running their own seed node. In either case, it is crucial to keep them in a good shape.
Security update mentioned above is a good excuse to do some maintenance checks:
- do you still have enough storage for your block log and shared memory file?
- isn't your shared memory size too small?
- is your seed node reachable from outside?
- is it able to keep up with the head block for most of the time?
Public Steem API endpoint - status and plans
For now, the main purpose of my node is to help various service providers with the transition from WebSockets to JSON RPC 2.0 requests by giving them a bit more time to adapt.
(Honestly, you guys should have done that a while ago.)
I’m writing this because I’m currently experiencing increased load on my node, which is caused not only by the high rate of requests from several big service providers that I know but also by a lot of new ones and tons of distributed, short-lived connections from random end-users.
That causes performance issues and 503/504 when upstream steemd(s) are too loaded to respond on time. Make sure that your software can handle such a situation gracefully.
Please be responsible while using public resources: if you expect a significant number of requests, you should consider running your local node, which would also greatly reduce latency, improve performance, and save your time.
(Seriously, when you need to throw 80 million of
get_blocks on a public API node in one week, you are doing it wrong. PRO TIP: we don’t even have 20 million blocks yet.)
But fear not. I’m not complaining, I will scale it up. I just need a little time.
Another thing is that it’s not really about the performance of hardware as such, but about certain limitations of the current
steemd and the way it handles RPC connections. For now, I’ve just added the second server running steemd to split the load. This issue will be addressed in one of the upcoming steemd releases based on appbase, which will greatly improve the performance of a single node.
If you are running a project that depends on my node, feel free to contact me when you encounter any issues or you need a dedicated node.
My main, public API endpoint, currently under test, is now working with artificially limited performance, occasionally falling back to external upstream servers. The final version will be powered by multiple separate steemd nodes optimized for various purposes and microservices to serve you better and faster. Do not use it for production yet.
Up-to-date blockchain data
available for download at:
or if you prefer
Periodically updated, highly compressed blockchain data
available for download at:
(compatible with parallel, indexed xz)
The "Steem Pressure" series is not a series yet, as there’s only one episode out there, but there will be more posts soon.
If you believe I can be of value to Steem, please vote for me (gtg) as a witness on Steemit's Witnesses List or set (gtg) as a proxy that will vote for witnesses for you.
Your vote does matter!
You can contact me directly on steemit.chat, as Gandalf