feat: add Apollo v2 (Go) off-chain implementations - #65
Open
wolf31o2 wants to merge 1 commit into
Open
Conversation
Adds Go to the off-chain framework matrix, implemented with Apollo v2.0.1.
Go is a new runtime for this repo, so this carries the runtime plumbing
alongside two use-case implementations: simple-transfer and vesting.
Apollo v2 is built on the Blink Labs Cardano libraries — gouroboros for
ledger types, CBOR and addresses, bursa for wallet derivation and signing,
and plutigo for Plutus data. Apollo has no ApplyParamsToScript, so
simple-transfer applies the receiver key hash to its parameterised validator
using plutigo's UPLC codec directly: decode the flat program, wrap its term
in an Apply node carrying the parameter as a Data constant, re-encode.
Runtime plumbing:
- frameworks.json entry (runtime "go", statusPrefix "apollo")
- go case in scripts/local-test-offchain.sh, running `go run .`
- .github/actions/setup-go, sourcing the toolchain from each module's
go.mod so a Go floor bump needs no workflow edit
- go branches in _test-offchain.yml and ecosystem-test.yml
- scaffold templates plus a go case in scaffold-offchain.sh
- Apollo pinned in versions.json and handled by both version scripts,
including go.sum regeneration so an automated bump cannot leave a tree
that fails -mod=readonly
Both entry files are standalone per docs/ADDING-A-LIBRARY.md: they read
PLUTUS_JSON with a fallback to the local Aiken blueprint, look the validator
up by title with an index fallback, and exit non-zero on any failure.
Verified locally: go vet, cold-cache -mod=readonly builds and go mod verify
on both modules; parameter application byte-identical to `aiken blueprint
apply` for two separate key hashes; VestingDatum encoding matching the Aiken
type; script hashes and addresses recomputed against the blueprint; and the
frameworks.json -> discovery -> CI matrix -> resolve_status -> dashboard
identifier chain checked end to end.
Not verified: neither scenario has transacted against a live chain. The
development machine is arm64 and yaci-devkit is amd64-only, so end-to-end
runs are still outstanding.
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 Go to the off-chain framework matrix, implemented with Apollo v2.0.1. Go is a new runtime for this repo, so this carries the runtime plumbing alongside two use-case implementations: simple-transfer and vesting.
Apollo v2 is built on the Blink Labs Cardano libraries — gouroboros for ledger types, CBOR and addresses, bursa for wallet derivation and signing, and plutigo for Plutus data. Apollo has no ApplyParamsToScript, so simple-transfer applies the receiver key hash to its parameterised validator using plutigo's UPLC codec directly: decode the flat program, wrap its term in an Apply node carrying the parameter as a Data constant, re-encode.
Runtime plumbing:
go run .Both entry files are standalone per docs/ADDING-A-LIBRARY.md: they read PLUTUS_JSON with a fallback to the local Aiken blueprint, look the validator up by title with an index fallback, and exit non-zero on any failure.
Verified locally: go vet, cold-cache -mod=readonly builds and go mod verify on both modules; parameter application byte-identical to
aiken blueprint applyfor two separate key hashes; VestingDatum encoding matching the Aiken type; script hashes and addresses recomputed against the blueprint; and the frameworks.json -> discovery -> CI matrix -> resolve_status -> dashboard identifier chain checked end to end.Not verified: neither scenario has transacted against a live chain. The development machine is arm64 and yaci-devkit is amd64-only, so end-to-end runs are still outstanding.