1 00:00:00,000 --> 00: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. 2 00:00:14,620 --> 00: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. 3 00:00:27,600 --> 00:00:31,400 So wrapping up a quick speaker's introduction. 4 00:00:31,400 --> 00:00:32,200 So here am I. 5 00:00:32,200 --> 00:00:34,320 My name is Tejasura Sogi. 6 00:00:34,320 --> 00: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. 7 00:00:45,320 --> 00:00:47,720 I'm also a YouTuber as RazerSharp . 8 00:00:47,720 --> 00:00:54,280 I post security content on YouTube and the most important thing I'm a cybersecurity enthusiast. 9 00:00:54,300 --> 00:00:56,880 I love the world of internet. 10 00:00:57,120 --> 00:00:59,480 With that I will ask my partner Mr. 11 00:00:59,480 --> 00:01:02,640 Gokul Alex to say a few words about him. 12 00:01:02,880 --> 00:01:04,740 Thank you Tejasura. 13 00:01:04,780 --> 00:01:08,720 Hi everyone this is Gokul Alex. 14 00:01:08,760 --> 00:01:19,360 It's my pleasure and privilege to present in this platform in DEF CON in front of every one of you. 15 00:01:19,360 --> 00: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. 16 00:01:30,340 --> 00:01:33,160 We are a non-profit organization. 17 00:01:33,420 --> 00:01:42,700 I am also building a blockchain protocol integrating off-chain and on-chain data called Fusion Ledger. 18 00:01:42,820 --> 00:01:57,720 I am representing a collection of cryptocurrencies and platforms in India such as Algorand, Eternity, Elixir, Hashgraph, Horizon and Tezos. 19 00:01:57,720 --> 00: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. 20 00:02:08,580 --> 00:02:19,590 I am a global leader for XS collective created by David Choum known as the godfather of cryptography and blockchain technology. 21 00:02:19,590 --> 00:02:23,470 I am a programmer and poet in my personal life. 22 00:02:23,470 --> 00:02:30,470 I've been a blockchain security auditor for government, public sector and private sector across various countries. 23 00:02:30,610 --> 00:02:37,440 I am actively researching on the convergence of quantum algorithms and post-quantum cryptography. 24 00:02:38,400 --> 00:02:42,200 Over to Tejeshwar to get start with the presentation. 25 00:02:42,200 --> 00:02:43,540 Awesome! 26 00:02:43,540 --> 00: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. 27 00:02:53,920 --> 00:02:59,140 So let's talk about what is proof-of-work consensus algorithm. 28 00:02:59,140 --> 00:03:02,380 Now before that let's talk about what are consensus algorithm. 29 00:03:02,380 --> 00: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. 30 00:03:18,020 --> 00:03:27,280 Now consensus algorithms is all about building fault-tolerant, fault-resilient machines for distributive computing. 31 00:03:27,280 --> 00:03:34,580 Now our talk is about the convergence of cryptographic schemes and consensus algorithms. 32 00:03:34,720 --> 00:03:41,400 Now consensus algorithms have both deterministic and probabilistic dimensions right. 33 00:03:41,400 --> 00:03:52,780 Now consensus algorithms helps us to achieve a consistent state and agreement between participating nodes in a blockchain network. 34 00:03:52,860 --> 00:03:55,940 Getting back to our proof-of-work consensus algorithm. 35 00:03:55,940 --> 00: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. 36 00:04:07,600 --> 00: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. 37 00:04:18,720 --> 00: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. 38 00:04:40,500 --> 00:04:45,140 Now let's move on to some of the attack vectors or proof-of-work. 39 00:04:45,880 --> 00: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. 40 00:04:56,280 --> 00:05:00,120 Now let's talk over this attack. 41 00:05:00,320 --> 00: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. 42 00:05:16,680 --> 00:05:26,740 Now in most of the blockchain these sudden changes in the processing power are not addressed by the nodes. 43 00:05:26,740 --> 00:05:32,580 They can be addressed by the nodes at a scheduled update. 44 00:05:33,260 --> 00:05:35,180 Now let's take a scenario. 45 00:05:35,280 --> 00: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. 46 00:05:43,660 --> 00:05:45,660 Six of them are malicious actors. 47 00:05:45,660 --> 00:05:49,180 Now they are not doing anything and just chilling in the network. 48 00:05:49,180 --> 00:05:51,680 Everything is going as planned. 49 00:05:51,760 --> 00:05:55,120 Mining difficulty is working as the way it should. 50 00:05:55,120 --> 00:06:00,140 Block creation is happening at a certain frequency and everything is perfect. 51 00:06:00,360 --> 00:06:06,460 Now suddenly what the malicious actors decide they decide to turn their machines down. 52 00:06:06,460 --> 00: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. 53 00:06:30,420 --> 00:06:35,000 So there are other attacks as well like routing attack. 54 00:06:35,000 --> 00:06:37,620 So routing attack consists of two parts. 55 00:06:37,620 --> 00: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. 56 00:06:51,980 --> 00:06:56,000 Moving on and there are user wallet attacks. 57 00:06:56,420 --> 00: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. 58 00:07:06,780 --> 00:07:10,040 Now what is this 51% of majority attack. 59 00:07:10,040 --> 00: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. 60 00:07:26,340 --> 00: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. 61 00:07:36,600 --> 00:07:43,860 Now if there is a group of malicious actors which is in majority. 62 00:07:43,880 --> 00:07:54,320 Now it will have this group will have a higher and better probability to be for the block creation. 63 00:07:54,540 --> 00:07:59,060 So this is the 51% attack. 64 00:07:59,080 --> 00:08:08,460 Moving on there are some mining pool attacks like selfish mining, forecaster, withhold and like that. 65 00:08:08,480 --> 00:08:12,400 So moving on let's talk over DDoS on ethereum. 66 00:08:13,360 --> 00:08:21,280 Now there are some attacks that happened on ethereum or there are scenarios as well. 67 00:08:21,420 --> 00:08:27,100 So we'll pick up some of them like there was an attack on parity client. 68 00:08:27,100 --> 00:08:34,580 So what was the incident like some parity ethereum nodes lost sync with the network because of the following incident. 69 00:08:34,580 --> 00:08:43,340 Now what was the incident that if you send to a parity node a block with invalid transaction what will happen. 70 00:08:43,400 --> 00: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. 71 00:09:03,220 --> 00:09:09,320 Moving on there was a vulnerability that was found in parity nodes as well. 72 00:09:09,320 --> 00: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. 73 00:09:25,540 --> 00: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. 74 00:09:40,500 --> 00:09:45,960 So moving on and there is an interesting underpriced DDoS attacks. 75 00:09:45,960 --> 00:09:56,100 Now these are a group of attacks which exploited the vulnerability in the improper cast cost of EVM's opcodes. 76 00:09:56,100 --> 00:10:00,800 Now the opcodes were the ext code size and the suicide opcode. 77 00:10:00,800 --> 00:10:06,560 The suicide opcode was renamed to self destruct after eip6. 78 00:10:06,560 --> 00:10:09,100 We'll talk about that in the next slide. 79 00:10:09,100 --> 00: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. 80 00:10:24,880 --> 00: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. 81 00:10:42,780 --> 00: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. 82 00:11:03,020 --> 00: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. 83 00:11:14,580 --> 00: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. 84 00:11:25,540 --> 00: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. 85 00:11:54,060 --> 00: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. 86 00:12:10,040 --> 00:12:11,960 Now what was the impact? 87 00:12:11,960 --> 00:12:19,840 It created millions of dead ethereum accounts and also bloated the state database. 88 00:12:20,060 --> 00:12:24,440 Now it also created tons of transaction freezes as well. 89 00:12:25,340 --> 00: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. 90 00:12:37,020 --> 00:12:45,420 Hacks can be created against huge amount of cleanup transactions and each cleanup transaction creates large set of freezes. 91 00:12:45,420 --> 00: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. 92 00:12:54,980 --> 00: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. 93 00:13:11,880 --> 00:13:16,780 Moving on to let's talk about the attack vectors on proof of stake. 94 00:13:16,780 --> 00:13:24,760 Now before covering the attack vectors let's do a quick refresher again on the proof of stake consensus algorithm. 95 00:13:25,300 --> 00:13:29,280 Now proof of stake is a popular alternative to proof of work. 96 00:13:29,380 --> 00:13:37,220 In proof of stake there are validators instead of miners and a validator is selected to forge a block. 97 00:13:37,380 --> 00: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. 98 00:13:51,920 --> 00:13:57,320 And proof of stake has many advantages over proof of work. 99 00:13:57,320 --> 00:14:00,120 The first is obviously the security. 100 00:14:00,120 --> 00:14:05,040 It provides a better security mechanism against 51% attack. 101 00:14:05,040 --> 00: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. 102 00:14:17,360 --> 00:14:31,040 But in proof of stake owning 51% of the stakes would be very would be computationally very expensive for an attacker. 103 00:14:31,040 --> 00:14:34,120 So that's how it provides a better security. 104 00:14:34,120 --> 00:14:41,300 Also it provides better it's energy efficient and provides energy savings. 105 00:14:41,640 --> 00: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. 106 00:14:56,280 --> 00:15:00,640 And there is a casper protocol based on proof of stake. 107 00:15:00,640 --> 00:15:12,740 It provides its own security implications like this slashing mechanism which provides slashing of stakes as a penalty to the validator. 108 00:15:12,740 --> 00: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. 109 00:15:39,280 --> 00:15:42,700 So this was casper protocol. 110 00:15:43,400 --> 00:15:49,260 Moving on to let's see some of the attack vectors attacks against proof of stake. 111 00:15:49,260 --> 00:15:53,320 You can see a list of attacks in front of the screen. 112 00:15:53,320 --> 00:15:57,660 There is a fake stake attack a very interesting attack. 113 00:15:57,660 --> 00:16:02,660 Now fake stake attack can be think about as a denial of service. 114 00:16:02,660 --> 00:16:11,320 An attacker can devote a node's valuable memory and cpu to a fake chain. 115 00:16:11,320 --> 00:16:20,060 Now we know there is a longest chain rule that any chain can suddenly become the accepted version of the ledger. 116 00:16:20,580 --> 00:16:26,680 Now validation of a proof in proof of stake is kind of complex. 117 00:16:26,680 --> 00:16:35,920 Now it required access to both the block header as well as the contents of block. 118 00:16:36,380 --> 00: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. 119 00:16:49,900 --> 00:16:56,800 It consumes valuable resources for the node and can eventually result into a denial of service. 120 00:16:56,840 --> 00:17:03,500 So fake stake attack can be think about as a denial of service and proof of stake. 121 00:17:03,960 --> 00:17:08,140 Moving on to let's see the 3m 2.0 architecture. 122 00:17:08,700 --> 00:17:17,120 In front of your screen you can see a beautiful picture defining the road map to serenity. 123 00:17:17,980 --> 00:17:23,400 Then there is the current blockchain showing proof of work and proof of stake together. 124 00:17:25,660 --> 00:17:30,140 And then you can see a little bit detailed architecture. 125 00:17:30,140 --> 00:17:33,340 Like there is a main chain based on proof of work. 126 00:17:33,340 --> 00:17:41,040 Then there is a beacon chain based on the casper ffg protocol, proof of stake protocol that we just discussed. 127 00:17:41,100 --> 00:17:44,120 And random number generation happens. 128 00:17:44,320 --> 00: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. 129 00:17:54,100 --> 00:17:58,720 Moving on to see some of the 3m 2.0 audit findings. 130 00:17:58,800 --> 00:18:01,880 Talking about the Constem audit first. 131 00:18:01,920 --> 00:18:14,000 Now Constem did an audit as well and founded some DDoS attack vectors, attack vectors and reported them. 132 00:18:14,140 --> 00:18:20,340 Like DDoS attack through creating a mapping between public keys and validator IPs. 133 00:18:20,340 --> 00:18:25,480 Also DDoS attack on insecure gRPC connection. 134 00:18:26,440 --> 00:18:28,380 So what was the Constem audit? 135 00:18:28,620 --> 00:18:37,020 Basically it involved 10 engineers who examined the entire code base over the course of two months. 136 00:18:37,020 --> 00:18:44,300 They examined the beacon node logic, validator client, flasher logic and almost everything. 137 00:18:46,570 --> 00:18:48,410 So what were the findings? 138 00:18:48,410 --> 00:18:50,850 They found a lot of vulnerabilities. 139 00:18:50,850 --> 00: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. 140 00:19:05,630 --> 00:19:09,090 Now let's talk about the least authority audit as well. 141 00:19:09,090 --> 00:19:18,310 So they did an audit over various subsections like they did a audit over block proposal system. 142 00:19:18,350 --> 00:19:19,590 What were the findings? 143 00:19:19,590 --> 00: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. 144 00:19:34,850 --> 00:19:41,290 With the information leak passed, the block proposer remains as protected as it is. 145 00:19:41,290 --> 00:19:46,650 It would be in proof of work chains but without the computational overhead. 146 00:19:47,950 --> 00:19:51,930 We're talking about the findings on a gossip protocol. 147 00:19:51,930 --> 00:19:56,350 Now gossip protocols generally suffer from the spam problem. 148 00:19:56,350 --> 00: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. 149 00:20:05,630 --> 00:20:10,010 This was one of the primary concerns in examining the network layer. 150 00:20:10,090 --> 00: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. 151 00:20:18,290 --> 00: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. 152 00:20:39,030 --> 00:20:47,090 Also, there were findings on slashing messages that we just discussed earlier, the Casper protocol security implication. 153 00:20:47,550 --> 00: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. 154 00:21:02,110 --> 00:21:06,450 Now moving on to talk about DDoS on Ethereum 2.0. 155 00:21:06,750 --> 00:21:11,630 Let's take the recently happened Teku attack scenario. 156 00:21:11,830 --> 00:21:19,950 Now there were security engineers who did research over public antagonists. 157 00:21:19,950 --> 00:21:23,230 They found a Teku attack, created a Teku attack. 158 00:21:23,230 --> 00:21:25,150 Now what was the scenario like? 159 00:21:25,150 --> 00:21:31,630 Two of the four Teku nodes were targeted by five ordinary machines with a sustained DDoS attack. 160 00:21:32,050 --> 00:21:34,010 Now what was the impact? 161 00:21:34,010 --> 00: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. 162 00:21:47,030 --> 00:21:49,350 Now what was the implementation? 163 00:21:49,390 --> 00:21:52,990 You can see a command in front of your screen. 164 00:21:53,470 --> 00: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. 165 00:22:08,830 --> 00:22:16,850 But stay off AWS and IPS radars to ensure the attack continuous. 166 00:22:17,290 --> 00:22:26,150 Also the data is then piped back into the netcat command which sends it to the nodes under attack. 167 00:22:26,230 --> 00:22:34,670 The while loop is there for when it loses connectivity and command compiles due to container restarts. 168 00:22:36,050 --> 00:22:39,450 And moving on to what was the impact of this Teku attack. 169 00:22:39,450 --> 00: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. 170 00:22:53,770 --> 00:23:00,370 Now the nodes under attack used large amounts of memory while subject to multiple container restarts. 171 00:23:00,370 --> 00:23:07,850 Had trouble staying connected to peers and even once nodes local clock was like 20 minutes slow. 172 00:23:08,890 --> 00:23:12,270 Moving on to the Teku attack root cause. 173 00:23:12,270 --> 00:23:16,550 Now firstly responding to one byte when multiple bytes is a vector. 174 00:23:16,550 --> 00:23:20,010 We know for various amplification attacks that we know. 175 00:23:20,010 --> 00:23:23,990 But that was not the issue that caused the loss of finality. 176 00:23:23,990 --> 00: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. 177 00:23:34,350 --> 00: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. 178 00:23:44,130 --> 00:23:49,210 This pushed up both the on and off heap memory usage very substantially. 179 00:23:49,930 --> 00:23:55,230 Also CPU spikes significantly partly due to the processing power. 180 00:23:55,510 --> 00:24:03,930 All those due to processing all those multi-stream messages but mostly because of the resultant memory pressure and GC activity. 181 00:24:04,770 --> 00:24:08,270 Now talking about what can be a solution. 182 00:24:08,270 --> 00: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. 183 00:24:19,410 --> 00: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. 184 00:24:32,230 --> 00:24:35,050 So this was the takeover attack. 185 00:24:35,050 --> 00:24:38,550 We covered consensus algorithms. 186 00:24:38,550 --> 00:24:41,790 We talked over proof-of-work, proof-of-stake. 187 00:24:41,790 --> 00:24:46,630 We took different attacks, attack vectors as well. 188 00:24:46,630 --> 00:24:50,050 We talked over 51% attack, denial of service. 189 00:24:50,050 --> 00:24:53,450 We have seen the ATM 2.0 architecture. 190 00:24:53,450 --> 00:24:57,290 Also the security implications of cash flow protocol. 191 00:24:57,290 --> 00:24:58,690 Now my partner Mr. 192 00:24:58,690 --> 00: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. 193 00:25:09,990 --> 00:25:11,290 So over to you sir. 194 00:25:13,090 --> 00:25:20,550 Thank you Tejaswar for setting the context, for researching on the randomness in Ethereum 2.0. 195 00:25:21,130 --> 00:25:29,450 We will see how randomness is very crucial to the overall engineering and overall design of Ethereum 2.0. 196 00:25:29,870 --> 00: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. 197 00:25:48,670 --> 00:25:57,250 Both the randomness and the validator assignment require computation that is not specific to any shard. 198 00:25:57,250 --> 00: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. 199 00:26:08,910 --> 00: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. 200 00:26:19,070 --> 00:26:20,450 This is very important. 201 00:26:22,770 --> 00:26:26,550 The shards and taking activity. 202 00:26:26,650 --> 00:26:30,790 In older times, we used to take additions, cut additions from the databases. 203 00:26:30,870 --> 00:26:33,030 The snapshots are the read-only versions. 204 00:26:33,230 --> 00: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. 205 00:26:51,210 --> 00: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. 206 00:27:04,670 --> 00:27:09,910 But we have to understand, we cannot afford any simple randomness. 207 00:27:09,910 --> 00:27:12,710 We need distributed randomness on blockchain. 208 00:27:12,710 --> 00:27:18,870 That is why randomness in blockchain becomes much more complex and more challenging. 209 00:27:18,970 --> 00:27:25,310 So many blockchains, if you know, blockchains have different purpose of using randomness. 210 00:27:25,310 --> 00: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. 211 00:27:41,570 --> 00:27:46,290 What happens if a malicious actor can influence such a source of randomness? 212 00:27:46,290 --> 00:27:53,210 They can increase the chance of being selected and possibly compromise the security of the protocol. 213 00:27:54,670 --> 00:28:02,590 And like we said, distributed randomness is very crucial building block for any kind of applications on blockchain. 214 00:28:02,770 --> 00:28:07,490 What are the essential properties of randomness required in a blockchain setup? 215 00:28:07,490 --> 00:28:10,670 There are three essential properties laid out. 216 00:28:10,670 --> 00:28:13,350 First, it needs to be unbiased. 217 00:28:13,370 --> 00:28:16,990 We cannot afford a biased source of entropy. 218 00:28:17,030 --> 00:28:22,930 In other words, no participant shall be able to influence in any way the outcome of the random generator. 219 00:28:23,150 --> 00:28:25,350 Second, it needs to be unpredictable. 220 00:28:25,430 --> 00: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. 221 00:28:32,010 --> 00: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. 222 00:28:43,670 --> 00:28:46,930 Now we will look at some of the existing approaches. 223 00:28:46,930 --> 00:28:53,250 One of the first approaches is the RANDAO approach, which is the acronym for Random DAO. 224 00:28:53,250 --> 00:28:59,430 The general idea is that the participants in the network, first of all, privately choose a pseudo random number. 225 00:28:59,430 --> 00:29:02,890 Submit a commitment to the privately chosen number. 226 00:29:02,890 --> 00:29:07,970 This commitment could be implemented as a polynomial commitment or a Pedersen commitment. 227 00:29:07,970 --> 00:29:12,850 All agree on some sort of commitment using a consensus algorithm. 228 00:29:12,850 --> 00: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. 229 00:29:22,970 --> 00:29:27,770 This is a pretty straightforward approach, but there are some limitations. 230 00:29:28,150 --> 00:29:33,190 It is fairly unpredictable, and it has liveness. 231 00:29:33,190 --> 00:29:39,490 We know liveness and safety are two required properties of any consensus mechanism. 232 00:29:39,490 --> 00:29:42,770 This provides a great degree of liveness. 233 00:29:42,830 --> 00: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. 234 00:29:56,790 --> 00: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. 235 00:30:11,090 --> 00:30:20,930 So there is a proposal, and there is a strong support in this direction, which is to blend RANDAO plus VDF. 236 00:30:20,930 --> 00:30:23,130 We will talk about VDF in detail. 237 00:30:23,130 --> 00:30:25,430 First, let us understand this approach. 238 00:30:25,750 --> 00: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. 239 00:30:37,190 --> 00: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. 240 00:30:46,970 --> 00:30:56,470 So we are talking about a computation which is sequential, which cannot be paralyzed by a powerful malicious adversary. 241 00:30:56,610 --> 00: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. 242 00:31:04,510 --> 00:31:11,830 It is called as verifiable delay functions, and the design is extremely complex, which we will talk in detail. 243 00:31:12,070 --> 00:31:15,330 What is Ethereum's perspective on RANDAO plus VDF? 244 00:31:15,330 --> 00:31:21,990 You can find numerous conversations on this in Ethereum research led by Justin Drake and others. 245 00:31:21,990 --> 00:31:27,130 Ethereum presents a plan to use RANDAO with VDF as their randomness beacon. 246 00:31:27,130 --> 00:31:31,450 Besides that fact, this approach is unpredictable and unbiasable. 247 00:31:31,450 --> 00:31:36,850 It has an extra advantage that it has liveness, even if only two participants are online. 248 00:31:36,850 --> 00:31:38,730 This is a very interesting property. 249 00:31:38,730 --> 00:31:44,770 It requires very, very less live participants compared to any other approach. 250 00:31:44,770 --> 00:31:52,870 For the family of VDF linked above a special ASIC, it can be 100 times faster than conventional hardware. 251 00:31:52,870 --> 00:32:01,070 That is why there is a strong effort and investment in Ethereum currently to build ASIC hardware for VDFs. 252 00:32:01,070 --> 00: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. 253 00:32:12,010 --> 00:32:19,230 And does the same VDF computed on the conventional hardware need to take 100x 100 seconds in three hours? 254 00:32:19,230 --> 00:32:22,470 Hence, there comes a dependency on hardware. 255 00:32:22,470 --> 00:32:28,470 That is the challenge because of this approach or the trade-off in this approach. 256 00:32:28,470 --> 00:32:34,930 Now let us look at an early approach which is fairly very popular. 257 00:32:34,930 --> 00:32:37,450 This approach is pioneered by DFINITY. 258 00:32:37,670 --> 00:32:44,330 In fact, more than one year back or two years back, DFINITY used BLS signature. 259 00:32:44,330 --> 00:32:46,050 What is BLS signature? 260 00:32:46,050 --> 00:32:50,310 It is known as Bonnet Line Shazam Signature. 261 00:32:50,710 --> 00:32:57,210 One of the authors of this cryptographic scheme, Ben Lin, is actually a member of DFINITY. 262 00:32:57,210 --> 00:32:59,010 What is this BLS signature? 263 00:32:59,010 --> 00:33:03,910 This is a scheme allowing a user to verify that a signer is authentic. 264 00:33:04,230 --> 00:33:07,850 This scheme uses a bilinear pairing for verification. 265 00:33:07,850 --> 00:33:14,150 We know about bilinear maps in elliptical cryptography, how powerful and formidable they are. 266 00:33:14,150 --> 00:33:17,970 So this is a signature scheme built using bilinear pairings. 267 00:33:17,970 --> 00: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. 268 00:33:32,510 --> 00:33:43,730 This is a very interesting property and hence BLS signatures are becoming very popular in more cryptocurrencies and blockchains. 269 00:33:43,730 --> 00:33:52,870 A common usage of BLS signatures is in signing BFT protocols, for signing blocks in BFT protocol. 270 00:33:52,970 --> 00: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. 271 00:34:06,570 --> 00: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. 272 00:34:18,850 --> 00:34:24,670 Any 67 parts can be used to create an accumulated or aggregated signature. 273 00:34:24,710 --> 00:34:32,350 However, the resulting signature will not be the same depending on what 67 signatures are aggregated. 274 00:34:32,690 --> 00:34:39,850 It turns out that the private keys that participants use are generated in a particular fashion. 275 00:34:39,850 --> 00:34:47,230 Then no matter what 67 or less signatures are aggregated, the resulting multi-signature will be the same. 276 00:34:47,330 --> 00:34:50,570 This can be used as a source of randomness. 277 00:34:50,910 --> 00:34:54,510 The participants first agree on some message that they will sign. 278 00:34:54,510 --> 00:34:58,470 It could be an output from a rando or it could be the hash of the block. 279 00:34:58,470 --> 00:35:04,190 It really doesn't matter as long as it is different every time and is agreed upon. 280 00:35:04,190 --> 00:35:11,970 So here we are blending both randomness and an agreement to create a multi-signature on it. 281 00:35:11,990 --> 00:35:15,230 But this has some limitations. 282 00:35:15,230 --> 00: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, 283 00:35:33,170 --> 00:35:37,750 it takes at least two by third participants to cooperate to influence the output. 284 00:35:38,530 --> 00:35:44,390 This is a big overhead when you consider a live blockchain system. 285 00:35:44,390 --> 00:35:48,050 Private keys in the scheme need to be aggregated in a particular fashion. 286 00:35:48,050 --> 00:35:52,270 And this process is known as distributed key generation. 287 00:35:52,270 --> 00:35:56,770 And this is something which is an ongoing area of research. 288 00:35:57,050 --> 00:36:01,790 And there is another interesting approach called ran-share approach. 289 00:36:01,790 --> 00:36:10,050 Ran-share approach is an unbiased and unpredictable protocol which can tolerate up to one by third of actors being malicious. 290 00:36:10,050 --> 00: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. 291 00:36:18,010 --> 00:36:22,970 But unlike ran-share, ran-hound and ran-herd are relatively complex. 292 00:36:22,970 --> 00:36:25,990 When you look at the details in the paper, you can understand. 293 00:36:25,990 --> 00: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. 294 00:36:33,950 --> 00:36:40,170 In fact, O to the O n to n cube messages are required. 295 00:36:40,330 --> 00:36:43,650 So this is kind of a gossip. 296 00:36:43,650 --> 00: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. 297 00:36:56,710 --> 00:37:02,550 So the challenge, one is the overhead because of the number of communications required. 298 00:37:02,550 --> 00:37:07,170 And second, the number of live participants required. 299 00:37:07,830 --> 00:37:09,690 So this is the challenge. 300 00:37:10,830 --> 00:37:18,070 The benefit from influencing the output can significantly outweigh the benefit of stalling randomness. 301 00:37:18,270 --> 00:37:20,450 Am I audible now? 302 00:37:21,070 --> 00:37:22,650 Keshav, can you confirm? 303 00:37:22,650 --> 00:37:23,730 Am I audible? 304 00:37:27,390 --> 00:37:29,250 Yes sir, you are audible. 305 00:37:29,510 --> 00:37:30,010 Okay. 306 00:37:30,970 --> 00:37:32,870 So let us continue. 307 00:37:32,870 --> 00:37:39,670 The benefit from influencing the output, this is one trade-off when we consider a randomness design. 308 00:37:39,690 --> 00:37:45,170 So either the adversary can stall the randomness or influence the output. 309 00:37:45,170 --> 00:37:47,730 So this is what we have to see in Rancher approach. 310 00:37:47,730 --> 00: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. 311 00:37:56,150 --> 00:37:57,490 This is a challenge. 312 00:37:57,490 --> 00:38:02,350 Thus, a malicious actor can do it without even ever being revealed. 313 00:38:02,370 --> 00:38:05,290 Stalling a consensus is always visible. 314 00:38:05,290 --> 00:38:12,990 So if somebody stalls a consensus or creates a fork or disrupts the network, this is visible. 315 00:38:12,990 --> 00:38:16,670 But if they influence the output, that leaves no trace. 316 00:38:16,670 --> 00:38:20,330 So that is the two aspects of this challenge. 317 00:38:20,630 --> 00: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. 318 00:38:34,650 --> 00:38:40,410 So we can't always say that that is an unimaginable or impossible situation. 319 00:38:40,410 --> 00:38:48,750 And hence, this Rancher approach creates some kind of a doubt or uncertainty. 320 00:38:49,050 --> 00:38:55,530 So we should look at the Near Protocol approach in this scenario. 321 00:38:55,530 --> 00: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. 322 00:39:11,130 --> 00:39:13,570 So what happens in Near Protocol? 323 00:39:13,570 --> 00:39:17,090 They have come up with an approach called erasure code. 324 00:39:17,090 --> 00:39:19,510 Let us understand what is this erasure code. 325 00:39:19,750 --> 00:39:26,350 Each participant comes up with their part of the network, split it into 67 parts. 326 00:39:26,350 --> 00:39:36,290 So this erasure code, it is generated to obtain 100 shares such that any 67 are enough to reconstruct the output. 327 00:39:37,170 --> 00: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. 328 00:39:44,410 --> 00:39:47,230 Then they can share all the encoded shares. 329 00:39:47,370 --> 00:39:49,850 Participants use some of the consensus. 330 00:39:49,850 --> 00:39:58,390 It could be any Lidl-based protocol like Tendermint to agree on such encoded set extracted from the 67 participants. 331 00:39:58,810 --> 00: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. 332 00:40:14,670 --> 00: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. 333 00:40:29,950 --> 00:40:37,330 The idea why this protocol is unbiasable and unpredictable is similar to the rand share and threshold signature approach. 334 00:40:37,350 --> 00: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. 335 00:40:51,150 --> 00: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. 336 00:41:06,290 --> 00:41:18,710 We can see that randavo, randshare, and the erasure code from near protocols, these are all specific consensus-based approaches. 337 00:41:18,710 --> 00:41:28,230 So one side we have threshold signatures, verifiable delay functions, other side we have randshare, randhound, and randherd. 338 00:41:28,330 --> 00:41:33,090 Now let us look at verifiable delay functions in detail. 339 00:41:34,010 --> 00:41:36,070 What is an anatomy of a VDF? 340 00:41:36,070 --> 00:41:38,550 A VDF consists of triple of algorithms. 341 00:41:38,570 --> 00:41:41,650 Setup, evaluate, and verify. 342 00:41:41,770 --> 00:41:50,830 A setup takes two parameters, lambda and t, the security parameter lambda and the delay parameter t. 343 00:41:51,310 --> 00:41:58,590 And it generates a public parameter pp which can fix the domain and range of the VDF. 344 00:41:58,590 --> 00:42:03,530 And we can add some additional information necessary to compute or verify it. 345 00:42:03,530 --> 00: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. 346 00:42:18,250 --> 00: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. 347 00:42:30,170 --> 00:42:35,390 So crucially for every input x there should be unique output of y. 348 00:42:35,730 --> 00: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. 349 00:42:58,830 --> 00: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. 350 00:43:10,110 --> 00:43:19,050 However their work was considered impractical then because one has to use rather large finite fields to make algorithms useful. 351 00:43:19,090 --> 00: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. 352 00:43:26,530 --> 00: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. 353 00:43:35,590 --> 00:43:38,310 What are the essential properties of VDF? 354 00:43:38,310 --> 00:43:41,110 Now we have seen how do we construct a VDF. 355 00:43:41,110 --> 00:43:42,930 What are the essential properties? 356 00:43:42,930 --> 00:43:45,690 Firstly it has to be sequential. 357 00:43:45,850 --> 00: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. 358 00:44:06,070 --> 00:44:07,690 So this is very important. 359 00:44:07,690 --> 00: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. 360 00:44:24,830 --> 00:44:33,210 They should not be able to distinguish this output from VDF from other randomness and it should be efficiently verifiable. 361 00:44:33,970 --> 00:44:38,810 The verify operation should be as fast as possible for honest parties to compute. 362 00:44:39,010 --> 00: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. 363 00:45:06,410 --> 00:45:11,430 Now there are some more additional properties of VDF very important for actual implementation. 364 00:45:11,550 --> 00:45:14,510 One of the first one is it should be decodable. 365 00:45:14,510 --> 00: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. 366 00:45:24,050 --> 00:45:29,050 This is very much required for a practical use of VDF and it should be implemented. 367 00:45:29,050 --> 00:45:31,230 Hi sir, sorry for interrupting. 368 00:45:31,850 --> 00:45:33,090 Yes. 369 00:45:33,710 --> 00:45:40,590 So we can take like 10 more minutes because it's already like just 30. 370 00:45:40,590 --> 00:45:42,030 So yep. 371 00:45:42,390 --> 00:45:43,830 Yeah, I'll move fast. 372 00:45:43,830 --> 00: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. 373 00:45:56,270 --> 00: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. 374 00:46:11,990 --> 00:46:18,830 But however this is a very complex implementation and hence even the author said this is a weak VDF. 375 00:46:18,830 --> 00: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. 376 00:46:34,390 --> 00: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. 377 00:46:48,810 --> 00:46:50,670 Innovations in VDF. 378 00:46:50,890 --> 00:46:57,350 One very crucial difference in VDF with others is VDF has a setup phase. 379 00:46:57,350 --> 00:47:02,990 Within the setup phase we set the public parameters for configuring the VDF. 380 00:47:02,990 --> 00:47:07,510 So any node who need to solve the VDF will use the public parameters. 381 00:47:07,570 --> 00: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. 382 00:47:19,530 --> 00:47:24,230 Now let us see how we can use VDF for DDoS prevention. 383 00:47:24,330 --> 00:47:30,150 One of the first approach for using VDF for DDoS prevention was from IOTA. 384 00:47:30,150 --> 00: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. 385 00:47:44,330 --> 00:47:48,770 So what IOTA has implemented is a DDoS prevention mechanism. 386 00:47:48,770 --> 00:47:54,030 IOTA is actually an IOT ledger with heterogeneous IOT devices. 387 00:47:54,030 --> 00: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. 388 00:48:07,710 --> 00: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. 389 00:48:17,270 --> 00:48:18,590 That is what they have done. 390 00:48:18,590 --> 00: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. 391 00:48:34,050 --> 00:48:44,270 They continuously calibrated what would be the time for constructing the VDF, evaluating the VDF and verifying the VDF. 392 00:48:44,670 --> 00:48:48,830 So they compared it with for their purpose. 393 00:48:48,830 --> 00:48:53,410 Actually IOTA doesn't have a system like a proof of stake. 394 00:48:53,410 --> 00:49:01,130 Hence their concern was how to use it instead of proof of work and that's how they use VDF. 395 00:49:01,130 --> 00:49:02,490 So how did they use it? 396 00:49:02,490 --> 00: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. 397 00:49:19,130 --> 00:49:25,490 The node also generated proof to facilitate the verification task which gossip along with the transaction. 398 00:49:25,490 --> 00:49:28,910 So they share the proof along with the transaction. 399 00:49:29,090 --> 00:49:32,970 Verification happens when a new transaction is received. 400 00:49:32,970 --> 00:49:41,010 A particular node verifies whether the VDF is solved correctly by the node which sent the transaction. 401 00:49:41,010 --> 00:49:43,490 If yes, it forward the transaction. 402 00:49:43,490 --> 00: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. 403 00:49:53,910 --> 00:49:56,050 That is how the tangle works. 404 00:49:56,050 --> 00:50:00,450 Let us look at how VDF integration is implemented in IOTA. 405 00:50:00,450 --> 00:50:07,330 There are evaluators and evaluators evaluate and generate the proof from the input to the VDF. 406 00:50:07,330 --> 00: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. 407 00:50:20,810 --> 00:50:23,250 If it is true, they broadcast to neighbor. 408 00:50:23,250 --> 00:50:25,410 If it is false, they discard it. 409 00:50:25,410 --> 00:50:31,490 We can configure the difficulty and the modulus in this VDF implementation IOTA. 410 00:50:31,490 --> 00:50:34,290 This is an important property which is mentioned. 411 00:50:34,290 --> 00:50:41,550 VDF difficulty can be configured that determines the number of sequential operations to solve and update the VDF. 412 00:50:41,550 --> 00:50:49,990 The second one, the prime modulus, the RSA modulus which we use for the RSA based groups of unknown order. 413 00:50:49,990 --> 00:50:53,370 And the third thing, they also use a cryptographic hash function. 414 00:50:54,190 --> 00:50:57,630 Now let us quickly talk about our approach. 415 00:50:57,630 --> 00: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. 416 00:51:16,670 --> 00: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. 417 00:51:38,310 --> 00:51:44,150 We also wanted to bring in an approach known as single secret leader selection. 418 00:51:44,150 --> 00:51:53,530 And we want to use this VDF for selecting a secret leader, a single secret leader from data shards each time. 419 00:51:53,530 --> 00:51:57,630 And we also want to use them in conjunction with random oracles. 420 00:51:57,630 --> 00:52:07,690 And we want to authenticate the nodes participating in stake mechanism using VDF based delay authentication, which is also proposed recently. 421 00:52:08,470 --> 00:52:14,110 And then we want to use randomness, ran-share and ran-hound powered beacon chain. 422 00:52:14,110 --> 00:52:16,650 So this is how we visualize our approach. 423 00:52:16,650 --> 00:52:25,550 We use isogeny based VDF generator and these VDF generators will be used to create random oracles. 424 00:52:25,790 --> 00:52:31,870 These random oracles will source to the shard chains with ran-hound and ran-share. 425 00:52:31,870 --> 00:52:36,270 And that's how we decide which shard to move in the proximity. 426 00:52:36,270 --> 00: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. 427 00:52:44,290 --> 00:52:50,030 And then finally, which will be added to the main chain based on... 428 00:52:50,030 --> 00:52:52,790 Hi sir, sorry again for interrupting. 429 00:52:52,950 --> 00:52:55,950 Ajit sir is saying we can like conclude our talk. 430 00:52:55,950 --> 00:53:00,230 So we can just quickly wrap up and just talk about the isogeny, right? 431 00:53:00,230 --> 00:53:03,130 Yeah, I'll just quickly show what we have. 432 00:53:03,130 --> 00:53:09,810 We have already done a prototype on this random oracle using the VDF from the software. 433 00:53:09,830 --> 00:53:12,490 You can see the code in our repository. 434 00:53:12,570 --> 00:53:18,330 And we also giving the highlight of the single secret leader selection mechanism. 435 00:53:18,330 --> 00:53:25,190 You can find the research paper which is substantiating this again from Dan Boneh and the node topology. 436 00:53:25,190 --> 00:53:32,830 And please let me hand over to Tejas to talk about the beautiful aspects of isogeny based VDF quickly. 437 00:53:33,630 --> 00:53:35,150 So, hey everyone. 438 00:53:35,150 --> 00:53:40,370 I will just quickly wrap up our presentation and we are just in more finale. 439 00:53:40,450 --> 00:53:44,930 And I will just quickly talk about the isogeny based VDF. 440 00:53:44,930 --> 00:53:47,030 Now, what is an isogeny? 441 00:53:47,030 --> 00:53:53,990 It is based on the idea of elliptic curve cryptography and Diffie-Hellman key exchange. 442 00:53:54,090 --> 00:53:58,010 So in isogeny, there are a group of elliptic curves. 443 00:53:58,010 --> 00:54:01,950 So you can think about that there are two elliptic curves, E1 and E2. 444 00:54:02,010 --> 00: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. 445 00:54:12,190 --> 00:54:15,050 And this mapping is called as the isogeny. 446 00:54:15,050 --> 00:54:21,270 Now, our secret here is then the isogeny here and the public key you can think about as the elliptic curve. 447 00:54:21,330 --> 00:54:28,950 And we can do a secret share exchange by mixing our secret key with other side's elliptic curve. 448 00:54:29,090 --> 00:54:30,090 Next slide. 449 00:54:31,010 --> 00:54:32,050 Next. 450 00:54:33,750 --> 00:54:35,370 Next, moving on. 451 00:54:37,230 --> 00:54:40,030 So, yep, let's see a quick construction. 452 00:54:40,070 --> 00: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. 453 00:54:53,190 --> 00:54:55,090 I call it as phi dash. 454 00:54:55,090 --> 00: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. 455 00:55:08,350 --> 00:55:09,270 Next. 456 00:55:11,250 --> 00:55:16,030 This is how isogeny look like, mapping between two elliptic curves. 457 00:55:16,030 --> 00:55:17,090 Next. 458 00:55:18,610 --> 00:55:26,970 And the final slide, how the evaluation and verification works in an isogeny based medium. 459 00:55:26,970 --> 00: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. 460 00:55:38,150 --> 00:55:47,730 And for the verification part, we will refer to our previous knowledge of the slides, which were field pairings. 461 00:55:47,790 --> 00: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. 462 00:56:03,090 --> 00: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. 463 00:56:11,970 --> 00: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, 464 00:56:40,330 --> 00:56:42,930 shard to the main chain itself. 465 00:56:42,930 --> 00:56:46,690 Overall, so this is a randomness engineering that we propose. 466 00:56:46,690 --> 00:56:49,910 We have done our first level of prototype. 467 00:56:49,910 --> 00: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. 468 00:56:59,250 --> 00: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. 469 00:57:06,930 --> 00:57:10,750 We have already participated in the Starkware VDF hackathon. 470 00:57:10,750 --> 00:57:17,410 We have used the VDF from Starkware and built random oracles and applied on RANDAO. 471 00:57:17,410 --> 00:57:20,230 Now we are excited to go forward. 472 00:57:20,230 --> 00:57:25,370 Thank you so much again for Blockchain Village, DEF CON for giving us this opportunity. 473 00:57:25,370 --> 00:57:26,490 It's an honor. 474 00:57:26,490 --> 00:57:29,450 It's a lifetime opportunity for us. 475 00:57:29,450 --> 00:57:30,510 Thank you so much once again. 476 00:57:30,510 --> 00:57:32,550 Looking forward to your questions and comments.