We recently completed the “New Engine Claiming and Management” milestone on our development roadmap. Our goal was to make it easier for Engine owners to build, configure and test an engine, and then join the PolySwarm Marketplace, so we’ve completely redesigned the architecture.
Today we introduce a new utility use for PolySwarm’s Nectar token for average users: distributing rewards for security-relevant data about TLS certificates, DNS resolutions, and potentially malicious files encountered in daily computer use. Many of these telemetry sources are already collected from user devices by Antivirus (AV) providers. Still, there are a number of serious issues with how they are collected, how users are compensated for their information, and how these results are shared. By re-imagining how this marketplace works, we can increase collection transparency, fairly compensate all participants in the marketplace, and, most importantly, create a more unified source of security telemetry that will better protect users worldwide.
In our original whitepaper, we discussed the fragmentation of the AV market and how, in its current form, this fragmentation leads to worse outcomes for users in the marketplace. However, this fragmentation is not limited simply to the world of scanner providers: it affects many other parts of the security industry as well. As we built the PolySwarm marketplace, we realized that many of the disparate pieces of security information our customers were trying to connect are often ones that exist, but in practice, are inaccessible due to the fragmentation of the market.
To attack this problem, we are extending our original design and adding a decentralized marketplace for security telemetry. Users will install a browser extension and, later, a system daemon that reports their telemetry, using privacy-sensitive data structures. Telemetry reports are received by Aggregators and are associated with a reporting user’s wallet, allowing querying by PolySwarm’s cyber security focused consumers who pay for query hits in NCT. Everyday users get paid to provide this telemetry, and, Aggregators and backers with NCT get rewarded for timely telemetry that highlights high-priority attacks and under-the-radar malware campaigns.
This new marketplace provides immediate benefits to all participants. Users get more control over their data and are actually compensated for the value they provide, as well as receive early warnings about threats they have encountered. Aggregators are no longer dependent on their own install base for data and earn NCT for providing query computation and telemetry validation. Stakers help the network determine the most useful sources of telemetry and help reduce the threat of spam on the network, for which they also earn a portion of NCT. Finally, Consumers will now be able to access a truly worldwide network to find the data they need to identify and fight emerging threats.
At PolySwarm, our mission is to bring the security community and users worldwide together to fight malware. By leveraging Ethereum’s global, decentralized network, our new marketplace will greatly further our efforts to bring these groups together by enabling (and incentivizing!) everyone to help solve this difficult problem.
Read the whitepaper here
The last 12 months have been intense yet very productive for PolySwarm, as we have scaled our platform, fast-tracked user acquisition and released new key features.
Let’s do a quick recap of what we’ve accomplished before we get into what lies ahead of us.
Hello engine developers,
We are putting the finishing touches on the new backend systems used to manage engines/arbiters and handle bounties. Our goal is to release these changes into production in late March.
Overview
Our primary goal with these changes is to greatly simplify how engines are built, tested and run. And to change how they communicate with PolySwarm to be more in line with current industry standards for remote distributed services.
For those of you with existing engines connected to the marketplace, this will be a breaking change. We will provide instructions for how to update your engine to work with the new system. We are trying to make it as simple as possible.
For those who want to start a new engine, or even convert your engine to the new simpler engine framework, we will provide documentation and instructions to do so.
For any engines hosted by PolySwarm, we will update them to continue operating using the parameters they are currently configured with.
We will share a lot more information and more specific details very soon.
The following are more in-depth details for those who are interested.
Backend Changes
The first major difference is a change to a Webhook-based system to send bounties to engines. This means that engines need to run a HTTP service on a publicly available IP address/port for the webhook to communicate. The Webhook message will contain all of the information the engine needs to process a bounty, download the artifact, and return the result.
The second major difference is a change to remove the ETH wallet from the engine itself and into a PolySwarm-hosted wallet management system. We have received many complaints about the difficulty and problems with managing a wallet inside an engine, so we are separating them. This will function similarly to how a web-based crypto-currency exchange hosts a wallet for your account.
User Interface Changes
From the user interface perspective, we are adding administrative functionality to user and team accounts on https://polyswarm.network to configure and manage engines, wallets, and webhooks. We will provide an example web service plus engine along with our documentation.
For each engine, you will be able to define an engine configuration. The following are some example configuration settings:
For each account, you will be able to create an ETH wallet, which can then be used by your engine/arbiter. It will provide basic transfer functionality:
For each account, you will be able to add one or more webhooks, which can then be used by your engines/arbiters. It will provide the standard webhook functionality:
Marketplace Changes
From the marketplace perspective, PolySwarm will use engine configurations to determine which engines are sent a webhook for each bounty. PolySwarm will use responses to webhooks and bounties to track the status of each Engine. Engines can still choose not to process a bounty, by returning an “Unknown” verdict with no bid.
We will continue to use fake ETH/NCT (rinkeby) for the first month or two after these changes are released. We need thorough testing to ensure everything is working reliably, and then we can go to Mainnet.
Cheers,
Nick
Read More
We are putting the finishing touches on the new backend systems used to manage engines/arbiters and handle bounties. Our goal is to release these changes into production in late March.
Overview
Our primary goal with these changes is to greatly simplify how engines are built, tested and run. And to change how they communicate with PolySwarm to be more in line with current industry standards for remote distributed services.
For those of you with existing engines connected to the marketplace, this will be a breaking change. We will provide instructions for how to update your engine to work with the new system. We are trying to make it as simple as possible.
For those who want to start a new engine, or even convert your engine to the new simpler engine framework, we will provide documentation and instructions to do so.
For any engines hosted by PolySwarm, we will update them to continue operating using the parameters they are currently configured with.
We will share a lot more information and more specific details very soon.
The following are more in-depth details for those who are interested.
Backend Changes
The first major difference is a change to a Webhook-based system to send bounties to engines. This means that engines need to run a HTTP service on a publicly available IP address/port for the webhook to communicate. The Webhook message will contain all of the information the engine needs to process a bounty, download the artifact, and return the result.
The second major difference is a change to remove the ETH wallet from the engine itself and into a PolySwarm-hosted wallet management system. We have received many complaints about the difficulty and problems with managing a wallet inside an engine, so we are separating them. This will function similarly to how a web-based crypto-currency exchange hosts a wallet for your account.
User Interface Changes
From the user interface perspective, we are adding administrative functionality to user and team accounts on https://polyswarm.network to configure and manage engines, wallets, and webhooks. We will provide an example web service plus engine along with our documentation.
For each engine, you will be able to define an engine configuration. The following are some example configuration settings:
- engine name, description, owner's website, tags
- artifact type(s) supported
- mimetype(s) supported
- max file size supported
- rate limit
- webhook
For each account, you will be able to create an ETH wallet, which can then be used by your engine/arbiter. It will provide basic transfer functionality:
- transfer NCT/ETH into the wallet
- withdraw NCT/ETH from the wallet
For each account, you will be able to add one or more webhooks, which can then be used by your engines/arbiters. It will provide the standard webhook functionality:
- create, test, delete the webhook
Marketplace Changes
From the marketplace perspective, PolySwarm will use engine configurations to determine which engines are sent a webhook for each bounty. PolySwarm will use responses to webhooks and bounties to track the status of each Engine. Engines can still choose not to process a bounty, by returning an “Unknown” verdict with no bid.
We will continue to use fake ETH/NCT (rinkeby) for the first month or two after these changes are released. We need thorough testing to ensure everything is working reliably, and then we can go to Mainnet.
Cheers,
Nick
“We are proud to be partnering with Polyswarm, and being part of their launchpad for new technologies and innovative threat detection methods” stated Julian Ziegler, Co CEO of Inlyse.