start	end	text
0	7240	Hey everyone and welcome to the DEF CON Blockchain Village and we are here to present our talk on
7240	14300	the title Verifiable Delay Functions for Preventing DDoS or TDoS Attacks on Ethereum 2.0.
14620	21340	So this is the agenda for our talk and at the very end of our session if the time allows
21920	26700	we'll try to pick up some of your questions and we'll try to answer as many as possible.
27600	34960	So wrapping up a quick speaker's introduction. So here am I. My name is Tejasura Sogi. I'm a
34960	41000	penetration tester, a blockchain security researcher, founder of RazerSec which is a
41000	47420	community that helps people to learn about blockchain security. I'm also a YouTuber as
47420	52760	RazerSharp. I post security content on YouTube and the most important thing I'm a cybersecurity
52760	61040	enthusiast. I love the world of internet. With that I will ask my partner Mr. Gokul Alex to say
61200	70420	a few words about him. Thank you Tejasura. Hi everyone this is Gokul Alex. It's my pleasure
70420	79360	and privilege to present in this platform in DEF CON in front of every one of you.
79360	86440	I'm the founder of Epic Knowledge Society, one of the fastest growing digital education platform
86440	96820	for engineers and entrepreneurs in India. We are a non-profit organization. I am also building a
96820	103140	blockchain protocol integrating off-chain and on-chain data called Fusion Ledger. I am
103140	113920	representing a collection of cryptocurrencies and platforms in India such as Algorand, Eternity,
113920	120440	Elixir, Hashgraph, Horizon and Tezos. I'm also the director of Tezos India Foundation
121640	130430	and I've been selected as the MVP for Hedera Hashgraph in 2018. I am a global leader for
131150	136410	XS collective created by David Choum known as the godfather of cryptography
137040	144470	and blockchain technology. I am a programmer and poet in my personal life. I've been a blockchain
144470	151570	security auditor for government, public sector and private sector across various countries. I am
152410	157440	actively researching on the convergence of quantum algorithms and post-quantum cryptography.
158400	165100	Over to Tejeshwar to get start with the presentation. Awesome! Now let's just start
165100	170820	our session and before moving to the attack vectors on proof-of-work, let's get a quick
170820	179140	refresher on some of the fundamentals. So let's talk about what is proof-of-work consensus algorithm.
179140	184860	Now before that let's talk about what are consensus algorithm. Now consensus algorithms decide like
184860	192820	who should create the next block and this decision defines the basic fundamental property
192820	198360	of blockchain which is decentralization and decentralized control of power. Now
199340	205440	consensus algorithms is all about building fault-tolerant, fault-resilient machines for
205440	212600	distributive computing. Now our talk is about the convergence of cryptographic schemes and
212600	219460	consensus algorithms. Now consensus algorithms have both deterministic and probabilistic
219460	228160	dimensions right. Now consensus algorithms helps us to achieve a consistent state and agreement
228160	234300	between participating nodes in a blockchain network. Getting back to our proof-of-work
234300	240420	consensus algorithm. Now in proof-of-work consensus algorithm there are miners who
240420	247100	compete with each other for the potential valid block creation right.
247600	255880	Now there are certain factors involved like that the block header must be less than a set threshold
255880	263160	and then there is a mining difficulty. Now mining difficulty defines like the current computational
263940	268960	power of the blockchain network and it can also be updated at regular intervals
268960	276680	to match the current computational power of the network and it also ensures that the block
276680	283660	creation should happen at a certain frequency. Now let's move on to some of the attack vectors
283660	290160	or proof-of-work. Now in front of your screen you can see some of the attacks or attack vectors given
291160	298100	like the first one which says denial of service or distributed denial of service. Now let's talk
298100	305020	over this attack. Now as we have just discussed about the mining difficulty
306000	311280	which defines the processing power of the network and can be updated at regular intervals
311280	318820	to match the to reflect the changes right in the processing power. Now in most of the
318820	327360	blockchain these sudden changes in the processing power are not addressed by the nodes. They can be
327360	337060	addressed by the nodes at a scheduled update. Now let's take a scenario. Let's take a scenario of
337060	343660	like there are nine machines on a blockchain network and six of them are malicious actors.
343660	349180	Six of them are malicious actors. Now they are not doing anything and just chilling in the network.
349180	355700	Everything is going as planned. Mining difficulty is working as the way it should. Block creation
355700	362340	is happening at a certain frequency and everything is perfect. Now suddenly what the malicious
362340	369620	actors decide they decide to turn their machines down. Now what will be the impact of this that
370260	377060	now the remaining three machines they have to do the work of nine machines and what will happen or
377060	384980	what will be the impact of this that the hash rate will decrease and it will decrease the block
384980	392940	creation rate and eventually create a denial of service. So there are other attacks as well
392940	399060	like routing attack. So routing attack consists of two parts. First one is the partition attack
399060	406260	which divides the blockchain network into two groups and then there is a delay attack which
406260	413920	tampers the propagating messages and sends them to the network. Moving on and there are
413920	421340	user wallet attacks. Then there are smart contract attacks, transaction verification mechanism
421340	428720	attacks and there you can see the well-known 51% of majority attack. Now what is this 51%
428720	436380	of majority attack. Now let's take example like there is a group which is in majority
436760	444600	a group of malicious actors which is in majority and they can take control over the
444600	452580	blockchain network. Now how it can be possible as we know that there is a race between miners
452580	459980	for the potential valid block creation. Now if there is a group of malicious actors
460540	470320	which is in majority. Now it will have this group will have a higher and better probability
471010	482820	to be for the block creation. So this is the 51% attack. Moving on there are some mining pool
482820	491140	attacks like selfish mining, forecaster, withhold and like that. So moving on let's talk over DDoS
491140	500300	on ethereum. Now there are some attacks that happened on ethereum or there are scenarios as
500300	507820	well. So we'll pick up some of them like there was an attack on parity client. So what was the
507820	513640	incident like some parity ethereum nodes lost sync with the network because of the following
513640	520880	incident. Now what was the incident that if you send to a parity node a block with invalid
520880	527820	transaction what will happen. If you send a parity node a block with invalid transaction but with
527820	535180	valid header borrowed from another block and what will happen that the node will mark the block
535180	542160	header as invalid and ban the block header forever but the header is still valid right.
543220	551200	Moving on there was a vulnerability that was found in parity nodes as well. So in may global
551200	557440	hacking research collective sr labs claimed that only two thirds of the ethereum client software
557440	563480	that ran on ethereum nodes had been patched against a critical security flaw discovered
563480	571100	earlier this year. The data reportedly indicated that unpatched parity nodes comprised 15% of all
571100	578240	the scanned nodes implying that 15% of all the ethereum nodes were vulnerable to a potential 51%
578240	587380	attack. So moving on and there is an interesting underpriced DDoS attacks. Now these are a group
587380	596880	of attacks which exploited the vulnerability in the improper cast cost of EVM's opcodes. Now the
596880	604760	opcodes were the ext code size and the suicide opcode. The suicide opcode was renamed to self
604760	611860	destruct after eip6. We'll talk about that in the next slide. So let's just take the ext code size
612660	621180	Now prior to eip150 hard fork, the ext code size opcode only charged 20 gas for reading a
621180	627920	contract byte code from disk and then deriving its length. Now as a consequence what happened
627920	634800	or what can happen if the attacker sent transactions to invoke a deployed smart contract
634800	641700	with many ext code size opcodes, it can cause a two to three times slower block creation rate.
642780	650860	Also there was a similar attack that exploited the vulnerability in the proper cast cost of
650860	660300	EVM's suicide opcode that was renamed to self destruct as I just said and also the empty code
660300	667460	vulnerability in the state drive. So the opcode is meant to remove a deployed smart contract
667460	673880	right and then send the remaining ether back to the account designated by the caller.
674580	680500	Now if the target doesn't exist a new account is created even though no ether may be transferred
680500	690860	but still a new account is created. Now what can happen like the attacker can create empty accounts
690860	699000	and that was or that happened like that the attacker created 19 million new empty accounts
699000	706560	by the opcode at a very minimal gas consumption and which wasted disk space and increased
706560	716120	synchronization and processing time and caused a kind of denial of service right. Moving on to
716120	726800	uh attack uh the attackers took advantage of the enterprise tdos attack and that happened
726800	732740	between the blocks mentioned in front of your screen. Now what was the impact? It created
732740	741860	millions of dead ethereum accounts and also bloated the state database. Now it also created
741860	750000	tons of transaction freezes as well. Moving on to the impact of ddos attacks uh the enterprise one
750760	758180	and what was the impact that that can be hacks against goethereum client. Hacks can be created
758180	764260	against huge amount of cleanup transactions and each cleanup transaction creates large set of
764260	770960	freezes. There may be a possibility of hard fork being created and even if the hard fork is created
770960	778300	hard forks do not remove the dead accounts right. Moving on to some of the quick fixes to
778300	785500	the attacks like scanning an initial set of transaction can be done measuring the traces
785500	790140	from each transaction and also checking the frequency of traces in the transactions.
791880	798520	Moving on to let's talk about the attack vectors on proof of stake. Now before covering the attack
798520	804760	vectors let's do a quick refresher again on the proof of stake consensus algorithm.
805300	811000	Now proof of stake is a popular alternative to proof of work. In proof of stake there are
811000	818560	validators instead of miners and a validator is selected to forge a block. Also the validator
818560	827100	selection depends upon the amount of cryptocurrency a validator has or the amount of stake a validator
827100	835380	has and also on the current complexity of the network. And proof of stake has many advantages
835380	842620	over proof of work. The first is obviously the security. It provides a better security mechanism
842620	852980	against 51% attack. Now as we know like in proof of work owning 51% of the computational power
852980	859040	meaning means like gaining control over of the network. But in proof of stake
860300	871040	owning 51% of the stakes would be very would be computationally very expensive for an attacker.
871040	878580	So that's how it provides a better security. Also it provides better it's energy efficient
878580	888460	and provides energy savings. Now also as the ethereum 2.0 is ethereum is transitioning
889060	895300	from ethereum 1 to ethereum 2.0 and it is transitioning from proof of work to proof of
895300	902380	stake. And there is a casper protocol based on proof of stake. It provides its own security
902380	911080	implications like this slashing mechanism which provides slashing of stakes as a penalty
911080	921780	to the validator. Now if a validator validates a block it has been awarded but if found that
921780	928900	the validator is involved in malicious activity the stakes will be slashed as a penalty and there
928900	937660	might be a chance as well that it can lose its privileges to take part in the network consensus.
939280	948140	So this was casper protocol. Moving on to let's see some of the attack vectors attacks against
948140	955800	proof of stake. You can see a list of attacks in front of the screen. There is a fake stake attack
956040	962700	a very interesting attack. Now fake stake attack can be think about as a denial of service. An
962700	972800	attacker can devote a node's valuable memory and cpu to a fake chain. Now we know there is a
972800	980060	longest chain rule that any chain can suddenly become the accepted version of the ledger.
980580	989700	Now validation of a proof in proof of stake is kind of complex. Now it required
989700	999060	access to both the block header as well as the contents of block. So like to trigger the stake
999060	1006860	value for the validator selection right and forcing the node to download data to validate
1006860	1015640	fake blocks. It consumes valuable resources for the node and can eventually result into a denial
1015640	1023500	of service. So fake stake attack can be think about as a denial of service and proof of stake.
1023960	1028140	Moving on to let's see the 3m 2.0 architecture.
1028700	1037120	In front of your screen you can see a beautiful picture defining the road map to serenity.
1037980	1043400	Then there is the current blockchain showing proof of work and proof of stake together.
1045660	1051840	And then you can see a little bit detailed architecture. Like there is a main chain
1051840	1058460	based on proof of work. Then there is a beacon chain based on the casper ffg protocol,
1058460	1065200	proof of stake protocol that we just discussed. And random number generation happens. Now you
1065200	1071640	can see that the beacon chain is cross-linked with the shard chain and underneath there is
1071640	1080040	execution engine as well. Moving on to see some of the 3m 2.0 audit findings. Talking about the
1080040	1090560	Constem audit first. Now Constem did an audit as well and founded some DDoS attack vectors,
1090560	1097080	attack vectors and reported them. Like DDoS attack through creating a mapping between
1097680	1105480	public keys and validator IPs. Also DDoS attack on insecure gRPC connection.
1106440	1113280	So what was the Constem audit? Basically it involved 10 engineers who examined the entire
1113280	1119840	code base over the course of two months. They examined the beacon node logic,
1119840	1124300	validator client, flasher logic and almost everything.
1126570	1132750	So what were the findings? They found a lot of vulnerabilities. Some of them are like
1132750	1138650	granularity of timestamps, pseudo random number generation where two random number
1138650	1144990	generation were needed and then a second pre-made attack on merkle trees as well.
1145630	1153250	Now let's talk about the least authority audit as well. So they did an audit over various subsections
1153250	1161210	like they did a audit over block proposal system. What were the findings? Like a single secret leader
1161210	1167170	election SSLE keeps a selection secret and stops the leak of information to an observer
1167170	1173750	while still allowing the chosen block proposer a fast way to verify to others that it is in fact
1173750	1181290	the proposer. With the information leak passed, the block proposer remains as protected as it is.
1181290	1186650	It would be in proof of work chains but without the computational overhead.
1187950	1194090	We're talking about the findings on a gossip protocol. Now gossip protocols generally suffer
1194090	1199390	from the spam problem. Without a centralized judge, it can be difficult to understand
1199390	1205290	whether a message is legitimate or is spam that is meant to clog a network.
1205630	1211610	This was one of the primary concerns in examining the network layer. In Ethereum 2.0,
1211610	1217750	when a node proposes a new finalized block, the block must be sent to the rest of the network.
1218290	1225350	There is an issue when a dishonest node is capable of sending an unlimited amount of
1225350	1230270	older block messages to the rest of the network with minimal penalty
1231790	1238950	which allows them to overwhelm the network and block legitimate messages.
1239030	1245030	Also, there were findings on slashing messages that we just discussed earlier, the Casper
1245030	1251710	protocol security implication. Now there is a small loophole as well that allowed a node to
1251710	1258250	send an unlimited amount of these types of messages with minimal penalty causing the same message
1258250	1267630	blocking if they send enough of them. Now moving on to talk about DDoS on Ethereum 2.0. Let's take
1267630	1275710	the recently happened Teku attack scenario. Now there were security engineers who
1276750	1283230	did research over public antagonists. They found a Teku attack, created a Teku attack.
1283230	1289250	Now what was the scenario like? Two of the four Teku nodes were targeted by five ordinary machines
1289250	1296610	with a sustained DDoS attack. Now what was the impact? That initial loss of finality was achieved
1296610	1303950	with two or three machines but the others joined with a few epochs to ensure that the network could
1303950	1312990	not recover. Now what was the implementation? You can see a command in front of your screen.
1313470	1322210	So what the command does, it pipes the null byte from Dave's view to the pb command which rate
1322210	1332890	limits to a somewhat arbitrary value high enough to prevent finality. But stay off AWS and IPS
1332890	1342270	radars to ensure the attack continuous. Also the data is then piped back into the netcat command
1342270	1350750	which sends it to the nodes under attack. The while loop is there for when it loses connectivity
1351450	1354670	and command compiles due to container restarts.
1356050	1361650	And moving on to what was the impact of this Teku attack. The effect that the denial of service
1361650	1368690	attack had on the attack net was a prolonged loss finality and required manual intervention
1368690	1375330	to restore the network to a healthy state once the attack stopped. Now the nodes under attack
1375330	1380730	used large amounts of memory while subject to multiple container restarts. Had trouble
1380730	1387850	staying connected to peers and even once nodes local clock was like 20 minutes slow.
1388890	1394890	Moving on to the Teku attack root cause. Now firstly responding to one byte when multiple
1394890	1400170	bytes is a vector. We know for various amplification attacks that we know. But
1400170	1405310	that was not the issue that caused the loss of finality. The second issue is that
1405310	1411290	responses were being written faster than they were read by the attacking peer and the JVM
1411290	1417950	libp2b was not applying any throttling. Eventually the TCP backpressure kicked in,
1417950	1423800	filled up the OS write buffers and the responses wound up being queued in user space memory.
1424130	1429210	This pushed up both the on and off heap memory usage very substantially.
1429930	1435230	Also CPU spikes significantly partly due to the processing power.
1435510	1441550	All those due to processing all those multi-stream messages but mostly because of the resultant
1441550	1449890	memory pressure and GC activity. Now talking about what can be a solution. It's like there
1449890	1456490	can be a straightforward solution like disconnect the peer immediately when an invalid example like
1457050	1463110	multistream message is received. And now also there's a resilience to dot attack as well
1463670	1469610	which increases significantly as increases the number of nodes and diversity of clients,
1469610	1476430	locations and network connections. So this was the takeover attack. We covered
1477130	1483270	consensus algorithms. We talked over proof-of-work, proof-of-stake. We took
1483270	1490270	different attacks, attack vectors as well. We talked over 51% attack, denial of service. We
1490270	1497290	have seen the ATM 2.0 architecture. Also the security implications of cash flow protocol.
1497290	1505710	Now my partner Mr. Gopal Alex will connect with you all the links, the PDF, randomness and DDoS
1505710	1511290	and will connect all of them and present it to you. So over to you sir.
1513090	1520550	Thank you Tejaswar for setting the context, for researching on the randomness in Ethereum 2.0.
1521130	1528650	We will see how randomness is very crucial to the overall engineering and overall design of
1528650	1535950	Ethereum 2.0. If you look at all the current implementations, be it on near protocol,
1535950	1542010	prismatic labs, the beacon chain, there is a crucial play for randomness because all the
1542010	1547950	sharding designs today rely on some source of randomness to assign validators to the shard.
1548670	1555910	Both the randomness and the validator assignment require computation that is not specific to any
1555910	1563310	shard. For this computation, existing designs have a separate blockchain that is tasked with
1563310	1570210	performing operations necessary for maintenance of the entire network. Besides generating these
1570210	1575910	random numbers and assigning validators to the shards, these operations also include receiving
1575910	1585310	updates from shards and taking snapshot of them. This is very important. The shards and taking
1585310	1590790	activity. In older times, we used to take additions, cut additions from the databases.
1590870	1596470	The snapshots are the read-only versions. And also when we process the stakes and slashing
1596470	1603050	in proof-of-stake systems, and when you have to plan the proximity of shard with the leaders
1603050	1609790	and rebalancing the shard, these randomness... so sharding, staking, and randomness have to
1609790	1616270	work together. When you look at all these implementations, whether it's Cosmos Hub in
1616270	1622890	Cosmos, or RelayChain in Polkadot, or BeaconChain in Ethereum and Near, this is the overall
1622890	1631110	architecture. But we have to understand, we cannot afford any simple randomness. We need distributed
1631110	1637590	randomness on blockchain. That is why randomness in blockchain becomes much more complex and more
1637590	1644370	challenging. So many blockchains, if you know, blockchains have different purpose of using
1644370	1651290	randomness. Maybe it's for time stamping, or it could be for games like lottery games, or it could
1651290	1659930	be for proof of replication, like in Filecoin, or in the case of Ethereum, BeaconChain for selecting
1659930	1666490	participants. What happens if a malicious actor can influence such a source of randomness? They
1666490	1673210	can increase the chance of being selected and possibly compromise the security of the protocol.
1674670	1679930	And like we said, distributed randomness is very crucial building block for any kind of
1679930	1685630	applications on blockchain. What are the essential properties of randomness required
1685630	1692450	in a blockchain setup? There are three essential properties laid out. First, it needs to be
1692450	1699130	unbiased. We cannot afford a biased source of entropy. In other words, no participant shall be
1699130	1704270	able to influence in any way the outcome of the random generator. Second, it needs to be
1704270	1709730	unpredictable. In other words, no participant shall be able to predict what number will be generated,
1709730	1714970	or what are the properties of it. Thirdly, the protocol needs to tolerate some percentage of
1714970	1720210	actors that go offline or try to intentionally stall the protocol, like the conventional
1720210	1725550	crash fault tolerance and Byzantine fault tolerance. Now we will look at some of the
1725550	1731870	existing approaches. One of the first approaches is the RANDAO approach, which is the acronym for
1731870	1736910	Random DAO. The general idea is that the participants in the network, first of all,
1736910	1743010	privately choose a pseudo random number. Submit a commitment to the privately chosen number. This
1743010	1748910	commitment could be implemented as a polynomial commitment or a Pedersen commitment. All agree
1748910	1755110	on some sort of commitment using a consensus algorithm. Then all reveal the chosen numbers,
1755110	1761390	reach a consensus on the revealed numbers, and have the XOR of the revealed numbers to be the
1761390	1766210	output of the protocol. This is a pretty straightforward approach, but there are
1766210	1775910	some limitations. It is fairly unpredictable, and it has liveness. We know liveness and safety are
1775910	1782770	two required properties of any consensus mechanism. This provides a great degree of liveness.
1782830	1790990	However, a malicious actor can observe the network once and start to reveal the numbers and choose
1790990	1798130	to reveal or not reveal the number based on the XOR of the number they observed. This allows a
1798130	1804250	single malicious actor to have one bit of influence on the output, and a malicious actor controlling
1804250	1809050	multiple participants have as many bits of influence as the number of participants they
1809050	1817490	are controlling. So there is a proposal, and there is a strong support in this direction,
1817490	1824170	which is to blend RANDAO plus VDF. We will talk about VDF in detail. First, let us understand
1824170	1830750	this approach. To make RANDAO unbiasable, one approach would be to make the output not just
1830750	1836170	an XOR, but something that takes more time to execute than the allocated time to reveal the
1836170	1841570	numbers. If the computation of the final output takes longer than the revealed phase, the malicious
1841570	1848850	actor cannot predict the effect of them revealing or not revealing the number. So we are talking
1848850	1855210	about a computation which is sequential, which cannot be paralyzed by a powerful malicious
1855210	1861730	adversary. Such a function that takes a long time to compute is fast to verify the computation,
1861730	1867350	and has a unique output for each input. It is called as verifiable delay functions,
1867350	1873470	and the design is extremely complex, which we will talk in detail. What is Ethereum's perspective
1873470	1879230	on RANDAO plus VDF? You can find numerous conversations on this in Ethereum research
1879230	1886250	led by Justin Drake and others. Ethereum presents a plan to use RANDAO with VDF as their randomness
1886250	1892170	beacon. Besides that fact, this approach is unpredictable and unbiasable. It has an extra
1892170	1897410	advantage that it has liveness, even if only two participants are online. This is a very
1897410	1904770	interesting property. It requires very, very less live participants compared to any other approach.
1904770	1911870	For the family of VDF linked above a special ASIC, it can be 100 times faster than conventional
1911870	1918310	hardware. That is why there is a strong effort and investment in Ethereum currently to build ASIC
1918850	1924950	hardware for VDFs. So if the reveal phase lasts only 10 seconds, for example,
1924950	1932210	VDF computed on such an ASIC must take longer than 100 seconds to have 10x safety. And
1932210	1938790	does the same VDF computed on the conventional hardware need to take 100x 100 seconds in three
1938790	1945990	hours? Hence, there comes a dependency on hardware. That is the challenge because of this approach or
1945990	1952450	the trade-off in this approach. Now let us look at an early approach which is fairly
1953650	1960810	very popular. This approach is pioneered by DFINITY. In fact, more than one year back or
1960810	1967690	two years back, DFINITY used BLS signature. What is BLS signature? It is known as Bonnet
1967690	1974070	Line Shazam Signature. One of the authors of this cryptographic scheme,
1974070	1980550	Ben Lin, is actually a member of DFINITY. What is this BLS signature? This is a scheme allowing
1980750	1987850	a user to verify that a signer is authentic. This scheme uses a bilinear pairing for verification.
1987850	1993410	We know about bilinear maps in elliptical cryptography, how powerful and formidable
1993410	1999730	they are. So this is a signature scheme built using bilinear pairings. BLS signature is a
1999730	2006190	construction which allows multiple parties to create a single signature on a message which
2006190	2012510	is often used to save the space and bandwidth by not requiring sending around multiple signatures.
2012510	2019070	This is a very interesting property and hence BLS signatures are becoming very popular
2019070	2027150	in more cryptocurrencies and blockchains. A common usage of BLS signatures is in signing
2027150	2035590	BFT protocols, for signing blocks in BFT protocol. When we look at threshold signatures in practice,
2036230	2041370	say there are 100 participants to create blocks and a block is considered final if
2042030	2048750	two by third of them, 67 of them sign on it. They can all submit the parts of the BLS signature
2049630	2056790	and then use some consensus algorithm to agree on 67 of them and aggregate them into a single
2056790	2064670	BLS signature. Any 67 parts can be used to create an accumulated or aggregated signature.
2064710	2071050	However, the resulting signature will not be the same depending on what 67 signatures are
2071050	2078910	aggregated. It turns out that the private keys that participants use are generated in a particular
2078910	2086150	fashion. Then no matter what 67 or less signatures are aggregated, the resulting multi-signature will
2086150	2092670	be the same. This can be used as a source of randomness. The participants first agree on
2092670	2097890	some message that they will sign. It could be an output from a rando or it could be the hash of the
2097890	2104890	block. It really doesn't matter as long as it is different every time and is agreed upon. So here
2104890	2113070	we are blending both randomness and an agreement to create a multi-signature on it. But this has
2113730	2119890	some limitations. The approach as we have seen earlier, even though this is unbiased and
2119890	2125130	unpredictable and is live as long as two by third of the participants are online, though this can
2125130	2131610	be configured to any threshold, while this one by third offline or misbehaving participants can
2131610	2137750	stall the algorithm, it takes at least two by third participants to cooperate to influence the output.
2138530	2145310	This is a big overhead when you consider a live blockchain system. Private keys in the
2145310	2150730	scheme need to be aggregated in a particular fashion. And this process is known as distributed
2150730	2157990	key generation. And this is something which is an ongoing area of research. And there is another
2157990	2164770	interesting approach called ran-share approach. Ran-share approach is an unbiased and unpredictable
2164770	2171290	protocol which can tolerate up to one by third of actors being malicious. It is relatively slow
2171290	2178010	and the paper linked also describes two ways to speed it up called ran-hound and ran-herd.
2178010	2183910	But unlike ran-share, ran-hound and ran-herd are relatively complex. When you look at the
2183910	2188770	details in the paper, you can understand. The general problems of ran-share, besides the large
2188770	2193870	number of message exchange, it requires a lot of back and forth communication between the participants.
2193950	2203650	In fact, O to the O n to n cube messages are required. So this is kind of a gossip.
2203650	2214030	While one by third of the meaningful threshold for liveness is only there, it is low for the
2214030	2221050	ability to influence the output. So the challenge, one is the overhead because of the number of
2221050	2227170	communications required. And second, the number of live participants required.
2227830	2234430	So this is the challenge. The benefit from influencing the output can
2234430	2240450	significantly outweigh the benefit of stalling randomness. Am I audible now?
2241070	2252870	Keshav, can you confirm? Am I audible? Yes sir, you are audible. Okay. So let us continue.
2252870	2259670	The benefit from influencing the output, this is one trade-off when we consider a randomness design.
2259690	2266050	So either the adversary can stall the randomness or influence the output. So this is what we have
2266050	2271330	to see in Rancher approach. If participants control more than one by third of the participants
2271930	2277490	in Rancher and use this to influence the output, it leaves no trace. This is a challenge.
2277490	2283310	Thus, a malicious actor can do it without even ever being revealed. Stalling a consensus
2283950	2291610	is always visible. So if somebody stalls a consensus or creates a fork or disrupts the
2291610	2297130	network, this is visible. But if they influence the output, that leaves no trace. So that is
2297130	2305190	the two aspects of this challenge. And then there are situations in which someone controls one by
2305190	2311790	third of the hash power, having a very powerful machine, a SIG miner or some kind of a very
2311790	2320410	powerful staking pool. So we can't always say that that is an unimaginable or impossible situation.
2320410	2328750	And hence, this Rancher approach creates some kind of a doubt or uncertainty.
2329050	2340310	So we should look at the Near Protocol approach in this scenario. What Near Protocol has done,
2340310	2346890	sharding implementation for Ethereum 2, like a candidate for Ethereum 2, and now they are
2346890	2353570	building the protocols as a separate protocol. So what happens in Near Protocol?
2353570	2359510	They have come up with an approach called erasure code. Let us understand what is this erasure code.
2359750	2366770	Each participant comes up with their part of the network, split it into 67 parts. So this
2366770	2374650	erasure code, it is generated to obtain 100 shares such that any 67 are enough to reconstruct
2374650	2381450	the output. And then they can assign each of the 100 shares to the participants and encode it with
2381450	2388710	the public key of that participant. Then they can share all the encoded shares. Participants use
2388710	2394070	some of the consensus. It could be any Lidl-based protocol like Tendermint to agree on such encoded
2394070	2402470	set extracted from the 67 participants. Once the consensus is reached, each participant takes the
2402470	2409590	encoded sharing, each of the 67 sets published this way, that is encoded with their public key,
2409590	2416890	then decodes all such share and publishes all such decoded shares at once. Once at least 67
2416890	2423470	participants did in the previous step, all agreed upon the sets fully can be decoded and reconstructed,
2423470	2427430	the final number can be obtained as an XOR of the initial part of the participants
2427930	2432950	which came up in the first step. The idea why this protocol is unbiasable and unpredictable
2433390	2439510	is similar to the rand share and threshold signature approach. The final output is decided
2439510	2445910	once the consensus is reached, but is not known to anyone until two by third of the participants
2445910	2454670	decrypt shares encrypted with their own public key. So when we look at all these previous approaches,
2454670	2461770	on one side we can see the verifiable delay functions very solid with the cryptographic
2461770	2468570	technique and threshold signatures also a cryptographic scheme. We can see that randavo,
2468570	2477550	randshare, and the erasure code from near protocols, these are all specific consensus-based
2477550	2484190	approaches. So one side we have threshold signatures, verifiable delay functions, other side
2484190	2493090	we have randshare, randhound, and randherd. Now let us look at verifiable delay functions in detail.
2494010	2498550	What is an anatomy of a VDF? A VDF consists of triple of algorithms.
2498570	2506590	Setup, evaluate, and verify. A setup takes two parameters, lambda and t,
2506590	2514910	the security parameter lambda and the delay parameter t. And it generates a public parameter pp
2515710	2521450	which can fix the domain and range of the VDF. And we can add some additional information necessary
2521450	2527490	to compute or verify it. The second phase is evaluation phase, where you take the public
2527490	2533530	parameter from the previous phase and an input x from the domain and generate an output value y
2533530	2542230	in the range and generate a short proof pi. Finally in the verification phase you use the
2542230	2548770	combination of public parameter x y and pi efficiently to verify that y is the correct
2548770	2556810	output on x. So crucially for every input x there should be unique output of y. When you look at the
2556810	2564290	historic inspirations to VDF, we should first look at the early works of Cynthia Dwork and Moni Navor
2564610	2571970	in early 1990s, who suggested using squaring roots over finite fields, finite field-based
2571970	2577710	puzzles as functions which take a predetermined time to compute and are very straightforward to
2577710	2585590	verify. Incidentally the same Cynthia Dwork and Moni Navor has inspired Satoshi Nakamoto
2585590	2591970	in his pioneering work on peer-to-peer cash in Bitcoin. However their work was considered
2591970	2599050	impractical then because one has to use rather large finite fields to make algorithms useful.
2599090	2603350	And libraries for handling multiple precision arithmetic at the time of the suggestion was
2603350	2609210	order of magnitude slower than the current ones. So we can see that even a lot of promises
2609210	2615290	on elliptical curve cryptography which uses finite fields came only in the early 2000s.
2615590	2621110	What are the essential properties of VDF? Now we have seen how do we construct a VDF.
2621110	2626950	What are the essential properties? Firstly it has to be sequential. Honest parties can compute
2626950	2635910	y and pi given we have public parameter nx in t sequential steps while no parallel machine
2635910	2640130	adversary with a polynomial number of processors can distinguish the output
2641030	2647690	y from random input significantly in fewer steps. So this is very important.
2647690	2655310	The output should be indistinguishable with any other randomness even if the adversary has
2655990	2661730	a polynomial number of processors so that they can compute they can execute all of them
2662190	2667090	in a very efficient polynomial time. They should not be able to distinguish this
2667090	2673210	output from VDF from other randomness and it should be efficiently verifiable.
2673970	2678810	The verify operation should be as fast as possible for honest parties to compute.
2679010	2686350	So the verification time should be as small as polynomial logarithm of the time taken to
2686350	2693730	generate it or construct it and it should be unique as we said before for every input x
2693730	2701030	it should be difficult to find an y for which the same combination of public parameters
2701030	2709330	x y and pi gives the same output. Now there are some more additional properties of VDF very
2709330	2715190	important for actual implementation. One of the first one is it should be decodable. A VDF is
2715190	2721470	decodable if there exists a decoding algorithm such that the combination of evaluate and decode
2721470	2727890	form a lossless encoding scheme. This is very much required for a practical use of VDF and
2727890	2736890	it should be implemented. Hi sir, sorry for interrupting. Yes. So we can take like 10
2736890	2744490	more minutes because it's already like just 30. So yep. Yeah, I'll move fast. So the second
2744490	2751130	property is the incremental property which will help us to compute the output with zero knowledge
2751130	2758010	proofs or any recursive proofs and the size should be smaller. And the main innovations if
2758010	2764690	you look at the main VDF constructions are the first construction is in the original paper by
2764690	2773850	Dan Bone, Ben Fish and others in 2018 which uses injective rational maps. But however this is a
2773850	2780710	very complex implementation and hence even the author said this is a weak VDF. Later two other
2780710	2787750	approaches were proposed by Paisarch and other by Veselovsky independently arriving at extremely
2787750	2794390	similar constructions but more practical by using repeated squaring in groups of unknown order.
2794390	2799070	These constructions are based on modular exponentiation arithmetic where Paisarch
2799470	2806210	and Veselovsky suggested to iteratively compute squarings in RSA groups with a large
2807090	2815050	prime modulus. Innovations in VDF. One very crucial difference in VDF with others is VDF
2815050	2822990	has a setup phase. Within the setup phase we set the public parameters for configuring the VDF.
2822990	2829110	So any node who need to solve the VDF will use the public parameters. And some VDF also allow
2829110	2834330	generating a proof so that you can use this in conjunction with the computational proofs of
2834330	2841770	integrity and we can use it in a multi-party computation setup. Now let us see how we can
2841770	2848730	use VDF for DDoS prevention. One of the first approach for using VDF for DDoS prevention was
2848730	2857470	from IOTA. IOTA is a IOT ledger which uses tangled consensus which is not strictly a blockchain but
2857470	2862370	they have come up with a lot of innovations in cryptography in the past like they have adopted
2862370	2868770	windermere's one-time signature. So what IOTA has implemented is a DDoS prevention mechanism.
2868770	2877070	IOTA is actually an IOT ledger with heterogeneous IOT devices. So they propose to use VDF for
2877070	2882310	VDF as a DDoS prevention mechanism where nodes are required to compute exactly
2883010	2890290	the prime modular squarings for an input message. Calibrating the VDF evaluation on different
2890290	2895690	hardware and optimizing the time need to verify the correctness of the puzzle through multi-
2895690	2900570	exponentiation techniques. That is what they have done. So what they have done is they have used
2900570	2908650	different kind of hardware like laptops, FPGAs and different IOT hardwares like Raspberry Pis
2909170	2916470	and different other devices and then they optimize the time. They continuously calibrated what would
2916470	2927150	be the time for constructing the VDF, evaluating the VDF and verifying the VDF. So they compared it
2927150	2934590	with for their purpose. Actually IOTA doesn't have a system like a proof of stake. Hence their concern
2934590	2942490	was how to use it instead of proof of work and that's how they use VDF. So how did they use it?
2942490	2949910	In the evaluation phase, every node decides to generate a transaction and all those nodes need
2949910	2957610	to solve a VDF such that the input is the hash of the transaction issued by the same node and the
2957610	2963710	proof that they generate. The node also generated proof to facilitate the verification task which
2963710	2969490	gossip along with the transaction. So they share the proof along with the transaction. Verification
2969490	2976830	happens when a new transaction is received. A particular node verifies whether the VDF is
2976830	2983490	solved correctly by the node which sent the transaction. If yes, it forward the transaction.
2983490	2990130	In IOTA, it has some kind of tipping mechanism or forward mechanism where every node
2990130	2996050	which receives an input has to send it to two other nodes. That is how the tangle works.
2996050	3001550	Let us look at how VDF integration is implemented in IOTA. There are evaluators
3002130	3009130	and evaluators evaluate and generate the proof from the input to the VDF. They use both hash and
3009130	3015270	the VDF and then when they generate transaction, transaction nodes will have VDF in it and then
3015270	3022030	the verifier will verify whether the VDF is accurate which they can do it fast. If it is true,
3022030	3026890	they broadcast to neighbor. If it is false, they discard it. We can configure the difficulty
3027450	3034290	and the modulus in this VDF implementation IOTA. This is an important property which is mentioned.
3034290	3039290	VDF difficulty can be configured that determines the number of sequential operations to solve
3039290	3047650	and update the VDF. The second one, the prime modulus, the RSA modulus which we use for the RSA
3047650	3053370	based groups of unknown order. And the third thing, they also use a cryptographic hash function.
3054190	3061690	Now let us quickly talk about our approach. Our approach is based on a closer view at what is
3061690	3068350	required for Ethereum 2.0 and what are the current capabilities we have in 2.0 like sharding, stake
3068350	3076670	and random oracles and also the presence of different proof, zero-knowledge proof implementations.
3076670	3083250	But one key difference what we would like to propose is, we are proposing VDF based on
3083250	3091090	super-singular isogenic cryptography, not based on the RSA based unknown groups of unknown order
3091090	3098890	approach or adiabatic adaptive root assumption approach of PISTRAC and Wyslawowski. We also
3098890	3105750	wanted to bring in an approach known as single secret leader selection. And we want to use this
3105750	3113530	VDF for selecting a secret leader, a single secret leader from data shards each time.
3113530	3119470	And we also want to use them in conjunction with random oracles. And we want to authenticate the
3119470	3125230	nodes participating in stake mechanism using VDF based delay authentication,
3125230	3131310	which is also proposed recently. And then we want to use randomness,
3131310	3136650	ran-share and ran-hound powered beacon chain. So this is how we visualize our approach.
3136650	3145550	We use isogeny based VDF generator and these VDF generators will be used to create random oracles.
3145790	3152550	These random oracles will source to the shard chains with ran-hound and ran-share. And that's
3152550	3158410	how we decide which shard to move in the proximity. And then the shards will be part of the beacon
3158410	3164570	chain where we will have a secret single leader selection and delay authentication. And then
3165330	3170030	finally, which will be added to the main chain based on...
3170030	3175950	Hi sir, sorry again for interrupting. Ajit sir is saying we can like conclude our talk.
3175950	3180230	So we can just quickly wrap up and just talk about the isogeny, right?
3180230	3186090	Yeah, I'll just quickly show what we have. We have already done a prototype on this random oracle
3186090	3194450	using the VDF from the software. You can see the code in our repository. And we also giving
3194450	3199410	the highlight of the single secret leader selection mechanism. You can find the research
3199410	3205890	paper which is substantiating this again from Dan Boneh and the node topology. And please let me
3205890	3212830	hand over to Tejas to talk about the beautiful aspects of isogeny based VDF quickly.
3213630	3220370	So, hey everyone. I will just quickly wrap up our presentation and we are just in more finale.
3220450	3227830	And I will just quickly talk about the isogeny based VDF. Now, what is an isogeny? It is based
3227830	3235570	on the idea of elliptic curve cryptography and Diffie-Hellman key exchange. So in isogeny,
3235570	3240650	there are a group of elliptic curves. So you can think about that there are two elliptic curves,
3240650	3248270	E1 and E2. We can do a mapping or a function of like, let's say, point P from elliptic curve E1
3248270	3256750	to point Q at elliptic curve E2. And this mapping is called as the isogeny. Now, our secret here is
3256750	3263810	then the isogeny here and the public key you can think about as the elliptic curve. And we can do a
3263810	3270090	secret share exchange by mixing our secret key with other side's elliptic curve. Next slide.
3271010	3282550	Next. Next, moving on. So, yep, let's see a quick construction. So we'll set up, we'll take
3282550	3287990	prime number n, we'll take a supersingular curve E, and performing a random non-backtracking
3287990	3295090	walk of length t, have as outcome the isogeny phi, and its dual as phi dash. I call it as phi dash.
3295090	3299410	Now, choosing a point P, we'll compute the isogeny of the point P,
3299410	3306010	and there will be output as isogeny dual, the elliptic curves E and E dash, the point P,
3306010	3315190	and the isogeny of point P. Next. This is how isogeny look like, mapping between two elliptic
3315190	3325750	curves. Next. And the final slide, how the evaluation and verification works in an isogeny
3325750	3333730	based medium. So for the evaluation, if we are receiving a random point Q, we have to compute
3333730	3344090	the isogeny dual of that point Q. And for the verification part, we will refer to our previous
3344090	3350070	knowledge of the slides, which were field pairings. So how the verification can be done,
3350070	3356650	just simply a field pairing of the point P with the isogeny dual of the point Q,
3356650	3363090	and that should be equal to the field pairing of isogeny of the point P and the point Q.
3363090	3368790	So having said that, we are done with our presentation, and I will hand over to Gokul
3368790	3376950	sir to say the final words. It's a great honor for us to present our compilation of thoughts on
3377510	3385590	applying powerful properties of randomness, unbiased randomness and entropy, for the
3385590	3392790	overall transformation of the consensus and cryptography and to make Ethereum 2.0 much
3392790	3400330	more stronger and make sure that every chance of DDoS attack can be prevented from the sharding,
3400330	3406690	shard to the main chain itself. Overall, so this is a randomness engineering that we propose.
3406690	3411950	We have done our first level of prototype. We would like to move to the next level by
3411950	3419910	integrating isogeny VDF from the SIDS library and the SS-isogeny library. And then we would
3419910	3426770	also want to blend single secret leader selection, and we would like to do it on the RANDAO.
3426930	3432030	We have already participated in the Starkware VDF hackathon. We have used the
3432030	3439610	VDF from Starkware and built random oracles and applied on RANDAO. Now we are excited to go
3439610	3445370	forward. Thank you so much again for Blockchain Village, DEF CON for giving us this opportunity.
3445370	3450910	It's an honor. It's a lifetime opportunity for us. Thank you so much once again. Looking forward
3450910	3452550	to your questions and comments.