Recap of AMA that happened 3/24/20 in DAO Makers telegram chat, most of the questions were submitted before hand to make the session as smooth as possible. If you want to educate yourself about AVA make sure to check out our article or community driven medium blog.
Emin Gün Sirer introduction:
I built the first crypto currency that used proof of work back in 2002. That was 7 years before Bitcoin. It’s very well-cited among academics, but it was too early. And Satoshi had other innovations that he added. I worked on making crypto more secure, on making it scale, on characterizing its decentralization, and also on Layer-2 protocols. Most recently, I put my tenured position at Cornell on pause and founded Ava Labs, to build a new crypto platform that actually achieves the goals that everyone else has been talking about so long.
Q: The market has proven that newly launched blockchains are not in demand since most are below ICO price. The best performers now tend to have a business model built in the token so that there is some real demand for it. What is your business model or concept for making real demand for the token and not just people betting to hodl?
A: Excellent question and excellent observation. Many new coins have tanked after their ICO. But the reason for that was pure greed. Many projects sold far too many coins to VCs, who then dumped the coins on retail. They had no protections, no timelocks, no limits of any kind. We have raised the smallest amount of any project to date, and we have run an incredibly lean & mean project. But the real question here was about the business model. Let me try to address that. The main purpose of the system we are building is NOT to compete with USD, and it is NOT to build a world computer. We are not trying to compete with these existing plans. I respect BTC and ETH, and wish them great luck in their endeavors. We are building the best digital asset platform, and it’s the only one that has (1) an engine that is fast enough, and (2) a way to issue legally compliant coins. AVA is envisioned as a platform where anyone can create these assets, attach covenants/restrictions/etc to them, and deploy them on networks consisting of nodes that fit certain criteria. For instance, one can create a network where all the nodes are US nodes, or non-US nodes, or nodes that have a minimum level of resources, or nodes that enforce whitelists/blacklists etc, for different kinds of assets. We call these subnetworks. AVA subnetworks are defined by the asset issuers, and they enable assets to be deployed in a legally compliant manner. AVA itself is the giant big network that ties all these subnetworks together. Like the narrow waist of the Internet. I believe this market to be very very large.
Q: I read that AVA is a stake-based system. I also read that descriptions that describe it as leaderless. Wouldn’t the person with more stake be the likely leader?
A: Having the most stake does not mean that the node is a “leader.” The Avalanche protocol is absolutely leaderless: anyone can propose a transaction, anyone who has stake above the min-stake threshold can vote on it. In a leader-ful protocol (e.g. HyperLedger Fabric, Tendermint, etc), there is typically single choke-point through which all transactions must flow. AVA does not have this. If the leader dies, the protocol must then pick a new leader. AVA does not have this either. Any node can initiate, all nodes check validity and confirm or reject.
Q: If more stake does not give me more rights to be the validator, why would I want more than 1 token?
A: There are 3 uses for AVA: (i) used to be a validator, (ii) used to carry out transactions, and (iii) used to define new assets. Being a validator is not the only game in town.
Q: How can you be both decentralized and also legally compliant?
A: First, let’s be clear about the distinction between AVA and the AVA Native Tokens (ANTs) issued on top of AVA. These are similar to ETH vs ERC-20 tokens. AVA is, by virtue of the Avalanche protocol, the most decentralized protocol ever devised. When I talked about legally compliant issuance, I was referring to ANTs. For instance, if someone wanted to issue digital assets for fractionalized real-estate in, say, Brooklyn, they would want to define their own Virtual Machine for how those coins behave, and they would want to control their own validator set for their real-estate coin, so they can comply with legal rules (e.g. OFAC has restrictions that change, which affects what the validators do). AVA enables people to issue an ANT that respects these restrictions.
Q: Would it be possible to dive a bit more into how the native token is applied in the definition of new assets and transaction carriage?
A: Certainly. Creating new assets consumes resources, and the creator of the asset is expected to compensate the network by paying with AVA tokens. In addition, every transaction consumes resources, so AVA transactions must carry fees denominated in AVA. Interestingly, each subnetwork can have its own rules for its fee structure. For the real-estate example above, the validators can demand that they be paid fees in a stablecoin. They may, in fact, demand that they be paid substantial fees! Because the real-estate subnetwork validators might be contractually required to keep records for multiple decades, which costs money. If one were to use a traditional payment chain for recording such transactions, the tx’s would appear as raw hashes to the validators. If one were to use a smart contract platform for recording such transactoins, the tx’s would appear as bytecode. The validators in those systems are unable to provide differentiated services, and they are unable to partake in the value they help create.
This is different in AVA. It’s designed from the ground up for assets. The validators for each subnetwork know exactly what tokens they are supporting, and can demand payment commensurate with the service they provide.
Q: Perlin bases off Avalanche consensus and it has been a disaster. Were you in any way associated or involved with Perlin’s development?
Perlin failed with their implementation of avalanche, did you analyze their situation and what are you going to do that is different?
A: We had absolutely nothing to do with Perlin, except they tried to join our AMAs and interfere with us. It was clear that they did not understand the Avalanche protocol at all. There are no lessons to be drawn from their failure — it was totally predictable.
Q: What was the cause of Perlin’s failure?
A: Lack of qualified people, lack of product-market fit, lack of vision, and a whole slew of other issues. People should realize that we have *already made our code public*. It runs today. Perlin was never able to build something that they could open source. They raised a lot of money, made some weak noises, and then fizzled out. Total train wreck.
Q: Startups are experimenting on local networks to show high TPS and low-latency, and many that try to show high tps also often just use an Amazon server farm. How real-life proven is your version high tps once the validator nodes are really, genuinely decentralized?
A: excellent point!!! Many teams outright lie or do some really dumb tricks to report high TPS. We saw a project claim 1M tps, then they went down to 500,000 after 6 months, then 100,000 after another 3, then 1000 tps, then they unveiled a system that does a few hundred tps. 😂We plan to write a blog post cataloging how people cheat on these benchmarks. The most common trick is to compromise decentralization: if I run everything on my laptop, well, things go fast. Other tricks: don’t write to disk. In fact, everyone uses the same DB, called LevelDB. So if someone says they get 1M tps, and they use LevelDB, they are scamming you. LevelDB cannot do that. Another trick: batch. If a system can only do 1 tps, then I make a single transaction, but I claim that that one transaction contains 1M smaller tx’s, so voila, 1M TPS!!! 😂 All of these are pathetic attempts. I’m used to seeing them among academics, it’s sad to see them used by various groups. We report end-to-end numbers. We have deployed on AWS across multiple geographically distributed regions. In some measurements in the datacenter (clearly marked as such), we have inserted delays corresponding to measured packet transmission delays between cities. But the ultimate test is the code itself. Take it, play with it, see what it actually does. You’ll see that I have been quite conservative in my claims. I’ve always claimed “finalization latency of 1–2 seconds” for instance. The actual latency on our testnet is much much much shorter than that. I should mention that we developed our own alternative to LevelDB as well. 😊
Q: Hi Emin, as soon as the AVA mainnet is available, and the first financial asset from Wall Street has to be digitized/deployed on the AVA platform, what do you think will be the feedback from regulators who don’t even want to approve a bitcoin ETF?
A: I think the regulators will be thrilled to see a platform that enables people to build their own compliant digital assets. That has been the feedback I have received directly from various regulators I have met with. The Bitcoin ETF issue is entirely different. The Bitcoin community goes before the regulators repeatedly with, pretty much, the same proposal. And the regulators shoot it down for the same reason: They say: “Crypto exchanges on which BTC and other coins are traded are not trustworthy.” This is typically the big problem they cite. AVA, the platform, does not address this issue. But I have worked on this topic and I believe that new kinds of DEX’es are possible on the AVA platform that will satisfy regulators and enable all kinds of tokens to be traded securely, guaranteeing that small investors are protected. Can’t wait to get there.
Q: Most blockchain companies are building selfishly on their own solution. Why should someone choose AVA to be the platform for their platform?
A: For a very simple reason: people should build on AVA if they want to have the fastest engine underneath while being able to control every aspect of their deployment. Validators are drawn to the platform because they can offer differentiated, rich services. Token issuers get access to that rich ecosystem.
Getting the engine right isn’t easy. Perlin failed even after they were handed a pretty clear roadmap by Team Rocket. We believe we got it right, and we are running an incentivized bug bounty right now to ferret out remaining issues. If anyone is interested, do download the system and check it out, there are at least a few bugs to be found that we placed there ourselves (and committed to, via a hashed textfile) :-).
We have a unique network model. Almost every single one of the 2000 existing coins out there copied their network model from Satoshi. They have a homogeneous network, one coin, one VM, one network. AVA enables many coins, many VMs, and many different networks.
Q: Open source projects are at risk of early forks that scratch away the open source development power. Not to mention, anyone can just take your work. Is your open codebase at risk of facing severe IP theft? If yes, what’s your solution?
A: Ultimately, the only thing that protects any codebase is the ability of the team behind it to innovate and carry that codebase forward. We have demonstrated that we have the most productive team, with innovations throughout the stack. If anyone can keep up with this pace, power to them! I know I find it hard myself sometimes to keep up with the super bright, super motivated folks who work on AVA :-).