jaekwon
commented
8 months ago Governance approval can become unnecessary after there is some safe virtualization or container or similar of the desired dapp. The dapp could be offered as a linux container image for example. I think this is the right way to go, with ABCI1.5 more or less designed for ICS1.5. But validators need to be ready to deal with images that have exploits in them, and this could for example even root your whole datacenter. We need to deal with isolation and recovery anyways even with permissioning anyways so might as well solve it completely and allow for arbitrary images. Anyways my point is, eventually this should become permissionless.
And there will be some number of parameters that deal with how many virtual machines (or virtual chains) are available and on standby for assignment to its dapp image (say), and how much storage each of these machines have, and also some of these machines can connect to the equivalent of Amazon elastic block stores, or infinite AVL stores (for example), and each virtual chain will need to reserve some amount of storage space too and require some minimal amount of RAM. Given that AtomOne is trying to be simple and minimal, I think it can just support at first a single configuration of machines for all shards for now (e.g. the same amount of disk, memory, cpu for every shard), and allow other splits to innovate on variations. But it also makes sense for AtomOne to only target what can run on a developer machine or laptop because this assumption if enforced is good for decentralization. Another hub can allow for large disk space for example, but not everyone will be able to sync such a chain, so it is less decentralized without refactoring the design.
Some conditions to consider:
- must have a well defined governance set.
- must have a constitution & bylaws.
- must define recovery procedure, but within a template provided by AtomOne.
- must select a jurisdictional identifier, or self-sovereign (see "how to immunize against the mark of the beast")
- must pay some minimum deposit / down payment
- must pay rent (whoever ends up paying it, often the shard itself)
Monitoring... yeah they should even pay AtomOne extra so we can hire somebody to monitor them periodically. But just because some of these are violated, or not well kept to date, doesn't mean the shard should be shut down or paused necessarily. Like if the bylaws are out of date should the chain be paused? Maybe one flag says this chain should never be paused even if governance is not responsive, that it has no recovery mechanism (no emergency contact), and even if its constitution/bylaws are out of date or inconsistent with each other, as long as rent is paid the logic doesn't error. Whereas other shards/dapps will want more automation and help from AtomOne or whoever it delegates authority to.
In addition to obtaining governance approval, should we establish any hardcoded conditions for becoming an ICS consumer of the hub, encoded directly into the software? Also, if we define these conditions, should we continuously monitor them over time?