Happy holidays from the AdEx team! It’s time for another AdEx Registry update, and this time it’s the big one — you can finally stake your ADX to start earning a portion of the network validator fees.

Last year around the same time, we announced the AdEx Registry and ADX staking. Earlier this month we revealed the architecture of the AdEx Registry.

Today marks the launch of the AdEx staking app, which you can find at staking.adex.network. This is the user-facing part of the Registry, where anyone can stake their ADX on one of the staking pools.

The first available staking pool is the “Validator Tom”: as the name suggests, this is the pool of the Tom validator, which is operated by us. We will distribute the fees it earns proportionally to stakers in this pool.

Under the hood, the staking app interacts with the Staking contract, which runs on Ethereum and is deployed here.

Here’s what you need to know:

1. The only official user interface is https://staking.adex.network (GitHub).
2. You need Metamask and you stake the ADX token.
3. There is a 30 day lock-up period.
4. Reward distribution will start by the end of Q1 2020.
5. You will receive a proportional part of the collected validator fees.
6. The smart contract source code and audit results can be found here. It passed a security audit by G0 group.

Here’s how to stake:

1. Make sure you have Metamask installed and set-up. Make sure you have ADX and some ETH for gas in your Metamask account.
2. Go to staking.adex.network. Metamask will ask you whether you want to connect to it; approve the request.
3. Click on “Stake your ADX” and fill the form — currently the only available pool is the “Validator Tom” pool, so select that one. Type in the amount of ADX tokens you want to stake.
4. Once you’ve filled the form, the “Stake ADX” button will become active. Click it and two Metamask popups will appear one after the other. You need to approve both.
5. Once those transactions are mined (you can check in the Metamask UI), a bond will appear in the bonds table.

Congratulations, you did it! We will start distributing rewards to stakers in this pool in 2020, so keep coming back to check your rewards!

For more details, please read the full post on our blog: https://www.adex.network/blog/adx-staking-is-here/

Today, we’re open-sourcing one of the most vital components of AdEx v4.0: the Market.

You can check out the repository here: https://github.com/AdExNetwork/adex-market

The primary role of the market is to facilitate demand/supply discovery and trading. It keeps record of all campaigns that are currently valid, and allows publishers/advertisers to query that list in order to find what they need.

In simple words, it’s one of the parts that enables publishers and advertisers to freely interact with each other and trade ad space/time between themselves, without middle parties.

In the upcoming days, we will deploy the new market APIs and update the repository with more documentation.

For technical details, you can check: https://github.com/adexnetwork/adex-protocol#market

In case you haven’t been following recent developments and plans, we highly recommend you read our March update!

Interested in AdEx? Follow us:

Website | Discord | Facebook | Twitter | Reddit | GitHub

Back in 2018, we wrote about off-chain event aggregation, which was the backbone of the AdEx v3 protocol.

With the AdEx v4 protocol, we’re introducing OUTPACE: Off-chain Unidirectional Trustless PAyment ChannEls.

What are payment channels and why are they great for AdEx?

Payment channels refers to a set of techniques/methods for enabling multiple payments between parties without committing each payment to the blockchain.

Payment channels are one of the most popular and proven forms of Layer 2 scaling and are used in projects like the Lightning Network, Raiden, Connext, Spankchain and Funfair, just to name a few.

For AdEx, using payment channels has a few important benefits.

Firstly, it allows us to minimize the number of on-chain transactions, and that’s is a huge UX improvement. In the v4 version of our protocol, the only on-chain transactions that you need are opening a campaign (as an advertiser) and withdrawing your earnings (as a publisher).

Secondly, because making payments does not incur any extra fees, we can use micropayments for each individual impression (or any other type of payable event).

This means publishers have a guarantee they can withdraw their revenue at any given time, unlike traditional systems where you can only withdraw your earnings for set, usually long periods, and/or only if you reach a certain threshold.

But most importantly, since the payments are per impression, this eliminates any possibility that an advertiser would cheat a publisher out of their earnings.

What are the benefits of OUTPACE?

OUTPACE is inspired by previous research, such as the Lightning Network and Perun, however it’s different in two major ways:

1. It’s strictly unidirectional, which eliminates the need for watchtowers and complex exit strategies; and
2. It allows multiple parties to be paid from a single channel (one-to-many).

No challenge periods or watchtowers

In bidirectional payment channels, if Alice sends 1 ETH to Bob, but Bob sends 0.5 ETH back, Bob can cheat by broadcasting an older version of the state (balance sheet) to the blockchain, in which he still has the whole 1 ETH.

To eliminate this issue, you usually need something called a challenge period. In practice, this means that if Bob submitted the older version of the state, he wouldn’t be able to withdraw immediately, but rather after the challenge period has ended. In this period, Alice can submit the newer state (where Bob has 0.5 ETH less). Each state is sequentially numbered, so that the on-chain contract can know whether the state is actually newer.

Another caveat to this is that it requires the so-called “watchtowers”: software systems that have to be constantly online and watch for fraud attempts. While this usually works, a watchtower going offline could have disastrous consequences.

Now, imagine a channel in which Alice can send funds to Bob, but Bob can’t send funds back to Alice. There is one possible state transition: Alice’s balance decreases, and Bob’s increases.

If Bob broadcasts an older state, they will only hurt themselves. But wait, can’t Alice broadcast an older state and therefore pay Bob less?

In OUTPACE, Alice’s funds are locked up until the channel expires. Once this happens, they can get their remaining funds back.

However, Bob can withdraw at any time using any state, as many times as they want. This is OK, since at every withdraw, we just need to subtract the amount they previously withdrew.

To recap, the unidirectional property in OUTPACE allows earning parties to withdraw immediately at any time, and a lot of the implementation complexity of regular payment channels is avoided, therefore helping the reliability/stability of the system.

The trust model in a one-to-many setup

In OUTPACE, rather than having one recipient of the funds, we have many. This is achieved by using a merkle tree of all of the balances (we often call it a balance tree).

However, the traditional trust model of payment channels dictates that funds are locked up on-chain by a 2/2 multisig controlled by the two participating parties.

Since the receiving parties in OUTPACE are not defined at the time of the channel creation, we can’t use the same model. We have a separate concept of “validators”, which are the parties that control the on-chain multisig.

Usually, this works by having a “leader” validator, who should be the same entity that funded the channel, and will propose new states, and a “follower” validator, who’s responsibility is signing new proposed states as long as they adhere to the unidirectionality rules.

There is additional trust implied in this: if you’re a receiving party, you need to be confident that the follower will act in your interest. This works perfectly for AdEx, where the leader is the advertiser-side platform and the follower is the publisher-side platform.

It’s important to point out that the “follower” validator is not a custodian: at any point, every receiving party has access to the latest signed state that guarantees they will be able to withdraw their earnings on-chain.

You can read more about this in the “Trust implications” section of the AdEx protocol documentation.

The advantages of one-to-many

If we used a 1–to-1 setup, each advertiser would have to open a payment channel to each and every publisher they want to interact with. Keep in mind that opening a channel means locking up funds on-chain; this leads to a significantly worse user experience, and requires more on-chain transactions that would lock up funds.

Alternatively, they’d use hubs, but this just shifts the same issues on to the hub itself. Plus, for this to work, there have to be proper incentives to operate a hub — which might mean adding considerable fees to the system.

A one-to-many system mitigates all of those issues and makes improves UX: the advertiser only needs to open a channel when they open a campaign, and never worry about it again.

Also, since we’re talking about funds that they are locking up anyway, they don’t even need to know what’s happening under the hood: they are just depositing their campaign funds into the platform, and they don’t even need to know what a payment channel or a blockchain is.

Finally, this allows any publisher to jump on board and start earning at any time — again, without even having to know what a payment channel is!

Is this only for Ethereum?

Absolutely not! OUTPACE was designed to be blockchain-agnostic, and you can implement it on pretty much any blockchain that supports smart contracts, or even a bitcoin-style UTXO/scripts model.

Currently, there are implementations for Ethereum and Substrate/Polkadot.

Is this only useful for AdEx?

Again: absolutely not! While OUTPACE is a great fit for AdEx, we believe it can be used for any other use case that requires micropayments and can benefit from a unidirectional one-to-many interaction.

For example, OUTPACE can be very useful for a bounty network, where one entity would continuously distribute bounties to various other parties.

It’s also possible to interleave several OUTPACE channels together (also called “netting”) in a way that a micropayment will be atomic across a few channels, allowing more complex use cases, for example a DEX (pun intended).

Additional reading

There is more documentation available here: https://github.com/adexnetwork/adex-protocol

Furthermore, we’ve already rolled out the AdEx validator stack, which is the first implementation of the off-chain parts of OUTPACE.

There are going to be follow up posts as well, going into more detail and looking into potential use cases.

Interested in AdEx? Follow us:

Website | Telegram | Facebook | Twitter | Reddit | GitHub

NOTE: To learn more about the context here, we recommend you familiarize yourself with the AdEx protocol: https://github.com/adexnetwork/adex-protocol

The latest addition to the AdEx protocol is the Registry. Its purpose is to allow publishers and advertisers to appoint (nominate) publicly available validators for their campaigns, therefore eliminating the need for them to run their own validator nodes.

It also allows anyone who wants to run a publicly available validator (and earn validator fees) to gain exposure by staking ADX. If they misbehave (in most cases, this means to become unavailable, therefore stalling the campaign), a portion of the staked ADX will be burned and they will be temporarily delisted.

This is what guarantees the Registry is a reliable list: every validator on the Registry has skin in the game. The larger the stake is, the higher the possibility of the validator being nominated for a campaign.

Choosing validators

Each campaign maps to one OUTPACE channel, which has a validator set. While it is possible for any number of validators to be appointed, only two validators are required for a trust-minimized setup, as long as they have opposing interests. You can read more about this here: https://github.com/adexnetwork/adex-protocol#validator-consensus.

In this minimal setup:

• The leading validator is the advertiser-side platform;
• The following validator is the publisher-side platform.

In reality, this means that large advertisers will probably want to run their own validator node (advertiser-side platform) and appoint the second validator through the Registry.

However, once the Registry is mature enough, it will be reasonable for advertisers to nominate *both* validators from the Registry, since it will maintain separate lists for advertiser-side platforms and publisher-side platforms, therefore satisfying the condition of appointing opposing sides.

Staking and ADX economics

The ADX token originated as a fixed-supply ERC20 designed to be used in the AdEx ecosystem.

Choosing ADX as the staking token for the Registry is critical for its security: since this is ADX’s primary purpose, the implication is that most of the tokens will be staked; this makes Sybil attacks much more expensive. Furthermore, it aligns incentives: the healthier the ecosystem is, the more demand there will be to be listed on the Registry.

Bear in mind, even if you hold a trivial amount of ADX and don’t have the resources/intentions to run your own public validator, you can still stake them by nominating another public validator, therefore earning a proportionate part of their fee profit.

Implementation

For the implementation of the Registry, we chose Parity’s Substrate framework which recently reached it’s 1.0 version.

Substrate takes building blockchain systems to another level, by utilizing a highly modular approach where all the boilerplate parts come as part of the framework, and all the logic (consensus, block authoring) is up to you. It’s also compiled to WASM — so it can be easily swapped and upgraded.

This, along with the Polkadot protocol, allows us to eventually build the Registry as a “parachain”: a type of application-specific chain that benefits from the security and consensus mechanism of the Polkadot network, while being interoperable with other blockchains (including Ethereum).

Ultimately, the combination of Substate+Polkadot gives us the following benefits:

• Scalability: Having a separate chain with a fast consensus mechanism dedicated to the Registry allows it to sustain high throughput; this is required for the underlying security of the challenge mechanisms.
• Interoperability: Fast finality consensus mechanisms allow easy interoperability between blockchains; this lets the ADX token to be moved between Ethereum and the Registry parachain. That factor could be beneficial for OUTPACE as well, as it enables using various cryptocurrencies (e.g. BTC, Zcash) as a channel deposit.
• Upgradability: Since all of the custom logic is represented by a state transition function defined in WASM, it’s trivial to ugprade.
• Governance: Substrate’s Runtime Module Library (SRML) comes with various on-chain governance primitives that may serve valuable in the future.
• Flexibility: Substrate-based systems can be deployed as Polkadot parachains or independent blockchains, as well as be adapted to serve as sidechains to Ethereum.

We’ve already started working towards this by creating adex-protocol-substrate. Currently, this repository hosts an OUTPACE implementation, and it will be updated over time to add the Registry as well.

We’ve described our experience building on Substrate here: https://hackmd.io/p_v1M8WGRyy9PggYiKA_Xw#.

👹 Ameen Soleimani on Twitter

Pretty cool Rust implementation of the @AdEx_Network OUTPACE (off-chain unidirectional trustless payment channel) on @polkadotnetwork's Substrate https://t.co/LuwrolRmjf Great to see more platforms and experimentation for web3!

The road ahead

Once the AdEx dApp is updated with the new protocol, and the validator stack implementation is more mature (we estimate this will happen in February 2019), we will provide instructions for everyone on how to run their own validator nodes.

The Registry is expected to be ready around Q3 2019 in terms of specification and reference implementation. At that stage, we will also provide instructions on how to setup public validators and stake ADX to register them.

The specification for the Registry is still a work in progress, but meanwhile you can track its development here: https://github.com/AdExNetwork/adex-protocol/issues/7.

Interested in AdEx? Follow us:

Website | Telegram | Facebook | Twitter | Reddit | GitHub

It’s time for an update again!

Since our last status updates related to the AdEx protocol, an awful lot of things have evolved.

Most notably, the entirety of the AdEx protocol has been documented here: https://github.com/adexnetwork/adex-protocol. This marks one of the most significant milestones for the AdEx protocol, as it also means most of the parts have been finalized.

Following the Web3 Summit in Berlin and Devcon4 in Prague, we refined one of the most important concepts in our protocol: OUTPACE: Off-chain Unidirectional Trustless PAyment ChannEls. This is what allows direct micropayments between advertisers and publishers, without any on-chain transactions. Expect a follow up blog post entirely dedicated solely to OUTPACE.

Talk is cheap. Show me the code.

Other than documentation/specification, we actually already have a working implementation of most of the protocol!

An Ethereum implementation of OUTPACE can be found here: https://github.com/adexnetwork/adex-protocol-eth.

And a reference implementation of the validator stack can be found here: https://github.com/adexnetwork/adex-validator-stack-js.

We are currently working to port the dApp to the new protocol, as well as improvements to the SDK (adview), so stay tuned!

We’re hiring

Amidst news of layoffs in the space, we’re still hiring, so if you happen to be looking for opportunities in the space, check out our open positions.

Interested in AdEx? Follow us:

Website | Telegram | Slack | Facebook | Twitter | Reddit | GitHub

Quick announcement: most of our team will be at devcon4 in Prague!

If you’re around, there’s many reasons to come to our booth and say hi:

1. if you feel like it
2. if you want to talk about our revised protocol
3. …or our layer 2 scalability solution and the Ethereum implementation
4. learn more about our exploration into Cosmos and Polkadot
5. grab a t-shirt or other cool merch :)
6. last, but not least, come see a demo of our dApp!

See you there!

Back in 2017, we set out to expand on what we’ve developed (The AdEx dapp). Our goal was to develop a set of primitives for transparent and decentralized digital advertising, under the name of AdEx Protocol.

Following the update last month, and the initial draft of our new spec, and the announcement of OCEAN, we have more exciting updates for you…

As you probably already know, some parts of AdEx are built on blockchain technology, and so far this has been Ethereum.

Ethereum is, and will continue being the backbone on which the AdEx dApp runs. The community is undeniably amazing, Ethereum 2.0 will bring sharding and eWASM, and we have a ton of reasons to be excited about. Check out the implementation of the AdEx Protocol on Ethereum here: https://github.com/AdExNetwork/adex-protocol-eth

However, we are constantly experimenting and exploring technological alternatives.

What we’re most excited about is interoperability and application-specific chains, sometimes called dAppchains. We believe that application-specific chains are great, because they provide horizontal scalability in a very natural way, and give us more flexibility, which in turn allows for better UX. To keep this brief, we will explore the benefits of application-specific chains later with a follow-up post.

The projects we’re particularly excited about are Cosmos and Polkadot, which are both very similar, but offer different tradeoffs. Both of them are built on innovative consensus mechanisms, namely Tendermint and GRANDPA. We will further explore the similarities and differences between the two in another follow-up post.

But now, the actual announcement…

We started building an implementation of the AdEx Protocol on Cosmos, and we’re almost done: https://github.com/AdExNetwork/adex-protocol-cosmos

In this repository, you can find a full implementation of on-chain parts of the AdEx Protocol, namely the OCEAN implementation that allows an advertiser to commit on-chain that upon certain ad goals, they will pay out a certain reward to a publisher.

We started building the Polkadot (actually, Substrate, which is the framework behind Polkadot) implementation as well, and it will appear on GitHub as soon as there’s something that works.

But wait, does this mean you’re migrating away from Ethereum?

Short answer: No.

Long answer: AdEx is a blockchain-agnostic project, we may implement the protocol in any technology we think is worth it. We also believe in a future where most blockchains are interoperable with each other.

Most likely, we are going to continue supporting the Ethereum, Cosmos and Polkadot implementations, and let the community dictate which one of those is our dApp running on. For now, and for the foreseeable future, this will be Ethereum.

Considering Cosmos and Polkadot are so similar, why #BUIDL on both?

As we previously mentioned, both offer different tradeoffs. For example, Cosmos provides a convenient SDK for developing dAppchains, and is further ahead in terms of development, while Polkadot offers more powerful inter-blockchain communication and a shared security model, where application-specific chains can benefit from the security of more general-purpose hub chains (also called relay chains).

In other words, to put it directly, we’re excited about both and want to get our hands dirty. It’s not really that much of an extra effort, given how simple the on-chain part of AdEx is.

What’s next?

1. Publishing a series of step-by-step guides on how to create your own dAppchain on both Cosmos and Polkadot (Substrate)
2. Releasing the source code of the Polkadot (Substrate) implementation
3. Launching a testnet for both
4. Improving both implementations: tooling, JS libs, CLI, etc.

Interested in AdEx? Follow us:

Website | Telegram | Slack | Facebook | Twitter | Reddit | GitHub

Once again, it’s that unfortunate time where we have to warn you to protect yourselves from scams.

First off, we have to start by saying that the AdEx Contribution Campaign was over by the end of June 2017. Anyone who is offering you participation in any token sale event supposedly run by AdEx is scamming you!

We have been notified recently that someone has been conducting a fraudulent AdEx ICO in China. They use pictures and videos of us to additionally help their cause.

In June 2018, we were approached by an individual who wanted to meet with us to discuss a potential partnership. Me (Ivo) and my co-founder Dimo met with that individual and his associate over lunch and dinner. They offered us community management services, and we politely refused. We never entered into any agreement with them, formal or otherwise.

Since then, we have not heard from those individuals, until we were informed of this by a member of our community.

To summarize:

1. Anyone claiming to be running an ICO associated with AdEx is lying
2. Stick to the official website https://www.adex.network, this Medium blog, and our Twitter. Do not trust any other source!
3. AdEx Network OÜ will NOT approach you in regards to any token sale
4. We have no agreement or relation with the individuals pretending to be running an AdEx ICO in China

We urge our community to help us to circulate this message to as many community members as you know.

Finally, we want to add how disturbing it is that this is happening. Things like this are precisely what skeptics use against cryptocurrencies, blockchain and our community — and they do have a point, things like this really do happen often. We are committed to doing everything in our power to (1) inform our community and (2) approached our legal counselors on taking the necessary actions

GPG Signed version of this message: https://gist.github.com/Ivshti/7c47ef2ce8a28274f32b88402bf20eda

— — —

UPDATE: Chinese translation:
警告！假冒AdEx币风险提示

我们近期了解到有人在中国进行假冒AdEx币进行诈骗的活动。过程中使用了我们的照片和录像。

我们警示：AdEx募集活动于2017年6月底已经终止。现在任何以AdEx名义的发币活动都是诈骗性质的。行用我们照片和录像的行为没有经过授权，属于盗用我们的名义和肖像。

请注意：

• 任何人声称与AdEx有关的ICO活动都是谎言
• 认准官方网址https://www.adex.network， 本布告栏，和我们的推特。不要相信任何其他的消息来源！
• AdEx Network OÜ不会与您联系销售事宜。
• 任何运行AdEx在中国ICO的人与我们没有任何协议或其他关系，均为假冒。

我们促请成员们向您认识的所有成员扩散本消息，勿周知。

Off-Chain Event AggregatioN

When building blockchain applications (dApps), we often face the challenge of taking as many things as possible off-chain — but while retaining the benefits of the underlying trustless consensus at the same time.

But why do we want to do this? Well, by design a decentralized consensus means that every validator/miner in the network has to compute the result of all transactions. This makes it expensive to use on-chain transactions for every action in your dApp. On top of this, most actions in a dApp do not actually require changing a global ledger.

The most popular ways for off-chain scaling are state channels and sidechains (such as Plasma), but we felt that the particular case of AdEx did not fit in any of those scaling solutions. This is why we came up with a solution that felt more natural to us; later on, we discovered that it could be useful for more projects.

We call this scaling mechanism OCEAN: Off-chain Event AggregatioN. It’s a very simple way to scale dApps: certain events happen off-chain, and are eventually committed to the chain, therefore providing the underlying security. Sounds a lot like a state channel, right? Wrong.

OCEAN is quite different. A state channel is usually an interaction between two parties only, where those two parties finalize the said interaction themselves. OCEAN, on the other hand, defines validators beforehand. These validators are supposed to observe interactions between any number of parties, and then vote on the the overall result on-chain.

An OCEAN flow goes like this:

1. A commitment is written to the blockchain, defining the end goal for the OCEAN channel (for example: 100 click events, signed by different whitelisted public keys), the validators, the validator rewards and the channel timeout.
2. The off-chain events transpire and the validators record them.
3. Within the timeout, the validators sign their vote, and over 2/3 signatures for the same vote value are required in order to be committed to the chain; the channel is considered finalized, and you can handle the result however you wish on-chain.
4. Beyond the timeout, the channel is considered expired and is reverted.

Within AdEx, anything between the beginning and the end of a delivery commitment is tracked off-chain (e.g. clicks, impressions, etc.), and committed on-chain by the validators (usually the publisher, advertiser and an arbiter) at the end. A ‘success’ vote means the publisher will get paid, and a ‘failure’ vote means the funds will be returned back to the advertiser.

You can see a working implementation of OCEAN here: https://github.com/adexnetwork/adex-protocol-eth

You can think of an OCEAN channel as a mini, one-block blockchain with pre-delegated validators. This is especially useful when:

1. There is a clear, logical and game-theoretically sound way to select validators;
2. There are clear start/end points of your dApp logic that correspond to opening/closing of OCEAN channels, where the result at the end would define important actions (e.g. funds being transferred);
3. There are interactions between multiple parties (ones that have never interacted with the blockchain) that need to be resolved or settled relatively quickly.

To make this more clear, here’s an explanation of the AdEx use case:

1. The publisher and advertiser have opposing interests, so a logical validator set will be: publisher, advertiser and arbiter.
2. When the publisher accepts to deliver an advertising bid, that’s a new OCEAN channel. It gets resolved when the publisher proves that they delivered the ad, and upon resolution the funds would be paid out to them.
3. The interactions happen between publishers, advertisers and any number end-users, where the end-users do have an automatically generated cryptographic identity but have no Ether.

OCEAN use cases

While the current implementation is specific to AdEx (validating impressions/clicks of ad bids), we believe that there are many other possible use cases for OCEAN, for example:

• AdEx: real-time bidding
• Social network: polls, voting
• Sidechain: you can implement a BPoS (bonded proof of stake) sidechain where every block is an OCEAN channel, and the final committed vote is a merkle root of the entire chain state; every finalization would save the new validator set on-chain, allowing validators to bond/unbond; since the merkle root is committed on a PoW chain, long range attacks are not feasible.

Is OCEAN trustless?

By itself, OCEAN relies completely on the validators you delegate when an OCEAN channel is opened. So it is as trustless as the method you use to delegate the validators. A good OCEAN implementation should (1) delegate validators who don’t stand to gain from their own malfeasance; (2) incentivize voting by validator rewards; and (3) implement stake and slashing if possible.

In most cases, most of your OCEAN validators would be the most important participants in the interaction themselves, along with third-party mediators.

Comparison

State channels

State channels are designed for interactions between two parties. You can use state channels for multi-party interactions too but that’s usually a network of multiple two-party state channels.

OCEAN channels are designed to handle multiple-party interactions in a much easier way, with much easier on-chain exits. For example, in a multi-party state channel network, each of the channels will have to exit/checkpoint before you could actually transfer a token reward out, while with OCEAN you’d only require finalizing a single OCEAN channel.

It needs to be said that a well-designed network of state channels may never need on-chain settlement. However, as of today, in a real world scenario, your users would actually need their funds to be moved on-chain if they want to spend them.

Furthermore, the trust model is different in that state channels rely on the participants to settle the channel, while OCEAN relies on delegated validators. When you scale that to multiple parties, however, it starts to look similar: you can have all the participants in the interactions be the validators on OCEAN. Should some validators decide to group together and act malicious, if they’re less than 2/3, they risk stalling the OCEAN channel and letting it timeout, therefore possibly getting slashed (depending on the implementation).

There’s much more to be said on the tradeoffs of both approaches, so expect a follow up post on this later this year.

To learn more on state channels, we recommend you check out https://www.learnchannels.org/

Plasma

Most Plasma designs are sidechains for fund/NFT transfer, while an OCEAN can be used for any arbitrary events/computation.

In a dApp design, a Plasma chain would be expected to always stay open, meanwhile OCEAN channels would get opened/closed all the time.

Plasma delegates a single validator, but does it’s best to allow users to exit, should the validator misbehave. In OCEAN, we trust the validators completely, so delegating the validators in a fair and trustless manner is critical.

Something interesting to mention is that you can implement a sidechain using OCEAN as well, by implementing PoS with slashing. Each block would be a separate OCEAN channel, getting resolved by a vote for the correct state merkle root. The state would contain the new validator set, since it might be changed if someone gets slashed. The next OCEAN channel (for the next block) would only respect votes from the new validator set.

Compared to Plasma, this OCEAN-based sidechain will not have the exit guarantees, instead shifting the trust into the validators, and relying on a BPoS (bonded proof of stake) system to ensure they behave correctly. Such a sidechain will be much more suitable for arbitrary state transitions (smart contracts/ EVM), because the security model relies on ensuring validators behave correctly rather than on exit guarantees, which depend on UTXOs/ clear coin ownership.

We will publish a follow-up on this use case of OCEAN later on.

For more information on Plasma, this post is an excellent start: https://medium.com/tendermint/blockchain-scaling-solutions-cosmos-and-plasma-b5ee09456f80; and, of course, https://www.learnplasma.org/.

When should I use OCEAN?

Generally, the answer to this question depends on the logic of your dApp.

If the interactions are state transitions, are strictly ordered, and often flow between two parties, you probably need state channels.

If the interactions are mostly fund transfers, you probably need a network of payment channels or Plasma.

If, however, interactions have a complex flow and you need to exit on-chain often, we recommend you look into OCEAN.

Protocol

The OCEAN protocol is very loosely defined, allowing each particular design/implementation to extend it and refine it for the particular purpose.

The basic building blocks are:

• startCommitment(*any args*) -> commitment: starts a commitment with specific goals, validUntil and validators; logic on how to determine those is up to the application;
• finalizeCommitment(commitment, vote, signatures): finalizes a commitment with a vote; signatures is an array of signatures, each index corresponding to the given index of validators; a validator must sign keccak256(commitmentId, vote); whether the validators will be rewarded and what will happen on specific votes is up to the application;
• timeoutCommitment(commitment): called to clean-up after a timed out commitment and perform the revert; this is not needed on systems where you can define your own block start/end behavior, such as Cosmos/Polkadot.

For a deep dive into the protocol, we have a working implementation at https://github.com/AdExNetwork/adex-protocol-eth and a protocol description at https://github.com/AdExNetwork/adex-protocol.

Interested in AdEx? Follow us:

Website | Telegram | Slack | Facebook | Twitter | Reddit | GitHub