Zel’s Kamata Update
“Double, double, toil and trouble; Fire burn, and cauldron bubble!”
-William Shakespeare
“The Bard” is quite famous for writing about witches and wizards, so he feels appropriate for opening a look at Zel’s Kamata update from the witches and wizards on the Zel team.
Why the name Kamata?
In Tokyo, one of the world’s busiest cities, there lies a discrete train station called Kamata, despite the relative quiet and lack of ostentation, it still handles more than 45.000 passengers daily on just 3 lines. Very much like the levels or “lines” in the Zelnode network.
To me, it’s perfectly clear that the team wants to clearly say “Hello world, welcome aboard!” with this feature-packed upgrade. And for good reasons as you will see below.
What are the features of the update?
There are so many that I will split them across three sections, one dealing with on-chain updates, updates related to flux and finally a section on what improvements are in store for the end-users.
On-chain upgrades:
- Deterministic node list for the chain.
- Improved benchmarking daemon.
- Network upgrades.
- Fully FIFO compliant nodelist.
- Code slashing.
Deterministic node list for the chain:
In the case of a blockchain, deterministic is in the mathematical sense of the word meaning an absence of randomness.
Users who are familiar with other service or masternode blockchain projects will have seen, if not experienced a certain degree of variance in payouts from service or masternodes.
This happens because each node on the network broadcasts a list of which nodes should be paid now and which should be paid later. Occasionally, there are overlaps in how paid nodes are added to the back of the list or even in how those nodes are paid.
That variance post-activation will be gone from the Zel network as there will no longer be an unchained list, everything related to the nodes will be written to the chain in the order they occur in.
Why does this matter?
To put it very bluntly, security and real continuity. The older styles of nodes are vulnerable to collateral spoofing where a high-level malicious actor adds fake nodes to the list, sets up a “ghost node” and uses that to steal node rewards from the chain.
Will this bloat my wallet so I need a 10tb drive?
The short answer is no. With roughly 2000 nodes operating on the network and them being set up and taken down in a pattern consistent with what has been the case to date, it will add roughly 1Gb per full year to the size of the chain. Which is minimal pain for a lot of gains.
Improved benchmarking daemon:
Everyone wants to cut as many corners as possible, so Zel has rolled out a second daemon for node operators which will keep everyone honest in terms of what resources they have allocated to their service nodes:
Why does this matter?
For everyone to make money and support a working network, meeting all the specifications above is a must. Having someone cause failure in the flux network by not delivering what they should be able to deliver according to the spec list hurts everyone. The moron trying to save a few dollars on hosting a BAMF included. The damage to the now non-spoofable collateral will DRASTICALLY outweigh any supposed savings.
For example, Moron A decides to feed the network bad data about his BAMF which saves him 15 $ a month in hosting, this succeeds for 2 months and he joyously rubs his greedy little hands over 30 $.
Then his fake data causes the launch of “awesomesauce” on flux to fail. Which causes a 10% price drop costing him 0.05 BTC on his collateral. Not so much hand rubbing now.
Once everyone figures out who he/she/it is and they will, he/she/it probably will not have a whole lot of social life left in the community.
I do not like closed source software, why is the benchmarking daemon closed source?
This is a question of a stop-gap solution until the Zel team is ready to implement a more wide-reaching solution.
There are things in the works/under consideration that can solve this. However, they will require a considerable amount of time to come out of development as several additional code upgrades will have to have happened before they can be released. Till then some idiot-proofing is in everyone’s best interest.
Network upgrades:
On the blockchain side, there are several networking upgrades that will improve the overall stability and accessibility of the network. One of these has been disabling Ipv6 on Zelnodes.
But Ipv6 is so much cheaper than Ipv4 GIMME!!!!!
There are issues with Ipv6 one of them being that it resolves (the lookup process for connections) much faster than Ipv4.
“But surely speed is a good thing!”
Yes and no, until the chain has gone 100% deterministic, the speed of Ipv6 can contribute to smaller chain splits causing orphan blocks when one part of the chain (ipv6) gets ahead of other parts of the chain (ipv4).
Luckily for Zel, this has so far been a minor and fairly contained issue due to Zel having a resilient networking infrastructure and team. For blockchain only, this is a manageable and acceptable risk level with a skilled team like the one on Zel. It has however been disastrous for several other chains with less experienced teams causing widespread netsplits, reliance on DNS seeder services, bloating team costs and so on ad nauseam.
With Flux, Zel is going several levels beyond just blockchain with the running and decentralizing of apps on Flux.
Allowing Ipv6 for this part of the process would mean that for more than half of the internet, these services would be unreachable. Many ISPs simply do not yet support the direct resolution of Ipv6 that would be required.
Fully FIFO compliant nodelist:
Once deterministic lists are live, the sometimes slightly random order in which nodes are chosen for payments by pools and re-added to the list will change. Which will mean:
- The next node to be paid will be identical across the network. No more doubles.
- New nodes being added to the list in the same block will go ahead of in the queue of paid nodes being readded to the list for payment.
- The randomness is gone!
What does that mean for me as a shared node investor/user?
Zelnodes are, once mathematical determinism goes live, an enhanced product for potential investors as they will not need to account for variance in their projections like with the majority of other node-based projects.
Code slashing:
But surely, the more code, the better it will all work? That could not be further from the truth as the more code you have the more potential attack vectors you present to malicious actors.
This release removes significant amounts of older Dash style code from the release that were wholly redundant in the case of Zel and provided malicious actors with potential ways of disrupting the network.
What does this mean for the average user?
Significantly increased security from the chain being bloated/spammed with redundant transactions and calls which could potentially cause memory pool spikes like Bitcoin occasionally has with transactions moving at a snail’s pace.
Flux related upgrades:
- Flexibility made easy
- Any language code deployments
- Security updates to deployments
Flexibility made easy:
Once active, dapp/app-developers will be able to deploy any single port dockerized applications across a number of Fluxnodes of their choosing. This is a massive leap forward for distributed applications and will once further developed demonstrate the massive potential inherent in the Zelnode network.
What does that mean for me as a node operator?
That you can very quickly be hosting content or bits of content ranging from containerized websites to containerized electrum servers to containerized distributed games. This has the potential to once developed a bit further, become a fully viable alternative to some types of IPFS hosting and some forms of Ethereum based Dapps.
The method of containerization for this will be “Docker”. There are several other possible options like JVMs however, none are truly suited for the versatility envisioned here.
But Docker security is horrible, I’ve seen studies saying all dockers mine CN coins?
The Docker team has pushed several solid updates since late 2018 when this very much was the case. Those updates combined with several new features of flux, described in the next section, leave docker as a secure and valid option for flux app deployment.
Any language code deployments:
The flexibility of the Docker containerization system means that application developers are free to write in their preferred language. This is a massive step up compared to several of the other solutions currently out there for Dapps as it dramatically increases the number of developers who can develop for the Flux network.
How does that affect me as a Zelnode operator?
In the short term not in any drastic way other than that you may very quickly be hosting an array of new software.
In the medium to longer-term, one can easily envision a shortage of Flux space and Flux capable nodes which will become an additional factor driving demand for Zelnodes.
Why are Flux apps different from Ethereum or Tezos Daps?
Currently, Eth and XTZ Dapps have a smart contract on-chain components allowing them to interact directly with the blockchain as well as having a frontend with the Dapp functionality built-in.
Flux apps do not, their purpose is distributing the applications by leveraging the computing power of the distributed node network, rather than having them interact with the chain at this time.
Security updates to deployments:
Given the earlier very real concerns about Docker and its security, the Zel team have taken the additional precaution of adding resource specification to the deployment of Flux apps. This is fully locked down upon deployments with changes requiring a redeployment.
What does this mean for node operators?
Essentially that you have peace of mind, you do not run the risk of having a rogue Flux app spiking your CPU/RAM usage past what you have agreed to by running the node you are currently running.
User experience upgrades:
- Node confirmation automation.
- Automated networking updates.
- Expanded and enhanced abuse monitoring.
Node confirmation automation:
Do you hate having to use command line commands? Detest having to ssh into your rented VPS to maintain nodes?
Well, Zel has gone far out of their way to minimize that process for you with the new deterministic node system.
2 transaction node starts.
Service nodes require two transactions to start up. One, the “start transaction” from your collateral holding wallet and Two, a “confirmation of being started” transaction from the node on the remote host.
This used to require a remote login to the server running the node. With full determinsticity, that is no longer required meaning your node will detect the incoming “start transaction” on the chain, check itself and then automatically send the “confirmation of being live transaction.”
Additionally, the setup process used to require the filling in of config files on the remote server, this information is now broadcast by the server as part of the “confirmation transaction” meaning less hassle for the node operator.
What does this mean for me as a node operator?
That the team has taken seriously the need to reduce the number of ssh sessions required to operate and maintain a node to the bare minimum.
Automated networking updates:
As part of the deterministic node setup process, networking information like the IP address is provided automatically by the daemons on the remote server.
What this means is that should you need to migrate to a new server for some reason, you may not need to fully redeploy the node, provided that you redeploy the new server in time to hit the next “confirmation transaction” as mentioned in the section above on “Node Confirmation Automation”.
That transaction will update the servers IP address in the Flux network. The window for this redeployment is 30 minutes from the last confirmation transaction broadcast by the remote server.
What does this mean for node operators?
That the Zel team has taken significant steps to minimize the pains you have to go to, to facilitate the smooth operation of your nodes.
So I can hop between VPS instances making the most of bonuses etc?
Yes and no, the yes part being between decent high-quality honest providers. The team has tested Digital Ocean, Contabo and AWS extensively and found no issues with them.
The much more relevant no part comes in when working with cut-rate and bonus spamming VPS providers. Many of them will not meet the minimum specifications required or will not do so consistently. This comes from them overselling their hardware and will result in the banning of your nodes hosted with them requiring a redeployment with a better provider.
Enhanced and Expanded Abuse Monitoring:
The Zel network has seen several types of malicious activity since launch. This has resulted in unfair situations for some users who have been taken advantage of. So, steps have been taken to curtail such behavior on the network.
Fraudulent benchmarking is no longer possible with the release of the new benchmarking daemon. Nodes attempting to do so will easily be caught out in doing so given the construction of the new confirmation transactions.
Luckily, Zel has so far dodged the bullet of collateral spoofing attacks on the nodelists. With the lists being dropped and everything being written fully to the chain, this type of malicious behavior is no longer possible.
What does all this mean for me as a regular miner or investor?
That you are now “invested” in one of the most secure and up to date blockchains with service nodes. The added security at the same time removes the current occasional variance in node payments making for an overall more stable and user-friendly platform.
Bigpiggy01 on behalf of the Zel Team
