Practical delegation of computation using multiple servers

Abstract

The current move to Cloud Computing raises the need for verifiable delegation of computations, where a weak client delegates his computation to a powerful server, while maintaining the ability to verify that the result is correct. Although there are prior solutions to this problem, none of them is yet both general and practical for real-world use.We demonstrate a relatively efficient and general solution where the client delegates the computation to several servers, and is guaranteed to determine the correct answer as long as even a single server is honest. We show:• A protocol for any efficiently computable function, with logarithmically many rounds, based on any collision-resistant hash family. The protocol is set in terms of Turing Machines but can be adapted to other computation models.• An adaptation of the protocol for the X86 computation model and a prototype implementation, called Quin, for Windows executables. We describe the architecture of Quin and experiment with several parameters on live clouds. We show that the protocol is practical, can work with nowadays clouds, and is efficient both for the servers and for the client.

Delegatable pseudorandom functions and applications

“…The notion of delegation of cryptographic operations is already mature: Starting from early work on proxy signatures [28] and proxy cryptography [5], basic primitives such as signatures (e.g., [6,28]) and encryption (e.g., [2,19,22]) have been studied in the context of an untrusted proxy who is authorized to operate on signatures or ciphertexts. Recently, there has also been an increased interest in verifiability and privacy of general outsourced computations (e.g., [1,9,10,18,33]) or specific crypto-related operations (e.g., [4,15,20]). To the best of our knowledge, however, no prior work explicitly and formally examines the delegation of PRFs.…”

“…We illustrate with a simple example using the tree from Figure 2. Consider ranges [2,7] and [9,14], both with size 6. The trapdoors generated for these ranges are ((f k (001), 1), (f k (01), 2) and (f k (101), 1), (f k (1001), 0), (f k (110), 1), (f k (1110), 0) , respectively.…”

“…Consider again the ranges [2,7] and [9,14] in the tree of Figure 2, for which BRC generates two distinguishable trapdoors, ((f k (001), 1), (f k (01), 2) and (f k (101), 1), (f k (1001), 0), (f k (110), 1), (f k (1110), 0) , respectively. Instead of computing the trapdoor of [2,7] as above, assume that we generate an alternative trapdoor equal to (f k (010), 1), (f k (0010), 0), (f k (011), 1), (f k (0011), 0) .…”

SmartDEMAP: A Smart Contract Deployment and Management Platform

“…Theoretical results already exist concerning the execution of complex computations in a way, such that the results can be trusted [3,5]. Their currently is a project developing a concrete implementation [6] based on the theoretical foundations from [3,5], and will allow smart contracts to trigger a trusted computation and access the result.…”

“…Their currently is a project developing a concrete implementation [6] based on the theoretical foundations from [3,5], and will allow smart contracts to trigger a trusted computation and access the result.…”