AVA:Q&A – Panama Crypto – Medium

0 32


Kevin Sekniqi — Co-founder

1. For those who don’t know you, who is Kevin Sekniqi?

I am a PhD candidate in computer science at Cornell University. I am now working on AVA full time. I’m passionate about edge tech and entrepreneurship.

2. What are you currently working on aside AVA and what are your plans for 2019 onwards?

A little bit of everything, from platform building to business operations. I think quite a bit about making it all happen, with most of my focus on the infrastructure and the various applications that should be built and that provide high value proposition for users.

3. How did you get into cryptocurrencies?

I’ve been a longtime crypto fan, longtime lurker, and only recently more publicly involved. At some point in 2010/2011 I found out about Bitcoin somewhere on Reddit and thought it was awesome, so I ended up running a small mining operation during high school. I then “re-discovered” crypto again in 2013. This continued for a few more times, until I finally became “full-time” at some point last year.

4. What sets AVA apart?

A multitude of things, but let me try to deconstruct our moat as the composition of two parts: the core tech and the platform itself.

AVA is built on Avalanche (released last year by Team Rocket, with additional internal updates), which is a new family of consensus protocols that flips lots of standard consensus literature on its head. To our best knowledge, all consensus protocols in deployment, besides longest-chain (Nakamoto style), use all-to-all voting, or “quorums”, for their core operations. A wonderful property of all-to-all voting is that it is relatively easy to reason about in terms of security. This is because one needs to simply demonstrate one invariant: once a threshold number of nodes all vote for a particular proposal, there will never be any other equal-sized or larger threshold number of nodes that also vote for another, yet conflicting proposal. Guaranteeing this invariant may sound scary and complicated, but it is actually quite intuitive, and is simply a matter of some set intersection arguments!

Now, since voting is all-to-all and we rely on very strict quorum sizes, these classical voting-based protocols provide exactly zero probability of failure (assuming that the number of Byzantine nodes is precisely less than an upper bound, usually labelled “f”, and not a single more). As you can imagine, however, this also means they are incredibly unscalable, since by definition we require full information from nearly all nodes. Every node needs to verify from every other node that the minimum threshold quorum size has been met.

Avalanche changes this all-to-all voting requirement, and no longer requires full information communication between all nodes. Just like Nakamoto consensus, this means that Avalanche provides a non-zero probability of failure, although this probability can be made negligible. In return for this non-zero probability of failure, we get best-in-class scalability (in fact, turns out that the message complexity of the system is nearly independent of the total number of nodes in the system, which is an amazing property). Furthermore, the core primitive (called Snowflake) provides an additional amazing property: the inherent metastability of the system provides a built-in-way for the system to make progress without any leaders (which is typically required in any all-to-all voting-based protocol in order to make progress). This allows Snowflake to operate in an entirely leaderless way, although certainly adding a leader could be a useful optimization to certain side-chains on AVA.

However, we are also innovating at the platform level, with lots of key innovations, from great usability and onboarding features, to high developer flexibility and platform compatibility. Although unfortunately I can’t share much just yet, I will share one of our biggest platform moats: the notion of a platform of platforms. This is a really powerful differentiator, which allows developers to interoperate heterogenous systems (eg., coins with their own scripting languages, VMs, etc) seamlessly within the AVA ecosystem. Imagine, for example, a chain which understands WASM and operates under its own set of rules, operate with another chain that understands EVM, under an entirely different set of rules, all made possible by subsets of the AVA network of validators. Our vision is to make AVA the most heterogeneous, backwards-compatible, scalable, secure, and flexible platform for highly decentralized and disintermediated applications.

5. How will governance be achieved in AVA?

Governance is obviously an important aspect for any platform, since things will always evolve, and thus any software system will require a notion of “self-amendment”. In centralized software systems, whether closed or open-sourced, the development team or foundation sets the rules. However, in a decentralized system, there ostensibly is no development team in charge. This leads to contentious debates between various parties, and potential forks.

Tezos-style governance is an interesting play, as in everything is up for governance. It may turn out that such flexibility in governance may pose no real risks in the long term, but this remains to be seen. Allowing all participants in the system to change consensus rules may be democratic, but it may also open the system to arbitrary and high risk attack vectors. Bribing from secondary markets may successfully allow external malicious parties the ability to initiate critical and covert core consensus changes, exposing the system to dangerous bugs and catastrophic failures, potentially while also obviating slashing and other penalties. Instead, these types of changes should typically be delegated to platform experts, core developers, etc., performed in an open, and transparent process.

In contrast to Tezos, AVA governance is more restrictive, and is designed to mitigate premature economic planning, arguably the area of highest contention. In AVA, governance is focused on a limited (but critical) set of parameters which must be open to all participants, including minting rates, staking amounts, etc. This effectively reduces to dynamic, crowd-sourced, parameter optimization. Central banking, for example, is simply a dynamic governance process. Limiting the amount of on-chain governance is also important in regards to establishing a contract with your users. I believe that without well established limits to governance, it is difficult, if not simply impossible, to provide reasonable custody risk guarantees.

6. Bitcoin is to POW what AVA is to?

New family of probabilistic, quorum-based protocols, with a highly heterogeneous network of nodes.

7. Can you share some insights on AVA’s roadmap for 2019 and 2020?

Our biggest milestone is the launch of our mainnet. No dates set yet. We are internally working on some very exciting products and partnerships, which we hope to announce soon. We hope 2020 to be the year that developers en-masse onboard to AVA, and this should be a no-brainer for developers: massive performance and scalability (best-in-class, to our best knowledge), and highly heterogeneous, multi-VM/scripting-language capabilities (a more flexible and backwards compatible version of Cosmos + Polkadot, although they are ahead of us in terms of development time, but we hope to close the gap very soon).

8. What can AVA do better than already existing competition?

I’ll just drop a few words: raw performance, scalability, security, flexibility, backwards compatibility, interoperability, and ease of use.

9. What VCs are invested in AVA?

For our first round we purposefully aimed at keeping it nimble, focusing on raising a small amount of money from funds which would provide value far beyond cash. We were lucky to partner with some of the best funds in the space, including A16Z, Polychain, Metastable, Initialized Capital, and Abstract Ventures.

10. What will be the success factor for AVA?

The trillions of dollars of digitized and non-digitized assets moving to AVA.

Additional footnotes:

Let me provide a simple example that demonstrates how quorum intersection works, and this example relates to the parliament of the Republic of Consensuslandia. In this parliament, 100 senators must vote on a new bill, either “Yea” or “Nay”. However, it turns out that 33 of these senators are corrupt, and will constantly choose to change their votes any which way they want. Their goal is to send the country in total chaos and force some people to think that the bill has been passed, while others that it hasn’t. Fortunately for us, this is not a problem! The worse the corrupt senators can do is the following: vote “Yea” alongside 33 of the honest senators and vote “Nay” alongside the remaining 34 of the honest senators. This would create a total vote of 66 for the “Yea” vote and 67 for the “Nay” vote. If we set 67 to be the minimum threshold to pass or deny a bill, then in this case only “Nay” has sufficient votes and thus the bill is denied. All of classical consensus literature relies on maintaining precisely this invariant.”

You might also like

Pin It on Pinterest

Share This

Share this post with your friends!

WhatsApp chat