Add TMCall and verify_with_retry: TM-side VM protocol helpers - #7
Open
zephyrnova wants to merge 2 commits into
Open
Add TMCall and verify_with_retry: TM-side VM protocol helpers#7zephyrnova wants to merge 2 commits into
zephyrnova wants to merge 2 commits into
Conversation
Adds a TM (Transaction Machine) counterpart to the existing AIMCall yield- helper: a VM program can yield TMCall(action, request) to talk to the host's TM container (info/balance/commit/verify/settle, plus host-specific extension verbs). tm_type selects which TM handles the call on hosts that run more than one type side by side, defaulting to "nullpay" so every pre-existing VM program's behavior is unchanged -- purely additive. Also adds .gitignore for __pycache__/*.pyc.
…rify Thin client-side shim wrapping a bounded retry/backoff around a TM "verify" call, for any VM/brain program's pay-then-trust flow. A twin-to-twin transfer's funds move immediately, but the payee's binder (what "verify" scans to confirm the transfer happened) can take a short moment to reflect a just-landed transfer -- calling verify immediately after a payment can see a binder that doesn't yet include the entry and fail closed even though the payment is completely valid. The retry/backoff loop itself runs host-side (dispatched via the "verify_with_retry" TM action), not in this generator -- a client-side time.sleep here would block the calling VM container's own async event loop for the whole retry window. This function is a thin pass-through to an async-safe host implementation, not a client-side polling loop.
zephyrnova
force-pushed
the
feat/toda-tm-support
branch
from
July 17, 2026 18:12
fbeafda to
52d6a8b
Compare
zephyrnova
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds a TM (Transaction Machine) counterpart to the existing
AIMCallyield-helper invm.py:TMCall(action, request, tm_type="nullpay")-- a VM program yieldsTMCall(action, request)to talk to the host's TM container (verbs: info/balance/commit/verify/settle, plus host-specific extension verbs). MirrorsAIMCall's exact shape (a status-tagged dict) so a driving loop only needs one moreelifbranch to support it.tm_typeselects which TM handles the call on hosts running more than one type side by side; defaults to"nullpay", so every pre-existing VM program's behavior is byte-identical -- purely additive, verified against the diff (only new module-level content, nothing in the existing file touched).verify_with_retry(twin_nonce, amount, root=None, tm_type="toda")-- ayield fromhelper for a VM/brain program's pay-then-trust flow. A twin-to-twin transfer's funds move immediately, but the payee's binder (whatverifyscans to confirm the transfer happened) can take a short moment to catch up -- calling verify immediately after a payment can see a binder that doesn't yet include the entry and fail closed even though the payment is completely valid.Design note on
verify_with_retry, changed after initial review: the retry/backoff loop runs host-side (dispatched via a"verify_with_retry"TM action), not client-side in this generator. An earlier version of this PR looped withtime.sleepinside the generator itself -- since this generator is driven synchronously from inside the VM container's ownasyncwebsocket-handling loop, that blocked the container's entire event loop for up to several seconds per retry, stalling every other request it was trying to serve. This version is a thin pass-through to an async-safe host implementation instead. Depends on the corresponding host-side"verify_with_retry"dispatch, which lands in a follow-onnode-managerPR -- until that's merged, this helper's yield will hit the host's "unknown tm_call action" fallback rather than actually retrying.Testing: no test suite exists in this repo currently (checked); behavior verified by direct code inspection against the host-side envelope contract (
{"result": ..., "headers": ...}) and by tracing the actual VM-container driving loop this generator runs inside.Built during the HyperCycle multinode TM/VM experiment, no longer referencing any experiment-only files or paths.