WIP: Design of a transparent/local AVM

Protocol Design
5

Changes to be made:

  • Change core data type to S-expressions of pair Sexp | natural
  • Add CALLER instruction (returns the identity of the caller).
  • Add CALLDATA instruction (returns the message sent to this object).
  • Drop the ownership restrictions, they’re too strict. This can be implemented by runtime checks where desired. Exception: we must keep them for data objects.
  • Add SOLVE instruction and REQUIRE instruction (per this topic)
    • Question: should SOLVE take constraints + preferences directly?
      • Preferences must be explicit (cannot be inferred). Preferences could be represented as a function (with our multiformat), which then must have a particular type (or it is just invalid).
      • Constraints can potentially be inferred. They kinda have to be inferred anyways, as the resulting value may be used in ways which would result in REVERT in a value-conditional manner.
  • Consider adding SELFDESTRUCT. This would allow for code objects to be destroyed.
    • DESTROY does not work for this as there is no way to enforce permissioning.
  • Add REFLECT instruction which reads an object’s code (or data-object-ness). Note that the use of REFLECT will break observational symmetry (we can no longer replace object-programs by other object-programs which are behaviorally equivalent).
  • Add DEFINE_FUNCTION at an “administrative” level (permissioned) which must include lower-level bytecode legible to the host (e.g. RISC-V).

Transactional semantics:

  • REVERT is already implicitly transactional, just make it explicit.
  • Add BEGIN [controller] which starts a transactional context. This was already somewhat implicit. Transactional contexts must be specific to a controller.
  • Add COMMIT which [attempts to] commit a transactional context. This was already somewhat implicit. Commit returns success/failure (which can subsequently be acted on). TELEPORT (to the appropriate controller) must be called before COMMIT.
  • Add TELEPORT [node] which packages the current transactional context as a transaction function + transaction pair and jumps to the specified node to continue execution. TELEPORT can be used in conjunction with SOLVE for flexible teleportation (“any solver”). This allows for first-class control over when transaction function “packaging” happens.
  • Add LOCAL (or such) which returns the identifier of the executing controller.
1 Like