Kiln v0.6.0: Snapshots, Full Nodes, and Revamped Public Nodes
Kiln v0.6.0 is now available! This is a big update that makes getting started as a baker easier than ever.
The major updates in this release are:
- The Kiln Node can be started from a snapshot
- The Kiln Node runs in Full Mode
- Kiln can monitor full nodes
- The Obsidian Public Node cache is now enabled by default
- Notifications reminding the Kiln Baker to vote
- A Notification when an update to Kiln is available
Kiln Node Updates
The Kiln Node now runs in full mode and can be started from a snapshot! Snapshots are taken at a given block level and represent the chain's history up until that block level.
When syncing a node from a snapshot, you only need to sync from that block level instead of syncing from the genesis block. Only needing to sync, for example, 500 blocks instead of 500,000 blocks drastically reduces the amount of time it takes to sync with the network. The Kiln Node can now sync in minutes instead of days!
This also has a huge impact on storage requirements. As the Tezos blockchain grows larger, it takes more disk space to store chain history. For instance, as of July 2019 an archive node requires 188GB of disk space. Snapshots can bring that number down to the single digits.
Over time the node will store more chain history and that number will grow, but don't worry - you can always recreate your node from a more recent snapshot to reduce storage requirements again!
If you are a Kiln user looking to upgrade your Kiln Node to full mode, you will need to delete your existing archive node and start a new node from a snapshot. You can find detailed instructions on how to upgrade here!
If you'd like to learn more about snapshots and how they work, we recommend reading this post by Nomadic Labs. We are able to bring this great feature to Kiln because of their excellent work!
Data Source Updates
In addition to running the Kiln Node in full mode, Kiln can monitor full nodes too!
Some backstory - Kiln keeps a cache of chain data that it builds from the nodes it runs or monitors. This cache builds its chain history from the collective state of all the nodes it is monitoring and re-evaluates its correctness every time it sees a new block. Not only does this offer the highest guarantees of accuracy, it allows Kiln to acknowledge states where monitored nodes recognize multiple chain heads, spot reorganizations effortlessly, and correct itself if its history is found to be incorrect due to a reorganization.
This cache is what serves the information you see in Kiln's dashboard for existing features and lots of other potential features we'd love to introduce in the future. For instance, showing your baker's efficiency would require that we know all your previous opportunities to bake (your rights), as well as all the times you successfully baked. We'd also want to know instances where a lower priority than yours was baked for your non-priority 0 rights (i.e. was a priority 2 block baked when you had priority 1 rights). Retrieving that information from a node can be costly and time consuming, which is why it must be stored in a cache. Additionally, Kiln recognizes nodes it is monitoring could be used for baking, so it politely polls for information as necessary rather than hammering it with requests. This means it can take a bit longer to build a cache of chain history, but we view that as a better alternative to missing opportunities due to an overloaded node.
Prior to this release, Kiln assumed it could grab all chain data from any node. This was a fine assumption when there were only archive nodes, but the introduction of two new, more lightweight history modes has challenged that assumption. Not only do they keep less chain history as an archive node, they could have been started from a recent snapshot resulting in partial history, too. Current Kiln users monitoring a full node started from a snapshot may have seen the results of this - Kiln indefinitely reporting that it is 'Gathering Baker Data' while it tries to retrieve information that is unavailable. That won't happen anymore.
We've made Kiln smarter about what information it can get from monitored nodes so its cache can remain robust and correct no matter the data sources it has available. But that didn't completely solve the issue; there was still the opportunity that the user's nodes wouldn't be sufficient for Kiln to correctly report chain data. For instance, if a user has a full node started from a snapshot only a few blocks ago, that isn't enough information for us to see details of previous voting periods in the current amendment process or what your rights were several cycles ago.
To permanently fix this for all users, the OS Public Node now serves all the data Kiln needs to operate! This public node, which is really just an instance of Kiln with an exposed API for other instances of Kiln, has chain data cached and immediately available for other instances of Kiln. Since this will be a critical data source for most users we've enabled the OS Public Node by default, but you can disable it via the command line if you choose. Just know that you'll need your own archive node for Kiln to behave correctly in this case.
Notification Updates
The overarching goal of Kiln is to make participating in Tezos as easy as possible. An important part of that means making sure our users are active and engaged participants in the protocol amendment process. For that reason, Kiln now sends voting notifications! You should generally expect notifications 1) at the start of a voting period, 2) half way through the voting period and 3) 90% through the voting period. I say 'generally' because the logic takes into account which amendment period it is and whether or not you have already voted. For instance, if you have already voted in the Proposal Period and new proposals are injected after that, we'll let you know there are new proposals for you to consider - you can vote for up to 20!
We've also added a notification when a new version of Kiln is available! Kiln updates can be critical to ensuring it continues to work properly. For example, protocol amendments may introduce changes that will break older versions of Kiln. We've added this notification to make sure you are aware of these updates and can upgrade in time to keep your baker running smoothly.
Other Updates and Next Steps
Like all Kiln releases, we've made some UI improvements and bug fixes along the way. You might also notice the browser tab now has a favicon and a page title!
For our next release, we're making it easier to export logs from the node, baker, and endorser from Kiln's UI. This should help us assist anyone who thinks they are having a problem with Kiln and root out any bugs more efficiently. This feature, along with the ability to run commands against tezos-client and tezos-admin-client (which is already in place), provide lots of flexibility for our users to do their own debugging, get assistance from our team, and fix issues.
We're also making progress on distributions - an OVA file to run in Virtualbox, a Mac version, and a dedicated website! We don't have release dates for these yet, but we are making progress on having them available.
Questions? Encountered a bug? Email us at tezos@obsidian.systems, tweet us @obsidian_llc, join our slack group (just ask for an invite), or post your question on Tezos Stack Exchange! We'd love to hear from you.
Comments ()