Files
aitbc/research/standards/eip-aitbc-receipts.md
oib c8be9d7414 feat: add marketplace metrics, privacy features, and service registry endpoints
- Add Prometheus metrics for marketplace API throughput and error rates with new dashboard panels
- Implement confidential transaction models with encryption support and access control
- Add key management system with registration, rotation, and audit logging
- Create services and registry routers for service discovery and management
- Integrate ZK proof generation for privacy-preserving receipts
- Add metrics instru
2025-12-22 10:33:23 +01:00

459 lines
13 KiB
Markdown

---
eip: 8XXX
title: AITBC Receipt Interoperability Standard
description: Standard format for AI/ML workload receipts enabling cross-chain verification and marketplace interoperability
author: AITBC Research Consortium <research@aitbc.io>
discussions-to: https://github.com/ethereum/EIPs/discussions/8XXX
status: Draft
type: Standards Track
category: ERC
created: 2024-01-XX
requires: 712, 191, 1155
---
## Abstract
This standard defines a universal format for AI/ML workload receipts that enables:
- Cross-chain verification of computation results
- Interoperability between decentralized AI marketplaces
- Standardized metadata for model inference and training
- Cryptographic proof verification across different blockchain networks
- Composable receipt-based workflows
## Motivation
The growing ecosystem of decentralized AI marketplaces and blockchain-based AI services lacks a standard for receipt representation. This leads to:
- Fragmented markets with incompatible receipt formats
- Difficulty in verifying computations across chains
- Limited composability between AI services
- Redundant implementations of similar functionality
By establishing a universal receipt standard, we enable:
- Seamless cross-chain AI service integration
- Unified verification mechanisms
- Enhanced marketplace liquidity
- Reduced development overhead for AI service providers
## Specification
### Core Receipt Structure
```solidity
interface IAITBCReceipt {
struct Receipt {
bytes32 receiptId; // Unique identifier
address provider; // Service provider
address client; // Client who requested
uint256 timestamp; // Execution timestamp
uint256 chainId; // Source chain ID
WorkloadType workloadType; // Type of AI workload
WorkloadMetadata metadata; // Workload-specific data
VerificationProof proof; // Cryptographic proof
bytes signature; // Provider signature
}
enum WorkloadType {
INFERENCE,
TRAINING,
FINE_TUNING,
VALIDATION
}
}
```
### Workload Metadata
```solidity
struct WorkloadMetadata {
string modelId; // Model identifier
string modelVersion; // Model version
bytes32 modelHash; // Model content hash
bytes32 inputHash; // Input data hash
bytes32 outputHash; // Output data hash
uint256 computeUnits; // Compute resources used
uint256 executionTime; // Execution time in ms
mapping(string => string) customFields; // Extensible metadata
}
```
### Verification Proof
```solidity
struct VerificationProof {
ProofType proofType; // Type of proof
bytes proofData; // Proof bytes
bytes32[] publicInputs; // Public inputs
bytes32[] verificationKeys; // Verification keys
uint256 verificationGas; // Gas required for verification
}
```
### Cross-Chain Verification
```solidity
interface ICrossChainVerifier {
event VerificationRequested(
bytes32 indexed receiptId,
uint256 fromChainId,
uint256 toChainId
);
event VerificationCompleted(
bytes32 indexed receiptId,
bool verified,
bytes32 crossChainId
);
function verifyReceipt(
Receipt calldata receipt,
uint256 targetChainId
) external returns (bytes32 crossChainId);
function submitCrossChainProof(
bytes32 crossChainId,
bytes calldata proof
) external returns (bool verified);
}
```
### Marketplace Integration
```solidity
interface IAITBCMarketplace {
function listService(
Service calldata service,
ReceiptTemplate calldata template
) external returns (uint256 serviceId);
function executeWorkload(
uint256 serviceId,
bytes calldata workloadData
) external payable returns (Receipt memory receipt);
function verifyAndSettle(
Receipt calldata receipt
) external returns (bool settled);
}
```
### JSON Representation
```json
{
"receiptId": "0x...",
"provider": "0x...",
"client": "0x...",
"timestamp": 1704067200,
"chainId": 1,
"workloadType": "INFERENCE",
"metadata": {
"modelId": "gpt-4",
"modelVersion": "1.0.0",
"modelHash": "0x...",
"inputHash": "0x...",
"outputHash": "0x...",
"computeUnits": 1000,
"executionTime": 2500,
"customFields": {
"temperature": "0.7",
"maxTokens": "1000"
}
},
"proof": {
"proofType": "ZK_SNARK",
"proofData": "0x...",
"publicInputs": ["0x..."],
"verificationKeys": ["0x..."],
"verificationGas": 50000
},
"signature": "0x..."
}
```
## Rationale
### Design Decisions
1. **Hierarchical Structure**: Receipt contains metadata and proof separately for flexibility
2. **Extensible Metadata**: Custom fields allow for workload-specific extensions
3. **Multiple Proof Types**: Supports ZK-SNARKs, STARKs, and optimistic rollups
4. **Chain Agnostic**: Works across EVM and non-EVM chains
5. **Backwards Compatible**: Builds on existing ERC standards
### Trade-offs
1. **Gas Costs**: Comprehensive metadata increases verification costs
- Mitigation: Optional fields and lazy verification
2. **Proof Size**: ZK proofs can be large
- Mitigation: Proof compression and aggregation
3. **Standardization vs Innovation**: Fixed format may limit innovation
- Mitigation: Versioning and extension mechanisms
## Backwards Compatibility
This standard is designed to be backwards compatible with:
- **ERC-712**: Typed data signing for receipts
- **ERC-1155**: Multi-token standard for representing receipts as NFTs
- **ERC-191**: Signed data standard for cross-chain verification
Existing implementations can adopt this standard by:
1. Wrapping current receipt formats
2. Implementing adapter contracts
3. Using migration contracts for gradual transition
## Security Considerations
### Provider Misbehavior
- Providers must sign receipts cryptographically
- Slashing conditions for invalid proofs
- Reputation system integration
### Cross-Chain Risks
- Replay attacks across chains
- Bridge security dependencies
- Finality considerations
### Privacy Concerns
- Sensitive data in metadata
- Proof leakage risks
- Client privacy protection
### Mitigations
1. **Cryptographic Guarantees**: All receipts signed by providers
2. **Economic Security**: Stake requirements for providers
3. **Privacy Options**: Zero-knowledge proofs for sensitive data
4. **Audit Trails**: Complete verification history
## Implementation Guide
### Basic Implementation
```solidity
contract AITBCReceipt is IAITBCReceipt {
mapping(bytes32 => Receipt) public receipts;
mapping(address => uint256) public providerNonce;
function createReceipt(
WorkloadType workloadType,
WorkloadMetadata calldata metadata,
VerificationProof calldata proof
) external returns (bytes32 receiptId) {
require(providerNonce[msg.sender] == metadata.nonce);
receiptId = keccak256(
abi.encodePacked(
msg.sender,
block.timestamp,
metadata.modelHash,
metadata.inputHash
)
);
receipts[receiptId] = Receipt({
receiptId: receiptId,
provider: msg.sender,
client: tx.origin,
timestamp: block.timestamp,
chainId: block.chainid,
workloadType: workloadType,
metadata: metadata,
proof: proof,
signature: new bytes(0)
});
providerNonce[msg.sender]++;
emit ReceiptCreated(receiptId, msg.sender);
}
}
```
### Cross-Chain Bridge Implementation
```solidity
contract AITBCBridge is ICrossChainVerifier {
mapping(bytes32 => CrossChainVerification) public verifications;
function verifyReceipt(
Receipt calldata receipt,
uint256 targetChainId
) external override returns (bytes32 crossChainId) {
crossChainId = keccak256(
abi.encodePacked(
receipt.receiptId,
targetChainId,
block.timestamp
)
);
verifications[crossChainId] = CrossChainVerification({
receiptId: receipt.receiptId,
fromChainId: receipt.chainId,
toChainId: targetChainId,
timestamp: block.timestamp,
status: VerificationStatus.PENDING
});
emit VerificationRequested(receipt.receiptId, receipt.chainId, targetChainId);
}
}
```
## Test Cases
### Test Case 1: Basic Receipt Creation
```solidity
function testCreateReceipt() public {
WorkloadMetadata memory metadata = WorkloadMetadata({
modelId: "test-model",
modelVersion: "1.0.0",
modelHash: keccak256("model"),
inputHash: keccak256("input"),
outputHash: keccak256("output"),
computeUnits: 100,
executionTime: 1000,
customFields: new mapping(string => string)
});
bytes32 receiptId = receiptContract.createReceipt(
WorkloadType.INFERENCE,
metadata,
proof
);
assertTrue(receiptId != bytes32(0));
}
```
### Test Case 2: Cross-Chain Verification
```solidity
function testCrossChainVerification() public {
bytes32 crossChainId = bridge.verifyReceipt(receipt, targetChain);
assertEq(bridge.getVerificationStatus(crossChainId), VerificationStatus.PENDING);
// Submit proof on target chain
bool verified = bridgeTarget.submitCrossChainProof(
crossChainId,
crossChainProof
);
assertTrue(verified);
}
```
## Reference Implementation
A full reference implementation is available at:
- GitHub: https://github.com/aitbc/receipt-standard
- npm: @aitbc/receipt-standard
- Documentation: https://docs.aitbc.io/receipt-standard
## Industry Adoption
### Current Supporters
- [List of supporting organizations]
- [Implemented marketplaces]
- [Tooling providers]
### Integration Examples
1. **Ethereum Mainnet**: Full implementation with ZK proofs
2. **Polygon**: Optimistic rollup integration
3. **Arbitrum**: STARK-based verification
4. **Cosmos**: IBC integration for cross-chain
### Migration Path
1. Phase 1: Adapter contracts for existing formats
2. Phase 2: Hybrid implementations
3. Phase 3: Full standard adoption
## Future Extensions
### Planned Enhancements
1. **Recursive Proofs**: Nested receipt verification
2. **Batch Verification**: Multiple receipts in one proof
3. **Dynamic Pricing**: Market-based verification costs
4. **AI Model Registry**: On-chain model verification
### Potential Standards
1. **EIP-XXXX**: AI Model Registry Standard
2. **EIP-XXXX**: Cross-Chain AI Service Protocol
3. **EIP-XXXX**: Decentralized AI Oracles
## Copyright
Copyright and related rights waived via CC0.
---
## Appendix A: Full Interface Definition
```solidity
// SPDX-License-Identifier: CC0-1.0
pragma solidity ^0.8.0;
interface IAITBCReceipt {
// Structs
struct Receipt {
bytes32 receiptId;
address provider;
address client;
uint256 timestamp;
uint256 chainId;
WorkloadType workloadType;
WorkloadMetadata metadata;
VerificationProof proof;
bytes signature;
}
struct WorkloadMetadata {
string modelId;
string modelVersion;
bytes32 modelHash;
bytes32 inputHash;
bytes32 outputHash;
uint256 computeUnits;
uint256 executionTime;
mapping(string => string) customFields;
}
struct VerificationProof {
ProofType proofType;
bytes proofData;
bytes32[] publicInputs;
bytes32[] verificationKeys;
uint256 verificationGas;
}
// Enums
enum WorkloadType { INFERENCE, TRAINING, FINE_TUNING, VALIDATION }
enum ProofType { ZK_SNARK, ZK_STARK, OPTIMISTIC, TRUSTED }
// Events
event ReceiptCreated(bytes32 indexed receiptId, address indexed provider);
event ReceiptVerified(bytes32 indexed receiptId, bool verified);
event ReceiptRevoked(bytes32 indexed receiptId, string reason);
// Functions
function createReceipt(
WorkloadType workloadType,
WorkloadMetadata calldata metadata,
VerificationProof calldata proof
) external returns (bytes32 receiptId);
function verifyReceipt(bytes32 receiptId) external returns (bool verified);
function revokeReceipt(bytes32 receiptId, string calldata reason) external;
function getReceipt(bytes32 receiptId) external view returns (Receipt memory);
}
```
## Appendix B: Version History
| Version | Date | Changes |
|---------|------|---------|
| 1.0.0 | 2024-01-XX | Initial draft |
| 1.0.1 | 2024-02-XX | Added cross-chain verification |
| 1.1.0 | 2024-03-XX | Added batch verification support |
| 1.2.0 | 2024-04-XX | Enhanced privacy features |