encryptogroup/motion

1. MOTION is a C++20 framework for mixed-protocol secure multi-party computation. The core deliverable is a reusable library under src/motioncore, with optional example executables under src/examples and tests under src/test.

2. The highest-level runtime boundary is the “party” abstraction: each participant runs a local Party/Backend instance, loads a protocol configuration, and participates in distributed computation through a communication layer. The framework is designed for multiple parties executing the same circuit/protocol logic with secret-shared or garbled values.

3. Communication is isolated in src/motioncore/communication. It provides a transport-agnostic message system plus concrete transports:

- tcp_transport for real network communication

- dummy_transport for local or test execution

- message classes such as hello and garbled-circuit messages

FlatBuffers definitions live in fbs/, so serialized messages are a distinct boundary from protocol logic.

4. Protocol execution is centered around the generic gate, wire, share, and share_wrapper abstractions. Concrete protocol families implement these interfaces in subdirectories under src/motioncore/protocols, which is the main architectural partition of the computation layer.

5. The supported protocol families include boolean GMW, arithmetic GMW, BMR, garbled circuits, Astra, and constant shares. This means the framework can represent the same application at different abstraction levels and switch between protocols or mix them within one computation. Conversions between domains are handled explicitly in protocols/conversion, while protocols/data_management provides SIMD-style packing/unpacking and subset selection.

6. The garbled-circuit path is a major subsystem. It has its own provider, gate, share, wire, and constants, and it connects to dedicated message types in communication. This indicates a full end-to-end offline/online flow for garbled computation rather than a thin wrapper over another protocol.

7. Oblivious transfer is a separate foundational layer in src/motioncore/oblivious_transfer. It includes base OT providers and KK13-style 1-out-of-n OT flavors/providers. These primitives feed other protocol layers, especially garbled circuits and OT-based extensions.

8. Multiplication triples and Beaver-style randomness are another core service layer in src/motioncore/multiplication_triple. Providers for different share types supply preprocessed correlated randomness to arithmetic-style protocols. This preprocessing layer is structurally separate from online gate execution.

9. Cryptographic and randomness primitives are centralized in src/motioncore/primitives. This includes AES-NI helpers, BLAKE2b, Curve25519 code, PRGs, and RNG backends such as OpenSSL and AES-CTR. These primitives support OT, preprocessing, and protocol-specific randomness generation.

10. Application code is intentionally separated from the core framework. The examples in src/examples show how to build end-user MPC programs such as AES-128, SHA-256, the millionaires’ problem, benchmarking apps, and tutorial workloads like inner product and cross-tabs. This makes the repo both a library and a collection of reference deployments.

11. The circuits/ directory contains Bristol-format circuit descriptions and metadata for integer, float, and advanced functions like AES and SHA. These are externalized circuit assets consumed by protocol implementations, especially garbled-circuit-based ones, and they serve as the bridge between high-level applications and low-level gate networks.

12. Supporting infrastructure is substantial but secondary to the computation stack: utility/ contains threading/fiber pools, queues, logging, bit containers, and runtime helpers; statistics/ collects runtime measurements; data_storage/ holds OT extension state. This separation shows that MOTION’s architecture is layered around distributed protocol execution, with shared infrastructure reused across protocols and applications.

13. Build and portability are managed with CMake, optional bundled dependencies in extern/, and Docker for a reproducible environment. The repo also uses GoogleTest for validation and Benchmarks for performance experiments, reinforcing that this is a research/experimental MPC platform rather than an application-specific product.