Building a purpose built blockchain for trading - ask me anything

Dr Klaus Kursawe, Vega’s BFT and blockchain researcher (and self-identifying blockchain dinosaur) will be answering questions here on all-things research Friday 22nd 16.00 GMT

To see how we’re currently tackling building a blockchain for trading see this presentation by Klaus from SFBW :point_down:

Feel free to start asking questions!

1 Like

I often wonder about how true decentralisation can happen when so many of today’s underlying services are run by such huge centralised organisations, and for this purpose, flocking seems to take some of that into account.

Could you go into more detail on how flocking can be used to avoid the Amazon effect (making sure that a majority of validators aren’t using the same cloud service)?

1 Like

One of the slides mentions ‘Unfair rushing’ as a potential attack, along with DDOS/front-running and wash trading. What is this attack and how is it mitigated?

2 Likes

Trading systems achieve sub-millisecond latency for colocated traders. Assuming I can colocate with the nodes, whats the theoretical lowest latency for a decentralised network using advanced techniques like flocking.

What is an impossibility result? Can you explain it with an example I could use from real life to impress my friends?

2 Likes

@Candia Flocking itself will not solve that problem (if one is not careful, it might even become a bigger problem if flocking is used). The Amazon cloud effect can be handelnd with the property based add-ons to the stakes, i.e., where we can say we don’t only want 2/3 of the available stake to vote. Rather, we can divide validates into groups, and then require 2/3 of share stake of 2/3 of the groups. If one group is then all validators that use the Amazon Cloud, their influence is drastically reduced (and, anyone else using the amazon cloud will get very little voting power and thus very little payout, so validators are motivated to spread)

3 Likes

@Edd Unfair rushing is essentially what happened when Bitcoin crashed, and coin owners with more resources essentially bribed the miners to give them priority treatment in selling - thus, if someone with little resources saw it coming earlier, they still sold later than the wealthier sellers and thus got a lower price. For a real trading application, this rushing in front of others can be a deal breaker.
Unfortunately there are a couple of impossibility proofs around creating a fair order; we can do some pre-protocol though that assures that if your order is seen by all validators at a time before mine is, then you are guaranteed to be executed first

2 Likes

Hi Vega Team
It would seem that the valuation of liquidity will be critical for an equitable distribution of rewards among market participants. What approach do you plan to take to quantify its value?

3 Likes

@Barney That’s a tough one. I think (without proof yet) that the minimum one needs is three rounds of messages, i.e., three times the latency between two parties (if we’re precise, only the 2/3 fastest parties count). What this time is depends a bit on our diversity requirements - if everyone flocks into the same cloud server, it is blazing fast, but that’s exactly what we want to avoid. This also excludes preprotocols for increased fairness, and assumes that computing time to verify all the signatures is negligible. So my guess is that one can bring it below 100ms (plus the time to tell the world what the result was), but that might require some trade offs we would think about twice.

3 Likes

Hey,

Are you Satoshi?

Hi @SpenceTapi we aim to use a market based mechanism to ensure liquidity is always priced to balance supply and demand. This will allow market makers to reallocate their resources where it is most needed in real time, something we are hugely excited about!

3 Likes

Hey there, I have two questions:

  • what is your staking model?
  • Do market orders have a relative sequence to each other within your blocks and how do you determine this fairly?
2 Likes

Is there a way to combine this work with privacy/anonymity features to provide untraceable trading?

3 Likes

How many nodes are needed in this model for the network to be decentralised enough to be relatively safe? What factors or decisions impact the answer to this?

2 Likes

If someone suddenly deposits a lot of value on Vega is there a risk that the PoS network looks ‘cheap’ to attack vs. the stealable value? If so what could be done to mitigate this?

2 Likes

How do your nodes reach agreement on time?

Furthermore, what other use cases are there for a blockchain with lower latency and better security, besides for trading? Might this end up being widely adopted?

@Maxcock it’s a mathematical proof that something simply cannot be done. This is used a lot to prove the security of cryptographic algorithms - for example, one can proof that it is not possible to fake an RSA signature with more efficiency than factoring large numbers (which we then assume to be difficult).

In consensus, there’s a bunch of more annoying proofs; foremost is one by Fischer, Lynch, ans Patterson from 1985 that in a fully asynchronous system, it is impossible to guarantee for a deterministic consensus algorithm to ever terminate - this is the result that makes it so hard what we’re doing, as we need to find loopholes (e.g., Bitcoin that never really terminates, or use a randomizrd algorithm). Another annoying one is that in an asynchronous system, one cannot achieve agreement if a third or more validators are corrupted (this actually does apply to PoW too, it’s just more hidden)

2 Likes

If you want a really impressive one, there’s a proof that it is impossible to prove if hard problems exist in the first place

4 Likes

Nope, but she says hi

5 Likes