Planning Doc - Oct. 29, 2022

Check progress since meetings in Paris

Medusa Notes Sept. 7 2022

Things to do by end of Q4

Collaboration & Team

Hire 1 - 2 Engineers.
- Daniel + Dan from Launchpad?
  
  —> @Deleted User @Jonathan Easterman Chat with him
- Outercore Engineers?
  - Ruben talk in process
- Start to look at Greenhouse → give access to Jonathan
Define a concrete collaboration goal / user target (within PL)
- P1 dOnlyFans collab where dOnlyFans content creator use medusa for access control
  - Higher priority: + ask on pushing for Logs
- Compute Over Data: unclear yet, haven’t been able to use them yet but let’s have a meeting with its engineers and talk before deciding on one
Emboard @[email protected] into the project and define the best strategies for product and the future of the project
FIP for precompiles: working early on this is necessary so we can get it when we want to deploy on FIL
- Here’s a good roadmap tracking EVM features… according to this, precompiles are done, but logs and solidity libraries are coming in the next 2 releases
- Wait… the work looks done?
  - And here’s an issue tracking an EVM Audit, which includes precompiles (implies that the work is done)
  - Maybe the precompiles that aren’t implemented are FVM-specific precompiles
    
    Update: YES BN254 are being WIP https://github.com/filecoin-project/builtin-actors/pull/654
- Answer: No, the work is done.
  - Do we really need a new FIP to get this implemented? If there is already a FIP to have an EVM runtime for Filecoin, I’d assume EVM runtime implies EVM precompiles. Maybe we can sidestep the whole FIP governance process and just talk to the FVM team (core devs?)
- FEVM description from FIP 30: Introducing the Filecoin Virtual Machine
- EVM precompiles in FVM spec (implies that precompiles will be taken from existing EVM implementation and compiled to WASM; therefore, not re-implemented or run in a true “native” way)
- Update: can’t deploy using foundry → hardhat works.
  - @Deleted User Ask on FVM whether to support Foundry ?

Project

Simplify the story telling of what Medusa does and how it works
- Need “someone” that tackles the whole “marketing” / “user perspective” side of Medusa
P2 Nodes deliver signed reencryption result onchain +
- This work highly depends on which platforms we launch
- ⚠️ What to do ?
  - Option 1. Trusted relayer in the meantime that we have bls12381 (wait for Eth, push on Arbitrum)
  - Option 2. Do it now
  - Option 3. Do in inside of a SNARK circuit - can be done with bn254 already
  - TODO @Deleted User @Jonathan Easterman Figure out when BLS12381 goes out
P1 🔥 Offer a nice Medusa SDK v1 to users @Jonathan Easterman
- update dependencies & cleaning
- Should we use typechain bindings?
- Expose a solid well documented library
- Typescript types for the FF library
P2 Node + network metrics monitoring
- Needs more info about libp2p network visibility
- Could be interesting for Daniel potential launchpad recruit
P1 🔥DKG Verification onchain: only requires dleq proof verification @Deleted User
P1 🔥DKG resharing add new nodes / remove nodes @Deleted User
Config file:
- P1 v0: config file with EVM specific
- P2: v1: generalization of notion of “Platform” (EVM, Cosmos, FVM, HTTP etc) with different entries in the config file
🔥 Privacy: We need to research and implement one method - using many of the already available framework for private signalling available on EVM.
- For dOnlyFans, at least hide who requests the content to be reencrypted
- We need a survey available tools we can use (semaphore. circuits, ring signatures, private contracts → think aztec
- 🔥 P1 Research phase + P2 implementation phase
P2/3 incentivized network; how to secure network against collusion; set high threshold and slash for lack of participation.
- P1 🔥Cryptoeconomics model research/discussion @Deleted User
- Depends on use case targeted in high priority: dOnlyFans case, will be the validators themselves.
- Weighted DKG / Resharing: implement in crypto code, not backward compatible