WEBVTT 00:00.000 --> 00:14.300 Hey everyone and welcome to the DEF CON Blockchain Village and we are here to present our talk on the title Verifiable Delay Functions for Preventing DDoS or TDoS Attacks on Ethereum 2.0. 00:14.620 --> 00:26.700 So this is the agenda for our talk and at the very end of our session if the time allows we'll try to pick up some of your questions and we'll try to answer as many as possible. 00:27.600 --> 00:31.400 So wrapping up a quick speaker's introduction. 00:31.400 --> 00:32.200 So here am I. 00:32.200 --> 00:34.320 My name is Tejasura Sogi. 00:34.320 --> 00:45.320 I'm a penetration tester, a blockchain security researcher, founder of RazerSec which is a community that helps people to learn about blockchain security. 00:45.320 --> 00:47.720 I'm also a YouTuber as RazerSharp . 00:47.720 --> 00:54.280 I post security content on YouTube and the most important thing I'm a cybersecurity enthusiast. 00:54.300 --> 00:56.880 I love the world of internet. 00:57.120 --> 00:59.480 With that I will ask my partner Mr. 00:59.480 --> 01:02.640 Gokul Alex to say a few words about him. 01:02.880 --> 01:04.740 Thank you Tejasura. 01:04.780 --> 01:08.720 Hi everyone this is Gokul Alex. 01:08.760 --> 01:19.360 It's my pleasure and privilege to present in this platform in DEF CON in front of every one of you. 01:19.360 --> 01:30.040 I'm the founder of Epic Knowledge Society, one of the fastest growing digital education platform for engineers and entrepreneurs in India. 01:30.340 --> 01:33.160 We are a non-profit organization. 01:33.420 --> 01:42.700 I am also building a blockchain protocol integrating off-chain and on-chain data called Fusion Ledger. 01:42.820 --> 01:57.720 I am representing a collection of cryptocurrencies and platforms in India such as Algorand, Eternity, Elixir, Hashgraph, Horizon and Tezos. 01:57.720 --> 02:08.140 I'm also the director of Tezos India Foundation and I've been selected as the MVP for Hedera Hashgraph in 2018. 02:08.580 --> 02:19.590 I am a global leader for XS collective created by David Choum known as the godfather of cryptography and blockchain technology. 02:19.590 --> 02:23.470 I am a programmer and poet in my personal life. 02:23.470 --> 02:30.470 I've been a blockchain security auditor for government, public sector and private sector across various countries. 02:30.610 --> 02:37.440 I am actively researching on the convergence of quantum algorithms and post-quantum cryptography. 02:38.400 --> 02:42.200 Over to Tejeshwar to get start with the presentation. 02:42.200 --> 02:43.540 Awesome! 02:43.540 --> 02:53.920 Now let's just start our session and before moving to the attack vectors on proof-of-work, let's get a quick refresher on some of the fundamentals. 02:53.920 --> 02:59.140 So let's talk about what is proof-of-work consensus algorithm. 02:59.140 --> 03:02.380 Now before that let's talk about what are consensus algorithm. 03:02.380 --> 03:17.980 Now consensus algorithms decide like who should create the next block and this decision defines the basic fundamental property of blockchain which is decentralization and decentralized control of power. 03:18.020 --> 03:27.280 Now consensus algorithms is all about building fault-tolerant, fault-resilient machines for distributive computing. 03:27.280 --> 03:34.580 Now our talk is about the convergence of cryptographic schemes and consensus algorithms. 03:34.720 --> 03:41.400 Now consensus algorithms have both deterministic and probabilistic dimensions right. 03:41.400 --> 03:52.780 Now consensus algorithms helps us to achieve a consistent state and agreement between participating nodes in a blockchain network. 03:52.860 --> 03:55.940 Getting back to our proof-of-work consensus algorithm. 03:55.940 --> 04:07.100 Now in proof-of-work consensus algorithm there are miners who compete with each other for the potential valid block creation right. 04:07.600 --> 04:18.720 Now there are certain factors involved like that the block header must be less than a set threshold and then there is a mining difficulty. 04:18.720 --> 04:40.400 Now mining difficulty defines like the current computational power of the blockchain network and it can also be updated at regular intervals to match the current computational power of the network and it also ensures that the block creation should happen at a certain frequency. 04:40.500 --> 04:45.140 Now let's move on to some of the attack vectors or proof-of-work. 04:45.880 --> 04:56.180 Now in front of your screen you can see some of the attacks or attack vectors given like the first one which says denial of service or distributed denial of service. 04:56.280 --> 05:00.120 Now let's talk over this attack. 05:00.320 --> 05:16.680 Now as we have just discussed about the mining difficulty which defines the processing power of the network and can be updated at regular intervals to match the to reflect the changes right in the processing power. 05:16.680 --> 05:26.740 Now in most of the blockchain these sudden changes in the processing power are not addressed by the nodes. 05:26.740 --> 05:32.580 They can be addressed by the nodes at a scheduled update. 05:33.260 --> 05:35.180 Now let's take a scenario. 05:35.280 --> 05:43.660 Let's take a scenario of like there are nine machines on a blockchain network and six of them are malicious actors. 05:43.660 --> 05:45.660 Six of them are malicious actors. 05:45.660 --> 05:49.180 Now they are not doing anything and just chilling in the network. 05:49.180 --> 05:51.680 Everything is going as planned. 05:51.760 --> 05:55.120 Mining difficulty is working as the way it should. 05:55.120 --> 06:00.140 Block creation is happening at a certain frequency and everything is perfect. 06:00.360 --> 06:06.460 Now suddenly what the malicious actors decide they decide to turn their machines down. 06:06.460 --> 06:29.940 Now what will be the impact of this that now the remaining three machines they have to do the work of nine machines and what will happen or what will be the impact of this that the hash rate will decrease and it will decrease the block creation rate and eventually create a denial of service. 06:30.420 --> 06:35.000 So there are other attacks as well like routing attack. 06:35.000 --> 06:37.620 So routing attack consists of two parts. 06:37.620 --> 06:51.300 First one is the partition attack which divides the blockchain network into two groups and then there is a delay attack which tampers the propagating messages and sends them to the network. 06:51.980 --> 06:56.000 Moving on and there are user wallet attacks. 06:56.420 --> 07:06.780 Then there are smart contract attacks, transaction verification mechanism attacks and there you can see the well-known 51% of majority attack. 07:06.780 --> 07:10.040 Now what is this 51% of majority attack. 07:10.040 --> 07:26.340 Now let's take example like there is a group which is in majority a group of malicious actors which is in majority and they can take control over the blockchain network. 07:26.340 --> 07:36.460 Now how it can be possible as we know that there is a race between miners for the potential valid block creation. 07:36.600 --> 07:43.860 Now if there is a group of malicious actors which is in majority. 07:43.880 --> 07:54.320 Now it will have this group will have a higher and better probability to be for the block creation. 07:54.540 --> 07:59.060 So this is the 51% attack. 07:59.080 --> 08:08.460 Moving on there are some mining pool attacks like selfish mining, forecaster, withhold and like that. 08:08.480 --> 08:12.400 So moving on let's talk over DDoS on ethereum. 08:13.360 --> 08:21.280 Now there are some attacks that happened on ethereum or there are scenarios as well. 08:21.420 --> 08:27.100 So we'll pick up some of them like there was an attack on parity client. 08:27.100 --> 08:34.580 So what was the incident like some parity ethereum nodes lost sync with the network because of the following incident. 08:34.580 --> 08:43.340 Now what was the incident that if you send to a parity node a block with invalid transaction what will happen. 08:43.400 --> 09:02.160 If you send a parity node a block with invalid transaction but with valid header borrowed from another block and what will happen that the node will mark the block header as invalid and ban the block header forever but the header is still valid right. 09:03.220 --> 09:09.320 Moving on there was a vulnerability that was found in parity nodes as well. 09:09.320 --> 09:25.040 So in may global hacking research collective sr labs claimed that only two thirds of the ethereum client software that ran on ethereum nodes had been patched against a critical security flaw discovered earlier this year. 09:25.540 --> 09:39.580 The data reportedly indicated that unpatched parity nodes comprised 15% of all the scanned nodes implying that 15% of all the ethereum nodes were vulnerable to a potential 51% attack. 09:40.500 --> 09:45.960 So moving on and there is an interesting underpriced DDoS attacks. 09:45.960 --> 09:56.100 Now these are a group of attacks which exploited the vulnerability in the improper cast cost of EVM's opcodes. 09:56.100 --> 10:00.800 Now the opcodes were the ext code size and the suicide opcode. 10:00.800 --> 10:06.560 The suicide opcode was renamed to self destruct after eip6. 10:06.560 --> 10:09.100 We'll talk about that in the next slide. 10:09.100 --> 10:24.580 So let's just take the ext code size Now prior to eip150 hard fork, the ext code size opcode only charged 20 gas for reading a contract byte code from disk and then deriving its length. 10:24.880 --> 10:41.700 Now as a consequence what happened or what can happen if the attacker sent transactions to invoke a deployed smart contract with many ext code size opcodes, it can cause a two to three times slower block creation rate. 10:42.780 --> 11:02.700 Also there was a similar attack that exploited the vulnerability in the proper cast cost of EVM's suicide opcode that was renamed to self destruct as I just said and also the empty code vulnerability in the state drive. 11:03.020 --> 11:13.880 So the opcode is meant to remove a deployed smart contract right and then send the remaining ether back to the account designated by the caller. 11:14.580 --> 11:25.300 Now if the target doesn't exist a new account is created even though no ether may be transferred but still a new account is created. 11:25.540 --> 11:53.840 Now what can happen like the attacker can create empty accounts and that was or that happened like that the attacker created 19 million new empty accounts by the opcode at a very minimal gas consumption and which wasted disk space and increased synchronization and processing time and caused a kind of denial of service right. 11:54.060 --> 12:09.920 Moving on to uh attack uh the attackers took advantage of the enterprise tdos attack and that happened between the blocks mentioned in front of your screen. 12:10.040 --> 12:11.960 Now what was the impact? 12:11.960 --> 12:19.840 It created millions of dead ethereum accounts and also bloated the state database. 12:20.060 --> 12:24.440 Now it also created tons of transaction freezes as well. 12:25.340 --> 12:37.020 Moving on to the impact of ddos attacks uh the enterprise one and what was the impact that that can be hacks against goethereum client. 12:37.020 --> 12:45.420 Hacks can be created against huge amount of cleanup transactions and each cleanup transaction creates large set of freezes. 12:45.420 --> 12:54.500 There may be a possibility of hard fork being created and even if the hard fork is created hard forks do not remove the dead accounts right. 12:54.980 --> 13:10.140 Moving on to some of the quick fixes to the attacks like scanning an initial set of transaction can be done measuring the traces from each transaction and also checking the frequency of traces in the transactions. 13:11.880 --> 13:16.780 Moving on to let's talk about the attack vectors on proof of stake. 13:16.780 --> 13:24.760 Now before covering the attack vectors let's do a quick refresher again on the proof of stake consensus algorithm. 13:25.300 --> 13:29.280 Now proof of stake is a popular alternative to proof of work. 13:29.380 --> 13:37.220 In proof of stake there are validators instead of miners and a validator is selected to forge a block. 13:37.380 --> 13:50.900 Also the validator selection depends upon the amount of cryptocurrency a validator has or the amount of stake a validator has and also on the current complexity of the network. 13:51.920 --> 13:57.320 And proof of stake has many advantages over proof of work. 13:57.320 --> 14:00.120 The first is obviously the security. 14:00.120 --> 14:05.040 It provides a better security mechanism against 51% attack. 14:05.040 --> 14:17.360 Now as we know like in proof of work owning 51% of the computational power meaning means like gaining control over of the network. 14:17.360 --> 14:31.040 But in proof of stake owning 51% of the stakes would be very would be computationally very expensive for an attacker. 14:31.040 --> 14:34.120 So that's how it provides a better security. 14:34.120 --> 14:41.300 Also it provides better it's energy efficient and provides energy savings. 14:41.640 --> 14:56.280 Now also as the ethereum 2.0 is ethereum is transitioning from ethereum 1 to ethereum 2.0 and it is transitioning from proof of work to proof of stake. 14:56.280 --> 15:00.640 And there is a casper protocol based on proof of stake. 15:00.640 --> 15:12.740 It provides its own security implications like this slashing mechanism which provides slashing of stakes as a penalty to the validator. 15:12.740 --> 15:37.660 Now if a validator validates a block it has been awarded but if found that the validator is involved in malicious activity the stakes will be slashed as a penalty and there might be a chance as well that it can lose its privileges to take part in the network consensus. 15:39.280 --> 15:42.700 So this was casper protocol. 15:43.400 --> 15:49.260 Moving on to let's see some of the attack vectors attacks against proof of stake. 15:49.260 --> 15:53.320 You can see a list of attacks in front of the screen. 15:53.320 --> 15:57.660 There is a fake stake attack a very interesting attack. 15:57.660 --> 16:02.660 Now fake stake attack can be think about as a denial of service. 16:02.660 --> 16:11.320 An attacker can devote a node's valuable memory and cpu to a fake chain. 16:11.320 --> 16:20.060 Now we know there is a longest chain rule that any chain can suddenly become the accepted version of the ledger. 16:20.580 --> 16:26.680 Now validation of a proof in proof of stake is kind of complex. 16:26.680 --> 16:35.920 Now it required access to both the block header as well as the contents of block. 16:36.380 --> 16:48.480 So like to trigger the stake value for the validator selection right and forcing the node to download data to validate fake blocks. 16:49.900 --> 16:56.800 It consumes valuable resources for the node and can eventually result into a denial of service. 16:56.840 --> 17:03.500 So fake stake attack can be think about as a denial of service and proof of stake. 17:03.960 --> 17:08.140 Moving on to let's see the 3m 2.0 architecture. 17:08.700 --> 17:17.120 In front of your screen you can see a beautiful picture defining the road map to serenity. 17:17.980 --> 17:23.400 Then there is the current blockchain showing proof of work and proof of stake together. 17:25.660 --> 17:30.140 And then you can see a little bit detailed architecture. 17:30.140 --> 17:33.340 Like there is a main chain based on proof of work. 17:33.340 --> 17:41.040 Then there is a beacon chain based on the casper ffg protocol, proof of stake protocol that we just discussed. 17:41.100 --> 17:44.120 And random number generation happens. 17:44.320 --> 17:54.100 Now you can see that the beacon chain is cross-linked with the shard chain and underneath there is execution engine as well. 17:54.100 --> 17:58.720 Moving on to see some of the 3m 2.0 audit findings. 17:58.800 --> 18:01.880 Talking about the Constem audit first. 18:01.920 --> 18:14.000 Now Constem did an audit as well and founded some DDoS attack vectors, attack vectors and reported them. 18:14.140 --> 18:20.340 Like DDoS attack through creating a mapping between public keys and validator IPs. 18:20.340 --> 18:25.480 Also DDoS attack on insecure gRPC connection. 18:26.440 --> 18:28.380 So what was the Constem audit? 18:28.620 --> 18:37.020 Basically it involved 10 engineers who examined the entire code base over the course of two months. 18:37.020 --> 18:44.300 They examined the beacon node logic, validator client, flasher logic and almost everything. 18:46.570 --> 18:48.410 So what were the findings? 18:48.410 --> 18:50.850 They found a lot of vulnerabilities. 18:50.850 --> 19:04.990 Some of them are like granularity of timestamps, pseudo random number generation where two random number generation were needed and then a second pre-made attack on merkle trees as well. 19:05.630 --> 19:09.090 Now let's talk about the least authority audit as well. 19:09.090 --> 19:18.310 So they did an audit over various subsections like they did a audit over block proposal system. 19:18.350 --> 19:19.590 What were the findings? 19:19.590 --> 19:34.850 Like a single secret leader election SSLE keeps a selection secret and stops the leak of information to an observer while still allowing the chosen block proposer a fast way to verify to others that it is in fact the proposer. 19:34.850 --> 19:41.290 With the information leak passed, the block proposer remains as protected as it is. 19:41.290 --> 19:46.650 It would be in proof of work chains but without the computational overhead. 19:47.950 --> 19:51.930 We're talking about the findings on a gossip protocol. 19:51.930 --> 19:56.350 Now gossip protocols generally suffer from the spam problem. 19:56.350 --> 20:05.290 Without a centralized judge, it can be difficult to understand whether a message is legitimate or is spam that is meant to clog a network. 20:05.630 --> 20:10.010 This was one of the primary concerns in examining the network layer. 20:10.090 --> 20:17.750 In Ethereum 2.0, when a node proposes a new finalized block, the block must be sent to the rest of the network. 20:18.290 --> 20:38.950 There is an issue when a dishonest node is capable of sending an unlimited amount of older block messages to the rest of the network with minimal penalty which allows them to overwhelm the network and block legitimate messages. 20:39.030 --> 20:47.090 Also, there were findings on slashing messages that we just discussed earlier, the Casper protocol security implication. 20:47.550 --> 21:01.450 Now there is a small loophole as well that allowed a node to send an unlimited amount of these types of messages with minimal penalty causing the same message blocking if they send enough of them. 21:02.110 --> 21:06.450 Now moving on to talk about DDoS on Ethereum 2.0. 21:06.750 --> 21:11.630 Let's take the recently happened Teku attack scenario. 21:11.830 --> 21:19.950 Now there were security engineers who did research over public antagonists. 21:19.950 --> 21:23.230 They found a Teku attack, created a Teku attack. 21:23.230 --> 21:25.150 Now what was the scenario like? 21:25.150 --> 21:31.630 Two of the four Teku nodes were targeted by five ordinary machines with a sustained DDoS attack. 21:32.050 --> 21:34.010 Now what was the impact? 21:34.010 --> 21:45.150 That initial loss of finality was achieved with two or three machines but the others joined with a few epochs to ensure that the network could not recover. 21:47.030 --> 21:49.350 Now what was the implementation? 21:49.390 --> 21:52.990 You can see a command in front of your screen. 21:53.470 --> 22:08.430 So what the command does, it pipes the null byte from Dave's view to the pb command which rate limits to a somewhat arbitrary value high enough to prevent finality. 22:08.830 --> 22:16.850 But stay off AWS and IPS radars to ensure the attack continuous. 22:17.290 --> 22:26.150 Also the data is then piped back into the netcat command which sends it to the nodes under attack. 22:26.230 --> 22:34.670 The while loop is there for when it loses connectivity and command compiles due to container restarts. 22:36.050 --> 22:39.450 And moving on to what was the impact of this Teku attack. 22:39.450 --> 22:53.470 The effect that the denial of service attack had on the attack net was a prolonged loss finality and required manual intervention to restore the network to a healthy state once the attack stopped. 22:53.770 --> 23:00.370 Now the nodes under attack used large amounts of memory while subject to multiple container restarts. 23:00.370 --> 23:07.850 Had trouble staying connected to peers and even once nodes local clock was like 20 minutes slow. 23:08.890 --> 23:12.270 Moving on to the Teku attack root cause. 23:12.270 --> 23:16.550 Now firstly responding to one byte when multiple bytes is a vector. 23:16.550 --> 23:20.010 We know for various amplification attacks that we know. 23:20.010 --> 23:23.990 But that was not the issue that caused the loss of finality. 23:23.990 --> 23:34.170 The second issue is that responses were being written faster than they were read by the attacking peer and the JVM libp2b was not applying any throttling. 23:34.350 --> 23:43.800 Eventually the TCP backpressure kicked in, filled up the OS write buffers and the responses wound up being queued in user space memory. 23:44.130 --> 23:49.210 This pushed up both the on and off heap memory usage very substantially. 23:49.930 --> 23:55.230 Also CPU spikes significantly partly due to the processing power. 23:55.510 --> 24:03.930 All those due to processing all those multi-stream messages but mostly because of the resultant memory pressure and GC activity. 24:04.770 --> 24:08.270 Now talking about what can be a solution. 24:08.270 --> 24:19.410 It's like there can be a straightforward solution like disconnect the peer immediately when an invalid example like multistream message is received. 24:19.410 --> 24:31.970 And now also there's a resilience to dot attack as well which increases significantly as increases the number of nodes and diversity of clients, locations and network connections. 24:32.230 --> 24:35.050 So this was the takeover attack. 24:35.050 --> 24:38.550 We covered consensus algorithms. 24:38.550 --> 24:41.790 We talked over proof-of-work, proof-of-stake. 24:41.790 --> 24:46.630 We took different attacks, attack vectors as well. 24:46.630 --> 24:50.050 We talked over 51% attack, denial of service. 24:50.050 --> 24:53.450 We have seen the ATM 2.0 architecture. 24:53.450 --> 24:57.290 Also the security implications of cash flow protocol. 24:57.290 --> 24:58.690 Now my partner Mr. 24:58.690 --> 25:09.990 Gopal Alex will connect with you all the links, the PDF, randomness and DDoS and will connect all of them and present it to you. 25:09.990 --> 25:11.290 So over to you sir. 25:13.090 --> 25:20.550 Thank you Tejaswar for setting the context, for researching on the randomness in Ethereum 2.0. 25:21.130 --> 25:29.450 We will see how randomness is very crucial to the overall engineering and overall design of Ethereum 2.0. 25:29.870 --> 25:47.950 If you look at all the current implementations, be it on near protocol, prismatic labs, the beacon chain, there is a crucial play for randomness because all the sharding designs today rely on some source of randomness to assign validators to the shard. 25:48.670 --> 25:57.250 Both the randomness and the validator assignment require computation that is not specific to any shard. 25:57.250 --> 26:08.770 For this computation, existing designs have a separate blockchain that is tasked with performing operations necessary for maintenance of the entire network. 26:08.910 --> 26:19.070 Besides generating these random numbers and assigning validators to the shards, these operations also include receiving updates from shards and taking snapshot of them. 26:19.070 --> 26:20.450 This is very important. 26:22.770 --> 26:26.550 The shards and taking activity. 26:26.650 --> 26:30.790 In older times, we used to take additions, cut additions from the databases. 26:30.870 --> 26:33.030 The snapshots are the read-only versions. 26:33.230 --> 26:51.150 And also when we process the stakes and slashing in proof-of-stake systems, and when you have to plan the proximity of shard with the leaders and rebalancing the shard, these randomness... so sharding, staking, and randomness have to work together. 26:51.210 --> 27:04.350 When you look at all these implementations, whether it's Cosmos Hub in Cosmos, or RelayChain in Polkadot, or BeaconChain in Ethereum and Near, this is the overall architecture. 27:04.670 --> 27:09.910 But we have to understand, we cannot afford any simple randomness. 27:09.910 --> 27:12.710 We need distributed randomness on blockchain. 27:12.710 --> 27:18.870 That is why randomness in blockchain becomes much more complex and more challenging. 27:18.970 --> 27:25.310 So many blockchains, if you know, blockchains have different purpose of using randomness. 27:25.310 --> 27:41.430 Maybe it's for time stamping, or it could be for games like lottery games, or it could be for proof of replication, like in Filecoin, or in the case of Ethereum, BeaconChain for selecting participants. 27:41.570 --> 27:46.290 What happens if a malicious actor can influence such a source of randomness? 27:46.290 --> 27:53.210 They can increase the chance of being selected and possibly compromise the security of the protocol. 27:54.670 --> 28:02.590 And like we said, distributed randomness is very crucial building block for any kind of applications on blockchain. 28:02.770 --> 28:07.490 What are the essential properties of randomness required in a blockchain setup? 28:07.490 --> 28:10.670 There are three essential properties laid out. 28:10.670 --> 28:13.350 First, it needs to be unbiased. 28:13.370 --> 28:16.990 We cannot afford a biased source of entropy. 28:17.030 --> 28:22.930 In other words, no participant shall be able to influence in any way the outcome of the random generator. 28:23.150 --> 28:25.350 Second, it needs to be unpredictable. 28:25.430 --> 28:31.790 In other words, no participant shall be able to predict what number will be generated, or what are the properties of it. 28:32.010 --> 28:43.670 Thirdly, the protocol needs to tolerate some percentage of actors that go offline or try to intentionally stall the protocol, like the conventional crash fault tolerance and Byzantine fault tolerance. 28:43.670 --> 28:46.930 Now we will look at some of the existing approaches. 28:46.930 --> 28:53.250 One of the first approaches is the RANDAO approach, which is the acronym for Random DAO. 28:53.250 --> 28:59.430 The general idea is that the participants in the network, first of all, privately choose a pseudo random number. 28:59.430 --> 29:02.890 Submit a commitment to the privately chosen number. 29:02.890 --> 29:07.970 This commitment could be implemented as a polynomial commitment or a Pedersen commitment. 29:07.970 --> 29:12.850 All agree on some sort of commitment using a consensus algorithm. 29:12.850 --> 29:22.810 Then all reveal the chosen numbers, reach a consensus on the revealed numbers, and have the XOR of the revealed numbers to be the output of the protocol. 29:22.970 --> 29:27.770 This is a pretty straightforward approach, but there are some limitations. 29:28.150 --> 29:33.190 It is fairly unpredictable, and it has liveness. 29:33.190 --> 29:39.490 We know liveness and safety are two required properties of any consensus mechanism. 29:39.490 --> 29:42.770 This provides a great degree of liveness. 29:42.830 --> 29:56.790 However, a malicious actor can observe the network once and start to reveal the numbers and choose to reveal or not reveal the number based on the XOR of the number they observed. 29:56.790 --> 30:10.130 This allows a single malicious actor to have one bit of influence on the output, and a malicious actor controlling multiple participants have as many bits of influence as the number of participants they are controlling. 30:11.090 --> 30:20.930 So there is a proposal, and there is a strong support in this direction, which is to blend RANDAO plus VDF. 30:20.930 --> 30:23.130 We will talk about VDF in detail. 30:23.130 --> 30:25.430 First, let us understand this approach. 30:25.750 --> 30:37.130 To make RANDAO unbiasable, one approach would be to make the output not just an XOR, but something that takes more time to execute than the allocated time to reveal the numbers. 30:37.190 --> 30:46.970 If the computation of the final output takes longer than the revealed phase, the malicious actor cannot predict the effect of them revealing or not revealing the number. 30:46.970 --> 30:56.470 So we are talking about a computation which is sequential, which cannot be paralyzed by a powerful malicious adversary. 30:56.610 --> 31:04.510 Such a function that takes a long time to compute is fast to verify the computation, and has a unique output for each input. 31:04.510 --> 31:11.830 It is called as verifiable delay functions, and the design is extremely complex, which we will talk in detail. 31:12.070 --> 31:15.330 What is Ethereum's perspective on RANDAO plus VDF? 31:15.330 --> 31:21.990 You can find numerous conversations on this in Ethereum research led by Justin Drake and others. 31:21.990 --> 31:27.130 Ethereum presents a plan to use RANDAO with VDF as their randomness beacon. 31:27.130 --> 31:31.450 Besides that fact, this approach is unpredictable and unbiasable. 31:31.450 --> 31:36.850 It has an extra advantage that it has liveness, even if only two participants are online. 31:36.850 --> 31:38.730 This is a very interesting property. 31:38.730 --> 31:44.770 It requires very, very less live participants compared to any other approach. 31:44.770 --> 31:52.870 For the family of VDF linked above a special ASIC, it can be 100 times faster than conventional hardware. 31:52.870 --> 32:01.070 That is why there is a strong effort and investment in Ethereum currently to build ASIC hardware for VDFs. 32:01.070 --> 32:12.010 So if the reveal phase lasts only 10 seconds, for example, VDF computed on such an ASIC must take longer than 100 seconds to have 10x safety. 32:12.010 --> 32:19.230 And does the same VDF computed on the conventional hardware need to take 100x 100 seconds in three hours? 32:19.230 --> 32:22.470 Hence, there comes a dependency on hardware. 32:22.470 --> 32:28.470 That is the challenge because of this approach or the trade-off in this approach. 32:28.470 --> 32:34.930 Now let us look at an early approach which is fairly very popular. 32:34.930 --> 32:37.450 This approach is pioneered by DFINITY. 32:37.670 --> 32:44.330 In fact, more than one year back or two years back, DFINITY used BLS signature. 32:44.330 --> 32:46.050 What is BLS signature? 32:46.050 --> 32:50.310 It is known as Bonnet Line Shazam Signature. 32:50.710 --> 32:57.210 One of the authors of this cryptographic scheme, Ben Lin, is actually a member of DFINITY. 32:57.210 --> 32:59.010 What is this BLS signature? 32:59.010 --> 33:03.910 This is a scheme allowing a user to verify that a signer is authentic. 33:04.230 --> 33:07.850 This scheme uses a bilinear pairing for verification. 33:07.850 --> 33:14.150 We know about bilinear maps in elliptical cryptography, how powerful and formidable they are. 33:14.150 --> 33:17.970 So this is a signature scheme built using bilinear pairings. 33:17.970 --> 33:32.510 BLS signature is a construction which allows multiple parties to create a single signature on a message which is often used to save the space and bandwidth by not requiring sending around multiple signatures. 33:32.510 --> 33:43.730 This is a very interesting property and hence BLS signatures are becoming very popular in more cryptocurrencies and blockchains. 33:43.730 --> 33:52.870 A common usage of BLS signatures is in signing BFT protocols, for signing blocks in BFT protocol. 33:52.970 --> 34:06.570 When we look at threshold signatures in practice, say there are 100 participants to create blocks and a block is considered final if two by third of them, 67 of them sign on it. 34:06.570 --> 34:18.470 They can all submit the parts of the BLS signature and then use some consensus algorithm to agree on 67 of them and aggregate them into a single BLS signature. 34:18.850 --> 34:24.670 Any 67 parts can be used to create an accumulated or aggregated signature. 34:24.710 --> 34:32.350 However, the resulting signature will not be the same depending on what 67 signatures are aggregated. 34:32.690 --> 34:39.850 It turns out that the private keys that participants use are generated in a particular fashion. 34:39.850 --> 34:47.230 Then no matter what 67 or less signatures are aggregated, the resulting multi-signature will be the same. 34:47.330 --> 34:50.570 This can be used as a source of randomness. 34:50.910 --> 34:54.510 The participants first agree on some message that they will sign. 34:54.510 --> 34:58.470 It could be an output from a rando or it could be the hash of the block. 34:58.470 --> 35:04.190 It really doesn't matter as long as it is different every time and is agreed upon. 35:04.190 --> 35:11.970 So here we are blending both randomness and an agreement to create a multi-signature on it. 35:11.990 --> 35:15.230 But this has some limitations. 35:15.230 --> 35:33.170 The approach as we have seen earlier, even though this is unbiased and unpredictable and is live as long as two by third of the participants are online, though this can be configured to any threshold, while this one by third offline or misbehaving participants can stall the algorithm, 35:33.170 --> 35:37.750 it takes at least two by third participants to cooperate to influence the output. 35:38.530 --> 35:44.390 This is a big overhead when you consider a live blockchain system. 35:44.390 --> 35:48.050 Private keys in the scheme need to be aggregated in a particular fashion. 35:48.050 --> 35:52.270 And this process is known as distributed key generation. 35:52.270 --> 35:56.770 And this is something which is an ongoing area of research. 35:57.050 --> 36:01.790 And there is another interesting approach called ran-share approach. 36:01.790 --> 36:10.050 Ran-share approach is an unbiased and unpredictable protocol which can tolerate up to one by third of actors being malicious. 36:10.050 --> 36:18.010 It is relatively slow and the paper linked also describes two ways to speed it up called ran-hound and ran-herd. 36:18.010 --> 36:22.970 But unlike ran-share, ran-hound and ran-herd are relatively complex. 36:22.970 --> 36:25.990 When you look at the details in the paper, you can understand. 36:25.990 --> 36:33.870 The general problems of ran-share, besides the large number of message exchange, it requires a lot of back and forth communication between the participants. 36:33.950 --> 36:40.170 In fact, O to the O n to n cube messages are required. 36:40.330 --> 36:43.650 So this is kind of a gossip. 36:43.650 --> 36:56.710 While one by third of the meaningful threshold for liveness is only there, it is low for the ability to influence the output. 36:56.710 --> 37:02.550 So the challenge, one is the overhead because of the number of communications required. 37:02.550 --> 37:07.170 And second, the number of live participants required. 37:07.830 --> 37:09.690 So this is the challenge. 37:10.830 --> 37:18.070 The benefit from influencing the output can significantly outweigh the benefit of stalling randomness. 37:18.270 --> 37:20.450 Am I audible now? 37:21.070 --> 37:22.650 Keshav, can you confirm? 37:22.650 --> 37:23.730 Am I audible? 37:27.390 --> 37:29.250 Yes sir, you are audible. 37:29.510 --> 37:30.010 Okay. 37:30.970 --> 37:32.870 So let us continue. 37:32.870 --> 37:39.670 The benefit from influencing the output, this is one trade-off when we consider a randomness design. 37:39.690 --> 37:45.170 So either the adversary can stall the randomness or influence the output. 37:45.170 --> 37:47.730 So this is what we have to see in Rancher approach. 37:47.730 --> 37:56.150 If participants control more than one by third of the participants in Rancher and use this to influence the output, it leaves no trace. 37:56.150 --> 37:57.490 This is a challenge. 37:57.490 --> 38:02.350 Thus, a malicious actor can do it without even ever being revealed. 38:02.370 --> 38:05.290 Stalling a consensus is always visible. 38:05.290 --> 38:12.990 So if somebody stalls a consensus or creates a fork or disrupts the network, this is visible. 38:12.990 --> 38:16.670 But if they influence the output, that leaves no trace. 38:16.670 --> 38:20.330 So that is the two aspects of this challenge. 38:20.630 --> 38:33.810 And then there are situations in which someone controls one by third of the hash power, having a very powerful machine, a SIG miner or some kind of a very powerful staking pool. 38:34.650 --> 38:40.410 So we can't always say that that is an unimaginable or impossible situation. 38:40.410 --> 38:48.750 And hence, this Rancher approach creates some kind of a doubt or uncertainty. 38:49.050 --> 38:55.530 So we should look at the Near Protocol approach in this scenario. 38:55.530 --> 39:11.070 What Near Protocol has done, sharding implementation for Ethereum 2, like a candidate for Ethereum 2, and now they are building the protocols as a separate protocol. 39:11.130 --> 39:13.570 So what happens in Near Protocol? 39:13.570 --> 39:17.090 They have come up with an approach called erasure code. 39:17.090 --> 39:19.510 Let us understand what is this erasure code. 39:19.750 --> 39:26.350 Each participant comes up with their part of the network, split it into 67 parts. 39:26.350 --> 39:36.290 So this erasure code, it is generated to obtain 100 shares such that any 67 are enough to reconstruct the output. 39:37.170 --> 39:44.410 And then they can assign each of the 100 shares to the participants and encode it with the public key of that participant. 39:44.410 --> 39:47.230 Then they can share all the encoded shares. 39:47.370 --> 39:49.850 Participants use some of the consensus. 39:49.850 --> 39:58.390 It could be any Lidl-based protocol like Tendermint to agree on such encoded set extracted from the 67 participants. 39:58.810 --> 40:14.670 Once the consensus is reached, each participant takes the encoded sharing, each of the 67 sets published this way, that is encoded with their public key, then decodes all such share and publishes all such decoded shares at once. 40:14.670 --> 40:29.950 Once at least 67 participants did in the previous step, all agreed upon the sets fully can be decoded and reconstructed, the final number can be obtained as an XOR of the initial part of the participants which came up in the first step. 40:29.950 --> 40:37.330 The idea why this protocol is unbiasable and unpredictable is similar to the rand share and threshold signature approach. 40:37.350 --> 40:51.070 The final output is decided once the consensus is reached, but is not known to anyone until two by third of the participants decrypt shares encrypted with their own public key. 40:51.150 --> 41:06.290 So when we look at all these previous approaches, on one side we can see the verifiable delay functions very solid with the cryptographic technique and threshold signatures also a cryptographic scheme. 41:06.290 --> 41:18.710 We can see that randavo, randshare, and the erasure code from near protocols, these are all specific consensus-based approaches. 41:18.710 --> 41:28.230 So one side we have threshold signatures, verifiable delay functions, other side we have randshare, randhound, and randherd. 41:28.330 --> 41:33.090 Now let us look at verifiable delay functions in detail. 41:34.010 --> 41:36.070 What is an anatomy of a VDF? 41:36.070 --> 41:38.550 A VDF consists of triple of algorithms. 41:38.570 --> 41:41.650 Setup, evaluate, and verify. 41:41.770 --> 41:50.830 A setup takes two parameters, lambda and t, the security parameter lambda and the delay parameter t. 41:51.310 --> 41:58.590 And it generates a public parameter pp which can fix the domain and range of the VDF. 41:58.590 --> 42:03.530 And we can add some additional information necessary to compute or verify it. 42:03.530 --> 42:18.070 The second phase is evaluation phase, where you take the public parameter from the previous phase and an input x from the domain and generate an output value y in the range and generate a short proof pi. 42:18.250 --> 42:30.150 Finally in the verification phase you use the combination of public parameter x y and pi efficiently to verify that y is the correct output on x. 42:30.170 --> 42:35.390 So crucially for every input x there should be unique output of y. 42:35.730 --> 42:58.830 When you look at the historic inspirations to VDF, we should first look at the early works of Cynthia Dwork and Moni Navor in early 1990s, who suggested using squaring roots over finite fields, finite field-based puzzles as functions which take a predetermined time to compute and are very straightforward to verify. 42:58.830 --> 43:09.910 Incidentally the same Cynthia Dwork and Moni Navor has inspired Satoshi Nakamoto in his pioneering work on peer-to-peer cash in Bitcoin. 43:10.110 --> 43:19.050 However their work was considered impractical then because one has to use rather large finite fields to make algorithms useful. 43:19.090 --> 43:26.530 And libraries for handling multiple precision arithmetic at the time of the suggestion was order of magnitude slower than the current ones. 43:26.530 --> 43:35.290 So we can see that even a lot of promises on elliptical curve cryptography which uses finite fields came only in the early 2000s. 43:35.590 --> 43:38.310 What are the essential properties of VDF? 43:38.310 --> 43:41.110 Now we have seen how do we construct a VDF. 43:41.110 --> 43:42.930 What are the essential properties? 43:42.930 --> 43:45.690 Firstly it has to be sequential. 43:45.850 --> 44:06.070 Honest parties can compute y and pi given we have public parameter nx in t sequential steps while no parallel machine adversary with a polynomial number of processors can distinguish the output y from random input significantly in fewer steps. 44:06.070 --> 44:07.690 So this is very important. 44:07.690 --> 44:24.830 The output should be indistinguishable with any other randomness even if the adversary has a polynomial number of processors so that they can compute they can execute all of them in a very efficient polynomial time. 44:24.830 --> 44:33.210 They should not be able to distinguish this output from VDF from other randomness and it should be efficiently verifiable. 44:33.970 --> 44:38.810 The verify operation should be as fast as possible for honest parties to compute. 44:39.010 --> 45:05.410 So the verification time should be as small as polynomial logarithm of the time taken to generate it or construct it and it should be unique as we said before for every input x it should be difficult to find an y for which the same combination of public parameters x y and pi gives the same output. 45:06.410 --> 45:11.430 Now there are some more additional properties of VDF very important for actual implementation. 45:11.550 --> 45:14.510 One of the first one is it should be decodable. 45:14.510 --> 45:24.050 A VDF is decodable if there exists a decoding algorithm such that the combination of evaluate and decode form a lossless encoding scheme. 45:24.050 --> 45:29.050 This is very much required for a practical use of VDF and it should be implemented. 45:29.050 --> 45:31.230 Hi sir, sorry for interrupting. 45:31.850 --> 45:33.090 Yes. 45:33.710 --> 45:40.590 So we can take like 10 more minutes because it's already like just 30. 45:40.590 --> 45:42.030 So yep. 45:42.390 --> 45:43.830 Yeah, I'll move fast. 45:43.830 --> 45:56.270 So the second property is the incremental property which will help us to compute the output with zero knowledge proofs or any recursive proofs and the size should be smaller. 45:56.270 --> 46:11.990 And the main innovations if you look at the main VDF constructions are the first construction is in the original paper by Dan Bone, Ben Fish and others in 2018 which uses injective rational maps. 46:11.990 --> 46:18.830 But however this is a very complex implementation and hence even the author said this is a weak VDF. 46:18.830 --> 46:34.390 Later two other approaches were proposed by Paisarch and other by Veselovsky independently arriving at extremely similar constructions but more practical by using repeated squaring in groups of unknown order. 46:34.390 --> 46:48.590 These constructions are based on modular exponentiation arithmetic where Paisarch and Veselovsky suggested to iteratively compute squarings in RSA groups with a large prime modulus. 46:48.810 --> 46:50.670 Innovations in VDF. 46:50.890 --> 46:57.350 One very crucial difference in VDF with others is VDF has a setup phase. 46:57.350 --> 47:02.990 Within the setup phase we set the public parameters for configuring the VDF. 47:02.990 --> 47:07.510 So any node who need to solve the VDF will use the public parameters. 47:07.570 --> 47:19.530 And some VDF also allow generating a proof so that you can use this in conjunction with the computational proofs of integrity and we can use it in a multi-party computation setup. 47:19.530 --> 47:24.230 Now let us see how we can use VDF for DDoS prevention. 47:24.330 --> 47:30.150 One of the first approach for using VDF for DDoS prevention was from IOTA. 47:30.150 --> 47:44.330 IOTA is a IOT ledger which uses tangled consensus which is not strictly a blockchain but they have come up with a lot of innovations in cryptography in the past like they have adopted windermere's one-time signature. 47:44.330 --> 47:48.770 So what IOTA has implemented is a DDoS prevention mechanism. 47:48.770 --> 47:54.030 IOTA is actually an IOT ledger with heterogeneous IOT devices. 47:54.030 --> 48:07.610 So they propose to use VDF for VDF as a DDoS prevention mechanism where nodes are required to compute exactly the prime modular squarings for an input message. 48:07.710 --> 48:17.270 Calibrating the VDF evaluation on different hardware and optimizing the time need to verify the correctness of the puzzle through multi- exponentiation techniques. 48:17.270 --> 48:18.590 That is what they have done. 48:18.590 --> 48:34.050 So what they have done is they have used different kind of hardware like laptops, FPGAs and different IOT hardwares like Raspberry Pis and different other devices and then they optimize the time. 48:34.050 --> 48:44.270 They continuously calibrated what would be the time for constructing the VDF, evaluating the VDF and verifying the VDF. 48:44.670 --> 48:48.830 So they compared it with for their purpose. 48:48.830 --> 48:53.410 Actually IOTA doesn't have a system like a proof of stake. 48:53.410 --> 49:01.130 Hence their concern was how to use it instead of proof of work and that's how they use VDF. 49:01.130 --> 49:02.490 So how did they use it? 49:02.490 --> 49:19.130 In the evaluation phase, every node decides to generate a transaction and all those nodes need to solve a VDF such that the input is the hash of the transaction issued by the same node and the proof that they generate. 49:19.130 --> 49:25.490 The node also generated proof to facilitate the verification task which gossip along with the transaction. 49:25.490 --> 49:28.910 So they share the proof along with the transaction. 49:29.090 --> 49:32.970 Verification happens when a new transaction is received. 49:32.970 --> 49:41.010 A particular node verifies whether the VDF is solved correctly by the node which sent the transaction. 49:41.010 --> 49:43.490 If yes, it forward the transaction. 49:43.490 --> 49:53.910 In IOTA, it has some kind of tipping mechanism or forward mechanism where every node which receives an input has to send it to two other nodes. 49:53.910 --> 49:56.050 That is how the tangle works. 49:56.050 --> 50:00.450 Let us look at how VDF integration is implemented in IOTA. 50:00.450 --> 50:07.330 There are evaluators and evaluators evaluate and generate the proof from the input to the VDF. 50:07.330 --> 50:20.810 They use both hash and the VDF and then when they generate transaction, transaction nodes will have VDF in it and then the verifier will verify whether the VDF is accurate which they can do it fast. 50:20.810 --> 50:23.250 If it is true, they broadcast to neighbor. 50:23.250 --> 50:25.410 If it is false, they discard it. 50:25.410 --> 50:31.490 We can configure the difficulty and the modulus in this VDF implementation IOTA. 50:31.490 --> 50:34.290 This is an important property which is mentioned. 50:34.290 --> 50:41.550 VDF difficulty can be configured that determines the number of sequential operations to solve and update the VDF. 50:41.550 --> 50:49.990 The second one, the prime modulus, the RSA modulus which we use for the RSA based groups of unknown order. 50:49.990 --> 50:53.370 And the third thing, they also use a cryptographic hash function. 50:54.190 --> 50:57.630 Now let us quickly talk about our approach. 50:57.630 --> 51:16.670 Our approach is based on a closer view at what is required for Ethereum 2.0 and what are the current capabilities we have in 2.0 like sharding, stake and random oracles and also the presence of different proof, zero-knowledge proof implementations. 51:16.670 --> 51:38.310 But one key difference what we would like to propose is, we are proposing VDF based on super-singular isogenic cryptography, not based on the RSA based unknown groups of unknown order approach or adiabatic adaptive root assumption approach of PISTRAC and Wyslawowski. 51:38.310 --> 51:44.150 We also wanted to bring in an approach known as single secret leader selection. 51:44.150 --> 51:53.530 And we want to use this VDF for selecting a secret leader, a single secret leader from data shards each time. 51:53.530 --> 51:57.630 And we also want to use them in conjunction with random oracles. 51:57.630 --> 52:07.690 And we want to authenticate the nodes participating in stake mechanism using VDF based delay authentication, which is also proposed recently. 52:08.470 --> 52:14.110 And then we want to use randomness, ran-share and ran-hound powered beacon chain. 52:14.110 --> 52:16.650 So this is how we visualize our approach. 52:16.650 --> 52:25.550 We use isogeny based VDF generator and these VDF generators will be used to create random oracles. 52:25.790 --> 52:31.870 These random oracles will source to the shard chains with ran-hound and ran-share. 52:31.870 --> 52:36.270 And that's how we decide which shard to move in the proximity. 52:36.270 --> 52:44.210 And then the shards will be part of the beacon chain where we will have a secret single leader selection and delay authentication. 52:44.290 --> 52:50.030 And then finally, which will be added to the main chain based on... 52:50.030 --> 52:52.790 Hi sir, sorry again for interrupting. 52:52.950 --> 52:55.950 Ajit sir is saying we can like conclude our talk. 52:55.950 --> 53:00.230 So we can just quickly wrap up and just talk about the isogeny, right? 53:00.230 --> 53:03.130 Yeah, I'll just quickly show what we have. 53:03.130 --> 53:09.810 We have already done a prototype on this random oracle using the VDF from the software. 53:09.830 --> 53:12.490 You can see the code in our repository. 53:12.570 --> 53:18.330 And we also giving the highlight of the single secret leader selection mechanism. 53:18.330 --> 53:25.190 You can find the research paper which is substantiating this again from Dan Boneh and the node topology. 53:25.190 --> 53:32.830 And please let me hand over to Tejas to talk about the beautiful aspects of isogeny based VDF quickly. 53:33.630 --> 53:35.150 So, hey everyone. 53:35.150 --> 53:40.370 I will just quickly wrap up our presentation and we are just in more finale. 53:40.450 --> 53:44.930 And I will just quickly talk about the isogeny based VDF. 53:44.930 --> 53:47.030 Now, what is an isogeny? 53:47.030 --> 53:53.990 It is based on the idea of elliptic curve cryptography and Diffie-Hellman key exchange. 53:54.090 --> 53:58.010 So in isogeny, there are a group of elliptic curves. 53:58.010 --> 54:01.950 So you can think about that there are two elliptic curves, E1 and E2. 54:02.010 --> 54:12.190 We can do a mapping or a function of like, let's say, point P from elliptic curve E1 to point Q at elliptic curve E2. 54:12.190 --> 54:15.050 And this mapping is called as the isogeny. 54:15.050 --> 54:21.270 Now, our secret here is then the isogeny here and the public key you can think about as the elliptic curve. 54:21.330 --> 54:28.950 And we can do a secret share exchange by mixing our secret key with other side's elliptic curve. 54:29.090 --> 54:30.090 Next slide. 54:31.010 --> 54:32.050 Next. 54:33.750 --> 54:35.370 Next, moving on. 54:37.230 --> 54:40.030 So, yep, let's see a quick construction. 54:40.070 --> 54:53.190 So we'll set up, we'll take prime number n, we'll take a supersingular curve E, and performing a random non-backtracking walk of length t, have as outcome the isogeny phi, and its dual as phi dash. 54:53.190 --> 54:55.090 I call it as phi dash. 54:55.090 --> 55:08.350 Now, choosing a point P, we'll compute the isogeny of the point P, and there will be output as isogeny dual, the elliptic curves E and E dash, the point P, and the isogeny of point P. 55:08.350 --> 55:09.270 Next. 55:11.250 --> 55:16.030 This is how isogeny look like, mapping between two elliptic curves. 55:16.030 --> 55:17.090 Next. 55:18.610 --> 55:26.970 And the final slide, how the evaluation and verification works in an isogeny based medium. 55:26.970 --> 55:38.150 So for the evaluation, if we are receiving a random point Q, we have to compute the isogeny dual of that point Q. 55:38.150 --> 55:47.730 And for the verification part, we will refer to our previous knowledge of the slides, which were field pairings. 55:47.790 --> 56:03.090 So how the verification can be done, just simply a field pairing of the point P with the isogeny dual of the point Q, and that should be equal to the field pairing of isogeny of the point P and the point Q. 56:03.090 --> 56:10.850 So having said that, we are done with our presentation, and I will hand over to Gokul sir to say the final words. 56:11.970 --> 56:40.330 It's a great honor for us to present our compilation of thoughts on applying powerful properties of randomness, unbiased randomness and entropy, for the overall transformation of the consensus and cryptography and to make Ethereum 2.0 much more stronger and make sure that every chance of DDoS attack can be prevented from the sharding, 56:40.330 --> 56:42.930 shard to the main chain itself. 56:42.930 --> 56:46.690 Overall, so this is a randomness engineering that we propose. 56:46.690 --> 56:49.910 We have done our first level of prototype. 56:49.910 --> 56:59.090 We would like to move to the next level by integrating isogeny VDF from the SIDS library and the SS-isogeny library. 56:59.250 --> 57:06.770 And then we would also want to blend single secret leader selection, and we would like to do it on the RANDAO. 57:06.930 --> 57:10.750 We have already participated in the Starkware VDF hackathon. 57:10.750 --> 57:17.410 We have used the VDF from Starkware and built random oracles and applied on RANDAO. 57:17.410 --> 57:20.230 Now we are excited to go forward. 57:20.230 --> 57:25.370 Thank you so much again for Blockchain Village, DEF CON for giving us this opportunity. 57:25.370 --> 57:26.490 It's an honor. 57:26.490 --> 57:29.450 It's a lifetime opportunity for us. 57:29.450 --> 57:30.510 Thank you so much once again. 57:30.510 --> 57:32.550 Looking forward to your questions and comments.