[00:00.000 --> 00:07.240] Hey everyone and welcome to the DEF CON Blockchain Village and we are here to present our talk on [00:07.240 --> 00:14.300] the title Verifiable Delay Functions for Preventing DDoS or TDoS Attacks on Ethereum 2.0. [00:14.620 --> 00:21.340] So this is the agenda for our talk and at the very end of our session if the time allows [00:21.920 --> 00:26.700] we'll try to pick up some of your questions and we'll try to answer as many as possible. [00:27.600 --> 00:34.960] So wrapping up a quick speaker's introduction. So here am I. My name is Tejasura Sogi. I'm a [00:34.960 --> 00:41.000] penetration tester, a blockchain security researcher, founder of RazerSec which is a [00:41.000 --> 00:47.420] community that helps people to learn about blockchain security. I'm also a YouTuber as [00:47.420 --> 00:52.760] RazerSharp. I post security content on YouTube and the most important thing I'm a cybersecurity [00:52.760 --> 01:01.040] enthusiast. I love the world of internet. With that I will ask my partner Mr. Gokul Alex to say [01:01.200 --> 01:10.420] a few words about him. Thank you Tejasura. Hi everyone this is Gokul Alex. It's my pleasure [01:10.420 --> 01:19.360] and privilege to present in this platform in DEF CON in front of every one of you. [01:19.360 --> 01:26.440] I'm the founder of Epic Knowledge Society, one of the fastest growing digital education platform [01:26.440 --> 01:36.820] for engineers and entrepreneurs in India. We are a non-profit organization. I am also building a [01:36.820 --> 01:43.140] blockchain protocol integrating off-chain and on-chain data called Fusion Ledger. I am [01:43.140 --> 01:53.920] representing a collection of cryptocurrencies and platforms in India such as Algorand, Eternity, [01:53.920 --> 02:00.440] Elixir, Hashgraph, Horizon and Tezos. I'm also the director of Tezos India Foundation [02:01.640 --> 02:10.430] and I've been selected as the MVP for Hedera Hashgraph in 2018. I am a global leader for [02:11.150 --> 02:16.410] XS collective created by David Choum known as the godfather of cryptography [02:17.040 --> 02:24.470] and blockchain technology. I am a programmer and poet in my personal life. I've been a blockchain [02:24.470 --> 02:31.570] security auditor for government, public sector and private sector across various countries. I am [02:32.410 --> 02:37.440] actively researching on the convergence of quantum algorithms and post-quantum cryptography. [02:38.400 --> 02:45.100] Over to Tejeshwar to get start with the presentation. Awesome! Now let's just start [02:45.100 --> 02:50.820] our session and before moving to the attack vectors on proof-of-work, let's get a quick [02:50.820 --> 02:59.140] refresher on some of the fundamentals. So let's talk about what is proof-of-work consensus algorithm. [02:59.140 --> 03:04.860] Now before that let's talk about what are consensus algorithm. Now consensus algorithms decide like [03:04.860 --> 03:12.820] who should create the next block and this decision defines the basic fundamental property [03:12.820 --> 03:18.360] of blockchain which is decentralization and decentralized control of power. Now [03:19.340 --> 03:25.440] consensus algorithms is all about building fault-tolerant, fault-resilient machines for [03:25.440 --> 03:32.600] distributive computing. Now our talk is about the convergence of cryptographic schemes and [03:32.600 --> 03:39.460] consensus algorithms. Now consensus algorithms have both deterministic and probabilistic [03:39.460 --> 03:48.160] dimensions right. Now consensus algorithms helps us to achieve a consistent state and agreement [03:48.160 --> 03:54.300] between participating nodes in a blockchain network. Getting back to our proof-of-work [03:54.300 --> 04:00.420] consensus algorithm. Now in proof-of-work consensus algorithm there are miners who [04:00.420 --> 04:07.100] compete with each other for the potential valid block creation right. [04:07.600 --> 04:15.880] Now there are certain factors involved like that the block header must be less than a set threshold [04:15.880 --> 04:23.160] and then there is a mining difficulty. Now mining difficulty defines like the current computational [04:23.940 --> 04:28.960] power of the blockchain network and it can also be updated at regular intervals [04:28.960 --> 04:36.680] to match the current computational power of the network and it also ensures that the block [04:36.680 --> 04:43.660] creation should happen at a certain frequency. Now let's move on to some of the attack vectors [04:43.660 --> 04:50.160] or proof-of-work. Now in front of your screen you can see some of the attacks or attack vectors given [04:51.160 --> 04:58.100] like the first one which says denial of service or distributed denial of service. Now let's talk [04:58.100 --> 05:05.020] over this attack. Now as we have just discussed about the mining difficulty [05:06.000 --> 05:11.280] which defines the processing power of the network and can be updated at regular intervals [05:11.280 --> 05:18.820] to match the to reflect the changes right in the processing power. Now in most of the [05:18.820 --> 05:27.360] blockchain these sudden changes in the processing power are not addressed by the nodes. They can be [05:27.360 --> 05:37.060] addressed by the nodes at a scheduled update. Now let's take a scenario. Let's take a scenario of [05:37.060 --> 05:43.660] like there are nine machines on a blockchain network and six of them are malicious actors. [05:43.660 --> 05:49.180] Six of them are malicious actors. Now they are not doing anything and just chilling in the network. [05:49.180 --> 05:55.700] Everything is going as planned. Mining difficulty is working as the way it should. Block creation [05:55.700 --> 06:02.340] is happening at a certain frequency and everything is perfect. Now suddenly what the malicious [06:02.340 --> 06:09.620] actors decide they decide to turn their machines down. Now what will be the impact of this that [06:10.260 --> 06:17.060] now the remaining three machines they have to do the work of nine machines and what will happen or [06:17.060 --> 06:24.980] what will be the impact of this that the hash rate will decrease and it will decrease the block [06:24.980 --> 06:32.940] creation rate and eventually create a denial of service. So there are other attacks as well [06:32.940 --> 06:39.060] like routing attack. So routing attack consists of two parts. First one is the partition attack [06:39.060 --> 06:46.260] which divides the blockchain network into two groups and then there is a delay attack which [06:46.260 --> 06:53.920] tampers the propagating messages and sends them to the network. Moving on and there are [06:53.920 --> 07:01.340] user wallet attacks. Then there are smart contract attacks, transaction verification mechanism [07:01.340 --> 07:08.720] attacks and there you can see the well-known 51% of majority attack. Now what is this 51% [07:08.720 --> 07:16.380] of majority attack. Now let's take example like there is a group which is in majority [07:16.760 --> 07:24.600] a group of malicious actors which is in majority and they can take control over the [07:24.600 --> 07:32.580] blockchain network. Now how it can be possible as we know that there is a race between miners [07:32.580 --> 07:39.980] for the potential valid block creation. Now if there is a group of malicious actors [07:40.540 --> 07:50.320] which is in majority. Now it will have this group will have a higher and better probability [07:51.010 --> 08:02.820] to be for the block creation. So this is the 51% attack. Moving on there are some mining pool [08:02.820 --> 08:11.140] attacks like selfish mining, forecaster, withhold and like that. So moving on let's talk over DDoS [08:11.140 --> 08:20.300] on ethereum. Now there are some attacks that happened on ethereum or there are scenarios as [08:20.300 --> 08:27.820] well. So we'll pick up some of them like there was an attack on parity client. So what was the [08:27.820 --> 08:33.640] incident like some parity ethereum nodes lost sync with the network because of the following [08:33.640 --> 08:40.880] incident. Now what was the incident that if you send to a parity node a block with invalid [08:40.880 --> 08:47.820] transaction what will happen. If you send a parity node a block with invalid transaction but with [08:47.820 --> 08:55.180] valid header borrowed from another block and what will happen that the node will mark the block [08:55.180 --> 09:02.160] header as invalid and ban the block header forever but the header is still valid right. [09:03.220 --> 09:11.200] Moving on there was a vulnerability that was found in parity nodes as well. So in may global [09:11.200 --> 09:17.440] hacking research collective sr labs claimed that only two thirds of the ethereum client software [09:17.440 --> 09:23.480] that ran on ethereum nodes had been patched against a critical security flaw discovered [09:23.480 --> 09:31.100] earlier this year. The data reportedly indicated that unpatched parity nodes comprised 15% of all [09:31.100 --> 09:38.240] the scanned nodes implying that 15% of all the ethereum nodes were vulnerable to a potential 51% [09:38.240 --> 09:47.380] attack. So moving on and there is an interesting underpriced DDoS attacks. Now these are a group [09:47.380 --> 09:56.880] of attacks which exploited the vulnerability in the improper cast cost of EVM's opcodes. Now the [09:56.880 --> 10:04.760] opcodes were the ext code size and the suicide opcode. The suicide opcode was renamed to self [10:04.760 --> 10:11.860] destruct after eip6. We'll talk about that in the next slide. So let's just take the ext code size [10:12.660 --> 10:21.180] Now prior to eip150 hard fork, the ext code size opcode only charged 20 gas for reading a [10:21.180 --> 10:27.920] contract byte code from disk and then deriving its length. Now as a consequence what happened [10:27.920 --> 10:34.800] or what can happen if the attacker sent transactions to invoke a deployed smart contract [10:34.800 --> 10:41.700] with many ext code size opcodes, it can cause a two to three times slower block creation rate. [10:42.780 --> 10:50.860] Also there was a similar attack that exploited the vulnerability in the proper cast cost of [10:50.860 --> 11:00.300] EVM's suicide opcode that was renamed to self destruct as I just said and also the empty code [11:00.300 --> 11:07.460] vulnerability in the state drive. So the opcode is meant to remove a deployed smart contract [11:07.460 --> 11:13.880] right and then send the remaining ether back to the account designated by the caller. [11:14.580 --> 11:20.500] Now if the target doesn't exist a new account is created even though no ether may be transferred [11:20.500 --> 11:30.860] but still a new account is created. Now what can happen like the attacker can create empty accounts [11:30.860 --> 11:39.000] and that was or that happened like that the attacker created 19 million new empty accounts [11:39.000 --> 11:46.560] by the opcode at a very minimal gas consumption and which wasted disk space and increased [11:46.560 --> 11:56.120] synchronization and processing time and caused a kind of denial of service right. Moving on to [11:56.120 --> 12:06.800] uh attack uh the attackers took advantage of the enterprise tdos attack and that happened [12:06.800 --> 12:12.740] between the blocks mentioned in front of your screen. Now what was the impact? It created [12:12.740 --> 12:21.860] millions of dead ethereum accounts and also bloated the state database. Now it also created [12:21.860 --> 12:30.000] tons of transaction freezes as well. Moving on to the impact of ddos attacks uh the enterprise one [12:30.760 --> 12:38.180] and what was the impact that that can be hacks against goethereum client. Hacks can be created [12:38.180 --> 12:44.260] against huge amount of cleanup transactions and each cleanup transaction creates large set of [12:44.260 --> 12:50.960] freezes. There may be a possibility of hard fork being created and even if the hard fork is created [12:50.960 --> 12:58.300] hard forks do not remove the dead accounts right. Moving on to some of the quick fixes to [12:58.300 --> 13:05.500] the attacks like scanning an initial set of transaction can be done measuring the traces [13:05.500 --> 13:10.140] from each transaction and also checking the frequency of traces in the transactions. [13:11.880 --> 13:18.520] Moving on to let's talk about the attack vectors on proof of stake. Now before covering the attack [13:18.520 --> 13:24.760] vectors let's do a quick refresher again on the proof of stake consensus algorithm. [13:25.300 --> 13:31.000] Now proof of stake is a popular alternative to proof of work. In proof of stake there are [13:31.000 --> 13:38.560] validators instead of miners and a validator is selected to forge a block. Also the validator [13:38.560 --> 13:47.100] selection depends upon the amount of cryptocurrency a validator has or the amount of stake a validator [13:47.100 --> 13:55.380] has and also on the current complexity of the network. And proof of stake has many advantages [13:55.380 --> 14:02.620] over proof of work. The first is obviously the security. It provides a better security mechanism [14:02.620 --> 14:12.980] against 51% attack. Now as we know like in proof of work owning 51% of the computational power [14:12.980 --> 14:19.040] meaning means like gaining control over of the network. But in proof of stake [14:20.300 --> 14:31.040] owning 51% of the stakes would be very would be computationally very expensive for an attacker. [14:31.040 --> 14:38.580] So that's how it provides a better security. Also it provides better it's energy efficient [14:38.580 --> 14:48.460] and provides energy savings. Now also as the ethereum 2.0 is ethereum is transitioning [14:49.060 --> 14:55.300] from ethereum 1 to ethereum 2.0 and it is transitioning from proof of work to proof of [14:55.300 --> 15:02.380] stake. And there is a casper protocol based on proof of stake. It provides its own security [15:02.380 --> 15:11.080] implications like this slashing mechanism which provides slashing of stakes as a penalty [15:11.080 --> 15:21.780] to the validator. Now if a validator validates a block it has been awarded but if found that [15:21.780 --> 15:28.900] the validator is involved in malicious activity the stakes will be slashed as a penalty and there [15:28.900 --> 15:37.660] might be a chance as well that it can lose its privileges to take part in the network consensus. [15:39.280 --> 15:48.140] So this was casper protocol. Moving on to let's see some of the attack vectors attacks against [15:48.140 --> 15:55.800] proof of stake. You can see a list of attacks in front of the screen. There is a fake stake attack [15:56.040 --> 16:02.700] a very interesting attack. Now fake stake attack can be think about as a denial of service. An [16:02.700 --> 16:12.800] attacker can devote a node's valuable memory and cpu to a fake chain. Now we know there is a [16:12.800 --> 16:20.060] longest chain rule that any chain can suddenly become the accepted version of the ledger. [16:20.580 --> 16:29.700] Now validation of a proof in proof of stake is kind of complex. Now it required [16:29.700 --> 16:39.060] access to both the block header as well as the contents of block. So like to trigger the stake [16:39.060 --> 16:46.860] value for the validator selection right and forcing the node to download data to validate [16:46.860 --> 16:55.640] fake blocks. It consumes valuable resources for the node and can eventually result into a denial [16:55.640 --> 17:03.500] of service. 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:31.840] And then you can see a little bit detailed architecture. Like there is a main chain [17:31.840 --> 17:38.460] based on proof of work. Then there is a beacon chain based on the casper ffg protocol, [17:38.460 --> 17:45.200] proof of stake protocol that we just discussed. And random number generation happens. Now you [17:45.200 --> 17:51.640] can see that the beacon chain is cross-linked with the shard chain and underneath there is [17:51.640 --> 18:00.040] execution engine as well. Moving on to see some of the 3m 2.0 audit findings. Talking about the [18:00.040 --> 18:10.560] Constem audit first. Now Constem did an audit as well and founded some DDoS attack vectors, [18:10.560 --> 18:17.080] attack vectors and reported them. Like DDoS attack through creating a mapping between [18:17.680 --> 18:25.480] public keys and validator IPs. Also DDoS attack on insecure gRPC connection. [18:26.440 --> 18:33.280] So what was the Constem audit? Basically it involved 10 engineers who examined the entire [18:33.280 --> 18:39.840] code base over the course of two months. They examined the beacon node logic, [18:39.840 --> 18:44.300] validator client, flasher logic and almost everything. [18:46.570 --> 18:52.750] So what were the findings? They found a lot of vulnerabilities. Some of them are like [18:52.750 --> 18:58.650] granularity of timestamps, pseudo random number generation where two random number [18:58.650 --> 19:04.990] generation were needed and then a second pre-made attack on merkle trees as well. [19:05.630 --> 19:13.250] Now let's talk about the least authority audit as well. So they did an audit over various subsections [19:13.250 --> 19:21.210] like they did a audit over block proposal system. What were the findings? Like a single secret leader [19:21.210 --> 19:27.170] election SSLE keeps a selection secret and stops the leak of information to an observer [19:27.170 --> 19:33.750] while still allowing the chosen block proposer a fast way to verify to others that it is in fact [19:33.750 --> 19:41.290] the proposer. 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:54.090] We're talking about the findings on a gossip protocol. Now gossip protocols generally suffer [19:54.090 --> 19:59.390] from the spam problem. Without a centralized judge, it can be difficult to understand [19:59.390 --> 20:05.290] whether a message is legitimate or is spam that is meant to clog a network. [20:05.630 --> 20:11.610] This was one of the primary concerns in examining the network layer. In Ethereum 2.0, [20:11.610 --> 20:17.750] when a node proposes a new finalized block, the block must be sent to the rest of the network. [20:18.290 --> 20:25.350] There is an issue when a dishonest node is capable of sending an unlimited amount of [20:25.350 --> 20:30.270] older block messages to the rest of the network with minimal penalty [20:31.790 --> 20:38.950] which allows them to overwhelm the network and block legitimate messages. [20:39.030 --> 20:45.030] Also, there were findings on slashing messages that we just discussed earlier, the Casper [20:45.030 --> 20:51.710] protocol security implication. Now there is a small loophole as well that allowed a node to [20:51.710 --> 20:58.250] send an unlimited amount of these types of messages with minimal penalty causing the same message [20:58.250 --> 21:07.630] blocking if they send enough of them. Now moving on to talk about DDoS on Ethereum 2.0. Let's take [21:07.630 --> 21:15.710] the recently happened Teku attack scenario. Now there were security engineers who [21:16.750 --> 21:23.230] did research over public antagonists. They found a Teku attack, created a Teku attack. [21:23.230 --> 21:29.250] Now what was the scenario like? Two of the four Teku nodes were targeted by five ordinary machines [21:29.250 --> 21:36.610] with a sustained DDoS attack. Now what was the impact? That initial loss of finality was achieved [21:36.610 --> 21:43.950] with two or three machines but the others joined with a few epochs to ensure that the network could [21:43.950 --> 21:52.990] not recover. Now what was the implementation? You can see a command in front of your screen. [21:53.470 --> 22:02.210] So what the command does, it pipes the null byte from Dave's view to the pb command which rate [22:02.210 --> 22:12.890] limits to a somewhat arbitrary value high enough to prevent finality. But stay off AWS and IPS [22:12.890 --> 22:22.270] radars to ensure the attack continuous. Also the data is then piped back into the netcat command [22:22.270 --> 22:30.750] which sends it to the nodes under attack. The while loop is there for when it loses connectivity [22:31.450 --> 22:34.670] and command compiles due to container restarts. [22:36.050 --> 22:41.650] And moving on to what was the impact of this Teku attack. The effect that the denial of service [22:41.650 --> 22:48.690] attack had on the attack net was a prolonged loss finality and required manual intervention [22:48.690 --> 22:55.330] to restore the network to a healthy state once the attack stopped. Now the nodes under attack [22:55.330 --> 23:00.730] used large amounts of memory while subject to multiple container restarts. Had trouble [23:00.730 --> 23:07.850] staying connected to peers and even once nodes local clock was like 20 minutes slow. [23:08.890 --> 23:14.890] Moving on to the Teku attack root cause. Now firstly responding to one byte when multiple [23:14.890 --> 23:20.170] bytes is a vector. We know for various amplification attacks that we know. But [23:20.170 --> 23:25.310] that was not the issue that caused the loss of finality. The second issue is that [23:25.310 --> 23:31.290] responses were being written faster than they were read by the attacking peer and the JVM [23:31.290 --> 23:37.950] libp2b was not applying any throttling. Eventually the TCP backpressure kicked in, [23:37.950 --> 23:43.800] 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:01.550] All those due to processing all those multi-stream messages but mostly because of the resultant [24:01.550 --> 24:09.890] memory pressure and GC activity. Now talking about what can be a solution. It's like there [24:09.890 --> 24:16.490] can be a straightforward solution like disconnect the peer immediately when an invalid example like [24:17.050 --> 24:23.110] multistream message is received. And now also there's a resilience to dot attack as well [24:23.670 --> 24:29.610] which increases significantly as increases the number of nodes and diversity of clients, [24:29.610 --> 24:36.430] locations and network connections. So this was the takeover attack. We covered [24:37.130 --> 24:43.270] consensus algorithms. We talked over proof-of-work, proof-of-stake. We took [24:43.270 --> 24:50.270] different attacks, attack vectors as well. We talked over 51% attack, denial of service. We [24:50.270 --> 24:57.290] have seen the ATM 2.0 architecture. Also the security implications of cash flow protocol. [24:57.290 --> 25:05.710] Now my partner Mr. Gopal Alex will connect with you all the links, the PDF, randomness and DDoS [25:05.710 --> 25:11.290] and will connect all of them and present it to you. 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:28.650] We will see how randomness is very crucial to the overall engineering and overall design of [25:28.650 --> 25:35.950] Ethereum 2.0. If you look at all the current implementations, be it on near protocol, [25:35.950 --> 25:42.010] prismatic labs, the beacon chain, there is a crucial play for randomness because all the [25:42.010 --> 25:47.950] sharding designs today rely on some source of randomness to assign validators to the shard. [25:48.670 --> 25:55.910] Both the randomness and the validator assignment require computation that is not specific to any [25:55.910 --> 26:03.310] shard. For this computation, existing designs have a separate blockchain that is tasked with [26:03.310 --> 26:10.210] performing operations necessary for maintenance of the entire network. Besides generating these [26:10.210 --> 26:15.910] random numbers and assigning validators to the shards, these operations also include receiving [26:15.910 --> 26:25.310] updates from shards and taking snapshot of them. This is very important. The shards and taking [26:25.310 --> 26:30.790] activity. In older times, we used to take additions, cut additions from the databases. [26:30.870 --> 26:36.470] The snapshots are the read-only versions. And also when we process the stakes and slashing [26:36.470 --> 26:43.050] in proof-of-stake systems, and when you have to plan the proximity of shard with the leaders [26:43.050 --> 26:49.790] and rebalancing the shard, these randomness... so sharding, staking, and randomness have to [26:49.790 --> 26:56.270] work together. When you look at all these implementations, whether it's Cosmos Hub in [26:56.270 --> 27:02.890] Cosmos, or RelayChain in Polkadot, or BeaconChain in Ethereum and Near, this is the overall [27:02.890 --> 27:11.110] architecture. But we have to understand, we cannot afford any simple randomness. We need distributed [27:11.110 --> 27:17.590] randomness on blockchain. That is why randomness in blockchain becomes much more complex and more [27:17.590 --> 27:24.370] challenging. So many blockchains, if you know, blockchains have different purpose of using [27:24.370 --> 27:31.290] randomness. Maybe it's for time stamping, or it could be for games like lottery games, or it could [27:31.290 --> 27:39.930] be for proof of replication, like in Filecoin, or in the case of Ethereum, BeaconChain for selecting [27:39.930 --> 27:46.490] participants. What happens if a malicious actor can influence such a source of randomness? They [27:46.490 --> 27:53.210] can increase the chance of being selected and possibly compromise the security of the protocol. [27:54.670 --> 27:59.930] And like we said, distributed randomness is very crucial building block for any kind of [27:59.930 --> 28:05.630] applications on blockchain. What are the essential properties of randomness required [28:05.630 --> 28:12.450] in a blockchain setup? There are three essential properties laid out. First, it needs to be [28:12.450 --> 28:19.130] unbiased. We cannot afford a biased source of entropy. In other words, no participant shall be [28:19.130 --> 28:24.270] able to influence in any way the outcome of the random generator. Second, it needs to be [28:24.270 --> 28:29.730] unpredictable. In other words, no participant shall be able to predict what number will be generated, [28:29.730 --> 28:34.970] or what are the properties of it. Thirdly, the protocol needs to tolerate some percentage of [28:34.970 --> 28:40.210] actors that go offline or try to intentionally stall the protocol, like the conventional [28:40.210 --> 28:45.550] crash fault tolerance and Byzantine fault tolerance. Now we will look at some of the [28:45.550 --> 28:51.870] existing approaches. One of the first approaches is the RANDAO approach, which is the acronym for [28:51.870 --> 28:56.910] Random DAO. The general idea is that the participants in the network, first of all, [28:56.910 --> 29:03.010] privately choose a pseudo random number. Submit a commitment to the privately chosen number. This [29:03.010 --> 29:08.910] commitment could be implemented as a polynomial commitment or a Pedersen commitment. All agree [29:08.910 --> 29:15.110] on some sort of commitment using a consensus algorithm. Then all reveal the chosen numbers, [29:15.110 --> 29:21.390] reach a consensus on the revealed numbers, and have the XOR of the revealed numbers to be the [29:21.390 --> 29:26.210] output of the protocol. This is a pretty straightforward approach, but there are [29:26.210 --> 29:35.910] some limitations. It is fairly unpredictable, and it has liveness. We know liveness and safety are [29:35.910 --> 29:42.770] two required properties of any consensus mechanism. This provides a great degree of liveness. [29:42.830 --> 29:50.990] However, a malicious actor can observe the network once and start to reveal the numbers and choose [29:50.990 --> 29:58.130] to reveal or not reveal the number based on the XOR of the number they observed. This allows a [29:58.130 --> 30:04.250] single malicious actor to have one bit of influence on the output, and a malicious actor controlling [30:04.250 --> 30:09.050] multiple participants have as many bits of influence as the number of participants they [30:09.050 --> 30:17.490] are controlling. So there is a proposal, and there is a strong support in this direction, [30:17.490 --> 30:24.170] which is to blend RANDAO plus VDF. We will talk about VDF in detail. First, let us understand [30:24.170 --> 30:30.750] this approach. To make RANDAO unbiasable, one approach would be to make the output not just [30:30.750 --> 30:36.170] an XOR, but something that takes more time to execute than the allocated time to reveal the [30:36.170 --> 30:41.570] numbers. If the computation of the final output takes longer than the revealed phase, the malicious [30:41.570 --> 30:48.850] actor cannot predict the effect of them revealing or not revealing the number. So we are talking [30:48.850 --> 30:55.210] about a computation which is sequential, which cannot be paralyzed by a powerful malicious [30:55.210 --> 31:01.730] adversary. Such a function that takes a long time to compute is fast to verify the computation, [31:01.730 --> 31:07.350] and has a unique output for each input. It is called as verifiable delay functions, [31:07.350 --> 31:13.470] and the design is extremely complex, which we will talk in detail. What is Ethereum's perspective [31:13.470 --> 31:19.230] on RANDAO plus VDF? You can find numerous conversations on this in Ethereum research [31:19.230 --> 31:26.250] led by Justin Drake and others. Ethereum presents a plan to use RANDAO with VDF as their randomness [31:26.250 --> 31:32.170] beacon. Besides that fact, this approach is unpredictable and unbiasable. It has an extra [31:32.170 --> 31:37.410] advantage that it has liveness, even if only two participants are online. This is a very [31:37.410 --> 31:44.770] interesting property. It requires very, very less live participants compared to any other approach. [31:44.770 --> 31:51.870] For the family of VDF linked above a special ASIC, it can be 100 times faster than conventional [31:51.870 --> 31:58.310] hardware. That is why there is a strong effort and investment in Ethereum currently to build ASIC [31:58.850 --> 32:04.950] hardware for VDFs. So if the reveal phase lasts only 10 seconds, for example, [32:04.950 --> 32:12.210] VDF computed on such an ASIC must take longer than 100 seconds to have 10x safety. And [32:12.210 --> 32:18.790] does the same VDF computed on the conventional hardware need to take 100x 100 seconds in three [32:18.790 --> 32:25.990] hours? Hence, there comes a dependency on hardware. That is the challenge because of this approach or [32:25.990 --> 32:32.450] the trade-off in this approach. Now let us look at an early approach which is fairly [32:33.650 --> 32:40.810] very popular. This approach is pioneered by DFINITY. In fact, more than one year back or [32:40.810 --> 32:47.690] two years back, DFINITY used BLS signature. What is BLS signature? It is known as Bonnet [32:47.690 --> 32:54.070] Line Shazam Signature. One of the authors of this cryptographic scheme, [32:54.070 --> 33:00.550] Ben Lin, is actually a member of DFINITY. What is this BLS signature? This is a scheme allowing [33:00.750 --> 33:07.850] a user to verify that a signer is authentic. This scheme uses a bilinear pairing for verification. [33:07.850 --> 33:13.410] We know about bilinear maps in elliptical cryptography, how powerful and formidable [33:13.410 --> 33:19.730] they are. So this is a signature scheme built using bilinear pairings. BLS signature is a [33:19.730 --> 33:26.190] construction which allows multiple parties to create a single signature on a message which [33:26.190 --> 33:32.510] is often used to save the space and bandwidth by not requiring sending around multiple signatures. [33:32.510 --> 33:39.070] This is a very interesting property and hence BLS signatures are becoming very popular [33:39.070 --> 33:47.150] in more cryptocurrencies and blockchains. A common usage of BLS signatures is in signing [33:47.150 --> 33:55.590] BFT protocols, for signing blocks in BFT protocol. When we look at threshold signatures in practice, [33:56.230 --> 34:01.370] say there are 100 participants to create blocks and a block is considered final if [34:02.030 --> 34:08.750] two by third of them, 67 of them sign on it. They can all submit the parts of the BLS signature [34:09.630 --> 34:16.790] and then use some consensus algorithm to agree on 67 of them and aggregate them into a single [34:16.790 --> 34:24.670] BLS signature. Any 67 parts can be used to create an accumulated or aggregated signature. [34:24.710 --> 34:31.050] However, the resulting signature will not be the same depending on what 67 signatures are [34:31.050 --> 34:38.910] aggregated. It turns out that the private keys that participants use are generated in a particular [34:38.910 --> 34:46.150] fashion. Then no matter what 67 or less signatures are aggregated, the resulting multi-signature will [34:46.150 --> 34:52.670] be the same. This can be used as a source of randomness. The participants first agree on [34:52.670 --> 34:57.890] some message that they will sign. It could be an output from a rando or it could be the hash of the [34:57.890 --> 35:04.890] block. It really doesn't matter as long as it is different every time and is agreed upon. So here [35:04.890 --> 35:13.070] we are blending both randomness and an agreement to create a multi-signature on it. But this has [35:13.730 --> 35:19.890] some limitations. The approach as we have seen earlier, even though this is unbiased and [35:19.890 --> 35:25.130] unpredictable and is live as long as two by third of the participants are online, though this can [35:25.130 --> 35:31.610] be configured to any threshold, while this one by third offline or misbehaving participants can [35:31.610 --> 35:37.750] stall the algorithm, it takes at least two by third participants to cooperate to influence the output. [35:38.530 --> 35:45.310] This is a big overhead when you consider a live blockchain system. Private keys in the [35:45.310 --> 35:50.730] scheme need to be aggregated in a particular fashion. And this process is known as distributed [35:50.730 --> 35:57.990] key generation. And this is something which is an ongoing area of research. And there is another [35:57.990 --> 36:04.770] interesting approach called ran-share approach. Ran-share approach is an unbiased and unpredictable [36:04.770 --> 36:11.290] protocol which can tolerate up to one by third of actors being malicious. It is relatively slow [36:11.290 --> 36:18.010] and the paper linked also describes two ways to speed it up called ran-hound and ran-herd. [36:18.010 --> 36:23.910] But unlike ran-share, ran-hound and ran-herd are relatively complex. When you look at the [36:23.910 --> 36:28.770] details in the paper, you can understand. The general problems of ran-share, besides the large [36:28.770 --> 36:33.870] number of message exchange, it requires a lot of back and forth communication between the participants. [36:33.950 --> 36:43.650] In fact, O to the O n to n cube messages are required. So this is kind of a gossip. [36:43.650 --> 36:54.030] While one by third of the meaningful threshold for liveness is only there, it is low for the [36:54.030 --> 37:01.050] ability to influence the output. So the challenge, one is the overhead because of the number of [37:01.050 --> 37:07.170] communications required. And second, the number of live participants required. [37:07.830 --> 37:14.430] So this is the challenge. The benefit from influencing the output can [37:14.430 --> 37:20.450] significantly outweigh the benefit of stalling randomness. Am I audible now? [37:21.070 --> 37:32.870] Keshav, can you confirm? Am I audible? Yes sir, you are audible. Okay. 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:46.050] So either the adversary can stall the randomness or influence the output. So this is what we have [37:46.050 --> 37:51.330] to see in Rancher approach. If participants control more than one by third of the participants [37:51.930 --> 37:57.490] in Rancher and use this to influence the output, it leaves no trace. This is a challenge. [37:57.490 --> 38:03.310] Thus, a malicious actor can do it without even ever being revealed. Stalling a consensus [38:03.950 --> 38:11.610] is always visible. So if somebody stalls a consensus or creates a fork or disrupts the [38:11.610 --> 38:17.130] network, this is visible. But if they influence the output, that leaves no trace. So that is [38:17.130 --> 38:25.190] the two aspects of this challenge. And then there are situations in which someone controls one by [38:25.190 --> 38:31.790] third of the hash power, having a very powerful machine, a SIG miner or some kind of a very [38:31.790 --> 38:40.410] powerful staking pool. 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 --> 39:00.310] So we should look at the Near Protocol approach in this scenario. What Near Protocol has done, [39:00.310 --> 39:06.890] sharding implementation for Ethereum 2, like a candidate for Ethereum 2, and now they are [39:06.890 --> 39:13.570] building the protocols as a separate protocol. So what happens in Near Protocol? [39:13.570 --> 39:19.510] They have come up with an approach called erasure code. Let us understand what is this erasure code. [39:19.750 --> 39:26.770] Each participant comes up with their part of the network, split it into 67 parts. So this [39:26.770 --> 39:34.650] erasure code, it is generated to obtain 100 shares such that any 67 are enough to reconstruct [39:34.650 --> 39:41.450] the output. And then they can assign each of the 100 shares to the participants and encode it with [39:41.450 --> 39:48.710] the public key of that participant. Then they can share all the encoded shares. Participants use [39:48.710 --> 39:54.070] some of the consensus. It could be any Lidl-based protocol like Tendermint to agree on such encoded [39:54.070 --> 40:02.470] set extracted from the 67 participants. Once the consensus is reached, each participant takes the [40:02.470 --> 40:09.590] encoded sharing, each of the 67 sets published this way, that is encoded with their public key, [40:09.590 --> 40:16.890] then decodes all such share and publishes all such decoded shares at once. Once at least 67 [40:16.890 --> 40:23.470] participants did in the previous step, all agreed upon the sets fully can be decoded and reconstructed, [40:23.470 --> 40:27.430] the final number can be obtained as an XOR of the initial part of the participants [40:27.930 --> 40:32.950] which came up in the first step. The idea why this protocol is unbiasable and unpredictable [40:33.390 --> 40:39.510] is similar to the rand share and threshold signature approach. The final output is decided [40:39.510 --> 40:45.910] once the consensus is reached, but is not known to anyone until two by third of the participants [40:45.910 --> 40:54.670] decrypt shares encrypted with their own public key. So when we look at all these previous approaches, [40:54.670 --> 41:01.770] on one side we can see the verifiable delay functions very solid with the cryptographic [41:01.770 --> 41:08.570] technique and threshold signatures also a cryptographic scheme. We can see that randavo, [41:08.570 --> 41:17.550] randshare, and the erasure code from near protocols, these are all specific consensus-based [41:17.550 --> 41:24.190] approaches. So one side we have threshold signatures, verifiable delay functions, other side [41:24.190 --> 41:33.090] we have randshare, randhound, and randherd. Now let us look at verifiable delay functions in detail. [41:34.010 --> 41:38.550] What is an anatomy of a VDF? A VDF consists of triple of algorithms. [41:38.570 --> 41:46.590] Setup, evaluate, and verify. A setup takes two parameters, lambda and t, [41:46.590 --> 41:54.910] the security parameter lambda and the delay parameter t. And it generates a public parameter pp [41:55.710 --> 42:01.450] which can fix the domain and range of the VDF. And we can add some additional information necessary [42:01.450 --> 42:07.490] to compute or verify it. The second phase is evaluation phase, where you take the public [42:07.490 --> 42:13.530] parameter from the previous phase and an input x from the domain and generate an output value y [42:13.530 --> 42:22.230] in the range and generate a short proof pi. Finally in the verification phase you use the [42:22.230 --> 42:28.770] combination of public parameter x y and pi efficiently to verify that y is the correct [42:28.770 --> 42:36.810] output on x. So crucially for every input x there should be unique output of y. When you look at the [42:36.810 --> 42:44.290] historic inspirations to VDF, we should first look at the early works of Cynthia Dwork and Moni Navor [42:44.610 --> 42:51.970] in early 1990s, who suggested using squaring roots over finite fields, finite field-based [42:51.970 --> 42:57.710] puzzles as functions which take a predetermined time to compute and are very straightforward to [42:57.710 --> 43:05.590] verify. Incidentally the same Cynthia Dwork and Moni Navor has inspired Satoshi Nakamoto [43:05.590 --> 43:11.970] in his pioneering work on peer-to-peer cash in Bitcoin. However their work was considered [43:11.970 --> 43:19.050] impractical then because one has to use rather large finite fields to make algorithms useful. [43:19.090 --> 43:23.350] And libraries for handling multiple precision arithmetic at the time of the suggestion was [43:23.350 --> 43:29.210] order of magnitude slower than the current ones. So we can see that even a lot of promises [43:29.210 --> 43:35.290] on elliptical curve cryptography which uses finite fields came only in the early 2000s. [43:35.590 --> 43:41.110] What are the essential properties of VDF? Now we have seen how do we construct a VDF. [43:41.110 --> 43:46.950] What are the essential properties? Firstly it has to be sequential. Honest parties can compute [43:46.950 --> 43:55.910] y and pi given we have public parameter nx in t sequential steps while no parallel machine [43:55.910 --> 44:00.130] adversary with a polynomial number of processors can distinguish the output [44:01.030 --> 44:07.690] y from random input significantly in fewer steps. So this is very important. [44:07.690 --> 44:15.310] The output should be indistinguishable with any other randomness even if the adversary has [44:15.990 --> 44:21.730] a polynomial number of processors so that they can compute they can execute all of them [44:22.190 --> 44:27.090] in a very efficient polynomial time. They should not be able to distinguish this [44:27.090 --> 44:33.210] 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 --> 44:46.350] So the verification time should be as small as polynomial logarithm of the time taken to [44:46.350 --> 44:53.730] generate it or construct it and it should be unique as we said before for every input x [44:53.730 --> 45:01.030] it should be difficult to find an y for which the same combination of public parameters [45:01.030 --> 45:09.330] x y and pi gives the same output. Now there are some more additional properties of VDF very [45:09.330 --> 45:15.190] important for actual implementation. One of the first one is it should be decodable. A VDF is [45:15.190 --> 45:21.470] decodable if there exists a decoding algorithm such that the combination of evaluate and decode [45:21.470 --> 45:27.890] form a lossless encoding scheme. This is very much required for a practical use of VDF and [45:27.890 --> 45:36.890] it should be implemented. Hi sir, sorry for interrupting. Yes. So we can take like 10 [45:36.890 --> 45:44.490] more minutes because it's already like just 30. So yep. Yeah, I'll move fast. So the second [45:44.490 --> 45:51.130] property is the incremental property which will help us to compute the output with zero knowledge [45:51.130 --> 45:58.010] proofs or any recursive proofs and the size should be smaller. And the main innovations if [45:58.010 --> 46:04.690] you look at the main VDF constructions are the first construction is in the original paper by [46:04.690 --> 46:13.850] Dan Bone, Ben Fish and others in 2018 which uses injective rational maps. But however this is a [46:13.850 --> 46:20.710] very complex implementation and hence even the author said this is a weak VDF. Later two other [46:20.710 --> 46:27.750] approaches were proposed by Paisarch and other by Veselovsky independently arriving at extremely [46:27.750 --> 46:34.390] similar constructions but more practical by using repeated squaring in groups of unknown order. [46:34.390 --> 46:39.070] These constructions are based on modular exponentiation arithmetic where Paisarch [46:39.470 --> 46:46.210] and Veselovsky suggested to iteratively compute squarings in RSA groups with a large [46:47.090 --> 46:55.050] prime modulus. Innovations in VDF. One very crucial difference in VDF with others is VDF [46:55.050 --> 47:02.990] has a setup phase. Within the setup phase we set the public parameters for configuring the VDF. [47:02.990 --> 47:09.110] So any node who need to solve the VDF will use the public parameters. And some VDF also allow [47:09.110 --> 47:14.330] generating a proof so that you can use this in conjunction with the computational proofs of [47:14.330 --> 47:21.770] integrity and we can use it in a multi-party computation setup. Now let us see how we can [47:21.770 --> 47:28.730] use VDF for DDoS prevention. One of the first approach for using VDF for DDoS prevention was [47:28.730 --> 47:37.470] from IOTA. IOTA is a IOT ledger which uses tangled consensus which is not strictly a blockchain but [47:37.470 --> 47:42.370] they have come up with a lot of innovations in cryptography in the past like they have adopted [47:42.370 --> 47:48.770] windermere's one-time signature. So what IOTA has implemented is a DDoS prevention mechanism. [47:48.770 --> 47:57.070] IOTA is actually an IOT ledger with heterogeneous IOT devices. So they propose to use VDF for [47:57.070 --> 48:02.310] VDF as a DDoS prevention mechanism where nodes are required to compute exactly [48:03.010 --> 48:10.290] the prime modular squarings for an input message. Calibrating the VDF evaluation on different [48:10.290 --> 48:15.690] hardware and optimizing the time need to verify the correctness of the puzzle through multi- [48:15.690 --> 48:20.570] exponentiation techniques. That is what they have done. So what they have done is they have used [48:20.570 --> 48:28.650] different kind of hardware like laptops, FPGAs and different IOT hardwares like Raspberry Pis [48:29.170 --> 48:36.470] and different other devices and then they optimize the time. They continuously calibrated what would [48:36.470 --> 48:47.150] be the time for constructing the VDF, evaluating the VDF and verifying the VDF. So they compared it [48:47.150 --> 48:54.590] with for their purpose. Actually IOTA doesn't have a system like a proof of stake. Hence their concern [48:54.590 --> 49:02.490] was how to use it instead of proof of work and that's how they use VDF. So how did they use it? [49:02.490 --> 49:09.910] In the evaluation phase, every node decides to generate a transaction and all those nodes need [49:09.910 --> 49:17.610] to solve a VDF such that the input is the hash of the transaction issued by the same node and the [49:17.610 --> 49:23.710] proof that they generate. The node also generated proof to facilitate the verification task which [49:23.710 --> 49:29.490] gossip along with the transaction. So they share the proof along with the transaction. Verification [49:29.490 --> 49:36.830] happens when a new transaction is received. A particular node verifies whether the VDF is [49:36.830 --> 49:43.490] solved correctly by the node which sent the transaction. If yes, it forward the transaction. [49:43.490 --> 49:50.130] In IOTA, it has some kind of tipping mechanism or forward mechanism where every node [49:50.130 --> 49:56.050] which receives an input has to send it to two other nodes. That is how the tangle works. [49:56.050 --> 50:01.550] Let us look at how VDF integration is implemented in IOTA. There are evaluators [50:02.130 --> 50:09.130] and evaluators evaluate and generate the proof from the input to the VDF. They use both hash and [50:09.130 --> 50:15.270] the VDF and then when they generate transaction, transaction nodes will have VDF in it and then [50:15.270 --> 50:22.030] the verifier will verify whether the VDF is accurate which they can do it fast. If it is true, [50:22.030 --> 50:26.890] they broadcast to neighbor. If it is false, they discard it. We can configure the difficulty [50:27.450 --> 50:34.290] and the modulus in this VDF implementation IOTA. This is an important property which is mentioned. [50:34.290 --> 50:39.290] VDF difficulty can be configured that determines the number of sequential operations to solve [50:39.290 --> 50:47.650] and update the VDF. The second one, the prime modulus, the RSA modulus which we use for the RSA [50:47.650 --> 50:53.370] based groups of unknown order. And the third thing, they also use a cryptographic hash function. [50:54.190 --> 51:01.690] Now let us quickly talk about our approach. Our approach is based on a closer view at what is [51:01.690 --> 51:08.350] required for Ethereum 2.0 and what are the current capabilities we have in 2.0 like sharding, stake [51:08.350 --> 51:16.670] and random oracles and also the presence of different proof, zero-knowledge proof implementations. [51:16.670 --> 51:23.250] But one key difference what we would like to propose is, we are proposing VDF based on [51:23.250 --> 51:31.090] super-singular isogenic cryptography, not based on the RSA based unknown groups of unknown order [51:31.090 --> 51:38.890] approach or adiabatic adaptive root assumption approach of PISTRAC and Wyslawowski. We also [51:38.890 --> 51:45.750] wanted to bring in an approach known as single secret leader selection. And we want to use this [51:45.750 --> 51:53.530] VDF for selecting a secret leader, a single secret leader from data shards each time. [51:53.530 --> 51:59.470] And we also want to use them in conjunction with random oracles. And we want to authenticate the [51:59.470 --> 52:05.230] nodes participating in stake mechanism using VDF based delay authentication, [52:05.230 --> 52:11.310] which is also proposed recently. And then we want to use randomness, [52:11.310 --> 52:16.650] ran-share and ran-hound powered beacon chain. 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:32.550] These random oracles will source to the shard chains with ran-hound and ran-share. And that's [52:32.550 --> 52:38.410] how we decide which shard to move in the proximity. And then the shards will be part of the beacon [52:38.410 --> 52:44.570] chain where we will have a secret single leader selection and delay authentication. And then [52:45.330 --> 52:50.030] finally, which will be added to the main chain based on... [52:50.030 --> 52:55.950] Hi sir, sorry again for interrupting. 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:06.090] Yeah, I'll just quickly show what we have. We have already done a prototype on this random oracle [53:06.090 --> 53:14.450] using the VDF from the software. You can see the code in our repository. And we also giving [53:14.450 --> 53:19.410] the highlight of the single secret leader selection mechanism. You can find the research [53:19.410 --> 53:25.890] paper which is substantiating this again from Dan Boneh and the node topology. And please let me [53:25.890 --> 53:32.830] hand over to Tejas to talk about the beautiful aspects of isogeny based VDF quickly. [53:33.630 --> 53:40.370] So, hey everyone. I will just quickly wrap up our presentation and we are just in more finale. [53:40.450 --> 53:47.830] And I will just quickly talk about the isogeny based VDF. Now, what is an isogeny? It is based [53:47.830 --> 53:55.570] on the idea of elliptic curve cryptography and Diffie-Hellman key exchange. So in isogeny, [53:55.570 --> 54:00.650] there are a group of elliptic curves. So you can think about that there are two elliptic curves, [54:00.650 --> 54:08.270] E1 and E2. We can do a mapping or a function of like, let's say, point P from elliptic curve E1 [54:08.270 --> 54:16.750] to point Q at elliptic curve E2. And this mapping is called as the isogeny. Now, our secret here is [54:16.750 --> 54:23.810] then the isogeny here and the public key you can think about as the elliptic curve. And we can do a [54:23.810 --> 54:30.090] secret share exchange by mixing our secret key with other side's elliptic curve. Next slide. [54:31.010 --> 54:42.550] Next. Next, moving on. So, yep, let's see a quick construction. So we'll set up, we'll take [54:42.550 --> 54:47.990] prime number n, we'll take a supersingular curve E, and performing a random non-backtracking [54:47.990 --> 54:55.090] walk of length t, have as outcome the isogeny phi, and its dual as phi dash. I call it as phi dash. [54:55.090 --> 54:59.410] Now, choosing a point P, we'll compute the isogeny of the point P, [54:59.410 --> 55:06.010] and there will be output as isogeny dual, the elliptic curves E and E dash, the point P, [55:06.010 --> 55:15.190] and the isogeny of point P. Next. This is how isogeny look like, mapping between two elliptic [55:15.190 --> 55:25.750] curves. Next. And the final slide, how the evaluation and verification works in an isogeny [55:25.750 --> 55:33.730] based medium. So for the evaluation, if we are receiving a random point Q, we have to compute [55:33.730 --> 55:44.090] the isogeny dual of that point Q. And for the verification part, we will refer to our previous [55:44.090 --> 55:50.070] knowledge of the slides, which were field pairings. So how the verification can be done, [55:50.070 --> 55:56.650] just simply a field pairing of the point P with the isogeny dual of the point Q, [55:56.650 --> 56:03.090] and that should be equal to the field pairing of isogeny of the point P and the point Q. [56:03.090 --> 56:08.790] So having said that, we are done with our presentation, and I will hand over to Gokul [56:08.790 --> 56:16.950] sir to say the final words. It's a great honor for us to present our compilation of thoughts on [56:17.510 --> 56:25.590] applying powerful properties of randomness, unbiased randomness and entropy, for the [56:25.590 --> 56:32.790] overall transformation of the consensus and cryptography and to make Ethereum 2.0 much [56:32.790 --> 56:40.330] more stronger and make sure that every chance of DDoS attack can be prevented from the sharding, [56:40.330 --> 56:46.690] shard to the main chain itself. Overall, so this is a randomness engineering that we propose. [56:46.690 --> 56:51.950] We have done our first level of prototype. We would like to move to the next level by [56:51.950 --> 56:59.910] integrating isogeny VDF from the SIDS library and the SS-isogeny library. And then we would [56:59.910 --> 57:06.770] also want to blend single secret leader selection, and we would like to do it on the RANDAO. [57:06.930 --> 57:12.030] We have already participated in the Starkware VDF hackathon. We have used the [57:12.030 --> 57:19.610] VDF from Starkware and built random oracles and applied on RANDAO. Now we are excited to go [57:19.610 --> 57:25.370] forward. Thank you so much again for Blockchain Village, DEF CON for giving us this opportunity. [57:25.370 --> 57:30.910] It's an honor. It's a lifetime opportunity for us. Thank you so much once again. Looking forward [57:30.910 --> 57:32.550] to your questions and comments.