An intriguing aspect from a community perspective is providing a space for Web3 individuals within the Mastodon network, which often leans anti-blockchain and anti-crypto. This could create common ground for those who uphold free software and federation values from a blockchain standpoint.

This could be achieved using BuilderPass (proof-of-builder!) as a token gate or by forking Farcaster into separate deployments, allowing for an independent Farcaster registry for each Mastodon and Matrix community. Rather simply, it's a matter of token-gating a Mastodon instance, possibly using something like Unlock Protocol. A more infolved altenrative is to build in an option for Mastodon/Matrix server admins to easily deploy a Farcaster registry under their control

This would introduce federation and logical decentralisation to the Farcaster architecture.

Developers offer software in a runnable containers using Docker. This enables the system to create a competitive proposal process for running that container in production, and running multiple instances of it for scale or fail-over.

An "alliance" model for server failover is employed, essentially a devops convention for sharing data between two containers on different servers, enabling them to support one another in case of failure, even though they are run by independent teams. Each provider can operate and be paid independently, offering redunduncy at the organisational level as well,

EIP: Trustable Off-chain Compute

Preamble

EIP: <to be assigned>
Title: Trustable Off-chain Compute
Author: Voboda
Type: Standards Track
Category: ERC
Status: Draft
Created: <date>

Simple Summary

A standard for ensuring the integrity of off-chain computations in containerized environments, particularly useful for non-deterministic processes like machine learning models.

Abstract

This EIP proposes a framework for registering and verifying containerized off-chain computations to provide cryptographic guarantees about the integrity and authenticity of the computation process and its results. It outlines mechanisms for file system hashing at container boot, runtime integrity checks, and the registration of Trusted Execution Environment (TEE) attestations.

Developing this framework as an EIP promotes standardization across the Ethereum ecosystem. It offers a unified approach to verify the integrity of off-chain computations, ensuring consistency and interoperability among various applications and services. Thus, it allows for robust cross-implimentation transparency and auditing systems.

Motivation

To enhance trust and transparency in decentralized systems where off-chain computations are necessary, particularly when those computations are non-deterministic and require a high degree of trustworthiness.

In comparison to existing mechanisms like oracles, zk-proofs, economic consensus models, and distributed compute platforms (e.g., iExec), this framework offers a unique approach to enesulng off-chain computation integrity.

  • Oracles: Unlike oracles that provide external data to blockchain networks, this framework focuses on verifying the internal integrity of off-chain computations. It offers a more granular level of security by ensuring the authenticity of the execution environment itself.

  • zk-Proofs: While zk-proofs provide a way to verify the correctness of computations without revealing underlying data, they can be computationally intensive making complex zk-proofs infeasible or prohibitavely expensive.. This framework offers a more straightforward, hardware-based approach to attestation of computation integrity.

  • Economic Consensus/Distributed Compute Platforms: Compared to economic consensus models or platforms like Ethereum and iExec, which rely on network consensus or distributed computing resources, our framework provides a direct, hardware-enforced trust model. It is particularly useful in scenarios where the computational process itself, rather than just the output, needs to be verifiable.

  • MPC: Multi-Party Commute provides trust guarantees to those willing to participate in the compute process as it happens. This model, while complimentary, provides a post-factum chain of trust.

This approach fills a unique niche in the blockchain ecosystem, providing a hardware-based solution and a cryptographic chain of trust of off-chain computations, which is intrinsically similar to the cryptographic chain of trust pattern that defines blockchains themselves. It complements existing technologies and can be particularly valuable in use cases where a high level of computational integrity and security is required.

Chain Of Trust Pattern

  1. Container Image Hash (At-Rest Integrity):

The image hash acts as a fingerprint of the container at the time of its creation. It ensures that the source code and dependencies are exactly as intended before deployment.
This hash provides a baseline for verifying that any subsequent container instance is based on this exact image.

  1. Filesystem Hash (At-Boot Integrity):

When a container instance boots, it generates a hash of its filesystem. This action verifies that the runtime environment matches the original image's state (as per the image hash).
The consistency between the at-rest image hash and the at-boot filesystem hash ensures the instance starts in an expected, untampered state.

  1. TEE (Hardware & Side-Attack Integrity) Attestation:

The TEE attestation confirms that the container instance is executing within a secure, hardware-isolated environment. It protects the execution from external tampering or observation.
This step overlaps with the filesystem hash by adding an additional layer of trust that the environment is secure at the hardware level.

  1. Runtime Integrity Checks:

Throughout its operation, the container performs self-checks to ensure its ongoing integrity. These checks are designed to detect and respond to runtime anomalies or breaches.
If integrity is compromised, the container shuts down, preventing any tampered or compromised data from contributing to the final computation result.

Resulting Computation Integrity

The overlap of these components – the unaltered image, the verified filesystem at boot, the secure execution environment, and the continuous runtime checks – forms a comprehensive chain of trust.
This chain ensures that the computation results produced and sent to a relying smart contract are as intended by the original image, free from tampering or unauthorized alterations. This EIP describes an API for an on-chain registry, allowing any public third-party to cryptographically verify the chain of trust.

Weakenesses in the Chain of Trust
  • Reliance on TEE Integrity: The integrity of the TEE (e.g., Intel IAS for SGX hardware) is a critical component. Any vulnerabilities in the TEE could compromise the entire chain of trust.
  • Admin Verification Process: The process relies on admin verification for instance authorization, particularly to verify an instances signature is signed by the appropriate external TEE registry.. Human errors or delays in this process could lead to vulnerabilities.
  • Runtime Checks Limitations: Runtime integrity checks are only as robust as their implementation. Sophisticated attacks that evade these checks, particularly through vulnerabilities in imported libraries, could potentially compromise container integrity without triggering a shutdown.

Specification

ContainerRegistry Contract

The ContainerRegistry contract manages the registration and verification of container images and instances.

pragma solidity ^0.8.0;

contract ContainerRegistry {
    struct ImageInfo {
        string imageHash;
        string filesystemHash;
        string attestationRootKey;
        string containerHostUrl; // Optional
    }

    struct InstanceInfo {
        string imageHash;
        string enclaveSignature;
        string attestationData;
    }

    struct VerificationResult {
        bool isVerified;
        string verificationDetails;
    }

    mapping(string => ImageInfo) public registeredImages;
    mapping(address => InstanceInfo) public registeredInstances;
    mapping(address => VerificationResult) public verificationResults;
    address private admin;

    event ImageRegistered(string indexed imageHash, ImageInfo info);
    event InstanceRegistered(address indexed instanceAddress, InstanceInfo info);
    event InstanceAuthorized(address indexed instanceAddress, string verificationDetails);

    constructor() {
        admin = msg.sender;
    }

    modifier onlyAdmin() {
        require(msg.sender == admin, "Only admin can perform this action");
        _;
    }

    function registerImage(string calldata imageHash, ImageInfo calldata info) external onlyAdmin {
        registeredImages[imageHash] = info;
        emit ImageRegistered(imageHash, info);
    }

    function registerInstance(address instanceAddress, InstanceInfo calldata info) external {
        registeredInstances[instanceAddress] = info;
        emit InstanceRegistered(instanceAddress, info);
    }

    function authorizeInstance(address instanceAddress, string calldata verificationDetails) external onlyAdmin {
        VerificationResult storage result = verificationResults[instanceAddress];
        result.isVerified = true;
        result.verificationDetails = verificationDetails;
        emit InstanceAuthorized(instanceAddress, verificationDetails);
    }
}

Rationale

This approach offers a robust mechanism for ensuring the integrity of off-chain computations, crucial in decentralized systems where trust is paramount. The combination of admin-managed registrations and public event emissions balances security with transparency.

Backwards Compatibility

This EIP is backward compatible as it introduces new functionalities without altering existing ones.

Test Cases

  • Test case for admin registration of a new container image.
  • Test case for a container instance registering itself and submitting computation results.
  • Test case for runtime integrity breach detection and container shutdown.

Implementation

The implementation includes two main contracts: ContainerRegistry and RelierApplication. The ContainerRegistry contract manages the registration of container images and instances, along with the verification results post-admin authorization. The RelierApplication contract handles the processing of task results from verified instances, ensuring that only authenticated and authorized containers can submit results.

Conclusion

This EIP provides a framework for trustable off-chain computations in decentralized applications, incorporating crucial elements such as container image registration, attestation verification, and runtime integrity checks. This comprehensive system provides an auditable, cryptographic trail of proof that warrants the authenticity and integrity of computation processes and results, fostering trust and reliability in decentralized ecosystems.

Guiding Principle: Equitability

We prioritize equitability and trustlessness. Our goal is to distribute funds based on actual usage, moving away from traditional models (such as SaaS, open core, and delegation populism) that often concentrate power and leave creators unrewarded.

  • How can we ensure our system remains equitable as it evolves?
  • What challenges might arise in maintaining these principles?
  • How can we balance immutability with this? Can we have long-term guarantees or anti-erosion systems that protect fund distribution to authors, but also have adaptability to include contributors at later stages or of different types? How can we keep the authors and main contributors in power?

Mechanism: ZK-OAuth & ZK-Activity

We're exploring a zero-knowledge (ZK) OAuth mechanism, allowing trustless user authentication and anonymous activity tallying. This approach emphasizes actual user interaction as an input for redistribution. (As a highly composable primitive, this sidesteps the need for identity proofs compared to most sybil-naive QF models, for example.)

  • How can we ensure the ZK mechanism remains robust and secure?
  • Which ZK platform makes sense for this? Seems feasiable on Mina but Mina mainnet isn't ready. Starknet maybe?
  • Are there other mechanisms that align with our principles?
  • Any other mechanisms that feel worth building or experimenting with?
  • How can we make this mechanism more accessible and understandable for all?

Collaboration Culture: Pluralistic Building

We can't predict which ideas will really work until we try them. So experiment widely, iterate and prototype with users. Share progress with Super Shadowy peers. At its core, a bi-weekly WIP Wednesday meetup.

  • How can we foster a culture of open experimentation and support?
  • What guidance might help streamline our collaborative ?
  • Are there existing collaboration models you'd like us all to consider?

Super Shadowy 👥

Our goal is to create an on-chain SaaS host for FOSS authors, with trustless and transparent revenue distribution to contributors, based on actual usage.

Why?

Existing modes of Free Software funding, like SaaS, enterprise hosting, and advertising-based models - they distribute funding unevenly and are susceptible to extracting financial gains at the cost of both end users and contributors. This is endemic, from startups to non-profits, NGOs and DAOs.

If we're honest about how this affects FOSS authors, it's simple: developers tend not to be commercially-motivated resulting in their projects being underfunded or taken over by commercial interests.. The problem is that we give up the end-user relationships, and the revenue control that goes with it. But this doesn't have to be a case of "do business" or rely on donations.

Guaranteed revenue share

Blockchains provide a third way. So as AMMs are to banks, we aim to be to SaaS.

Allowing users access to your software while maintaining control over the revenue through a SaaS-hosting hyperstructure offers a few novel benefits. It requires less time spent on deploying infrastructure and marketing, while still allow revenue streams to flow back to the core contributors more easily. Plus it assists in maintaining a close user-feedback loop. Most of all, it guarantees future revenue is distributed to contributors.

Principles

  • Equitable - distribute funds based on actual usage, avoiding profit-hoarding
  • Pluralist - we can't predict which ideas will really work until we try them, so we experiment widely and help each other

Mechanisms

This requires using decentralised infrastructure: politically, logically and architecturally.

  • ZK O-Auth - distributing on-chain revenue based on usage requires a private on-chain mechanism for tracking use. ZK OAuth allows for any web2 software to authenticate with an on-chain tally.
  • TOC - Trustable Off-chain Compute using enclaves - Enclave architectures (such as TPM and SGX) are usually designed for commercial goals compromising end-user freedom. We can invert this trust chain by redirecting the trust chain to a hyperstructure or public smart contract.
  • Alliances - Politically Redundant Server Architecture - architectural redundancy also requres redudant organisational structures supporting the servers. This can be acheived though this primitive.
  • Federated on-chain user registries for social - Most VC-funded blockchain models are designed for logical centralisation (a singe source of truth for a registry). By federating them, we logigicall decentralise them.

Join us: get super shadowy