MPC 設置中的真實離線階段實現
我一直在閱讀各種基本的 MPC 原語（多方共享的秘密的乘法、求逆、求冪等）。在現實世界中實現 MPC 的問題之一是性能。常見的解決方案趨勢之一是將協議分為離線（預處理）和線上階段。
計算越複雜和資源密集，我們通過將其解除安裝到離線階段獲得的收益就越大……我試圖想像這在實踐中意味著什麼：我正在想像對某些“業務”的持續請求流“ 功能（例如，用於計算 AES），每個功能都需要在離線階段已經準備好一些（可能是多個）預處理數據片段（例如，Beaver Triples）……所以，基本上，一個偶數（計算上）更大的“離線”處理流將在後台發生……
我自己的願景包括在“業務”負載較低時在後台計算此類離線資源，將這些資源集中在某個儲存中（我猜這也很敏感？）或嘗試將預處理解除安裝到單獨的程序（伺服器？）。
所以，我的主要問題是：是否有任何工作/指南討論在實踐中實施此類離線階段的方式？
我認為沒有這樣的指導方針。然而，已經考慮了不同的方法。
旨在使這些東西在實踐中更易於訪問的多個實現（例如TF-Encrypted或PySyft）的一個共同考慮是考慮在計算開始之前分發必要的預處理材料的第三方可信方。然而，這會引入不同的安全假設並產生新的潛在故障點。
文獻中提出的另一種方法包括讓一組伺服器為需要計算的伺服器生成三元組“作為服務”。這將減少單個預處理生產者暗示的單點故障。
然而，這都是研究文獻。我不知道任何具有大量預處理的協議的實際部署，也沒有任何關於如何這樣做的指南。此外，有一種觀點認為，由於預處理與輸入無關，因此這種預處理想法並不那麼“重要”，在實踐中並不那麼有效。對於主動安全的 2 方協議，相對於線上階段而言，預處理確實會花費大量時間，因此在您獲得恆定計算請求流的真實場景中，計算端到端更準確-結束執行時間。
最後，繁重的預處理時間在不誠實的多數設置中很常見，但是當您願意假設對手最多破壞嚴格的少數方時，我們可以找到預處理非常便宜甚至根本沒有預處理的協議。這在國內很常見 $ 3 $ -派對設置（與 $ 1 $ 腐敗），所以我希望在實踐中進行真正的部署以使用這些設置之一，而不是說， $ 2 $ 派對。