Current Functionality
- Re-encryption
Functionality to Add
Core Operations
- Public Decryption
- (Signatures / random beacon)?
Software architecture:
- ⭐upgrade mechanism !!!
- for the threshold network
- for the smart contracts
- Test coverage / CI / infra / monitoring
- Client + (Daemon + RPC interface)
- ⭐Multi chain interface (abstract the blockchain) !!
- Files upload / client library !!
- Encrypt Key that encrypts a file stored off chain (IPFS)
- Trusted Relayer (testnet v1) vs. signed re-encryption (testnet v2) vs. zksnark proof of re-encryption (BLS12-381 curve in eth2)
Additional Infrastructure
- Relayer node
- Send results back to chain
- Websocket server for clients to receive events quicker
- incentives?
Design Questions to Answer
- Payments / scalability?
- L2 Appchain?
People Problems
- Use-case / customer
- Partners / sponsors to run nodes
- Documentation
Delivering result to end user
Option 1 (current) : pass by result on chain
Option 2: pass by a separate public gossip network / http gateway
- Problem : how to incentivize and guarantee service delivery
Brainstorm sessions
Incentivization
- Of nodes
- Of clients
Blockchain vs nonblockchain:
- dividends: real life non blockchain can pay in fiat, and someone buys back the token and token value increase so nodes are rewarded
- Users would pay gas
Validation mechanism to abstract in oracle.rs:220 get_ciphertext_submission
- in blockchain world validation is done on smart contract level, just check if request == submission
- in non blockchain world, validation must be done at the node level
Upgrade Mechanism
Smart contract:
- Option 1 is not upgrade, immutable
- Option 2: is proxy but error prone, censorhsip, governance problem etc
Rust Medusa Node:
- Check with libp2p if they can already help with upgrade mechanism
Encryption method:
- Metadata “suite” name to do which includes curve, ciphersuite, etc
Maybe not update smart contract because of future of Medusa (integration with other system) but focus on rust Node medusa because that will stay