Unstructured notes

Starting with large datasets makes sense for the project

• Especially makes sense with larger data, and longer processes, because longer jobs and orchestration
• Don't spend time with match making, etc Fission direction
• When you have networks where all the data is in one namespace, and everyone is the same layer, you could start caching subresults
• By working together, you get more efficiency with more info
• By referencing the merkle tree, you could cache more
• You could do hotspot analysis - how/where to speed up Two directions
• K8s
• WASM - WASM is closer to the direction
  • You don't need to ship around the entire container Have we looked at Gollum?
• Flow:
  • They were doing roughly what we were describing
  • Post a docker container
  • Match making on the block chain
  • Output a 3D render
• Never got there because of the speed necessary to accept and run jobs We're talking about cloud use cases right now
• But what would it look like for edge use cases - like a cloudflare worker
• Something that might run on a private network Fission
• Does not run big jobs
• Stuff they work on affect PLN and other parts of the stack Biggest thing that would help them in the long term is the really efficient orchestration layer
• Doing things like posting jobs on the FVM
• Maybe start with pushing containers over nodes to start Challenge with FVM
• It's not a fast method of broadcast
• BUT - build a data availability layer (laconic)
• Instead of waiting for the item to come in via the blockchain, get consensus, etc
• Everyone sets some money aside (bonds) in the chain, then we have a side agreement
• Similar to lightning network
• State channels => L2 for consensus Netflix - push around docker images
• Diff was really small Burning questions:
• How do we deal with security
• How do we deal with the halting problem Problems
• Have multiple people run the compute and then gain agreement
  • Docker side effects
  • WASM does offer some close-ish deterministic effects
  • BUT won't be able to lean on commodity things
• How do you deal with not enabling claiming stuff as your own
  • Wrap it in a symmetric encryption
  • Only once you pay, you clear the data
  • Use a reputation system to slash the results
  • Heavy-weight stuff (SNARKs)
• ZK-SNARK is too early in practice
  • Work going into high level images that compile down
  • In concept you could use it, but wait 5 years
• Run the job several times, confirm the results
  • Provide the container and the "check me" function WASM is extremely constrained
• You can compile python into WASM, with the entire runtime, GC, etc
• You won't have networking, randomness, etc - depends on the host environemnt

---

• reputation system

  • combine the consensus on results hash with reputation system

• determinism

  • turns out that go will try hard to be non-deterministic
    • find out that if we compile go to WASM, if a simple use-case could still be non-deterministic
  • the go playground is forced to be deterministic (e.g. they fix the date)

• forcing determinsm

  • do we need to stop people from writing non-deterministic code or not?

• halting problem approach

  • there is a "profile" of running code - stack trace, CPU usage, memory usage, etc.
  • by just looking at the code - it would be very hard to guess what this is
  • you might as well run the code
  • we then need a way of comparing fingerprints (proofs of computation a.k.a. stack trace, CPU usage, memory usage, etc.) with a tolerance

• there are 2 types of non-determinsm

  • 1. the results
  • 2. the profile of running code