buckysballs
commented
3 years ago Apparently dependencies cannot be removed, so to be VERY clear, neither of these dependencies are blocking this ticket, nor each other
Closed buckysballs closed 3 years ago
buckysballs
commented
3 years ago Apparently dependencies cannot be removed, so to be VERY clear, neither of these dependencies are blocking this ticket, nor each other
Once we have out ACI registry, we're ready to re-implement L0 conensus, or rather the majority snapshot selection process. Like L1, we can build a pipeline from a continuous source sunk into a Cell that incrementally decides majorities by updating a local cache and if necessary, re-download to realign the node if it notices it is not in the majority. We should be able to define this as an ifM in a CV algebra where new proposals are input to the cache and if after updating the node is not in majority, it re-downloads.
There is one other thing that we will want to do is use Snapshots and more specifically, when a height reaches majority, to add ACI to the schema registry. We will need a custom Transaction type that contains the ACI. When the ACI is accepted, we need to then update the database, and then allow the Balance Update fcn to move funds according to what is in the ACI (Note the example I gave in the registry ticket does not go into this but its just a few more float fields.) In order to simplify everything, we can just make the database immutable. If there ever needs to be a change to an ACI, the address that sent it can simply deploy another and migrate their downstream services.
Due to the new registry, we will want to add some sort of reference to the contents of the registry in SnapshotInfo. We could calculate a hash of the table and rely on guarantees given by proof of space (the time and cost it takes to break is orders of magnitude beyond convergence time, see 2.2 here https://www.chia.net/assets/ChiaGreenPaper.pdf)
Note, we actually should charge a fee for deployment, since it takes up space in the registry.
DoD) 1) implementation of majority state chooser using GAS (scatter would be the redownload requests) 2) Pipeline sinking Snapshots into MajorityStateChooser 3) Insert to registry based upon new ACI (don't worry about balance update)
One more note, we will need to rely on some sort of build in order for the types in Kryo to interoperate. If one channel compiles a new jar, the new jar and official $dag release will not be compatible. So what we can do for now ($ltx launch) is manually re-release main net with the ACI of $ltx such that kryo registrars are compatible. In the future, we can solve this by creating out own build server which just loads in a new ACI and outputs a new jar containing the Kryo registry updated for a given snapshot height. Each snapshot then, will be the version of the kryo registrar for verifying the total state.