Constitution + jael updates

[Fang-]

This PR contains two sets of changes.

First, it updates the zuse-constitution and jael logic to work more cleanly with the current version of the contracts. Aside from a few tweaks, I did a quick look-over of the existing logic, and it all still seems to match the contracts.

Secondly, it makes jael track continuity... sort of. When a ship indicates a continuity breach on-chain (or we've just never met it before), its live aka continuity flag will get set to |. It is then up to @joemfb's modified ames to send a %meet task to jael when we finally manage to connect with that ship again, setting the flag to &.
Changes to this flag get sent as part of the existing %pubs subscription, which has been updated to always send full public key state for a ship (now [live=? life=life pubs=(map life pass)]) rather than just the changes.

...That continuity flag is stored as part of jael's state-relative, even though it really is absolute state (ie can't be deduced from other parts of the state). It would be more correct to store a list of [ship life]s we've "met" alongside the Ethereum event logs, but that also feels a bit janky.
For now, I feel like this slight architectural mismatch isn't a big deal. This particular piece of state might need more work in the near future, I'd rather wait for the dust to settle before refactoring this.

I have lightly tested this and expect it to be correct based on that. No stress-testing was done though, but the logic here isn't too fragile.

[cgyarvin]

I hope everyone realizes that this means —or will eventually mean! — we never have a global breach again.

…

Sent from my iPhone

On Aug 29, 2018, at 5:24 PM, Fang ***@***.***> wrote: This PR contains two sets of changes. First, it updates the zuse-constitution and jael logic to work more cleanly with the current version of the contracts. Aside from a few tweaks, I did a quick look-over of the existing logic, and it all still seems to match the contracts. Secondly, it makes jael track continuity... sort of. When a ship indicates a continuity breach on-chain (or we've just never met it before), its live aka continuity flag will get set to |. It is then up to @joemfb's modified ames to send a %meet task to jael when we finally manage to connect with that ship again, setting the flag to &. Changes to this flag get sent as part of the existing %pubs subscription, which has been updated to always send full public key state for a ship (now [live=? life=life pubs=(map life pass)]) rather than just the changes. ...That continuity flag is stored as part of jael's state-relative, even though it really is absolute state (ie can't be deduced from other parts of the state). It would be more correct to store a list of [ship life]s we've "met" alongside the Ethereum event logs, but that also feels a bit janky. For now, I feel like this slight architectural mismatch isn't a big deal. This particular piece of state might need more work in the near future, I'd rather wait for the dust to settle before refactoring this. I have lightly tested this and expect it to be correct based on that. No stress-testing was done though, but the logic here isn't too fragile. You can view, comment on, or merge this pull request online at: #795 Commit Summary Update constitution and jael logic to work with latest contracts Include continuity flag in relative public key state Add %meet task to jael for indicating era connectivity Misc. jael notes and improvements File Changes M sys/vane/jael.hoon (133) M sys/zuse.hoon (35) Patch Links: https://github.com/urbit/arvo/pull/795.patch https://github.com/urbit/arvo/pull/795.diff — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[Fang-]

Network breach headaches are dead. Long live node breach headaches!

[joemfb]

LGTM