context

car-transaction/README.md at main · mikeal/car-transaction

https://github.com/mikeal/level-bucket-vm

motivation

we have a wide variety of use cases for a protocol solution to:

• executing protocols at scale
  • that are described as CAR files
• storing the result as a CAR
• and hold on to any state that has built up in that “instance” of the vm.
• and we really want the data these generate to be stored forever and available in the public network over IPFS/IPLD

requirements

• bucket-id
  • which is a DID
  • so it’s already a UCAN actor
• queue
  • of pending executions (car files)
  • to be executed in one of two “modes”
    • mutex - pending transactions are bulked to implement mutexes in any dependent protocols.
    • atomic - every transaction can and should be done concurrently.
• executor
  • the implementation of all protocols supported in the bucket.
  • we’ll do:
    • js functions for local implementations
    • something in AWS w/ Lambda, SQS and S3
    • something in Cloudflare w/ R2 and workers.
  • but you can see how it would be easy to implement in any
    • cloud provider
    • VM w/ sufficient storage like FVM
    • edge computing environment
    • embedded device
    • browser
      • in fact, the proof-of-concept is on leveldown so it already is

the implementations of various protocols can be chained into a single bucket-vm or dispatched across bucket-vm’s by simply returning a car file from one protocol that describes another protocol to be dispatched.

this produces unbounded functional composability without the ability to perform long term blocking operations (as long as people compose protocols using continuation passing rather than just blocking their executor, which can be encouraged by reducing timeouts).

• api
  • schedule (input:CAR CID)
    • should return something immediately that can be used to be notified of state changes, or perhaps the schedule api takes appropriate hooks to instrument
    • force flag - re-run a CAR CID that has already been run
    • note that in-memory implementations may just accept CAR files as input and generate - a CAR CID for persisting state.
  • receipt (input: car cid, output: car cid)
    • get the result of a prior execution