Some of you have asked what happened to the Stake Pool; why can’t you find it on pooltool.io; Or just “When Pool?”
Being a security first oriented team our Stake Pool designs are focused around security and resiliency. While we could have a stake pool operating during the first epoch, we decided to wait as we want these features not only for our own security, but also for those who delegate to the pool. We did not feel comfortable releasing the pool while not keeping to the design and functionality we promised the pool would take advantage of. Some of these features were security specific, some were more about functionality.
The list below are the combination of features which made us decide to delay releasing the pool. One or two are blockers for us, but we don’t need all of these to be available before the pool will go live. We will go into detail and try to explain the concept of each feature, and the impact it has on the Operators and the Delegators.
- Delegation from Hardware wallets
- Stake Pool keys on hardware wallets
- Additional MFA support
- Delegation from Multisig accounts
- One to many delegation
- Highly Available node configurations
Delegation from Hardware wallets means that holders of ADA who want to delegate their funds to a Stake Pool will not have to transfer ada out of their Hardware Wallet to delegate it to a pool. This feature wasn’t immediately available at the hard fork in Daedalus, Yoroi or Adalite. However both EMURGO and VacuumLabs, the respective creators of Yoroi and Adalite, are hard at work to provide this functionality. We expect it to arrive within the next week or two in Yoroi or Adalite, and shortly thereafter in Daedalus.
Stake pool keys on hardware wallets means that Stake Pool Operators (abbreviated to SPO from here on) can secure the private keys required to run the pool. This extends the safety of hardware wallets to SPO’s the same way that holders of ADA can store their private keys that secures their ADA.
While security best practices of keeping cold keys off internet connected devices and other methods work well when stringently following security protocols, we didn’t feel this was enough. We wanted to rely on the security of hardware wallets for securing the stake pool keys as well as the pledge funds in the exact same manor we have been accustomed to securing our personal ADA. IOHK has VacuumLabs, the makers of the Adalite Cardano wallet, working provide these features. Unfortunately the firmware updates that the hardware wallets required delayed having the features available for SPO’s on July 29th’s hardfork.
This is the biggest obstacle to the ChainCrucial.io stake pool joining the mainnet and being available to all delegators. While we wanted to be online during the first available epoch, we decided to wait and implement the full architecture and not rush or skip anything that could hinder the security or functionality of the pool.
Additional MFA support means providing MFA (aka 2FA) functionality via the U2F protocol. OK, that was a lot of acronyms all at once! Lets break it down a little even though most of you may know these terms already. MFA or 2FA is Multi Factor Authentication, or Two Factor Authentication, and from this point on we will just reference MFA as it encompasses 2FA. So have you ever logged into your banks mobile app and received a text message with a random PIN to enter and prove your identity? Well there you go, you have used a form of MFA yourself, even if you did not know it. This is not the only form of MFA, but it is quite likely one almost everyone has experienced.
The U2F protocol is an open standard that implements a hardware key as the second factor. This greatly increases the security of MFA solutions because there is no password that can be written down, copied or shared with multiple people. This takes your proof of identity to the same level of security as your hardware wallet does for you cryptocurrency.
While not a game stopper to moving our pool to the mainnet, it would be a warmly welcomed feature.
Delegation from Multisig accounts is the ability to have funds (ADA) which are controlled by multiple private keys (signatures) for spending purposes, support delegation to a pool and require the same multisig (multiple signatures) authorization to delegate the funds. At first glance this feature seems solely related to the delegators to the stake pool. However this functionality would also allow SPO’s to merge funds safely and securely into a single pledge. The functionality would ensure that when multiple people funded the pledge, that no single member of the team had sole control over the pools pledge. This would drastically increase the security of the pools pledged amount and allow multiple team members or even multiple pool operators to band together and securely combine their pledge to create a larger pool.
This is also not a game stopper to providing a mainnet stake pool, but it sure helps if we can create a single pool with the entire pledge safely, vs. creating mutliple pools while none have reached a saturation point.
One to many delegation gives the ADA holder the ability to delegate funds to multiple pools from a single wallet/account. Today unfortunately this would require the holder of the ADA to generate separate wallets and manage the stake delegation individually in separate accounts. While still functional this does not create a great user experience and limits the probability that anyone delegating their funds will choose more than a single stake pool, even if their viewpoints align with the goals of more than on team of operators.
This won’t stop us from putting the pool on the mainnet, however not being one of the earliest stake pools on the mainnet probably hurts our changes of getting a large amount delegated to the pool. We believe that this feature/functionality is now crucial (see what I did there?) to the success of the stake pool being able to provide adequate rewards by attracting enough delegation/stake.
Highly Available node configurations is primarily a concern for the stake pool operator, but it also creates a small risk for the stake pool delegator. How you ask? Well the current infrastructure only allows for one core node and many relay nodes. The core node, aka the Block Producing node, is the only one able to generate blocks when elected. The relay nodes are strictly there for a buffer between the core node and the rest of the network, and they also ensure a timely distribution of blocks created by the core node.
OK, that’s a bunch of tech jargon I just tossed at you, what does it really mean? Well since there is only a single block producing node (will use core node from this point on), what happens if there is a failure of some kind? Well if it is a relay node and the SPO properly configured multiple relays, the entire pool is online and they just fix the down relay as time permits. However what happens if its the core node with a storage, cpu or power failure? Do the relay nodes automatically take over as a core node? NO. At the current time there is no “standby core node” which can take over in the event of a failure, however this functionality used to exist with the ability to promote a node that was prepared to produce blocks, but was not competing with the existing active core node. This requires the SPO to scramble and either rebuild a new core node, or promote a relay node to a core node by changing its configuration so it only talks to the SPO’s own relays and no longer connects to the public relays. Then they have to get the proper keys onto the node so it can take over the delegation and respond when selected to create blocks. All of this comes at the cost of uptime and participating in the protocol. The end result is if this happens and the pool is selected to produce blocks before the issue is resolved, both the SPO and delegators lose. The SPO will also lose reputation and the trust of at least some of the delegators who won’t be happy the pool was not online when it was elected to produce blocks.
Some of you are probably right now asking “Why not just setup two core nodes with the same keys?”. The reason is that this can cause something called Adversarial Forking, the link goes to a reddit forum which provides the long version explanation. However the short version is that by having multiple core nodes online at the same time they are actively competing with each other to produce a block. Each one produces a block and then broadcasts it to the network, creating forks. When other SPO’s are selected next to produce blocks, they might be working from what is considered the invalid fork of the chain. Even though the next pool operator was online, ran a single core node and had a sufficient relay nodes, they are penalized for producing blocks on the wrong chain. Is it the next pools fault they produced blocks on the wrong chain when elected? No, it’s the fault of the SPO who configured their system to create the adversarial forks.
This design is the epitome of having a SPO basically engaging as a bad actor. We all want to be good network citizens, participate in the protocol and everyone wins, right? So the multiple core nodes design should never be used until a proper solution is provided.
This also won’t stop us from moving the pool to the mainnet. However until this or another solution is provided it puts the effort to resolve an issue on the SPO vs. allowing the SPO to design a self healing architecture that keeps the pool online during failure events.
We at ChainCrucial.io are still committed to providing a Stake Pool to aid in running and decentralizing of the Cardano network. We hope that our followers see and understand our delays and that they still choose to delegate to our pool when we bring it online, and we will definitely keep you posted as that time comes and we make progress.
While we wait for the additional features and functionality required to implement the architecture we envisioned we are hard at work testing various features, building relays and testing tools for both the mainnet and testnets. We hope these tools will help both those who delegate ADA as well as those developing solutions on the Cardano blockchain.
No Responses