Replacing devices

The rate of device onboarding has been increasing at a healthy rate since we launched self onboarding in the summer of 2019. Whilst some of our contributors have used their own hardware, we’ve also seen an unexpected number of cloud hosted instances the network.

Whilst cloud hosted machines are a great choice for those who aren’t necessarily able to offer dedicated home hardware, they have posed a number of reliability issues that aren’t typically seen with owned hardware. We’ve heard stories of faulty instances, unexpected bandwidth caps and hidden costs that have forced many of the community to have to create new instances and go through the entire onboarding process again.

🔗Automated Staking

Manual stake verification provided a necessary bottleneck as we optimized Edge CLI, as well as insuring the network was capable of handling the increase in capacity. We found and resolved load issues with the ACL service, the Host update process and the Key/Value storage mechanism which will ultimately shape the next roadmap, to be released this quarter.

The next stage is to introduce automated stake verification and completely remove ourselves from the picture. This will be accomplished in a series of changes across each part of the process.

🔗Stake verification key

The first change will be with Edge CLI, the tool you’ve been using to launch and configure a device. The current iteration takes you as far as registration on the network, but then directs the user to contact a community admin to receive an address in order to complete the staking process. The next release will display the address, the amount of $EDGE required, and a unique key to be used in the transaction, as well as instructions on how to apply the key.

🔗Watching Service

We’ll be dropping the manual process of checking the wallet address for your stake, replacing it with a watching service which will periodically look for your stake by matching the unique key you were provided against incoming transfers. When it sees your stake, it automatically applies the transfer hash to our record which is linked directly to your registered device.

🔗Stake Storage

The new process will create stake entries in the Edge database and link them to your device during onboarding. It’ll also allow you to create unassigned stakes which you’ll be able to apply instantly during the registration process.

🔗Stake transfer

Transferring stake has become widely recognised as a process in heavy need of automation, and by separating stakes into entities in the Edge database we’ll be introducing the kind of flexibility contributors have asked for. When migrating to a new device you’ll be able to instantly transfer a stake away from your legacy hardware using Edge CLI.

🔗Listing Stakes and Devices

Edge CLI will ship with a new list feature which will allow you view a complete list of stakes and devices, as well as seeing which stakes are attributed to which devices, making it easier to identify the right stake to transfer.

🔗A note on migration and UUIDs

A lot of people have wondered whether it is possible to replicate an existing device in order to migrate it to another piece of hardware. This is a perfectly reasonable question which hopefully stake transfer will resolve.

UUIDs are supposed to be unique to the device. When a device is faulty or for any other reason is required to be terminated, the UUID and the device name should not be transferred. The device should instead be marked as terminated, a new device with a new UUID created and the stake transferred. This process ensures that an accurate history of contributing devices exists, including historic hardware specifications which would otherwise be overwritten.

🔗Release

There’s a lot of work ahead of us to get automated stakes in place, but we’re confident that it can be delivered in Q1 2020. I’ll be updating you on the progress as it happens, and appreciate all of the wonderful feedback so far.