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.
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.
So wrapping up a quick speaker's introduction. So here am I. My name is Tejasura Sogi. I'm a
penetration tester, a blockchain security researcher, founder of RazerSec which is a
community that helps people to learn about blockchain security. I'm also a YouTuber as
RazerSharp. I post security content on YouTube and the most important thing I'm a cybersecurity
enthusiast. I love the world of internet. With that I will ask my partner Mr. Gokul Alex to say
a few words about him. Thank you Tejasura. Hi everyone this is Gokul Alex. It's my pleasure
and privilege to present in this platform in DEF CON in front of every one of you.
I'm the founder of Epic Knowledge Society, one of the fastest growing digital education platform
for engineers and entrepreneurs in India. We are a non-profit organization. I am also building a
blockchain protocol integrating off-chain and on-chain data called Fusion Ledger. I am
representing a collection of cryptocurrencies and platforms in India such as Algorand, Eternity,
Elixir, Hashgraph, Horizon and Tezos. I'm also the director of Tezos India Foundation
and I've been selected as the MVP for Hedera Hashgraph in 2018. I am a global leader for
XS collective created by David Choum known as the godfather of cryptography
and blockchain technology. I am a programmer and poet in my personal life. I've been a blockchain
security auditor for government, public sector and private sector across various countries. I am
actively researching on the convergence of quantum algorithms and post-quantum cryptography.
Over to Tejeshwar to get start with the presentation. Awesome! 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. So let's talk about what is proof-of-work consensus algorithm.
Now before that let's talk about what are consensus algorithm. 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. Now
consensus algorithms is all about building fault-tolerant, fault-resilient machines for
distributive computing. Now our talk is about the convergence of cryptographic schemes and
consensus algorithms. Now consensus algorithms have both deterministic and probabilistic
dimensions right. Now consensus algorithms helps us to achieve a consistent state and agreement
between participating nodes in a blockchain network. Getting back to our proof-of-work
consensus algorithm. Now in proof-of-work consensus algorithm there are miners who
compete with each other for the potential valid block creation right.
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. 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. Now let's move on to some of the attack vectors
or proof-of-work. 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. Now let's talk
over this attack. 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. Now in most of the
blockchain these sudden changes in the processing power are not addressed by the nodes. They can be
addressed by the nodes at a scheduled update. Now let's take a scenario. Let's take a scenario of
like there are nine machines on a blockchain network and six of them are malicious actors.
Six of them are malicious actors. Now they are not doing anything and just chilling in the network.
Everything is going as planned. Mining difficulty is working as the way it should. Block creation
is happening at a certain frequency and everything is perfect. Now suddenly what the malicious
actors decide they decide to turn their machines down. 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. So there are other attacks as well
like routing attack. So routing attack consists of two parts. 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. Moving on and there are
user wallet attacks. Then there are smart contract attacks, transaction verification mechanism
attacks and there you can see the well-known 51% of majority attack. Now what is this 51%
of majority attack. 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. Now how it can be possible as we know that there is a race between miners
for the potential valid block creation. Now if there is a group of malicious actors
which is in majority. Now it will have this group will have a higher and better probability
to be for the block creation. So this is the 51% attack. Moving on there are some mining pool
attacks like selfish mining, forecaster, withhold and like that. So moving on let's talk over DDoS
on ethereum. Now there are some attacks that happened on ethereum or there are scenarios as
well. So we'll pick up some of them like there was an attack on parity client. So what was the
incident like some parity ethereum nodes lost sync with the network because of the following
incident. Now what was the incident that if you send to a parity node a block with invalid
transaction what will happen. 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.
Moving on there was a vulnerability that was found in parity nodes as well. 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. 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. So moving on and there is an interesting underpriced DDoS attacks. Now these are a group
of attacks which exploited the vulnerability in the improper cast cost of EVM's opcodes. Now the
opcodes were the ext code size and the suicide opcode. The suicide opcode was renamed to self
destruct after eip6. We'll talk about that in the next slide. 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. 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.
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. 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.
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. 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. 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. Now what was the impact? It created
millions of dead ethereum accounts and also bloated the state database. Now it also created
tons of transaction freezes as well. 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. Hacks can be created
against huge amount of cleanup transactions and each cleanup transaction creates large set of
freezes. 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. 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.
Moving on to let's talk about the attack vectors on proof of stake. Now before covering the attack
vectors let's do a quick refresher again on the proof of stake consensus algorithm.
Now proof of stake is a popular alternative to proof of work. In proof of stake there are
validators instead of miners and a validator is selected to forge a block. 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. And proof of stake has many advantages
over proof of work. The first is obviously the security. It provides a better security mechanism
against 51% attack. Now as we know like in proof of work owning 51% of the computational power
meaning means like gaining control over of the network. But in proof of stake
owning 51% of the stakes would be very would be computationally very expensive for an attacker.
So that's how it provides a better security. Also it provides better it's energy efficient
and provides energy savings. 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. And there is a casper protocol based on proof of stake. It provides its own security
implications like this slashing mechanism which provides slashing of stakes as a penalty
to the validator. 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.
So this was casper protocol. Moving on to let's see some of the attack vectors attacks against
proof of stake. You can see a list of attacks in front of the screen. There is a fake stake attack
a very interesting attack. Now fake stake attack can be think about as a denial of service. An
attacker can devote a node's valuable memory and cpu to a fake chain. Now we know there is a
longest chain rule that any chain can suddenly become the accepted version of the ledger.
Now validation of a proof in proof of stake is kind of complex. Now it required
access to both the block header as well as the contents of block. So like to trigger the stake
value for the validator selection right and forcing the node to download data to validate
fake blocks. It consumes valuable resources for the node and can eventually result into a denial
of service. So fake stake attack can be think about as a denial of service and proof of stake.
Moving on to let's see the 3m 2.0 architecture.
In front of your screen you can see a beautiful picture defining the road map to serenity.
Then there is the current blockchain showing proof of work and proof of stake together.
And then you can see a little bit detailed architecture. Like there is a main chain
based on proof of work. Then there is a beacon chain based on the casper ffg protocol,
proof of stake protocol that we just discussed. And random number generation happens. Now you
can see that the beacon chain is cross-linked with the shard chain and underneath there is
execution engine as well. Moving on to see some of the 3m 2.0 audit findings. Talking about the
Constem audit first. Now Constem did an audit as well and founded some DDoS attack vectors,
attack vectors and reported them. Like DDoS attack through creating a mapping between
public keys and validator IPs. Also DDoS attack on insecure gRPC connection.
So what was the Constem audit? Basically it involved 10 engineers who examined the entire
code base over the course of two months. They examined the beacon node logic,
validator client, flasher logic and almost everything.
So what were the findings? They found a lot of vulnerabilities. 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.
Now let's talk about the least authority audit as well. So they did an audit over various subsections
like they did a audit over block proposal system. What were the findings? 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. With the information leak passed, the block proposer remains as protected as it is.
It would be in proof of work chains but without the computational overhead.
We're talking about the findings on a gossip protocol. Now gossip protocols generally suffer
from the spam problem. 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.
This was one of the primary concerns in examining the network layer. In Ethereum 2.0,
when a node proposes a new finalized block, the block must be sent to the rest of the network.
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.
Also, there were findings on slashing messages that we just discussed earlier, the Casper
protocol security implication. 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. Now moving on to talk about DDoS on Ethereum 2.0. Let's take
the recently happened Teku attack scenario. Now there were security engineers who
did research over public antagonists. They found a Teku attack, created a Teku attack.
Now what was the scenario like? Two of the four Teku nodes were targeted by five ordinary machines
with a sustained DDoS attack. Now what was the impact? 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. Now what was the implementation? You can see a command in front of your screen.
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. But stay off AWS and IPS
radars to ensure the attack continuous. Also the data is then piped back into the netcat command
which sends it to the nodes under attack. The while loop is there for when it loses connectivity
and command compiles due to container restarts.
And moving on to what was the impact of this Teku attack. 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. Now the nodes under attack
used large amounts of memory while subject to multiple container restarts. Had trouble
staying connected to peers and even once nodes local clock was like 20 minutes slow.
Moving on to the Teku attack root cause. Now firstly responding to one byte when multiple
bytes is a vector. We know for various amplification attacks that we know. But
that was not the issue that caused the loss of finality. 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. Eventually the TCP backpressure kicked in,
filled up the OS write buffers and the responses wound up being queued in user space memory.
This pushed up both the on and off heap memory usage very substantially.
Also CPU spikes significantly partly due to the processing power.
All those due to processing all those multi-stream messages but mostly because of the resultant
memory pressure and GC activity. Now talking about what can be a solution. It's like there
can be a straightforward solution like disconnect the peer immediately when an invalid example like
multistream message is received. 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. So this was the takeover attack. We covered
consensus algorithms. We talked over proof-of-work, proof-of-stake. We took
different attacks, attack vectors as well. We talked over 51% attack, denial of service. We
have seen the ATM 2.0 architecture. Also the security implications of cash flow protocol.
Now my partner Mr. 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. So over to you sir.
Thank you Tejaswar for setting the context, for researching on the randomness in Ethereum 2.0.
We will see how randomness is very crucial to the overall engineering and overall design of
Ethereum 2.0. 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.
Both the randomness and the validator assignment require computation that is not specific to any
shard. For this computation, existing designs have a separate blockchain that is tasked with
performing operations necessary for maintenance of the entire network. Besides generating these
random numbers and assigning validators to the shards, these operations also include receiving
updates from shards and taking snapshot of them. This is very important. The shards and taking
activity. In older times, we used to take additions, cut additions from the databases.
The snapshots are the read-only versions. 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. 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. But we have to understand, we cannot afford any simple randomness. We need distributed
randomness on blockchain. That is why randomness in blockchain becomes much more complex and more
challenging. So many blockchains, if you know, blockchains have different purpose of using
randomness. 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. What happens if a malicious actor can influence such a source of randomness? They
can increase the chance of being selected and possibly compromise the security of the protocol.
And like we said, distributed randomness is very crucial building block for any kind of
applications on blockchain. What are the essential properties of randomness required
in a blockchain setup? There are three essential properties laid out. First, it needs to be
unbiased. We cannot afford a biased source of entropy. In other words, no participant shall be
able to influence in any way the outcome of the random generator. Second, it needs to be
unpredictable. In other words, no participant shall be able to predict what number will be generated,
or what are the properties of it. 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. Now we will look at some of the
existing approaches. One of the first approaches is the RANDAO approach, which is the acronym for
Random DAO. The general idea is that the participants in the network, first of all,
privately choose a pseudo random number. Submit a commitment to the privately chosen number. This
commitment could be implemented as a polynomial commitment or a Pedersen commitment. All agree
on some sort of commitment using a consensus algorithm. 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. This is a pretty straightforward approach, but there are
some limitations. It is fairly unpredictable, and it has liveness. We know liveness and safety are
two required properties of any consensus mechanism. This provides a great degree of liveness.
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. 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. So there is a proposal, and there is a strong support in this direction,
which is to blend RANDAO plus VDF. We will talk about VDF in detail. First, let us understand
this approach. 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. 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. So we are talking
about a computation which is sequential, which cannot be paralyzed by a powerful malicious
adversary. Such a function that takes a long time to compute is fast to verify the computation,
and has a unique output for each input. It is called as verifiable delay functions,
and the design is extremely complex, which we will talk in detail. What is Ethereum's perspective
on RANDAO plus VDF? You can find numerous conversations on this in Ethereum research
led by Justin Drake and others. Ethereum presents a plan to use RANDAO with VDF as their randomness
beacon. Besides that fact, this approach is unpredictable and unbiasable. It has an extra
advantage that it has liveness, even if only two participants are online. This is a very
interesting property. It requires very, very less live participants compared to any other approach.
For the family of VDF linked above a special ASIC, it can be 100 times faster than conventional
hardware. That is why there is a strong effort and investment in Ethereum currently to build ASIC
hardware for VDFs. 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. And
does the same VDF computed on the conventional hardware need to take 100x 100 seconds in three
hours? Hence, there comes a dependency on hardware. That is the challenge because of this approach or
the trade-off in this approach. Now let us look at an early approach which is fairly
very popular. This approach is pioneered by DFINITY. In fact, more than one year back or
two years back, DFINITY used BLS signature. What is BLS signature? It is known as Bonnet
Line Shazam Signature. One of the authors of this cryptographic scheme,
Ben Lin, is actually a member of DFINITY. What is this BLS signature? This is a scheme allowing
a user to verify that a signer is authentic. This scheme uses a bilinear pairing for verification.
We know about bilinear maps in elliptical cryptography, how powerful and formidable
they are. So this is a signature scheme built using bilinear pairings. 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.
This is a very interesting property and hence BLS signatures are becoming very popular
in more cryptocurrencies and blockchains. A common usage of BLS signatures is in signing
BFT protocols, for signing blocks in BFT protocol. 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. 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. Any 67 parts can be used to create an accumulated or aggregated signature.
However, the resulting signature will not be the same depending on what 67 signatures are
aggregated. It turns out that the private keys that participants use are generated in a particular
fashion. Then no matter what 67 or less signatures are aggregated, the resulting multi-signature will
be the same. This can be used as a source of randomness. The participants first agree on
some message that they will sign. It could be an output from a rando or it could be the hash of the
block. It really doesn't matter as long as it is different every time and is agreed upon. So here
we are blending both randomness and an agreement to create a multi-signature on it. But this has
some limitations. 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, it takes at least two by third participants to cooperate to influence the output.
This is a big overhead when you consider a live blockchain system. Private keys in the
scheme need to be aggregated in a particular fashion. And this process is known as distributed
key generation. And this is something which is an ongoing area of research. And there is another
interesting approach called ran-share approach. Ran-share approach is an unbiased and unpredictable
protocol which can tolerate up to one by third of actors being malicious. It is relatively slow
and the paper linked also describes two ways to speed it up called ran-hound and ran-herd.
But unlike ran-share, ran-hound and ran-herd are relatively complex. When you look at the
details in the paper, you can understand. 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.
In fact, O to the O n to n cube messages are required. So this is kind of a gossip.
While one by third of the meaningful threshold for liveness is only there, it is low for the
ability to influence the output. So the challenge, one is the overhead because of the number of
communications required. And second, the number of live participants required.
So this is the challenge. The benefit from influencing the output can
significantly outweigh the benefit of stalling randomness. Am I audible now?
Keshav, can you confirm? Am I audible? Yes sir, you are audible. Okay. So let us continue.
The benefit from influencing the output, this is one trade-off when we consider a randomness design.
So either the adversary can stall the randomness or influence the output. So this is what we have
to see in Rancher approach. If participants control more than one by third of the participants
in Rancher and use this to influence the output, it leaves no trace. This is a challenge.
Thus, a malicious actor can do it without even ever being revealed. Stalling a consensus
is always visible. So if somebody stalls a consensus or creates a fork or disrupts the
network, this is visible. But if they influence the output, that leaves no trace. So that is
the two aspects of this challenge. 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. So we can't always say that that is an unimaginable or impossible situation.
And hence, this Rancher approach creates some kind of a doubt or uncertainty.
So we should look at the Near Protocol approach in this scenario. 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. So what happens in Near Protocol?
They have come up with an approach called erasure code. Let us understand what is this erasure code.
Each participant comes up with their part of the network, split it into 67 parts. So this
erasure code, it is generated to obtain 100 shares such that any 67 are enough to reconstruct
the output. And then they can assign each of the 100 shares to the participants and encode it with
the public key of that participant. Then they can share all the encoded shares. Participants use
some of the consensus. It could be any Lidl-based protocol like Tendermint to agree on such encoded
set extracted from the 67 participants. 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. 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. The idea why this protocol is unbiasable and unpredictable
is similar to the rand share and threshold signature approach. 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. 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. We can see that randavo,
randshare, and the erasure code from near protocols, these are all specific consensus-based
approaches. So one side we have threshold signatures, verifiable delay functions, other side
we have randshare, randhound, and randherd. Now let us look at verifiable delay functions in detail.
What is an anatomy of a VDF? A VDF consists of triple of algorithms.
Setup, evaluate, and verify. A setup takes two parameters, lambda and t,
the security parameter lambda and the delay parameter t. And it generates a public parameter pp
which can fix the domain and range of the VDF. And we can add some additional information necessary
to compute or verify it. 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. 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. So crucially for every input x there should be unique output of y. 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. Incidentally the same Cynthia Dwork and Moni Navor has inspired Satoshi Nakamoto
in his pioneering work on peer-to-peer cash in Bitcoin. However their work was considered
impractical then because one has to use rather large finite fields to make algorithms useful.
And libraries for handling multiple precision arithmetic at the time of the suggestion was
order of magnitude slower than the current ones. So we can see that even a lot of promises
on elliptical curve cryptography which uses finite fields came only in the early 2000s.
What are the essential properties of VDF? Now we have seen how do we construct a VDF.
What are the essential properties? Firstly it has to be sequential. 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. So this is very important.
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. They should not be able to distinguish this
output from VDF from other randomness and it should be efficiently verifiable.
The verify operation should be as fast as possible for honest parties to compute.
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. Now there are some more additional properties of VDF very
important for actual implementation. One of the first one is it should be decodable. A VDF is
decodable if there exists a decoding algorithm such that the combination of evaluate and decode
form a lossless encoding scheme. This is very much required for a practical use of VDF and
it should be implemented. Hi sir, sorry for interrupting. Yes. So we can take like 10
more minutes because it's already like just 30. So yep. Yeah, I'll move fast. 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. 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. But however this is a
very complex implementation and hence even the author said this is a weak VDF. 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.
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. Innovations in VDF. One very crucial difference in VDF with others is VDF
has a setup phase. Within the setup phase we set the public parameters for configuring the VDF.
So any node who need to solve the VDF will use the public parameters. 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. Now let us see how we can
use VDF for DDoS prevention. One of the first approach for using VDF for DDoS prevention was
from IOTA. 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. So what IOTA has implemented is a DDoS prevention mechanism.
IOTA is actually an IOT ledger with heterogeneous IOT devices. 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. Calibrating the VDF evaluation on different
hardware and optimizing the time need to verify the correctness of the puzzle through multi-
exponentiation techniques. That is what they have done. 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. They continuously calibrated what would
be the time for constructing the VDF, evaluating the VDF and verifying the VDF. So they compared it
with for their purpose. Actually IOTA doesn't have a system like a proof of stake. Hence their concern
was how to use it instead of proof of work and that's how they use VDF. So how did they use it?
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. The node also generated proof to facilitate the verification task which
gossip along with the transaction. So they share the proof along with the transaction. Verification
happens when a new transaction is received. A particular node verifies whether the VDF is
solved correctly by the node which sent the transaction. If yes, it forward the transaction.
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. That is how the tangle works.
Let us look at how VDF integration is implemented in IOTA. There are evaluators
and evaluators evaluate and generate the proof from the input to the VDF. 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. If it is true,
they broadcast to neighbor. If it is false, they discard it. We can configure the difficulty
and the modulus in this VDF implementation IOTA. This is an important property which is mentioned.
VDF difficulty can be configured that determines the number of sequential operations to solve
and update the VDF. The second one, the prime modulus, the RSA modulus which we use for the RSA
based groups of unknown order. And the third thing, they also use a cryptographic hash function.
Now let us quickly talk about our approach. 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.
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. We also
wanted to bring in an approach known as single secret leader selection. And we want to use this
VDF for selecting a secret leader, a single secret leader from data shards each time.
And we also want to use them in conjunction with random oracles. And we want to authenticate the
nodes participating in stake mechanism using VDF based delay authentication,
which is also proposed recently. And then we want to use randomness,
ran-share and ran-hound powered beacon chain. So this is how we visualize our approach.
We use isogeny based VDF generator and these VDF generators will be used to create random oracles.
These random oracles will source to the shard chains with ran-hound and ran-share. And that's
how we decide which shard to move in the proximity. And then the shards will be part of the beacon
chain where we will have a secret single leader selection and delay authentication. And then
finally, which will be added to the main chain based on...
Hi sir, sorry again for interrupting. Ajit sir is saying we can like conclude our talk.
So we can just quickly wrap up and just talk about the isogeny, right?
Yeah, I'll just quickly show what we have. We have already done a prototype on this random oracle
using the VDF from the software. You can see the code in our repository. And we also giving
the highlight of the single secret leader selection mechanism. You can find the research
paper which is substantiating this again from Dan Boneh and the node topology. And please let me
hand over to Tejas to talk about the beautiful aspects of isogeny based VDF quickly.
So, hey everyone. I will just quickly wrap up our presentation and we are just in more finale.
And I will just quickly talk about the isogeny based VDF. Now, what is an isogeny? It is based
on the idea of elliptic curve cryptography and Diffie-Hellman key exchange. So in isogeny,
there are a group of elliptic curves. So you can think about that there are two elliptic curves,
E1 and E2. 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. And this mapping is called as the isogeny. Now, our secret here is
then the isogeny here and the public key you can think about as the elliptic curve. And we can do a
secret share exchange by mixing our secret key with other side's elliptic curve. Next slide.
Next. Next, moving on. So, yep, let's see a quick construction. 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. I call it as phi dash.
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. Next. This is how isogeny look like, mapping between two elliptic
curves. Next. And the final slide, how the evaluation and verification works in an isogeny
based medium. So for the evaluation, if we are receiving a random point Q, we have to compute
the isogeny dual of that point Q. And for the verification part, we will refer to our previous
knowledge of the slides, which were field pairings. 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.
So having said that, we are done with our presentation, and I will hand over to Gokul
sir to say the final words. 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,
shard to the main chain itself. Overall, so this is a randomness engineering that we propose.
We have done our first level of prototype. We would like to move to the next level by
integrating isogeny VDF from the SIDS library and the SS-isogeny library. And then we would
also want to blend single secret leader selection, and we would like to do it on the RANDAO.
We have already participated in the Starkware VDF hackathon. We have used the
VDF from Starkware and built random oracles and applied on RANDAO. Now we are excited to go
forward. Thank you so much again for Blockchain Village, DEF CON for giving us this opportunity.
It's an honor. It's a lifetime opportunity for us. Thank you so much once again. Looking forward
to your questions and comments.