2022-05-12 08:14:26 +03:00
|
|
|
/- eth-watcher, *dice, *hood
|
2021-07-22 07:34:42 +03:00
|
|
|
/+ ethereum,
|
|
|
|
azimuth,
|
|
|
|
naive,
|
|
|
|
dice,
|
|
|
|
default-agent,
|
|
|
|
verb,
|
|
|
|
dbug
|
2021-12-03 18:11:15 +03:00
|
|
|
:: To update, run from dojo:
|
2021-12-10 18:19:59 +03:00
|
|
|
:: -azimuth-snap-state %default 'version-0'
|
2021-12-03 18:11:15 +03:00
|
|
|
::
|
2021-12-14 11:40:34 +03:00
|
|
|
:: To recreate from a full list of logs (at /app/azimuth/logs/eth-logs):
|
2021-12-10 18:19:59 +03:00
|
|
|
:: -azimuth-snap-logs %default 'version-0'
|
2021-11-09 11:22:32 +03:00
|
|
|
::
|
2021-04-08 10:36:34 +03:00
|
|
|
=, jael
|
|
|
|
|%
|
2021-08-27 17:05:59 +03:00
|
|
|
+$ app-state
|
azimuth: fetch snapshot on boot
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.
2022-07-01 08:55:57 +03:00
|
|
|
$: %7
|
2021-04-08 10:36:34 +03:00
|
|
|
url=@ta
|
2021-11-09 11:22:32 +03:00
|
|
|
=net
|
2022-03-30 13:18:25 +03:00
|
|
|
refresh=_~m5
|
2021-04-08 10:36:34 +03:00
|
|
|
whos=(set ship)
|
|
|
|
nas=^state:naive
|
2021-06-28 08:26:47 +03:00
|
|
|
own=owners
|
2021-11-10 19:46:22 +03:00
|
|
|
spo=sponsors
|
2021-04-08 10:36:34 +03:00
|
|
|
logs=(list =event-log:rpc:ethereum)
|
azimuth: fetch snapshot on boot
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.
2022-07-01 08:55:57 +03:00
|
|
|
sap=snap-state
|
2021-04-08 10:36:34 +03:00
|
|
|
==
|
2021-08-27 17:05:59 +03:00
|
|
|
::
|
2021-04-08 10:36:34 +03:00
|
|
|
+$ poke-data
|
azimuth: fetch snapshot on boot
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.
2022-07-01 08:55:57 +03:00
|
|
|
$% :: %load: load snapshot
|
|
|
|
::
|
|
|
|
[%load snap=snap-state]
|
|
|
|
:: %listen
|
2021-04-08 10:36:34 +03:00
|
|
|
::
|
|
|
|
[%listen whos=(list ship) =source:jael]
|
2021-08-27 17:05:59 +03:00
|
|
|
:: %watch: configure node url and network
|
2021-04-08 10:36:34 +03:00
|
|
|
::
|
2021-11-09 11:22:32 +03:00
|
|
|
[%watch url=@ta =net]
|
2022-05-07 17:27:04 +03:00
|
|
|
:: %kick: re-start %azimuth subscriptions
|
|
|
|
::
|
|
|
|
[%kick ~]
|
2021-04-08 10:36:34 +03:00
|
|
|
==
|
2021-05-29 16:42:27 +03:00
|
|
|
::
|
2021-08-27 17:05:59 +03:00
|
|
|
+$ tagged-diff [=id:block diff:naive]
|
|
|
|
+$ card card:agent:gall
|
2021-04-08 10:36:34 +03:00
|
|
|
--
|
|
|
|
::
|
2021-08-27 17:05:59 +03:00
|
|
|
=| state=app-state
|
|
|
|
%- agent:dbug
|
|
|
|
%+ verb |
|
|
|
|
^- agent:gall
|
2022-05-07 17:27:04 +03:00
|
|
|
:: Cards
|
|
|
|
::
|
|
|
|
=> |%
|
|
|
|
++ subscribe-to-eth-watcher
|
|
|
|
|= =bowl:gall
|
|
|
|
^- card
|
|
|
|
:* %pass /eth-watcher %agent [our.bowl %eth-watcher]
|
|
|
|
%watch /logs/[dap.bowl]
|
|
|
|
==
|
|
|
|
::
|
|
|
|
++ listen-to-azimuth
|
|
|
|
|= [ships=(set ship) =source:jael]
|
|
|
|
^- card
|
|
|
|
[%pass /lo %arvo %j %listen ships source]
|
|
|
|
::
|
|
|
|
++ nuke-azimuth-tracker
|
|
|
|
|= =bowl:gall
|
|
|
|
^- card
|
|
|
|
:* %pass /old-tracker %agent [our.bowl %hood]
|
|
|
|
%poke %kiln-nuke !>([%azimuth-tracker %|])
|
|
|
|
==
|
|
|
|
::
|
|
|
|
++ init-timer
|
azimuth: fetch snapshot on boot
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.
2022-07-01 08:55:57 +03:00
|
|
|
|= at=@da
|
2022-05-07 17:27:04 +03:00
|
|
|
^- card
|
azimuth: fetch snapshot on boot
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.
2022-07-01 08:55:57 +03:00
|
|
|
[%pass /init %arvo %b %wait at]
|
2022-05-07 17:27:04 +03:00
|
|
|
::
|
|
|
|
++ start-log-retrieval
|
|
|
|
|= [=ship args=vase]
|
|
|
|
^- card
|
|
|
|
[%pass /wa %agent [ship %eth-watcher] %poke %eth-watcher-poke args]
|
azimuth: fetch snapshot on boot
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.
2022-07-01 08:55:57 +03:00
|
|
|
::
|
|
|
|
++ start-azimuth-load
|
|
|
|
^- card
|
|
|
|
[%pass /al %arvo %k %fard %base %azimuth-load %noun !>(~)]
|
2022-05-07 17:27:04 +03:00
|
|
|
--
|
|
|
|
::
|
2021-08-27 17:05:59 +03:00
|
|
|
=<
|
|
|
|
|_ =bowl:gall
|
|
|
|
+* this .
|
|
|
|
do ~(. +> bowl)
|
|
|
|
def ~(. (default-agent this %|) bowl)
|
|
|
|
::
|
|
|
|
++ on-init
|
|
|
|
:_ this
|
2021-11-10 09:36:05 +03:00
|
|
|
?: .^(? %j /(scot %p our.bowl)/fake/(scot %da now.bowl))
|
|
|
|
~
|
azimuth: fetch snapshot on boot
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.
2022-07-01 08:55:57 +03:00
|
|
|
~[(init-timer now.bowl)]
|
2021-08-27 17:05:59 +03:00
|
|
|
++ on-save !>(state)
|
|
|
|
++ on-load
|
|
|
|
|= old=vase
|
|
|
|
^- (quip card _this)
|
2021-11-10 19:46:22 +03:00
|
|
|
|^
|
|
|
|
=+ !<(old-state=app-states old)
|
|
|
|
=? old-state ?=(%0 -.old-state)
|
|
|
|
=, old-state
|
|
|
|
[%1 url net whos nas own *sponsors logs]
|
2021-11-17 21:03:15 +03:00
|
|
|
=^ cards-1 old-state
|
|
|
|
?. ?=(%1 -.old-state)
|
|
|
|
`old-state
|
|
|
|
%- %- slog :_ ~
|
2021-12-09 09:30:08 +03:00
|
|
|
leaf+"ship: loading snapshot with {<(lent logs.old-state)>} events"
|
azimuth: fetch snapshot on boot
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.
2022-07-01 08:55:57 +03:00
|
|
|
=. +.state +:(state-6-to-7 (state-5-to-6 old-state))
|
2021-11-17 21:03:15 +03:00
|
|
|
=^ cards state
|
|
|
|
(%*(run-logs do nas.state *^state:naive) logs.state)
|
|
|
|
[(jael-update:do (to-udiffs:do cards)) state]
|
2022-01-07 20:13:51 +03:00
|
|
|
=^ cards-2 old-state
|
|
|
|
?. ?=(%2 -.old-state)
|
|
|
|
`old-state
|
2022-01-08 11:48:28 +03:00
|
|
|
~& > '%azimuth: updating to state 3'
|
azimuth: fetch snapshot on boot
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.
2022-07-01 08:55:57 +03:00
|
|
|
=. +.state +:(state-6-to-7 (state-5-to-6 old-state))
|
2022-01-07 20:13:51 +03:00
|
|
|
:: replace naive state and indices with snapshot
|
|
|
|
::
|
azimuth: fetch snapshot on boot
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.
2022-07-01 08:55:57 +03:00
|
|
|
=: nas.state nas.sap.state
|
|
|
|
own.state owners.sap.state
|
|
|
|
spo.state sponsors.sap.state
|
2022-01-08 11:48:28 +03:00
|
|
|
logs.state ~
|
|
|
|
:: TODO: shouldn't be needed but have seen eth-watcher
|
|
|
|
:: threads use a url='' if this is not used
|
|
|
|
::
|
|
|
|
url.state 'http://eth-mainnet.urbit.org:8545'
|
2022-01-07 20:13:51 +03:00
|
|
|
==
|
2022-01-08 11:48:28 +03:00
|
|
|
=/ points=@ud ~(wyt by points.nas.state)
|
2022-01-07 20:13:51 +03:00
|
|
|
%- %- slog :_ ~
|
azimuth: fetch snapshot on boot
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.
2022-07-01 08:55:57 +03:00
|
|
|
leaf+"ship: processing azimuth snapshot (~{<points>} points)"
|
|
|
|
=/ snap-cards=udiffs:point (run-state:do id.sap.state points.nas.state)
|
2022-03-30 13:18:25 +03:00
|
|
|
:_ [%3 url net whos nas own spo logs]:state
|
2022-01-08 11:48:28 +03:00
|
|
|
%+ weld
|
2022-01-07 20:13:51 +03:00
|
|
|
(jael-update:do snap-cards)
|
2022-01-08 11:48:28 +03:00
|
|
|
:: start getting new logs after the last id:block in the snapshot
|
|
|
|
::
|
|
|
|
start:do
|
|
|
|
=^ cards-3 old-state
|
|
|
|
?. ?=(%3 -.old-state) [cards-2 old-state]
|
|
|
|
:_ old-state(- %4)
|
|
|
|
~& > '%azimuth: updating to state 4'
|
|
|
|
[%pass /resend-pk %arvo %j %resend ~]^cards-2
|
2022-01-19 19:41:05 +03:00
|
|
|
=^ cards-4 old-state
|
|
|
|
?. ?=(%4 -.old-state) [cards-3 old-state]
|
|
|
|
=^ cards this
|
azimuth: fetch snapshot on boot
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.
2022-07-01 08:55:57 +03:00
|
|
|
%- %*(. on-poke +.state.this +:(state-6-to-7 (state-5-to-6 old-state)))
|
2022-01-19 19:41:05 +03:00
|
|
|
[%azimuth-poke !>([%watch [url net]:old-state])]
|
|
|
|
~& > '%azimuth: updating to state 5'
|
2022-03-30 13:18:25 +03:00
|
|
|
[cards [%5 url net whos nas own spo logs]:state.this]
|
|
|
|
=? old-state ?=(%5 -.old-state)
|
|
|
|
(state-5-to-6 old-state)
|
azimuth: fetch snapshot on boot
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.
2022-07-01 08:55:57 +03:00
|
|
|
=? old-state ?=(%6 -.old-state)
|
|
|
|
(state-6-to-7 old-state)
|
|
|
|
?> ?=(%7 -.old-state)
|
2022-01-19 19:41:05 +03:00
|
|
|
[cards-4 this(state old-state)]
|
2021-11-10 19:46:22 +03:00
|
|
|
::
|
azimuth: fetch snapshot on boot
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.
2022-07-01 08:55:57 +03:00
|
|
|
++ app-states $%(state-0 state-1-2-3-4-5 state-6 app-state)
|
2022-01-08 11:48:28 +03:00
|
|
|
::
|
azimuth: fetch snapshot on boot
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.
2022-07-01 08:55:57 +03:00
|
|
|
+$ state-6
|
|
|
|
$: %6
|
|
|
|
url=@ta
|
|
|
|
=net
|
|
|
|
refresh=_~m5
|
|
|
|
whos=(set ship)
|
|
|
|
nas=^state:naive
|
|
|
|
own=owners
|
|
|
|
spo=sponsors
|
|
|
|
logs=(list =event-log:rpc:ethereum)
|
|
|
|
==
|
2022-03-30 13:18:25 +03:00
|
|
|
+$ state-1-2-3-4-5
|
|
|
|
$: ?(%1 %2 %3 %4 %5)
|
2021-11-17 21:03:15 +03:00
|
|
|
url=@ta
|
|
|
|
=net
|
|
|
|
whos=(set ship)
|
|
|
|
nas=^state:naive
|
|
|
|
own=owners
|
|
|
|
spo=sponsors
|
|
|
|
logs=(list =event-log:rpc:ethereum)
|
|
|
|
==
|
2021-11-10 19:46:22 +03:00
|
|
|
::
|
|
|
|
++ state-0
|
|
|
|
$: %0
|
|
|
|
url=@ta
|
|
|
|
=net
|
|
|
|
whos=(set ship)
|
|
|
|
nas=^state:naive
|
|
|
|
own=owners
|
|
|
|
logs=(list =event-log:rpc:ethereum)
|
|
|
|
==
|
azimuth: fetch snapshot on boot
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.
2022-07-01 08:55:57 +03:00
|
|
|
++ state-5-to-6
|
|
|
|
|= state-1-2-3-4-5
|
|
|
|
^- state-6
|
|
|
|
[%6 url net ~m5 whos nas own spo logs]
|
|
|
|
::
|
|
|
|
++ state-6-to-7
|
|
|
|
|= state-6
|
|
|
|
^- app-state
|
|
|
|
[%7 url net refresh whos nas own spo logs *snap-state]
|
2021-11-10 19:46:22 +03:00
|
|
|
--
|
2021-08-27 17:05:59 +03:00
|
|
|
::
|
|
|
|
++ on-poke
|
|
|
|
|= [=mark =vase]
|
|
|
|
^- (quip card _this)
|
|
|
|
?: =(%noun mark)
|
|
|
|
?+ q.vase !!
|
2022-03-30 13:18:25 +03:00
|
|
|
[%refresh-rate @]
|
|
|
|
=. refresh.state +.q.vase
|
|
|
|
[start:do this]
|
2022-01-08 21:28:11 +03:00
|
|
|
::
|
|
|
|
%rerun
|
|
|
|
=/ points=@ud ~(wyt by points.nas.state)
|
|
|
|
~& > "rerunning ({<points>} points)"
|
|
|
|
=/ =udiffs:point
|
|
|
|
(run-state:do (last-block-id:dice logs.state) points.nas.state)
|
|
|
|
[(jael-update:do udiffs) this]
|
2021-08-27 17:05:59 +03:00
|
|
|
::
|
|
|
|
%resub
|
2022-05-07 17:27:04 +03:00
|
|
|
:_ this
|
|
|
|
[(subscribe-to-eth-watcher bowl)]~
|
2021-08-27 17:05:59 +03:00
|
|
|
::
|
|
|
|
%resnap
|
azimuth: fetch snapshot on boot
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.
2022-07-01 08:55:57 +03:00
|
|
|
=: nas.state nas.sap.state
|
|
|
|
own.state owners.sap.state
|
|
|
|
spo.state sponsors.sap.state
|
2021-12-03 18:11:15 +03:00
|
|
|
==
|
|
|
|
`this
|
2021-08-27 17:05:59 +03:00
|
|
|
==
|
|
|
|
::
|
|
|
|
?. ?=(%azimuth-poke mark)
|
|
|
|
(on-poke:def mark vase)
|
|
|
|
=+ !<(poke=poke-data vase)
|
azimuth: fetch snapshot on boot
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.
2022-07-01 08:55:57 +03:00
|
|
|
|-
|
2021-08-27 17:05:59 +03:00
|
|
|
?- -.poke
|
azimuth: fetch snapshot on boot
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.
2022-07-01 08:55:57 +03:00
|
|
|
%load
|
|
|
|
=/ points=@ud ~(wyt by points.nas.snap.poke)
|
|
|
|
%- %- slog
|
|
|
|
[leaf+"ship: loading azimuth snapshot ({<points>} points)"]~
|
|
|
|
::
|
|
|
|
=: net.state %default
|
|
|
|
nas.state nas.snap.poke
|
|
|
|
own.state owners.snap.poke
|
|
|
|
spo.state sponsors.snap.poke
|
|
|
|
url.state 'http://eth-mainnet.urbit.org:8545'
|
|
|
|
sap.state snap.poke
|
|
|
|
==
|
|
|
|
$(poke [%kick ~])
|
|
|
|
::
|
2021-08-27 17:05:59 +03:00
|
|
|
%listen
|
2022-05-07 17:27:04 +03:00
|
|
|
[[(listen-to-azimuth (silt whos.poke) source.poke)]~ this]
|
|
|
|
::
|
|
|
|
%kick
|
|
|
|
=/ last-block=@
|
|
|
|
?^ logs.state
|
|
|
|
number:(last-block-id:dice logs.state)
|
azimuth: fetch snapshot on boot
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.
2022-07-01 08:55:57 +03:00
|
|
|
:: ~& >> %no-logs-in-azimuth-state
|
|
|
|
number.id.sap.state
|
2022-05-12 08:14:26 +03:00
|
|
|
=+ [our=(scot %p our.bowl) now=(scot %da now.bowl)]
|
|
|
|
=+ .^(dudes=(set [dude:gall ?]) %ge our %base now /)
|
|
|
|
=/ running=? (~(has in dudes) [%eth-watcher &])
|
|
|
|
=/ installed=?
|
|
|
|
|((~(has in dudes) [%eth-watcher &]) (~(has in dudes) [%eth-watcher |]))
|
2022-05-07 17:27:04 +03:00
|
|
|
:_ this
|
|
|
|
=/ cards=(list card)
|
|
|
|
:- :: %jael will re-subscribe to get all azimuth diffs
|
|
|
|
::
|
|
|
|
(listen-to-azimuth ~ [%| dap.bowl])
|
|
|
|
:: we poke eth-watcher to retrieve logs from the latest we have
|
|
|
|
::
|
azimuth: fetch snapshot on boot
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.
2022-07-01 08:55:57 +03:00
|
|
|
%*(start do number.id.sap.state last-block)
|
2022-05-12 08:14:26 +03:00
|
|
|
=? cards !running
|
|
|
|
:: restart %eth-watcher
|
|
|
|
::
|
|
|
|
~& >> %starting-eth-watcher
|
|
|
|
=/ rein=[desk rein] [%base %.y [%eth-watcher ~ ~] ~]
|
|
|
|
:_ cards
|
|
|
|
[%pass /rein %agent [our.bowl %hood] %poke kiln-rein+!>(rein)]
|
|
|
|
=? cards !installed
|
|
|
|
:: reinstall %base desk
|
|
|
|
::
|
|
|
|
=+ spo=(sein:title [our now our]:bowl)
|
|
|
|
~& >> re-installing-base-from+spo
|
|
|
|
=/ fresh=[desk ship desk] [%base spo %kids]
|
|
|
|
:_ cards
|
|
|
|
[%pass /fresh %agent [our.bowl %hood] %poke kiln-install+!>(fresh)]
|
2022-05-07 17:27:04 +03:00
|
|
|
:: resubscribe if we somehow get unsubscribed from eth-watcher
|
|
|
|
::
|
|
|
|
?: (~(has by wex.bowl) [/eth-watcher our.bowl %eth-watcher])
|
|
|
|
cards
|
azimuth: fetch snapshot on boot
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.
2022-07-01 08:55:57 +03:00
|
|
|
:: ~& >> %resubscribing-to-eth-watcher
|
2022-05-07 17:27:04 +03:00
|
|
|
[(subscribe-to-eth-watcher bowl) cards]
|
2021-08-27 17:05:59 +03:00
|
|
|
::
|
|
|
|
%watch
|
azimuth: fetch snapshot on boot
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.
2022-07-01 08:55:57 +03:00
|
|
|
=: nas.state ?:(?=(%default net.poke) nas.sap.state *^state:naive)
|
|
|
|
own.state ?:(?=(%default net.poke) owners.sap.state ~)
|
|
|
|
spo.state ?:(?=(%default net.poke) sponsors.sap.state ~)
|
2021-08-27 17:05:59 +03:00
|
|
|
net.state net.poke
|
|
|
|
url.state url.poke
|
2021-12-03 18:11:15 +03:00
|
|
|
logs.state ~
|
2021-08-27 17:05:59 +03:00
|
|
|
==
|
azimuth: fetch snapshot on boot
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.
2022-07-01 08:55:57 +03:00
|
|
|
`this
|
2021-08-27 17:05:59 +03:00
|
|
|
==
|
2021-05-29 16:42:27 +03:00
|
|
|
::
|
2021-08-27 17:05:59 +03:00
|
|
|
++ on-watch
|
|
|
|
|= =path
|
|
|
|
^- (quip card _this)
|
|
|
|
?< =(/sole/drum path)
|
|
|
|
?: =(/event path)
|
|
|
|
:_ this
|
2021-11-10 19:46:22 +03:00
|
|
|
[%give %fact ~ %naive-state !>([nas.state own.state spo.state])]~
|
2021-08-27 17:05:59 +03:00
|
|
|
=/ who=(unit ship)
|
|
|
|
?~ path ~
|
|
|
|
?: ?=([@ ~] path) ~
|
|
|
|
`(slav %p i.path)
|
|
|
|
=. whos.state
|
|
|
|
?~ who
|
|
|
|
~
|
|
|
|
(~(put in whos.state) u.who)
|
|
|
|
^- (quip card _this)
|
2021-11-09 11:42:34 +03:00
|
|
|
:: Slow to recalculate all the diffs, but this is necessary to make
|
|
|
|
:: sure Jael gets the updates from the snapshot
|
|
|
|
::
|
2021-12-08 14:52:23 +03:00
|
|
|
=/ points=@ud ~(wyt by points.nas.state)
|
2021-11-09 11:42:34 +03:00
|
|
|
%- %- slog :_ ~
|
2021-12-03 18:11:15 +03:00
|
|
|
:- %leaf
|
2021-12-09 09:30:08 +03:00
|
|
|
"ship: processing azimuth snapshot ({<points>} points)"
|
2021-12-03 18:11:15 +03:00
|
|
|
=/ snap-cards=udiffs:point
|
azimuth: fetch snapshot on boot
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.
2022-07-01 08:55:57 +03:00
|
|
|
(%*(run-state do logs.state ~) id.sap.state points.nas.state)
|
2021-12-03 18:11:15 +03:00
|
|
|
[(weld (jael-update:do snap-cards) start:do) this]
|
2021-08-27 17:05:59 +03:00
|
|
|
::
|
|
|
|
++ on-leave on-leave:def
|
|
|
|
++ on-peek
|
|
|
|
|= =path
|
|
|
|
^- (unit (unit cage))
|
|
|
|
|^
|
|
|
|
?+ path (on-peek:def path)
|
|
|
|
[%x %logs ~] ``noun+!>(logs.state)
|
|
|
|
[%x %nas ~] ``noun+!>(nas.state)
|
|
|
|
[%x %dns ~] ``noun+!>(dns.nas.state)
|
|
|
|
[%x %own ~] ``noun+!>(own.state)
|
2021-11-10 20:39:43 +03:00
|
|
|
[%x %spo ~] ``noun+!>(spo.state)
|
2022-03-30 13:18:25 +03:00
|
|
|
[%x %refresh ~] ``atom+!>(refresh.state)
|
2021-08-27 17:05:59 +03:00
|
|
|
[%x %point @ ~] ``noun+(point i.t.t.path)
|
|
|
|
==
|
2021-09-05 13:36:19 +03:00
|
|
|
::
|
2021-08-27 17:05:59 +03:00
|
|
|
++ point
|
|
|
|
|= wat=@t
|
|
|
|
^- vase
|
|
|
|
!> ^- (unit point:naive)
|
|
|
|
?~ ship=(rush wat ;~(pfix sig fed:ag))
|
|
|
|
~
|
|
|
|
(get:orm:naive points.nas.state u.ship)
|
|
|
|
--
|
|
|
|
::
|
|
|
|
++ on-agent
|
|
|
|
|= [=wire =sign:agent:gall]
|
|
|
|
^- (quip card _this)
|
|
|
|
?. ?=([%eth-watcher ~] wire)
|
|
|
|
(on-agent:def wire sign)
|
|
|
|
?. ?=(%fact -.sign)
|
|
|
|
(on-agent:def wire sign)
|
|
|
|
?. ?=(%eth-watcher-diff p.cage.sign)
|
|
|
|
(on-agent:def wire sign)
|
|
|
|
=+ !<(diff=diff:eth-watcher q.cage.sign)
|
|
|
|
?: ?=(%disavow -.diff)
|
|
|
|
[(jael-update:do [*ship id.diff %disavow ~]~) this]
|
|
|
|
::
|
|
|
|
=. logs.state
|
|
|
|
?- -.diff
|
|
|
|
:: %history loglist.diff
|
|
|
|
%history (welp logs.state loglist.diff)
|
|
|
|
%logs (welp logs.state loglist.diff)
|
|
|
|
==
|
2022-01-08 11:48:28 +03:00
|
|
|
:: doing :azimuth|watch caused a l2-sig-fail when using the eth-log
|
|
|
|
:: snapshot because we were not updating nas with the saved logs.
|
|
|
|
::
|
2022-05-07 17:27:04 +03:00
|
|
|
:: now nas.state is loaded with the contents of the snapshot,
|
2022-01-08 11:48:28 +03:00
|
|
|
:: if we are on the %default network.
|
|
|
|
::
|
2021-08-27 17:05:59 +03:00
|
|
|
=^ effects state (run-logs:do loglist.diff)
|
|
|
|
:_ this
|
|
|
|
%+ weld
|
|
|
|
(event-update:do effects)
|
|
|
|
(jael-update:do (to-udiffs:do effects))
|
|
|
|
::
|
2021-11-10 03:42:03 +03:00
|
|
|
++ on-arvo
|
|
|
|
|= [=wire =sign-arvo]
|
azimuth: fetch snapshot on boot
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.
2022-07-01 08:55:57 +03:00
|
|
|
?: &(=(/al wire) ?=(%arow +<.sign-arvo))
|
|
|
|
?- -.p.sign-arvo
|
|
|
|
%& `this
|
|
|
|
%|
|
|
|
|
%- (slog 'loading azimuth snapshot failed! still trying' p.p.sign-arvo)
|
|
|
|
[~[(init-timer (add ~s10 now.bowl))] this]
|
|
|
|
==
|
2021-11-10 03:42:03 +03:00
|
|
|
?. &(=(/init wire) ?=(%wake +<.sign-arvo))
|
|
|
|
(on-arvo:def wire sign-arvo)
|
2021-11-17 08:08:01 +03:00
|
|
|
?^ error.sign-arvo
|
|
|
|
%- (slog 'azimuth: failed to initialize!' ~)
|
|
|
|
`this
|
2021-11-10 03:42:03 +03:00
|
|
|
:_ this
|
azimuth: fetch snapshot on boot
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.
2022-07-01 08:55:57 +03:00
|
|
|
~[start-azimuth-load]
|
2021-11-10 03:42:03 +03:00
|
|
|
::
|
2021-08-27 17:05:59 +03:00
|
|
|
++ on-fail on-fail:def
|
|
|
|
--
|
|
|
|
|_ =bowl:gall
|
2021-04-21 09:08:32 +03:00
|
|
|
::
|
2021-04-08 10:36:34 +03:00
|
|
|
++ verifier
|
|
|
|
^- ^verifier:naive
|
2021-04-29 01:38:28 +03:00
|
|
|
|= [dat=octs v=@ r=@ s=@]
|
2021-04-28 08:58:19 +03:00
|
|
|
?: (gth v 3) ~ :: TODO: move to jet
|
2021-04-08 10:36:34 +03:00
|
|
|
=/ result
|
|
|
|
%- mule
|
|
|
|
|.
|
|
|
|
=, secp256k1:secp:crypto
|
|
|
|
%- address-from-pub:key:ethereum
|
|
|
|
%- serialize-point
|
2021-04-29 01:38:28 +03:00
|
|
|
(ecdsa-raw-recover (keccak-256:keccak:crypto dat) v r s)
|
2021-04-08 10:36:34 +03:00
|
|
|
?- -.result
|
|
|
|
%| ~
|
|
|
|
%& `p.result
|
|
|
|
==
|
|
|
|
::
|
|
|
|
++ topics
|
|
|
|
|= ships=(set ship)
|
|
|
|
^- (list ?(@ux (list @ux)))
|
2021-04-15 11:02:58 +03:00
|
|
|
~
|
|
|
|
::
|
2021-12-03 18:11:15 +03:00
|
|
|
++ run-state
|
|
|
|
|= [=id:block =points:naive]
|
|
|
|
::%- road |. :: count memory usage in a separate road
|
|
|
|
^- =udiffs:point
|
|
|
|
%- flop
|
|
|
|
%+ roll (tap:orp:dice points)
|
|
|
|
|= [[=ship naive-point=point:naive] =udiffs:point]
|
|
|
|
=, naive-point
|
|
|
|
=/ =pass
|
|
|
|
(pass-from-eth:azimuth [32^crypt 32^auth suite]:keys.net)
|
|
|
|
^- (list [@p udiff:point])
|
2021-12-06 15:47:59 +03:00
|
|
|
:* [ship id %rift rift.net %.y]
|
|
|
|
[ship id %keys [life.keys.net suite.keys.net pass] %.y]
|
2021-12-03 18:11:15 +03:00
|
|
|
[ship id %spon ?:(has.sponsor.net `who.sponsor.net ~)]
|
|
|
|
udiffs
|
|
|
|
==
|
2021-06-28 08:26:47 +03:00
|
|
|
::
|
2021-04-08 10:36:34 +03:00
|
|
|
++ run-logs
|
2021-08-27 17:05:59 +03:00
|
|
|
|= [logs=(list event-log:rpc:ethereum)]
|
2021-08-04 16:53:57 +03:00
|
|
|
^- (quip tagged-diff _state)
|
2021-12-03 18:11:15 +03:00
|
|
|
=+ net=(get-network:dice net.state)
|
2021-11-17 07:03:20 +03:00
|
|
|
=| effects=(list tagged-diff)
|
|
|
|
!. :: saves 700MB replaying snapshot
|
|
|
|
=- =/ res (mule -)
|
|
|
|
?- -.res
|
|
|
|
%& p.res
|
|
|
|
%| (mean 'naive: fail!' p.res)
|
|
|
|
==
|
|
|
|
|.
|
2021-04-08 10:36:34 +03:00
|
|
|
?~ logs
|
2021-11-17 07:03:20 +03:00
|
|
|
[(flop effects) state]
|
2021-04-08 10:36:34 +03:00
|
|
|
?~ mined.i.logs
|
|
|
|
$(logs t.logs)
|
2021-11-24 17:31:59 +03:00
|
|
|
=+ cache=nas.state
|
|
|
|
=^ raw-effects nas.state
|
2021-04-15 11:02:58 +03:00
|
|
|
=/ =^input:naive
|
2021-09-27 17:29:12 +03:00
|
|
|
:- block-number.u.mined.i.logs
|
2021-08-27 17:05:59 +03:00
|
|
|
?: =(azimuth.net address.i.logs)
|
2021-12-03 18:11:15 +03:00
|
|
|
=/ data (data-to-hex:dice data.i.logs)
|
2021-04-15 11:02:58 +03:00
|
|
|
=/ =event-log:naive
|
|
|
|
[address.i.logs data topics.i.logs]
|
|
|
|
[%log event-log]
|
|
|
|
?~ input.u.mined.i.logs
|
|
|
|
[%bat *@]
|
2021-05-29 15:57:57 +03:00
|
|
|
[%bat u.input.u.mined.i.logs]
|
2021-11-17 07:03:20 +03:00
|
|
|
(%*(. naive lac |) verifier chain-id.net nas.state input)
|
2021-11-25 23:22:15 +03:00
|
|
|
:: TODO: make index update optional?
|
|
|
|
::
|
2021-11-24 17:31:59 +03:00
|
|
|
=/ =indices [own spo]:state
|
|
|
|
=. indices
|
2021-11-25 23:22:15 +03:00
|
|
|
?: =(naive.net address.i.logs)
|
|
|
|
(tx-effects:dice chain-id.net raw-effects cache indices)
|
2021-11-24 17:31:59 +03:00
|
|
|
=< indices
|
2021-11-28 18:37:06 +03:00
|
|
|
(point-effects:dice raw-effects points.cache points.nas.state indices)
|
2021-11-24 17:31:59 +03:00
|
|
|
=: own.state own.indices
|
|
|
|
spo.state spo.indices
|
2021-08-27 17:05:59 +03:00
|
|
|
==
|
2021-04-08 10:36:34 +03:00
|
|
|
=/ effects-1
|
|
|
|
=/ =id:block [block-hash block-number]:u.mined.i.logs
|
|
|
|
(turn raw-effects |=(=diff:naive [id diff]))
|
2021-11-17 07:03:20 +03:00
|
|
|
=. effects (welp (flop effects-1) effects)
|
|
|
|
$(logs t.logs)
|
2021-04-08 10:36:34 +03:00
|
|
|
::
|
|
|
|
++ to-udiffs
|
|
|
|
|= effects=(list tagged-diff)
|
|
|
|
^- =udiffs:point
|
|
|
|
%+ murn effects
|
|
|
|
|= tag=tagged-diff
|
|
|
|
^- (unit [=ship =udiff:point])
|
|
|
|
?. ?=(%point +<.tag) ~
|
2021-04-29 06:51:43 +03:00
|
|
|
?+ +>+<.tag ~
|
2021-12-06 15:47:59 +03:00
|
|
|
%rift `[ship.tag id.tag %rift rift.tag %.n]
|
2021-04-29 06:51:43 +03:00
|
|
|
%sponsor `[ship.tag id.tag %spon sponsor.tag]
|
|
|
|
%keys
|
|
|
|
=/ =pass
|
|
|
|
(pass-from-eth:azimuth 32^crypt.keys.tag 32^auth.keys.tag suite.keys.tag)
|
2021-12-06 15:47:59 +03:00
|
|
|
`[ship.tag id.tag %keys [life.keys.tag suite.keys.tag pass] %.n]
|
2021-04-08 10:36:34 +03:00
|
|
|
==
|
|
|
|
::
|
|
|
|
++ jael-update
|
|
|
|
|= =udiffs:point
|
2021-08-27 17:05:59 +03:00
|
|
|
^- (list card)
|
2021-04-08 10:36:34 +03:00
|
|
|
:- [%give %fact ~[/] %azimuth-udiffs !>(udiffs)]
|
2021-08-27 17:05:59 +03:00
|
|
|
|- ^- (list card)
|
2021-04-08 10:36:34 +03:00
|
|
|
?~ udiffs
|
|
|
|
~
|
|
|
|
=/ =path /(scot %p ship.i.udiffs)
|
|
|
|
:: Should really give all diffs involving each ship at the same time
|
|
|
|
::
|
|
|
|
:- [%give %fact ~[path] %azimuth-udiffs !>(~[i.udiffs])]
|
|
|
|
$(udiffs t.udiffs)
|
|
|
|
::
|
2021-07-08 17:45:27 +03:00
|
|
|
++ event-update
|
2021-05-29 15:53:57 +03:00
|
|
|
|= effects=(list tagged-diff)
|
2021-08-27 17:05:59 +03:00
|
|
|
^- (list card)
|
2021-05-29 15:53:57 +03:00
|
|
|
%+ murn effects
|
|
|
|
|= tag=tagged-diff
|
2021-08-27 17:05:59 +03:00
|
|
|
^- (unit card)
|
2021-07-08 17:45:27 +03:00
|
|
|
?. |(?=(%tx +<.tag) ?=(%point +<.tag)) ~
|
2021-05-29 15:53:57 +03:00
|
|
|
%- some
|
2021-08-27 17:05:59 +03:00
|
|
|
^- card
|
2021-07-08 17:45:27 +03:00
|
|
|
[%give %fact ~[/event] %naive-diffs !>(+.tag)]
|
2021-05-29 16:42:27 +03:00
|
|
|
::
|
2021-04-08 10:36:34 +03:00
|
|
|
++ start
|
2021-08-27 17:05:59 +03:00
|
|
|
^- (list card)
|
2021-12-03 18:11:15 +03:00
|
|
|
=+ net=(get-network:dice net.state)
|
2021-04-08 10:36:34 +03:00
|
|
|
=/ args=vase !>
|
2021-08-27 17:05:59 +03:00
|
|
|
:+ %watch /[dap.bowl]
|
2021-04-08 10:36:34 +03:00
|
|
|
^- config:eth-watcher
|
2022-03-30 13:18:25 +03:00
|
|
|
:* url.state =(%czar (clan:title our.bowl)) refresh.state ~h30
|
azimuth: fetch snapshot on boot
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.
2022-07-01 08:55:57 +03:00
|
|
|
(max launch.net ?:(=(net.state %default) +(number.id.sap.state) 0))
|
2022-04-06 15:04:05 +03:00
|
|
|
~
|
2021-08-27 17:05:59 +03:00
|
|
|
~[azimuth.net]
|
|
|
|
~[naive.net]
|
2021-04-08 10:36:34 +03:00
|
|
|
(topics whos.state)
|
|
|
|
==
|
2022-05-07 17:27:04 +03:00
|
|
|
[(start-log-retrieval our.bowl args)]~
|
2021-04-08 10:36:34 +03:00
|
|
|
--
|