Motion: Ethereum 1.0 can scale (Uri Klarman vs. Mrinal Manohar)

WEBVTT
00:00:08.980 --> 00:00:14.980
Welcome to another episode of The Blockchain Debate Podcast, where consensus is optional, but proof of thought is required.
00:00:15.460 --> 00:00:16.839
I'm your host Richard Yan.
00:00:17.410 --> 00:00:25.410
Today's motion is:"Ethereum 1.0 can scale." The guests we have today have close ties to Ethereum.
00:00:25.710 --> 00:00:32.189
One is actively working on a solution to scale the 1.0 version, as well as other blockchains.
00:00:32.700 --> 00:00:35.520
The other was an early investor in Ethereum.
00:00:36.450 --> 00:01:16.319
In this episode I learned about: an interesting layer-0 approach to improve the performance of Ethereum 1.0 as well as any layer-one protocol; Disadvantages in layer-2 solutions with similar value propositions in scaling; Main benefits of upgrading from Ethereum 1.0 to 2.0 besides the change from POW to POS; And other non-scaling goodies such as perspectives on M&A of public blockchains in a crowded space.
00:01:17.489 --> 00:01:37.920
Be sure to also check out our previous episodes too, on Bitcoin's store of value status, tokenization and smart contracts, DeFi, Bitcoin halvening, China's future in blockchain, POW vs POS, oligopoly vs multiplicity of public blockchains, and permissioned versus permissionless blockchain for enterprise usage.
00:01:39.180 --> 00:01:45.390
If you would like to debate or want to nominate someone, please DM me@blockdebate on Twitter.
00:01:46.170 --> 00:01:50.659
Please note that nothing in our podcast should be construed as financial advice.
00:01:51.530 --> 00:01:53.359
I hope you'll enjoy listening to this debate.
00:01:53.810 --> 00:01:57.680
Here we go! Welcome to the debate.
00:01:57.290 --> 00:01:59.659
Consensus optional, proof of thought required.
00:01:59.870 --> 00:02:00.920
I'm your host, Richard Yan.
00:02:01.280 --> 00:02:03.829
Today's motion: Ethereum 1.0 can scale.
00:02:04.189 --> 00:02:09.199
Scalability refers to the ability of the network to sustain performance with large number of nodes.
00:02:09.680 --> 00:02:14.330
And it seems long settled that Ethereum 1.0 has this problem of scalability.
00:02:14.840 --> 00:02:18.319
This is one of the main reasons for the urgent call for its upgrade to 2.0.
00:02:18.590 --> 00:02:23.659
That said, I'm very curious to hear opposing views on this quote unquote conventional wisdom.
00:02:23.330 --> 00:02:27.439
To my metaphorical left is Uri Klarman, arguing for the motion.
00:02:27.740 --> 00:02:30.979
His position is that Ethereum 1.0 can scale.
00:02:31.280 --> 00:02:36.889
In fact, I suspect that he would argue that scalability is possible for many other blockchains as well.
00:02:36.621 --> 00:02:41.569
To my metaphorical right is Mrinal Manohar, arguing against the motion.
00:02:42.050 --> 00:02:44.960
His position is that Ethereum 1.0 cannot scale.
00:02:45.409 --> 00:02:48.409
Although this seems, again, to be somewhat of an established fact, I'm excited to hear how he defends it from Uri's arguments.
00:02:48.800 --> 00:02:54.050
Gentlemen, I'm excited to have you joined the show.
00:02:54.080 --> 00:02:54.439
Welcome!
00:02:54.889 --> 00:02:55.370
Thank you.
00:02:55.939 --> 00:02:56.750
Thanks Richard.
00:02:56.870 --> 00:02:57.590
Pleasure to be on.
00:02:58.009 --> 00:02:59.699
Here's a bio for the debaters.
00:02:59.759 --> 00:03:06.719
Uri is CEO and cofounder of Bloxroute, a layer-0 solution aiming to solve scalability bottleneck for all blockchains.
00:03:07.080 --> 00:03:13.800
In particular, the solution operates at the network layer and can be proven to treat all nodes fairly in propagating blocks.
00:03:14.159 --> 00:03:17.039
Uri is an interdisciplinary network researcher.
00:03:17.340 --> 00:03:24.030
His specialty includes alternative content distribution networks, trustless peer coordination and security.
00:03:25.110 --> 00:03:36.180
Mrinal Manohar is a computer scientist and CEO& cofounder of CasperLabs, a new proof-of-stake public blockchain, based on the fully decentralized CBC Casper consensus algorithms.
00:03:36.990 --> 00:03:43.020
Mrinal was previously with Microsoft, the consulting firm Bain& company, and private equity firm Bain Capital.
00:03:43.319 --> 00:03:50.009
He also previously worked at a$1 billion hedge fund, being the sector head for the Tech, Media and Telecom sector.
00:03:50.430 --> 00:03:54.840
He began programming at age 11 and received his Masters from Carnegie Mellon University.
00:03:55.139 --> 00:04:01.289
He has been investing in the space since 2012 and was an early investor in Ethereum, Blockstack and several other protocols.
00:04:01.889 --> 00:04:06.599
As usual, the debate has three parts: an opening statement from both sides, starting with Uri.
00:04:06.930 --> 00:04:10.680
The second round is the body of the debate, with me directing questions to the debaters.
00:04:10.919 --> 00:04:15.360
Both sides are highly encouraged to follow up with their opponent after hearing answers on the other side.
00:04:15.750 --> 00:04:20.250
And of course they're also free to respond to each other's points raised during the opening statement.
00:04:20.670 --> 00:04:22.980
The last round is audience questions selected from Twitter.
00:04:23.250 --> 00:04:25.920
And we'll end with concluding remarks from both debaters.
00:04:26.370 --> 00:04:34.290
Currently our Twitter poll shows roughly 23% agreeing that ETH 1.0 can scale, and 65% disagreeing with that motion.
00:04:34.680 --> 00:04:40.230
We will have a post debate poll and whoever tips the ratio more to their side wins the debate.
00:04:40.709 --> 00:04:40.980
Okay.
00:04:40.980 --> 00:04:42.899
Let's get started with the opening statement.
00:04:43.079 --> 00:04:44.189
Uri, please go ahead.
00:04:44.930 --> 00:04:45.379
Thank you.
00:04:45.439 --> 00:04:46.220
I appreciate that.
00:04:46.550 --> 00:04:53.930
A lot of people in the blockchain space refer to this technology as something which is very complex and very complicated.
00:04:54.319 --> 00:05:06.519
And so if there is a scalability problem, which is: Can the blockchain handle a lot of transactions, not four transactions per second, like Bitcoin, or 10 like Ethereum is handling now.
00:05:06.550 --> 00:05:11.199
Can you do hundreds of transactions per second, thousands, tens of thousands, beyond that.
00:05:11.949 --> 00:05:14.620
So people refer to this problem as being complex.
00:05:14.620 --> 00:05:19.300
They think it's super technical and it has to be very complicated.
00:05:19.779 --> 00:05:22.069
But in reality, it's kind of simple.
00:05:22.819 --> 00:05:27.569
The way blockchains work is that people make transactions, right?
00:05:27.990 --> 00:05:38.660
I'll send Richard one Bitcoin or I'll send Mrinal, one ETH, I'll create a transaction saying send some ETH, for example, from me to Mrinal.
00:05:38.990 --> 00:05:42.860
And I signed the transaction and I send it to everybody in the network.
00:05:43.490 --> 00:05:54.769
And so if people send transactions, these transactions propagating the network and miners or validators here of these transactions and try to aggregate them into blocks.
00:05:55.079 --> 00:06:03.000
So blocks are just like a long list of transactions with the biggest metadata like conversion and timestamp, et cetera.
00:06:03.360 --> 00:06:05.189
And then they have to propagate.
00:06:05.490 --> 00:06:09.720
Once somebody created the block, he has to send this block to everybody else.
00:06:10.199 --> 00:06:13.810
So the next person could add the next block afterwards.
00:06:14.089 --> 00:06:20.569
And the result, as we all know, is a chain of blocks, the blockchain, which contained all the transaction that ever happened.
00:06:21.439 --> 00:06:28.220
Now here's the thing, you can't add the next block before hearing off the previous one.
00:06:28.699 --> 00:06:32.930
And so if you've tried to make the block 10 times better or a hundred times better...
00:06:34.100 --> 00:06:43.160
If I mined a block, which is a hundred times better, it takes me a hundred times longer to send it to my peer, it takes me a hundred times longer to reach everybody else in the network.
00:06:43.639 --> 00:06:48.769
And so the time between blocks has to be increased by a factor of a hundred.
00:06:49.100 --> 00:06:55.129
So the rate, like the frequency of blocks goes down by a factor of a hundred, and you go back to square one.
00:06:55.319 --> 00:06:59.889
You're doing a hundred times larger blocks, but a hundred times less frequently.
00:07:00.430 --> 00:07:03.009
And this is the scalability bottleneck.
00:07:03.100 --> 00:07:03.339
Okay?
00:07:03.341 --> 00:07:20.850
The idea that if you try to do blocks larger, that you take proportionately longer to propagate, and therefore you have to space the block at the same proportion, this is not only a bottleneck, it is THE bottleneck.
00:07:21.139 --> 00:07:28.699
We have seen that you can run blockchains at significantly higher rates than the current being used.
00:07:28.701 --> 00:07:42.360
In Ethereum in Bitcoin and others, we were able to run Bitcoin at a peak of 3000 transactions per second, just by allowing for blocks to propagate faster and doing larger and more frequent blocks.
00:07:42.779 --> 00:07:51.899
And for this discussion, we were able to take Ethereum as is, and run it at hundreds of transactions per second.
00:07:52.170 --> 00:07:58.459
With the only thing that we did was affecting the network layer, allowing blocks to propagate extremely fast.
00:07:58.461 --> 00:08:05.910
And so can Ethereum, ETH 1.x, can Ethereum 1 scale?
00:08:05.970 --> 00:08:07.829
The answer is absolutely yes.
00:08:08.220 --> 00:08:16.430
The only thing you need to do is tweak a bit, and improve a bit the way blocks propagate, and the propagation of blocks, and that solves it.
00:08:17.120 --> 00:08:29.529
The other bottlenecks down the line, processing time, how long it takes to do all sorts of operations, they are orders of magnitude far away, and therefore not a bottleneck at all.
00:08:29.889 --> 00:08:33.360
Now, it remains to be seen if they turn out to be bottlenecks.
00:08:33.750 --> 00:08:43.419
And that's the argument why Ethereum 1.0 can scale, just because there is a single bottleneck as the network layer which is solvable.
00:08:44.360 --> 00:08:45.080
Okay, great.
00:08:45.440 --> 00:08:46.460
Powerful opening statement, Uri.
00:08:46.071 --> 00:08:48.090
Mrinal, please go ahead.
00:08:49.009 --> 00:08:55.809
To start off, I by and large agree with a lot of what Uri said, especially about the congestion of the network layer.
00:08:55.811 --> 00:09:01.929
However, I would like to talk about two things specifically.
00:09:02.529 --> 00:09:08.139
One, I do think the problem is a little more complicated than Uri said.
00:09:08.769 --> 00:09:29.049
And what I'd say specifically there is, in a completely decentralized system where people can choose any sort of hardware stacks they want, choose to be located anywhere and might have extremely different latencies, etc, it might be a little harder to make sure that block propagation is fast enough.
00:09:29.440 --> 00:09:30.820
That being said, it could still happen.
00:09:30.520 --> 00:09:30.820
But secondly, you also want to make sure that you've heard from everyone or at least most of the network, and most of the network has opined on every single block, reason being that's where the inherent decentralized security of the system.
00:09:30.821 --> 00:09:52.779
The second main thing I want to discuss about is what really is scalable?
00:09:52.780 --> 00:09:55.629
I think it's three things, not just one thing.
00:09:55.630 --> 00:10:06.399
I think everyone focuses on throughput, and I think throughput is very, very important and I think that, defining throughput as number of transactions per second.
00:10:07.240 --> 00:10:18.580
I think the reason Ethereum 1.0 cannot really scale long-term, is because proof-of-stake versus proof-of-work is just a much more efficient system.
00:10:19.029 --> 00:10:25.659
Whatever scaling we get on the proof-of-work system, even with better block propagation, will be infinitely better...
00:10:25.331 --> 00:10:29.019
not infinite, many times better in a proof-of-stake system.
00:10:29.320 --> 00:10:30.820
And it comes down to one fundamental thing.
00:10:31.960 --> 00:10:37.809
In a proof-of-work system, 90 to 95% of your processing power is used to generate hashes.
00:10:38.259 --> 00:10:42.879
Fancy word for random numbers, which is what gives us systems underlying security.
00:10:43.899 --> 00:11:05.529
Redirecting that 90 to 95% processing power to doing actual useful work like processing transactions, which is what happens with proof-of-stake model really increases throughput and increases the amount of time that your computers are spending on actual formation of consensus and actual transaction processing.
00:11:11.019 --> 00:11:11.139
The second part of scalability really is security.
00:11:11.019 --> 00:11:27.100
The security of a proof-of-work system is completely related to the emission schedule, because the amount of hardware you're going to put against the system and a proof-of-work system is directly proportional to how many ETH or how many Bitcoin you're going to earn in rewards.
00:11:28.179 --> 00:11:38.500
However, in a proof-of-stake system, the underlying costs to attack the system is actually the total amount of stake that's staked on the network.
00:11:39.309 --> 00:11:45.340
So as the network grows more valuable, there's a one to one correlation in how security increases.
00:11:45.639 --> 00:11:55.220
And I think this is really, really important for scalability because as systems get faster and more widely used, you want security to go up proportionally.
00:11:55.700 --> 00:12:05.929
And the issue with proof-of-work is you'd have to play with emission curves to really make sure that, the incremental cost of hardware is enough to keep attackers at Bay.
00:12:06.230 --> 00:12:12.110
Whereas in proof-of-stake, you have a natural system that has a bonded stake and prevents attacks.
00:12:12.620 --> 00:12:15.049
And then finally I realize the scalability also comes down to developer adoption.
00:12:17.269 --> 00:12:22.039
And ETH 1.0 uses a proprietary programming language, solidity.
00:12:22.519 --> 00:12:27.200
That's the most widely used smart contracting language on the planet.
00:12:27.649 --> 00:12:31.399
But there's like 15 to 20,000 blockchain developers in the world.
00:12:31.909 --> 00:12:36.200
Now you contrast that with 26 million developers worldwide.
00:12:36.590 --> 00:12:39.440
It tells you how under-penetrated the industry is.
00:12:39.860 --> 00:12:51.409
And if you look at polls that are conducted, the primary reason for this is because people aren't familiar with the architectures and programming languages that you use in blockchain.
00:12:51.830 --> 00:12:55.190
People want to use rust, they want to use AssemblyScript, they want to use Python.
00:12:55.879 --> 00:13:06.110
And this is a direction that Ethereum is going to, and it's ETH 2.0, 3.0 builds, where they're going to a WebAssembly type bill, which will support open programming standards.
00:13:06.710 --> 00:13:31.429
And so all three of these issues, throughput, security as well as developer adoption really get much better in the ETH 2.0 and ETH 3.0, which is my belief that, while these 1.0 can scale a little bit more, with, great modifications at the network layer, I don't think it's enough to be sustainable across all these three factors.
00:13:31.460 --> 00:13:34.100
And I think that's really the reason why they're going in the direction that they are.
00:13:35.120 --> 00:13:40.879
That being said, I do think, fixing the bottleneck at the network layer is very, very important.
00:13:41.950 --> 00:13:42.250
Thank you Mrinal.
00:13:42.909 --> 00:13:49.720
Definitely lots to unpack from both sides, but let's proceed to round two, where I'll be directing questions to each of you.
00:13:50.379 --> 00:13:59.740
My first question is for Uri: Can you provide a quick rundown of the various blockchain-agnostic scalability solutions out there?
00:14:00.039 --> 00:14:09.759
For instance, Celer network is a layer-two solution with the same value proposition or similar value proposition, albeit approaching from a different layer than Bloxroute.
00:14:10.659 --> 00:14:10.659
Sure.
00:14:11.591 --> 00:14:18.129
But I will really start with a bit referring to what Mrinal said, because he brought up a lot of interesting points.
00:14:18.799 --> 00:14:20.539
I don't agree with everything that he said.
00:14:20.570 --> 00:14:25.919
One thing he said, it's an argument that I hadn't heard a lot and they, I think I agree with it.
00:14:26.240 --> 00:14:36.659
The amount of tooling and the languages that you can use in the blockchain really is going to affect how fast you're going to get traction.
00:14:36.690 --> 00:14:43.759
Like the speed at which you're going to get more stuff happening, etc, and that's part of growing up, and part of the scalability.
00:14:43.760 --> 00:14:50.679
So it's not a standard way of defining scalability, but I agree that that point is important.
00:14:58.789 --> 00:14:59.000
I don't agree the same way when he said, well, the security has to go hand in hand with the importance of the blockchain, etc.
00:14:58.789 --> 00:15:02.330
It's an important point, but I don't think it relates really to the scalability.
00:15:02.331 --> 00:15:13.559
Scalability is really defined as can the blockchain handle a lot of transactions, less about, can we get people to play with our blockchain, and can we get them to participate?
00:15:14.789 --> 00:15:17.250
So just referring to the point Mrinal brought up.
00:15:17.581 --> 00:15:21.990
Going to your question, it's actually one of my favorite questions.
00:15:21.990 --> 00:15:22.500
I think.
00:15:22.529 --> 00:15:29.789
I think a lot of people are so deep in this space and everybody are running in all direction and it's really hard to keep up with what's happening.
00:15:30.299 --> 00:15:38.580
But having a concise understanding of what is layer-1, what is layer- 2, what is layer-0, how do they play together?
00:15:38.581 --> 00:15:42.299
And these are fancy words, channels and all these kinds of things.
00:15:43.120 --> 00:15:44.679
So I'm really glad that you brought that up.
00:15:45.570 --> 00:15:47.340
The quick rundown is the following.
00:15:47.879 --> 00:15:52.600
Well, the blockchain as we, as I said earlier, is when you have participants, right?
00:15:52.600 --> 00:15:57.039
You have people running nodes, people just sending transactions and they form a consensus, right?
00:15:57.041 --> 00:16:01.990
Somebody creates a block, it goes through everybody else, everybody starts working on the next block, etc.
00:16:03.519 --> 00:16:04.629
That we refer to layer-1.
00:16:05.320 --> 00:16:05.830
Why?
00:16:05.919 --> 00:16:08.409
Because layer-2 is what comes on top of it.
00:16:08.559 --> 00:16:08.769
Okay.
00:16:08.779 --> 00:16:35.379
The idea of a layer-2 like Celer, okay, and I'll give a few examples in a second, is the idea that rather than making a transaction, sending it to everybody else and then wait for that to grow on the blockchain, you could do something like: Oh, if me and Mrinal, we'll just send transactions among ourselves, can we do something that we just transact just me and him, and not put it on the blockchain.
00:16:35.380 --> 00:16:42.110
But eventually or periodically, at some point, we'll commit to the blockchain.
00:16:42.110 --> 00:16:44.629
So we could do something like...
00:16:45.471 --> 00:17:00.889
if people heard of state channels, the idea that maybe I'll put 10 ETH, and Mrinal will put 10 ETH, and now we have a joint account, a channel, which when it closes, I should receive five ETH back and he should receive five ETH back.
00:17:01.399 --> 00:17:03.470
But now, maybe we can update that.
00:17:03.500 --> 00:17:06.769
I can give him without telling everybody else, I can give you 1 ETH.
00:17:07.400 --> 00:17:13.670
So now it's six to him, four to me, then you can pay me three, and now it's seven for me and three for him.
00:17:14.000 --> 00:17:18.210
And we could do that an infinite amount of time, and as fast as we can do that.
00:17:18.269 --> 00:17:22.769
And eventually, let's say a year from now, we say, like, oh, let's settle this.
00:17:22.799 --> 00:17:25.309
Let's put it in the blockchain.
00:17:25.460 --> 00:17:25.730
Right?
00:17:26.390 --> 00:17:33.170
And then, based on that state of our channel,of our joint account, each day, get his correct portion.
00:17:34.670 --> 00:17:38.119
This is the high level of a layer-2.
00:17:53.519 --> 00:17:53.670
Now the complications around layer-2 is how do you make it in a secure way?
00:17:53.519 --> 00:17:53.670
What if it was five, five, and then Mrinal send me three ETH, now I'm supposed to get eight and he's supposed to get two, I go offline.
00:17:53.519 --> 00:18:03.019
I go do some stuff, and while I'm not looking, Mrinal takes the older state, where it's five, five, which is better for him and put that on the blockchain.
00:18:03.920 --> 00:18:09.289
And then if I'm not aware of that this is happening, I might lose my money.
00:18:09.380 --> 00:18:19.410
And so all the complexities around layer-two, I think that's happened on top of the blockchain, really go to that area of preventing these kinds of frauds.
00:18:20.400 --> 00:18:34.910
If you think about ZK-roll up or optimistic rollup, really any kind of fraud, they all fall under the category of, what's it called, fraud proofs.
00:18:35.500 --> 00:18:47.809
If Mrinal is behaving this way, there are actors, whether it's me, whether it's somebody external to me, like a Watchtower, which shows proof that this is problematic.
00:18:48.150 --> 00:18:57.240
We chose like, oh, here's a more updated, more correct state, and I will get my deserved share and Mrinal will actually be punished on it.
00:18:57.839 --> 00:19:02.339
So they are doing these things that periodically interact with the blockchain.
00:19:02.599 --> 00:19:02.599
Okay.
00:19:02.601 --> 00:19:04.950
It could be just one at the beginning and one at the end.
00:19:05.190 --> 00:19:07.440
It could be that every day we settle.
00:19:07.441 --> 00:19:14.400
So the difference isn't too great and we can have a time-window, in which we can play with these kinds of things.
00:19:14.880 --> 00:19:21.369
So these happen, where we operate layer-zero, is just the network layer, right?
00:19:21.460 --> 00:19:30.690
The idea when, when in the blockchain where layer-one nodes send a block to one another, we're just a faster internet for blockchains.
00:19:30.720 --> 00:19:40.420
The idea is that you can send a block from one person or from one computer to another computer extremely fast, even if that block is very, very big.
00:19:40.509 --> 00:19:41.289
This is what we do.
00:19:41.680 --> 00:19:49.180
And the same way that your computer doesn't know that its data is being sent on a copper wire or optic fibers.
00:19:49.480 --> 00:19:50.200
The same goes here.
00:19:50.259 --> 00:19:52.500
It doesn't know what happens at the network layer.
00:19:52.519 --> 00:19:54.759
Just ask to be sent, right?
00:19:54.819 --> 00:19:57.039
It's being handled lower in the stack.
00:19:57.599 --> 00:20:12.160
And so if you look at the entire blockchain stack, you have layer-zero, which is just happening at the network layer and allow us blockchain participant and blockchain nodes to send messages and blocks and transactions.
00:20:12.490 --> 00:20:14.710
You have layer-one, the consensus.
00:20:15.279 --> 00:20:21.130
And layer-two extending this consensus, by just only periodically interacting with it.
00:20:22.000 --> 00:20:25.900
So Mrinal, would you like to counter any of the points that Uri raised?
00:20:27.140 --> 00:20:31.160
So let's start with Uri's comments on what I talked about.
00:20:32.730 --> 00:20:36.920
I agree with the programming languages and broad distribution as well.
00:20:37.339 --> 00:20:39.079
I'd say where we have a slight difference.
00:20:38.780 --> 00:20:40.430
It's kind of nuanced.
00:20:41.390 --> 00:20:45.440
I guess Uri is saying, scalability is primarily about throughput.
00:20:45.559 --> 00:20:48.309
And I add it's about throughput and security.
00:20:48.819 --> 00:20:51.400
And here's why I think the security is very, very important.
00:20:52.330 --> 00:20:54.910
you can get any amount of throughput you want.
00:20:55.119 --> 00:20:59.500
If you start making compromises to decentralization and compromises to secure.
00:21:00.079 --> 00:21:14.289
And the moment you say, Hey, I'm going to relax my threshold or how many people want to actually participate in consensus or you relax your threshold on how decentralized the system is and say, you know what, I'm just going to put two nodes in charge and let them do what they want.
00:21:14.650 --> 00:21:17.349
You can get throughput without almost fixing anything.
00:21:18.069 --> 00:21:24.849
And so the reason why I say they're both important is, you need to have security that scales with the network as well.
00:21:24.851 --> 00:21:28.029
Otherwise the throughput doesn't really make sense.
00:21:28.030 --> 00:21:29.529
But it's a nuanced point.
00:21:29.920 --> 00:21:30.700
And I get that.
00:21:30.730 --> 00:21:34.089
If there's a KPI measuring, it's probably TPS.
00:21:34.900 --> 00:21:40.390
And then you have the backdrop, of this is a TPS but this is compromise being made or not being made.
00:21:41.799 --> 00:21:45.670
So that's the only, small point of difference I have there.
00:21:45.671 --> 00:21:54.160
Although you said about layer-zero, layer-one and layer-two, I happen to actually agree pretty much a hundred percent with everything you said.
00:21:54.579 --> 00:21:57.759
I think that was a really good way of breaking it down.
00:22:17.589 --> 00:22:17.710
when I refer to layer-two solutions, the examples I really like to give are, we've seen this happen before, like PayPal, Stripe, square, a lot of these payments solutions tend to batch transactions before they propagate them to the visa or MasterCard networks.
00:22:17.589 --> 00:22:24.910
Now that's not a perfect analogy but that's kind of how a layer-two and layer-one works, layer-two kind of batches things.
00:22:25.690 --> 00:22:29.950
And I think now, the example he gave about state channels is really, really good.
00:22:30.609 --> 00:22:36.250
I also agree with the description of layer-zero and I agree with why it's super important.
00:22:36.250 --> 00:22:44.109
Where I have slightly more nuanced you is I think layer-zero is great for Ethereum 1.0.
00:22:45.640 --> 00:23:00.430
But I actually think what Bloxroute is doing will be even more powerful for what Ethereum 2.0 and 3.0 are doing, and what we're doing at CasperLabs, because in a proof-of-stake system, a lot of the consensus is just based on message passing.
00:23:00.910 --> 00:23:05.529
There's very little of this,"guess the hash" work going on.
00:23:05.980 --> 00:23:10.420
And so, a good layer-zero could be even more powerful.
00:23:10.480 --> 00:23:19.809
So whatever benefits, layer-zero gives a proof of work layer-one, I think it could give even more well-constructed proof-of-stake layer-one.
00:23:21.039 --> 00:23:26.440
But long winded way of saying I pretty much agree with most of what he said.
00:23:26.769 --> 00:23:28.900
I just wanted that some additional context in my views.
00:23:28.330 --> 00:23:43.809
Regarding security as a part of the broad definition of scalability-- So I totally agree that ultimately if you are sacrificing security in pursuit of scalability, then that is not a good thing to do.
00:23:44.140 --> 00:23:45.710
But the question is, does this layer-zero solution that hopes to scale Ethereum 1.0, come at the expense of security in any way?
00:23:45.441 --> 00:23:45.710
And I was hoping to get some perspective on this from both of you.
00:23:46.190 --> 00:24:15.609
So I think one important thing, going back to what Mrinal said, or even before that, Mrinal is right to say, listen, you can do like whatever you can do for ETH 1.0, it's even better for ETH 2.0 I agree with that.
00:24:16.880 --> 00:24:18.589
There is an argument to be made there.
00:24:19.039 --> 00:24:22.529
I, at my core, I am a networking guy.
00:24:22.589 --> 00:24:25.559
Even before being a crypto guy, I am a networking person.
00:24:26.730 --> 00:24:34.859
Is there some hole in the idea of proof-of-stake in terms of security, which had been patched the right way?
00:24:34.950 --> 00:24:36.809
And is that absolutely true?
00:24:37.410 --> 00:24:43.710
I think it's true, but that's not where my expertise lies really like deeper than anything else.
00:24:44.160 --> 00:24:47.619
But if we take it for granted, is that yeah, it might be true.
00:24:47.680 --> 00:24:58.630
It might be that the consensus that's being done with POS is maybe more secure and maybe faster than what we have in Ethereum 1.0.
00:24:59.289 --> 00:25:19.910
That being said, that is so far down the line that it seems stopping Ethereum 1.0 from scaling, and working on scaling Ethereum 1.0, and hoping for Ethereum 2.0 to save the day, instead of just scaling Ethereum 1.0, seems like I would even say a fool's errand.
00:25:19.970 --> 00:25:21.170
Why would we do that?
00:25:20.901 --> 00:25:22.220
Ethereum 1.
00:25:22.220 --> 00:25:30.619
0, and then pushing that even further regarding security, Ethereum 1.0 has so much going for it.
00:25:30.650 --> 00:25:34.789
So many people working on it, including the great people at Casper, right?
00:25:35.509 --> 00:25:40.180
CasperLabs, like the research coming from that is terrific.
00:25:40.210 --> 00:25:41.259
The ideas are great.
00:25:41.559 --> 00:25:50.740
Some of them could be applied immediately, some of them will be applied in the future, but that doesn't really have to do with scaling Ethereum 1.0.
00:25:50.829 --> 00:25:57.670
And because Ethereum 1.0 has so much going on for it, I go back to Marinal's point regarding the security.
00:25:58.569 --> 00:26:08.319
The security of Ethereum 1.0 is terrific, and greater than more than any other of the other blockchains because so much is already invested in it.
00:26:08.799 --> 00:26:27.390
And so even if it's not as optimized and as efficient as other blockchains and consensus mechanisms and systems, even at the current imperfect model, I would argue that its security is actually greater than others.
00:26:44.730 --> 00:26:44.730
Why?
00:26:44.730 --> 00:26:44.730
Just because a lot more people care about that versus some, take blockchain, CoinMarketCap#100.
00:26:44.730 --> 00:26:44.730
Okay.
00:26:44.730 --> 00:26:51.910
Even if it's really great, even if the tech is terrific, if not enough people are invested in it, it likely, but it's not going to get, if we're talking about the benefit of, security to scalability.
00:26:52.779 --> 00:27:06.859
So I, to boil it down, even if Ethereum 1.0 security has inefficiencies which can be fixed, it doesn't make it not secure.
00:27:06.890 --> 00:27:13.700
I would even argue that it's more secure just because of how much stake in terms of hardware and money is invested in it.
00:27:15.650 --> 00:27:18.200
I actually don't disagree with either of what you said.
00:27:18.230 --> 00:27:19.970
I just had a couple of nuances.
00:27:20.000 --> 00:27:31.400
So, let's go to the first point where you talked about, it's, it's a fool's errand not to scale if you're in 1.0 and just wait for 2.0.
00:27:31.640 --> 00:27:32.660
I actually have to agree with it.
00:27:33.140 --> 00:27:33.650
I agree.
00:27:33.651 --> 00:27:40.009
Because any, any innovations we do at the network layer to make that faster will carry on to 2.0 anyway.
00:27:40.279 --> 00:27:42.799
And so, it won't be wasted work.
00:27:43.069 --> 00:27:47.390
There might be some form of rejiggering this required, but it's all good work.
00:27:49.059 --> 00:27:54.289
My, my point is just 1.0 versus 2.0, 3.0, just won't scale as much.
00:27:55.579 --> 00:28:00.619
So, my view is that all the work being done at the network layer to make it faster is good.
00:28:00.621 --> 00:28:03.740
But the system does need to evolve.
00:28:04.460 --> 00:28:15.259
Let's talk about your point on security because you actually make a really strong argument and I don't disagree with it, but I think I need to clarify what I meant.
00:28:16.250 --> 00:28:29.869
And so why meant is, in a proof-of-work system to relative security relative to the size of the network, and in a proof-of-stake system, the amount of security relative to the size of the network is quite different.
00:28:30.109 --> 00:28:31.130
And it's better in proof-of-stake.
00:28:32.059 --> 00:28:33.650
And let me explain why.
00:28:34.430 --> 00:28:41.569
And you're absolutely right that Ethereum has much higher security than smaller chains, but maybe not as a percentage of the value of the network.
00:28:41.121 --> 00:28:41.569
I'll explain why.
00:28:42.559 --> 00:28:55.490
So the proof-of-work system, the asset that you're putting against, assets that are securitizing the blockchain is your[ inaudible] that's generating hash power.
00:28:56.029 --> 00:29:02.119
And to your point, billions of dollars have been spent on hardware to run the Ethereum network since its inception in 2014.
00:29:03.049 --> 00:29:12.980
However, the point at which it's efficient to put that hardware is related to the emission schedule this year.
00:29:13.519 --> 00:29:14.089
So let me give you...
00:29:14.090 --> 00:29:17.599
let's just put numbers out there and make this very clear to people.
00:29:18.259 --> 00:29:27.500
Assume if your network is worth$20 billion and assume it emits 5% of its total value every year.
00:29:27.920 --> 00:29:30.680
So that's a new 1 billion dollars coming into the network.
00:29:31.609 --> 00:29:41.349
So the optimum amount of hardware that you will use to secure that work, or new hardware purchases is just sub-$1 billion.
00:29:41.351 --> 00:29:46.720
$1 billion is the revenue, you choose what your cost wants to be, and that's the profit that the miners get.
00:29:52.150 --> 00:29:55.569
Hence the cost of attack to attack to the network, if you want to do a 51% attack, is also that amount.
00:29:56.049 --> 00:30:03.789
So call it$800 million, if you're assuming, you know of, if you're assuming that 20% profit margin.
00:30:03.789 --> 00:30:08.170
Now think about a proof-of-stake network where half the money is already staked.
00:30:09.609 --> 00:30:15.250
Now you have a$20 billion network, there's$10 billion of security against that network.
00:30:15.789 --> 00:30:25.569
Meaning in order to attack the network, the amount of stake you need to buy is equivalent to almost$10 billion to have enough of the say within the network.
00:30:26.410 --> 00:30:37.210
And that's really what I meant, like, in proof-of-stake versus proof-of-work, for a network of the same size, and proof-of-stake, you actually have more economic security.
00:30:37.269 --> 00:30:39.069
Now I'm vastly oversimplifying here.
00:30:39.460 --> 00:30:40.750
But your point is true, right?
00:30:42.190 --> 00:30:47.470
Will Ethereum with proof-of-stake have more security than someone who's number 100 on CoinMarketCap?
00:30:48.039 --> 00:30:48.339
Yes.
00:30:48.400 --> 00:30:57.099
'cause the cost to attack that network is lower on an absolute basis, while it's still may be higher on a percentage basis.
00:30:57.549 --> 00:31:07.869
I do think overall though, as the blockchain industry moves towards more mainstream adoption, anything we can do to keep increasing the cost of attack is just a good thing.
00:31:08.440 --> 00:31:10.390
But I don't disagree with the points.
00:31:10.400 --> 00:31:16.299
I was just trying to like clarify, that I meant it much more on a percentage basis than an absolute basis.
00:31:16.630 --> 00:31:20.079
And I hope the example kind of clarified the point I was trying to make.
00:31:21.680 --> 00:31:23.930
So Marinal., you brought up a really great point.
00:31:23.931 --> 00:31:31.579
And it's actually one of the more concise and coherent explanations regarding the value of POS versus POW that I've heard.
00:31:31.819 --> 00:31:41.880
With that being said, if we brought in a Bitcoin maximalist to the show right now to argue ferociously against it, what would he tell you?
00:31:41.881 --> 00:31:44.579
Tell me the counter-arguments to what you said.
00:31:44.580 --> 00:31:59.039
Why would he argue that's the current POW, as you see in Bitcoin, and again we're talking Ethereum, but if I brought in a really diehard pow person to the show and he were to respond to you, what do you think he would tell you?
00:31:59.069 --> 00:32:02.099
Why would he disagree with you and what would be his strongest argument?
00:32:02.819 --> 00:32:07.710
Yeah, so his strongest argument would be, a lot of this would be future-based.
00:32:07.980 --> 00:32:20.640
So one argument they make is hardware is kind of table stakes, versus with the token, depending on how the team decides to distribute a POS token, they could have concentrated value.
00:32:21.450 --> 00:32:23.400
What I mean is, a token is a token, right?
00:32:23.579 --> 00:32:27.779
And you know right up front and the team has decided we're going to keep 30% of the tokens.
00:32:28.019 --> 00:32:29.460
They have centralized 30% of the power.
00:32:28.800 --> 00:32:33.420
And I think that's why teams have to be careful not to do things like that.
00:32:33.960 --> 00:32:38.970
And so what they say is hardware, anyone can acquire, and as a result you've made it table-stakes.
00:32:39.380 --> 00:32:49.339
However, if you don't replicate that model in proof-of-stake, and make sure that the token can be broadly access, and no one's holding like large percentages of it, you basically just replicated, like a cartel.
00:32:50.269 --> 00:32:52.160
So that would be argument one, they'd make.
00:32:54.019 --> 00:33:06.019
Argument two, they've made is that, a lot of Bitcoin maximalists love the fact that there's a decaying supply curve on Bitcoin that, basically the inflation schedule, reduces over time.
00:33:06.950 --> 00:33:09.740
Now I would argue that this is...
00:33:09.769 --> 00:33:13.640
unless they solve this problem, it's a ticking time bomb.
00:33:14.000 --> 00:33:15.529
It's not a problem right now.
00:33:15.950 --> 00:33:22.009
But to my point, you only put as much hardware, as much profit you can make off the chain.
00:33:22.849 --> 00:33:34.039
when you're getting 6.25 Bitcoin per block, that might be okay to sustain a lot of hardware, but at some point the cost to attack versus the cost of hardware will flip the other way.
00:33:34.190 --> 00:33:40.130
I don't know if that's at 3.125 BTC per block or 1.625.
00:33:42.019 --> 00:33:44.900
I don't know at what point that happens, but you could model it out.
00:33:45.710 --> 00:33:48.200
But they love the decay curve.
00:33:48.950 --> 00:33:55.460
And I would agree with them, for the pure store of value, it probably makes sense.
00:33:56.299 --> 00:34:08.119
And then finally the other thing they say is like, another issue with a smart contracting platform is that, it's actually not that necessary.
00:34:08.300 --> 00:34:10.820
You can build all of that on the application layer.
00:34:11.090 --> 00:34:16.869
You should just have a very simple protocol, because a simple protocol is much harder to break.
00:34:16.869 --> 00:34:19.610
That's why Bitcoin, unlike Ethereum, had their miner DAO hack.
00:34:24.289 --> 00:34:25.099
Bitcoin has been more resilient.
00:34:25.670 --> 00:34:27.590
These are the strongest arguments I hear.
00:34:28.911 --> 00:34:31.340
I don't agree or disagree with them.
00:34:31.340 --> 00:34:35.090
I think it's a completely different use case versus a smart contracting platform.
00:34:35.480 --> 00:34:41.239
And I do think the decaying curve is something that Bitcoin as a community is going to have to solve.
00:34:41.931 --> 00:34:53.210
the current, well the current view is that transaction fees might be increased in lieu of like having the decaying inflation curve and therefore a miner still get rewarded.
00:34:53.630 --> 00:34:56.659
And we could still run a lot of hardware profitably.
00:34:57.349 --> 00:34:59.539
But those are, those are the biggest arguments I hear.
00:34:59.630 --> 00:35:11.269
And I agree with the first one the most, which is they say, there's no point in proof-of-stake if the, that state is ultra centralized across a few people kind of defeats the purpose
00:35:12.829 --> 00:35:17.150
First, I appreciate you bringing the counter arguments and that's always hard to do.
00:35:17.510 --> 00:35:29.050
Pushing that even further, I would argue that, and this first argument that it's not only the teams that can get a substantial portion of the tokens in the staking.
00:35:28.990 --> 00:35:37.130
In the current crypto landscape, exchanges, especially centralized exchanges, play a significant role.
00:35:37.380 --> 00:35:45.900
And if you look just take like the top three or top five, they control so much staking that that becomes, I feel that that becomes dangerous.
00:35:45.900 --> 00:35:48.239
And so yeah, that's a small point.
00:35:48.730 --> 00:35:55.269
I would now, like to, turning it back to"Can Ethereum 1.0, can it scale now or not"?
00:35:56.019 --> 00:35:58.719
And I want to go to the question that one of you brought up.
00:35:59.010 --> 00:36:10.619
Yes you can increase scalability if you hurt decentralization, but if you have just two nodes and they're working with one another, yeah, you can make it scale much further if you sacrifice that.
00:36:10.739 --> 00:36:17.639
And the question is,"can Ethereum 1.0 scale," without sacrificing de-centralization.
00:36:17.730 --> 00:36:28.380
And I would argue that it can, mostly because the idea is that, any improvements on layer-zero must be so that they're probably neutral.
00:36:28.630 --> 00:36:42.260
Nothing that a layer-zero system could do, can affect the blockchain, can reduce its scalability, can censor or discriminate between block transactions, miner, validator, or anything like that.
00:36:42.710 --> 00:36:45.949
And further than that, it must not be a single point of failure.
00:36:46.400 --> 00:37:03.369
So I'm not saying that, oh well if we just had faster internet somehow, some company put really great optic fibers in the ground, but now everybody relies on them, that's not the argument that I'm making that the Ethereum 1.0 can scale.
00:37:03.760 --> 00:37:29.440
My argument is that, without affecting de-centralization, okay, without requiring better hardware, more storage, more bandwidth, without affecting any of those, Ethereum 1.0 can scale right now, because there is a way that, we work very hard to make it happen, for nodes to send one another blocks extremely fast.
00:37:29.989 --> 00:37:40.320
The basic idea is we have a system that allows all the nodes to remain in sync regarding transactions that waits to be added to the block.
00:37:40.710 --> 00:37:47.579
And so when somebody creates a new block and he needs to send it to everybody else, he doesn't actually have to send the entire block.
00:37:47.960 --> 00:37:50.960
It only needs to say which transaction are in there.
00:37:51.050 --> 00:37:54.769
And so, on the wire, actually much smaller pieces of data are being sent.
00:37:55.670 --> 00:38:04.260
And this only works if, even if, Bloxroute goes down, and even if we were being shut down, if everything must continue to operate, there's an idea of backup network.
00:38:04.769 --> 00:38:19.550
So going back to what Richard said at the beginning, yes, there's definitely a push-back and a balance between decentralization and scalability, but it doesn't affect this argument that we're currently having regarding Ethereum.
00:38:19.550 --> 00:38:20.449
1.0.
00:38:20.719 --> 00:38:30.289
If Ethereum 1.0 can scale at least to the hundreds of transactions per second, and I'm saying at least, because we already see that, like we were able to make that happen.
00:38:30.829 --> 00:38:46.780
And whether there is something beyond that point, that requires tweaking for sure, plenty of things, like the code isn't written generally well enough to handle the high volumes, but to not in a way that affects decentralization.
00:38:46.840 --> 00:38:55.030
Nothing that's being done there is going to be, Oh, we're increasing scalability because now less players are capable of participating.
00:38:56.190 --> 00:38:56.400
Yeah.
00:38:56.400 --> 00:39:00.269
So, Uri, just to clarify, I actually don't disagree with what you just said.
00:39:00.271 --> 00:39:07.860
The reason I brought up security and decentralization was just to say why I think that's also part of scalability.
00:39:08.010 --> 00:39:18.809
I mean, just looking at throughput without looking at security and decentralization might be a little shortsighted, because you can get throughput by sacrificing[inaudible], I agree with you.
00:39:18.811 --> 00:39:25.679
Fixing stuff at layer-zero shouldn't in effect, if done properly, affect decentralization or security in any way.
00:39:26.130 --> 00:39:29.539
If we're just getting blocked, propagated faster, with no censorship.
00:39:30.170 --> 00:39:31.090
Yeah, I don't disagree.
00:39:31.539 --> 00:39:35.860
The point I was trying to make was, why I think security and throughput go hand in hand.
00:39:35.860 --> 00:39:49.929
Because I think, and again this is broader than just ETH, right, I think when people view blockchain infrastructure in general, I think sometimes if you just look at a TPS number and say, okay, that blockchain is better because it's got a higher, I'm like, well, you've got to figure out why.
00:39:50.730 --> 00:39:54.690
Sometimes it's just like, okay, I like these five guys.
00:39:54.719 --> 00:39:56.760
These guys are going to decide everything.
00:39:57.710 --> 00:40:05.300
So Mrinal, can you elaborate on the various bottlenecks in Ethereum 1.0's design that prevents scalability?
00:40:05.510 --> 00:40:10.130
I know that you have sort of touched upon this a little bit, but maybe any additional color would be helpful.
00:40:10.519 --> 00:40:15.590
Also in which ways will the migration to 2.0 resolve such weaknesses?
00:40:15.920 --> 00:40:28.070
And here's also an opportunity for you to talk about how CasperLabs looks to differentiate yourself in comparison to ETH 1.0 and/or ETH 2.0.
00:40:28.889 --> 00:40:31.469
Let's at a high level split this into a few pieces.
00:40:31.500 --> 00:40:35.340
Which are, there's thematic bottlenecks here and I'll talk about each one.
00:40:36.179 --> 00:40:39.269
So theme one is really the shift from proof-of-work to proof-of-stake.
00:40:40.230 --> 00:40:51.179
And we already talked about why I think proof-of-stake is a better system both in terms of efficiency as well as security overall, if managed right.
00:40:52.349 --> 00:40:53.070
Nothing's free.
00:40:53.070 --> 00:40:54.809
There's give and takes on both sides.
00:40:55.530 --> 00:41:05.159
So I think that bottleneck that gets solved by ETH 2.0, more so ETH 3.0, so the way they've described Casper FFG right now...
00:41:05.161 --> 00:41:22.469
Plans go back and forth a little bit as, as it does in software engineering, they're going to have an interim step called Casper FFG, which really has, proof-of-work, Nakomoto style consensus for the most part and overlays proof-of-stake as a finality system.
00:41:23.099 --> 00:41:29.519
So, a lot of the network will look almost exactly the same because it's a proof-of-work, proof-of-stake hybrid.
00:41:29.521 --> 00:41:39.500
But then they eventually go to Ethereum 3.0, which is a 100% proof-of-stake system, running a CBC Casper or CBC Casper variant.
00:41:39.500 --> 00:41:54.739
So, we, and one of the reasons why we started the company was let's just build that end state proof-of-stake system, that is fully decentralized and secure, which I think is actually a unique characteristic ours has.
00:41:55.280 --> 00:41:58.280
We don't have any, two node structure.
00:41:58.280 --> 00:41:59.539
There's only one type of node.
00:41:59.300 --> 00:42:01.969
It is fully permissionless; it's fully decentralized.
00:42:01.971 --> 00:42:04.250
So we don't sacrifice any of that.
00:42:04.251 --> 00:42:08.030
But it's very in line with where Ethereum wants to get to eventually.
00:42:08.780 --> 00:42:11.630
We just thought, hey, why don't, why don't we just do it right now.
00:42:13.190 --> 00:42:27.380
The second, I'd say scalability bottleneck is that, if you think about proof-of-work systems in general and the way Ethereum of VM works in particular, it's a highly serialized system.
00:42:27.980 --> 00:42:36.769
Meaning the ordering of transactions is extremely important and you can't really run things concurrently even if they don't depend on each other.
00:42:37.280 --> 00:42:46.309
For example, me transferring money to you, Richard, and then Uri transferring money to Shen, these two transactions don't talk to each other.
00:42:46.489 --> 00:42:49.849
Really they're additive and therefore commutative.
00:42:49.851 --> 00:42:52.969
And therefore can be run at the same time.
00:42:53.059 --> 00:42:58.010
And that's really an issue when you have like a serialized blockchain.
00:42:58.010 --> 00:43:08.659
What a full version of CBC Casper does, which is, where they're going with 3.0, is you actually build a directed acyclic graph, and I won't get into too much detail.
00:43:08.780 --> 00:43:14.960
But in essence you can add a level of parallelism and concurrency that you otherwise could not.
00:43:16.880 --> 00:43:20.630
A great way to think about that as your laptop or your mobile phone right now.
00:43:21.110 --> 00:43:27.590
You know the system that plays the sound system that puts up the video or the one that knows your calculator.
00:43:27.599 --> 00:43:30.289
These are all independent systems and they can run at the same time.
00:43:31.070 --> 00:43:36.980
There's some interdependencies which are explicitly declared, but when, when they aren't, they can run on their own.
00:43:37.639 --> 00:43:41.360
And so similarly, you want an infrastructure layer to behave like that.
00:43:41.900 --> 00:43:48.860
And so the shift from, serialized blockchain to something that supports parallelism and concurrency is another bottleneck.
00:43:49.400 --> 00:43:53.960
And we're solving it by basically implementing a DAG based protocol, right out the gate.
00:43:54.050 --> 00:43:57.409
That's literally what we're doing at CasperLabs.
00:43:59.599 --> 00:44:06.139
And then finally, the other bottleneck is the one we've been talking about in terms of developers.
00:44:07.820 --> 00:44:11.750
I'll use this to[inaudible] my answer to Ethereum.
00:44:12.320 --> 00:44:22.639
So, having a proprietary programming language like Solidity, or any programming really, it takes a lot of time for it to build.
00:44:22.730 --> 00:44:27.440
And Ethereum was by and large, the 800 pound gorilla in the room.
00:44:27.440 --> 00:44:29.510
A massive market leader.
00:44:30.590 --> 00:44:34.530
It's 10 to 15,000 developers out of 26 million.
00:44:34.650 --> 00:44:38.670
So, it's a very, very under-penetrated industry.
00:44:39.510 --> 00:44:49.829
And so, we solve that because we have a lot of assembly based build; we'll support rust and assemblyScript right out of the gate and a bunch of others as well.
00:44:52.559 --> 00:44:52.559
Second[inaudible] to Uri's answer.
00:44:52.891 --> 00:44:55.739
First off, I'll start with, I'm a massive fan of Ethereum.
00:44:57.300 --> 00:44:58.889
I've been in the industry since 2012.
00:44:58.891 --> 00:45:03.630
I bought Ethereum tokens as early as you could possibly buy them.
00:45:03.840 --> 00:45:07.050
And I've been a supporter of the project for a long time.
00:45:07.050 --> 00:45:18.150
That being said, and I agree with you, a product to take over the network effects of a market leader, needs to be a hundred times better, or 10 times better.
00:45:18.331 --> 00:45:30.659
The two caveats I'd make to that though are one, I think we're very early stage in this industry, and it's not really, in its full competitive state.
00:45:31.110 --> 00:45:37.380
I mean, if you remember search engines, the same argument was made for AltaVista, the same argument that was made for Yahoo.
00:45:37.710 --> 00:45:38.550
And then you had Google.
00:45:38.639 --> 00:45:43.010
At every stage people are gonna say, AltaVista will never be beaten by Yahoo, never be beaten by Google.
00:45:44.099 --> 00:45:49.429
Google, I agree with, because that's the time when the industry actually got fully penetrated.
00:45:49.429 --> 00:45:52.340
[inaudible] everyone in the industry is fully penetrated.
00:45:52.699 --> 00:46:03.050
So, Google had full penetration, basically 60% of people worldwide in search when they took market leadership, and they had an 85% share.
00:46:02.780 --> 00:46:10.969
In an underpenetrated industry where 0.6% of developers are using it, there's just so much more white space.
00:46:11.000 --> 00:46:25.099
I agree within blockchain, meaning all the people who are in blockchain already, it's probably impossible to compete with Ethereum, or many of the established blockchains.
00:46:25.820 --> 00:46:27.320
But you have to look for the white space.
00:46:27.679 --> 00:46:29.840
It's a hugely under-penetrated industry.
00:46:30.139 --> 00:46:32.059
Similar thing happened with operating systems, right?
00:46:32.061 --> 00:46:41.239
Like IBM had 95% market share and Microsoft didn't go after corporate end user first along with Apple.
00:46:41.659 --> 00:46:44.210
And the whole landscape has changed completely.
00:46:44.900 --> 00:46:50.000
So because the industry is underpenetrated, I think there's still an opportunity.
00:46:50.300 --> 00:46:53.989
That being said, I'm also a massive open source enthusiast.
00:46:55.099 --> 00:47:00.619
You know what we're doing at CasperLabs, we want to build what we hope to be one of the best blockchains out there.
00:47:01.039 --> 00:47:06.739
We're very, very focused on decentralization security, but we're also open source purists.
00:47:07.099 --> 00:47:18.650
And if at the end of the day it leads to innovation in the industry, and part of what we built is used by other projects that helps push the industry forward, we'll still take that as a win.
00:47:19.460 --> 00:47:25.460
obviously we're competitive and would love to see, us turn a lot of developers towards the industry.
00:47:26.090 --> 00:47:28.969
But it's an open source world.
00:47:29.809 --> 00:47:35.329
Glad to help bring some thought leadership and hopefully it's helpful.
00:47:36.400 --> 00:47:37.750
Well thanks for that answer.
00:47:37.840 --> 00:47:40.420
So I have another set of questions for Uri.
00:47:40.659 --> 00:47:51.940
My understanding is that in terms of UX, in using Bloxroute for your layer-one solution, all that's needed to make use of it is for Ethereum nodes to download and run your software.
00:47:52.210 --> 00:47:57.309
Is that understanding accurate and what are the challenges for convincing the nodes to use that software?
00:47:57.369 --> 00:47:58.119
That's the first question.
00:47:58.480 --> 00:48:20.230
The second question is, so if we go back to the actual use case of Ethereum, let's say CryptoKitty at a time when there are many transactions happening, as people transact with CryptoKitty, as they breed kittens, the block was quickly full and then other legitimate transactions on Ethereum couldn't get through in time.
00:48:20.650 --> 00:48:28.750
So if we were to replay that scenario, but with some kind of layer-zero solution being in place, what would that scenario look like?
00:48:29.739 --> 00:48:46.210
So first to your UX question, that idea that like, oh, for this to work you need nodes to utilize to run Bloxroute software and connect to their, have their nodes work with it, etc, is that what's needed?
00:48:47.980 --> 00:48:48.820
Not really.
00:48:49.239 --> 00:48:51.219
In terms of what do you need for Bloxroute to happen?
00:48:51.250 --> 00:48:51.699
Nothing.
00:48:52.059 --> 00:48:52.239
Okay.
00:48:52.240 --> 00:48:53.590
Bloxroute is deployed.
00:48:53.590 --> 00:48:56.230
There is a system that allows the blocks to propagate faster.
00:48:56.829 --> 00:48:59.349
Nobody needs to connect to it.
00:48:59.769 --> 00:49:09.039
However, miner s connecting to Bloxroute hear blocks faster than others, because, and the more who joined, the better.
00:49:09.099 --> 00:49:17.409
So even if you're the first miner to join, then because Bloxroute is already connected to nodes all around the globe, you're going to hear blocks faster.
00:49:17.769 --> 00:49:23.170
That means you can start mining, working on the next block sooner, and you're going to make more money.
00:49:23.559 --> 00:49:26.530
And therefore nobody needs to connect to it.
00:49:26.559 --> 00:49:28.179
But miners make money.
00:49:28.181 --> 00:49:33.250
It starts as a competitive advantage and really quickly it goes into a competitive necessity.
00:49:33.610 --> 00:49:48.489
If everybody else is connected to the fast network and you're connected with just to your peers, it's like you're running your operation with, I don't know, 512 kilobytes like analog modem from like 97 or something.
00:49:48.789 --> 00:49:53.019
You can do that, but you're going to be slower than everybody else and you're going to make less money.
00:49:53.409 --> 00:49:59.739
And so the first people we started working with were miners and pools telling them, oh, here's the technology.
00:49:59.920 --> 00:50:01.900
Don't change anything in what you do.
00:50:02.349 --> 00:50:08.619
We built blocks starting in such a way, that nodes don't even know that they're connected to Bloxroute.
00:50:09.400 --> 00:50:16.210
We give you, if you run a node or a miner or a pool, we give you an open source gateway.
00:50:16.659 --> 00:50:21.219
You run it on your machine, you tell your node: Connect to this gateway.
00:50:21.369 --> 00:50:22.630
So he thinks it's a peer.
00:50:22.869 --> 00:50:24.760
Just a friendly neighbor peer.
00:50:24.789 --> 00:50:26.440
It's a peer but sits on the same machine.
00:50:27.090 --> 00:50:35.159
It doesn't trust it in any way, but that peer is going to tell him about blocks from the outside faster than his other peers.
00:50:35.161 --> 00:50:39.059
And when he's being told the block, he would tell the others.
00:50:39.659 --> 00:50:44.550
However, Richard, if you are using Ethereum, you don't care.
00:50:44.670 --> 00:50:46.710
Like you don't need to connect to Bloxroute.
00:50:46.980 --> 00:50:48.900
You don't need to know that Bloxroute exists.
00:50:49.230 --> 00:50:59.409
Again, the same way that you don't know whether the wires connecting under the, you know, Japan with mainland Asia, is that optic fibers or copper?
00:50:59.500 --> 00:51:00.219
You don't know.
00:51:00.309 --> 00:51:01.449
You really don't care.
00:51:01.929 --> 00:51:07.860
So by making miner s and nodes connecting faster, that allows for scalability.
00:51:08.030 --> 00:51:08.780
Nobody.
00:51:09.079 --> 00:51:18.230
If you are a user, if you're running a node, if you're mining, you should connect to us, not should in terms of, that would be more profitable to you.
00:51:18.320 --> 00:51:19.429
You really don't have to.
00:51:19.460 --> 00:51:20.360
It gives an edge.
00:51:20.809 --> 00:51:29.300
If you are a user, if you are running a node, if you're Infura, if you're Ethereum, something like this, you don't have to, you don't need to.
00:51:29.869 --> 00:51:34.550
It does offer some services and advantages that you can choose to connect.
00:51:34.579 --> 00:51:43.190
The same way if you can choose to connect to Infura, you can choose to connect to ETH gas station, you can choose to connect to Bloxroute.
00:51:43.730 --> 00:51:50.000
Because Bloxroute will tell you about transactions as they happen really, really fast, which is important for DeFi traders.
00:51:50.269 --> 00:52:00.349
Or it has a really, if you make a transaction, you gave some gas, usually you have to just wait and see, well, let's see if it goes, when it goes, and we'll give you a feedback.
00:52:00.351 --> 00:52:02.099
These are kind of that.
00:52:02.239 --> 00:52:04.820
Then reducing fees, like we have some services that we offer.
00:52:05.119 --> 00:52:11.329
But going back to your original question, for you, for this, for Ethereum 1.0 to scale, what do you need?
00:52:11.900 --> 00:52:13.400
I don't, I need very little.
00:52:13.579 --> 00:52:16.820
I give it away practically for free.
00:52:16.820 --> 00:52:18.980
I don't, I give it to miner s and pools.
00:52:19.340 --> 00:52:23.420
I allow them to hear a block faster, and then it's in their hands.
00:52:23.690 --> 00:52:25.039
The way Ethereum works.
00:52:25.440 --> 00:52:30.090
So to Mrinal's earlier point though, does this introduce a point of centralization?
00:52:30.360 --> 00:52:39.780
So for example, let's say you have a finite number of Bloxroute servers installed, and then all these miners are incentivized to connect with them in order to hear blocks faster.
00:52:40.559 --> 00:52:50.820
Then does that mean your entity is now sort of in control because you have this very superior offering, but it's sort of concentrated in one entity's holding?
00:52:51.210 --> 00:52:52.250
That is a great point.
00:52:52.280 --> 00:52:56.150
If that was the whole story, the answer would be yes and nobody should use us.
00:52:56.690 --> 00:52:57.769
Nobody should use us.
00:52:57.771 --> 00:52:58.639
If that was the case.
00:52:59.239 --> 00:53:03.769
However, we made sure that we can't discriminate or censor, right?
00:53:03.800 --> 00:53:08.480
We can only, as I explained earlier, that we keep everybody in sync regarding transaction,
00:53:08.940 --> 00:53:10.889
How do you prove that, that you're not censoring?
00:53:11.239 --> 00:53:15.320
There are tons of technical details, but at the high level, here's how it works.
00:53:15.800 --> 00:53:20.929
Every few hundred milliseconds we send to everybody, oh, here are new transactions.
00:53:20.960 --> 00:53:28.170
Okay, so these are sent to everybody, all the gateways and through that to all the nodes who are connected: Here on new transactions, here are new transactions.
00:53:28.380 --> 00:53:35.550
So these nodes, everybody who is listening to Bloxroute knows that the others know exactly the same transactions.
00:53:35.909 --> 00:53:37.980
These[inaudible] that we send, we sign,...
00:53:37.769 --> 00:53:41.190
so we timestamp them and we sign them.
00:53:41.670 --> 00:53:48.570
Every time a gateway receives such an update from Bloxroute, he tells these gates..., his peers, the other gateways.
00:53:48.659 --> 00:53:50.789
So gateway has created a peer to peer network of their own.
00:53:51.119 --> 00:53:54.480
They say, oh here's the update that I've got.
00:53:54.809 --> 00:53:55.380
Here's the hash,...
00:53:56.369 --> 00:53:57.269
that's a hash of it.
00:53:57.659 --> 00:53:58.679
Did you get the same?
00:53:59.190 --> 00:54:08.730
So everybody verifies, that everybody got to the same and we can't give, I can give one transaction, one ID and then not tell it to somebody else.
00:54:08.731 --> 00:54:12.090
Like I can't give inconsistent updates.
00:54:11.460 --> 00:54:15.360
Or, if I do that, it's immediately visible.
00:54:15.690 --> 00:54:20.429
And what happened in that scenario is the same thing that happens if Bloxroute goes down.
00:54:20.610 --> 00:54:25.139
Okay, so, but using this mechanism, it is visible that we're misbehaving.
00:54:25.590 --> 00:54:29.610
The solution to the misbehavior is assuming Bloxroute went down.
00:54:30.059 --> 00:54:31.920
What happened when Bloxroute goes down?
00:54:32.519 --> 00:54:35.489
Well, we introduce the concept of backup networks.
00:54:36.030 --> 00:54:42.239
Anybody can take our code and deploy a backup network, an idle version of Bloxroute.
00:54:42.630 --> 00:54:42.840
Okay.
00:54:42.840 --> 00:54:48.809
It's a network that can do the same thing, connect to everybody, but in reality it doesn't do anything.
00:54:48.989 --> 00:54:56.280
So extending their idle, waiting for the doomsday scenario that Bloxroute either goes down or misbehave.
00:54:57.000 --> 00:54:58.769
If that were to ever happen.
00:54:58.291 --> 00:55:00.840
Okay, we're being shut down by the government.
00:55:01.019 --> 00:55:03.090
We went to Vegas and we lost all our money.
00:55:03.119 --> 00:55:03.420
Okay?
00:55:03.420 --> 00:55:11.309
We're being forced, I love to call the Steven Seagal scenario, somebody kidnaps my family and forces me to reject transactions or blocks...
00:55:12.119 --> 00:55:13.559
I am coerced to do so.
00:55:13.231 --> 00:55:18.119
If that happens, everybody sees that that happened.
00:55:18.300 --> 00:55:23.010
Whether because we send in consistent updates or we just went down.
00:55:23.369 --> 00:55:27.599
And then move to use backup network number one and everybody knows who's backup network number one.
00:55:28.860 --> 00:55:51.320
If that misbehaves too, everybody goes to backup network number two, number three, etc, and the incentive to use a backup network is that if you are a miner, if you are a pool, if you're a big business like Coinbase, okay, if your operation, if you have significant stake in the blockchain continuing to operate, this is a cheap insurance policy, okay?
00:55:51.500 --> 00:55:55.880
You run a backup network, it doesn't do anything, so it doesn't need to incur a lot of costs.
00:55:55.940 --> 00:56:01.760
It costs you a hundred dollars a year or$300 per year, depending on the size, etc.
00:56:02.239 --> 00:56:03.170
It doesn't do anything.
00:56:03.230 --> 00:56:10.489
But in the worst case scenario, if you're a miner, you know that you're, even if Bloxroute goes down, your blocks would propagate fast.
00:56:10.490 --> 00:56:11.840
You'll hear about blocks from the others.
00:56:12.110 --> 00:56:19.039
And everybody can continue to use the backup network for six months or for a year or for two years, like at any period of time.
00:56:19.369 --> 00:56:25.940
It's not as cost efficient as a Bloxroute, but it's than going back to 10 transactions per second.
00:56:26.449 --> 00:56:33.590
And so the idea is that there are people who has stake to run these and they are the safeguard against Bloxroute.
00:56:34.250 --> 00:56:47.750
So to wrap it up to your question, if we were capable of sending inconsistent updates, or if we were capable of being, like if we go down, everything goes back to how we were, nobody should use us.
00:56:47.751 --> 00:56:51.590
But we built it in such a way that that is not the case.
00:56:51.769 --> 00:57:00.800
Again, I'm not, I'm not trying to argue why Bloxroute is awesome, because I don't want the question to be about blocks road, but they think that gives the high level idea there.
00:57:00.829 --> 00:57:01.550
Does that make sense?
00:57:02.260 --> 00:57:02.679
Yes.
00:57:02.800 --> 00:57:07.510
And Mrinal, so we're discussing whether ETH 1.0 can scale.
00:57:07.510 --> 00:57:14.590
And a big part of that is all these solutions that could help make things happen such as a layer-two solution or a layer-zero solution.
00:57:14.940 --> 00:57:26.969
In particular, today we're fortunate to have someone from the layer-zero world, basically describing a method of increasing block propagation without giving into the trade-off of decentralization, it seems.
00:57:27.030 --> 00:57:30.119
So it almost looks like having your cake and eating it too.
00:57:30.809 --> 00:57:41.190
If we were to establish that fact, do you still see issues with Ethereum 1.0 not being able to scale beyond what you mentioned about the adoption problem?
00:57:41.869 --> 00:57:51.820
I do think layer-zero and layer-two solutions will make it faster than it is right now, but nowhere near as fast as where it can be.
00:57:52.030 --> 00:58:02.260
It goes back to my point where I just think efficient management of resources is extremely important and that's why the shift from proof-of-work to proof-of-stake is really, really important.
00:58:02.260 --> 00:58:13.059
Both in terms of, if you're getting a few hundred transactions per second, with a great layer-zero on proof-of-work, you're going to get thousands if you move to proof-of-stake.
00:58:13.061 --> 00:58:16.389
Just because of the redirecting of the processing power.
00:58:16.601 --> 00:58:27.639
If you're getting good security hardware because of, 3-5% emission rate that I covered, you're going to get even more security with 50% of token staked on the network.
00:58:28.900 --> 00:58:51.280
So regardless of improvements made, it won't compare to the level of improvement you can see when ETH 2.0 or 3.0 transition happens, or you've run a similar system on a CasperLabs or some other network, assuming they become big as well.
00:58:51.280 --> 00:58:52.570
So that's one.
00:58:52.570 --> 00:59:13.630
And the second thing is just to, dig into the serialized nature of 1.0 again, shift the proof-of-stake in, especially, like a CBC Casper style, consensus mechanism, will enable a level of concurrency and parallelism, that doesn't exist.
00:59:13.989 --> 00:59:23.070
The issue with proof-of-work systems is since they're highly serial, you can't take advantage of, very broad footprint of computational power.
00:59:23.610 --> 00:59:35.219
When you shift the proof of stake, especially one that is directed acyclic graph based, you actually get so much more efficiency, because you can have a lot of concurrency and parallelization.
00:59:36.059 --> 00:59:40.380
So I do agree, it can get faster, and it can scale a little bit more.
00:59:40.920 --> 00:59:49.619
My point is for it to truly scale and truly be efficient, that transition from proof-of-work to proof-of-stake needs to happen.
00:59:50.309 --> 00:59:53.519
That's why there's so much work in research going into it.
00:59:54.360 --> 00:59:58.829
I don't disagree with the point that a layer-zero doesn't necessitate a problem with decentralization or security.
00:59:58.831 --> 00:59:59.250
That I think we're fine.
00:59:58.831 --> 01:00:06.360
I'm just saying, all of that will look even better as those transitions happen.
01:00:07.260 --> 01:00:18.929
I would argue that, regarding the question that we're discussing right now, can ETH 1.0 scale, I think it can scale, it can scale a lot, but Mrinal is right to say, hold on, we can do better.
01:00:19.349 --> 01:00:23.250
Like we can build a blockchain, it can work in great parallelism.
01:00:23.550 --> 01:00:32.280
And so for everything that you can achieve with ETH 1.0, we in CasperLabs believe we can do 10x a 100x, I'm not sure what their number is.
01:00:32.280 --> 01:00:34.920
But, that is a good and strong argument...
01:00:35.489 --> 01:00:40.559
Or even ETH 2.0, or 3.0, I think we'll be much faster, right?
01:00:41.630 --> 01:00:50.250
At the current state of the ecosystem, when Ethereum 1.0 is the market leader, we are working with the miners and the pools.
01:00:50.670 --> 01:01:06.449
So if the audience isn't familiar, unlike Bitcoin where you have to change the protocol to increase the block size and scale the blockchain, Ethereum miners and pools can vote every time, do they want to increase it by a bit or decrease it by a bit.
01:01:06.869 --> 01:01:13.619
And so if majority of miner s vote to increase the capacity of Ethereum blockchain, it increases the capacity.
01:01:13.710 --> 01:01:17.880
It actually happened in around September 1st, 2019.
01:01:17.880 --> 01:01:20.400
It was increased by 25% which is a lot.
01:01:21.239 --> 01:01:22.409
That was after...
01:01:22.411 --> 01:01:29.869
So we at Bloxroute work really closely with the miners and the major pools, exactly on that.
01:01:30.260 --> 01:01:33.829
All this stuff out there are terrific and worth having.
01:01:33.831 --> 01:01:38.239
And I'm very glad that people are investing their time and efforts in capturing them.
01:01:38.960 --> 01:01:40.840
And I agree strongly with Mrinal.
01:01:40.840 --> 01:01:41.630
This is early.
01:01:44.090 --> 01:01:58.340
Think of how few developers even know how to handle blockchains, but Ethereum 1.0 can definitely, scale significantly, like at least one order of magnitude but around closer to two really.
01:02:00.130 --> 01:02:01.150
So I want to point that out.
01:02:02.230 --> 01:02:04.000
I don't actually disagree with that.
01:02:03.760 --> 01:02:07.090
I do think you can scale more than it is right now.
01:02:09.130 --> 01:02:13.750
Just the transition to ETH 2.0 and 3.0 is very, very important, because...
01:02:13.240 --> 01:02:16.809
we're kind of in agreement here.
01:02:19.380 --> 01:02:23.250
That's where you'll see, ultra scale, so to speak.
01:02:24.090 --> 01:02:33.360
And to my point, I think the economic security ultimately increases a lot as we make that transition.
01:02:33.360 --> 01:02:39.570
But I do agree a hundred percent that, and I'm glad you guys are working on it.
01:02:39.570 --> 01:02:44.400
That layer-zero and actual limiting of latency, etc.
01:02:45.181 --> 01:02:48.059
It's great that you guys are working on it.
01:02:48.061 --> 01:03:04.110
I mean, and I'm sure Uri knows about this really, really well, but if it wasn't for CDNs like Optimi, Level 3 etc, that are basically the backbone of the internet, I mean, I could, I almost think of them as analogous to what Bloxroute is doing for the blockchain.
01:03:05.400 --> 01:03:07.289
We wouldn't enjoy things like Netflix, etc.
01:03:07.891 --> 01:03:13.170
So it is definitely, great that people are working on this problem as well.
01:03:13.260 --> 01:03:43.769
And I think, as we make consensus better, which is what in Ethereum was doing and what we're doing, as we get the network problem better, which is with Bloxroute, and then also batching, which is what layer-two guys are doing, then across the ecosystem we'll finally, hopefully have a stack that's competitive with, what we see out there in terms of infrastructure, like the AWS is in the more centralized repositories of computers.
01:03:44.650 --> 01:03:49.960
So ETH 2.0 is definitely better scale than ETH 1.0.
01:03:50.289 --> 01:03:59.289
But to the extent that we're talking about improvement upon existing ETH 1.0 architecture, can we get it to a point where the scalability is acceptable?
01:03:59.949 --> 01:04:02.110
Is it sufficiently scaled?
01:04:02.320 --> 01:04:04.780
Which is why I brought up the CryptoKitty problem.
01:04:05.079 --> 01:04:19.360
So maybe it's better to quantify things, but I think if there's some way to address, if we were to replay that scenario, what would the Ethereum network congestion look like as a result?
01:04:19.539 --> 01:04:22.239
I think that would be an interesting thing to look at.
01:04:22.449 --> 01:04:24.219
So I was wondering if anyone has any thoughts there?
01:04:25.349 --> 01:04:30.030
So I would actually like to point out that it's not just KryptoKitties.
01:04:31.739 --> 01:04:36.510
I assume you're both familiar with what happened with MakerDAO, on black Thursday.
01:04:37.090 --> 01:04:46.449
Something very interesting happened there and I think it's important to point it out, for people to understand scalability better, and that would help to illuminate the point that you're bringing.
01:04:46.599 --> 01:04:47.409
It's not just CryptoKitties.
01:04:48.099 --> 01:04:48.369
Okay.
01:04:48.519 --> 01:05:06.789
What happened with MakerDAO is that the blockchain got so congested, that MakerDAO did not operate as intended, because there were underwater assets that people were supposed to b and there were like I think four and a half million dollar worth of ETH.
01:05:07.809 --> 01:05:11.949
And people were supposed to bid on it, and whoever made the highest bid were supposed to get it.
01:05:12.389 --> 01:05:17.579
And that was how the market should have made sure that everything...
01:05:20.960 --> 01:05:23.579
that the assets were priced correctly.
01:05:23.581 --> 01:05:29.800
But what happened when, when layer-one got congested is that nobody was able to make a bid.
01:05:29.829 --> 01:05:38.679
And so one person just made the bid and got four and a half million dollar worth of ETH because nobody else was also capable of making a bid.
01:05:39.309 --> 01:05:41.199
Now it could be that, there was also a bug there.
01:05:41.201 --> 01:05:46.340
I didn't look closely at the postmortem regarding that, but it does bring up a very important point.
01:05:47.119 --> 01:06:12.139
Practically all the scalability solutions out there, all the layer-two solution out there, Go back to this, fraud proof, the idea that if, if something is wrong, if something isn't priced right, if something is, there is some misbehavior, you can always show you have like a window of time, in which you can send the transaction and prove, hold on, there is some misbehavior going on.
01:06:12.141 --> 01:06:13.369
I'm being defrauded here.
01:06:13.880 --> 01:06:22.719
However, it's like for layer-two to work, you need layer-one to be at scale to have excess scale and not be easily congested.
01:06:23.139 --> 01:06:43.130
And so if, if there was a full blown operating, the best layer-two solution out there working on Ethereum, during the like that black Thursday and somebody would decide to defraud and say, oh, I'm going to to to commit to the blockchain, some older state...
01:06:43.130 --> 01:06:49.980
it used to be valid, but now it's no longer valid because like the change the state had changed.
01:06:50.670 --> 01:06:56.369
Even if somebody saw that, if the blockchain is congested, then you couldn't prevent him from doing it.
01:06:56.371 --> 01:07:01.650
You can't get your transaction there, or maybe you could, but it would cost you more than you're being defrauded.
01:07:01.050 --> 01:07:04.079
Now, take that and multiply it by a thousand, okay.
01:07:04.081 --> 01:07:05.670
Not a single person who's being defrauded.
01:07:06.300 --> 01:07:18.079
Think of it, a decentralized exchange or something like that that a lot of transactions happen off chain and then somebody with some measure of control, go take that and defraud everybody at the same time.
01:07:18.300 --> 01:07:26.090
Now you have a thousand people that, under congestion, are fighting to show that they're being defrauded but there is no room for them.
01:07:26.539 --> 01:07:32.030
So I would argue that you need layer-one to scale even if you have a layer-two solution operating there.
01:07:32.840 --> 01:07:45.539
So Mrinal might have a take on that because, in the context of on-chain and how Casper might react to that, but generally speaking, this is an issue.
01:07:45.541 --> 01:07:58.769
You need to scale the blockchain to such an extent that you can do off-chain stuff, but you can also do on-chain stuff if you need to.
01:07:59.340 --> 01:08:00.150
Does that kinda make sense?
01:08:00.539 --> 01:08:03.030
I agree that layer-two is not a panacea.
01:08:02.280 --> 01:08:07.500
Like, oh wow, layer-one is too slow, but we can solve this in layer-two.
01:08:07.501 --> 01:08:11.940
Layer-two is extremely important, an integral part of the ecosystem.
01:08:13.889 --> 01:08:17.449
But yes, if layer-one isn't fast enough, that's your trust anchor, for lack of a better term.
01:08:17.869 --> 01:08:23.630
And so the amount you have to batch is, kind of inversely proportional, to how fast the underlying system is.
01:08:24.079 --> 01:08:29.300
And so you can run into, you know, race conditions like you've laid out.
01:08:29.359 --> 01:08:30.260
So I actually agree with that 100%.
01:08:30.261 --> 01:08:34.640
To Richard's question of, is it fast enough?
01:08:35.510 --> 01:08:51.350
To scale a blockchain to be, competitive trust anchor, de-centralized trust anchor, similar to an AWS or Google cloud or something, I think you have to get into the tens of thousands of transactions per second.
01:08:52.039 --> 01:08:57.380
Now, I don't know if that's possible in a fully decentralized manner with present technology.
01:08:59.569 --> 01:09:01.010
We've not seen it implemented.
01:09:01.310 --> 01:09:11.539
You can see a few thousand, in tests we're seeing in a single shard, again, fully decentralized, permission-less, 1500 plus in tests.
01:09:12.140 --> 01:09:15.859
And so, you get pretty fast.
01:09:15.860 --> 01:09:24.829
But you also have to start doing things like, sharding and partitioning of the network, because I truly believe like that number is more in the tens of thousands.
01:09:25.100 --> 01:09:27.380
I'm not talking about the industry as it is now, right?
01:09:27.381 --> 01:09:30.739
We're talking about a 0.3% penetrated industry.
01:09:31.100 --> 01:09:34.449
I'm talking about what happens when it becomes a 50, 60% penetrated industry.
01:09:35.510 --> 01:09:37.220
That's real scalability.
01:09:38.149 --> 01:09:46.789
At that point you need tens of thousands because if you think, people like to use visa as a metric, which can peak at around 40,000 transactions per second.
01:09:47.239 --> 01:09:49.760
But bear in mind, that's just money transfer.
01:09:49.100 --> 01:10:11.270
If you're actually doing things like propagating every single intellectual property record onto the blockchain, if you want to be monitoring supply chains, even with a level of batching, you can see that, the amount of worldwide, call it writes or commits to the blockchain, could get very big, very fast.
01:10:11.899 --> 01:10:19.699
We're already seeing things throttling for such an under-penetrated industry, with no real, big industrial use cases yet.
01:10:20.449 --> 01:10:26.960
Once those start coming on board, the numbers you're going to need are very, very high.
01:10:26.961 --> 01:10:35.960
So I don't know if a couple of orders of magnitude for the real big prize, is sufficient for the end state.
01:10:35.961 --> 01:10:42.140
But I do think for current usage of blockchains that will probably suffice.
01:10:42.140 --> 01:10:56.930
But when I'm thinking about scalability, I'm thinking always about, okay, decade and a half from now, and I'm hoping this ends up happening, blockchains become a major part of the Internet's technology stack.
01:10:56.930 --> 01:11:00.500
at that point I think we're looking closer to tens of thousands.
01:11:00.979 --> 01:11:02.630
I don't know what the exact number is.
01:11:02.960 --> 01:11:07.880
I think you'd have to kind of look at, kind of writes and commits, that are done on the OS.
01:11:08.600 --> 01:11:12.859
You can of course, partition them into like some portion that required blockchain and some that don't.
01:11:13.350 --> 01:11:17.310
There's a lot of stuff that, some people I think try to throw everything on the blockchain that doesn't need to be there.
01:11:18.899 --> 01:11:20.520
It's just that the stuff that needs a decentralized trust anchor.
01:11:22.170 --> 01:11:24.239
But even that should be tens of thousands.
01:11:24.270 --> 01:11:37.229
Because if you're thinking about, if you take TPS as like a single write or a single commit, AWS itself is probably doing millions if not billions a second, across their entire infrastructure.
01:11:37.890 --> 01:11:59.100
So hard question to answer, but I think several orders of magnitude above where we are as an industry right now, which is why I think the efficient shift over to proof-of-stake as well as parallelization and concurrency while in its infancy, are sort of the building blocks to getting toward that scale eventually.
01:12:00.189 --> 01:12:03.279
I actually think Mrinal here is underestimating.
01:12:03.430 --> 01:12:10.659
If you look at credit card companies, last year they did an average of 6,000 transactions per second.
01:12:10.779 --> 01:12:11.590
Now that's average.
01:12:12.430 --> 01:12:20.600
Alibaba holds the record with 325,000 transactions per second in Singles day, like two or three years ago.
01:12:20.899 --> 01:12:25.520
But that is for regular transaction, you need 6,000 transactions per second on average.
01:12:25.819 --> 01:12:33.710
If you want to do micro payments, which are, you can't do right now because they're like prohibitively expensive to make a transaction.
01:12:34.189 --> 01:12:41.460
Immediately you reach to the area of like 50, 60, 70,000 transactions per second like 10x out there.
01:12:41.970 --> 01:12:55.260
Add in programmable money, add in DeFi algo trading on decentralized exchange, and practically like IOT device, that[inaudible] with one another.
01:12:56.119 --> 01:12:57.819
The way we estimate it isn't...
01:12:58.590 --> 01:13:03.270
at the end game, it is like 200, 300, 400,000 transactions per second.
01:13:03.600 --> 01:13:08.399
I actually think tens of thousands is underestimating it.
01:13:08.430 --> 01:13:21.899
If you're looking at supply chains and you're looking at, you want everybody, if you're, if you were Boeing, poor Boeing, to build the Dreamliner, have something like 50,000 different subcontractors.
01:13:22.170 --> 01:13:23.909
Each one of them has sub-subcontractors.
01:13:25.140 --> 01:13:39.489
And so if you want a system that allows you to see everything as it happens, and nobody can fumble with it and nobody can hack it,'cause you want to know whether things are actually delivered or not delivered on time, etc.
01:13:40.390 --> 01:13:43.869
Just that one use case is very, very, very big.
01:13:44.350 --> 01:13:48.470
So tens of thousands in my estimation is actually understatement.
01:13:49.319 --> 01:13:49.859
Yeah, I agree.
01:13:49.860 --> 01:13:51.090
It might not even be enough.
01:13:52.680 --> 01:13:54.539
What I meant to say was"at least," right?
01:13:54.541 --> 01:13:56.670
Like yeah, it might not be enough.
01:13:56.371 --> 01:13:57.359
My view...
01:13:58.500 --> 01:14:17.170
like hopefully what happens though is, batching systems get efficient enough that, they almost have to, because at the end of the day, blockchain will always be a more expensive technology than a regular database or a regular AWS.
01:14:19.720 --> 01:14:24.970
Just because you're getting a ton of security because you're having a lot of different computers run the same thing.
01:14:26.380 --> 01:14:43.060
And so just by its underlying structure, of course we can make this more efficient, but just by its underlying structure, they'll always be, I don't know what that number is, something-x of the cost of deploying a database, or something like that.
01:14:43.720 --> 01:14:47.079
And so, some level of batching will be required.
01:14:47.199 --> 01:15:09.819
But I agree, hopefully we get to a state where tens, or hundreds of thousands of sufficient, but I agree with you, if you were to like decompose everything right down to the atomic unit of a read or write, those numbers could be, again, orders of magnitude lower than what people want to propagate onto a decentralized store of data and value.
01:15:12.010 --> 01:15:20.380
And notice that this floor that Uri is providing to the TPS for Ethereum to really be considered scalable.
01:15:20.381 --> 01:15:22.989
That's sort of working against your argument though, right?
01:15:23.250 --> 01:15:26.430
So I wouldn't consider it working against my case.
01:15:26.550 --> 01:15:29.279
I would argue with that this is the end game.
01:15:29.340 --> 01:15:33.569
This is 10 years from now, if not if not 15 as Mrinal pointed out.
01:15:34.380 --> 01:15:37.760
Um, so the question is pretty much what's going to be...
01:15:37.761 --> 01:15:44.090
we have seen Ethereum grow right in an exponential way and nothing grows forever in an exponential way.
01:15:44.149 --> 01:15:45.109
It just grows too fast.
01:15:45.409 --> 01:15:51.619
But we have seen, the grass root movement and people making and building stuff and it's terrific.
01:15:52.140 --> 01:15:56.090
The question is can Ethereum 1.0 scale.
01:15:56.359 --> 01:15:59.479
So we are always ahead of the curve off of the need.
01:15:59.819 --> 01:16:00.060
Okay.
01:16:00.060 --> 01:16:12.810
So, when we worked with the miners and they increase it by 25%, that was immediately eaten up because the demand for transaction is significantly higher than just 25% more than the current capacity.
01:16:13.319 --> 01:16:19.109
But can we take, can Ethereum 1.0 be scaled by 10x right now, short answer is yes.
01:16:19.140 --> 01:16:32.460
We deployed on the Ethereum network, worked with Bloxroute, with the current state, etc, we were able to see, even we were just half as fast as we are today, we saw in the hundreds of transactions per second.
01:16:33.489 --> 01:16:37.060
Are there going to be challenges moving from that to the next-x?
01:16:37.930 --> 01:16:38.890
Definitely.
01:16:39.369 --> 01:16:43.329
But these challenges a lot of the times has to do with how the code is written.
01:16:43.840 --> 01:16:46.420
And that's true for almost all the blockchains out there.
01:16:47.159 --> 01:16:50.239
They're operating such a small scale.
01:16:50.560 --> 01:16:56.420
So they are not written in order to operate at...
01:16:56.670 --> 01:16:58.199
the operations are just too slow.
01:16:58.439 --> 01:17:02.090
They're not written to operate at the thousands of transactions per second.
01:17:02.091 --> 01:17:03.590
Yet however people are writing.
01:17:03.619 --> 01:17:15.239
I hear Vitalik told me about one of the dev teams, I don't remember if it was iPegasus, or somebody else, very, very professional in how they're writing their code.
01:17:15.300 --> 01:17:24.960
And so, can Ethereum 1.0 scale, really goes to the question, can it give more capacity than it's being consumed and needed.
01:17:25.289 --> 01:17:37.609
And that is absolutely correct right now and it is absolutely or very, very, very likely that in a year from now the growth we see with capacity is going to go hand in hand with the demand.
01:17:37.610 --> 01:17:41.600
So yes, we're not ready for the end game.
01:17:41.301 --> 01:17:42.079
ETH 1.0 is nowhere ready for the endgame.
01:17:42.470 --> 01:17:46.340
But we have 10 years to get ready for it.
01:17:47.020 --> 01:17:47.800
Okay, perfect.
01:17:47.949 --> 01:17:51.460
So let's move on to round three with audience question, and the closing remarks.
01:17:51.850 --> 01:18:01.420
There's one question from an audience member named@youngbitness: The overcrowded nature of public chains these days will lead to inevitable consolidation in the next few years.
01:18:01.689 --> 01:18:04.569
How do you see M&A get played out in the space?
01:18:04.930 --> 01:18:10.359
So this is clearly not strictly related to ETH scalability, but it is a question from the audience.
01:18:10.360 --> 01:18:11.859
I'd love to hear answers from you both.
01:18:12.899 --> 01:18:14.369
So I agree with the insight.
01:18:14.729 --> 01:18:18.479
it's kind of overcrowded and M&A is kind of inevitable.
01:18:20.970 --> 01:18:23.609
This is how the software industry works in general, right?
01:18:23.610 --> 01:18:34.529
I mean, when people think of companies like Microsoft or Oracle, and I'm not saying that that's where blockchain is headed, but just, just to give historical context, they're not one company.
01:18:34.770 --> 01:18:38.130
Microsoft has acquired, I don't know, a few thousand.
01:18:38.699 --> 01:18:40.890
Cisco has acquired a few thousand companies.
01:18:41.340 --> 01:18:45.630
So M&A has just been a historical, truth of the software industry.
01:18:45.270 --> 01:18:47.550
And it does happen.
01:18:47.609 --> 01:18:50.579
I think M&A is going to happen.
01:18:50.670 --> 01:18:53.670
It's not really happened a lot in our industry.
01:18:54.180 --> 01:18:57.630
I mean those, that Bitcoin Dark and Komodo that merged.
01:18:57.121 --> 01:19:03.359
But I wouldn't call that true M&A, but expect to see a lot more.
01:19:03.930 --> 01:19:11.670
There's the added complexity where, the standard M&A, equity or debt process is very well understood.
01:19:12.060 --> 01:19:15.239
And it's something that I personally worked in for many years.
01:19:15.840 --> 01:19:22.529
However, when you add the community and token elements to it, there's that complexity.
01:19:22.530 --> 01:19:26.640
And so I do, I don't want to go into too much detail here.
01:19:27.029 --> 01:19:36.449
I mentally have a framework of how I see it working, but essentially very similar to how, equity companies have merged, private companies have merged.
01:19:36.451 --> 01:19:51.180
I see something very, very similar, happening here where, people take the value of all the stakeholders and all the assets and then figure out what the merged entity looks like, and figures out how to split it across the stakeholders.
01:19:51.989 --> 01:19:53.729
It's really, at its essence that.
01:19:54.569 --> 01:19:57.989
And as an overcrowded space,I see that happening a lot.
01:19:59.159 --> 01:20:08.189
I don't know whether it starts happening in a year or two, but there's some very well funded projects that have not good technology.
01:20:08.550 --> 01:20:11.939
There are some not so well funded projects that have excellent technology.
01:20:12.270 --> 01:20:21.119
And if you think about it, that combination would make so much sense, two of them just combined, because they, offset each others' foibles.
01:20:22.329 --> 01:20:25.189
And so I would expect it to start happening.
01:20:25.671 --> 01:20:29.270
As an industry it's fairly immature, and that's why we haven't seen it happen.
01:20:30.140 --> 01:20:34.579
So first of all, I would like to say, that I really like Mrinal's point.
01:20:34.609 --> 01:20:39.539
You have really well funded project with not the best technology and vice versa.
01:20:39.779 --> 01:20:43.380
And I think that's just, absolutely true and correct.
01:20:42.961 --> 01:20:50.229
The synergy there is just too great not to happen.
01:20:50.710 --> 01:21:00.010
But if you were thinking from a framework perspective, when I was asked about this like two years ago, how do I see the space progressing?
01:21:00.750 --> 01:21:11.529
My take was, which is not the take I have today, but my take at the time was that, blockchain and crypto has multiple value propositions, right?
01:21:11.530 --> 01:21:17.960
You have programmable money, you have uncensorable money, you have hard money, right?
01:21:18.649 --> 01:21:24.199
Bitcoin has hard money in a way that ETH doesn't have, and ETH has programmable money that BTC doesn't have.
01:21:24.920 --> 01:21:31.920
You have private transitactions, right, if you think about Z-cash or if you think about Monero.
01:21:32.460 --> 01:21:46.310
Then if you could, my take was that you'll see, depending on how many value propositions are out there, you will see multiple, but not a thousand, not a hundred, like three or five or seven.
01:21:46.369 --> 01:21:46.699
Right?
01:21:47.079 --> 01:21:54.130
If you could incorporate Z-cash or Monero into one of the others, then they shouldn't exist and they won't exist and vice versa.
01:21:54.131 --> 01:21:56.199
So that was my take at the time.
01:21:56.500 --> 01:22:06.409
However, spending some time in the real world blockchain space, I think regionality plays a significant role that people are missing.
01:22:06.890 --> 01:22:21.649
And so even though if you have a project like Ethereum, and you have a project like Ontology in China, you might think, well they are different but there are a lot of synergies there, why would they both exist?
01:22:22.069 --> 01:22:33.960
There is a strong community in China and which is different from the community in the US, and the resources that are available to them and you see them creating different ecosystems.
01:22:34.350 --> 01:22:39.180
And I'm saying China just as an example, it's not that all Asia is the same.
01:22:39.630 --> 01:22:44.130
Japan is very different from Korea, which is very different from China.
01:22:44.159 --> 01:22:52.350
So my guess is that we're going to see consolidation but not two, five, seven blockchains but I don't know, 20 or 30.
01:22:52.590 --> 01:22:57.050
You'll see blockchain serving South America and Europe.
01:22:57.399 --> 01:23:03.270
You'll see one for the Arab world, you'll see one for the like the US, Canada, English speaking countries.
01:23:03.270 --> 01:23:06.590
You'll see definitely several projects in Asia.
01:23:06.829 --> 01:23:11.909
Some of them working with governments, some of them open, some of them all sorts of hybrids.
01:23:12.300 --> 01:23:17.810
And so I see the acquisition and merger coming and this is happening.
01:23:17.869 --> 01:23:22.340
I think the current crisis is actually going to accelerate that significantly.
01:23:22.609 --> 01:23:29.539
So we're definitely going to see all sorts of projects running out of money, and not being able to raise enough funds.
01:23:29.899 --> 01:23:35.710
And that makes for easy acquisition options for other companies which are better funded that could use that technology.
01:23:35.720 --> 01:23:49.800
But eventually I think, and I don't know that, I don't know that better than anybody else, that's just my opinion, but we'll see this consolidation to a small number of blockchains but, not five or seven.
01:23:49.890 --> 01:23:51.550
We'll see a bit more than that.
01:23:52.199 --> 01:23:57.090
The way I've been thinking about it is, M&A in software has usually been global.
01:23:58.380 --> 01:24:02.939
Whereas M&A in the banking industry has been very, very hyper regional, right?
01:24:02.940 --> 01:24:05.970
Like European banks acquire other European banks, same in Asia.
01:24:06.779 --> 01:24:08.609
Actually almost at the individual country level.
01:24:08.610 --> 01:24:17.100
And given blockchain is kind of the intersection of both these things, it's hard to predict how global or regional it is.
01:24:17.100 --> 01:24:20.069
And I think you're right.
01:24:20.430 --> 01:24:24.180
Like, we'll see some bifurcation there.
01:24:24.180 --> 01:24:27.119
What exactly that looks like is impossible to predict.
01:24:27.121 --> 01:24:28.439
I don't have a crystal ball.
01:24:28.890 --> 01:24:30.420
But in general I've move the points.
01:24:30.989 --> 01:24:42.090
But I just thought it was interesting that you talked about geographic disparities because we have seen that be a driver for regionally limited M&A especially in banks, etc, historically.
01:24:44.779 --> 01:24:45.170
Great.
01:24:45.739 --> 01:24:50.930
I would love to invite you guys to offer your closing remarks now, starting with Mrinal.
01:24:51.680 --> 01:24:52.520
Please go ahead, Mrinal.
01:24:53.270 --> 01:25:02.569
So my closing remarks are, I think ETH 1.0 can be vastly improved by layer-zero and layer-two solutions.
01:25:02.570 --> 01:25:07.369
But the reason why I say it can't scale is because I'm talking about the end game.
01:25:07.970 --> 01:25:18.409
We need a system that is extremely efficient, extremely parallel, concurrent and allows its security to scale with the value of the network.
01:25:18.411 --> 01:25:22.520
And I think that is much more ETH 2.0 or 3.0.
01:25:22.760 --> 01:25:34.220
So while I think ETH 1.0 can't scale, I would also agree that that isn't a reason to not let it scale in the interim, because that's the way technology evolves.
01:25:34.220 --> 01:25:51.289
So I kind of stand with my status that, I don't think ETH 1.0 will scale, in its current form, to be a solution that can really be, a worldwide, fully used blockchain, but pretty confident, ETH 2.0, 3.0, if it gets there.
01:25:51.649 --> 01:26:04.819
That being said, I will say that, the optimizations at the layer-zero level are extremely important, and will be a huge driving factor both for ETH 1.0 and other blockchains as you know[inaudible].
01:26:06.289 --> 01:26:19.159
But overall, more than the debate, etc, etc, I just wanted to add that it was really enjoyable to speak with Uri because I think, most things we agree more than more than disagree.
01:26:19.161 --> 01:26:26.180
And it was a fascinating and intellectually stimulating debate, which I think, hopefully the audience feels that as well.
01:26:26.630 --> 01:26:28.130
And that's the whole point of debate.
01:26:28.460 --> 01:26:32.659
Hopefully, we all learn something out of it and I certainly did.
01:26:33.460 --> 01:26:33.699
Great.
01:26:33.701 --> 01:26:34.239
Please go ahead Uri.
01:26:35.550 --> 01:26:39.000
Ethereum 1.0 can scale right now.
01:26:39.550 --> 01:26:43.770
It can scale by a multiplier, like an order of magnitude.
01:26:44.939 --> 01:26:46.439
Can it be designed better?
01:26:46.710 --> 01:26:47.640
For sure.
01:26:47.670 --> 01:26:48.510
Definitely.
01:26:48.949 --> 01:26:54.260
Can ETH 2.0 and 3.0 and other blockchains improve on it or be competitive?
01:26:54.470 --> 01:26:56.090
All that is absolutely true.
01:26:56.659 --> 01:27:00.949
But whether it can scale right now, the answer is definitely yes.
01:27:01.460 --> 01:27:03.260
And can it continue to scale?
01:27:03.680 --> 01:27:05.869
I don't see any reason that it can't.
01:27:06.439 --> 01:27:17.229
So while you might not reach the end game with the current design, however you can make progressive updates to it.
01:27:17.260 --> 01:27:22.420
It's kind of like, it's solving a problem that nobody's facing right now.
01:27:22.449 --> 01:27:29.710
How do you know that this is what you need versus some other aspect of the network or other aspect of the consensus which we are not considering?
01:27:29.140 --> 01:27:42.920
Ethereum 1.0 can scale because we saw that, and I have yet to see evidence that even going forward it cannot be changed, and like yo, you need POS, you need to change the consensus.
01:27:43.090 --> 01:27:43.489
No, no, no.
01:27:43.490 --> 01:27:43.970
Hold on.
01:27:43.970 --> 01:27:55.220
I think, let's see a point that it doesn't scale further, and then decide whether we, do you really need 2.0 or 3.0, or you need a new blockchain.
01:27:56.409 --> 01:28:06.590
But that being said, I agree that me and Mrinal did a terrible job in debating with one another, because we did most of the agreement but I think it was really educational and enlightening.
01:28:06.591 --> 01:28:08.270
So I appreciate the opportunity as well.
01:28:09.029 --> 01:28:09.329
Great.
01:28:10.170 --> 01:28:13.680
Uri and Mrinal, it's been an absolute delight to have you come on the show and debate.
01:28:13.680 --> 01:28:19.829
I've learned a lot and I think you've added new ways of thinking to our listeners' existing perspectives on Ethereum 1.0 scalability.
01:28:20.279 --> 01:28:22.680
It will be interesting to see how things unfold from here.
01:28:23.310 --> 01:28:25.529
Lastly, how can our listeners find you?
01:28:26.369 --> 01:28:31.859
So I don't use Twitter, so if you see my name on there, that's not me.
01:28:32.250 --> 01:28:33.600
Don't respond to that person.
01:28:34.479 --> 01:28:37.270
If you want to find out more about our project, just go to CasperLabs.io.
01:28:38.350 --> 01:28:42.430
And we have all our technical documentation and we have links to our github.
01:28:43.569 --> 01:28:45.039
We're an open source project.
01:28:45.369 --> 01:28:46.960
You can download all the code today.
01:28:47.170 --> 01:28:49.390
You can look at every single line of code we have out there.
01:28:50.170 --> 01:28:52.539
If you want to look at it, use it, whatever.
01:28:53.010 --> 01:28:58.960
It's all out there for you, but if you want to interact with the team, the best starting point is telegram: t.me/casperlabs.
01:29:01.109 --> 01:29:05.729
Myself and lots of members of the team try to be as responsive as we can while we're within the channel.
01:29:05.730 --> 01:29:10.920
But if you want to reach out to me directly as well, just find me in the CasperLabs channel on Telegram.
01:29:10.920 --> 01:29:10.920
Perfect.
01:29:10.920 --> 01:29:10.920
Uri?
01:29:10.920 --> 01:29:15.750
If you wonder why we're were called bloxroute, it's because we route blocks.
01:29:16.560 --> 01:29:17.130
We spell it Bloxroute.
01:29:17.131 --> 01:29:25.109
You can look for Uri Bloxroute, you can look for Uri blockchain on Twitter, on LinkedIn, bloxroute.com.
01:29:27.300 --> 01:29:28.170
Okay, thank you.
01:29:28.350 --> 01:29:32.369
So listeners, we would love to hear from you and to have you join the debate via Twitter.
01:29:32.640 --> 01:29:37.770
Definitely vote in the post debate poll and also feel free to leave your comments and say hi.
01:29:38.310 --> 01:29:42.149
We look forward to seeing you in future episodes of The Blockchain Debate Podcast.
01:29:42.270 --> 01:29:44.640
Consensus optional, proof of thought required.
01:29:45.090 --> 01:29:45.750
Thank you guys.
01:29:45.840 --> 01:29:46.260
Goodbye.
01:29:47.369 --> 01:29:47.880
Thank you.
01:29:47.909 --> 01:29:48.359
Thank you, that was great!
01:29:50.689 --> 01:29:53.550
Thanks again to Uri and Mrinal for joining the show.
01:29:54.149 --> 01:30:02.340
The layer-zero solution to scale Ethereum 1.0 is quite interesting, and it sounds like the friction of adoption is also quite low.
01:30:03.090 --> 01:30:11.159
After the debate, I learned that the related product is already live and being used by large Ethereum mining pools.
01:30:12.329 --> 01:30:28.829
And to follow up with Mrinal's point: if scalability can be broadly interpreted to include dev adoption, then embracing open programming standards and supporting more widely known languages outside of crypto would be key, which is what they're doing at CasperLabs.
01:30:30.239 --> 01:30:32.100
What was your takeaway from the debate?
01:30:32.609 --> 01:30:35.609
Don't forget to vote in our post-debate Twitter poll.
01:30:36.090 --> 01:30:39.149
This will be live for a few days after the release of this episode.
01:30:39.600 --> 01:30:42.960
And feel free to say hi or post feedback for our show on Twitter.
01:30:43.800 --> 01:30:48.989
If you like the show, don't hesitate to give us five stars on iTunes or wherever you listen to this.
01:30:50.010 --> 01:31:10.350
And be sure to check out our other episodes with a variety of debate topics: Bitcoin's store value status, tokenization and smart contracts, DeFi, Bitcoin halvening, China's future in blockchain, POW vs POS, oligopoly vs multiplicity of public blockchains, and permissioned vs permissionless blockchain for enterprise usage.
01:31:11.220 --> 01:31:13.020
Thanks for joining us on the debate today.
01:31:13.350 --> 01:31:16.770
I'm your host Richard Yan, and my Twitter is@gentso09.
01:31:19.770 --> 01:31:21.659
Our show's Twitter is@blockdebate.
01:31:22.409 --> 01:31:23.640
See you at our next debate!