Hi everyone đź‘‹
The pace of development at Edge, the excitement in the crypto space in general and of course the effect of being in place, in lockdown, means that the weeks are just flying by at the moment.
We’ve managed to secure the Edge username on Medium. Our new Medium URL is:
We’ll be posting all of the latest updates here going forward.
We have multiple additional videos in the works, with scripts now finished and voiceover work under way. These cover upcoming services with a focus on end users. We also have a video in production that provides an introduction to the platform for community users.
And we’re putting the meat on the bones of a social activation campaign, which I expect to be kicking off this month.
Real Research has north of 1.5m users now. However you cut it, this is a very meaningful number. As the app is opened up for broader use this month we expect to see it driving significant liquidity in the TNC Coin.
We’re continuing to deliver on the underpinnings of the new $EDGE token. Token contracts are complete and in testing.
For complete clarity, the decision has been taken that the token will be ERC-20. There are several reasons for this, the main being 1. stability of smart contracts; 2. interoperability with the wider community; 3. liquidity provision; and 4. development pace.
We assessed a broad array of options, including extending the DAG in the network to provide smart contract functionality. This would be the preference from a technical interest perspective, but it’s also massively complex, time consuming and comes with significant cost for little to no benefit versus ERC-20.
Of course this decision in no way rules out future changes, but it’s where we are today, and it represents the best route forward for the network.
The team have been working on the new load balanced queue for Gateway, which is a significant upgrade of the existing queue system. It brings real time device scoring to the network to enable a better distribution of requests. Device scoring will be used as a primary metric for node earnings in future, factoring in more data points than just jobs completed.
We’ll be writing much more about this in the coming weeks, but here’s a little more detail…
Requests in Gateway queues run through a bi-directional stream (which is always open between Gateways and their Hosts). This is somewhat like being at a counter with a ticket in a queue. Devices subscribe to the queue and the first Host in line for a job up gets handed the request. If the Host fails to respond in a given timeframe the job gets passed out to additional devices in sequence until a response is received. (This is the job race that we’ve spoken about before.)
With the upcoming release this will change so that all Host devices are subscribed with their own dedicated channel to their Gateway. The queue will then send requests to the Host devices through their dedicated channels based on their current score (the Host that at that moment in time Gateway thinks will respond the fastest based on it’s impact score - i.e. not a device that currently has a lot of requests for example).
And the score of the Host device will be updated on the back of every job completed.
In this way Gateway is constantly rebalancing load across devices based on their realtime performance.
Certman - the network’s new certificate store - has been upgraded to deliver metrics for network monitoring. This update should be completed and deployed to mainnet next week.
Since it launched in the mainnet a little over a week ago Certman has been performing flawlessly.
Certman is a certificate service running in Stargate.
Its predecessor was Consul. In the old set up when a request came in for a particular domain it would hit Stargate which responded with the nearest Gateway to the request. If that Gateway had no SSL certificate for the domain it would auto generate a one by talking directly to Lets Encrypt. The problem with this was that Lets Encrypt moved from a single geographical request challenge to making multiple distributed request challenges, which meant that multiple Gateways would get the challenge, even though they had no knowledge of the original request. This was an issue because you can’t forward on SSL requests (for security reasons), meaning that the process required every Gateway to daisy chain requests.
This was slow and prone to failure.
So we needed a central cache for certificates, which is where Certman comes in. There are two components to the application: an in-memory store for ACME tokens that don’t need persisting, and a long term persisted store for certificates. Certman handles this as well as the issuance of keys and security negotiation with Gateways.
Certman also handles the cleaning up of certificates on expiration along with a bunch of other cleanup tasks. It’s a very lightweight but very elegant solution to a major pillar of the network. And it allows us to automatically provide SSL certificates for third party domains, which can be mapped into edge services.
The implementation of Storage moved forward, with plans for the implementation of a dedicated team tabled and under review. The intention here is to pick up development pace by establishing product-level teams around the core platform team, all under Arthur’s purview.
And finally on a related note, we’ve started working with a start up in the storage space, who are working with the network to unpin their platform.
And that’s it for this week.
Enjoy your weekends.
