1. Steps Towards a Unified Coding Theory for Error- Resilient Computation Allison Bishop Columbia University featuring works by Schulman, Haeupler, Brakerski, Kalai, Jain, Rao, Vitercik, King, Saia

2. Starting Point: Two-Party Computation with Communication Errors Bob Alice *Sender does not know an error occurred, Rest of the computation is wrong! We consider strong adversary who can corrupt a constant fraction of all bits (fixed communication length). Input x Input y

3. What Makes Interactive Coding Distinct from Error-Correcting Codes? Interactive coding problem for 2 parties: As first formulated and studied by Schulman (1992) For m rounds of interaction, just using error-correcting codes can only achieve error rate < 1/m Goal is to get constant relative error rate, and constant (multiplicative) overhead in communication

4. Expressing the Protocol as a Tree Bob speaks (function of input x) Alice speaks (function of input y) 01 0011

5. Execution of the Protocol with No Errors Path in tree = transcript of communication 01 001 1

6. Simulating the Protocol Tree Path Under Errors 1 - Errors cause Bob and Alice to have differing views of simulated transcript Approach: 1.Provide mechanism to detect disagreement 2.Provide mechanism to move back toward agreement 3.Once re-synched, try again to proceed down protocol tree

7. Communicating “Pebble” Movements Each party has a “pebble” it moves around the protocol tree We can use 4 symbol alphabet for “Down Left”, “Down Right,” “Back Up”, “Hold” to describe pebbles that move along one branch of the tree at a time (or stay put) Goal is to communicate the sequence of pebble moves so each party can know where the other party’s pebble is. We want to encode a dynamic string of characters L, R, B, H so that it is decoded properly at moments in time when there are not too many past errors.

8. Encoding Movements via Tree Codes [Schulman 92] Tree code: Edges labeled by symbols from Constant-size alphabet Any two paths have constant-fraction of symbols differing from lowest common ancestor onwards Example with alphabet {1,2,3,4,5} 4 4 2 2 5 3 2 3 1 1 5 4 4 2 2 3 3 2 5 5 5 1 1 1 3 3 4 4 1 1 Example: Strings 1, 2, 5 and 3, 2, 4 differ in 2 out of 3 symbols.

9. Efficient Solution: (tiny) TCs + Hashing [BK12] 1.Provide mechanism to detect disagreement 2.Provide mechanism to move back toward agreement 3.Once re-synched, try again to proceed down protocol tree Let’s revisit the higher level approach: Observation: - We can build short tree codes by brute force in poly time - Naïve concatenation: use TC1 for awhile, then use TC2, etc. Problem: lose ability to detect/correct errors in the more distant past Solution: Hash entire simulated transcript to detect any lingering disagreement

10. [BK12] Protocol Overview 2 5 2 3 5 1 2 5 2 3 5 1 Chunk Hash Check Chunk Hash Check … Divide original protocol into smallish chunks – use short tree code within each Hash entire simulated transcript so far + chunk number to detect disagreement Back up when disagreement found Note: hash length long enough to avoid collisions whp, and chunk length should be similar to avoid communication blowup from the hash phases. Short tree code

11. Even Simpler Efficient Solution – no TCs! [H14] Observation: Hash collisions aren’t really so bad! If they happen at a constant rate, can really handle them like errors. We can make the chunks and hashes constant length now we don’t even need short TCs to get constant error rate with constant communication overhead. Independent hash keys are picked each time, so we can use a Chernoff bound to suitably control overall effect of hash collisions on simulation progress. (Surmountable) Challenge: chunk indices too long to be transmitted to know who should go back

12. Simplest Protocol Overview Chunk Hash Check Chunk Hash Check Divide original protocol into constant size chunks Hash entire simulated transcript so far + chunk number to detect disagreement Back up when disagreement found (hiding some complications here) Note: chunk length should be similar to hash length to avoid communication blowup from the hash phases. Hash collisions happen at bounded constant frequency whp. *Simulated In the clear

13. Applications/Extensions: Multi-party Protocols Interactive coding for multi-party protocols [RS94, GMS11, JKL15] Network of n parties, can communicate via pairwise channels Goal is to compute a joint function of inputs over channels Many models: synchronous vs. asynchronous, noisy vs. adversarial, etc. Many measures: communication complexity, computation, rounds, links, etc.

14. Problems: Basic Idea: Reduce to 2-party case

15. Efficiency preserving Resilient to constant fraction of adversarial error Constant blowup in communication constant Properties: ongoing work Assumptions: 1. Protocol is semi-adaptive 2. There exists one party connected to all the rest One Approach [JKL15]

16. Use variant of [Schulman93] (inefficient) Use variant of [Haeupler14] (efficient) High-Level Description

17. Passing the Burden of Being P* [LV] Challenge: P* maintains a view of each pairwise transcript to check consistency – can’t pass these all to a new P* without lots of communication overhead!

18. A More Speculative Connection Recently, King and Saia [KS13] presented an expected poly-time Byzantine Agreement algorithm against a computationally unbounded, adaptive asynchronous adversary who can corrupt O(n) parties [LL13] presented an impossibility result for a kind of “mobile” adversary who can corrupt a changing set of players and reset their memories upon releasing them to corrupt others. Intriguing Question: Adversarial network channels can be defined to model each of these adversaries, so can we classify a “worst-case” adversarial network against which Byzantine Agreement is possible?

19. Overview of KS Protocol Idea: Punish processors with suspicious deviation over time by adding them to blacklists

20. Open Problem Consider an asynchronous adversary who can: corrupt/crash some processors Cause some number of communication failures even on links from good processors How might we extend KS in one direction and impossibility results in the other direction to get a tight understanding of exactly when agreement becomes impossible?

21. Connection Between Formulas and Communication [KW88] Bob Alice How many bits need to be sent in the worst case? Boolean function f from n bits to 1 bit: x s.t. f(x) = 1 y s.t. f(y) = 0 i s.t. x i not equal to y i

22. Communication Complexity = Formula Depth [KW88] AND OR AND Alice Bob Right Left

23. Carrying Error-Resilience through the Karchmer-Wigderson Connection [KLR12] We want: Error-resilient computation Error-free computation Compiler Error-free communication [KW88] Error-resilient communication Compiler We know:We build:

24. Communication with Errors: An Easier Model (Sender Feedback) Bob Alice *Sender knows error occurred Oops! Redo

25. Short-Circuit Errors AND OR AND 0 1 0 0 1 1 1 1 0 1 0 1 1 1 1 0 True output of gate replaced by value from one of its inputs

26. Recovery from Non-Fatal Short-Circuits Result: can allow a fixed constant fraction of errors per path Example: allow one error per path Efficiency: formula depth multiplied by a constant

27. Why Limited to Formulas and Not Extendable to Circuits Immediately? Error-free circuit computation: OR AND Simulation with errors “Redo” is sent Where should the simulation go? ? ?

28. Goal: Lower Bounds for Circuits *ongoing joint work with Yael Kalai, Jon Ullman OR AND Corresponds to Transcript compression/ Limited memory

29. Attempt: Time-Space Tradeoff? One idea: Be willing to spend computation time - parties can compute if they are both “happy” at current node Bad example: Alice Bob Correct Edges: Current State Alice thinks this is ok Bob thinks this is ok too!

30. Obstruction: Interactive Coding with Low Memory? Bob Alice 0 0 0 1 0 1 0 Errors Detected! ? ? Those who forget history are doomed to repeat it?

31. Intuition: A Tale of Two Oracles How many turns does it take As a function of memory size to reorient after errors?

32. Translating back to Computation: Another remaining challenge – translate a space bound on Interactive coding back to a size bound on error-resilient circuits Related open problem – what does the full power of interactive coding translate back into? Analogy question: Sender feedback coding  short circuit errors Full interactive coding  ??

33. Thanks! Questions?