 Hello everyone, my name is Yoros Panayotakos and I'm going to talk about blockchain from an idealized hash function. This is joint work with Wangarai and Akilos KS. Blockchain protocols are characterized by the fact that transactions are organized into blocks and blocks into chains. Now this type of protocol was made popular with Bitcoin in 2008, which uses this structure to implement what is called a robust transaction ledger, a security notion developed through a series of papers that mainly satisfies two properties, consistency, that is everyone should eventually agree on the order of transactions, and liveness, that is anyone should be able to add a valid transaction in the ledger. Now what's interesting about these protocols is that they can operate in what is called the permissionless setting. While in the classical setting parties register, for example using a PKI and then they can communicate in an authenticated manner, in the permissionless setting participation is open, anyone can join the protocol, which also implies that parties communicate through some kind of gossip protocol and communication is not authenticated. Obviously this is a more challenging setting and participation directly implies that we are open to civil attacks. A civil attack is an attack where the adversary creates many fake identities in order to over-represent himself. And this is especially important because classical protocols that can implement a ledger rely on the assumption that the majority of the parties is honest. Hence all these protocols do not work when the adversary can launch a civil attack because by over-representing himself he can essentially break the honest majority assumption. And the novelty of Bitcoin to deal with this attack, which was adopted by many other protocols, was to try to make participation costly. Now this is achieved by the use of proof of work. A proof of work is a proof that some computational work has been done in a specific time interval and also introduced by work in hour 1992. And the main idea is to use a proof of work in its block. Now this implies that the ability of the adversary to create new blocks is limited by its computational power. And proof of work-based protocols take advantage of this by operating under the assumption that the majority of computational power is controlled by honest parties. There have also been other approaches, for example the use of proofs of spacetime, which require disk space. And I should note that in this discussion we do not involve protocols that use proofs of stake because they require an initial registration phase. Now most blocks and protocols use hash-based proofs of work and the same holds for proofs of spacetime. And as an example I'll describe the construction used by Bitcoin. In this construction parties first receive a challenge string x and they seek to find a witness consisting of two parts, a message and a counter. And a proof of work of this type is valid if hasing the challenge with the message and then hasing the game with the counter produces a string that's smaller than some target t. Now the way these protocols are analyzed is using the random oracle methodology. This methodology dictates that we should replace hash functions with a random oracle and then prove security. And it has been shown by Kaneti, Goldrein and Hallevi in 1998 that the random oracle methodology is not sound and should only be used as a sanity check for our protocols. Hence the question we pose here is whether we can base the security of proof of work blocks and protocols on a set of properties for run idealized hash functions. We answer this question in the affirmative. We design a blocks and protocol that's proven secure assuming first the existence of a non idealized hash function that satisfies a set of three simple properties, secondly the existence of non-interactive zero-knowledge proofs and thirdly that the adversary controls at most one-third of the computational power. Now in the process of doing that we introduce a notion of iterated search problems. This is a class of search of hard problems closely related to iterated sequential functions. With the difference being that at this iteration parties have to solve a search problem and not compute a function. What is also interesting here is that our notion allows for parallelization unlike sequential functions and this property is shown to be important for the design of proof of work based blocks and protocols. So next I'll present the three hash function properties we assume. The first one is collision resistance. This is a standard property of hash functions. The second one is that we assume that the hash function is a computational weak random extractor. More specifically we need that for any adversarial generated x it should be hard for the adversary to distinguish between hasing x with a uniformly random string from a uniformly random string that has the same size as the hash output. Again this is a standard assumption about hash functions. And finally the third property that we introduce is iterated hardness. In a high level this property says that it should be hard to generate a sequence of small hases. In more detail now given a string x that is randomly sampled and for large enough k any adversary that takes k times t steps should generate a list of strings w i w i prime such that hasing this string, iterated hasing this string starting from the challenging x has the property that every second has a smaller than target t with probability negligible in lambda the security parameter. Again this property looks similar to iterated sequential functions but the difference is that at every iteration the adversary has to find has to solve a search problem instead of computing a function has to find strings w i w i prime instead of just computing a function. Moreover as I said collision resistance and being a weak extractor are standard properties about hash functions so in this work we also had to argue about what evidence we have about the iterated hardness property. So to describe our approach I'll first remind you of how we evaluate the security of real world hash function properties. Take for example Ketzak and collision resistance. The reason we believe that Ketzak is collision resistant is because there was a competition run by NIST that incentivized researchers to break this property. Now since no serious attack was found for the duration of this competition we considered Ketzak to be collision resistant or we consider that there is positive evidence for the collision resistance of Ketzak. Now take the case of SATA-56 squared the hash function used by bitcoin and iterated hardness. In the next slides I'll argue that breaking iterated hardness means also breaking bitcoin hence there was an incentive all these years that the coins run to break this property. However for the last 10 years no serious attack against this property has been shown. Hence we conclude that there is some positive evidence towards the security of the iterated hardness of SATA-56 squared. It's important to say here that this claim is not trivial since this argument would not necessarily hold for stronger hardness properties because it may not be the case that breaking these properties means breaking bitcoin which also creates the incentive to do the work. First I'll give a brief description of bitcoin. Its block in bitcoin contains a pointer to the previous block, a message in the counter. For the block to contain a valid proof of work it should be the case that hashing the pointer with a message and then hashing again with the counter produces an output that's smaller than some target T. Now the protocol dictates that parties should pick the longest chain among the ones they have heard and try to extend it by computing a small another proof of work that contains the message, the transactions they want to add to the chain. And a transaction is considered to be stable if it is contained in a block that is at least K blocks deep in the chain of the respective party. So now we're in a position to argue that if for some T there is an adversary that breaks iterated hardness then there is an adversary that breaks the security of bitcoin. So the bitcoin adversary is going to use the iterated hardness adversary to break this security of bitcoin and the way he's going to do that is by selecting the longest chain at some point in the bitcoin execution hashing its last block B in this image and giving it as input to the iterated hardness adversary who in turn is going to produce in less than K times T steps a list of witnesses where iteratively hashing these witnesses starting from the hash of the last block has the property that every second has is smaller than some target T which effectively means that its pair of these witnesses is going to be a valid block extending B and on the other hand we can show that honest parties in the same time interval are not going to be able to generate as many blocks hence the adversary can create a deep fork and force some party some honest parties force honest parties have different views about which transactions are stable and effectively break consistency this is exactly what we wanted as breaking the iterated hardness means breaking bitcoin which effectively means creating an incentive to break this property. So next I'll talk a bit about how we can implement a secure blockchain protocol under the assumptions we just presented in the previous section so our first naive attempt is to try to follow bitcoins design the main problem with that is that we have to bound the rate that the adversary generates blocks using the iterated hardness assumption now the first issue is that the adversary in the Bitcoin execution sees also honestly computer blocks if you remember the iterated hardness game there the adversary does not get any help by any external oracle let's say giving him small hashes this kind of implies that in our solution we should be able to cheaply generate simulate honest blocks the second reason we have is that iterated harness does not exclude the possibility that the proof of work of Bitcoin is witness malleable while the harness ensures that it's hard to generate a sequence of blocks does not say anything about generating blocks the same level about generating small hashes at the same level I'll just note here that in the case of the random oracle model we are sure we can prove that it's hard to generate also small witnesses at the same level to deal with this issues we choose to embrace proof of work witness malleability similar techniques have been applied to other graphic primitive such as witness malleable commitments or witness malleable nicks essentially we allow malleability in a control way so the first thing we do is to reverse to reverse bitcoins proof of work design by requiring that the first has is smaller than some target t instead of the second one note here that this preserves this property that every second has is smaller than some target and will later help us argue that hardness is preserved the second change we do is that we require that the witnesses are sampled uniformly at random this has the effect that the second has the output of the second has is going to be computationally indistinguishable from uniform due to the weak extraction property of the house finally note that this proof of work we have constructed is explicitly witness malleable in the sense that you can create a new proof of work by changing the second part of the witness of course all these does not help us from the issue mentioned before where the adversary manages to compute a new block cheaply because he has seen an honest block at the same level to address this issue we choose to use an extractable nisk scheme to hide witnesses so we were gonna replace witness strings let's say w1 w1 prime with some proof p1 this proof is gonna guarantee that there exists strings w1 w1 prime such has such that passing x1 with w1 is smaller than some target t this is to ensure hardness secondly that has in x1 with w1 and then has again with w1 prime the second part of the witness is equal to some string x2 that's gonna be a part of the block and publicly revealed this allows other parties continue mining on top of our block after publishing the block essentially gonna use x2 they're gonna try to extend x2 and finally we're gonna attach a message we're gonna publicly reveal a message and ensure that this nisk proof is generated with respect to this message so that a unique message is always attached to a block all the changes have helped us in being able to cheaply simulate a block and we can do that because first we're able to simulate the second has x2 in this case by just randomly sampling a new string and this string is gonna be distinguishable from the actual has due to the weak randomness extractor property and secondly because we can use the nisk simulator now to simulate the nisk proof of the block so next I'll give a brief outline of how all these changes help us reduce an attacker against Bitcoin to an attacker against the iterated hardness property so assume you have an attacker that generates blocks fast in the Bitcoin protocol we're gonna use it to generate small has is against the iterated hardness property so soon now you have some you start some from some block and at some point the adversary generates a new block in the Bitcoin execution time passes and then let's say some honest party is about to generate a new block what we want is to be able to cheaply simulate this block so what we're gonna do is the following first extract the witness of the desire block WGW prime we can do that because the nisk is extractable then we're gonna sample a new witness by uniformly sampling the second string let's call it WGW star and let now x2 be the second has for this new witness now notice that what we've managed to do up to now is create two blocks or almost two blocks that at the same level instead what we wanted was to come to to come to simulate a block that is extending the adversarial one so to do that we're gonna use the nisk simulator to create a proof that there exist as things W1 W1 prime says that the if you have x1 with W1 index and the out and the result of that with W1 prime the result is x2 now we can show that the adversary cannot distinguish in between between the two case in two cases cannot distinguish in between generating the honest block the way we did now and generating the honest block as in the real execution now if the adversary at some later point generates another desired block we will be able to extract a sequence of small houses as the iterate harness game dictates so we're gonna extract the witness from the new block w2 then w2 prime and now x0 w0 w0 star w2 w2 prime constitute a sequence with two small houses as the third harness game dictates so by continuing the strategy we can generate a long sequence of small houses as the harness game dictates and break this property now as I mentioned earlier we perform our analysis in a modular way to do that we abstract the underlying hardest notion and build our analysis on top of it we call this notion iterated search problems this problems should have the following properties first this would be hard similar to how we have to find iterate hardness for hash functions this should be next problem simulatable in the sense that there exists a simulator that can simulate the next problem in a sequence without knowing the witness this should be witness malleable in the sense that there exists a program that can that given a problem statement that a witness can generate another witness simply and they also have fast verification and guarantee a lower bound on the probability of success for honest miners and I would have managed to instantiate this primitive using the three has function properties I mentioned at the beginning but the reason the main reason we build our analysis this way is to help coming up with other associations that we may not imagine imagine right now concluding we have shown that assuming the existence of a has function family that satisfies collision resistance is a computational weak extractor and iterated hardness and the robustness proof system with appropriate parameters there exists a protocol that implements a transaction ledger against an adversary that controls up to one third of the computational power moreover in the process we've introduced a new hard problem notion called iterated search problems and the number of questions are left open from our work the one is whether we can reduce it it hardness to similar assumptions or more well-standing assumptions the second one is whether we can use techniques from crypt analysis to attack iterated hardness of property internet harness property of sat of 56 squared or there are better better has functions treated for this property and finally in the protocol level whether we can achieve security against an adversary that controls half of the computational power or close to half the computational power under the same assumptions in other words want to see whether with this my ability is a limiting factor for for security in our analysis the reason we go up to one third is because we can only take advantage of one adversarial block per level of the block block three in in our reduction shown earlier that's all I wanted to say so thank you all and take care