AMA with Medha (CTO CasperLabs)
The below AMA (Ask Me Anything) was conducted with Medha Parlikar the CTO of CasperLabs) on 02-Aug-2021 and based around pre-submitted questions from community.
The questions were grouped into the following higher level topics:
- Introduction
- General
- Network
- Marketing
- Enterprise Focus
Introduction
Would you kindly share some insight into your background and personal journey working at CasperLab?, Maybe also some insights into the team/talent at CasperLabs and collectively how you have brought CSPR to production – any challenges, and high and low points through the journey?
Oh this is a good one.
I’m Medha Parlikar, the CTO and one of the Co Founders of Casper. Before this, I worked at software as a service companies in a variety of verticals, like Content Delivery, web analytics, and fintech, at companies like MP3.com, DivX, Omniture, Adobe and Avalara.
Been in SaaS since about 1999. Before that I worked in Educational software. I”ve worked in about a dozen companies in my career.
I worked in QC, Core development, product and program management – as an Executive.
Fell into Crypto in 2017 when a buddy of mine asked me to run an open source blockchain project for him. That’s when Mrinal and the other investors / coFounders of Casper came to know my work.
Learning about the tech was a crazy journey for me.
On starting CasperLabs, I’m super proud of the team we have built.
When we founded the company, we started with 6 developers, and I’m happy to say, 2 of these core developers are still with us today. In the history of the company, we have only had 3 developers leave. To be clear, of all the developers we have ever hired, only 3 developers have ever resigned. This is huge!
Our 42nd team member joined today.
There are some funny stories about hiring in the early days. Early on Mateusz told me -‘Medha we need a consensus expert’, so I went to LinkedIn and started recruiting. I”m happy to say of all the pings I sent, Andreas was the one that answered. The rest is history. He’s been with us since then.
On recruiting Daniel Kane, I heard about his work from the Stanford blockchain hackathon, and I literally got into my car and drove to his office – after sending him an email. I pitched him the opportunity and that’s how he came to work with us.
Ed Hastings and I worked together for a few years while I was at Avalara, and he is one of the most rock solid developers I’ve ever met. I always wanted to work with him – and he – with me – so we hired him as soon as we could.
I’m proud to say that a lot of the people on the project have been referred to us by existing team members. This is super important to me.
Challenges:
Well -getting the protocol through research and to implementation! Making the choice to move to rust from the split architecture was a huge challenge.
Fundraising, keeping the lights on was also rough. 2020 was a difficult year. The devs stuck it out though, they kept the faith. Mrinal and I worked like crazy to bring in the money we needed to fund the company. Cliff and Neil worked around the clock to make it happen..
The high point was obviously the CoinList sale. We were just stunned at the response we got. With the way 2020 went, none of us expected it at all.
And of course, the launch of mainnet – big high. Sealing the deal with BitGo – also a big win for the project.
General
Blockchain Trilemma – Some insight into the blockchain trilemma and how CSPR is attempting to solve it?
We are solving it with good old fashioned Engineering.
- Better consensus protocol that is fast and efficient.
- Does not use statistical algorithms for finalizing blocks
- Validators have to vote on blocks. Weight depends on stake.
- Decentralized and permissionless. Allows validators to come and go as they wish.
- Low footprint of a node + easy to spin up.
I wont get into the tps war with projects. It doesn’t matter how fast it is if security is compromised.
Highway protocol – How the highway protocol compares with other blockchains?
Highway Does not use statistical algorithms for finalizing blocks. Every validator needs to participate in consensus.
- Along with consensus, incentive mechanisms around rewards are such that rewards are given only for participation – lazy validators are ejected. Validators are compensated only for building the blockchain.
- Avalanche – you could affect that protocol by sending in a bunch of conflicting transactions.
- Algorand uses statistical principles for security.
- Solana requires 256 GB of ram for a node. We require 32 GB
- Eth is slow, and they don’t have a working CBC Casper paper yet.
Roadmap – Can you share your tech roadmap with regards to features and partnerships in the next 12 months?
On the roadmap – We have a few big priorities
- Performance – Protocol overhead, straight up contract execution performance (translation -> more tps)
- Smart contracts ux -more features for smart contract developers that provide more api’s in the contracts library.
- Integrations – more SDK’s, thin clients for bridges
There’s more details in upcoming questions as well.
Network
Number of validators – comment on the reasoning for the initial 100 validator cap and any issues with regard to safety/decentralization this may pose? Additionally are there any plans to change/increase this in the future?
The auction contract has a config parameter to define the number of participants. This is in the chain specification.
Presently the number is set to 100 in the auction. The Auction is configurable by the validator set / community if more validators are desired.
Right now, we need to see stakes be distributed more broadly than they are presently. It is possible for the community to change the number of validators in the validator set if they wish.
This would happen via the upgrade mechanics. We tested 100 validators and found the system to be stable with this number.
Once stakes are better distributed, more unlocks have taken place, we will explore increasing the validator set.
The long tail of the stake distribution adds overhead to the protocol without adding much security.
To me – the most important thing is easy tools for self custody + selecting any validator one wants to stake with. Gotta get CSPR off of exchanges.
The unlock delay in staking – comment on the current 7 era (14 hour) unlock period, and the reasons for CSPR setting a much shorter delay when compared to some other blockchains. Is there a risk to stability of the network considering how volatile the market can be? Has there been consideration to implement something more akin to some other blockchains where the token is fist bounded to the network? The unbinding is where the the unlock delay is experienced and could be typically set to eg. 20 days. However when the tokens have been bounded, the delegator is free to move their stake between validators without any delay. A solution like this will (1) disincentives validators to behave poorly because of the risk of instant loss of stake (2) give more flexibility to delegators to move there stake if a node behaves poorly and (3) increase the stability of the network as the unbounding period is considerably higher.
Few questions here and I will attempt to break this down into sections.
Unbonding delay is short.
- We are aware that our unbonding delay is pretty short for the moment. We did this because the protocol state that the system needed to hold on became very large. Part of this was also because originally, Casper was going to support slashing. Performing cross era slashing made the code very very complex.
We have since had Tim Roughgarden perform some research for us – and it turns out that Slashing is not required in order to secure Casper.
As part of the work that is taking place presently, the consensus team is working on trying to reduce the protocol overhead. Protocol overhead has to go down in order to both increase the validator set, and lengthen the unbonding delay. We believe it will be easier to lengthen the unbonding delay first.
The movement of delegations from validator to validator should not require unbonding first.
We have also observed this, and agree that this is desirable, especially if we want to increase the unbonding delay. I believe this would be a new method in the auction contract that would run at the end of the era, move the delegation from validator X to validator Y. We have not yet sized this effort. This would affect consensus weights, and could only happen when the auction runs. I believe it is possible to do – but it will take time and testing.
The speed through multithreading and sharding – If possible, comment on what methodology CasperLabs is developing/researching to incorporate multi-threading onto the blockchain? How this methodology will impact security and what features may be present to mitigate this impact?
Daniel Kane has started the work on sharding – here are his initial ideas:
- The memory space of our virtual machine is divided up into shards. Shards might reasonably be quite small. For example, by default we could make a shard the memory associated with a single account or smart contract. On the other hand, we might want them to be a bit bigger, to, for example, be large enough that they approximately take up an entire disk.
- Transactions must include a list of all of the shards whose memory they might need to access. A transaction that fails to list all shards it tries to access will fail.
- Each block is given a limited amount of sequential compute time (perhaps a constant or perhaps proportional to the number of tics that have passed since the parent block), and perhaps also given a bounded amount of total compute.
- When a block includes a bunch of transactions instead of specifying a transaction order, it specifies a computation schedule. This schedule uses times from 0 to t where t is our bound on sequential compute time. Each transaction is assigned a sub-interval of this window with the length of the sub-interval given by the computation bound specified by the transaction. Furthermore, the intervals for any two transactions that share a shard are not allowed to overlap. We might make a distinction between reads to a shard and writes to a shard and allow several transactions to simultaneously read from the same shard so long as none write to it. We might also require that the total length of the intervals not exceed some total computation bound or the number of windows overlapping at the same time not exceed some bound.
This should ensure that the transactions within a block are reasonably parallelizable, as the computation schedule essentially provides a mechanism for parallelizing the computation. Furthermore, this mechanism should produce the same results as if the computations were atomic with each operation being performed at some arbitrary time during its interval.
Because each block supports parallel execution, should not affect security.
Vendor Risk – Do you feel there is some vendor risk and potentially routing (back-bone) risk involved? AWS servers used for validator nodes indeed stand out. If Casper really would like enterprise grade level accessibility and high decentralization I would guess/say that more validators are needed and some kind of reasoning/discussion on geographical/regional clustering and dependency. The later could be important in case enterprises are bound by law and tax issues to only use infrastructure in x,y,z region
Yes I tend to agree. The desire is to have more physical backbone infrastructure in the network. From a product perspective (which is my focus) – the best way I can affect this is to make the node as efficient as possible to run – and ensure that Casper is available as Docker, Kubernetes Azure and GCP instances, as well as working with infrastructure providers that are using bare metal.
The good news is that Enterprise has very strict auditing rules around where their infrastructure is run, for those that need to run bare metal, this is a good thing.
It’s important to Know your Validator! Select those that are running bare metal, and support keeping the network decentralized!
Highway protocol – Are you planning any future research collaboration with Dr Daniel Kane? His more recent papers and talks haven’t really been focused in the crypto space.
He is not fully embedded in crypto. He works on Highway and with us only. I think this is a good thing. We continue to collaborate with Dr. Kane & we are supporting his research via a grant to UCSD. We meet with Dr. Kane every week.
Malicious nodes – Is the team happy with the performance of the current endorsement strategy (refined endorsement strategy which is already an improvement over LNC + rapid endorsement spread)? Is there any further theoretical improvement possible before we are in danger of violating liveness, or have we hit the limit?
We have our own malicious node called ‘Stinky’ (He’s Casper’s enemy in the movie) – So we focus on this internally to ferret any security issues that we are concerned about. Stinky tests are part of our pre-release testing.
According to the summit theorem we are where we are supposed to be. Ed Hastings (head of engineering) believes that we can do better in terms of protocol overhead. So we will need to see if we can reduce the overhead.
The good news is that the performance bottleneck in the system presently is NOT consensus – it is the VM. We have a PR in the hopper for 1.4 that improves performance by 5X – in the VM.
So we can definitely improve throughput. What this would mean is either reducing block times OR increasing the number of transactions in a block. We will need to fine tune this – and figure out which one it will be.
Marketing
Dapp interest – Comment on the level of interest you are seeing from dapp developers. Are there any specific types of projects currently showing an interest in building on CSPR?
We have a large number of DeFi applications that are in progress, including a Swap, Dex, AMM and other applications. These are happening via the Dev DAO
- CasperLabs is working on MetaCask – and we are building their whiskey cask auction infrastructure. We are also working with Civic to support on chain KYC.
- IPWe – building their patent marketplace using NFT’s
Both of these DApps are building on the public protocol.
General Marketing – Do you have any info if the CSPR team plans to change its type of marketing in the coming weeks / months? Or is the guideline likely to be the same?
We have recently hired Randi Drinkwater to head up marketing. Expect to see the following:
- Announcement about her joining the team.
- A top level strategy regarding the product, what it is, why it’s valuable
- More communications around the product.
- Better social channel engagement
- Uplifted brand and website
Broadleaf – “Companies including IPwe and Broadleaf are already using the Casper Network to unlock new value by tokenizing existing assets.” This is from whitepaper. We can find information regarding IPwe but we are unclear on Broadleaf? Would you kindly share some more detail or information as to how Broadleaf is using the Casper network?
We are under NDA regarding Broadleaf and we can’t discuss. They are building a product that they want to bring to market.
What I can say is that they are using the public protocol.
Enterprise focus
Regulatory risks – enterprise level services pose much greater regulatory risks. what challenges do you foresee and how do you plan to tackle them?
This is my opinion – Highly regulated companies will not implement blockchain in the near term in the areas that are under scrutiny. Casper is better positioned because we do not take the stance that implementing blockchain has to be ‘big bang’ – blockchain is a small part of a much larger application architecture.
AWS node – Can you share more about the AWS partnership and marketplace node?
We partnered with AWS to build a ‘one click node’ for AWS customers to use in their blockchain deployments. These nodes can be used as unbonded nodes in testnet or mainnet (own RPC) – or to spin up entire networks.
AWS node real world use cases – Regarding the Casper node on AWS marketplace, can you share use cases/application examples? It would be interesting to understand an example of how you feel an enterprise will benefit from this. What should be the utility?
Well – Caper supports private and permissioned networks. Because it is proof of stake, it is possible to limit who has access via tokens. Enterprises that want to use Casper technology as a private network, can easily do so within their own AWS infrastructure.
If there is a broader question around how enterprises will use blockchain, here are some specific examples:
- tokenize reputation. This way I own my reputation, versus it being controlled by someone else on a central server.
- NFT’s to make it possible to sell and re-sell items that couldn’t be represented in that way. Like the whiskey casks.
- Blind auctions (where you have to trust the auctioneer)
There are many many more.
Enterprise adoption challenges – Enterprises tend to use established systems and they usually don‘t invest so much time in new technologies (depends on the company). So why should a company invest time and money to build something they are not sure is going to work out? Do you foresee any challenges therefore with encouraging enterprise adoption?
Again, Casper does not take a ‘big bang approach’ – I believe Enterprise will adopt blockchain slowly. 84% of Enterprises are actually ready. They have clear use cases and are looking to move straight to production.
The key is that blockchain has to integrate into THEIR work streams, infrastructure and development operations. Enterprises are not going to use Truffle Suite in their devops.
Blockchain will ultimately need to integrate into Enterprise workflow tools.
Marketing to enterprise – Regarding the above enterprise use case, we can see a lot of news lately about companies looking to move their existing infrastructure to blockchains (Citibank being one example). Is there an active effort to reach out to these companies to discuss the AWS marketplace node?
I cannot say yet what is happening behind the scenes about this. What I can say though, is that Casperlabs is a professional software company, with the express goal of building blockchain enabled solutions that use the Casper technology. I can share though, that 🤞 we will have some super exciting announcements coming up!
Features for enterprise – Are there any specific feature you feel will be important in enterprise adoption in the next 12 months? Any new use cases defined?
I’m super excited about the contracts + account unification feature. This will make everything on the protocol a contract and give contracts the same features as accounts. This enables contracts to pay for themselves, lays the foundation for associated keys in contracts with weights and thresholds for key management and execution.
This will open up a whole world of really cool things that can be done with contracts that pay for themselves.
Thin clients are imminent, with Fast sync coming in 1.4 – and after that we will start building out state pruning & a rent model for storage.
Really getting to a place where tx. Fees being stabilized is also a big research initiative. Solving this problem IMO is critical.
Finishing On A Lighter Note
Can you give us some juicy gossip of the team. Who’s the joker in the team?
Karan has the best meme’s and gifs. Ed has a great sense of humour. All the guys are just great. Super smart, hard working and flexible. They will do what needs to be done to get the job done.
Is there any gossip on Joe Sacher which we can use to tease him with?
Joe can fix anything given some duct tape and paper clips – call him MacGyver.
(And I dare say, his office looks like the IT support desk at the office 😂 )
Finally, what we ALL have been wondering…..has Mrinal ever seen Amit’s profile picture?
Mrinal hadn’t seen @amircspr pic – until I asked him. Now he has. 🙂
Disclaimer: This article is written for the purposes of research and does not constitute financial advice or a recommendation to buy.