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: <to be assigned>
Title: Trustable Off-chain Compute
Author: Voboda
Type: Standards Track
Category: ERC
Status: Draft
Created: <date>
A standard for ensuring the integrity of off-chain computations in containerized environments, particularly useful for non-deterministic processes like machine learning models.
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.
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.
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.
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.
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.
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.
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.
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);
}
}
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.
This EIP is backward compatible as it introduces new functionalities without altering existing ones.
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.
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.
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.
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.)
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.
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.
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.
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.
This requires using decentralised infrastructure: politically, logically and architecturally.