Hi everyone 👋
We’ve been hard at work integrating the method of value exchange into the internal chain in the network. This is going very well. Nodes are up and running with the P2P protocol and we’re currently working on optimisations for the synchronisation protocol.
The internal network token is called $XE. Network transactions are fee free and instant.
We expect to be distributing $XE at the end of April this year, which is a little later than originally planned, factoring the changes to enable the use of the internal ledger as a layer 2 solution.
We’ll be sharing the tokenonmics and the approach for the reissue ahead of time.
The Eth contract for $EDGE is ready. As is the staking contract and process. Work on the bridge between $XE and $EDGE is ongoing. This diagram illustrates how the bridge and the chain within the network works:
The diagram also shows how the chain interacts with various other parts of the Edge ecosystem.
The Bridge process handles the conversion of $EDGE to $XE and vice versa. The web wallet allows the creation & management of wallets and associated funds, including allowing internal transactions among $XE wallets, and helping facilitate the depositing of $XE via the Ethereum bridge contract, as well as withdrawing $XE via the Bridge service.
Wallets are client-side. You will generate, own and be responsible for your own private keys.
The format for $XE addresses is as follows: xe_[HASH]
For example: xe_08b8083fb37CcBed785b4278B85Cf74aa7719A1E4
Other areas covered in the diagram include the interaction of Staking & Governance functions with the Staking & Governance services, and the interaction of Stargates with the Earnings services which in turn generates payout transactions direct to your associated $XE wallets automatically.
Of course there is also the $XE explorer, providing full transparency of all transactions and Host contribution data.
You can see chain synchronisation working here:
The chain runs in Stargates and each Stargate has an API for interacting with the chain. The spec for the API will be published as part of a second phase, and third parties will be able to provide integrations in time.
A member of the community raised the question of the potential for bridging to other chains. This is possible, and a definite area of interest for future research and discussion.
With regard to staking, we are moving to a yield basis for rewards, with yield calculated based on performance – jobs completed – within a block window in competition with an individual node’s direct peers (Gateways>Hosts).
We are expecting a yield average of 10% for Hosts, 15% for Gateways and 20% for Stargates. The distribution model builds on the internal network market concept, rewarding where there is capacity requirement. The approach means that yield will be much higher in some cases and much lower in others.
In other news, we are moving the centre of gravity for our communications away from Telegram towards Discord. Why? Because it allows us to provide a more focused community experience, which we see as essential with the advent of project governance.
The good news you’re already reading this on Discord! Congratulations on being cool.
Jim has been back working with us again over the past year, and will continue to do so, advising on the evolution of the network chain and providing support for smart contract development.
A new white paper will be published soon. This provides details of the platform as it exists today, and is designed in support of community growth.
The engagement campaign I mentioned in an earlier update is ready and will be launching this month, ahead of the release of $EDGE. You can expect to see regular articles, social promotions, newsletters and more as we ramp up the activity. We’ll be pushing hard for community and network growth. Anything that you can do in support of these efforts would be greatly appreciated, including putting forward ideas through the governance function once it is up and running.
On network updates, there have been several major changes pushed to mainnet this week. Arthur is with me to run you through the latest.
Arthur:
This week we deployed the new device impact score and priority queue into production which had an immediate significant impact on response times.
This is a big subject, so I’ve written up as a separate article, which you can see here: https://edge.medium.com/priority-queue-aeb6c7abea0d
We fixed an issue that occasionally caused devices to miss-report the status of CDN’s state and subsequently receive jobs they were unable to fulfil. A patch fixed an issue that caused Gateway cache to flush after a fresh deployment. We also patched a minor bug with the impact score heap that caused memory issues when a device removal was attempted twice in quick succession.
Gateway now outputs the domain for cache size reporting, allowing us to easily understand the impact of each domain without the need to perform a lookup on the ID.
We migrated from using docker images per architecture (edge/host-amd64, edge/host-arm64) to a single unified image manifest edge/host.
And work continued on the API dedicated to capturing real time usage data from the network.
Joseph:
Thank you Arthur!
These changes to Gateway have made the network radically faster. It was already fast, but performance is now something else.
You can see a fully decentralised site here: https://thedecentralizedweb.com
(Check the site’s headers and you will the devices that participated in delivering it to you.)
Also this week, Edit held a few new businesses meetings, with some interesting opportunities for technology implementation being explored. Everything Edit does ladders back to the network.
Finally, something cool:
Type cdn.new in your browser and hit return.
And that’s all for this week.
Enjoy your weekends.
