Gluon Plasma Full Spec for Non-custodial Exchanges

  1. Is this assumption correct?

If the operator fails to cancel orders of someone exiting directly from the smart contract, this can be detected and proven via “Exit Insolvency Fraud proof”

  1. Who is running the Orderbook?

The operator

  1. Were any fund safety guarantees discussed regarding order cancelation?

Order creation, modification and cancels do not impact custody. Every exchange needs to be able to cancel orders for any or no reason, for example: to shutdown for maintenance, delisting an asset, etc.

Holding users canceled orders and filling them adversely is detected by the “price time priority fraud proof”.

There are very few frauds that A_1 himself cannot submit a proof on.

This would require A_1 to be live and running a validator node, which sounds impractical for 99% of users no matter how light-weight the validator node is (have to download separate software, keep it always running, etc.)

I can see having a separate group of people, who have much more at stake in the DEX, running these validator nodes with a TrueBit-style incentive scheme. Again, this is possible in Plasma MVP/Cash as I describe below.

Exit games are interactive steps mediated by the smart contract and have the following issues:

  1. can be manipulated by spam attacks to prevents the other party from responding in time
  2. Possibly get miners to exclude challenge responses.
  3. A sudden surge of challenges that empty eth preventing you from challenging more claims.

Unclear what you meant by #3, could you please clarify?

The first two problems are not mitigated in Gluon. Consider a case where a G-block with fraudulent transactions has been submitted (e.g., a “Withdraw” transaction with the wrong amount of Z tokens). Validators will be able to catch that problem quickly, but will have to submit the fraud proof on-chain. The first two problems you mention still hold:

  1. Spam attacks on-chain could prevent a validator from submitting the fraud proof or halting the chain in time (before the next G-block).
  2. You can get miners to exclude the fraud proof or the voting process to halt the chain.

Non-interactive proofs are not games in the sense that once submitted, there is little room for manipulation.

How is this different than existing Plasma constructions? What kinds of “manipulation” are you referring to that Gluon prevents vs. MVP/Cash? Per your whitepaper, it seems like if fraud is detected, it results in a vote to halt the chain (the equivalent of a “challenge”). In MVP/Cash, challenges are issued against individual exits, which prevent the exit from going further. The definitions and outcomes of a challenge may be different, but the requirement of monitoring the operator and on-chain proofs is the same.

Quite the opposite. MVP validation is onerous: every user has to validate the chain every week or they are at a risk of loss. Any system where only the victim can protect himself is weak. In Gluon, a single validator provides security for everyone . This is far more robust than MVP

Dissecting this further:

It seems like only having one validator provide security for everyone is possible because of an account-based scheme as it reduces the amount of data the validator needs to check through, making it feasible for one validator to do the job for everyone. Looking at the implementation of the account-based scheme in your whitepaper, it seems like it’s modeled as a UTXO-based system, where each user has one UTXO per token type (the token’s balance) with on-chain checkpointing effectively happening every G-block. By having each G-block act as a checkpoint, you remove the need to store the UTXO history because anything before the G-block is unchallengeable, and so so there’s no point in storing the history.

You can get a similar benefit with MVP and Cash if you exit the coin and deposit it back to the Plasma chain (“checkpointing”). Of course, doing so is much more inefficient, so having the operator do the checkpointing (reducing the UTXO set to a single balance every time, i.e. an account-based system) without requiring a round-trip cost of going on-chain and back off-chain is a clever optimization. This does require an honest set of validators that have much more stringent requirements to verify correctness of each G-block to ensure that the operator is not acting maliciously. I believe the Plasma MVP/Cash constructions were made to not have any reliance on third parties. There is a perceived security benefit with the MVP/Cash model (each user is responsible for their own security so no need to trust any third party), and there’s a practicality benefit with Gluon (trust a group of incentivized third party validators to do the job since they have something on the line as well).

Detection of frauds in Gluon immediate on seeing a new entry, even before it goes into a block. In MVP, you would need to trace the history of every coin.
[…]
A 10 minute MVP will implode since one can create a fraudulent coin whose history takes longer than 10 minutes to verify.

The benefit you’re touting in Gluon is because of the requirement of always having one live, incentivized, honest validator. This lets any validator (even a new one that just joins the network) assume that everything up until the last G-block does not need to be re-validated. This argument also holds in an MVP world. If you have the same validator requirement, you could have the validator creating checkpoints (the equivalent of G-blocks) that reduce the amount of data someone doing transaction history verification in the future needs to analyze (it would only be data from the latest checkpoint onwards). The key point here is that this is only possible if you introduce a requirement of a live, incentivized, honest validator.

Plasma cash in non-fungible, leading to a knapsack problem when trying to construct transactions that match desired quantities.

Be on the lookout for Plasma Cashflow, which solves this problem.

  1. How will you match […] million utxo history?

I’m curious what your answers are for each of these questions with Gluon as that’ll elucidate some of the tradeoffs you considered and how you made you decision. I’m sure some of them are scattered in the whitepaper, but would be good to get it succinctly included here.

(All of this is not meant as a knock to the Gluon construction. It describes a clever, practical Plasma abstraction and is similar to many of the things we’re doing in our Plasma construction to make things more practical. My goal here is to dig deeper to understand the nuances and motivations behind some of the decisions taken, especially as we’ve considered many of these ourselves.)

Since every (A,Z) is a separate chain, validation can be sharded:

  1. Every user can choose to validate only the assets they are interested in and shard by Z
  2. Validators can shard by account only (shard on A)
  3. Full Validators can use a LRU cache to listen to only listen to recently active users or only listen to market makers, etc.

We havent thought of optimization in depth at this point.

Various optimizations and sharding may enable light validation within the trading client itself

The first two problems are not mitigated in Gluon.

Ways to Spam MVP that is not possible in Gluon:

  1. Gluon can ignore dust deposits. MVP can be spammed by millions of dust deposits which will create millions of deposit blocks. This can overwhelm all participants
  2. Gluon needs a single fraud proof to have high enough gas to attract a single miner to mine the tx and everyone is safe. On MVP every fraud needs a separate challenge.for every utxo thats trying to exit. There could be a million fraudulent exits in a few minutes. There is no way every single challenge will hold.

it seems like if fraud is detected, it results in a vote to halt

No, fraud proof submissions are separate from vote to halt. Fraud proofs are for provable frauds. Voting is for unprovable frauds (ie data unavailability). Both will halt the chain. Data Unavailability is a research topic and we may find a way to eliminate it. Voting to halt is the current best approach to dealing with it.

you can get a similar benefit with MVP and Cash if you exit the coin and deposit it back to the Plasma chain

Will never happen because UTXO shredding guarantees everyone will have many tiny outputs and this becomes uneconomical.

There is a perceived security benefit … each user is responsible for their own security

This is a security weakness, not a benefit. Would you say Bitcoin is more secure if everyone had to verify their coin every week?

This argument also holds in an MVP world.

Your point seems to be that MVP and Gluon are similar. I will say yes, all plasma flavors are similar.

would be good to get it succinctly included here

Until you can answer those questions, my advice is don’t attempt writing a DEX on MVP. This is simply because building something in a specialized domain needs experience in the domain.

Your line of questioning tells me you sense something very unique about Gluon and you are asking yourself “Why this is different? Couldn’t they have just done this in MVP?”

The simple answer is NO. Plasma MVP and Plasma Cash (which were the only flavors when we began) wouldn’t work. Nor would many others that have been spawned since. The UX would be terrible and there would be no traction. We have built financial systems for decades and really loved the bright idea that is plasma. However, it was obvious that no plasma flavor was suitable for trading. So we tailored Gluon for the UX of trading systems.

To summarize:

  • There’s a requirement of an always-live group of validators that every single user must trust, or elect to join, in Gluon which is a critical component to making this work and does not exist in existing Plasma constructions.
  • By having this requirement, you can operate an account-based system and have frequent checkpoints, called G-blocks in Gluon, which reduce the burden of transaction history verification to a limited window of time.
1 Like

You make it sound like a country club. Validators act individually completely oblivious of others if any. They dont all have to be always live. You just need at least one of them live at any point in time. Nothing prevents people from starting to validate and stopping at random times. If a 10000 people do this for a random hour a day, theres a very solid chance that at least one will be live all the time.

You are focused on the history and verification stuff, which I think is the least important part. Why do we have rock solid safe DEXes that no one uses while Bitfinex is still one of the top exchanges?

Gluon is a plasma that prioritizes providing UX similar to centralized exchanges and can scale with volume. Its designed to attract liquidity, whereas other DEXes are designed to repel it. It then adds provable safety, which even many DEXes dont have.

So I would summarize this way:

  • Gluon solves the DEX liquidity problem by enabling a centralized-like latency and UX
  • Gluon solves the DEX scaling problem by being spam resistant and congestion tolerant
  • Gluon adds provable security, which no exchange of its speed has ever had.

I’ve added Joey Krug’s suggestion of Tendermint consensus (see update to original post), this should address your concern about having to trust an always live group of validators. Perhaps other approaches can be taken such as Dfinity’s 423 with aggregate signatures.

A few concerns:

  1. The functionality for a DEX includes maintaining an orderbook of all orders and matching orders from the top of the orderbook when there is a match. The protocol for the Gluon sidechain provides more like a general trading functionality that enables clients to simply send money to another client instead of a DEX. And since transactions are processed by a single operator, it is much easier for the operator to mount front-running than in ordinary DEX where front-runners still need to compete by gas price.

  2. The design of voting to halt is vulnerable to Denial-of-Service attack. An attacker only needs to vote to halt with a small size each time and make finality time for the sidechain very slow.

Please let me know if I misunderstood anything. Thanks!

This would be correct. However, a central limit order book’s behavior is deterministic and any discrepancy is immediately obvious. A fraud proof can be submitted as described in S9.3.5.

An attacker only needs to vote to halt with a small size each time and make finality time for the sidechain very slow.

If the voted amount is too small, it may just delay by one ethereum block (15s), which may not even be noticed. The delay response is stronger if they vote all their tokens at once rather than a bit by bit every block. Only deposits and withdrawals are slowed during the delay, normal trading can progress unnoticed. This would be similar in UX to centralized exchanges today.

They can slow down the chain, but it will cost them 10% of their tokens every time they vote. A hypothetical denial of service attack would cost them a significant chunk of money to delay the blocks by more than an hour. They would have to buy a large number of tokens on the open market to effect a large delay (say one day). The buying pressure would spike the price of the tokens making the attack economically self-limiting.

If no one else joins their vote, then they lose tokens. It is unlikely they will be able to keep this up for long.

Economically, its equivalent to a miner mining empty blocks on your chain. Most of it will be unnoticed. Some of it will happen longer than normal occasionally and it can be annoying, but it would be prohibitively expensive to run a sustained campaign.

This is still not detectable, especially when the DEX aims to scale up and have a large popularity. The orders have to be timestamped by the operator because clients’ local time cannot be trusted. Then if an order is timestamped by the operator, certain network delay should be tolerated and this gives space for the operator to inject their own orders.

Do honest large stake owners have to lose 10% of their tokens every time they vote? If so, this sounds like a discouragement for them to vote to halt when data is unavailable while their own profit is not affected. In addition, since delayFunc takes in voteTally as a parameter, which is accumulative, an adversary’s prior vote has a long-term accumulative impact on delaying the commitment of a new Gluon block. I didn’t mean this reduces the throughput of the sidechain, but this does increases the finality time, which was supposed to be a pro of the design.

This is absolutely detectable on all central limit order books including centralized/fiat exchanges of today. It may not be provable in many instances. The victim and anyone else who can see the victim order will basically see the price move through the victim order and fill a different order at a worse price. i.e. If you had a limit buy at 200, the price will fill 199 before filling your order.

Orders are timestamped by the user AND the operator. The users order timestamp serves to ensure the operator is time-stamping accurately. The operators timestamp serves as the single clock of reference for a price time priority proof. A small clock skew is tolerated to ensure variable ping delays.
As a practical matter, the user clock is adjusted from the server price feed and the skew is adjusted automatically, so for all practical purposes the requests will have nearly same timestamp as the server.

Note that front-running requires the deployment of capital and the smaller the price movement, the larger the capital allocation that is needed to make the same amount of profit. Large ticks on futures products ensures that even if the underlying spot market moves a bit (due to 6 decimal places) the futures product is unlikely to move (due to 1 decimal place) within a span of a few milliseconds. While there is a theoretical possibility of operator frontrunning in the skew tolerance (difference between user and server clock), the profit collected would be so small that its not economically attractive to deploy a huge amount of capital for it; it would be more attractive to just lend it at interest.

When data is unavailable in Gluon Plasma, it affects all users since the rootHashes wont match and they won’t be able to exit. Also note that if the operator steals from one person, everyone else should know they are next and the only rational course is to halt the chain.

Do honest large stake owners have to lose 10% of their tokens every time they vote

If the operator is compromised, there is a very good chance that the governance tokens are nearly worthless in a few hours. Its better to sacrifice 10% of them and save other assets. On the flip side a malicious person would be discouraged from voting falsely or carelessly since they would have to pay with valuable tokens.

an adversary’s prior vote has a long-term accumulative impact

Everything is reset when a new G-block is created.

but this does increases the finality time

Perhaps there is a chance that someone will spend $100K maliciously to delay a G-block by 10 minutes. Or $2M to delay by a few hours or $200M to delay by a day. Its certainly possible since there are some wealthy folks in crypto who have “more money than Rwanda”, but I think its highly unlikely they will dump so much money on a temporary prank, whose only lasting effect is to advertise the robustness of the thing they are attacking.

There are cases when an honest user just happen to have an order that is falsely considered as front-running. This is not provable as you pointed out. And sadly, this is probably undetectable either. You cannot distinguish between a front-running and a case when multiple users just happen to send orders with similar prices simultaneously, which may happen rather often in a exchange with a great popularity.

There is always network delay and with difference of 1 sec in the client’s and operator’s timestamp, it is sufficient for the operator to mount front-running.

An operator can front run at no cost. This is actually a problem in general centralised exchange and I don’t think there is a decent way to detect front-running. And based on the design of this protocol, I think both the functionality and vulnerability are comparable to centralised exchanges instead of DEX. The Gluon Plasma is more like a verifiable centralised exchange rather than DEX.

I think some assumptions on the off-chain network of Gluon Plasma are needed. It is possible that a user is isolated and made to vote and lose 10% of his tokens.

Note that my original statement referred to existing exchanges like NYSE. There is simply no way for a user to front run anything on gluon plasma since the operator clock is used for price-time priority. The execution order in a central limit order is deterministic, given an order price, size and time. Any variance is seen by everyone and provable by S9.3.5. The exception is market orders, which users do not have to use.

This is incorrect. The client knows the network latency and applies the difference when creating an order. For example, if the round trip difference including minor clock differences, network latency and processing time all add up to one second, the client will add one second to his current timestamp and use it instead. This delta is automatically corrected by the realtime feed from the exchange.

Indeed, front running is not impossible. The window to do it is so tight (milliseconds) that it becomes unattractive compared to a regular centralized exchange, where there are no restraints.

As a practical matter user’s limit orders are filled at the limit price and maker orders cannot be victimized. Taker orders would need to specify an IOC flag to ensure that they don’t pay more than they intended.

In the general markets, front running occurs on thin books when market orders are placed because this kind of front running is undetectable and unprovable and you could do it all day with no restrictions of millisecond sized windows.

This is only true on exchanges where you can place orders without depositing capital. On Gluon, this would lead to a solvency violation and is detected by S9.3.3 Counterfeit fraud.

Yes, its a non-custodial exchange with centralized pieces.

Designs to address data unavailability are the weak spots for all plasmas. In Gluon, we need to run a few simulations to get the right mix. Tendermint consensus may eliminate data unavailability and also token voting.

I don’t see the relation between using Tendermint consensus and ensuring data availability? Can you please elaborate?

This is still a work in progress and any ideas are welcome. Security vetting is pending.

The basic idea is in the UPDATE of the original post but let me try to state it differently:

In most other plasmas, the operator manages the chain. In Gluon the operator is the exchange AND manages the chain. These roles can be decoupled. The exchange role only needs to match orders and create ledger entries (including deposits and withdrawals). We introduce a Tendermint consensus validators who listen to these entries and create new blocks and manage the chain.

In such a construction, the exchange cannot withhold data (ie commit a hashroot using hidden entries) because it would no longer be its job. At least 1/3 of Tendermint validators would need to be compromised for an unverifiable hashRoot to be committed.

The exchange can certainly not publish some entries, or skip a few. These would result in the Tendermint block producers simply not committing any more blocks since they wont be able to compute a valid block. So far, the only harm the exchange can do is basically halt itself by publishing anything other than complete fully correct entries. Voting to halt or other ways to manage data withholding by users becomes unnecessary. In a way, users have delegated verification to tendermint consensus but this avoids figuring out the optimal voting parameters.

In a multi-exchange scenario, other exchanges can continue trading on the chain. Only the bad exchange is halted. Multi-exchange needs to address race conditions during deposits and withdrawals and needs some work on co-ordinating fills.

Thanks @bharathrao, I’ve missed the UPDATE part, now I’ve read it, along with your reply.

This setup is certainly better than the one with the centralized operator. However, Tendermint (being a modification of PBFT) has quadratic message complexity (which means it becomes very slow when the number of nodes increase). This means that you will always have a low node count in practice, which means it’s very realistic to expect cartelization. Speaking of cartelization:

If 1/3 +1 validators are malicious, they still can not commit malicious blocks (2/3 is needed for consensus). What they can do is halt the consensus, and they can not be punished for this (unless you introduce some sort of “slow bleed-out” function, similar to what Eath 2.0 has for unavailable validators).

The same as above.

Thanks for the correction.

I see, thanks for the input. The other option we are considering is Dfinity style consensus using BLS signature aggregation. This can probably be done log(n) due to BLS properties.

Or crypto-economic signatures as described here.

Either way, we should be able to support 400+ validators, which should be fairly resistant to cartelization.

I think that would be awesome.

A highly decentralized validator set instantly solves most of the issues. :slight_smile: The hard part is to chose a proper consensus (I generally like Dfinity’s approach) and to bootstrap the network (token economics has to be tuned well).

FYI, leverj is live with Gluon Plasma. An excellent example of research turning into a working product. Just wanted to thank everyone for their input and vetting the idea.

1 Like

That is great, good luck and keep us updated. :crossed_fingers: