Previously, the initial Azimuth snapshot was stored in Clay and shipped
in the pill. This causes several problems:
- It bloats the pill
- Updating the snapshot added large blobs to Clay's state. Even now
that tombstoning is possible, you don't want to have to do that
regularly.
- As a result, the snapshot was never updated.
- Even if you did tombstone those files, it could only be updated as
often as the pill
- And those updates would be sent over the network to people who didn't
need them
This moves the snapshot out of the pill and refactors Azimuth's
initialization process. On boot, when app/azimuth starts up, it first
downloads a snapshot from bootstrap.urbit.org and uses that to
initialize its state. As before, updates after this initial snapshot
come from an Ethereum node directly and are verified locally.
Relevant commands are:
- `-azimuth-snap-state %filename` creates a snapshot file
- `-azimuth-load "url"` downloads and inits from a snapshot, with url
defaulting to https://bootstrap.urbit.org/mainnet.azimuth-snapshot
- `:azimuth &azimuth-poke-data %load snap-state` takes a snap-state any
way you have it
Note the snapshot is downloaded from the same place as the pill, so this
doesn't introduce additional trust beyond what was already required.
When remote scry is released, we should consider allowing downloading
the snapshot in that way.
Changes the test command to check if args contains a single path and
wraps it in a list. Now a test thread can be started without providing
a list:
-test %/tests/lib
And passing a list still works:
test %/tests/lib ~
One nit in this change is the lark expression to reach into args: if
args is ~ then instead of getting a useful need/have error, the test
ends in a "false-start". Perhaps this could be fixed by detecting ~
and setting it to %/tests.
Only "shortmoons" though, due to some ames lane size limitation which
makes encoding longer ships difficult.
Notably the -ph-moon-az test does not pass, the moon cannot talk to a
non-sponsor galaxy.
