Release: PolySwarm Beta (v0.2)

Offers, Relays, WebSockets, Staking, and more!

The entire PolySwarm team is thrilled to announce the immediate availability of PolySwarm Beta (v0.2)!

We’ve been busy bees (is there a PUN token yet?), working to bring you Offer channels, scalability improvements, polyswarmd multiplexing (multiple account support!), WebSockets, improved Arbiter selection & ground truth algorithms, and much, much more!

As part of Beta, we’re releasing polyswarm-relay: an interim scaling solution

Beta brings us closer to delivering on our promise of a threat intelligence ecosystem with better malware coverage, higher detection quality, and more immediate detection.

For the impatient: grab the source code and pre-built binaries here & jump to the end of this article for a time-limited offer :)

Transferring NCT across chains using the new polyswarm-relay

Beta Highlights

• Offer channels — 1-to-1, off-chain mechanisms for Ambassadors and Experts to interact in a rapid, very low cost manner

Establishing an Offer channel in PolySwarm Beta

• Relays & sidechains —move Nectar (NCT) to / from a sidechain and place Bounties on this sidechain — massively decreasing the cost and increasing the speed of PolySwarm Bounties.

Using the PolySwarm Beta to move NCT from the Ethereum mainnet to the high-throughput sidechain

• WebSockets — polyswarmd is now WebSocket-capable, unlocking substantial efficiency improvements, supporting more network configurations and, thanks to Infura, eliminating the need to run a full Ethereum node!
• Arbiter election, staking & ground truth determination — we’re continuing to innovate on the economic design surrounding Arbiter selection and ground truth determination. We have integrated a Proof of Stake based mechanism to ensure that arbiters’ financial incentives are aligned with the health of the market and are not correlated with their vote on any particular artifact.

Development is accelerating and will continue to pick up speed for our Gamma release. In the interim, expect tutorials on building your own microengine and announcements about new partnerships, a new contest, and a grant program!

Join us after the jump, where we unpack some of the new tech bundled into PolySwarm Beta.

Offer Channels

Undoubtedly, the biggest consumer-facing feature of Beta is Offer channels. Offers enable Ambassadors and Experts to rapidly exchange threat intelligence off-chain and periodically settle their “tab” to the Ethereum mainnet. Think handing a bartender a credit card, periodically ordering drinks and then settling at the end of the night.

Fig A-C: Creating an Offer channel with an Expert, sending artifact(s) over that channel, checking the status of the channel, respectively.

Offer channels are a way for Ambassadors to engage designated Experts off-chain without incurring trust requirements.

Our initial Beta Offer mechanism is inspired by µRaiden, providing simple open, join, close functionality in a traditional* state channel.

For Gamma, we’ll be incorporating counterfactual state channel technology to reduce Ethereum gas costs of Offer channels substantially further.

*Is it fair to refer to anything as traditional in this space?

Scaling & polyswarm-relay

As discussed in our Beta sneak peak, we’re designing a sidechain + relay as a stopgap solution to scaling the platform. More about the long term solution soon!

PolySwarm will need to support a large number of artifacts scanned per day. We’re targeting 100,000 artifacts / day by the end the of the year. That’s a lot. Transactions to support this volume would rival CryptoKitties.

Needless to say, we need to get creative. Recall that PolySwarm supports two types of interactions:

• Bounties: Wild West, free-for-all crowdsourced wisdom. Learn more about our bounty process: PolySwarm’s Bounty Lifecycle.
• Offers (new in Beta): High throughput, low latency direct exchanges between Ambassadors and Experts

Each type demands its own scaling solution.

For Bounties, we’re building a PoA sidechain that will allow participants to place Bounties without incurring Ethereum mainnet transaction fees and delays. polyswarm-relay will make this transparent to the developer.

Fig E: Transferring NCT to / from a sidechain.

This sidechain is a stopgap solution — using a Proof of Authority chain demands trust in the Authorities (currently: us). This is bad — we don’t want you to have to trust us. This stopgap will be in place to allow us to onboard more security experts during development phases. Anything PoA will be phased out before Stable, hopefully even before Gamma — plenty more to announce on this front!

As far as scaling Offers, for Beta we’re currently building on the ideas behind Raiden (but not the code) to implement simple state channels. For Gamma, we’re targeting counterfactual state channels — very exciting tech that we’ll be discussing in a future post.

WebSockets

With Beta, polyswarm-gui and polyswarmd gained the ability to speak across WebSockets. What does that do for us? I’m glad you asked:

1. Participants should no longer need to run a full Ethereum node — Experts and Ambassadors alike should now be able to use services such as Infura (this is what MetaMask uses) to easily connect with the Ethereum ecosystem! Implementing WebSocket support in polyswarmd was necessary to achieve this because polyswarmd must listen for when Bounties are placed on the Ethereum chain and Infura only delivers these events via their WebSocket endpoints.
2. WebSockets are designed to look like normal HTTP(S) — at least to start. In a nutshell, WebSockets are OSI layer 7 transports for arbitrary binary full-duplex data using ports commonly associated with web browsing traffic. Using WebSockets permits users to connect to PolySwarm from some of the most tightly controlled networks. It’s pretty sneaky and unfortunately necessary to mimic HTTP(S) in order to punch through NATs and other network filters in many configurations.
3. We needed a way for Ambassadors and Experts’ polyswarmds to chat about the logistics that go into establishing an Offer channel. We wanted these logistics to be as easy and quick to negotiate as possible. We chose WebSockets because we were adding support for #1 and #2 anyway, but are investigating using Ethereum’s Whisper protocol for PolySwarm Gamma, which should allow for greater decentralization and more privacy.

Multiplexing

We’re all about lowering the barrier to entry for Security Experts, Ambassadors and other users of the PolySwarm ecosystem. Toward that end, we’ve moved account management logic out of polyswarmd and into our exemplar microengines.

In Alpha, accounts (Ethereum addresses) were owned and managed by polyswarmd. In Beta, microengines house their own accounts and simply hand signed transactions off to polyswarmd — no need for polyswarmd to keep track of state!

This is great for several reasons:

1. Security Experts running their own instance of polyswarmd only need to run a single instance in order to support an arbitrary number of microengines. Imagine a scenario where an Expert maintains a PDF engine and a DOC engine — we don’t want them to have to run two polyswarmd's! This is a big efficiency gain and lowers deployment complexity.
2. We’re going to be running a contest where security experts compete against one another to detect malware. It’s basically real world PolySwarm, except the money is funny and top contestants are eligible for prizes. We want it to be as easy as possible for people to compete, so we’re planning to host polyswarmd on behalf of all contestants! More on this program soon :)

Arbiter Selection Algorithm

We are upping the ante with arbiter selection model and have implemented adapted Proof of Stake mechanisms to ensure that arbiters’ incentives are aligned with the health of the market.

In Alpha, Arbiter candidates went through a vetting process that examines their capacity to deliver to gain arbitership. In Beta, we are adding the additional requirement that selected arbiters must stake a minimum amount of NCT tokens and commit them to their arbitration smart contract. This adds a continuous financial incentive for arbiters to remain active and promote a trustworthy marketplace.

We are mitigating the ability of Arbiter candidates to use the staking process as means for financial gain.

• The tokens staked by an arbiter must be aged, meaning that vetted arbiter candidates must have been holding at this many tokens for a minimum amount of time prior to assuming arbitership.
• After assuming arbitership, Arbiters cannot add to or withdraw from their stake during the initial vesting period.
• Arbiters must maintain a minimum balance of NCT tokens in their stake to keep their arbitership.

To prevent any one arbiter from taking control of ground truth determination, arbiters may only stake up to a maximum amount of tokens in their arbiter smart contract. In addition to this, arbiters must participant in a minimum proportion of ground truth voting to keep their post.

What’s next

For Gamma, we’re working on adapting principles from Distributed Proof of Stake mechanisms to enable market governance of the arbiter class. Stay tuned to see how that works!

Ground Truth Determination

Arbiters must work as honest judges in the marketplace, so it is crucial that there are no market pressures or incentives that would encourage arbiters to abstain from voting with malintent, vote randomly, or collude. To promote this, we have designed the ground truth determination process as such:

• All arbiters may vote on any given artifact.
• The fees paid by security experts and the ambassador for an artifact are pooled into one sum. This pot is awarded to one arbiter, which is chosen through a weighted random selection based on the relative size of their stake. For example, if arbiter A staked twice as many tokens as arbiter B, then arbiter A is twice as likely to be selected.
• All arbiters may be rewarded the fees, regardless of whether they voted or whether their vote was part of the deciding majority.

This design moves an arbiter’s financial motivations away from the individual artifact level and toward the larger arbitration process. On average, arbiters will earn a consistent amount with an overall size relative to the size of their stake. Knowing this, arbiters should have no reason to vote dishonestly, attempt to wrongly sway the ground truth decision, or collude with other arbiters to increase their earning potential.

Stay Connected

Follow us on Twitter, Telegram and GitHub.

And, we’re sharing a special Beta invite to Discord for the first 50 people who click through with this link!

Don’t forget to join our Weekly Security Experts Newsletter to be the first to know about major PolySwarm updates and more.